De markt is volledig ongevoelig geworden voor "high-speed public chains", waarom is Somnia anders?

Auteur: TVBee

Dit artikel wordt geanalyseerd aan de hand van de volgende twee vragen:

Vraag 1: De markt is volledig ongevoelig geworden voor de "high-speed public chain", waarom is Somnia anders?

Vraag 2: Schept Sommia op over de snelste en meest kosteneffectieve parallelle EVM Layer 1?

➡️➡️➡️ Jane • Clean • Editie ⬅️⬅️⬅️

In dit deel wordt Sonnia samengevat vanuit drie dimensies: technologie, achtergrond en ecologie, zodat u de hoogtepunten en voordelen van het Somnia-project kunt begrijpen.

💠De technische hoogtepunten van Somnia

🔹 Multi-stream consensusalgoritme: dataketen + consensusketen, die bevorderlijk is voor het voorkomen van MEV, het verminderen van redundantie, het verlagen van kosten en het verhogen van de efficiëntie.

🔹 Innovatieve EVM-compiler: Implementeert parallelle EVM op instructieniveau om hoogfrequente interacties in extreme gevallen op te lossen.

🔹 Zelf ontwikkelde IceDB-database-engine: verbetert de lees-/schrijfsnelheid van gegevens en de stabiliteit van het netwerk.

🔹 Gegevenscompressietechnologie: Verbeter de efficiëntie van de gegevensoverdracht.

💠De voordelen van Somnia

🔹 Team: Het ontwikkelingsteam is van Improbable, een multinationaal technologiebedrijf dat in 2012 is opgericht en zijn hoofdkantoor heeft in Londen, VK. Hij heeft software, games en Web3 metaverse-producten ontwikkeld.

🔹 Financiering: In totaal werd $ 270 miljoen geïnvesteerd door MSquared, a16z, SoftBank, Mirana en andere bekende instellingen.

💠Ecologische vooruitgang in Somnia

🔹 Ecologisch landschap: Het Somnia-testnet heeft zich al gevestigd in 4 AI/sociale producten, 7 games, 4 NFT-projecten en 6 Defi-applicaties, en nog eens 2 AI/sociale producten, 11 games en 1 Defi-applicatie zullen binnenkort worden gelanceerd.

🔹 Ecologische gegevens: Vanaf de lancering eind februari 2025 tot het moment van schrijven (26 juni 2025) heeft het Somnia-testnet meer dan 100 miljoen blokken geproduceerd, met een gemiddelde productietijd van 0,1 seconde per blok. In totaal namen 96.878.557 wallet-adressen deel aan het testnet, met een handelsvolume van 26,43 miljoen in de afgelopen 1 dag.

Op block explorers zie je vaak het aantal transacties en blokken constant knipperen, wat Sonnia "subsecundair" noemt, wat met het blote oog zichtbaar is.

💠 Waarom zou Somnia anders kunnen zijn?

🔹 Hoogfrequente interactie: Hoewel de markt volledig ongevoelig is geworden voor het concept van "high-speed public chain", streeft Somnia niet alleen naar technische indicatoren, maar richt het zich op hoe Web3-technologie echt geschikt kan zijn voor toepassingsscenario's, vooral in hoogfrequente gerelateerde interactiegebieden zoals games en sociale netwerken.

🔹Web3 vs. Web3 Convergentie: De unieke achtergrond van Somnia kan een sleutelrol spelen bij de convergentie van Web3 en Web2. Somnia heeft het potentieel om Web2-gebruikers naadloze toegang te bieden tot de Web3-wereld, wat mogelijk kan leiden tot een echt gebruikersgericht applicatie-ecosysteem.

➡️➡️➡️ Details• Uitleg• Editie ⬅️⬅️⬅️

Het vorige deel introduceerde de hoogtepunten, voordelen en ecologische vooruitgang van [WHAT] Somnia, en dit deel zal een diepgaande interpretatie geven van de technologie van Somnia. Laat iedereen begrijpen hoe [HOE] Somnia technisch hoogfrequente interactie bereikt, hoe lage kosten en hoge prestaties kunnen worden bereikt, en waarom [WAAROM] Somnia anders is dan andere parallelle EVM-projecten.

💠 Multi-stream consensusalgoritme: dataketen + consensusketen

