Una pregunta preferida sobre qualsevol sistema distribuït d'una persona no tècnica és "Quants tps hi ha a la vostra cadena de blocs?" No obstant això, el nombre donat en resposta acostuma a tenir poc en comú amb el que l'interrogant voldria escoltar. De fet, volia preguntar "s'adaptarà la vostra cadena de blocs als meus requisits empresarials" i aquests requisits no són un número, sinó moltes condicions: aquí hi ha la tolerància a errors de la xarxa, els requisits de finalitat, les mides, la naturalesa de les transaccions i molts altres paràmetres. Per tant, és poc probable que la resposta a la pregunta "quants tps" sigui senzilla i gairebé mai completa. Un sistema distribuït amb desenes o centenars de nodes que realitzen càlculs força complexos pot estar en un gran nombre d'estats diferents relacionats amb l'estat de la xarxa, els continguts de la cadena de blocs, fallades tècniques, problemes econòmics, atacs a la xarxa i moltes altres raons. . Les etapes en què són possibles problemes de rendiment difereixen dels serveis tradicionals, i un servidor de xarxa blockchain és un servei de xarxa que combina la funcionalitat d'una base de dades, servidor web i client torrent, cosa que el fa extremadament complex pel que fa al perfil de càrrega de tots els subsistemes. : processador, memòria, xarxa, emmagatzematge

Succeeix que les xarxes descentralitzades i les cadenes de blocs són un programari força específic i inusual per als desenvolupadors de programari centralitzat. Per tant, m'agradaria destacar aspectes importants del rendiment i la sostenibilitat de les xarxes descentralitzades, els enfocaments per mesurar-les i trobar colls d'ampolla. Analitzarem diversos problemes de rendiment que limiten la velocitat de prestació de serveis als usuaris de blockchain i observarem les característiques característiques d'aquest tipus de programari.

Etapes d'una sol·licitud de servei per part d'un client blockchain

Per parlar honestament de la qualitat de qualsevol servei més o menys complex, cal tenir en compte no només els valors mitjans, sinó també els màxims/mínims, les mitjanes, els percentils. Teòricament, podem parlar de 1000 tps en alguna cadena de blocs, però si 900 transaccions es van completar amb una velocitat enorme i 100 es van "encallar" durant uns segons, el temps mitjà recollit en totes les transaccions no és una mètrica completament justa per a un client. que no vaig poder completar la transacció en uns segons. Els "forats" temporals causats per rondes de consens perduts o divisions de xarxa poden arruïnar molt un servei que ha mostrat un rendiment excel·lent als bancs de proves.

Per identificar aquests colls d'ampolla, és necessari tenir una bona comprensió de les etapes en què una cadena de blocs real pot tenir dificultats per atendre els usuaris. Anem a descriure el cicle de lliurament i processament d'una transacció, així com l'obtenció d'un nou estat de la cadena de blocs, des del qual el client pot comprovar que la seva transacció s'ha processat i comptabilitzat.

la transacció es forma al client
la transacció està signada al client
el client selecciona un dels nodes i li envia la seva transacció
el client es subscriu a les actualitzacions de la base de dades d'estat del node, esperant que apareguin els resultats de la seva transacció
el node distribueix la transacció per la xarxa p2p
diversos o un BP (productor de blocs) processa transaccions acumulades, actualitzant la base de dades estatal
BP forma un nou bloc després de processar el nombre necessari de transaccions
BP distribueix un nou bloc per la xarxa p2p
el bloc nou es lliura al node al qual accedeix el client
node actualitza la base de dades d'estat
el node veu l'actualització respecte al client i li envia una notificació de transacció

Ara fem una ullada més de prop a aquestes etapes i descrivim els possibles problemes de rendiment a cada etapa. A diferència dels sistemes centralitzats, també tindrem en compte l'execució de codi als clients de xarxa. Molt sovint, quan es mesura TPS, el temps de processament de la transacció es recull dels nodes i no del client, això no és del tot just. Al client no li importa la rapidesa amb què el node va processar la seva transacció; el més important per a ell és el moment en què la informació fiable sobre aquesta transacció inclosa a la cadena de blocs està disponible. Aquesta mètrica és essencialment el temps d'execució de la transacció. Això vol dir que diferents clients, fins i tot enviant la mateixa transacció, poden rebre hores completament diferents, que depenen del canal, càrrega i proximitat del node, etc. Per tant, és absolutament necessari mesurar aquest temps als clients, ja que aquest és el paràmetre que cal optimitzar.

Preparació d'una transacció al costat del client

