Hallo, ik wurkje yn it team fan it DRD KP-projekt (ferspraat dataregister foar it kontrolearjen fan de libbenssyklus fan tsjilsets). Hjir wol ik de ûnderfining fan ús team diele yn it ûntwikkeljen fan in ûndernimmingsblokje foar dit projekt ûnder de beheiningen fan technology. Ik sil it meast oer de Hyperledger Fabric hawwe, mar de hjir beskreaune oanpak kin ekstrapolearre wurde nei elke tastiene blockchain. It úteinlike doel fan ús ûndersyk is it tarieden fan enterprise blockchain-oplossingen sadat it einprodukt noflik is om te brûken en net te dreech te ûnderhâlden.
D'r sille gjin ûntdekkingen, ûnferwachte oplossings wêze, en gjin unike ûntjouwings sille hjir markearre wurde (om't ik gjin ien haw). Ik wol gewoan myn beskieden ûnderfining diele, sjen litte dat "it mooglik wie" en, miskien, lêze oer de ûnderfiningen fan oare minsken fan it meitsjen fan goede en net sa goede besluten yn 'e kommentaren.
Probleem: Blockchains skaalje noch net
Tsjintwurdich binne de ynspanningen fan in protte ûntwikkelders rjochte op it meitsjen fan blockchain in wirklik handige technology, en net in tiidbom yn in prachtige wrapper. Steatskanalen, optimistyske rollup, plasma en sharding sille wierskynlik gewoan wurde. Guon dei. Of miskien sil TON de lansearring wer seis moanne útstelle, en de folgjende Plasma Group sil ophâlde te bestean. Wy kinne leauwe yn 'e folgjende roadmap en nachts briljante wite kranten lêze, mar hjir en no moatte wy wat dwaan mei wat wy hawwe. Meitsje shit dien.
De taak dy't ús team yn it hjoeddeistige projekt ynsteld hat, sjocht der yn 't algemien sa út: der binne in protte ûnderwerpen, dy't ferskate tûzen berikke, dy't gjin relaasjes op fertrouwen bouwe wolle; It is needsaaklik om in oplossing op DLT te bouwen dy't sil wurkje op gewoane PC's sûnder spesjale prestaasjeseasken en in brûkersûnderfining net slimmer leverje dan alle sintralisearre boekhâldingsystemen. De technology efter de oplossing moat de mooglikheid fan kweade manipulaasje fan gegevens minimalisearje - dêrom is blockchain hjir.
Slogans út whitepapers en de media tasizze ús dat de folgjende ûntwikkeling sil tastean ús te meitsjen miljoenen transaksjes per sekonde. Wat is it echt?
Mainnet Ethereum rint op it stuit op ~30 tps. Fanwegen dit allinich is it lestich om it as blockchain op ien of oare manier te besjen dy't geskikt is foar bedriuwsbehoeften. Under tastiene oplossingen binne d'r benchmarks dy't 2000 tps sjen litte () of 3000 tps (, der is in bytsje minder yn 'e publikaasje, mar jo moatte rekken hâlde dat de benchmark waard útfierd op' e âlde konsensusmotor). Was , dy't net de minste resultaten joech, 20000 tps, mar oant no ta is dit gewoan akademysk ûndersyk, wachtsjend op har stabile ymplemintaasje. It is net wierskynlik dat in korporaasje dy't it betelje kin om in ôfdieling fan blockchain-ûntwikkelders te behâlden, mei sokke yndikatoaren sil sette. Mar it probleem is net allinich trochslach, d'r is ek latency.
Latency
De fertraging fan it momint dat in transaksje wurdt inisjearre oant syn definitive goedkarring troch it systeem hinget net allinich ôf fan 'e snelheid wêrop it berjocht troch alle stadia fan falidaasje en bestellen giet, mar ek fan' e blokfoarmingsparameters. Sels as ús blockchain ús tastean te begean mei in snelheid fan 1000000 tps, mar fereasket 10 minuten om in 488 MB blok te generearjen, sil it makliker wurde foar ús?
Litte wy de transaksjelibbenssyklus yn Hyperledger Fabric in tichterby besjen om te begripen wêr't tiid wurdt bestege en hoe't it relatearret oan parameters foar blokgeneraasje.
nommen hjirwei:
(1) De klant makket in transaksje, stjoert it nei ûnderskriuwende peers, de lêste simulearje de transaksje (tapasje wizigingen makke troch kettingkoade nei de hjoeddeistige steat, mar ferplichtsje jo net oan it ledger) en ûntfange RWSet - kaainammen, ferzjes en wearden nommen út 'e kolleksje yn CouchDB, (2) endossers stjoere in ûndertekene RWSet werom nei de klant, (3) de kliïnt kontrolearret of de oanwêzigens fan hantekeningen fan alle nedige peers (endorsers), en stjoert dan de transaksje nei de besteltsjinst , of stjoert it sûnder ferifikaasje (de kontrôle sil noch letter plakfine), de besteltsjinst foarmet in blok en ( 4) stjoert werom nei alle peers, net allinich ûnderskriuwers; Peers kontrolearje dat de kaaiferzjes yn 'e lêsset oerienkomme mei de ferzjes yn' e databank, dat alle endorsers hantekeningen hawwe, en úteinlik it blokje begean.
Mar dat is net alles. De wurden "besteller foarmet in blok" ferbergje net allinich de oardering fan transaksjes, mar ek 3 opfolgjende netwurkoanfragen fan 'e lieder nei de folgers en werom: de lieder foeget in berjocht ta oan it log, stjoert it nei de folgers, de lêste foeget it ta nei har log, stjoert befêstiging fan suksesfolle replikaasje nei de lieder, de lieder set it berjocht yn, stjoert befestigingsbefêstiging nei folgers, folgers commit. Hoe lytser de grutte en tiid fan blokfoarming, hoe faker sil de besteltsjinst konsensus moatte fêstigje. Hyperledger Fabric hat twa parameters foar blok formaasje: BatchTimeout - blok formaasje tiid en BatchSize - blok grutte (it oantal transaksjes en de grutte fan it blok sels yn bytes). Sadree't ien fan 'e parameters de limyt berikt, wurdt in nij blok frijjûn. Hoe mear oarderknooppunten, hoe langer dit sil nimme. Dêrom moatte jo BatchTimeout en BatchSize ferheegje. Mar om't RWSets ferzjes binne, hoe grutter it blok dat wy meitsje, hoe heger de kâns op MVCC-konflikten. Derneist, as BatchTimeout ferheget, degradearret de UX katastrofysk. It folgjende skema foar it oplossen fan dizze problemen liket my ridlik en fanselssprekkend.
Hoe kinne jo foarkomme dat jo wachtsje op blokfinalisaasje en de mooglikheid net ferlieze om transaksjestatus te folgjen
Hoe langer de formaasjetiid en blokgrutte, hoe heger de trochfier fan 'e blockchain. Ien folget net direkt fan 'e oare, mar it moat betocht wurde dat it fêststellen fan konsensus yn RAFT trije netwurkoanfragen fereasket fan' e lieder nei de folgers en werom. Hoe mear oarderknooppunten, hoe langer dit sil nimme. Hoe lytser de grutte en tiid fan blokfoarming, hoe mear sokke ynteraksjes binne. Hoe kinne jo de generaasjetiid en blokgrutte ferheegje sûnder de systeemresponstiid foar de einbrûker te fergrutsjen?
Earst moatte wy op ien of oare manier MVCC-konflikten oplosse dy't feroarsake binne troch in grutte blokgrutte, dy't ferskate RWSets mei deselde ferzje kinne befetsje. Fansels, oan 'e kant fan' e kliïnt (yn relaasje mei it blockchain-netwurk, kin dit goed de efterkant wêze, en ik bedoel it) jo moatte MVCC konflikt handler, dat kin wêze of in aparte tsjinst of in reguliere decorator boppe de oprop dy't inisjearret de transaksje mei opnij logika.
Opnij probearje kin wurde ymplementearre mei in eksponinsjele strategy, mar dan sil de latency like eksponentiell degradearje. Dat jo moatte of in willekeurich opnij besykje binnen bepaalde lytse grinzen, of in konstante. Mei it each op mooglike botsingen yn de earste opsje.
De folgjende stap is om de ynteraksje fan 'e kliïnt mei it systeem asynchronous te meitsjen sadat it net wachtet foar 15, 30 of 10000000 sekonden, dy't wy sille ynstelle as BatchTimeout. Mar tagelyk is it nedich om de mooglikheid te behâlden om te ferifiearjen dat de wizigingen dy't troch de transaksje ynsteld binne / net opnommen binne yn 'e blockchain.
In databank kin brûkt wurde om transaksjestatus op te slaan. De ienfâldichste opsje is CouchDB fanwegen it gemak fan gebrûk: de databank hat in UI út 'e doaze, in REST API, en jo kinne maklik replikaasje en sharding foar ynstelle. Jo kinne gewoan in aparte kolleksje oanmeitsje yn deselde CouchDB-eksimplaar dy't Fabric brûkt om syn wrâldsteat op te slaan. Wy moatte dizze soarten dokuminten opslaan.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Dit dokumint wurdt skreaun nei de database foardat de transaksje nei peers ferstjoerd wurdt, de entiteits-ID wurdt weromjûn oan de brûker (itselde ID wurdt brûkt as in kaai) as dit in skeppingsoperaasje is, en dan binne de fjilden Status, TxID en Flater bywurke as relevante ynformaasje wurdt ûntfongen fan peers.
Yn dit skema wachtet de brûker net foar it einlings foarmjen fan it blok, sjocht it draaiende tsjil op it skerm foar 10 sekonden, hy krijt in direkte antwurd fan it systeem en bliuwt te wurkjen.
Wy hawwe BoltDB keazen om transaksjestatussen op te slaan, om't wy ûnthâld moatte bewarje en gjin tiid wolle fergrieme op netwurk ynteraksje mei in aparte databanktsjinner, benammen as dizze ynteraksje foarkomt mei in gewoane tekstprotokol. Trouwens, of jo CouchDB brûke om it hjirboppe beskreaune skema út te fieren of gewoan om wrâldsteat op te slaan, yn alle gefallen is it logysk om de manier te optimalisearjen fan gegevens opslein yn CouchDB. Standert, yn CouchDB, is de grutte fan b-tree-knooppunten 1279 bytes, wat folle lytser is as de sektorgrutte op 'e skiif, wat betsjut dat sawol it lêzen as it rebalisearjen fan 'e beam mear fysike tagong ta de skiif fereaskje. De optimale grutte komt oerien mei de standert en is 4 kilobytes. Om te optimalisearjen moatte wy de parameter ynstelle btree_chunk_size lyk oan 4096 yn it CouchDB-konfiguraasjetriem. Foar BoltDB sa'n hânmjittich yntervinsje .
Backpressure: buffer strategy
Mar der kinne in protte berjochten wêze. Mear dan it systeem kin omgean, it dielen fan boarnen mei in tsiental oare tsjinsten neist de werjûn yn it diagram - en dit alles soe perfekt wurkje, sels op masines wêrop it útfieren fan Intellij Idea ekstreem saai wêze soe.
It probleem fan ferskate kapasiteiten fan kommunikaasjesystemen, produsint en konsumint, wurdt op ferskate manieren oplost. Litte wy sjen wat wy kinne dwaan.
Droping: Wy kinne beweare dat wy by steat binne om te ferwurkjen op de measte X transaksjes yn T sekonden. Alle oanfragen dy't dizze limyt te boppe binne, wurde wegere. Dit is frij ienfâldich, mar dan kinne jo UX ferjitte.
Kontrolearjen: de konsumint moat in soarte fan ynterface hawwe wêrmei't hy, ôfhinklik fan 'e lading, de TPS fan 'e produsint kontrolearje kin. Net min, mar it legt ferplichtingen op oan 'e ûntwikkelders fan' e kliïnt dy't de lading kreëarje om dizze ynterface út te fieren. Dit is foar ús net akseptabel, om't blockchain yn 'e takomst yntegreare wurde yn in grut oantal lang besteande systemen.
Bufferjen: Ynstee fan te besykjen om de ynfierdatastream te wjerstean, kinne wy dizze stream bufferje en ferwurkje mei de fereaske snelheid. Fansels is dit de bêste oplossing as wy in goede brûkersûnderfining wolle leverje. Wy ymplementearre de buffer mei help fan in wachtrige yn RabbitMQ.
Twa nije aksjes binne tafoege oan it skema: (1) nei't in fersyk oan 'e API komt, wurdt in berjocht mei de parameters dy't nedich binne om in transaksje op te roppen yn' e wachtrige pleatst, en de kliïnt krijt in berjocht dat de transaksje is akseptearre troch it systeem, (2) de efterkant lêst de gegevens mei de snelheid oantsjutte yn de konfiguraasje fan wachtrige; inisjearret in transaksje en updates gegevens yn de status winkel.
No kinne jo de formaasjetiid ferheegje en kapasiteit blokkearje safolle as jo wolle, ferbergje fertragingen foar de brûker.
Oare ark
Hjir is neat sein oer chaincode, om't d'r yn 'e regel neat is om te optimalisearjen. Chaincode moat sa ienfâldich en feilich mooglik wêze - dat is alles wat derfan fereaske is. It ramt helpt ús chaincode ienfâldich en feilich te skriuwen út S7 Techlab en statyske analyzer .
Derneist ûntwikkelet ús team in set nutsbedriuwen om it wurkjen mei Fabric ienfâldich en noflik te meitsjen: , in nut foar (taheakjen / fuortsmite organisaasjes, RAFT knopen), nut foar . Wolle jo bydrage, dan binne jo wolkom.
konklúzje
Dizze oanpak lit jo Hyperledger Fabric maklik ferfange troch Quorum, oare privee Ethereum-netwurken (PoA of sels PoW), de eigentlike trochfier signifikant ferminderje, mar tagelyk normale UX behâlde (sawol foar brûkers yn 'e browser as foar yntegreare systemen). By it ferfangen fan Fabric mei Ethereum yn it skema, hoege jo allinich de logika fan 'e opnij tsjinst / dekorator te feroarjen fan it ferwurkjen fan MVCC-konflikten nei atomyske nonce-inkrement en opnij ferstjoere. Buffer- en statusopslach makken it mooglik om de reaksjetiid te ûntkoppelen fan 'e blokformaasjetiid. No kinne jo tûzenen bestellingknooppunten tafoegje en net bang wêze dat blokken te faak wurde foarme en de besteltsjinst laden.
Yn prinsipe, dat is alles wat ik diele woe. Ik sil bliid wêze as dit immen helpt yn har wurk.
Boarne: www.habr.com