Op 26 maart publiceerde Keone Hon, medeoprichter van Monad, een diepgaand artikel over de prestaties van Rollup op Personal X. In het artikel bespreekt Keone hoe de theoretische TPS-limiet van Rollup kan worden berekend na de Cancun-upgrade, en ook waarom de enkele transactiekosten voor sommige Laag 2 (basis) is na de upgrade nog steeds enkele dollars waard. Daarnaast bespreekt Keone enkele van de uitdagingen waarmee Rollup wordt geconfronteerd. Knelpuntbeperkingen en mogelijke verbeteringen. De laatste tijd zijn er grote zorgen in de markt over knelpunten bij de uitvoering van roll-ups en gasbeperkingen, die zowel Laag 1 als Laag 2 beïnvloeden.
Beschikbaarheid van gegevens (DA)
Met de introductie van de Blob-datastructuur (EIP-4844) in de Cancun-upgrade is de databeschikbaarheid (DA) van Ethereum aanzienlijk verbeterd. Layer2-gegevenssynchronisatietransacties hoeven niet langer op dezelfde markt te plaatsvinden als gewone Layer1-transacties. Momenteel is de capaciteit van Blobs ongeveer drie blobs van 125 kb per blok (12 seconden), wat neerkomt op 31,25 kb per seconde. Aangezien de omvang van een transactie ongeveer 100 bytes bedraagt, betekent dit dat alle gedeelde TPS van Rollup waarschijnlijk rond de 300 liggen.
Er is hier informatie die speciale opmerkingen vereist:
- Ten eerste: als Rollup betere compressietechnologie voor transactiegegevens gebruikt om de omvang van een enkele transactie te verkleinen, kan TPS groeien.
- Ten tweede kan Rollup in theorie, naast het gebruik van Blob om gegevens te synchroniseren, ook calldata blijven gebruiken om gegevens te synchroniseren (dat wil zeggen de oude oplossing vóór de Cancun-upgrade), hoewel dit extra complexiteit met zich meebrengt.
- Ten derde zijn er verschillen in de manier waarop verschillende ZK-rollups de status publiceren (vooral zkSync Era en Starknet), dus voor deze rollups zullen de berekeningsmethoden en resultaten ook anders zijn.
Gaslimiet van rollup
De laatste tijd heeft Base veel aandacht getrokken vanwege de explosie van zijn gastarieven, die zijn gestegen tot een paar dollar voor een gewone transactie op het netwerk. Waarom ging het basisnetwerk pas een tijdje achteruit na de upgrade in Cancun, en is het nu teruggekeerd naar het niveau van vóór de upgrade of zelfs overschreden? Dit komt omdat er een totale gaslimiet geldt voor blokken op Base, die wordt afgedwongen via een parameter in de code.
De gasparameters die momenteel door Base worden gebruikt, zijn dezelfde als Optimism, dat wil zeggen dat er een totale limiet is van 5 miljoen gas per Layer2-blok (2 seconden). Wanneer de vraag (totaal aantal transacties) op het netwerk groter is dan het aanbod (blokruimte), zal de prijsafrekening een on-demand uitvoeringsmechanisme toepassen, wat resulteert in een stijging van de gasvoorraad op het netwerk.
Waarom verhoogt Base deze totale gaslimiet niet? Of met andere woorden: waarom moet Rollup een totale gaslimiet instellen? Naast de hierboven genoemde TPS-bovengrens voor de beschikbaarheid van gegevens zijn er eigenlijk nog twee andere belangrijke redenen, namelijk het knelpunt van de uitvoeringsdoorvoer en het verborgen gevaar van staatsgroei.
Probleem 1: Knelpunt in de uitvoeringscapaciteit
Over het algemeen voert EVM Rollup een EVM-vork van Geth uit, wat betekent dat ze vergelijkbare prestatiekenmerken hebben als de Geth-client. De client van Geth is single-threaded (dat wil zeggen dat hij slechts één taak tegelijk kan verwerken), gebruikt LevelDB/PebbleDB-codering en slaat de status ervan op in eenmerkle Patricia Trie (MPT). Dit is een database voor algemene doeleinden die een andere boomstructuur (LSM-boom) gebruikt als onderliggende laag om gegevens op een solid-state drive (SSD) op te slaan.
Voor Rollup wordt “statustoegang” (waarden lezen uit demerkle trie) en “state update” (bijwerken van hetmerkle probeer aan het einde van elk blok) zijn de duurste schakels in het uitvoeringsproces. Dit komt omdat de kosten van een enkele leesactie vanaf de SSD 40-100 microseconden bedragen, en omdat demerkle Als de datastructuur is ingebed in een andere datastructuur (LSM-boom), vergt dit veel onnodig extra zoekwerk.
Deze koppeling kan worden gezien als het proces van het vinden van een specifiek bestand in een complex bestandssysteem. U moet van de hoofdmap (trie root node) helemaal naar het doelbestand (leaf node) gaan. Bij het zoeken naar elk bestand moet u een specifieke sleutel vinden in de database LevelDB, en binnen LevelDB moet u de daadwerkelijke gegevensopslagbewerking uitvoeren via een andere gegevensstructuur, de LSM-boom genaamd. Dit proces veroorzaakt veel extra zoekopdrachten. stap. Deze extra stappen zorgen ervoor dat het lezen en bijwerken van alle gegevens behoorlijk traag en inefficiënt is.
Bij het ontwerp van Monad hebben we dit probleem opgelost via MonadDb. MonadDb is een aangepaste database die opslag ondersteuntmerkle probeer het rechtstreeks op schijf en vermijd de overhead van LevelDb; ondersteunt asynchrone IO, waardoor meerdere leesbewerkingen parallel kunnen worden verwerkt; het omzeilen van het bestandssysteem.
Bovendien maakt het “optimistische parallelle uitvoeringsmechanisme” van Monad het mogelijk dat meerdere transacties parallel worden uitgevoerd en dat hun status parallel uit MonadDb kan worden gehaald.
Rollup beschikt echter niet over deze optimalisaties en heeft daarom last van een knelpunt in de uitvoeringsdoorvoer. Opgemerkt moet worden dat deErigon/Over client heeft bepaalde optimalisaties voor database-efficiëntie, en sommige Rollup-clients zijn ook gebouwd op basis van deze clients (zoals OP-Reth). Erigon/Reth gebruikt een platte datastructuur, waardoor de querykosten bij het lezen tot op zekere hoogte worden verlaagd; ze ondersteunen echter geen asynchrone lezing of multi-threaded verwerking. Bovendien is demerkle root moet na elk blok opnieuw worden berekend, wat ook een nogal langzaam proces is.
Probleem 2: Verborgen gevaren van staatsgroei
Net als andere blockchains beperkt Rollup hun doorvoer om te voorkomen dat hun actieve status te snel groeit. Een veelgehoord argument in de markt is dat de reden dat de staatsgroeicijfers zorgwekkend zijn, is dat als de staatsgegevens aanzienlijk groeien, de vraag naar apparaten voor solid-state drives (SSD's) ook zal moeten stijgen. Ik denk echter dat dit een beetje onnauwkeurig is, SSD's zijn relatief goedkoop (een hoogwaardige SSD van 2 TB kost ongeveer $ 200), en de volledige staat van Ethereum was "slechts" ongeveer 200 GB in zijn bijna 10-jarige geschiedenis. Vanuit puur opslagperspectief is er nog veel ruimte voor groei.
Het grotere verborgen gevaar is dat naarmate de status blijft groeien, de tijd voor het opvragen van het opgegeven statusfragment langer zal worden. Dit komt omdat de huidigemerkle Patricia Trie zal de “snelkoppeling” gebruiken wanneer aan de voorwaarde “knooppunt heeft slechts één onderliggende knooppunt” wordt voldaan, wat de effectieve diepte van het knooppunt kan verminderen.proberen en versnelt daardoor het zoekproces. Echter, als de status van demerkle Als het steeds voller wordt, zullen er steeds minder “snelkoppelingen” beschikbaar zijn. Samenvattend is het verborgen gevaar van staatsgroei uiteindelijk een kwestie van efficiëntie van de staatstoegang. Daarom is het versnellen van de toegang van staten de sleutel tot het duurzamer maken van de staatsgroei.
Waarom optimaliseert het hardwarewerk niet eenvoudigweg?
Laag 2 bevindt zich momenteel nog in een relatief gecentraliseerde staat, dat wil zeggen dat het netwerk nog steeds afhankelijk is van een enkele sequencer om de status te behouden en blokken te produceren. Je zou je kunnen afvragen: waarom zou je de sorter niet draaien op hardware met een zeer hoog RAM-geheugen (Random Access Memory), zodat alle statussen in het geheugen kunnen worden opgeslagen?
Daar zijn twee redenen voor:
- Ten eerste zal dit het knelpuntprobleem van de databeschikbaarheid van het Ethereum-hoofdnetwerk niet oplossen. Hoewel gebaseerd op de huidige situatie van Base, wordt de stijging van het netwerkgas niet veroorzaakt door onvoldoende databeschikbaarheidsmogelijkheden van het hoofdnetwerk, maar op de lange termijn zal dit uiteindelijk een groot knelpunt worden dat Rollup beperkt.
- Ten tweede is er de kwestie van decentralisatie. Hoewel de sorteerder nog steeds sterk gecentraliseerd is, zijn andere rollen die betrokken zijn bij de werking van het netwerk ook belangrijk. Ze moeten ook knooppunten onafhankelijk kunnen runnen, dezelfde transactiegeschiedenis kunnen afspelen en dezelfde status kunnen behouden.
Ruwe transactiegegevens en statuscommits op Laag1 zijn niet voldoende om de volledige status te ontsluiten. Elke rol die toegang nodig heeft tot de volledige status (zoals een handelaar, beurs of geautomatiseerde handelaar) moet een volledig Layer 2-knooppunt uitvoeren om transacties te verwerken en een actuele kopie van de status te hebben. Rollups zijn nog steeds blockchains, en blockchains zijn interessant omdat ze mondiale coördinatie mogelijk maken via een gedeelde mondiale staat. Voor alle blockchains is krachtige software nodig, en het simpelweg optimaliseren van hardware is niet voldoende.
Gemeenschapsinteractie
Nadat Keone dit artikel had geplaatst, communiceerden sleutelfunctionarissen van meerdere hoofdlaag 2-projecten onder de post.
Alex Gluchowski, mede-oprichter van zkSync, vroeg Monad hoe het in dit opzicht anders is met betrekking tot de inhoud van het artikel dat “de merkle-wortel na elk blok opnieuw moet worden berekend”. Het antwoord van Keone was dat er een geoptimaliseerd algoritme zou zijn voor het berekenen van de merkle-wortel na elk blok.
Jesse Pollak, de persoon die de leiding had over de basis, gebruikte dit ook om uit te leggen waarom de gaskosten van de basis na de upgrade in Cancun toenamen in plaats van daalden. Hij zei dat EIP-4844 de DA-kosten op Layer1-niveau aanzienlijk heeft verlaagd. De gaskosten hadden moeten worden verlaagd, maar als gevolg van netwerktransactiebehoeften zijn deze meer dan vijf keer zo hoog geworden en geldt er een limiet van 250 gas/s voor blokken op het basisnetwerk. De vraag overstijgt het aanbod, waardoor de gasvergoeding stijgt.
Officiële website:
Website: https://www.bitrue.com/
Aanmelden: https://www.bitrue.com/user/register
Disclaimer: de geuite meningen behoren uitsluitend toe aan de auteur en weerspiegelen niet de mening van dit platform. Dit platform en zijn dochterondernemingen wijzen elke verantwoordelijkheid af voor de juistheid of geschiktheid van de verstrekte informatie. Het is uitsluitend bedoeld voor informatieve doeleinden en niet bedoeld als financieel of beleggingsadvies.