Een favoriete vraag over elk gedistribueerd systeem van een niet-technisch persoon is: “Hoeveel tps staan ​​er op uw blockchain?” Het aantal dat als antwoord wordt gegeven, heeft echter meestal weinig gemeen met wat de vraagsteller graag zou willen horen. In feite wilde hij vragen “zal uw blockchain passen bij mijn bedrijfsvereisten”, en deze vereisten zijn niet één getal, maar vele voorwaarden – hier zijn netwerkfouttolerantie, finaliteitsvereisten, omvang, aard van transacties en vele andere parameters. Het antwoord op de vraag “hoeveel tps” is dus waarschijnlijk niet eenvoudig en bijna nooit volledig. Een gedistribueerd systeem met tientallen of honderden knooppunten die vrij complexe berekeningen uitvoeren, kan zich in een groot aantal verschillende toestanden bevinden, gerelateerd aan de toestand van het netwerk, de inhoud van de blockchain, technische storingen, economische problemen, aanvallen op het netwerk en vele andere redenen. . De stadia waarin prestatieproblemen mogelijk zijn, verschillen van traditionele diensten, en een blockchain-netwerkserver is een netwerkdienst die de functionaliteit van een database, webserver en torrent-client combineert, wat hem extreem complex maakt in termen van het belastingsprofiel op alle subsystemen. : processor, geheugen, netwerk, opslag

Het gebeurt zo dat gedecentraliseerde netwerken en blockchains vrij specifieke en ongebruikelijke software zijn voor gecentraliseerde softwareontwikkelaars. Daarom zou ik belangrijke aspecten van de prestaties en duurzaamheid van gedecentraliseerde netwerken willen benadrukken, evenals de benaderingen om deze te meten en knelpunten te vinden. We zullen kijken naar verschillende prestatieproblemen die de snelheid van het leveren van diensten aan blockchain-gebruikers beperken en de kenmerken van dit soort software noteren.

Fasen van een serviceverzoek door een blockchain-client

Om eerlijk te kunnen spreken over de kwaliteit van een min of meer complexe dienst, moet je niet alleen rekening houden met gemiddelde waarden, maar ook met maximum/minimum, medianen en percentielen. Theoretisch kunnen we in een bepaalde blockchain over 1000 tps praten, maar als 900 transacties met een enorme snelheid zouden worden voltooid en 100 een paar seconden ‘vast zouden zitten’, dan is de gemiddelde tijd die over alle transacties wordt verzameld niet helemaal eerlijk voor een klant. met wie ik de transactie niet binnen een paar seconden kon voltooien. Tijdelijke ‘gaten’ veroorzaakt door gemiste consensusrondes of netwerksplitsingen kunnen een dienst die uitstekende prestaties heeft laten zien op testbanken ernstig ruïneren.

Om dergelijke knelpunten te identificeren, is het noodzakelijk om goed inzicht te hebben in de stadia waarin een echte blockchain moeite kan hebben om gebruikers te bedienen. Laten we de cyclus beschrijven van het leveren en verwerken van een transactie, evenals het verkrijgen van een nieuwe staat van de blockchain, van waaruit de klant kan verifiëren dat zijn transactie is verwerkt en verantwoord.

1. de transactie wordt gevormd op de cliënt
2. de transactie wordt ondertekend op de klant
3. de klant selecteert een van de knooppunten en stuurt zijn transactie ernaartoe
4. de klant abonneert zich op updates van de statusdatabase van het knooppunt, in afwachting van het verschijnen van de resultaten van zijn transactie
5. het knooppunt verdeelt de transactie over het p2p-netwerk
6. meerdere of één BP (blokproducent) verwerkt geaccumuleerde transacties en werkt de statusdatabase bij
7. BP vormt een nieuw blok nadat het vereiste aantal transacties is verwerkt
8. BP distribueert een nieuw blok over het p2p-netwerk
9. het nieuwe blok wordt afgeleverd bij het knooppunt waartoe de client toegang heeft
10. knooppunt werkt de statusdatabase bij
11. het knooppunt ziet de update over de klant en stuurt hem een ​​transactiemelding