🔹 Overzicht: Dataketen + consensusketenstructuur

Somnia maakt gebruik van een nieuw multistream consensus (MULTISTREAM) algoritme.

In de zogenaamde multi-stream registreert Somnia transactie-informatie op meerdere dataketens, elke datalink wordt door 1 validator geregistreerd en elke validator kan de dataketen van andere validators niet verstoren.

Somnia voert consensus uit op de consensusketen, sorteert transacties en registreert verwijzingen naar transacties in de consensusketen. De consensusketen wordt uitgevoerd en onderhouden door alle validators.

🔹 Overzicht: Workflow voor Somnia multi-stream consensus

a Nadat een gebruiker een verzoek heeft ingediend bij het Somnia-netwerk, schrijft de validator die het verzoek ontvangt de transactie afzonderlijk naar de dataketen.

b Elke andere tijdsperiode (bijv. 30 seconden, 1 seconde, enz.) van de consensusketen, uploaden en downloaden de validator van de datalink en andere datalinkvalidators de datashards bovenaan de dataketen.

C De validator schrijft de verzameling datashards bovenaan alle dataketens naar de consensusketen als een volledige dataslice.

d Validators sorteren de transacties en alle validators worden synchroon naar de IceDB-database van Somnia geschreven op basis van de bijgewerkte status van de gesorteerde transacties.

🔹 Hoogtepunten: Somnia's transactiesequencing is goed voor MEV-preventie

Somnia gebruikt een deterministische pseudo-willekeurige functie om transacties te sorteren.

We weten dat er geen echte willekeur in het rekenprogramma zit, maar pseudo-willekeur door middel van algoritmen. Deterministische pseudowillekeurige functies hebben twee kenmerken: de ene is willekeur, die niet voorspelt wat het volgende willekeurige getal zal zijn, maar elke validator zal hetzelfde willekeurige getal in een vaste volgorde genereren wanneer het wordt uitgevoerd.

Op deze manier voeren alle validators dezelfde deterministische pseudo-willekeurige functie uit, die een reeks identieke willekeurige getallen genereert en de dataketen sorteert op basis van de willekeurige getallen. Op basis hiervan worden de transacties voor deze periode gesorteerd.

De gesorteerde gegevensketen is bijvoorbeeld B, A, C......

Dan is de volgorde van de transactie dat de transactie van dataketen B eerst komt, gevolgd door dataketen A en dataketen C...... Natuurlijk verwijdert dit proces dubbele transacties op basis van de hash-waarde.

Natuurlijk ligt de volgorde van de dataketen vast, maar de volgorde van transacties in verschillende dataketens kan verschillen. In datachain A kan transactie 1 bijvoorbeeld vooraan en transactie 2 achteraan plaatsvinden, terwijl in datachain B transactie 2 vooraan en transactie 1 achteraan kan plaatsvinden. Aangezien de volgorde van de gegevensketen B voor A is, is de uiteindelijke transactievolgorde transactie 2 vóór en transactie 1 als laatste.

Het voordeel van deze bestelmethode is dat het voor een MEV-aanvaller moeilijk is om de validator om te kopen omdat hij niet weet wat de dataketen is die overeenkomt met de validator. Als er in totaal 100 validatorknooppunten op het netwerk zijn, ervan uitgaande dat zelfs als een MEV-aanvaller 50 validators omkoopt, zolang er een validator is (inclusief de aangevallen transactie) die niet is omgekocht in het bijzijn van deze 50 validators, zal de consensusketen worden geregistreerd in de juiste volgorde van transacties en zal de MEV-aanval mislukken.

🔹 Hoogtepunten: Verminder redundantie, verlaag de kosten en verhoog de efficiëntie

Aan de ene kant registreert Somnia een aparte dataketen voor elke validator en is er geen datavalidatieproces tussen validators. Bij het overbrengen van snapshots wordt alleen de snapshot-informatie van elke gegevenslink verzonden en bevat de snapshot-informatie geen specifieke transactie-informatie, zodat de redundantie van de interactie wordt verminderd.

