Hola, aghju travagliatu in a squadra di u prughjettu DRD KP (registru di dati distribuitu per u seguimentu di u ciculu di vita di i set di roti). Quì mi piacerebbe sparte l'esperienza di a nostra squadra in u sviluppu di una blockchain d'impresa per stu prughjettu sottu à e limitazioni di a tecnulugia. Per a maiò parte, parleraghju di Hyperledger Fabric, ma l'approcciu descrittu quì pò esse estrapolatu à qualsiasi blockchain permessu. L'ultimu scopu di a nostra ricerca hè di priparà suluzioni di blockchain di l'impresa in tale manera chì u pruduttu finali hè piacevule à utilizà è micca troppu difficiule di mantene.
Ùn ci saranu scuperte, suluzioni inespettate, è ùn ci saranu micca sviluppi unichi quì (perchè ùn l'aghju micca). Vogliu solu sparte a mo spirienza umile, dimustrà chì "era pussibule" è, forsi, leghje nantu à l'esperienza di qualcunu altru per piglià decisioni boni è micca cusì boni in i cumenti.
Prublemu: i blockchains ùn sò ancu scalabili
Oghje, i sforzi di parechji sviluppatori sò destinati à fà a blockchain una tecnulugia veramente còmuda, è micca una bomba di tempu in una bella wrapper. Canali statali, rollup ottimista, plasma è sharding ponu diventà cumune. Qualchì ghjornu. O forse TON rinviarà u lanciu per sei mesi, è u prossimu Gruppu di Plasma cesserà di esiste. Pudemu crede in un altru roadmap è leghje libri bianchi brillanti di notte, ma quì è avà avemu bisognu di fà qualcosa cù ciò chì avemu. Fate a merda.
U compitu assignatu à a nostra squadra in u prughjettu attuale s'assumiglia à questu in termini generale: ci sò assai sugetti, righjunghjendu parechji milla, chì ùn volenu micca custruisce relazioni nantu à a fiducia; hè necessariu di custruisce nantu à DLT una suluzione chì hà da travaglià nantu à i PC ordinali senza esigenze di prestazione speciale è furnisce una sperienza d'utilizatore micca peghju di qualsiasi sistema di cuntabilità centralizata. A tecnulugia daretu à a suluzione deve minimizzà a pussibilità di manipulazione di dati maliziusi - per quessa chì u blockchain hè quì.
Slogans da whitepapers è media prumettenu chì u prossimu sviluppu permetterà milioni di transazzione per seconda. Chì ghjè veramente?
Mainnet Ethereum hè attualmente in esecuzione à ~ 30 tps. Per via di questu solu, hè difficiule di percive cum'è una blockchain chì hè in ogni modu adattatu per i bisogni corporativi. Trà e soluzioni permesse, sò cunnisciuti benchmarks chì mostranu 2000 tps () o 3000 tps (, Ci hè un pocu menu in a publicazione, ma tenite in mente chì u benchmark hè statu realizatu nantu à u vechju mutore di cunsensu). Era , chì ùn hà micca datu u peghju risultati, 20000 tps, ma finu à quì sò solu studii accademichi chì aspettanu a so implementazione stabile. Hè improbabile chì una corporazione chì pò permette di mantene un dipartimentu di sviluppatori di blockchain si mette cun tali indicatori. Ma u prublema ùn hè micca solu in u throughput, ci hè ancu a latenza.
Latenza
U ritardu da u mumentu chì una transazzione hè iniziata à a so appruvazioni finali da u sistema dipende micca solu da a rapidità di u messagiu chì passa per tutte e tappe di validazione è ordine, ma ancu di i paràmetri di furmazione di blocchi. Ancu s'è a nostra blockchain ci permette di impegnà à 1000000 tps, ma ci vole 10 minuti per furmà un bloccu 488MB, serà più faciule per noi?
Fighjemu un ochju più vicinu à u ciculu di vita di una transazzione in Hyperledger Fabric per capisce ciò chì piglia u tempu è cumu si tratta di i paràmetri di furmazione di blocchi.
presa da quì:
(1) U cliente forma una transazzione, u manda à i pari di l'endorsing, l'ultimi simulanu a transazzione (applicà i cambiamenti fatti da u chaincode à u statu attuale, ma ùn si impegnanu micca à u ledger) è riceve RWSet - nomi chjave, versioni è valori pigliati da a cullezzione in CouchDB, (2) l'endorsers mandanu u RWSet firmatu torna à u cliente, (3) u cliente o verifica per e firme di tutti i pari richiesti (endorsers), è poi manda a transazzione à u serviziu di ordine. , o l'invià senza verificazione (a verificazione serà sempre più tardi), u serviziu di cumanda forma un bloccu è (4) rinvia à tutti i pari, micca solu endorsers; i pari cuntrollanu chì e versioni di e chjavi in u set di lettura currispondenu à e versioni in a basa di dati, e firme di tutti l'endorsers, è infine commit the block.
Ma questu hè micca tuttu. Dopu à e parolle "order forms a block" hè ammucciatu micca solu l'urdinamentu di e transazzione, ma ancu 3 richieste di rete consecutivi da u capu à i seguitori è torna: u capu aghjunghje un missaghju à u logu, manda à i seguitori, l'ultimi aghjunghje à u so logu, manda a cunferma di a replicazione riescita à u capu, u capu cummette u missaghju, manda a cunferma di cummissione à i seguitori, i seguitori commit. A più chjuca hè a dimensione è u tempu di furmazione di blocchi, u più spessu u serviziu d'ordine duverà stabilisce cunsensu. Hyperledger Fabric hà dui paràmetri di furmazione di bloccu: BatchTimeout - tempu di furmazione di bloccu è BatchSize - dimensione di bloccu (u nùmeru di transazzione è a dimensione di u bloccu stessu in byte). Appena unu di i paràmetri righjunghji u limitu, un novu blocu hè liberatu. Quantu più nodi d'ordine, più longu questu duverà. Dunque, avete bisognu di cresce BatchTimeout è BatchSize. Ma siccomu RWSets sò versionati, u più grande u bloccu chì facemu, più a probabilità di cunflitti MVCC. Inoltre, cum'è BatchTimeout aumenta, l'UX si degrada catastroficamente. U schema seguente per risolve questi prublemi mi pare raghjone è ovvi.
Cumu evità di aspittà per a finalizazione di u bloccu è ùn perde micca a traccia di u statutu di a transazzione
U più longu u tempu di furmazione è a dimensione di u bloccu, u più altu u throughput di u blockchain. Unu ùn seguita micca direttamente da l'altru, ma deve esse ricurdatu chì stabilisce u cunsensu in RAFT richiede trè richieste di rete da u capu à i seguitori è torna. Quantu più nodi di ordine, u più longu sarà. A più chjuca hè a dimensione è u tempu di furmazione di blocchi, più tali interazzioni. Cumu aumentà u tempu di furmazione è a dimensione di bloccu senza aumentà u tempu di risposta di u sistema per l'utilizatore finale?
Prima, avete bisognu di risolve in qualchì modu i cunflitti MVCC causati da una grande dimensione di bloccu, chì ponu include diverse RWSets cù a listessa versione. Ovviamente, da u latu di u cliente (in relazione à a reta di blockchain, questu pò esse un backend, è vogliu dì) Gestione di cunflittu MVCC, chì pò esse sia un serviziu separatu o un decoratore regulare nantu à una chjama di iniziazione di transazzione cù a logica di retry.
Riprova pò esse implementatu cù una strategia esponenziale, ma allora a latenza si degraderà in modu esponenziale. Allora duvete aduprà sia un retry randomized in certi picculi limiti, o un constante. Cù un ochju nantu à pussibuli collisioni in a prima opzione.
U prossimu passu hè di fà l'interazzione di u cliente cù u sistema asincrona in modu chì ùn aspittà micca 15, 30, o 10000000 seconde, chì avemu stabilitu cum'è BatchTimeout. Ma à u stessu tempu, hè necessariu di mantene a capacità di assicurà chì i cambiamenti iniziati da a transazzione sò arregistrati / micca arregistrati in u blockchain.
Una basa di dati pò esse usata per almacenà u statutu di e transazzione. L'opzione più faciule hè CouchDB per via di a so facilità d'utilizazione: a basa di dati hà una UI fora di a scatula, una API REST, è pudete facilmente cunfigurà a replicazione è u sharding per questu. Pudete solu creà una cullizzioni separata in a stessa istanza CouchDB chì Fabric usa per almacenà u so statu mundiale. Avemu bisognu di almacenà sti tipi di documenti.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Stu documentu hè scrittu à a basa di dati prima chì a transazzione hè mandata à i pari, l'identità di l'entità hè tornata à l'utilizatore (u stessu ID hè utilizatu cum'è chjave) s'ellu hè una operazione di creazione, è dopu i campi Status, TxID è Errore sò. aghjurnatu cum'è l'infurmazioni pertinenti sò ricevute da i pari.
In questu schema, l'utilizatore ùn aspittà micca chì u bloccu si forma infine, fighjendu u spinning wheel nantu à u screnu per 10 seconde, riceve una risposta immediata da u sistema è cuntinueghja à travaglià.
Avemu sceltu BoltDB per almacenà i stati di transazzione perchè avemu bisognu di salvà a memoria è ùn vulemu micca perde u tempu in l'interazzione di a rete cù un servitore di basa di dati stand-alone, soprattuttu quandu sta interazzione si faci cù u protocolu di testu chjaru. A propositu, sè vo avete aduprà CouchDB per implementà u schema descrittu sopra o solu per almacenà u statu mundiale, in ogni casu, hè sensu per ottimisà a manera chì i dati sò almacenati in CouchDB. Per automaticamente, in CouchDB, a dimensione di i nodi di b-tree hè 1279 bytes, chì hè assai menu di u settore di u settore nantu à u discu, chì significa chì a lettura è u reequilibriu di l'arbulu necessitanu più accessi fisici di discu. U tagliu ottimali risponde à u standard è hè 4 kilobyte. Per ottimisazione, avemu bisognu di stabilisce u paràmetru btree_chunk_size uguale à 4096 in u schedariu di cunfigurazione CouchDB. Per BoltDB tali intervenzione manuale .
Back pressure: strategia buffer
Ma ci ponu esse assai missaghji. Più di ciò chì u sistema pò gestisce, sparte risorse cù una decina di altri servizii oltri à quelli mostrati in u diagramma - è tuttu questu duverebbe travaglià perfettamente ancu in e macchine chì l'esecuzione di Intellij Idea seria estremamente fastidiosa.
U prublema di differente throughput di sistemi di cumunicazione, pruduttori è cunsumatori, hè risolta in modu differente. Videmu ciò chì pudemu fà.
Abbandunà: pudemu pretendenu di pudè processà à a maiò parte di transazzioni X in T seconde. Tutte e dumande chì superanu stu limitu sò abbandunate. Hè abbastanza simplice, ma allora pudete scurdà di UX.
Cuntrullà: u cunsumadore deve avè qualchì interfaccia per mezu di quale, secondu a carica, pò cuntrullà i tps di u pruduttore. Ùn hè micca male, ma impone un obbligazione à i sviluppatori di u cliente di carica per implementà sta interfaccia. Per noi, questu hè inacceptable, postu chì u blockchain in u futuru serà integratu in un gran numaru di sistemi longu.
Tampone: invece di cunvene per resiste à u flussu di dati di input, pudemu buffer stu flussu è processà à a velocità necessaria. Ovviamente, questa hè a megliu suluzione se vulemu furnisce una bona sperienza d'utilizatore. Avemu implementatu u buffer utilizendu una fila in RabbitMQ.
Dui novi azzioni sò stati aghjuntu à u schema: (1) dopu chì una dumanda API hè ricivuta, un messagiu hè in fila cù i paràmetri necessarii per chjamà a transazzione, è u cliente riceve un missaghju chì a transazzione hè stata accettata da u sistema, ( 2) u backend leghje e dati à una velocità specificata in a cunfigurazione da a fila; inizia una transazzione è aghjurnà i dati in u magazzinu di statutu.
Avà pudete aumentà u tempu di creazione è bluccà a capacità quantu vulete, ocultendu i ritardi da l'utilizatore.
Altri strumenti
Nunda hè statu dettu quì nantu à chaincode, perchè ùn ci hè di solitu nunda di ottimisimu in questu. U chaincode deve esse u più simplice è sicuru pussibule - hè tuttu ciò chì hè necessariu. U quadru ci aiuta assai à scrive chaincode simplice è sicuru. da S7 Techlab è analizzatore staticu .
Inoltre, a nostra squadra sviluppa un inseme di utilità per fà u travagliu cù Fabric simplice è piacevule: , utilità per (aghjunghje / sguassate organizzazioni, nodi RAFT), utilità per . Sè vo vulete cuntribuisce, benvenutu.
cunchiusioni
Stu approcciu facilita à rimpiazzà Hyperledger Fabric cù Quorum, altre rete private Ethereum (PoA o ancu PoW), riduce significativamente u throughput reale, ma à u stessu tempu mantene UX normale (sia per l'utilizatori in u navigatore è da u latu di i sistemi integrati). ). Quandu rimpiazzà Fabric cù Ethereum in u schema, solu a logica di u serviziu di ricuperazione / decoratore deve esse cambiatu da a gestione di cunflitti MVCC à un incrementu atomicu nonce è risending. U buffering è u almacenamentu di statutu hà permessu di disaccoppià u tempu di risposta da u tempu di furmazione di blocchi. Avà pudete aghjunghje millaie di nodi di ordine è ùn avè micca paura chì i blocchi sò furmati troppu spessu è carricà u serviziu di ordine.
In generale, questu hè tuttu ciò chì vulia sparte. Seraghju cuntentu s'ellu aiuta à qualchissia in u so travagliu.
Source: www.habr.com