Laten we nu deze fasen eens nader bekijken en de potentiële prestatieproblemen in elke fase beschrijven. In tegenstelling tot gecentraliseerde systemen zullen we ook de uitvoering van code op netwerkclients overwegen. Bij het meten van TPS wordt heel vaak de transactieverwerkingstijd verzameld van de knooppunten, en niet van de klant - dit is niet helemaal eerlijk. Het maakt de klant niet uit hoe snel het knooppunt zijn transactie verwerkt; het belangrijkste voor hem is het moment waarop betrouwbare informatie over deze transactie, opgenomen in de blockchain, voor hem beschikbaar komt. Het is deze maatstaf die in wezen de uitvoeringstijd van de transactie weergeeft. Dit betekent dat verschillende clients, zelfs als ze dezelfde transactie verzenden, totaal verschillende tijden kunnen ontvangen, die afhankelijk zijn van het kanaal, de belasting en de nabijheid van het knooppunt, enz. Het is dus absoluut noodzakelijk om deze tijd bij klanten te meten, aangezien dit de parameter is die geoptimaliseerd moet worden.

Het voorbereiden van een transactie aan de klantzijde

Laten we beginnen met de eerste twee punten: de transactie wordt gevormd en ondertekend door de klant. Vreemd genoeg kan dit vanuit het oogpunt van de klant ook een knelpunt zijn voor de blockchain-prestaties. Dit is ongebruikelijk voor gecentraliseerde diensten, die alle berekeningen en bewerkingen met gegevens overnemen, en de klant bereidt eenvoudigweg een kort verzoek voor dat een grote hoeveelheid gegevens of berekeningen kan opvragen, waardoor een kant-en-klaar resultaat wordt verkregen. In blockchains wordt de clientcode steeds krachtiger en wordt de blockchain-kern steeds lichter, en worden enorme computertaken meestal overgedragen naar de clientsoftware. In blockchains zijn er klanten die één transactie een behoorlijk lange tijd kunnen voorbereiden (ik heb het over verschillende merkle-bewijzen, beknopte bewijzen, drempelhandtekeningen en andere complexe operaties aan de kant van de klant). Een goed voorbeeld van eenvoudige verificatie in de keten en zware voorbereiding van een transactie bij de klant is een bewijs van lidmaatschap van een lijst gebaseerd op Merkle-tree, hier artikel.

Vergeet ook niet dat de clientcode niet eenvoudigweg transacties naar de blockchain verzendt, maar eerst de status van de blockchain opvraagt ​​- en deze activiteit kan de congestie van het netwerk en de blockchain-knooppunten beïnvloeden. Bij het uitvoeren van metingen zou het dus redelijk zijn om het gedrag van de clientcode zo volledig mogelijk te emuleren. Zelfs als er in uw blockchain gewone lichte klanten zijn die een gewone digitale handtekening zetten op de eenvoudigste transactie om activa over te dragen, zijn er elk jaar nog steeds grotere berekeningen op de klant, worden crypto-algoritmen sterker, en dit deel van de verwerking kan toekomst een belangrijk knelpunt worden. Wees daarom voorzichtig en mis de situatie niet waarin bij een transactie die 3.5 seconden duurt, 2.5 seconden worden besteed aan het voorbereiden en ondertekenen van de transactie, en 1.0 seconden aan het verzenden ervan naar het netwerk en wachten op een antwoord. Om de risico's van dit knelpunt te beoordelen, moet u statistieken verzamelen van clientmachines, en niet alleen van blockchain-knooppunten.

Een transactie verzenden en de status ervan controleren

De volgende stap is het verzenden van de transactie naar het geselecteerde blockchain-knooppunt en het ontvangen van de status van acceptatie in de transactiepool. Deze fase is vergelijkbaar met een reguliere databasetoegang; het knooppunt moet de transactie in de pool registreren en beginnen met het verspreiden van informatie erover via het p2p-netwerk. De aanpak voor het beoordelen van de prestaties is hier vergelijkbaar met het beoordelen van de prestaties van traditionele Web API-microservices, en de transacties zelf in blockchains kunnen worden bijgewerkt en hun status actief wijzigen. Over het algemeen kan het bijwerken van transactie-informatie op sommige blockchains meerdere keren plaatsvinden, bijvoorbeeld bij het wisselen tussen chain-forks of wanneer BP’s hun voornemen aankondigen om een ​​transactie in een blok op te nemen. Beperkingen op de grootte van deze pool en het aantal transacties daarin kunnen de prestaties van de blockchain beïnvloeden. Als de transactiepool zo groot mogelijk gevuld is, of niet in het RAM-geheugen past, kunnen de netwerkprestaties sterk afnemen. Blockchains beschikken niet over een gecentraliseerd middel om bescherming te bieden tegen een stortvloed aan ongewenste berichten, en als de blockchain grootschalige transacties en lage kosten ondersteunt, kan dit ertoe leiden dat de transactiepool overstroomt – nog een potentieel knelpunt in de prestaties.

