Silav, ez di tîmê projeya DRD KP de dixebitim (qeyda daneya belavkirî ji bo şopandina çerxa jiyanê ya komên çerxer). Li vir ez dixwazim ezmûna tîmê me di pêşxistina blokek pargîdanî de ji bo vê projeyê di bin astengên teknolojiyê de parve bikim. Ez ê bi piranî li ser Fabric Hyperledger biaxivim, lê nêzîkatiya ku li vir hatî destnîşan kirin dikare ji her blokek destûrkirî re were veqetandin. Armanca dawîn a lêkolîna me ev e ku em çareseriyên zincîra bloka pargîdaniyê amade bikin da ku hilbera paşîn karanîna xweş be û domandina wê ne pir dijwar be.
Dê tu vedîtin, çareseriyên nediyar, û pêşkeftinên bêhempa li vir neyên ronî kirin (ji ber ku min tune). Ez tenê dixwazim ezmûna xweya nerm parve bikim, nîşan bidim ku "ew mimkun bû" û, dibe ku, di şîroveyan de serpêhatiyên kesên din ên girtina biryarên baş û ne ewqas baş bixwînim.
Pirsgirêk: Blockchains hîna mezin nakin
Îro, hewildanên gelek pêşdebiran bi mebesta çêkirina blokê teknolojiyek bi rastî hêsan e, û ne bombeyek demjimêr di pêçekek xweşik de. Kanalên dewletê, berhevkirina xweşbîn, plasma û parvekirin dê bibe gelemperî. Hin roj. An jî dibe ku TON dîsa dest pê bike ji bo şeş mehan, û Koma Plasma ya din dê raweste. Em dikarin bi nexşeya rê ya paşîn bawer bikin û bi şev kaxezên spî yên berbiçav bixwînin, lê li vir û naha pêdivî ye ku em bi tiştê ku em hene re tiştek bikin. Xêra xwe bike.
Di projeya heyî de peywira ku ji bo tîmê me hatî danîn bi gelemperî bi vî rengî xuya dike: gelek mijar hene, ku digihîje çend hezaran, ku naxwazin têkiliyan li ser baweriyê ava bikin; Pêdivî ye ku li ser DLT-ê çareseriyek were çêkirin ku dê li ser PC-yên asayî bêyî hewcedariyên performansa taybetî bixebite û ezmûnek bikarhêner peyda bike ku ji pergalên hesabkirina navendî ne xirabtir be. Teknolojiya li pişt çareseriyê pêdivî ye ku îhtîmala manipulasyona xirab a daneyan kêm bike - ji ber vê yekê blokchein li vir e.
Sloganên ji spî û medyayê soz didin me ku pêşkeftina paşîn dê rê bide me ku em her çirkeyê bi mîlyonan danûstendinan bikin. Bi rastî ew çi ye?
Mainnet Ethereum niha li ~ 30 tps dixebite. Ji ber vê yekê tenê, dijwar e ku meriv wê wekî blokcheyn bi her awayî ji bo hewcedariyên pargîdanî guncan bibîne. Di nav çareseriyên destûrdayî de pîvanên ku 2000 tps nîşan didin hene () an 3000 tps (, di weşanê de hindiktir heye, lê hûn hewce ne ku bihesibînin ku pîvan li ser motora lihevhatinê ya kevn hate bicîh kirin). Bû , ku ne encamên herî xirab, 20000 tps da, lê heya nuha ev tenê lêkolînek akademîk e, li benda pêkanîna wê ya domdar e. Ne mimkûn e ku pargîdaniyek ku bikaribe debara domandina dezgehek pêşdebirên blokê bike dê nîşanên weha ragire. Lê pirsgirêk ne tenê rêwiyan e, derengbûn jî heye.
Latînî
Derengiya ji gava ku danûstendinek tê destpêkirin heya pejirandina wê ya paşîn ji hêla pergalê ve ne tenê bi leza ku peyam di hemî qonaxên pejirandin û fermanê re derbas dibe ve girêdayî ye, lê di heman demê de bi pîvanên damezrandina blokê ve jî girêdayî ye. Her çend zincîra meya blokê rê bide me ku em bi leza 1000000 tps tevbigerin, lê ji bo afirandina blokek 10 MB 488 hûrdeman hewce bike, gelo ew ê ji me re hêsantir bibe?
Ka em ji nêz ve li çerxa jiyana danûstendinê ya di Hyperledger Fabric de mêze bikin da ku fêm bikin ka dem li ku derê derbas dibe û ew çawa bi parametreyên hilberîna blokê re têkildar e.
ji vir hatiye girtin:
(1) Xerîdar danûstendinek çêdike, wê dişîne ji hevalên pejirandî re, yên paşîn danûstendinê simule dikin (guhartinên ku ji hêla koda zincîrê ve hatine çêkirin li rewşa heyî bicîh bikin, lê xwe bi sernavê nepejirînin) û RWSet - navên sereke, versiyonên û nirxan bistînin. ji berhevoka li CouchDB hatî girtin, (2) pejiranker RWSetek îmzekirî ji xerîdar re dişînin, (3) xerîdar hebûna îmzeyên hemî pevgirêdanên pêwîst (pesendker) kontrol dike, û dûv re danûstendinê dişîne karûbarê fermandanê , an jî wê bêyî verastkirinê dişîne (kontrol dê hîn paşê pêk were), karûbarê fermankirinê blokê çêdike û (4) ji hemî hevalan re, ne tenê pejirankeran, vedigerîne; peers kontrol dikin ku guhertoyên sereke yên di koma xwendinê de bi guhertoyên di databasê de li hev dikin, ku hemî pejirankar îmze hene, û di dawiyê de blokê pêk tînin.
Lê ev ne hemû ye. Peyvên "fermandar blokê çêdike" ne tenê rêzkirina danûstendinan vedişêre, lê di heman demê de 3 daxwazên torê yên birêkûpêk jî ji rêber ji şagirtan re vedişêre û vedigere: rêber peyamek li têketinê zêde dike, ji şagirtan re dişîne, ya paşîn lê zêde dike. têketina wan, piştrastkirina dubarekirina serketî ji serok re dişîne, rêber peyamê dişîne, erêkirina peywirê ji şagirtan re dişîne, şagirtan dişoxilîne. Mezinahî û dema damezrandina blokê her ku piçûktir be, dê pir caran karûbarê fermanberiyê pêdivî ye ku lihevhatinek saz bike. Hyperledger Fabric ji bo damezrandina blokê du parameteran hene: BatchTimeout - dema damezrandina blokê û BatchSize - mezinahiya blokê (hejmara danûstendinan û mezinahiya blokê bixwe di byte de). Hema ku yek ji pîvanan digihîje sînor, bloka nû tê berdan. Zêdetir girêkên fermanê, ew ê dirêjtir bibe. Ji ber vê yekê, hûn hewce ne ku BatchTimeout û BatchSize zêde bikin. Lê ji ber ku RWSets têne guhertokirin, bloka ku em çêdikin mezintir dibe, îhtîmala pevçûnên MVCC jî ewqasî zêde dibe. Wekî din, her ku BatchTimeout zêde dibe, UX bi felaketî xirab dibe. Plana jêrîn ji bo çareserkirina van pirsgirêkan ji min re maqûl û eşkere xuya dike.
Meriv çawa ji benda qedandina blokê dûr dikeve û şiyana şopandina rewşa danûstendinê winda neke
Her ku dema damezrandinê û mezinahiya blokê dirêjtir be, rêjeya zincîra blokê jî ew qas bilindtir dibe. Yek rasterast ji yê din nagere, lê divê were ji bîr kirin ku damezrandina lihevhatinê di RAFT de sê daxwazên torê ji rêber ji şagirtan re û paşde hewce dike. Zêdetir girêkên fermanê, ew ê dirêjtir bibe. Mezinahî û dema damezrandina blokê çiqas piçûktir be, ewqas têkiliyên weha hene. Meriv çawa dema nifşê û mezinahiya blokê zêde dike bêyî ku dema bersiva pergalê ji bo bikarhênerê dawî zêde bike?
Pêşîn, pêdivî ye ku em bi rengekî nakokiyên MVCC yên ku ji hêla mezinahiya blokek mezin ve têne çêkirin, çareser bikin, ku dibe ku RWSetên cihêreng ên bi heman guhertoyê ve girêdayî bin. Eşkere ye, li ser milê xerîdar (di derbarê tora blokê de, ev dibe ku paşverû be, û ez dibêjim) hûn hewce ne Rêvebirê nakokiya MVCC, ku dikare bibe karûbarek veqetandî an jî dekoratorek birêkûpêk li jorê bangê ku danûstendinê bi mantiqa dubarekirinê dide destpêkirin.
Ji nû ve biceribîne dikare bi stratejiyek berbiçav were sepandin, lê wê hingê dereng dê bi heman rengî bi rengek berbiçav kêm bibe. Ji ber vê yekê divê hûn di nav hin sînorên piçûk de ji nû ve ceribandinek rasthatî, an jî domdar bikar bînin. Bi çavek li ser pevçûnên gengaz ên di vebijarka yekem de.
Pêngava paşîn ev e ku meriv pêwendiya xerîdar bi pergalê re asînkron bike da ku ew li benda 15, 30 an 10000000 saniyeyan nemîne, ku em ê wekî BatchTimeout destnîşan bikin. Lê di heman demê de, pêdivî ye ku meriv şiyana verastkirinê biparêze ku guhartinên ku ji hêla danûstendinê ve hatî destpêkirin di zincîra blokê de têne tomar kirin/ne tomar kirin.
Databasek dikare were bikar anîn da ku rewşa danûstendinê hilîne. Vebijarka herî hêsan CouchDB ye ji ber karanîna wê hêsan e: databas xwedan UI-ya ji qutiyê, REST API-yê ye, û hûn dikarin bi hêsanî ji bo wê dubarekirin û parvekirinê saz bikin. Hûn dikarin di heman mînaka CouchDB-ê de ku Fabric-ê bikar tîne da ku dewleta xwe ya cîhanî hilîne de bi tenê berhevokek cihêreng biafirînin. Pêdivî ye ku em van celeb belgeyan hilînin.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Berî ku danûstendin ji hevalbendan re were şandin, ev belge ji databasê re tê nivîsandin, heke ev operasyonek çêkirinê be, nasnameya sazûmanê ji bikarhênerê re tê vegerandin (eynî nasname wekî mifteyê tê bikar anîn), û dûv re qadên Rewş, TxID û Çewt têne ji ber ku agahdariya têkildar ji hevalên xwe têne nûve kirin.
Di vê pilanê de, bikarhêner li bendê nemîne ku blokê di dawiyê de çêbibe, 10 çirkeyan li çerxa zivirîna li ser ekranê temaşe dike, ew bersivek tavilê ji pergalê distîne û xebata xwe didomîne.
Me BoltDB hilbijart da ku statûyên danûstendinê hilbijart ji ber ku em hewce ne ku bîranînê hilînin û naxwazin wextê li ser danûstendina torê ya bi serverek databasa veqetandî re winda bikin, nemaze dema ku ev têkilî bi karanîna protokolek nivîsê ya sade pêk tê. Bi awayê, hûn CouchDB-ê bikar bînin da ku hûn nexşeya ku li jor hatî destnîşan kirin bicîh bikin an jî tenê ji bo hilanîna dewleta cîhanê bikar bînin, di her rewşê de maqûl e ku meriv awayê hilanîna daneyan li CouchDB xweşbîn bike. Bi xwerû, di CouchDB-ê de, mezinahiya girêkên b-darê 1279 byte ye, ku ji mezinahiya sektora li ser dîskê pir piçûktir e, ku tê vê wateyê ku hem xwendin û hem jî hevsengkirina darê dê bêtir gihîştina laşî ya dîskê hewce bike. Mezinahiya çêtirîn bi standard re têkildar e û 4 kilobyte ye. Ji bo optimîzekirinê divê em pîvanê saz bikin btree_chunk_size bi 4096 re wekhev e di pelê veavakirina CouchDB de. Ji bo BoltDB destwerdana bi vî rengî ya destan .
Backpressure: stratejiya tampon
Lê dibe ku gelek peyam hebin. Zêdetirî ku pergal dikare bi rê ve bibe, ji bilî yên ku di diagramê de têne xuyang kirin bi dehan karûbarên din re parvekirina çavkaniyan - û ev hemî divê li ser makîneyên ku li ser wan xebitandina Intellij Idea dê pir westayî be jî bêkêmasî bixebite.
Pirsgirêka kapasîteyên cûda yên pergalên ragihandinê, hilberîner û xerîdar, bi awayên cûda têne çareser kirin. Ka em bibînin ka em dikarin çi bikin.
Qedandin: Em dikarin îdia bikin ku em dikarin herî zêde X danûstendinan di T çirkeyan de bikin. Hemî daxwazên ku ji vê sînor derbas dibin têne avêtin. Ev pir hêsan e, lê hingê hûn dikarin UX-ê ji bîr bikin.
Kontrolkirin: Pêdivî ye ku xerîdar xwedan celebek navbeynkar be ku bi wê ve girêdayî, li gorî barkirinê, ew dikare TPS-ya hilberîner kontrol bike. Ne xirab e, lê ew berpirsiyariyan li ser pêşdebirên xerîdar ferz dike ku ji bo bicihanîna vê navberê barekê diafirîne. Ev ji bo me nayê qebûlkirin, ji ber ku blok dê di pêşerojê de di nav hejmareke mezin a pergalên dirêj-heyî de were yek kirin.
Bufirkirin: Li şûna ku em li hember herikîna daneya têketinê bisekinin, em dikarin vê çemê tampon bikin û bi leza pêwîst pêve bikin. Eşkere ye ku ger em dixwazin ezmûnek bikarhênerek baş peyda bikin ev çareseriya çêtirîn e. Me tampon bi karanîna dorê li RabbitMQ bicîh kir.
Du kiryarên nû li nexşeyê hatine zêdekirin: (1) piştî ku daxwazek ji API-yê re tê, peyamek bi pîvanên ku ji bo banga danûstendinê hewce ne di rêzê de tê danîn, û xerîdar peyamek werdigire ku danûstendin ji hêla pejirandinê ve hatî pejirandin. pergal, (2) paşîn daneyan bi leza ku di vesazkirinê de ji rêzê hatî destnîşan kirin dixwîne; danûstendinek dest pê dike û daneyên li dikana statûyê nûve dike.
Naha hûn dikarin dema damezrandinê zêde bikin û kapasîteya xwe bi qasî ku hûn dixwazin asteng bikin, derengiyên ji bikarhêner veşêrin.
Amûrên din
Li vir di derbarê zincîra kodê de tiştek nehat gotin, ji ber ku, wekî qaîdeyek, di wê de tiştek çêtirîn tune. Pêdivî ye ku koda zincîrê bi qasî ku pêkan hêsan û ewledar be - ya ku jê re tê xwestin ev e. Çarçove ji me re dibe alîkar ku koda zincîrê bi hêsanî û bi ewlehî binivîsin ji S7 Techlab û analîzerê statîk .
Wekî din, tîmê me komek amûran pêşdixe da ku xebata bi Fabric re hêsan û xweş bike: , amûrek ji bo (zêdekirin / rakirina rêxistinan, girêkên RAFT), karûbar ji bo . Ger hûn dixwazin beşdar bibin, hûn bi xêr hatin.
encamê
Ev nêzîkatî dihêle hûn bi hêsanî Hyperledger Fabric bi Quorum, torgilokên din ên Ethereum-ê yên taybet (PoA an jî PoW) biguhezînin, bi girîngî rêgirtina rastîn kêm bikin, lê di heman demê de UX-ya normal (hem ji bo bikarhênerên di gerokê de hem jî ji bo pergalên yekbûyî) biparêzin. Dema ku Fabric-ê bi Ethereum-ê di pilanê de biguhezînin, hûn ê tenê hewce bikin ku mantiqa karûbar/dekoratorê ji nû ve ceribandinê ji pêvajokirina nakokiyên MVCC-ê berbi zêdekirina nefsa atomî û ji nû ve şandinê biguhezînin. Tampkirin û hilanîna statûyê mimkun kir ku dema bersivê ji dema damezrandina blokê were veqetandin. Naha hûn dikarin bi hezaran girêkên fermanê lê zêde bikin û netirsin ku blokên pir caran têne çêkirin û karûbarê fermanê bar dikin.
Di bingeh de, tiştê ku min dixwest ez parve bikim ev e. Ez ê kêfxweş bibim eger ev yek di karê xwe de alîkariya kesek bike.
Source: www.habr.com