Moien, ech schaffen am Team vum DRD KP Projet (verdeelt Dateregister fir d'Iwwerwaachung vum Liewenszyklus vu Radsets). Hei wëll ech d'Erfahrung vun eisem Team deelen an der Entwécklung vun engem Enterprise Blockchain fir dëse Projet ënner de Contrainten vun der Technologie. Ech wäert meeschtens iwwer den Hyperledger Stoff schwätzen, awer d'Approche, déi hei beschriwwe gëtt, kann op all autoriséiert Blockchain extrapoléiert ginn. D'ultimativ Zil vun eiser Fuerschung ass Enterprise Blockchain Léisunge virzebereeden sou datt d'Finale Produkt agreabel ass ze benotzen an net ze schwéier ze pflegen.
Et gi keng Entdeckungen, onerwaart Léisungen, a keng eenzegaarteg Entwécklungen ginn hei beliicht (well ech keng hunn). Ech wëll just meng bescheiden Erfahrung ze deelen, weisen, datt "et méiglech war" an, vläicht, liesen iwwer aner Leit Erfahrung gutt an net esou gutt Décisiounen an de Kommentaren.
Problem: Blockchains skaléieren nach net
Haut sinn d'Efforte vu villen Entwéckler zielt fir Blockchain eng wierklech praktesch Technologie ze maachen, an net eng Zäitbomm an engem schéine Wrapper. Staat Channels, optimistesch Rollup, Plasma a Sharding wäert wahrscheinlech allgemeng ginn. E puer Deeg. Oder vläicht wäert den TON de Start fir sechs Méint erëm ausstellen, an déi nächst Plasma Group wäert ophalen ze existéieren. Mir kënnen un déi nächst Fahrplang gleewen a genial Wäissbuch an der Nuecht liesen, awer hei an elo musse mir eppes maachen mat deem wat mir hunn. Maacht Schäiss gemaach.
D'Aufgab, déi eis Team am aktuelle Projet gesat huet, gesäit allgemeng esou aus: Et gi vill Themen, déi e puer dausend erreechen, déi keng Bezéiungen op Vertrauen opbauen wëllen; Et ass néideg eng Léisung op DLT ze bauen, déi op gewéinleche PCs ouni speziell Leeschtungsanforderungen funktionnéiert an eng Benotzererfarung net méi schlëmm wéi all zentraliséiert Comptabilitéitssystem ubitt. D'Technologie hannert der Léisung muss d'Méiglechkeet vu béiswëlleg Manipulatioun vun Daten minimiséieren - dofir ass Blockchain hei.
Slogans aus Whitepapers an de Medien verspriechen eis datt déi nächst Entwécklung eis erlaabt Millioune Transaktiounen pro Sekonn ze maachen. Wat ass et wierklech?
Mainnet Ethereum leeft momentan op ~30 tps. Wéinst deem eleng ass et schwéier et als Blockchain ze gesinn op iergendeng Manéier gëeegent fir Firmenbedürfnisser. Ënnert autoriséiert Léisunge ginn et Benchmarks déi 2000 tps weisen () oder 3000 tps (, et gëtt e bësse manner an der Verëffentlechung, awer Dir musst berücksichtegen datt de Benchmark op der aler Konsensmotor duerchgefouert gouf). War , déi net déi schlëmmste Resultater ginn, 20000 tps, mä bis elo ass dëst just akademesch Fuerschung, op seng stabil Ëmsetzung waarden. Et ass onwahrscheinlech datt eng Gesellschaft déi sech leeschte kann en Departement vu Blockchain Entwéckler z'erhalen, mat esou Indikatoren zoustëmmen. Awer de Problem ass net nëmmen Duerchsatz, et gëtt och latency.
Latenz
D'Verspéidung vum Moment vun enger Transaktioun bis zu senger definitiver Genehmegung vum System hänkt net nëmmen vun der Geschwindegkeet of, op där de Message duerch all Etappe vun der Validatioun an der Bestellung passéiert, awer och vun de Blockbildungsparameter. Och wann eis Blockchain et eis erlaabt mat enger Geschwindegkeet vun 1000000 tps ze engagéieren, awer 10 Minuten erfuerdert fir e 488 MB Block ze generéieren, gëtt et méi einfach fir eis?
Loosst eis den Transaktiounsliewenszyklus am Hyperledger Fabric méi no kucken fir ze verstoen wou Zäit verbruecht gëtt a wéi et mat Blockgeneratiounsparameter ass.
vun hei geholl:
(1) De Client erstellt eng Transaktioun, schéckt se un d'Persounen, déi lescht simuléiert d'Transaktioun (passen d'Ännerunge gemaach duerch Kettencode op den aktuellen Zoustand, awer verpflichte sech net an d'Ledger) a kritt RWSet - Schlësselnamen, Versiounen a Wäerter aus der Sammlung an CouchDB geholl, (2) Endosser schécken en ënnerschriwwene RWSet un de Client zréck, (3) de Client iwwerpréift entweder d'Präsenz vun Ënnerschrëfte vun all noutwendege Peer (Endorser), a schéckt dann d'Transaktioun un den Bestellungsservice , oder schéckt se ouni Verifizéierung (d'Kontroll wäert nach méi spéit stattfannen), de Bestellungsservice formt e Block a ( 4) schéckt zréck un all Kollegen, net nëmmen d'Endosséierer; Peer iwwerpréift datt d'Schlësselversioune vum Liesset mat de Versiounen an der Datebank passen, datt all Endosser Ënnerschrëften hunn, a schliisslech de Block engagéieren.
Mä dat ass net alles. D'Wierder "Besteller formt e Block" verstoppen net nëmmen d'Bestellung vun Transaktiounen, awer och 3 sequentiell Netzwierkfuerderunge vum Leader un d'Unhänger an zréck: de Leader füügt e Message un de Logbuch, schéckt et un d'Unhänger, dee leschte füügt et derbäi. op hire Logbuch, schéckt d'Bestätegung vun der erfollegräicher Replikatioun un de Leader, de Leader verpflicht de Message, schéckt d'Verpflichtungsbestätegung un d'Unhänger, d'Unhänger engagéieren. Wat méi kleng d'Gréisst an d'Zäit vun der Blockbildung ass, dest méi dacks muss de Bestellungsservice Konsens opbauen. Hyperledger Stoff huet zwee Parameteren fir Spär Formatioun: BatchTimeout - Spär Formatioun Zäit an BatchSize - Spär Gréisst (d'Zuel vun Transaktiounen an der Gréisst vun der Spär selwer an Bytes). Soubal ee vun de Parameteren d'Limit erreecht, gëtt en neie Block verëffentlecht. Wat méi Bestellungsknäppchen, wat méi laang dëst dauert. Dofir musst Dir BatchTimeout a BatchSize erhéijen. Awer zënter RWSets Versioune sinn, wat méi grouss de Block dee mir maachen, wat méi héich d'Wahrscheinlechkeet vun MVCC Konflikter. Zousätzlech, wéi BatchTimeout eropgeet, degradéiert d'UX katastrophal. De folgende Schema fir dës Probleemer ze léisen schéngt mir raisonnabel an offensichtlech ze sinn.
Wéi vermeit Dir op d'Finaliséierung vum Block ze waarden an net d'Fäegkeet ze verléieren fir Transaktiounsstatus ze verfolgen
Wat méi laang d'Formatiounszäit an d'Blockgréisst ass, dest méi héich ass den Duerchsatz vun der Blockchain. Een ass net direkt vun deem aneren no, awer et sollt drun erënnert ginn datt Konsens am RAFT opzebauen dräi Netzwierkfuerderunge vum Leader un d'Unhänger an zréck erfuerdert. Wat méi Bestellungsknäppchen, wat méi laang dëst dauert. Wat méi kleng d'Gréisst an d'Zäit vun der Blockbildung ass, wat méi esou Interaktiounen et ginn. Wéi erhéijen d'Generatiounszäit a Blockgréisst ouni d'Systemreaktiounszäit fir den Endbenotzer ze erhéijen?
Als éischt musse mir iergendwéi MVCC Konflikter léisen, déi duerch eng grouss Blockgréisst verursaacht ginn, déi verschidde RWSets mat der selwechter Versioun enthalen. Selbstverständlech, op der Clientssäit (am Zesummenhang mam Blockchain-Netzwierk, kann dëst gutt de Backend sinn, an ech mengen et) Dir braucht MVCC Konflikt Handler, wat entweder e separaten Service oder e regelméissegen Dekorateur iwwer dem Uruff ka sinn, deen d'Transaktioun mat der Retry Logik initiéiert.
Retry kann mat enger exponentieller Strategie ëmgesat ginn, awer da wäert d'Latenz grad esou exponentiell degradéieren. Also sollt Dir entweder e randomiséierte Versuch bannent bestëmmte klenge Grenzen benotzen, oder e konstante. Mat engem Aen op méiglech Kollisiounen an der éischter Optioun.
De nächste Schrëtt ass d'Interaktioun vum Client mam System asynchron ze maachen, sou datt et net op 15, 30 oder 10000000 Sekonnen waart, wat mir als BatchTimeout setzen. Awer gläichzäiteg ass et néideg fir d'Fäegkeet z'erhalen fir z'iwwerpréiwen datt d'Verännerungen, déi vun der Transaktioun initiéiert ginn, sinn / net an der Blockchain opgeholl ginn.
Eng Datebank kann benotzt ginn fir Transaktiounsstatus ze späicheren. Déi einfachst Optioun ass CouchDB wéinst senger einfacher Benotzung: d'Datebank huet en UI aus der Këscht, e REST API, an Dir kënnt einfach Replikatioun a Sharing dofir astellen. Dir kënnt einfach eng separat Sammlung an der selwechter CouchDB Instanz erstellen déi Stoff benotzt fir säi Weltstaat ze späicheren. Mir mussen dës Zort vun Dokumenter späicheren.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Dëst Dokument gëtt an d'Datebank geschriwwe ier d'Transaktioun un d'Peer geschéckt gëtt, d'Entitéits-ID gëtt un de Benotzer zréckginn (déi selwecht ID gëtt als Schlëssel benotzt) wann dëst eng Kreatiounsoperatioun ass, an dann sinn d'Status, TxID a Feeler Felder. aktualiséiert wéi relevant Informatioun vu Kollegen kritt gëtt.
An dësem Schema waart de Benotzer net fir de Block endlech ze bilden, kuckt d'Spinnrad um Écran fir 10 Sekonnen, kritt en direkt Äntwert vum System a schafft weider.
Mir hunn BoltDB gewielt fir Transaktiounsstatusen ze späicheren well mir Erënnerung musse spueren an net Zäit op Netzwierkinteraktioun mat engem getrennten Datebankserver verschwende wëllen, besonnesch wann dës Interaktioun mat engem Einfache Textprotokoll geschitt. Iwwregens, egal ob Dir CouchDB benotzt fir dat uewe beschriwwen Schema ëmzesetzen oder einfach de Weltstaat ze späicheren, op alle Fall mécht et Sënn fir d'Art a Weis wéi d'Daten an CouchDB gespäichert ginn ze optimiséieren. Par défaut, am CouchDB, ass d'Gréisst vun de B-Bam Noden 1279 Bytes, wat vill méi kleng ass wéi d'Sektorgréisst op der Disk, wat heescht datt d'Liesen an d'Rebalancéiere vum Bam méi kierperlechen Zougang zu der Scheif erfuerderen. Déi optimal Gréisst entsprécht dem Standard an ass 4 kilobytes. Fir ze optimiséieren musse mir de Parameter setzen btree_chunk_size gläich wéi 4096 an der CouchDB Konfiguratiounsdatei. Fir BoltDB esou manuell Interventioun .
Backpressure: Puffer Strategie
Mee et kann vill Messagen ginn. Méi wéi de System kann handhaben, Ressourcen deelen mat enger Dosen aner Servicer nieft deenen, déi am Diagramm ugewise sinn - an dat alles soll perfekt funktionnéieren och op Maschinnen op deenen d'Intellij Idea lafen extrem langweileg wier.
De Problem vu verschiddene Kapazitéite vu Kommunikatiounssystemer, Produzent a Konsument, gëtt op verschidde Weeër geléist. Loosst eis kucken wat mir maache kënnen.
Dréckt: Mir kënne behaapten datt mir fäeg sinn maximal X Transaktiounen an T Sekonnen ze veraarbecht. All Ufroen, déi dës Limit iwwerschreiden, ginn verworf. Dëst ass zimmlech einfach, awer da kënnt Dir iwwer UX vergiessen.
Controlling: de Konsument muss eng Zort Interface hunn, duerch déi, jee no der Laascht, den TPS vum Produzent kontrolléiere kann. Net schlecht, awer et setzt Verpflichtungen op d'Entwéckler vum Client déi d'Laascht erstallt fir dës Interface ëmzesetzen. Dëst ass fir eis inakzeptabel, well Blockchain an Zukunft an eng grouss Zuel vu laang existente Systemer integréiert gëtt.
Buffing: Amplaz ze probéieren den Inputdatenstroum ze widderstoen, kënne mir dëse Stroum bufferen a mat der erfuerderter Geschwindegkeet veraarbechten. Natierlech ass dëst déi bescht Léisung wa mir eng gutt Benotzererfarung ubidden. Mir hunn de Puffer ëmgesat mat enger Schlaang am RabbitMQ.
Zwee nei Aktiounen goufen zum Schema bäigefüügt: (1) nodeems eng Ufro un d'API ukomm ass, gëtt e Message mat de Parameteren néideg fir eng Transaktioun ze ruffen an der Schlaang gesat, an de Client kritt e Message datt d'Transaktioun akzeptéiert gouf de System, (2) de Backend liest d'Donnéeën mat der Geschwindegkeet, déi an der Configuratioun aus der Schlaang spezifizéiert ass; initiéiert eng Transaktioun an aktualiséiert Daten am Status Store.
Elo kënnt Dir d'Formatiounszäit erhéijen an d'Kapazitéit blockéieren sou vill wéi Dir wëllt, Verspéidungen vum Benotzer verstoppen.
Aner Tools
Näischt gouf hei iwwer Kettencode gesot, well normalerweis näischt dran ze optimiséieren ass. Chaincode soll esou einfach a sécher wéi méiglech sinn - dat ass alles wat dovunner verlaangt ass. De Kader hëlleft eis Kettencode einfach a sécher ze schreiwen aus S7 Techlab a statesch Analyser .
Zousätzlech entwéckelt eis Team eng Rei vun Utilitys fir d'Aarbecht mat Stoff einfach an erfreelech ze maachen: , en Utility fir (Organisatiounen derbäisetzen / ewechhuelen, RAFT Noden), Utility fir . Wann Dir wëllt bäidroen, sidd Dir wëllkomm.
Konklusioun
Dës Approche erlaabt Iech Hyperledger Fabric ganz einfach duerch Quorum ze ersetzen, aner privat Ethereum Netzwierker (PoA oder souguer PoW), wesentlech reduzéieren den aktuellen Duerchgang, awer gläichzäiteg normal UX erhalen (souwuel fir Benotzer am Browser a fir integréiert Systemer). Wann Dir Stoff mat Ethereum am Schema ersetzt, musst Dir nëmmen d'Logik vum Retry-Service / Dekorateur änneren aus der Veraarbechtung vun MVCC Konflikter op atomarer Nonce-Inkrement an nei Sendung. Buffer a Statuslagerung huet et méiglech gemaach d'Äntwertzäit vun der Blockbildungszäit ze decoupéieren. Elo kënnt Dir Dausende vun Bestellungsknäppchen addéieren an net fäerten datt d'Blöcke ze dacks geformt ginn an den Bestellungsservice lueden.
Am Fong wollt ech dat alles deelen. Ech wäert frou sinn wann dëst een an hirer Aarbecht hëlleft.
Source: will.com