Bij blockchains stuurt de klant een transactie naar elk blockchain-knooppunt dat hij leuk vindt. De hash van de transactie is meestal bekend bij de klant voordat deze wordt verzonden, dus het enige wat hij hoeft te doen is de verbinding tot stand te brengen en, na verzending, te wachten tot de blockchain verandert. de staat ervan, waardoor zijn transactie mogelijk wordt. Houd er rekening mee dat u door het meten van “tps” totaal verschillende resultaten kunt krijgen voor verschillende methoden om verbinding te maken met een blockchain-knooppunt. Dit kan een reguliere HTTP RPC zijn of een WebSocket waarmee u het ‘subscribe’-patroon kunt implementeren. In het tweede geval ontvangt de client eerder een melding en zal het knooppunt minder middelen (voornamelijk geheugen en verkeer) besteden aan antwoorden over de transactiestatus. Bij het meten van “tps” is het dus noodzakelijk om rekening te houden met de manier waarop clients verbinding maken met knooppunten. Om de risico’s van dit knelpunt te beoordelen, moet de benchmark-blockchain daarom in staat zijn om clients te emuleren met zowel WebSocket- als HTTP RPC-verzoeken, in verhoudingen die overeenkomen met echte netwerken, en de aard van transacties en hun omvang kunnen veranderen.

Om de risico's van dit knelpunt te beoordelen, moet u ook statistieken verzamelen van clientmachines, en niet alleen van blockchain-knooppunten.

Verzending van transacties en blokken via p2p-netwerk

In blockchains wordt peer-to-peer (p2p) netwerken gebruikt om transacties en blokken tussen deelnemers over te dragen. Transacties verspreiden zich over het netwerk, beginnend bij een van de knooppunten, totdat ze peer-blokproducenten bereiken, die transacties in blokken verpakken en, met behulp van dezelfde p2p, nieuwe blokken naar alle netwerkknooppunten distribueren. De basis van de meeste moderne p2p-netwerken zijn verschillende aanpassingen aan het Kademlia-protocol. Hier een goede samenvatting van dit protocol, en hier - een artikel met verschillende metingen in het BitTorrent-netwerk, waaruit blijkt dat dit type netwerk complexer en minder voorspelbaar is dan een rigide geconfigureerd netwerk van een gecentraliseerde dienst. Ook, hier artikel over het meten van verschillende interessante statistieken voor Ethereum-knooppunten.

Kortom, elke peer in dergelijke netwerken onderhoudt zijn eigen dynamische lijst van andere peers waarvan hij informatieblokken opvraagt ​​die door de inhoud worden geadresseerd. Wanneer een peer een verzoek ontvangt, geeft hij de benodigde informatie of geeft hij het verzoek door aan de volgende pseudo-willekeurige peer uit de lijst, en nadat hij een antwoord heeft ontvangen, geeft hij dit door aan de aanvrager en slaat het een tijdje in de cache op, waarbij hij dit geeft blok met informatie eerder de volgende keer. Populaire informatie komt dus terecht in een groot aantal caches van een groot aantal peers, en impopulaire informatie wordt geleidelijk vervangen. Peers houden bij wie hoeveel informatie aan wie heeft doorgegeven, en het netwerk probeert actieve distributeurs te stimuleren door hun beoordelingen te verhogen en hen een hoger serviceniveau te bieden, waardoor inactieve deelnemers automatisch van de peerlijsten worden verdrongen.