Aan de andere kant hoeft elke dataketen in Somnia de informatie van andere dataketens niet te synchroniseren, en de consensusketen registreert geen transactie-informatie, maar registreert om de andere periode een momentopname van de dataketeninformatie en de gesorteerde transactieverwijzingen (hash-waarden). Op deze manier wordt de redundantie van opslag verminderd.

Dankzij de verminderde redundantie van interacties kan Somnia efficiënter werken.

Somnia moet tegen lagere kosten werken vanwege verminderde redundantie van opslag.

🔹 Toegevoegd: Sabotagebestendige datalinks

Hoewel er geen verificatie is van de informatie in de gegevensketen, kan de validator niet knoeien met de transactie-informatie. Want zodra een validator met de transactie-informatie knoeit, zal dit de hash-waarde van de transactie en de hash-waarde van de volgende transacties beïnvloeden, wat resulteert in een conflict tussen de informatie en de informatie die is opgeslagen in de consensusketen.

💠 Parallelle EVM op instructieniveau

🔹 Pijnpunt: Het is moeilijk om de congestie van hoogfrequente interacties bij parallelle transacties te verbeteren

De parallelle EVM van Somnia verschilt van Monad en Reddio, en het EVM-parallellisme van deze drie ketens is transactieparallellisme, dat wil zeggen dat transacties parallel lopen om de snelheid van transacties te verbeteren.

Monad is optimistisch in het parallel laten verlopen van transacties, het detecteren van conflicten en het corrigeren ervan. Reddio daarentegen is een parallelle transactie die niet conflicteert en geen afhankelijkheden heeft.

Wanneer er echter een groot aantal transacties met verbonden partijen plaatsvindt, kunnen de transacties niet parallel lopen, zodat congestie gemakkelijk kan optreden. Er zijn twee extreme voorbeelden, zoals de plotselinge opkomst van een groot aantal gebruikers op het netwerk die USDC gebruiken om een bepaald token te verhandelen, en deze transacties kunnen niet worden geparallelliseerd omdat ze moeten worden verhandeld met LP-pools, maar kunnen alleen opeenvolgend worden uitgevoerd.

Een ander extreem voorbeeld zijn de talloze mensen die zich haasten om dezelfde NFT te slaan, die ook niet parallel kan zijn, omdat het aantal NFT's eindig is en opeenvolgend moet worden uitgevoerd om te bepalen welke mensen kunnen slagen in Mint en andere falen.

Reddio's oplossing voor dit probleem is het gebruik van de GPU, die de krachtige rekenkracht van de GPU gebruikt om deze congestie van hoogfrequente interacties op te lossen. Hoewel het de efficiëntie van de handel kan verbeteren, verhoogt het ook de handelskosten.

🔹 Hoogtepunt: Parallelle EVM op instructieniveau

Om het congestieprobleem op te lossen dat een groot aantal transacties met verbonden partijen tegelijkertijd wordt uitgevoerd en transacties moeilijk parallel op te lossen zijn, heeft Sommia op innovatieve wijze een EVM-compiler ontwikkeld.

In een standaard EVM-uitvoering kan de uitvoering van orders in een transactie alleen sequentieel worden geïnterpreteerd. Somnia ondersteunt echter het opsplitsen van transacties in verschillende instructiesets die niet conflicteren en geen afhankelijkheden hebben.

Als we Swap trading als voorbeeld nemen, kan het worden onderverdeeld in verschillende instructiesets op basis van functies: parameterverificatie, parameterverwerking, saldocontrole, autorisatiecontrole, poolstatuscontrole, prijsberekening, kostenberekening, overdracht van inputtokens, update poolstatus en vergoedingsrecords, overdracht van outputtokens en lancering van evenementen. Onder hen kan de instructieset die niet conflicteert en geen afhankelijkheden heeft, worden geparallelliseerd om de uitvoeringsefficiëntie van transacties te verbeteren.

De sleutel tot de parallelle EVM van de instructieset is de originele EVM-compiler van Somnia, die de bytecode van de EVM compileert in x86-machinecode. Moderne CPU's zijn multi-threaded cores en elke CPU-core kan machinecode parallel lopen op meerdere threads, zodat verschillende vingersets van de EVM kunnen worden geparallelld, waardoor de uitvoeringssnelheid van een enkele transactie wordt verhoogd. Daarom kan Somnia ook op hardwareniveau een parallelle EVM worden genoemd.

