Kaixo, DRD KP proiektuko taldean lan egiten dut (gurpil-multzoen bizi-zikloaren jarraipena egiteko datu-erregistro banatua). Hemen gure taldearen esperientzia partekatu nahi dut proiektu honetarako enpresa-blokeo-kate bat garatzeko teknologiaren mugapean. Batez ere Hyperledger Fabric-ari buruz hitz egingo dut, baina hemen deskribatutako ikuspegia baimendutako edozein bloke-katetara estrapola daiteke. Gure ikerketaren azken helburua enpresen bloke-kateen soluzioak prestatzea da, azken produktua erabiltzeko atsegina izan dadin eta mantentzeko zaila izan ez dadin.
Ez da aurkikuntzarik izango, ustekabeko irtenbiderik eta ez da garapen berezirik nabarmenduko hemen (ez dudalako). Nire esperientzia xumea partekatu nahi dut, "posible izan zela" erakutsi eta, agian, erabaki onak eta ez hain onak hartzeko besteen esperientziak irakurri iruzkinetan.
Arazoa: bloke-kateak oraindik ez dira eskalatzen
Gaur egun, garatzaile askoren ahaleginak blockchain teknologia benetan erosoa bilakatzea du helburu, eta ez denbora-bonba bat bilgarri eder batean. Estatuko kanalak, rollup baikorra, plasma eta zatiketak ohikoak izango dira ziurrenik. Egunen batean. Edo agian TONek berriro sei hilabetez atzeratuko du abian jartzea, eta hurrengo Plasma Taldeak existitzeari utziko dio. Hurrengo bide-orrian sinetsi eta gauez liburu zuri bikainak irakur ditzakegu, baina hemen eta orain daukagunarekin zerbait egin behar dugu. Egin kaka.
Oraingo proiektuan gure taldeari ezarri zaion zeregina, oro har, honelakoa da: subjektu asko daude, hainbat milaka izatera iristen direnak, konfiantzaz harremanik sortu nahi ez dutenak; Beharrezkoa da errendimendu-baldintza berezirik gabeko ordenagailu arruntetan funtzionatuko duen DLT-n soluzio bat eraikitzea eta kontabilitate-sistema zentralizatuak baino okerragoa ez den erabiltzaile-esperientzia bat eskaintzea. Irtenbidearen atzean dagoen teknologiak datuen manipulazio gaiztoa egiteko aukera minimizatu behar du - horregatik dago hemen blockchain.
Liburu zurietako eta hedabideetako esloganek hurrengo garapenak segundoko milioika transakzio egiteko aukera emango digula agintzen digute. Zer da benetan?
Une honetan Mainnet Ethereum ~ 30 tps-ra dago martxan. Horregatik bakarrik, zaila da enpresen beharretarako egokia den blockchain gisa hautematea. Baimendutako soluzioen artean 2000 tps erakusten duten erreferentziak daude () edo 3000 tps (, argitalpenean apur bat gutxiago dago, baina kontuan hartu behar da erreferentea adostasun motor zaharrean egin zela). zen , emaitzarik txarrenak ez zituen eman, 20000 tps, baina orain arte ikerketa akademikoa besterik ez da, bere ezarpen egonkorraren zain. Nekez da blockchain-en garatzaileen sail bat mantentzea ordaindu dezakeen korporazio batek adierazle horiek jartzea. Baina arazoa transmisioa ez ezik, latentzia ere badago.
latentzia
Transakzio bat hasten den unetik sistemak behin betiko onespena arte, mezuak baliozkotzeko eta ordenatzeko fase guztietatik igarotzen den abiaduraren araberakoa ez ezik, blokeak eratzeko parametroen araberakoa ere bada. Gure bloke-kateak 1000000 tps-ko abiaduran konprometitzeko aukera ematen badigu ere, baina 10 MBko bloke bat sortzeko 488 minutu behar baditu ere, errazagoa izango al zaigu?
Ikus ditzagun Hyperledger Fabric-en transakzioen bizi-zikloa hurbilagotik, denbora non igarotzen den eta blokeak sortzeko parametroekin nola erlazionatzen den ulertzeko.
hemendik hartua:
(1) Bezeroak transakzio bat sortzen du, parekideei bidaltzen die, azken hauek transakzioa simulatzen dute (aplikatu chaincode bidez egindako aldaketak uneko egoeran, baina ez konprometitu liburuan) eta RWSet jasotzen dute - gako-izenak, bertsioak eta balioak CouchDB-ko bildumatik hartuta, (2) endosatzaileek sinatutako RWSet bat bidaltzen diote bezeroari, (3) bezeroak beharrezkoak diren kide guztien (endosatzaileen) sinadurak daudela egiaztatzen du eta, ondoren, transakzioa eskaera-zerbitzura bidaltzen du. , edo egiaztatu gabe bidaltzen du (egiaztapena geroago egingo da), eskaera-zerbitzuak bloke bat osatzen du eta (4) parekide guztiei bidaltzen die, ez bakarrik endosatzaileei; Parekoek egiaztatzen dute irakurketa-multzoko gako-bertsioak datu-baseko bertsioekin bat datozela, endosatzaile guztiek sinadurak dituztela eta, azkenik, blokeoa konprometitzen dute.
Baina hori ez da guztia. "Ordenatzaileak bloke bat osatzen du" hitzek transakzioen ordenatzeaz gain, liderrak jarraitzaileengana eta itzulera sareko 3 eskaera sekuentzialak ezkutatzen ditu: liderrak mezu bat gehitzen du erregistroan, jarraitzaileei bidaltzen die, azken honek gehitzen du. beren erregistrora, erreplikazio arrakastatsuaren berrespena bidaltzen dio liderrari, liderrak mezua konprometitzen du, jarraitzaileei konprometitu baieztapena bidaltzen die, jarraitzaileak konprometitu. Blokeak eratzeko tamaina eta denbora txikiagoa izan, orduan eta maizago adostasuna ezarri beharko du eskaera-zerbitzuak. Hyperledger Fabric-ek bi parametro ditu blokeak eratzeko: BatchTimeout - blokea eratzeko denbora eta BatchSize - blokearen tamaina (transakzio kopurua eta blokearen beraren tamaina bytetan). Parametroetako bat mugara iritsi bezain laster, bloke berri bat askatzen da. Zenbat eta ordena-nodo gehiago, orduan eta luzeagoa izango da. Hori dela eta, BatchTimeout eta BatchSize handitu behar dituzu. Baina RWSets bertsioak direnez, zenbat eta bloke handiagoa egin, orduan eta handiagoa izango da MVCC gatazkak izateko probabilitatea. Horrez gain, BatchTimeout handitzen den heinean, UX hondamendia hondatzen da. Arazo hauek konpontzeko hurrengo eskema arrazoizkoa eta begi-bistakoa iruditzen zait.
Nola saihestu blokearen amaieraren zain egotea eta transakzioen egoeraren jarraipena egiteko gaitasuna ez galtzea
Zenbat eta eraketa-denbora eta bloke-tamaina luzeagoa izan, orduan eta handiagoa izango da bloke-katearen errendimendua. Batak ez du bestetik zuzenean jarraitzen, baina gogoratu behar da RAFT-en adostasuna ezartzeko hiru sare eskaera behar direla buruzagiarengandik jarraitzaileengana eta atzera. Zenbat eta ordena-nodo gehiago, orduan eta luzeagoa izango da. Blokeen eraketa zenbat eta tamaina eta denbora txikiagoa izan, orduan eta elkarrekintza gehiago egongo dira. Nola handitu sorkuntza-denbora eta bloke-tamaina azken erabiltzailearen sistemaren erantzun-denbora handitu gabe?
Lehenik eta behin, bloke-tamaina handi batek eragindako MVCC gatazkak konpondu behar ditugu, bertsio bereko RWSset desberdinak izan ditzaketenak. Jakina, bezeroaren aldetik (blockchain sareari dagokionez, hau ondo liteke backend-a izan daiteke, eta esan nahi dut) behar duzu MVCC gatazken kudeatzailea, transakzioa berriro saiatu logikarekin abiarazten duen deiaren gainean aparteko zerbitzu bat edo dekoratzaile arrunta izan daitekeena.
Berriro saiatu estrategia esponentzial batekin inplementa daiteke, baina gero latentzia modu esponentzialean degradatuko da. Beraz, ausazko berrazterketa bat erabili beharko zenuke muga txiki batzuen barruan, edo konstante bat. Lehen aukeran talka posibleei begira.
Hurrengo urratsa bezeroak sistemarekin duen interakzioa asinkronoa izatea da, 15, 30 edo 10000000 segundotan itxaron ez dezan, BatchTimeout gisa ezarriko duguna. Baina, aldi berean, beharrezkoa da transakzioak hasitako aldaketak bloke-katean erregistratuta daudela/ez daudela egiaztatzeko gaitasunari eustea.
Datu-base bat erabil daiteke transakzioen egoera gordetzeko. Aukerarik errazena CouchDB da erabiltzeko erraztasunagatik: datu-baseak kutxatik kanpo UI bat du, REST API bat, eta erraz konfigura ditzakezu erreplikazioa eta zatiketa. Besterik gabe, bilduma bereizi bat sor dezakezu Fabrica erabiltzen duen CouchDB instantzia berean bere mundu-egoera gordetzeko. Dokumentu mota hauek gorde behar ditugu.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Dokumentu hau datu-basean idazten da transakzioa parekideei bidali baino lehen, entitatearen IDa erabiltzaileari itzultzen zaio (ID bera erabiltzen da gako gisa) hau sortzeko eragiketa bat bada, eta, ondoren, Egoera, TxID eta Errore eremuak dira. eguneratzen da ikaskideengandik informazio garrantzitsua jasotzen den heinean.
Eskema honetan, erabiltzaileak ez du itxaron blokea azkenean osatzeko, 10 segundoz pantailan biratzen duen gurpila ikusten, sistemaren berehalako erantzuna jasotzen du eta lanean jarraitzen du.
BoltDB aukeratu dugu transakzioen egoerak gordetzeko, memoria aurreztu behar dugulako eta ez dugulako denbora galdu nahi sareko interakzioan datu-basearen zerbitzari bereizi batekin, batez ere interakzio hori testu arrunteko protokoloa erabiliz gertatzen denean. Bide batez, CouchDB erabiltzen baduzu goian deskribatutako eskema ezartzeko edo, besterik gabe, munduko egoera gordetzeko, edozein kasutan zentzuzkoa da datuak CouchDBn gordetzeko modua optimizatzea. Lehenespenez, CouchDB-n, b-tree nodoen tamaina 1279 byte da, hau da, diskoko sektorearen tamaina baino askoz txikiagoa da, eta horrek esan nahi du zuhaitza irakurtzeak eta berregokitzeak diskorako sarbide fisiko gehiago beharko duela. Tamaina optimoa estandarrari dagokio eta 4 kilobyte ditu. Optimitzeko parametroa ezarri behar dugu btree_chunk_size 4096ren berdina CouchDB konfigurazio fitxategian. BoltDBrako eskuzko esku-hartzea .
Atzerapresioa: buffer estrategia
Baina mezu asko egon daitezke. Sistemak kudeatu dezakeena baino gehiago, baliabideak partekatzea diagraman agertzen direnez gain beste hamaika zerbitzurekin, eta horrek guztiak ezin hobeto funtzionatu beharko luke Intellij Idea exekutatzen duten makinetan ere oso neketsua izango litzatekeen.
Komunikazio sistemen, ekoizle eta kontsumitzaileen gaitasun ezberdinen arazoa modu ezberdinetan konpontzen da. Ea zer egin genezakeen.
lausoturik: Gehienez X transakzio T segundotan prozesatzeko gai garela esan dezakegu. Muga hori gainditzen duten eskaera guztiak baztertzen dira. Hau nahiko erraza da, baina gero UX-a ahaztu dezakezu.
kontrolatzea: kontsumitzaileak nolabaiteko interfazea izan behar du, zeinaren bidez, kargaren arabera, ekoizlearen TPS kontrola dezan. Ez dago gaizki, baina bezeroaren garatzaileei betebeharrak ezartzen dizkie interfaze hau ezartzeko karga sortzeko. Hau onartezina da guretzat, etorkizunean bloke-katea aspaldiko sistema ugaritan integratuko baita.
Buffering: Sarrerako datu-korronteari aurre egiten saiatu beharrean, korronte hau bufferatu eta behar den abiaduran prozesatu dezakegu. Jakina, hau da irtenbiderik onena erabiltzaile esperientzia ona eskaini nahi badugu. Bufferra RabbitMQ-en ilara bat erabiliz inplementatu dugu.
Bi ekintza berri gehitu dira eskemari: (1) APIari eskaera bat heldu ondoren, transakzio bat deitzeko beharrezkoak diren parametroak dituen mezu bat jartzen da ilaran, eta bezeroak transakzioa onartu duela dioen mezua jasotzen du. sistemak, (2) backend-ak datuak ilaratik konfigurazioan zehaztutako abiaduran irakurtzen ditu; transakzio bat abiarazten du eta egoera biltegiko datuak eguneratzen ditu.
Orain eraketa-denbora handitu dezakezu eta nahi adina blokeatu ahalmena, erabiltzaileari atzerapenak ezkutatuz.
Beste tresna batzuk
Hemen ez zen ezer esan kate-kodeari buruz, izan ere, normalean, ez dago ezer optimizatzeko. Chaincode-ak ahalik eta errazena eta seguruena izan behar du - hori da eskatzen zaion guztia. Esparruak chaincode modu sinplean eta seguruan idazten laguntzen digu S7 Techlab eta analizatzaile estatikoa .
Horrez gain, gure taldea erabilgarritasun multzo bat garatzen ari da Fabric-ekin lan egitea erraza eta atsegina izan dadin: , erabilgarritasun bat (erakundeak gehitzea/kentzea, RAFT nodoak), erabilgarritasuna . Ekarpena egin nahi baduzu, ongi etorria zara.
Ondorioa
Hurbilketa honek Hyperledger Fabric Quorum-ekin erraz ordezkatzeko aukera ematen du, beste Ethereum sare pribatu batzuekin (PoA edo are PoW), nabarmen murrizten du benetako transmisioa, baina, aldi berean, UX normala mantentzen du (bai nabigatzaileko erabiltzaileentzat, bai sistema integratuak). Eskeman Fabric Ethereum-ekin ordezkatzean, berriro saiatu zerbitzuaren/dekoratzailearen logika aldatu beharko duzu MVCC gatazkak prozesatzeko nonce atomikora gehitzeko eta birbidaltzeko. Buffer-ak eta egoera biltegiratzeak erantzun-denbora blokeen eraketa-denboratik desakoplatzea ahalbidetu zuten. Orain milaka eskaera-nodo gehi ditzakezu eta ez izan beldurrik blokeak sarriegi sortzen diren eta eskaera-zerbitzua kargatu.
Funtsean, hori da partekatu nahi nuen guztia. Pozik egongo naiz honek norbaiti bere lanean laguntzen badu.
Iturria: www.habr.com