De transactie moet nu dus over het netwerk worden gedistribueerd, zodat blokproducenten deze kunnen zien en in het blok kunnen opnemen. Het knooppunt 'distribueert' actief een nieuwe transactie naar iedereen en luistert naar het netwerk, wachtend op een blok in de index waarvan de vereiste transactie zal verschijnen om de wachtende klant op de hoogte te stellen. De tijd die het netwerk nodig heeft om informatie over nieuwe transacties en blokken naar elkaar over te dragen in p2p-netwerken hangt van een zeer groot aantal factoren af: het aantal eerlijke knooppunten dat in de buurt werkt (vanuit netwerkoogpunt), de “warme” up” van de caches van deze knooppunten, de grootte van blokken, transacties, de aard van de veranderingen, netwerkgeografie, aantal knooppunten en vele andere factoren. Complexe metingen van prestatiestatistieken in dergelijke netwerken zijn een complexe zaak; het is noodzakelijk om tegelijkertijd de verwerkingstijd van verzoeken op zowel clients als peers (blockchain-knooppunten) te evalueren. Problemen in een van de p2p-mechanismen, onjuiste gegevensverwijdering en caching, ineffectief beheer van lijsten met actieve peers en vele andere factoren kunnen vertragingen veroorzaken die de efficiëntie van het hele netwerk als geheel beïnvloeden, en dit knelpunt is het moeilijkst te analyseren , testen en interpreteren van resultaten.

Blockchainverwerking en bijwerken van de statusdatabase

Het belangrijkste onderdeel van de blockchain is het consensusalgoritme, de toepassing ervan op nieuwe blokken die van het netwerk worden ontvangen en de verwerking van transacties met registratie van de resultaten in de staatsdatabase. Het toevoegen van een nieuw blok aan de keten en het selecteren van de hoofdketen zou zo snel mogelijk moeten werken. In het echte leven betekent ‘zou moeten’ echter niet ‘werken’, en men kan zich bijvoorbeeld een situatie voorstellen waarin twee lange concurrerende ketens voortdurend tussen elkaar schakelen, waarbij bij elke overstap de metagegevens van duizenden transacties in de pool veranderen. , en het voortdurend terugdraaien van de statusdatabase. Deze fase is, in termen van het definiëren van het knelpunt, eenvoudiger dan de p2p-netwerklaag, omdat transactie-uitvoering en consensusalgoritme zijn strikt deterministisch, en het is gemakkelijker om hier iets te meten.
Het belangrijkste is om willekeurige achteruitgang in de prestaties van deze fase niet te verwarren met netwerkproblemen: knooppunten zijn langzamer in het leveren van blokken en informatie over de hoofdketen, en voor een externe client kan dit lijken op een langzaam netwerk, hoewel het probleem ligt in een heel andere plek.

Om de prestaties in dit stadium te optimaliseren, is het nuttig om statistieken van de knooppunten zelf te verzamelen en te monitoren, en daarin gegevens op te nemen die verband houden met het bijwerken van de statusdatabase: het aantal blokken dat op het knooppunt wordt verwerkt, hun grootte, het aantal transacties, het aantal schakelaars tussen ketenvorken, het aantal ongeldige blokken, de bedrijfstijd van de virtuele machine, de tijd voor het vastleggen van gegevens, enz. Dit voorkomt dat netwerkproblemen worden verward met fouten in ketenverwerkingsalgoritmen.

Een virtuele machine die transacties verwerkt, kan een nuttige informatiebron zijn die de werking van de blockchain kan optimaliseren. Het aantal geheugentoewijzingen, het aantal lees-/schrijfinstructies en andere statistieken met betrekking tot de efficiëntie van de uitvoering van contractcode kunnen ontwikkelaars veel nuttige informatie opleveren. Tegelijkertijd zijn slimme contracten programma's, wat betekent dat ze in theorie alle bronnen kunnen verbruiken: cpu/geheugen/netwerk/opslag, dus transactieverwerking is een nogal onzekere fase, die bovendien sterk verandert bij het wisselen tussen versies en bij het wijzigen van contractcodes. Daarom zijn er ook statistieken met betrekking tot transactieverwerking nodig om de blockchain-prestaties effectief te optimaliseren.

Ontvangst door de klant van een melding over het opnemen van een transactie in de blockchain