Comencem pels dos primers punts: la transacció està formada i signada pel client. Curiosament, això també pot ser un coll d'ampolla del rendiment de la cadena de blocs des del punt de vista del client. Això és inusual per als serveis centralitzats, que es fan càrrec de tots els càlculs i operacions amb dades, i el client simplement prepara una petició breu que pot sol·licitar una gran quantitat de dades o càlculs, obtenint un resultat ja fet. A les cadenes de blocs, el codi del client es torna cada cop més potent i el nucli de la cadena de blocs es fa cada cop més lleuger i les tasques informàtiques massives solen transferir-se al programari del client. A les cadenes de blocs, hi ha clients que poden preparar una transacció durant força temps (estic parlant de diverses proves de merkle, proves succintes, signatures de llindar i altres operacions complexes al costat del client). Un bon exemple de verificació senzilla en cadena i preparació pesada d'una transacció al client és la prova de pertinença a una llista basada en Merkle-tree, aquí article.

A més, no oblideu que el codi del client no només envia transaccions a la cadena de blocs, sinó que primer consulta l'estat de la cadena de blocs, i aquesta activitat pot afectar la congestió de la xarxa i els nodes de la cadena de blocs. Per tant, quan es prenen mesures, seria raonable emular el comportament del codi del client el més completament possible. Fins i tot si a la vostra cadena de blocs hi ha clients lleugers normals que posen una signatura digital regular a la transacció més senzilla per transferir algun actiu, cada any encara hi ha més càlculs massius sobre el client, els algorismes criptogràfics es fan més forts i aquesta part del processament pot convertir-se en un coll d'ampolla important en el futur. Per tant, aneu amb compte i no us perdeu la situació en què, en una transacció que dura 3.5 segons, es dediquen 2.5 segons a preparar i signar la transacció, i 1.0 segons a enviar-la a la xarxa i esperar una resposta. Per avaluar els riscos d'aquest coll d'ampolla, cal recollir mètriques de les màquines clients, i no només dels nodes de la cadena de blocs.

Enviament d'una transacció i seguiment del seu estat

El següent pas és enviar la transacció al node blockchain seleccionat i rebre l'estat d'acceptació al grup de transaccions. Aquesta etapa és similar a l'accés normal a una base de dades; el node ha d'enregistrar la transacció al grup i començar a distribuir informació sobre ella a través de la xarxa p2p. L'enfocament per avaluar el rendiment aquí és similar a l'avaluació del rendiment dels microserveis tradicionals de l'API web, i les transaccions en si mateixes a les cadenes de blocs es poden actualitzar i canviar-ne l'estat de manera activa. En general, l'actualització de la informació de transaccions en algunes cadenes de blocs es pot produir diverses vegades, per exemple, quan es canvia entre bifurcacions de cadena o quan els BP anuncien la seva intenció d'incloure una transacció en un bloc. Els límits de la mida d'aquest grup i el nombre de transaccions que hi ha poden afectar el rendiment de la cadena de blocs. Si el conjunt de transaccions s'omple fins a la mida màxima possible o no s'adapta a la memòria RAM, el rendiment de la xarxa pot baixar bruscament. Les cadenes de blocs no tenen mitjans centralitzats per protegir-se d'una riuada de missatges no desitjats, i si la cadena de blocs admet transaccions de gran volum i tarifes baixes, això pot provocar que el conjunt de transaccions es desbordi, un altre coll d'ampolla de rendiment potencial.

En les cadenes de blocs, el client envia una transacció a qualsevol node de cadena de blocs que li agradi, el hash de la transacció sol ser conegut pel client abans de l'enviament, per tant només cal aconseguir la connexió i, després de la transmissió, esperar que canviï la cadena de blocs. el seu estat, permetent la seva transacció. Tingueu en compte que mesurant "tps" podeu obtenir resultats completament diferents per a diferents mètodes de connexió a un node de cadena de blocs. Pot ser un HTTP RPC normal o un WebSocket que us permeti implementar el patró "subscriure". En el segon cas, el client rebrà una notificació abans i el node gastarà menys recursos (principalment memòria i trànsit) en respostes sobre l'estat de la transacció. Per tant, a l'hora de mesurar "tps" cal tenir en compte la manera com els clients es connecten als nodes. Per tant, per avaluar els riscos d'aquest coll d'ampolla, la cadena de blocs de referència ha de ser capaç d'emular clients tant amb sol·licituds WebSocket com HTTP RPC, en proporcions corresponents a xarxes reals, així com canviar la naturalesa de les transaccions i la seva mida.

Per avaluar els riscos d'aquest coll d'ampolla, també heu de recollir mètriques de les màquines clients, i no només dels nodes de la cadena de blocs.

Transmissió de transaccions i blocs mitjançant xarxa p2p

