Marknaden har helt desensibiliserats för "snabba offentliga kedjor", varför är Somnia annorlunda?

Författare: TVBee

Den här artikeln kommer att analyseras med följande två frågor:

Fråga 1: Marknaden har helt desensibiliserat sig till den "offentliga höghastighetskedjan", varför är Somnia annorlunda?

Fråga 2: Skryter Sommia om det snabbaste och mest kostnadseffektiva parallella EVM Layer 1?

➡️➡️➡️ Jane • Ren • Edition ⬅️⬅️⬅️

I den här delen sammanfattas Sonnia ur tre dimensioner: teknik, bakgrund och ekologi, så att du kan förstå höjdpunkterna och fördelarna med Sonia-projektet.

💠Sominas tekniska höjdpunkter

🔹 Multi-stream konsensusalgoritm: datakedja + konsensuskedja, som bidrar till att förhindra MEV, minska redundans, minska kostnaderna och öka effektiviteten.

🔹 Innovativ EVM-kompilator: Implementerar parallell EVM på instruktionsnivå för att lösa högfrekventa interaktioner i extrema fall.

🔹 Självutvecklad IceDB-databasmotor: förbättrar läs-/skrivhastigheten för data och nätverksstabiliteten.

🔹 Datakomprimeringsteknik: Förbättra effektiviteten i dataöverföringen.

💠Somnias bakgrundsfördelar

🔹 Team: Utvecklingsteamet kommer från Improbable, ett multinationellt teknikföretag som grundades 2012 och har sitt huvudkontor i London, Storbritannien. Han har utvecklat mjukvara, spel och Web3 metaverse-produkter.

🔹 Finansiering: Totalt 270 miljoner dollar investerades av MSquared, a16z, SoftBank, Mirana och andra välkända institutioner.

💠Ekologiska framsteg i Somnia

🔹 Ekologiskt landskap: Sonia-testnätet har redan etablerat sig i 4 AI/sociala produkter, 7 spel, 4 NFT-projekt och 6 Defi-applikationer, och ytterligare 2 AI/sociala produkter, 11 spel och 1 Defi-applikation kommer snart att lanseras.

🔹 Ekologiska data: Från lanseringen i slutet av februari 2025 till skrivandet (26 juni 2025) har Sonia-testnätet producerat mer än 100 miljoner block, med en genomsnittlig produktionstid på 0,1 sekunder per block. Totalt 96 878 557 plånboksadresser deltog i testnätet, med en handelsvolym på 26,43 miljoner under den senaste 1 dagen.

På blockutforskare kan du ofta se antalet transaktioner och block som ständigt blinkar, vilket Sonnia kallar "sub-secondary", vilket är synligt för blotta ögat.

💠 Varför kan Somnia vara annorlunda?

🔹 Högfrekvent interaktion: Även om marknaden helt har desensibiliserat till begreppet "höghastighets offentlig kedja", strävar Somnia inte bara efter tekniska indikatorer, utan fokuserar på hur man kan få Web3-tekniken att verkligen tjäna applikationsscenarier, särskilt inom högfrekventa relaterade interaktionsområden som spel och sociala nätverk.

🔹Web3 vs. Web3 Convergence: Sominas unika bakgrund kan spela en nyckelroll i konvergensen mellan Web3 och Web2. Somnia har potential att ge Web2-användare sömlös tillgång till Web3-världen, vilket potentiellt kan leda till ett verkligt användarcentrerat applikationsekosystem.

➡️➡️➡️ Detaljer• Förklaring• Utgåva ⬅️⬅️⬅️

Den tidigare delen introducerade höjdpunkterna, fördelarna och de ekologiska framstegen med [VAD] Somnia, och denna del kommer att ge en djupgående tolkning av Somnias teknik. Låt alla förstå hur [HUR] Somnia tekniskt uppnår högfrekvent interaktion, hur man uppnår låg kostnad och hög prestanda och varför [VARFÖR] Somnia skiljer sig från andra parallella EVM-projekt.

💠 Konsensusalgoritm med flera strömmar: datakedja + konsensuskedja

🔹 Översikt: Datakedja + konsensuskedjestruktur

Somnia använder en ny algoritm för multistream-konsensus (MULTISTREAM).

I den så kallade multi-stream registrerar Somnia transaktionsinformation på flera datakedjor, varje datalänk registreras av 1 validerare och varje validerare kan inte störa andra validerares datakedja.

Somnia utför konsensus i konsensuskedjan, sorterar transaktioner och registrerar referenser till transaktioner i konsensuskedjan. Konsensuskedjan exekveras och underhålls av alla validerare.

🔹 Översikt: Arbetsflöde för Somnia multi-stream konsensus

a När en användare har gjort en begäran till Sonia-nätverket skriver valideraren som tar emot begäran transaktionen till datakedjan separat.