🔹 Hoogtepunten: Kosten en efficiëntie

Uitvoering van standaard EVM-interpretatie: transactie 1 → geparseerd naar bytecode → uitvoering van sequentiële interpretatie→ transactie 2 →geparseerd naar bytecode → uitvoering van sequentiële interpretatie→ transactie 3 →geparseerd naar bytecode → uitvoering van sequentiële interpretatie......

EVM-compilatie en -uitvoering van Somnia: contractcode → geparseerd in bytecode→ dynamisch gecompileerd in machinecode→ instructieset voor parallelle uitvoering van transactie 1→ instructieset voor parallelle uitvoering van transactie 2→ instructieset voor parallelle uitvoering van transactie 3......

Zoals te zien is, hoe meer transacties er zijn, hoe voordeliger de EVM-compilatie en -uitvoering van Somnia zal zijn.

Daarom gebruikt Somnia voor gewone niet-hoogfrequente handel nog steeds de standaard uitvoering van de EVM-interpretatie, elke keer dat de EVM wordt uitgevoerd, wordt de slimme contractcode geparseerd in EVM-bytecode en wordt de uitvoering in volgorde geïnterpreteerd.

Voor gecentraliseerde, hoogfrequente uitvoering van transacties schakelt Somnia de EVM-compiler in, die de bytecode van de EVM compileert in x86-machinecode. Vervolgens kan de machinecode herhaaldelijk worden uitgevoerd volgens de parameters om snel gecentraliseerde hoogfrequente handel te voltooien, wat niet mogelijk is met parallelle EVM op transactieniveau.

Als gevolg hiervan kan Somnia een dubbel voordeel behalen tussen kosten en efficiëntie.

💠IceDB-database-engine

🔹 Overzicht: Gebruik LSM-bomen in plaats van Merkle-boomgegevensstructuren

De overgrote meerderheid van de blockchains maakt gebruik van de Merkle Tree-gegevensstructuur. De leaf-knooppunten van de Merkle-boom slaan de hash van de transactiegegevens op (of de transactiegegevens zelf, en hashen deze vervolgens), terwijl de niet-bladknooppunten de hash-waarde van de hash-waarde van hun onderliggende knooppunten opslaan, en de hash-waarde wordt laag voor laag berekend, en ten slotte wordt een Merkle-wortel berekend, zodat de integriteit van de gegevens in het blok veilig kan worden geverifieerd en er met de gegevens kan worden geknoeid.

Als we de gegevensopslag van het ERC20-tokencontract als voorbeeld nemen, omvatten de bladknooppunten van de Merkle-boom:

• Sla attributen op zoals TotalSupply en NameSymbol, die elk overeenkomen met een sleutel (attribuutnaam) en een waarde (attribuutwaarde);

• De status van alle adressen die tokens bevatten, die elk overeenkomen met een sleutel (adreshash) en een waarde (het aantal tokens);

• Alle autorisatiestatus van het token, elk autorisatieadres komt overeen met een sleutel (adreshash) en een waarde (autorisatiebedrag);

……

Laten we zeggen dat een ERC-token 4 attributen, 32.000 holdingadressen en 2.764 geautoriseerde adressen heeft. Dit bedrag is natuurlijk niet veel. Maar er zijn in totaal 32.768 leaf-nodes en er moeten 65.535 hashes worden berekend om de Merkle-rechten van het token te schrijven.

De zelf ontwikkelde IceDB-database-engine van Somnia maakt geen gebruik van de veelgebruikte Merkle-boomgegevensstructuur, dus er zit geen hash-root in de blokinformatie.

IceDB maakt gebruik van de Log-Structured Merge-Tree (LSM Tree). Dit is een op logboeken gebaseerde boomgegevensstructuur waarvan het belangrijkste kenmerk is dat gegevens worden toegevoegd en geschreven in plaats van ter plaatse te worden gewijzigd, zodat er geen probleem is met knoeien.

Bij het schrijven naar een IceDB-database wordt eerst de in-memory MemTable geschreven. Wanneer de MemTable vol is, wordt deze naar de schijf gespoeld, waardoor een SSTable ontstaat. LSM voegt SSTable periodiek samen terwijl dubbele sleutels worden verwijderd.

