Dobrý deň, pracujem v tíme projektu DRD KP (distribuovaný register údajov pre sledovanie životného cyklu dvojkolesí). Tu sa chcem podeliť o skúsenosti nášho tímu s vývojom podnikového blockchainu pre tento projekt v rámci technologických obmedzení. Väčšinou budem hovoriť o Hyperledger Fabric, ale tu opísaný prístup možno extrapolovať na akýkoľvek povolený blockchain. Konečným cieľom nášho výskumu je pripraviť podnikové blockchainové riešenia tak, aby bol výsledný produkt príjemný na používanie a nebol príliš náročný na údržbu.
Nebudú tu žiadne objavy, neočakávané riešenia a nebude tu zdôraznený žiadny jedinečný vývoj (pretože žiadne nemám). Chcem sa len podeliť o svoju skromnú skúsenosť, ukázať, že „to sa dalo“ a možno si v komentároch prečítať o skúsenostiach iných ľudí s dobrými a nie až tak dobrými rozhodnutiami.
Problém: Blockchainy sa zatiaľ neškálujú
Dnes je úsilie mnohých vývojárov zamerané na to, aby sa blockchain stal skutočne pohodlnou technológiou a nie časovanou bombou v krásnom obale. Štátne kanály, optimistický rollup, plazma a sharding sa pravdepodobne stanú samozrejmosťou. Jedného dňa. Alebo možno TON opäť odloží spustenie o šesť mesiacov a ďalšia Plasma Group prestane existovať. Môžeme veriť v ďalší plán a v noci čítať brilantné biele knihy, ale tu a teraz musíme niečo urobiť s tým, čo máme. Urobte hovno.
Úloha stanovená pre náš tím v aktuálnom projekte vyzerá vo všeobecnosti takto: existuje veľa subjektov, dosahujúcich niekoľko tisíc, ktorí nechcú budovať vzťahy na dôvere; Na DLT je potrebné vybudovať riešenie, ktoré bude fungovať na bežných počítačoch bez špeciálnych požiadaviek na výkon a poskytne používateľskú skúsenosť o nič horšiu ako akékoľvek centralizované účtovné systémy. Technológia riešenia musí minimalizovať možnosť zlomyseľnej manipulácie s údajmi – preto je tu blockchain.
Slogany z whitepapers a médií nám sľubujú, že ďalší vývoj nám umožní robiť milióny transakcií za sekundu. čo to vlastne je?
Mainnet Ethereum momentálne beží na ~30 tps. Už len kvôli tomu je ťažké ho vnímať ako blockchain akýmkoľvek spôsobom vhodný pre firemné potreby. Medzi povolené riešenia patria benchmarky ukazujúce 2000 tps () alebo 3000 tps (, v publikácii je o niečo menej, ale musíte vziať do úvahy, že benchmark bol vykonaný na starom nástroji konsenzu). Bol , ktorý priniesol nie najhoršie výsledky, 20000 XNUMX tps, ale zatiaľ ide len o akademický výskum, ktorý čaká na stabilnú implementáciu. Je nepravdepodobné, že korporácia, ktorá si môže dovoliť udržiavať oddelenie vývojárov blockchainu, si potrpí na takéto ukazovatele. Problémom však nie je len priepustnosť, ale aj latencia.
latencia
Oneskorenie od okamihu spustenia transakcie po jej konečné schválenie systémom závisí nielen od rýchlosti, akou správa prejde všetkými fázami validácie a objednávania, ale aj od parametrov tvorby bloku. Aj keď nám náš blockchain umožňuje zaviazať sa rýchlosťou 1000000 10 488 tps, ale vyžaduje XNUMX minút na vygenerovanie XNUMX MB bloku, bude to pre nás jednoduchšie?
Pozrime sa bližšie na životný cyklus transakcií v Hyperledger Fabric, aby sme pochopili, kde sa trávi čas a ako súvisí s parametrami generovania blokov.
prevzaté odtiaľto:
(1) Klient vytvorí transakciu, odošle ju podporným partnerom, tí simulujú transakciu (aplikujú zmeny vykonané reťazovým kódom na aktuálny stav, ale nezapíšu sa do účtovnej knihy) a dostanú RWSet - názvy kľúčov, verzie a hodnoty prevzaté z kolekcie v CouchDB, (2) indosanti pošlú klientovi späť podpísaný RWSet, (3) klient buď skontroluje prítomnosť podpisov všetkých potrebných peerov (podporovateľov), a potom odošle transakciu objednávacej službe , alebo ho odošle bez overenia (kontrola aj tak prebehne neskôr), objednávková služba vytvorí blok a ( 4) pošle späť všetkým partnerom, nielen indosantom; rovesníci skontrolujú, či sa verzie kľúčov v množine na čítanie zhodujú s verziami v databáze, či majú všetci podporovatelia podpisy, a nakoniec potvrdí blok.
To však nie je všetko. Slová „objednávateľ tvorí blok“ skrývajú nielen zoradenie transakcií, ale aj 3 sekvenčné sieťové požiadavky od vedúceho k sledovateľom a späť: vedúci pridá správu do denníka, odošle ju sledovateľom, ten ju pridá do ich denníka, odošle potvrdenie o úspešnej replikácii vedúcemu, vedúci potvrdí správu, odošle potvrdenie o potvrdení nasledovníkom, odovzdá sledovateľom. Čím menšia je veľkosť a čas vytvorenia bloku, tým častejšie bude musieť objednávková služba dosiahnuť konsenzus. Hyperledger Fabric má dva parametre pre tvorbu bloku: BatchTimeout - čas vytvorenia bloku a BatchSize - veľkosť bloku (počet transakcií a veľkosť samotného bloku v bajtoch). Akonáhle jeden z parametrov dosiahne limit, uvoľní sa nový blok. Čím viac uzlov objednávky, tým dlhšie to bude trvať. Preto musíte zvýšiť BatchTimeout a BatchSize. Ale keďže RWSets sú verzované, čím väčší blok vytvoríme, tým vyššia je pravdepodobnosť konfliktov MVCC. Navyše, ako sa BatchTimeout zvyšuje, UX sa katastrofálne zhoršuje. Nasledujúca schéma riešenia týchto problémov sa mi zdá rozumná a zrejmá.
Ako sa vyhnúť čakaniu na finalizáciu bloku a nestratiť možnosť sledovať stav transakcie
Čím dlhší je čas vytvorenia a veľkosť bloku, tým vyššia je priepustnosť blockchainu. Jedna nevyplýva priamo z druhej, ale treba mať na pamäti, že dosiahnutie konsenzu v RAFT si vyžaduje tri sieťové požiadavky od lídra k nasledovníkom a späť. Čím viac uzlov objednávky, tým dlhšie to bude trvať. Čím menšia je veľkosť a čas vytvorenia bloku, tým viac takýchto interakcií je. Ako zvýšiť čas generovania a veľkosť bloku bez zvýšenia času odozvy systému pre koncového používateľa?
Najprv musíme nejako vyriešiť konflikty MVCC spôsobené veľkou veľkosťou bloku, ktorý môže zahŕňať rôzne sady RWS s rovnakou verziou. Je zrejmé, že na strane klienta (vo vzťahu k blockchainovej sieti to môže byť backend, a myslím to vážne) potrebujete Spracovateľ konfliktov MVCC, čo môže byť buď samostatná služba alebo bežný dekorátor nad hovorom, ktorý iniciuje transakciu s logikou opakovania.
Opakovaný pokus možno implementovať pomocou exponenciálnej stratégie, ale potom sa latencia zníži rovnako exponenciálne. Mali by ste teda použiť buď náhodné opakovanie v rámci určitých malých limitov, alebo konštantné. S ohľadom na možné kolízie v prvej možnosti.
Ďalším krokom je, aby bola interakcia klienta so systémom asynchrónna, aby nečakal 15, 30 alebo 10000000 sekúnd, ktoré nastavíme ako BatchTimeout. No zároveň je potrebné zachovať možnosť overenia, či zmeny iniciované transakciou sú/nie sú zaznamenané v blockchaine.
Databázu možno použiť na uloženie stavu transakcie. Najjednoduchšou možnosťou je CouchDB kvôli jednoduchému použitiu: databáza má už po vybalení UI, REST API a môžete pre ňu jednoducho nastaviť replikáciu a sharding. Môžete jednoducho vytvoriť samostatnú kolekciu v rovnakej inštancii CouchDB, ktorá používa Fabric na uloženie svojho svetového stavu. Tieto typy dokumentov musíme uchovávať.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Tento dokument sa zapíše do databázy pred odoslaním transakcie partnerom, ID entity sa vráti používateľovi (rovnaké ID sa použije ako kľúč), ak ide o operáciu vytvorenia, a potom sa polia Stav, TxID a Chyba aktualizované, keď sa získajú relevantné informácie od kolegov.
V tejto schéme používateľ nečaká, kým sa blok konečne vytvorí, 10 sekúnd sleduje rotujúce koliesko na obrazovke, dostane okamžitú odpoveď od systému a pokračuje v práci.
Na ukladanie stavov transakcií sme zvolili BoltDB, pretože potrebujeme šetriť pamäť a nechceme strácať čas sieťovou interakciou so samostatným databázovým serverom, najmä ak k tejto interakcii dochádza pomocou jednoduchého textového protokolu. Mimochodom, či už používate CouchDB na implementáciu vyššie opísanej schémy alebo jednoducho na ukladanie svetového stavu, v každom prípade má zmysel optimalizovať spôsob ukladania údajov v CouchDB. V predvolenom nastavení je v CouchDB veľkosť uzlov b-stromu 1279 bajtov, čo je oveľa menej ako veľkosť sektora na disku, čo znamená, že čítanie aj opätovné vyváženie stromu bude vyžadovať väčší fyzický prístup k disku. Optimálna veľkosť zodpovedá štandardu a má 4 kilobajty. Pre optimalizáciu musíme nastaviť parameter btree_chunk_size sa rovná 4096 v konfiguračnom súbore CouchDB. Pre BoltDB taký manuálny zásah .
Protitlak: vyrovnávacia stratégia
Ale správ môže byť veľa. Viac, než dokáže systém zvládnuť, zdieľanie zdrojov s tuctom ďalších služieb okrem tých, ktoré sú znázornené na diagrame – a to všetko by malo fungovať bezchybne aj na strojoch, na ktorých by bolo spúšťanie Intellij Idea mimoriadne únavné.
Problém rozdielnej kapacity komunikačných systémov, výrobcu a spotrebiteľa, sa rieši rôznymi spôsobmi. Pozrime sa, čo by sme mohli urobiť.
zvrhnutie: Môžeme tvrdiť, že sme schopní spracovať maximálne X transakcií za T sekúnd. Všetky žiadosti prekračujúce tento limit sa zahodia. To je celkom jednoduché, ale potom môžete zabudnúť na UX.
Ovládanie: spotrebiteľ musí mať nejaké rozhranie, cez ktoré môže v závislosti od zaťaženia ovládať TPS výrobcu. Nie je to zlé, ale ukladá povinnosti vývojárom klienta, ktorý vytvára záťaž, implementovať toto rozhranie. To je pre nás neprijateľné, keďže blockchain bude v budúcnosti integrovaný do veľkého množstva už existujúcich systémov.
buffering: Namiesto toho, aby sme sa snažili odolávať vstupnému toku údajov, môžeme tento tok uložiť do vyrovnávacej pamäte a spracovať ho požadovanou rýchlosťou. Je zrejmé, že toto je najlepšie riešenie, ak chceme poskytnúť dobrú používateľskú skúsenosť. Implementovali sme vyrovnávaciu pamäť pomocou frontu v RabbitMQ.
Do schémy boli pridané dve nové akcie: (1) po prijatí požiadavky na API sa do frontu umiestni správa s parametrami potrebnými na zavolanie transakcie a klient dostane správu, že transakcia bola prijatá systém, (2) backend číta dáta rýchlosťou určenou v konfigurácii z frontu; iniciuje transakciu a aktualizuje údaje v sklade stavu.
Teraz môžete zvýšiť čas formovania a blokovať kapacitu, koľko chcete, čím skryjete oneskorenia pred používateľom.
Iné nástroje
O reťazovom kóde tu nebolo povedané nič, pretože v ňom spravidla nie je čo optimalizovať. Reťazový kód by mal byť čo najjednoduchší a najbezpečnejší – to je všetko, čo sa od neho vyžaduje. Rámec nám pomáha písať reťazový kód jednoducho a bezpečne od S7 Techlab a statický analyzátor .
Okrem toho náš tím vyvíja sadu nástrojov, vďaka ktorým je práca s Fabric jednoduchá a príjemná: , pomôcka pre (pridávanie/odstraňovanie organizácií, uzlov RAFT), pomôcka pre . Ak chcete prispieť, ste vítaní.
Záver
Tento prístup umožňuje jednoducho nahradiť Hyperledger Fabric za Quorum, iné súkromné siete Ethereum (PoA alebo aj PoW), výrazne znížiť skutočnú priepustnosť, no zároveň zachovať normálne UX (ako pre používateľov v prehliadači, tak aj pre integrované systémy). Pri výmene Fabric za Ethereum v schéme budete musieť zmeniť iba logiku služby/dekorátora opakovaného pokusu zo spracovania konfliktov MVCC na atómový prírastok a opätovné odoslanie. Ukladanie do vyrovnávacej pamäte a stavové ukladanie umožnilo oddeliť čas odozvy od času vytvorenia bloku. Teraz môžete pridať tisíce uzlov objednávok a nebáť sa, že sa bloky tvoria príliš často a načítať objednávkovú službu.
V podstate to je všetko, o čo som sa chcel podeliť. Budem rád, ak to niekomu pomôže v jeho práci.
Zdroj: hab.com