A les cadenes de blocs, la xarxa peer-to-peer (p2p) s'utilitza per transferir transaccions i blocs entre participants. Les transaccions s'estenen per tota la xarxa, començant des d'un dels nodes, fins que arriben als productors de blocs iguals, que empaqueten les transaccions en blocs i, utilitzant el mateix p2p, distribueixen nous blocs a tots els nodes de la xarxa. La base de les xarxes p2p més modernes són diverses modificacions del protocol Kademlia. aquí està un bon resum d'aquest protocol, i aquí - un article amb diverses mesures a la xarxa BitTorrent, a partir del qual es pot entendre que aquest tipus de xarxa és més complexa i menys previsible que una xarxa rígidament configurada d'un servei centralitzat. També, aquí article sobre mesurar diverses mètriques interessants per als nodes d'Ethereum.

En resum, cada parell d'aquestes xarxes manté la seva pròpia llista dinàmica d'altres companys de la qual sol·licita blocs d'informació que s'aborden pel contingut. Quan un peer rep una sol·licitud, o bé dóna la informació necessària o passa la sol·licitud al següent peer pseudoaleatori de la llista i, després d'haver rebut una resposta, la passa al sol·licitant i l'emmagatzema a la memòria cau durant un temps. bloc d'informació abans la propera vegada. Així, la informació popular acaba en un gran nombre de memòria cau d'un gran nombre d'iguals, i la informació impopular es substitueix gradualment. Els companys mantenen registres de qui ha transferit quanta informació a qui, i la xarxa intenta estimular els distribuïdors actius augmentant les seves valoracions i proporcionant-los un nivell de servei més alt, desplaçant automàticament els participants inactius de les llistes d'iguals.

Per tant, la transacció ara s'ha de distribuir per la xarxa perquè els productors de blocs puguin veure-la i incloure-la al bloc. El node "distribueix" activament una nova transacció a tothom i escolta la xarxa, esperant un bloc en l'índex del qual apareixerà la transacció requerida per notificar el client que espera. El temps que triga la xarxa a transferir informació sobre noves transaccions i blocs entre si a les xarxes p2p depèn d'un gran nombre de factors: el nombre de nodes honestos que treballen a prop (des del punt de vista de la xarxa), el "calentisme". up” de les memòria cau d'aquests nodes, la mida dels blocs, les transaccions, la naturalesa dels canvis, la geografia de la xarxa, el nombre de nodes i molts altres factors. Les mesures complexes de mètriques de rendiment en aquestes xarxes són una qüestió complexa; és necessari avaluar simultàniament el temps de processament de la sol·licitud tant en clients com en iguals (nodes de cadena de blocs). Els problemes en qualsevol dels mecanismes p2p, el desallotjament de dades incorrectes i la memòria cau, la gestió ineficaç de llistes d'iguals actius i molts altres factors poden provocar retards que afecten l'eficiència de tota la xarxa en el seu conjunt, i aquest coll d'ampolla és el més difícil d'analitzar. , prova i interpretació de resultats.

Processament de blockchain i actualització de bases de dades d'estat

La part més important de la cadena de blocs és l'algoritme de consens, la seva aplicació als nous blocs rebuts de la xarxa i el processament de les transaccions amb l'enregistrament dels resultats a la base de dades estatal. Afegir un bloc nou a la cadena i seleccionar la cadena principal hauria de funcionar tan aviat com sigui possible. No obstant això, a la vida real, "hauria" no vol dir "funciona", i es pot, per exemple, imaginar una situació en què dues llargues cadenes competidores canvien constantment entre elles, canviant les metadades de milers de transaccions del grup a cada commutador. , i revertir constantment la base de dades de l'estat. Aquesta etapa, pel que fa a la definició del coll d'ampolla, és més senzilla que la capa de xarxa p2p, perquè L'execució de la transacció i l'algoritme de consens són estrictament deterministes, i aquí és més fàcil mesurar qualsevol cosa.
El més important és no confondre la degradació aleatòria en el rendiment d'aquesta etapa amb problemes de xarxa: els nodes són més lents a l'hora de lliurar blocs i informació sobre la cadena principal, i per a un client extern pot semblar una xarxa lenta, tot i que el problema rau en un lloc completament diferent.

Per optimitzar el rendiment en aquesta fase, és útil recollir i controlar mètriques dels mateixos nodes, i incloure-hi les relacionades amb l'actualització de la base de dades d'estat: el nombre de blocs processats al node, la seva mida, el nombre de transaccions, el nombre d'interruptors entre bifurcacions de cadena, el nombre de blocs no vàlids, el temps d'operació de la màquina virtual, el temps de confirmació de dades, etc. Això evitarà que els problemes de xarxa es confonguin amb errors en els algorismes de processament en cadena.

