Helo, rwy'n gweithio yn nhîm y prosiect DRD KP (cofrestrfa ddata ddosbarthedig ar gyfer monitro cylch bywyd setiau olwyn). Yma rwyf am rannu profiad ein tîm wrth ddatblygu blockchain menter ar gyfer y prosiect hwn o dan y cyfyngiadau a osodir gan dechnoleg. Ar y cyfan, byddaf yn siarad am Hyperledger Fabric, ond gellir allosod y dull a ddisgrifir yma i unrhyw blockchain a ganiateir. Nod eithaf ein hymchwil yw paratoi datrysiadau blockchain menter yn y fath fodd fel bod y cynnyrch terfynol yn ddymunol i'w ddefnyddio ac nad yw'n rhy anodd ei gynnal.
Ni fydd unrhyw ddarganfyddiadau, atebion annisgwyl, ac ni fydd unrhyw ddatblygiadau unigryw yn cael sylw yma (gan nad oes gennyf rai). Dwi jest eisiau rhannu fy mhrofiad gostyngedig, dangos "ei bod hi'n bosib" ac, efallai, darllen am brofiad rhywun arall o wneud penderfyniadau da a ddim cystal yn y sylwadau.
Problem: nid yw cadwyni bloc yn scalable eto
Heddiw, mae ymdrechion llawer o ddatblygwyr wedi'u hanelu at wneud y blockchain yn dechnoleg wirioneddol gyfleus, ac nid yn fom amser ticio mewn papur lapio hardd. Gall sianeli cyflwr, rholio optimistaidd, plasma a darnio ddod yn gyffredin. Rhyw ddiwrnod. Neu efallai y bydd TON yn gohirio'r lansiad eto am chwe mis, a bydd y Grŵp Plasma nesaf yn peidio â bodoli. Gallwn gredu mewn map ffordd arall a darllen papurau gwyn gwych yn y nos, ond yma ac yn awr mae angen i ni wneud rhywbeth gyda'r hyn sydd gennym. Cael cachu wneud.
Mae'r dasg a neilltuwyd i'n tîm yn y prosiect presennol yn edrych fel hyn yn gyffredinol: mae yna lawer o bynciau, gan gyrraedd sawl mil, nad ydyn nhw am adeiladu perthnasoedd ar ymddiriedaeth; mae angen adeiladu ar DLT datrysiad a fydd yn gweithio ar gyfrifiaduron personol arferol heb ofynion perfformiad arbennig ac yn darparu profiad defnyddiwr heb fod yn waeth nag unrhyw systemau cyfrifo canolog. Dylai'r dechnoleg y tu ôl i'r datrysiad leihau'r posibilrwydd o drin data maleisus - a dyna pam mae blockchain yma.
Mae sloganau o bapurau gwyn a chyfryngau yn addo inni y bydd y datblygiad nesaf yn caniatáu miliynau o drafodion yr eiliad. Beth ydyw mewn gwirionedd?
Ar hyn o bryd mae Mainnet Ethereum yn rhedeg ar ~30 tps. Oherwydd hyn yn unig, mae'n anodd ei ganfod fel blockchain sydd mewn unrhyw ffordd yn addas ar gyfer anghenion corfforaethol. Ymhlith atebion a ganiateir, mae meincnodau sy'n dangos 2000 tps yn hysbys () neu 3000 tps (, mae ychydig yn llai yn y cyhoeddiad, ond cofiwch fod y meincnod wedi'i wneud ar yr hen injan consensws). Oedd , na roddodd y canlyniadau gwaethaf, 20000 tps, ond hyd yn hyn astudiaethau academaidd yn unig sy'n aros am eu gweithredu sefydlog. Mae'n annhebygol y bydd corfforaeth sy'n gallu fforddio cynnal adran o ddatblygwyr blockchain yn goddef dangosyddion o'r fath. Ond mae'r broblem nid yn unig mewn trwygyrch, mae yna hefyd hwyrni.
latency
Mae'r oedi o'r eiliad y mae trafodiad yn cael ei gychwyn i'w gymeradwyaeth derfynol gan y system yn dibynnu nid yn unig ar gyflymder y neges sy'n mynd trwy bob cam o ddilysu a archebu, ond hefyd ar baramedrau ffurfio bloc. Hyd yn oed os yw ein blockchain yn caniatáu inni ymrwymo ar 1000000 tps, ond mae'n cymryd 10 munud i ffurfio bloc 488MB, a fydd yn haws i ni?
Gadewch i ni edrych yn agosach ar gylch bywyd trafodiad yn Hyperledger Fabric i ddeall beth sy'n cymryd amser a sut mae'n ymwneud â pharamedrau ffurfio bloc.
cymryd oddi yma:
(1) Mae'r cleient yn ffurfio trafodiad, yn ei anfon at gymheiriaid cymeradwyo, mae'r olaf yn efelychu'r trafodiad (cymhwyswch y newidiadau a wneir gan y cod cadwyn i'r cyflwr presennol, ond peidiwch ag ymrwymo i'r cyfriflyfr) a derbyn RWSet - enwau allweddol, fersiynau a gwerthoedd a gymerwyd o'r casgliad yn CouchDB, (2) mae cymeradwywyr yn anfon RWSet wedi'i lofnodi yn ôl at y cleient, (3) mae'r cleient naill ai'n gwirio am lofnodion yr holl gymheiriaid (cymeradwywyr) angenrheidiol, ac yna'n anfon y trafodiad i'r archeb gwasanaeth, neu ei anfon heb ddilysu (bydd y dilysu yn dal i ddigwydd yn ddiweddarach), mae'r gwasanaeth archebu yn ffurfio bloc ac (4) yn anfon yn ôl at yr holl gymheiriaid, nid dim ond cymeradwywyr; cyfoedion yn gwirio bod y fersiynau o'r bysellau yn y set darllen yn cyd-fynd â'r fersiynau yn y gronfa ddata, llofnodion yr holl gymeradwywyr, ac yn olaf ymrwymo'r bloc.
Ond nid dyna'r cyfan. Y tu ôl i'r geiriau mae “archebwr yn ffurfio bloc” yn gudd nid yn unig archebu trafodion, ond hefyd 3 chais rhwydwaith yn olynol gan yr arweinydd i ddilynwyr ac yn ôl: mae'r arweinydd yn ychwanegu neges at y log, yn anfon at y dilynwyr, mae'r olaf yn ychwanegu at eu log, anfon cadarnhad o ddyblygiad llwyddiannus i'r arweinydd, mae'r arweinydd yn ymrwymo'r neges, yn anfon cadarnhad ymrwymo i ddilynwyr, mae dilynwyr yn ymrwymo. Po leiaf yw maint ac amser y bloc, y mwyaf aml y bydd yn rhaid i'r gwasanaeth archebu sefydlu consensws. Mae gan Hyperledger Fabric ddau baramedr ffurfio bloc: BatchTimeout - amser ffurfio bloc a BatchSize - maint bloc (nifer y trafodion a maint y bloc ei hun mewn bytes). Cyn gynted ag y bydd un o'r paramedrau'n cyrraedd y terfyn, cyhoeddir bloc newydd. Po fwyaf o nodau archeb, yr hiraf y bydd hyn yn ei gymryd. Felly, mae angen i chi gynyddu BatchTimeout a BatchSize. Ond ers i RWSets gael eu fersiwn, po fwyaf y byddwn yn gwneud y bloc, yr uchaf yw'r tebygolrwydd o wrthdaro MVCC. Yn ogystal, gyda chynnydd mewn BatchTimeout, mae UX yn diraddio'n drychinebus. Mae'n ymddangos i mi yn rhesymol ac amlwg y cynllun canlynol ar gyfer datrys y problemau hyn.
Sut i osgoi aros am gwblhau bloc a pheidio â cholli golwg ar statws trafodion
Po hiraf yr amser ffurfio a maint y bloc, yr uchaf yw trwygyrch y blockchain. Nid yw un yn dilyn yn uniongyrchol o'r llall, ond dylid cofio bod sefydlu consensws yn RAFT yn gofyn am dri chais rhwydwaith gan yr arweinydd i'r dilynwyr ac yn ôl. Po fwyaf o nodau trefn, yr hiraf y bydd yn ei gymryd. Po leiaf yw maint ac amser ffurfio blociau, y mwyaf o ryngweithiadau o'r fath. Sut i gynyddu'r amser ffurfio a maint y bloc heb gynyddu amser ymateb y system ar gyfer y defnyddiwr terfynol?
Yn gyntaf, mae angen i chi rywsut ddatrys gwrthdaro MVCC a achosir gan faint bloc mawr, a all gynnwys gwahanol RWSets gyda'r un fersiwn. Yn amlwg, ar ochr y cleient (mewn perthynas â'r rhwydwaith blockchain, mae'n bosibl iawn mai backend yw hwn, ac rwy'n ei olygu) Triniwr gwrthdaro MVCC, a all fod naill ai'n wasanaeth ar wahân neu'n addurnwr rheolaidd dros alwad sy'n cychwyn trafodion gyda rhesymeg ailgynnig.
Gellir gweithredu eto gyda strategaeth esbonyddol, ond yna bydd yr hwyrni yn diraddio'n esbonyddol hefyd. Felly dylech ddefnyddio naill ai ailgynnig ar hap o fewn terfynau bach penodol, neu un cyson. Gyda llygad ar wrthdrawiadau posibl yn yr amrywiad cyntaf.
Y cam nesaf yw gwneud rhyngweithio'r cleient â'r system yn asyncronaidd fel nad yw'n aros am 15, 30, neu 10000000 eiliad, y byddwn yn ei osod fel BatchTimeout. Ond ar yr un pryd, mae angen cadw'r gallu i sicrhau bod y newidiadau a gychwynnir gan y trafodiad yn cael eu cofnodi / heb eu cofnodi yn y blockchain.
Gellir defnyddio cronfa ddata i storio statws trafodion. Yr opsiwn hawsaf yw CouchDB oherwydd ei fod yn hawdd i'w ddefnyddio: mae gan y gronfa ddata UI allan o'r bocs, API REST, a gallwch chi sefydlu atgynhyrchu a darnio ar ei gyfer yn hawdd. Gallwch chi greu casgliad ar wahân yn yr un achos CouchDB y mae Fabric yn ei ddefnyddio i storio ei gyflwr byd-eang. Mae angen inni storio dogfennau o'r math hwn.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Ysgrifennir y ddogfen hon i'r gronfa ddata cyn anfon y trafodiad at gyfoedion, dychwelir yr ID endid i'r defnyddiwr (defnyddir yr un ID fel allwedd) os yw hwn yn weithrediad creu, ac yna'r meysydd Statws, TxID a Gwall yw diweddaru gan fod gwybodaeth berthnasol yn cael ei derbyn gan gymheiriaid.
Yn y cynllun hwn, nid yw'r defnyddiwr yn aros i'r bloc ffurfio o'r diwedd, gan wylio'r olwyn nyddu ar y sgrin am 10 eiliad, mae'n derbyn ymateb ar unwaith gan y system ac yn parhau i weithio.
Fe wnaethom ddewis BoltDB i storio statws trafodion oherwydd bod angen i ni arbed cof ac nid ydym am wastraffu amser ar ryngweithio rhwydwaith â gweinydd cronfa ddata annibynnol, yn enwedig pan fydd y rhyngweithio hwn yn digwydd gan ddefnyddio'r protocol testun plaen. Gyda llaw, p'un a ydych chi'n defnyddio CouchDB i weithredu'r cynllun a ddisgrifir uchod neu dim ond i storio cyflwr y byd, beth bynnag, mae'n gwneud synnwyr i wneud y gorau o'r ffordd y caiff data ei storio yn CouchDB. Yn ddiofyn, yn CouchDB, maint nodau coed-b yw 1279 bytes, sy'n llawer llai na maint y sector ar ddisg, sy'n golygu y bydd angen mwy o fynediad disg corfforol i ddarllen ac ail-gydbwyso'r goeden. Mae'r maint gorau posibl yn cwrdd â'r safon ac mae'n 4 kilobeit. Ar gyfer optimeiddio, mae angen inni osod y paramedr btree_chunk_size hafal i 4096 yn y ffeil ffurfweddu CouchDB. Ar gyfer BoltDB ymyriad llaw o'r fath .
Pwysau cefn: strategaeth glustogi
Ond gall fod llawer o negeseuon. Yn fwy nag y gall y system ei drin, gan rannu adnoddau â dwsin o wasanaethau eraill ar wahân i'r rhai a ddangosir yn y diagram - a dylai hyn i gyd weithio'n ddi-ffael hyd yn oed ar beiriannau y byddai rhedeg Intellij Idea arnynt yn hynod ddiflas.
Mae'r broblem o trwygyrch gwahanol o systemau cyfathrebu, cynhyrchydd a defnyddiwr, yn cael ei datrys mewn gwahanol ffyrdd. Gawn ni weld beth allwn ni ei wneud.
Gollwng: gallwn honni ein bod yn gallu prosesu trafodion X ar y mwyaf mewn T eiliad. Mae pob cais sy'n fwy na'r terfyn hwn yn cael ei ollwng. Mae'n eithaf syml, ond yna gallwch chi anghofio am UX.
Rheoli: rhaid i'r defnyddiwr gael rhywfaint o ryngwyneb trwyddo, yn dibynnu ar y llwyth, gall reoli tps y cynhyrchydd. Ddim yn ddrwg, ond mae'n gosod rhwymedigaeth ar ddatblygwyr y cleient llwyth i weithredu'r rhyngwyneb hwn. I ni, mae hyn yn annerbyniol, gan y bydd y blockchain yn y dyfodol yn cael ei integreiddio i nifer fawr o systemau sy'n bodoli ers tro.
Buffering: yn hytrach na cheisio gwrthsefyll y ffrwd data mewnbwn, gallwn glustogi'r ffrwd hon a'i phrosesu ar y cyflymder gofynnol. Yn amlwg, dyma'r ateb gorau os ydym am ddarparu profiad defnyddiwr da. Gweithredwyd y byffer gan ddefnyddio ciw yn RabbitMQ.
Mae dau weithred newydd wedi'u hychwanegu at y cynllun: (1) ar ôl derbyn cais API, mae neges yn cael ei chiwio gyda'r paramedrau angenrheidiol i alw'r trafodiad, ac mae'r cleient yn derbyn neges bod y system wedi derbyn y trafodiad, ( 2) mae'r backend yn darllen data ar gyflymder a bennir yn y ffurfwedd o'r ciw; yn cychwyn trafodiad ac yn diweddaru'r data yn y storfa statws.
Nawr gallwch chi gynyddu'r amser adeiladu a rhwystro gallu cymaint ag y dymunwch, gan guddio oedi gan y defnyddiwr.
Offer eraill
Ni ddywedwyd dim yma am god cadwyn, oherwydd fel arfer nid oes dim i'w optimeiddio ynddo. Dylai'r cod cadwyn fod mor syml a diogel â phosibl - dyna'r cyfan sy'n ofynnol ohono. Mae'r fframwaith yn ein helpu llawer i ysgrifennu cod cadwyn yn syml ac yn ddiogel. o S7 Techlab a dadansoddwr statig .
Yn ogystal, mae ein tîm yn datblygu set o gyfleustodau i wneud gweithio gyda Fabric yn syml ac yn bleserus: , cyfleustodau ar gyfer (ychwanegu/tynnu sefydliadau, nodau RAFT), cyfleustodau ar gyfer . Os hoffech gyfrannu, croeso.
Casgliad
Mae'r dull hwn yn ei gwneud hi'n hawdd disodli Hyperledger Fabric gyda Quorum, mae rhwydweithiau Ethereum preifat eraill (PoA neu hyd yn oed PoW), yn lleihau trwybwn go iawn yn sylweddol, ond ar yr un pryd yn cynnal UX arferol (ar gyfer defnyddwyr yn y porwr ac o ochr systemau integredig ). Wrth ddisodli Ffabrig gydag Ethereum yn y cynllun, dim ond rhesymeg y gwasanaeth / addurnwr retry fydd angen ei newid o drin gwrthdaro MVCC i gynyddiad nonce atomig ac ail-anfon. Roedd byffro a storio statws yn ei gwneud hi'n bosibl datgysylltu'r amser ymateb o'r amser ffurfio blociau. Nawr gallwch chi ychwanegu miloedd o nodau archeb a pheidiwch â bod ofn bod blociau'n cael eu ffurfio yn rhy aml a llwytho'r gwasanaeth archebu.
Yn gyffredinol, dyma'r cyfan yr oeddwn am ei rannu. Byddaf yn falch os bydd yn helpu rhywun yn eu gwaith.
Ffynhonnell: hab.com