Voor dit proces hoeft de hash niet te worden berekend, alleen hoeven nieuwe gegevens naar de MemTable te worden geschreven, dus of de gegevens nu naar het geheugen, de cache of de schijf worden geschreven, de IceDB-database is aanzienlijk sneller.

🔹 Hoogtepunten: Lezen en schrijven op hogere snelheid

De datastructuur van de LSM-boom heeft een duidelijk prestatievoordeel bij het schrijven van gegevens. Daarnaast vermeldt de technische documentatie van Somnia dat "er een datacache is gecreëerd die zowel het lezen als het schrijven optimaliseert, zodat de gemiddelde lees- en schrijftijd van IceDB tussen de 15 en 100 nanoseconden ligt".

🔹 Kenmerken: Lees en schrijf prestatierapporten met eerlijk en efficiënt gas

In de meeste blockchain-netwerken heeft het laatste validatorknooppunt de neiging om dezelfde gegevens op te slaan. Gedurende een korte periode is er echter een zekere discrepantie tussen het geheugen van verschillende validator-nodes en de gegevens die op schijf zijn opgeslagen. Als gevolg hiervan zullen gebruikers verschillende hoeveelheden gas verbruiken bij het lezen en schrijven van gegevens vanwege de toegang tot verschillende locaties. Aan de andere kant kan het vanwege verschillende toegangslocaties lang duren voordat gebruikers gegevens hebben gelezen en geschreven, en het netwerkgas kan binnen dit tijdsbestek veranderen. Daarom is het moeilijk om een eerlijk en efficiënt gas te bepalen. Als het gas wordt onderschat, kunnen knooppunten passief zijn vanwege de lage inkomsten, wat de efficiëntie van het netwerk zal beïnvloeden. Als het gas wordt overschat, betalen gebruikers onnodige extra kosten, wat zelfs een kans kan bieden voor MEV-aanvallen.

Onder de IceDB-database-engine kunt u elke keer dat u gegevens leest of schrijft, de gegevens die u nodig hebt niet in de cache vinden, dus moet u gegevens uit respectievelijk het geheugen en de SSD lezen, de frequentie van het lezen van gegevens uit het geheugen en de SSD tellen en een "prestatierapport" retourneren. Het "Prestatierapport" biedt een deterministische basis voor het berekenen van het gas dat gebruikers nodig hebben, waardoor het netwerkgas eerlijker en efficiënter wordt, ten gunste van het netwerk stablecoin.

💠 Technologie voor gegevenscompressie

Volgens de machtstheorie van informatievolume en frequentieverdeling die in het technische document van Somnia wordt geïntroduceerd, kunnen de gegevens met een hoge vergrotingssnelheid worden gecomprimeerd door de informatie samen te vatten op basis van de waarschijnlijkheid dat informatie optreedt.

Elke datalink in Somnia is verantwoordelijk voor een validator, en de validator hoeft niet het hele blok te verzenden, maar hoeft alleen de informatiestroom te verzenden, en de streamcompressie heeft een hogere compressiesnelheid, dus het is bevorderlijk voor het verbeteren van de netwerktransmissiecapaciteit.

Bovendien gebruikt Somnia BLS-handtekeningen om de snelheid van de overdracht en verificatie van handtekeningen te verbeteren.

Onder het multi-stream consensusalgoritme van Somnia sturen de validatorknooppunten van de dataketen gegevensscherven naar elkaar, en er is geen gecentraliseerde leider om de gegevens op een gecentraliseerde manier te uploaden en te downloaden, en de bandbreedte kan gelijkmatig worden verdeeld over de validators. Elke validator stuurt datashards naar andere validators en downloadt datashards die door andere validators zijn verzonden, dus de bandbreedte die nodig is voor het uploaden en downloaden van elke validator is symmetrisch. Daarom zal de transmissiecapaciteit van het Somnia-netwerk relatief evenwichtig en stabiel zijn.

💠 Schrijf aan het einde

Hoewel Web3 op het eerste gezicht meer high-end is dan Web2, is het technische systeem van Web2 in feite vaak complexer en volwassener. Wanneer Web2-ontwikkelaars betrokken zijn bij Web3-ontwikkeling, kan hun technische achtergrond meer innovatie in de blockchain-wereld brengen.