b Varannan tidsperiod (t.ex. 30 sekunder, 1 sekund osv.) i konsensuskedjan laddar valideraren av datalänken och andra datalänkvaliderare upp och laddar ner dataskärvorna högst upp i datakedjan.

C: Valideraren skriver samlingen av dataskärvor högst upp i alla datakedjor till konsensuskedjan som en komplett datadel.

d Validerare sorterar transaktionerna, och alla validerare skrivs synkront till Somnias IceDB-databas i enlighet med den uppdaterade statusen för de sorterade transaktionerna.

🔹 Höjdpunkter: Sominas transaktionssekvensering är bra för att förebygga MEV

Somnia använder en deterministisk pseudo-slumpmässig funktion för att sortera transaktioner.

Vi vet att det inte finns någon egentlig slumpmässighet i beräkningsprogrammet, utan pseudoslumpmässighet genom algoritmer. Deterministiska pseudoslumpmässiga funktioner har två egenskaper: den ena är slumpmässighet, som inte förutsäger vad nästa slumptal kommer att vara, men varje validerare kommer att generera samma slumptal i en fast ordning när den körs.

På detta sätt kör alla validerare samma deterministiska pseudo-slumpmässiga funktion, som genererar en serie identiska slumptal och sorterar datakedjan enligt slumptalen. På grundval av detta sorteras transaktionerna för den här perioden.

Den sorterade datakedjan är till exempel B, A, C......

Då är transaktionsordningen att transaktionen i datakedja B kommer först, följt av datakedja A och datakedja C...... Naturligtvis tar denna process bort dubbla transaktioner baserat på hashvärdet.

Naturligtvis är ordningen på datakedjan fast, men ordningen på transaktionerna i olika datakedjor kan vara olika. I datakedja A kan till exempel transaktion 1 vara längst fram och transaktion 2 längst bak, medan i datakedja B kan transaktion 2 ligga längst fram och transaktion 1 längst bak. Eftersom ordningen i datakedjan är B före A, är den slutliga transaktionsordningen transaktion 2 före och transaktion 1 sist.

Fördelen med denna beställningsmetod är att det är svårt för en MEV-angripare att muta valideraren eftersom han inte vet hur datakedjan som motsvarar valideraren kommer att se ut. Om det finns totalt 100 valideringsnoder i nätverket, förutsatt att även om en MEV-angripare mutar 50 validerare, så länge det finns en validerare (inklusive den attackerade transaktionen) som inte har mutats framför dessa 50 validerare, kommer konsensuskedjan att registreras i rätt ordning av transaktioner, och MEV-attacken kommer att misslyckas.

🔹 Höjdpunkter: Minska redundansen, minska kostnaderna och öka effektiviteten

Å ena sidan registrerar Somnia en separat datakedja för varje validerare, och det finns ingen datavalideringsprocess mellan validerare. Vid överföring av ögonblicksbilder överförs endast ögonblicksbildsinformationen för varje datalänk, och ögonblicksbildsinformationen innehåller inte specifik transaktionsinformation, så redundansen i interaktionen minskar.

Å andra sidan behöver varje datakedja i Somnia inte synkronisera informationen från andra datakedjor, och konsensuskedjan registrerar inte transaktionsinformation, utan registrerar en ögonblicksbild av datakedjans information och de sorterade transaktionsreferenserna (hashvärden) varannan tidsperiod. På så sätt minskar redundansen i lagringen.

Tack vare den minskade redundansen av interaktioner kan Somnia vara mer effektiv när du arbetar.

Somnia måste fungera till en lägre kostnad på grund av minskad redundans i lagringen.

🔹 Tillagt: Manipuleringssäkra datalänkar

Även om det inte finns någon verifiering av informationen i datakedjan kan valideraren inte manipulera transaktionsinformationen. För när en validerare manipulerar transaktionsinformationen kommer det att påverka hashvärdet för transaktionen och hashvärdet för dess efterföljande transaktioner, vilket resulterar i en konflikt mellan dess information och den information som lagras i konsensuskedjan.

💠 Parallell EVM på instruktionsnivå

🔹 Smärtpunkt: Det är svårt att förbättra trängseln av högfrekventa interaktioner i parallella transaktioner

Sominas parallella EVM skiljer sig från Monad och Reddio, och EVM-parallelliteten för dessa tre kedjor är transaktionsparallellitet, det vill säga transaktioner parallelliseras för att förbättra transaktionshastigheten.

Monad är optimistisk när det gäller att tillåta transaktioner att vara parallella, upptäcka konflikter och korrigera dem. Reddio, å andra sidan, är en parallell transaktion som inte står i konflikt och inte har några beroenden.

