🚨SonicDB en revolusjon innen blokkjedestatstilgang? 💡Null leseforsterkning ⚡️6 ganger raskere enn Geth 💼Direkte binær butikk Men hvordan fungerer det egentlig? 👇👇👇 Leseforsterkninger har alltid vært flaskehalsen for effektivitet. ➡️Les forsterkningsproblem - flaskehalsen ➡️Hvordan SonicDB fungerer ➡️Forskjell fra Geth ➡️Prestasjon Sonic setter nye standarder for blokkjededataytelse. Les forsterkningsproblem: (vanlig blokkjede) ➡️Den skjulte flaskehalsen i alle blokkjededatabaser Vanlige blockhain-databaser (LevelDB/RocksDB) legger en Merkle-Patricia Trie (MPT) på toppen av de merkle-trebaserte nøkkelverdilagrene. ➡️Dette skaper et leseforsterkningsproblem, MPT krever multilogaritmiske oppslag, noe som resulterer i dårlig tilgangstid. ➡️For terabyte med data bremser dette oppslag i datastrukturen Slik fungerer SonicDB: ➡️SonicDB lagrer kontoer, saldoer, nonces og alle smartkontraktsdata i binære filer, og omgår nøkkelverdilagringen. ➡️Indeksering av binære data direkte til MPT-node med konstant tid, reduserer dette kompleksiteten ➡️Dobbel struktur 1) I minnet MPT (blå) for rask hash-beregning 2) Binære filer på disk (grønn) for direkte nodeindeksering Noder forblir faste, plass samles for gjenbruk og nye noder legges til filender, slik at man unngår kostbar omorganisering. Forskjell fra Geth: ➡️LevelDB er svært begrenset i leseforsterkning (flaskehals) ➡️SonicDB eliminerer overhead for nøkkelverdilagring ved å bygge MPT på binære filer, noe som resulterer i konstant nodetilgang. ➡️SonicDB unngår unødvendig støtte for rekkeviddespørringer, optimalisert for blokkjedespesifikke behov Prestasjon: ➡️SonicDB behandlet 11M Sonic-hovednettblokker ved 1,300 MGas/s ➡️6,2 ganger raskere enn Geth ➡️Etter hvert som SonicDB vokser, vil det effektive systemet skinne, noe som resulterer i høyere gjennomstrømning. Sonic gjorde en blokkjedespesifikk oppgradering, som øker ytelsen og gir mer rom for lagringsoptimalisering. @DrSonicScholz innoverer blokkjede-DB-er.