Hujambo, ninafanya kazi katika timu ya mradi wa DRD KP (rejista ya data iliyosambazwa kwa ajili ya kufuatilia mzunguko wa maisha wa seti za magurudumu). Hapa nataka kushiriki uzoefu wa timu yetu katika kutengeneza blockchain ya biashara kwa mradi huu chini ya vikwazo vya teknolojia. Nitakuwa nikizungumza zaidi juu ya Kitambaa cha Hyperledger, lakini mbinu iliyoelezewa hapa inaweza kutolewa kwa blockchain yoyote iliyoidhinishwa. Lengo kuu la utafiti wetu ni kuandaa suluhisho za biashara ya blockchain ili bidhaa ya mwisho iwe ya kupendeza kutumia na sio ngumu sana kutunza.
Hakutakuwa na uvumbuzi, suluhu zisizotarajiwa, na hakuna maendeleo ya kipekee yataangaziwa hapa (kwa sababu sina). Ninataka tu kushiriki uzoefu wangu wa kawaida, onyesha kwamba "iliwezekana" na, labda, soma kuhusu uzoefu wa watu wengine wa kufanya maamuzi mazuri na sio mazuri katika maoni.
Tatizo: Blockchains bado hazijaongezeka
Leo, juhudi za watengenezaji wengi zinalenga kufanya blockchain kuwa teknolojia rahisi sana, na sio bomu la wakati kwenye kanga nzuri. Njia za serikali, upangaji wa matumaini, plasma na sharding inaweza kuwa kawaida. Siku fulani. Au labda TON itaahirisha tena uzinduzi kwa miezi sita, na Kikundi kinachofuata cha Plasma kitakoma kuwepo. Tunaweza kuamini katika ramani inayofuata na kusoma karatasi nyeupe za kung'aa usiku, lakini hapa na sasa tunahitaji kufanya kitu na kile tulicho nacho. Fanya uchafu.
Kazi iliyowekwa kwa timu yetu katika mradi wa sasa inaonekana kwa ujumla kama hii: kuna masomo mengi, kufikia elfu kadhaa, ambao hawataki kujenga uhusiano juu ya uaminifu; Inahitajika kuunda suluhisho kwenye DLT ambayo itafanya kazi kwenye Kompyuta za kawaida bila mahitaji maalum ya utendaji na kutoa uzoefu wa mtumiaji sio mbaya zaidi kuliko mifumo yoyote ya uhasibu ya kati. Teknolojia iliyo nyuma ya suluhisho lazima ipunguze uwezekano wa udanganyifu mbaya wa data - ndiyo sababu blockchain iko hapa.
Kauli mbiu kutoka kwa karatasi nyeupe na vyombo vya habari hutuahidi kwamba maendeleo yajayo yataturuhusu kufanya mamilioni ya miamala kwa sekunde. Ni nini hasa?
Mainnet Ethereum kwa sasa inafanya kazi ~tps 30. Kwa sababu ya hili pekee, ni vigumu kuiona kama blockchain kwa njia yoyote inayofaa kwa mahitaji ya shirika. Miongoni mwa suluhisho zilizoruhusiwa kuna alama zinazoonyesha tps 2000 () au 3000 tps (, kuna kidogo kidogo katika uchapishaji, lakini unahitaji kuzingatia kwamba benchmark ilifanyika kwenye injini ya makubaliano ya zamani). Ilikuwa , ambayo haikutoa matokeo mabaya zaidi, tps 20000, lakini hadi sasa hii ni utafiti wa kitaaluma tu, unasubiri utekelezaji wake imara. Haiwezekani kwamba shirika ambalo linaweza kumudu kudumisha idara ya watengenezaji wa blockchain litaweka viashiria vile. Lakini tatizo si tu throughput, pia kuna latency.
Ukamilifu
Kuchelewa kutoka wakati shughuli imeanzishwa kwa idhini yake ya mwisho na mfumo inategemea si tu kwa kasi ambayo ujumbe hupitia hatua zote za uthibitishaji na kuagiza, lakini pia kwenye vigezo vya uundaji wa kuzuia. Hata kama blockchain yetu inaturuhusu kujituma kwa kasi ya tps 1000000, lakini inahitaji dakika 10 kutengeneza block ya 488 MB, itakuwa rahisi kwetu?
Hebu tuangalie kwa makini mzunguko wa maisha wa muamala katika Hyperledger Fabric ili kuelewa ni wapi muda unatumika na jinsi unavyohusiana na kuzuia vigezo vya kizazi.
kuchukuliwa kutoka hapa:
(1) Mteja huunda muamala, kuutuma kwa wenzao wanaoidhinisha, wa pili kuiga muamala (tumia mabadiliko yaliyofanywa na chaincode kwa hali ya sasa, lakini usijitoe kwenye leja) na kupokea RWSet - majina muhimu, matoleo na maadili ikichukuliwa kutoka kwa mkusanyiko katika CouchDB, (2) waidhinishaji hutuma tena RWSet iliyotiwa saini kwa mteja, (3) mteja aidha anakagua uwepo wa saini za washirika wote muhimu (waidhinishaji), na kisha kutuma muamala kwa huduma ya kuagiza. , au kuituma bila uthibitishaji (hundi bado itafanyika baadaye), huduma ya kuagiza huunda kizuizi na ( 4) kutuma nyuma kwa wenzao wote, si waidhinishaji tu; wenzao hukagua kuwa matoleo muhimu katika seti iliyosomwa yanalingana na matoleo katika hifadhidata, kwamba waidhinishaji wote wana saini, na hatimaye kuweka kizuizi.
Lakini si hayo tu. Maneno "mpangaji huunda kizuizi" huficha sio tu kuagiza shughuli, lakini pia maombi 3 ya mtandao mfululizo kutoka kwa kiongozi kwa wafuasi na nyuma: kiongozi anaongeza ujumbe kwenye logi, anaituma kwa wafuasi, mwisho anaongeza. kwa logi yao, hutuma uthibitisho wa kurudiwa kwa mafanikio kwa kiongozi, kiongozi hufanya ujumbe, hutuma uthibitisho wa kujitolea kwa wafuasi, wafuasi hujitolea. Ukubwa mdogo na wakati wa uundaji wa block, mara nyingi zaidi huduma ya kuagiza itabidi kuanzisha makubaliano. Kitambaa cha Hyperledger kina vigezo viwili vya uundaji wa block: BatchTimeout - muda wa uundaji wa kuzuia na BatchSize - ukubwa wa kuzuia (idadi ya shughuli na ukubwa wa block yenyewe katika byte). Mara tu moja ya vigezo inapofikia kikomo, kizuizi kipya kinatolewa. Kadiri nodi nyingi za mpangilio, hii itachukua muda mrefu. Kwa hivyo, unahitaji kuongeza BatchTimeout na BatchSize. Lakini kwa kuwa RWSets ni matoleo, kadiri kizuizi tunachotengeneza, ndivyo uwezekano wa migogoro ya MVCC unavyoongezeka. Kwa kuongeza, BatchTimeout inapoongezeka, UX huharibika vibaya. Mpango ufuatao wa kutatua shida hizi unaonekana kuwa sawa na dhahiri kwangu.
Jinsi ya kuepuka kusubiri kizuizi kukamilika na si kupoteza uwezo wa kufuatilia hali ya shughuli
Kadiri muda wa uundaji na ukubwa wa kizuizi unavyoongezeka, ndivyo upitishaji wa blockchain unavyoongezeka. Moja haifuati moja kwa moja kutoka kwa nyingine, lakini ikumbukwe kwamba kuanzisha makubaliano katika RAFT inahitaji maombi matatu ya mtandao kutoka kwa kiongozi kwa wafuasi na nyuma. Kadiri nodi nyingi za mpangilio, hii itachukua muda mrefu. Ukubwa mdogo na wakati wa uundaji wa block, mwingiliano kama huo kuna zaidi. Jinsi ya kuongeza muda wa kizazi na ukubwa wa kuzuia bila kuongeza muda wa majibu ya mfumo kwa mtumiaji wa mwisho?
Kwanza, tunahitaji kwa namna fulani kutatua migogoro ya MVCC inayosababishwa na ukubwa mkubwa wa kuzuia, ambayo inaweza kujumuisha RWSets tofauti na toleo sawa. Ni wazi, kwa upande wa mteja (kuhusiana na mtandao wa blockchain, hii inaweza kuwa sehemu ya nyuma, na ninamaanisha) unahitaji Kidhibiti cha migogoro cha MVCC, ambayo inaweza kuwa huduma tofauti au mpambaji wa kawaida juu ya simu ambayo huanzisha shughuli kwa mantiki ya kujaribu tena.
Kujaribu tena kunaweza kutekelezwa kwa mkakati wa kitaalam, lakini muda wa kusubiri utashusha hadhi kwa kasi zaidi. Kwa hivyo unapaswa kutumia kujaribu tena bila mpangilio ndani ya mipaka fulani ndogo, au ya mara kwa mara. Kwa jicho kwenye migongano inayowezekana katika chaguo la kwanza.
Hatua inayofuata ni kufanya mwingiliano wa mteja na mfumo ufanane ili isingoje kwa sekunde 15, 30 au 10000000, ambayo tutaiweka kama BatchTimeout. Lakini wakati huo huo, ni muhimu kudumisha uwezo wa kuthibitisha kwamba mabadiliko yaliyoanzishwa na shughuli ni / si kumbukumbu katika blockchain.
Hifadhidata inaweza kutumika kuhifadhi hali ya muamala. Chaguo rahisi zaidi ni CouchDB kwa sababu ya urahisi wa utumiaji: hifadhidata ina UI nje ya boksi, API ya REST, na unaweza kuisanidi kwa urahisi na kuigawanya. Unaweza tu kuunda mkusanyiko tofauti katika mfano sawa wa CouchDB ambao hutumia kitambaa kuhifadhi hali yake ya ulimwengu. Tunahitaji kuhifadhi aina hizi za hati.
{
Status string // Π‘ΡΠ°ΡΡΡ ΡΡΠ°Π½Π·Π°ΠΊΡΠΈΠΈ: "pending", "done", "failed"
TxID: string // ID ΡΡΠ°Π½Π·Π°ΠΊΡΠΈΠΈ
Error: string // optional, ΡΠΎΠΎΠ±ΡΠ΅Π½ΠΈΠ΅ ΠΎΠ± ΠΎΡΠΈΠ±ΠΊΠ΅
}Hati hii imeandikwa kwenye hifadhidata kabla ya shughuli kutumwa kwa wenzako, kitambulisho cha huluki kinarejeshwa kwa mtumiaji (kitambulisho sawa kinatumika kama ufunguo) ikiwa hii ni operesheni ya kuunda, kisha Sehemu za Hali, TxID na Hitilafu zinawekwa. inasasishwa kadri taarifa muhimu zinavyopokelewa kutoka kwa wenzao.
Katika mpango huu, mtumiaji hangojei kizuizi ili hatimaye kuunda, akiangalia gurudumu inayozunguka kwenye skrini kwa sekunde 10, anapokea jibu la papo hapo kutoka kwa mfumo na anaendelea kufanya kazi.
Tulichagua BoltDB kuhifadhi hali za muamala kwa sababu tunahitaji kuhifadhi kumbukumbu na hatutaki kupoteza muda kwenye mwingiliano wa mtandao na seva tofauti ya hifadhidata, hasa wakati mwingiliano huu unatokea kwa kutumia itifaki ya maandishi wazi. Kwa njia, iwe unatumia CouchDB kutekeleza mpango uliofafanuliwa hapo juu au kuhifadhi tu hali ya ulimwengu, kwa hali yoyote ni mantiki kuboresha jinsi data inavyohifadhiwa katika CouchDB. Kwa chaguo-msingi, katika CouchDB, saizi ya nodi za b-tree ni 1279 byte, ambayo ni ndogo sana kuliko saizi ya sekta kwenye diski, ambayo inamaanisha kusoma na kusawazisha mti kutahitaji ufikiaji zaidi wa mwili kwa diski. Ukubwa bora unalingana na kiwango na ni 4 kilobytes. Ili kuboresha tunahitaji kuweka parameter btree_chunk_size sawa na 4096 katika faili ya usanidi ya CouchDB. Kwa BoltDB uingiliaji wa mwongozo kama huo .
Shinikizo la nyuma: mkakati wa bafa
Lakini kunaweza kuwa na ujumbe mwingi. Zaidi ya mfumo unavyoweza kushughulikia, kugawana rasilimali na huduma kadhaa kando na zile zilizoonyeshwa kwenye mchoro - na yote haya yanapaswa kufanya kazi bila dosari hata kwenye mashine ambazo kuendesha Intellij Idea kunaweza kuchosha sana.
Tatizo la uwezo tofauti wa mifumo ya kuwasiliana, mtayarishaji na walaji, hutatuliwa kwa njia tofauti. Hebu tuone kile ambacho tungeweza kufanya.
Matone: Tunaweza kudai kwamba tunaweza kuchakata katika miamala mingi ya X katika sekunde T. Maombi yote yanayozidi kikomo hiki yanatupwa. Hii ni rahisi sana, lakini basi unaweza kusahau kuhusu UX.
Kudhibiti: mtumiaji lazima awe na aina fulani ya interface ambayo, kulingana na mzigo, anaweza kudhibiti TPS ya mtayarishaji. Sio mbaya, lakini inaweka majukumu kwa watengenezaji wa mteja kuunda mzigo wa kutekeleza kiolesura hiki. Hii haikubaliki kwetu, kwani blockchain katika siku zijazo itaunganishwa katika idadi kubwa ya mifumo ya muda mrefu.
Kuakibisha: Badala ya kujaribu kupinga mtiririko wa data ya ingizo, tunaweza kuakibisha mkondo huu na kuuchakata kwa kasi inayohitajika. Ni wazi kuwa hili ndilo suluhisho bora zaidi ikiwa tunataka kutoa hali nzuri ya utumiaji. Tulitekeleza bafa kwa kutumia foleni katika RabbitMQ.
Vitendo viwili vipya vimeongezwa kwenye mpango huo: (1) baada ya ombi kwa API kufika, ujumbe ulio na vigezo muhimu vya kupiga shughuli huwekwa kwenye foleni, na mteja hupokea ujumbe kwamba shughuli hiyo imekubaliwa na. mfumo, (2) nyuma husoma data kwa kasi iliyoainishwa kwenye usanidi kutoka kwa foleni; huanzisha muamala na kusasisha data katika duka la hali.
Sasa unaweza kuongeza muda wa uundaji na uwezo wa kuzuia kadiri unavyotaka, ukificha ucheleweshaji kutoka kwa mtumiaji.
Zana nyingine
Hakuna kilichosemwa hapa kuhusu chaincode, kwa sababu, kama sheria, hakuna kitu cha kuongeza ndani yake. Chaincode inapaswa kuwa rahisi na salama iwezekanavyo - hiyo ndiyo tu inahitajika kwake. Mfumo hutusaidia kuandika chaincode kwa urahisi na kwa usalama kutoka S7 Techlab na analyzer tuli .
Kwa kuongezea, timu yetu inaunda seti ya huduma ili kufanya kufanya kazi na Kitambaa kuwa rahisi na kufurahisha: , matumizi ya (kuongeza/kuondoa mashirika, nodi za RAFT), matumizi ya . Ukitaka kuchangia unakaribishwa.
Hitimisho
Njia hii inakuwezesha kuchukua nafasi ya Kitambaa cha Hyperledger kwa urahisi na Quorum, mitandao mingine ya kibinafsi ya Ethereum (PoA au hata PoW), kupunguza kwa kiasi kikubwa matokeo halisi, lakini wakati huo huo kudumisha UX ya kawaida (wote kwa watumiaji katika kivinjari na kwa mifumo iliyounganishwa). Unapobadilisha Kitambaa na Ethereum katika mpango, utahitaji tu kubadilisha mantiki ya huduma ya kujaribu tena/kipamba kutoka kuchakata mizozo ya MVCC hadi uongezaji wa atomiki na kutuma tena. Uwekaji akiba na uhifadhi wa hali ulifanya iwezekane kutenganisha muda wa majibu kutoka kwa muda wa kuunda kizuizi. Sasa unaweza kuongeza maelfu ya nodi za utaratibu na usiogope kwamba vitalu vinaundwa mara nyingi na kupakia huduma ya kuagiza.
Kimsingi, hiyo ndiyo yote nilitaka kushiriki. Nitafurahi ikiwa hii itasaidia mtu katika kazi yake.
Chanzo: mapenzi.com