Men när ett stort antal transaktioner med närstående uppstår kan transaktionerna inte vara parallella, så överbelastning kan lätt uppstå. Det finns två extrema exempel, som den plötsliga uppkomsten av ett stort antal användare i nätverket som använder USDC för att handla en viss token, och dessa transaktioner kan inte parallelliseras eftersom de ska handlas med LP-pooler, utan endast kan utföras sekventiellt.

Ett annat extremt exempel är de otaliga människor som rusar till Mint samma NFT, vilket inte heller kan vara parallellt, eftersom antalet NFT:er är ändligt och måste utföras sekventiellt för att avgöra vilka människor som kan lyckas i Mint och andra misslyckas.

Reddios lösning på detta problem är att använda GPU:n, som använder GPU:ns kraftfulla datorkraft för att lösa denna överbelastning av högfrekventa interaktioner. Även om det kan förbättra effektiviteten i handeln, ökar det också kostnaderna för handel.

🔹 Höjdpunkt: Parallell EVM på instruktionsnivå

För att lösa överbelastningsproblemet med att ett stort antal närståendetransaktioner genomförs samtidigt och transaktioner är svåra att lösa parallellt har Sommia innovativt utvecklat en EVM-kompilator.

I en vanlig EVM-exekvering kan utförandet av order i en transaktion endast tolkas sekventiellt. Somnia stöder dock uppdelning av transaktioner i flera instruktionsuppsättningar som inte står i konflikt och inte har några beroenden.

Med Swap-handel som exempel kan den delas in i flera instruktionsuppsättningar enligt funktioner: parameterverifiering, parameterbehandling, saldokontroll, auktoriseringskontroll, poolstatuskontroll, prisberäkning, avgiftsberäkning, överföring av indatatokens, uppdateringspoolstatus och avgiftsposter, överföring av utdatatoken och händelselansering. Bland dem kan instruktionsuppsättningen som inte står i konflikt och inte har några beroenden parallelliseras för att förbättra exekveringseffektiviteten för transaktioner.

Nyckeln till instruktionsuppsättningen parallell EVM är Somanias ursprungliga EVM-kompilator, som kompilerar bytekoden för EVM till x86-maskinkod. Moderna CPU:er är flertrådade kärnor, och varje CPU-kärna kan parallellisera maskinkod på flera trådar, så att flera fingeruppsättningar av EVM kan parallelliseras, vilket ökar exekveringshastigheten för en enda transaktion. Därför kan Somnia också kallas en parallell EVM på hårdvarunivå.

🔹 Höjdpunkter: Kostnad och effektivitet

Utförande av standard-EVM-tolkning: transaktion 1 → tolkad till bytecode → sekventiell tolkningskörning→ transaktion 2 →tolkad till bytecode → sekventiell tolkningskörning→ transaktion 3 →tolkad till bytecode → sekventiell tolkningskörning......

Sominas EVM-kompilering och exekvering: kontraktskod → tolkas till bytekod→ kompileras dynamiskt till maskinkod→ instruktionsuppsättning för parallell exekvering av transaktion 1→ instruktionsuppsättning för parallell exekvering av transaktion 2→ instruktionsuppsättning för parallell exekvering av transaktion 3......

Som man kan se, ju fler transaktioner det finns, desto mer fördelaktig blir Sominas EVM-kompilering och exekvering.

Därför, för vanlig icke-högfrekvent handel, använder Somnia fortfarande standard EVM-tolkning, varje gång EVM körs, analyseras den smarta kontraktskoden till EVM-bytekod och exekveringen tolkas i ordning.

För centraliserad, högfrekvent exekvering av transaktioner möjliggör Somnia EVM-kompilatorn, som kompilerar bytekoden för EVM till x86-maskinkod. Sedan kan maskinkoden exekveras upprepade gånger enligt parametrarna för att snabbt slutföra centraliserad högfrekvent handel, vilket inte är möjligt med parallell EVM på transaktionsnivå.

Som ett resultat kan Somnia uppnå en dubbel fördel mellan kostnad och effektivitet.

💠Motor för IceDB-databas

🔹 Översikt: Använd LSM-träd istället för Merkle-träddatastrukturer

De allra flesta blockkedjor använder Merkle Tree-datastrukturen. Lövnoderna i Merkle-trädet lagrar hashen för transaktionsdata (eller själva transaktionsdatan och hashar den sedan), medan noderna som inte är lövnoder lagrar hashvärdet för hashvärdet för sina underordnade noder, och hashvärdet beräknas lager för lager, och slutligen beräknas en Merkle-rot, så att integriteten hos data i blocket kan verifieras på ett säkert sätt och data kan manipuleras.

Om vi tar datalagringen av ERC20-tokenkontraktet som ett exempel inkluderar bladnoderna i Merkle-trädet:

• Lagra attribut som TotalSupply och NameSymbol, som var och en motsvarar en nyckel (attributnamn) och ett värde (attributvärde);