Dit is de laatste fase waarin de blockchain-client de dienst ontvangt; vergeleken met andere fasen zijn er geen grote overheadkosten, maar het is toch de moeite waard om de mogelijkheid te overwegen dat de klant een omvangrijk antwoord van het knooppunt ontvangt (bijvoorbeeld een slim contract het retourneren van een array met gegevens). Dit punt is in ieder geval het belangrijkste voor degene die de vraag stelde “hoeveel tps zitten er in jouw blockchain?”, omdat Op dit moment wordt het tijdstip van ontvangst van de dienst geregistreerd.

Op deze plaats wordt altijd de volledige tijd verzonden die de klant heeft moeten besteden aan het wachten op een antwoord van de blockchain; het is deze keer dat de gebruiker zal wachten op bevestiging in zijn applicatie, en het is de optimalisatie ervan die de sleutel is hoofdtaak van de ontwikkelaars.

Conclusie

Als gevolg hiervan kunnen we de soorten bewerkingen die op blockchains worden uitgevoerd beschrijven en deze in verschillende categorieën verdelen:

1. cryptografische transformaties, bewijsconstructie
2. peer-to-peer netwerken, transactie- en blokreplicatie
3. transactieverwerking, uitvoering van slimme contracten
4. het toepassen van wijzigingen in de blockchain op de staatsdatabase, het bijwerken van gegevens over transacties en blokken
5. alleen-lezen verzoeken aan staatsdatabase, blockchain-knooppunt-API, abonnementsdiensten

Over het algemeen zijn de technische vereisten voor moderne blockchain-knooppunten buitengewoon ernstig: snelle CPU's voor cryptografie, een grote hoeveelheid RAM voor het opslaan en snel toegang krijgen tot de statusdatabase, netwerkinteractie met behulp van een groot aantal gelijktijdig open verbindingen, en grote opslag. Dergelijke hoge eisen en de overvloed aan verschillende soorten bewerkingen leiden onvermijdelijk tot het feit dat knooppunten mogelijk niet over voldoende middelen beschikken, en dat elk van de hierboven besproken fasen een nieuw knelpunt kan worden voor de algehele netwerkprestaties.

Bij het ontwerpen en evalueren van de prestaties van blockchains zul je met al deze punten rekening moeten houden. Om dit te doen, moet u tegelijkertijd statistieken van clients en netwerkknooppunten verzamelen en analyseren, correlaties daartussen zoeken, de tijd schatten die nodig is om services aan clients te leveren, rekening houden met alle belangrijke bronnen: cpu/geheugen/netwerk/opslag , begrijpen hoe ze worden gebruikt en elkaar beïnvloeden. Dit alles maakt het vergelijken van de snelheden van verschillende blockchains in de vorm van “hoeveel TPS” een uiterst ondankbare taak, aangezien er een groot aantal verschillende configuraties en toestanden zijn. In grote gecentraliseerde systemen, clusters van honderden servers, zijn deze problemen ook complex en vereisen ze ook het verzamelen van een groot aantal verschillende statistieken, maar in blockchains zijn, als gevolg van p2p-netwerken, verwerkingscontracten voor virtuele machines, interne economieën, het aantal graden van vrijheid is veel groter, waardoor de test zelfs op meerdere servers is, niet indicatief is en slechts uiterst benaderende waarden laat zien die vrijwel geen verband houden met de werkelijkheid.

Daarom gebruiken we bij het ontwikkelen in de blockchain-kern, om de prestaties te evalueren en de vraag te beantwoorden “is het verbeterd vergeleken met de vorige keer?”, vrij complexe software die de lancering van een blockchain met tientallen knooppunten orkestreert en automatisch een benchmark lanceert en statistieken verzamelt. Zonder deze informatie is het uiterst moeilijk om protocollen te debuggen die met meerdere deelnemers werken.

Dus als u de vraag krijgt “hoeveel TPS zitten er in uw blockchain?”, bied uw gesprekspartner dan wat thee aan en vraag of hij bereid is om naar een tiental grafieken te kijken en ook te luisteren naar alle drie de vakjes met blockchain-prestatieproblemen en uw suggesties voor ze oplossen...

Bron: www.habr.com