Una màquina virtual que processa transaccions pot ser una font útil d'informació que pot optimitzar el funcionament de la cadena de blocs. El nombre d'assignacions de memòria, el nombre d'instruccions de lectura/escriptura i altres mètriques relacionades amb l'eficiència de l'execució del codi del contracte poden proporcionar molta informació útil als desenvolupadors. Al mateix temps, els contractes intel·ligents són programes, és a dir, en teoria poden consumir qualsevol dels recursos: CPU/memòria/xarxa/emmagatzematge, de manera que el processament de transaccions és una etapa força incerta, que, a més, canvia molt en moure's entre versions. i quan es canvien els codis de contracte. Per tant, també es necessiten mètriques relacionades amb el processament de transaccions per optimitzar eficaçment el rendiment de la cadena de blocs.

Recepció per part del client d'una notificació sobre la inclusió d'una transacció a la cadena de blocs

Aquesta és l'etapa final del client blockchain que rep el servei; en comparació amb altres etapes, no hi ha grans costos generals, però val la pena considerar la possibilitat que el client rebi una resposta voluminosa del node (per exemple, un contracte intel·ligent). retornant una matriu de dades). En qualsevol cas, aquest punt és el més important per a qui va fer la pregunta "quants tps hi ha a la teva cadena de blocs?", perquè En aquest moment s'enregistra l'hora de rebre el servei.

En aquest lloc, sempre hi ha un enviament del temps complet que el client va haver de dedicar a l'espera d'una resposta de la cadena de blocs; és aquest cop que l'usuari esperarà la confirmació a la seva aplicació, i és la seva optimització la que és tasca principal dels desenvolupadors.

Conclusió

Com a resultat, podem descriure els tipus d'operacions realitzades a les cadenes de blocs i dividir-les en diverses categories:

transformacions criptogràfiques, construcció de proves
xarxes peer-to-peer, transaccions i replicació de blocs
processament de transaccions, execució de contractes intel·ligents
aplicant canvis a la cadena de blocs a la base de dades estatal, actualitzant dades sobre transaccions i blocs
sol·licituds de només lectura a la base de dades d'estats, l'API del node blockchain, els serveis de subscripció

En general, els requisits tècnics dels nodes de blockchain moderns són extremadament seriosos: CPU ràpides per a la criptografia, una gran quantitat de RAM per emmagatzemar i accedir ràpidament a la base de dades de l'estat, interacció amb la xarxa amb un gran nombre de connexions obertes simultàniament i gran emmagatzematge. Aquests requisits tan elevats i l'abundància de diferents tipus d'operacions condueixen inevitablement al fet que els nodes poden no tenir prou recursos i, aleshores, qualsevol de les etapes comentades anteriorment es pot convertir en un altre coll d'ampolla per al rendiment global de la xarxa.

A l'hora de dissenyar i avaluar el rendiment de les cadenes de blocs, haureu de tenir en compte tots aquests punts. Per fer-ho, cal recollir i analitzar mètriques simultàniament de clients i nodes de xarxa, buscar correlacions entre ells, estimar el temps que es necessita per oferir serveis als clients, tenir en compte tots els recursos principals: cpu/memòria/xarxa/emmagatzematge. , entendre com s'utilitzen i s'influeixen mútuament. Tot això fa que comparar les velocitats de diferents blockchains en forma de "quants TPS" sigui una tasca extremadament ingrata, ja que hi ha un gran nombre de configuracions i estats diferents. En grans sistemes centralitzats, clústers de centenars de servidors, aquests problemes també són complexos i també requereixen la recollida d'un gran nombre de mètriques diferents, però en blockchains, a causa de xarxes p2p, màquines virtuals de processament de contractes, economies internes, el nombre de graus. de llibertat és molt més gran, la qual cosa fa que la prova fins i tot en diversos servidors sigui no indicativa i només mostra valors extremadament aproximats que gairebé no tenen connexió amb la realitat.

Per tant, quan es desenvolupa al nucli de blockchain, per avaluar el rendiment i respondre a la pregunta "ha millorat en comparació amb l'última vegada?", utilitzem un programari bastant complex que orquestra el llançament d'una cadena de blocs amb desenes de nodes i llança automàticament un punt de referència i recull mètriques. ; sense aquesta informació és extremadament difícil depurar protocols que funcionen amb diversos participants.

Per tant, quan rebeu la pregunta "quants TPS hi ha a la vostra cadena de blocs?", oferiu una mica de te al vostre interlocutor i pregunteu-li si està preparat per mirar una dotzena de gràfics i també escolteu les tres caixes de problemes de rendiment de la cadena de blocs i els vostres suggeriments per resolent-los...

Font: www.habr.com

Quants TPS hi ha a la vostra cadena de blocs?