• Innehavsstatus för alla adresser som innehar token, som var och en motsvarar en nyckel (adresshash) och ett värde (antalet tokens);

• All auktoriseringsstatus för token, varje auktoriseringsadress motsvarar en nyckel (adresshash) och ett värde (auktoriseringsbelopp);

……

Låt oss säga att en ERC-token har 4 attribut, 32 000 innehavsadresser och 2 764 auktoriserade adresser. Detta belopp är naturligtvis inte mycket. Men det finns totalt 32 768 lövnoder, och 65 535 hashvärden måste beräknas för att skriva Merkle-rättigheterna för token.

Sominas egenutvecklade IceDB-databasmotor använder inte den vanliga Merkle-träddatastrukturen, så det finns ingen hash-rot i dess blockinformation.

IceDB använder Log-Structured Merge-Tree (LSM Tree). Detta är en loggbaserad träddatastruktur vars huvudsakliga funktion är att data läggs till och skrivs istället för att ändras på plats, så det finns inga problem med manipulering.

När du skriver till en IceDB-databas skrivs MemTable i minnet först. När MemTable är full töms den till disken och bildar en SSTable. LSM sammanfogar med jämna mellanrum SSTable samtidigt som dubblettnycklar tas bort.

Denna process kräver inte att hashen beräknas, endast nya data behöver skrivas till MemTable, så oavsett om data skrivs till minnet, cacheminnet eller disken är IceDB-databasen betydligt snabbare.

🔹 Höjdpunkter: Högre hastighet för läsning och skrivning

LSM-träddatastrukturen har en klar prestandafördel när det gäller att skriva data. Dessutom nämns i den tekniska dokumentationen från Somnia att "en datacache har skapats som optimerar både läsningar och skrivningar, så att den genomsnittliga läs- och skrivtiden för IceDB är mellan 15 och 100 nanosekunder".

🔹 Funktioner: Läs och skriv prestandarapporter med rättvis och effektiv gas

I de flesta blockkedjenätverk tenderar den slutliga valideringsnoden att lagra samma data. Under en kort tidsperiod finns det dock en viss diskrepans mellan minnet hos olika valideringsnoder och de data som lagras på disken. Som ett resultat kommer användare att förbruka olika mängder gas när de läser och skriver data på grund av att de kommer åt olika platser. Å andra sidan, på grund av olika åtkomstplatser, kan det ta lång tid för användare att läsa och skriva data, och nätverksgasen kan ändras inom detta tidsfönster. Därför är det svårt att avgöra en rättvis och effektiv gas. Om gasen är underskattad kan noderna vara passiva på grund av låga intäkter, vilket kommer att påverka nätverkets effektivitet. Om gasen överskattas kommer användarna att betala onödiga extra avgifter, vilket till och med kan ge en möjlighet till MEV-attacker.

Under IceDB-databasmotorn, varje gång du läser eller skriver data, kan du inte hitta de data du behöver i cacheminnet, så du måste läsa data från minnet respektive SSD, räkna frekvensen för att läsa data från minnet och SSD och returnera en "prestandarapport". "Prestandarapporten" ger en deterministisk grund för att beräkna den gas som användarna behöver, vilket gör nätverksgasen mer rättvis och effektiv, till förmån för nätverkets stablecoin.

💠 Teknik för datakomprimering

Enligt maktteorin om informationsvolym och frekvensfördelning som introducerades i det tekniska dokumentet Somnia kan data komprimeras med hög förstoringshastighet genom att summera informationen enligt sannolikheten för att information inträffar.

Varje datalänk i Somnia ansvarar för en validerare, och valideraren behöver inte skicka hela blocket, utan behöver bara skicka informationsströmmen, och strömkomprimeringen har en högre komprimeringshastighet, så det bidrar till att förbättra nätverkets överföringskapacitet.

Dessutom använder Somnia BLS-signaturer för att förbättra hastigheten för överföring och verifiering av signaturer.

Enligt Sominas multi-stream konsensusalgoritm skickar valideringsnoderna i datakedjan dataskärvor till varandra, och det finns ingen centraliserad ledare som laddar upp och laddar ner data på ett centraliserat sätt, och bandbredden kan fördelas jämnt mellan validerarna. Varje validerare skickar dataskärvor till andra validerare och laddar ner dataskärvor som skickats av andra validerare, så den bandbredd som krävs för varje validerares uppladdning och nedladdning är symmetrisk. Därför kommer Somnia-nätets överföringskapacitet att vara relativt balanserad och stabil.

💠 Skriv i slutet

Även om Web3 är mer avancerat än Web2 på ytan, är det tekniska systemet i Web2 ofta mer komplext och moget. När Web2-utvecklare är involverade i Web3-utvecklingen kan deras tekniska bakgrund tillföra mer innovation till blockkedjevärlden.