Halló, ég vinn í teymi DRD KP verkefnisins (dreifð gagnaskrá til að fylgjast með líftíma hjólasetta). Hér vil ég deila reynslu teymisins okkar í að þróa blockchain fyrirtækja fyrir þetta verkefni undir takmörkunum tækninnar. Ég mun að mestu tala um Hyperledger Fabric, en nálgunina sem lýst er hér er hægt að framreikna á hvaða blockchain sem er með leyfi. Lokamarkmið rannsókna okkar er að undirbúa blockchain lausnir fyrir fyrirtæki þannig að endanleg vara sé skemmtileg í notkun og ekki of erfið í viðhaldi.
Það verða engar uppgötvanir, óvæntar lausnir og engin einstök þróun verður dregin fram hér (vegna þess að ég hef engar). Ég vil bara deila hóflegri reynslu minni, sýna að „það var hægt“ og kannski lesa um reynslu annarra af því að taka góðar og ekki svo góðar ákvarðanir í athugasemdunum.
Vandamál: Blockchains stækka ekki ennþá
Í dag miðar viðleitni margra þróunaraðila að því að gera blockchain að virkilega þægilegri tækni en ekki tímasprengju í fallegri umbúðum. Ríkisrásir, bjartsýn uppröðun, plasma og klipping verða sennilega algeng. Einhvern daginn. Eða kannski mun TON aftur fresta sjósetningunni um sex mánuði og næsta Plasma Group hættir að vera til. Við getum trúað á næsta vegakort og lesið ljómandi hvít blöð á kvöldin, en hér og nú þurfum við að gera eitthvað með það sem við höfum. Láttu skítkast.
Verkefnið sem sett er fyrir teymið okkar í núverandi verkefni lítur almennt svona út: það eru mörg viðfangsefni, sem ná til nokkur þúsund, sem vilja ekki byggja upp tengsl á trausti; Nauðsynlegt er að byggja upp lausn á DLT sem virkar á venjulegum tölvum án sérstakra frammistöðukrafna og veitir notendaupplifun ekki verri en öll miðlæg bókhaldskerfi. Tæknin á bak við lausnina verður að lágmarka möguleikann á illgjarnri meðferð gagna - þess vegna er blockchain hér.
Slagorð frá hvítbókum og fjölmiðlum lofa okkur að næsta þróun mun gera okkur kleift að gera milljónir viðskipta á sekúndu. Hvað er það eiginlega?
Mainnet Ethereum er núna í gangi á ~30 tps. Vegna þessa eingöngu er erfitt að skynja það sem blockchain á nokkurn hátt sem hentar þörfum fyrirtækja. Meðal leyfilegra lausna eru viðmið sem sýna 2000 tps () eða 3000 tps (, það er aðeins minna í útgáfunni, en þú þarft að taka með í reikninginn að viðmiðið var framkvæmt á gömlu samstöðuvélinni). Var , sem gaf ekki verstu niðurstöðuna, 20000 tps, en enn sem komið er eru þetta bara fræðilegar rannsóknir, sem bíða stöðugrar framkvæmdar. Það er ólíklegt að fyrirtæki sem hefur efni á að viðhalda deild blockchain forritara muni sætta sig við slíkar vísbendingar. En vandamálið er ekki aðeins afköst, það er líka leynd.
Leyfi
Töfin frá því augnabliki sem viðskipti eru hafin þar til kerfið hefur samþykkt það veltur ekki aðeins á hraðanum sem skilaboðin fara í gegnum öll stig staðfestingar og pöntunar, heldur einnig af breytum blokkamyndunar. Jafnvel þótt blockchain okkar leyfi okkur að skuldbinda sig á 1000000 tps hraða, en krefst 10 mínútur til að búa til 488 MB blokk, verður það auðveldara fyrir okkur?
Við skulum skoða nánar líftíma viðskipta í Hyperledger Fabric til að skilja hvar tímanum er varið og hvernig það tengist breytum blokkaframleiðslu.
tekið héðan:
(1) Viðskiptavinurinn býr til færslu, sendir hana til jafningja sem styðja, þeir síðarnefndu líkja eftir færslunni (beita breytingum sem gerðar eru með keðjukóða á núverandi ástand, en skuldbinda sig ekki til höfuðbókarinnar) og fá RWSet - lykilnöfn, útgáfur og gildi tekið úr safninu í CouchDB, ( 2) umsækjendur senda til baka undirritað RWS sett til viðskiptavinarins, (3) viðskiptavinurinn annað hvort athugar hvort undirskriftir allra nauðsynlegra jafningja (framtaksaðila) séu til staðar og sendir síðan færsluna til pöntunarþjónustunnar , eða sendir það án staðfestingar (athugunin mun samt eiga sér stað síðar), pöntunarþjónustan myndar blokk og ( 4) sendir til baka til allra jafningja, ekki bara áritunaraðila; Jafnaldrar athuga hvort lykilútgáfurnar í lessettinu passi við útgáfurnar í gagnagrunninum, að allir umboðsaðilar séu með undirskriftir og að lokum skuldbinda þeir sig.
En það er ekki allt. Orðin „pantandi myndar blokk“ fela ekki aðeins röð færslur, heldur einnig 3 röð netbeiðna frá leiðtoga til fylgjenda og til baka: leiðtoginn bætir skilaboðum við skrána, sendir þau til fylgjenda, sá síðarnefndi bætir því við í skrána þeirra, sendir staðfestingu á árangursríkri endurtekningu til leiðtogans, leiðtoginn framkvæmir skilaboðin, sendir staðfestingu á skuldbindingu til fylgjenda, fylgjendur skuldbinda sig. Því minni sem stærð og tími blokkamyndunar er, því oftar verður pöntunarþjónustan að koma á samstöðu. Hyperledger Fabric hefur tvær breytur fyrir kubbamyndun: BatchTimeout - blokkarmyndunartími og BatchSize - blokkastærð (fjöldi viðskipta og stærð blokkarinnar sjálfrar í bætum). Um leið og ein af færibreytunum nær mörkunum er nýr blokk sleppt. Því fleiri pöntunarhnútar, því lengri tíma mun þetta taka. Þess vegna þarftu að auka BatchTimeout og BatchSize. En þar sem RWSets eru útgáfur, því stærri sem blokkin sem við gerum, því meiri líkur eru á MVCC árekstrum. Þar að auki, þegar BatchTimeout eykst, versnar UX skelfilega. Eftirfarandi kerfi til að leysa þessi vandamál finnst mér sanngjarnt og augljóst.
Hvernig á að forðast að bíða eftir lokun blokkar og missa ekki getu til að fylgjast með viðskiptastöðu
Því lengri myndunartími og blokkastærð, því meiri afköst blokkarkeðjunnar. Eitt fylgir ekki beint af öðru, en það ber að hafa í huga að til að koma á samstöðu í RAFT þarf þrjár netbeiðnir frá leiðtoga til fylgjenda og til baka. Því fleiri pöntunarhnútar, því lengri tíma mun þetta taka. Því minni sem stærð og tími blokkamyndunar er, því fleiri slík samskipti eru. Hvernig á að auka kynslóðartíma og blokkastærð án þess að auka viðbragðstíma kerfisins fyrir endanotandann?
Í fyrsta lagi þurfum við einhvern veginn að leysa MVCC átök af völdum stórrar blokkastærðar, sem getur innihaldið mismunandi RWSset með sömu útgáfu. Augljóslega, á viðskiptavininum (í tengslum við blockchain netið, þetta gæti vel verið stuðningur, og ég meina það) sem þú þarft MVCC átakastjórnun, sem getur verið annaðhvort aðskilin þjónusta eða venjulegur skreytingamaður fyrir ofan símtalið sem byrjar viðskiptin með endurreynslurökfræði.
Hægt er að útfæra aftur tilraun með veldisvísisstefnu, en þá mun leynd minnka jafn mikið. Þannig að þú ættir að nota annað hvort slembiraðaða endurtilraun innan ákveðinna lítilla marka, eða fasta. Með auga á hugsanlegum árekstrum í fyrsta valmöguleikanum.
Næsta skref er að gera samskipti viðskiptavinarins við kerfið ósamstillt þannig að það bíði ekki í 15, 30 eða 10000000 sekúndur, sem við munum stilla sem BatchTimeout. En á sama tíma er nauðsynlegt að viðhalda getu til að sannreyna að breytingarnar sem viðskiptunum hófst séu / séu ekki skráðar í blockchain.
Hægt er að nota gagnagrunn til að geyma stöðu viðskipta. Einfaldasti kosturinn er CouchDB vegna auðveldrar notkunar hans: gagnagrunnurinn er með notendaviðmóti, REST API og þú getur auðveldlega sett upp afritun og sundrun fyrir hann. Þú getur einfaldlega búið til sérstakt safn í sama CouchDB tilviki sem notar Fabric til að geyma heimsástand sitt. Við þurfum að geyma þessar tegundir skjala.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Þetta skjal er skrifað í gagnagrunninn áður en færslan er send til jafningja, auðkenni einingarinnar er skilað til notanda (sama auðkenni er notað sem lykill) ef þetta er sköpunaraðgerð og þá eru Staða, TxID og Villa reitirnir uppfært eftir því sem viðeigandi upplýsingar berast frá jafnöldrum.
Í þessu kerfi bíður notandinn ekki eftir að blokkin myndist loksins, horfir á snúningshjólið á skjánum í 10 sekúndur, hann fær tafarlaust svar frá kerfinu og heldur áfram að vinna.
Við völdum BoltDB til að geyma viðskiptastöðu vegna þess að við þurfum að spara minni og viljum ekki eyða tíma í netsamskipti við sérstakan gagnagrunnsþjón, sérstaklega þegar þessi samskipti eiga sér stað með því að nota venjuleg textasamskiptareglur. Við the vegur, hvort sem þú notar CouchDB til að innleiða kerfið sem lýst er hér að ofan eða einfaldlega til að geyma heimsástand, í öllum tilvikum er skynsamlegt að fínstilla hvernig gögn eru geymd í CouchDB. Sjálfgefið er, í CouchDB, stærð b-tré hnúta 1279 bæti, sem er mun minni en geirastærðin á disknum, sem þýðir að bæði lestur og endurjafnvægi á trénu mun krefjast meiri líkamlegs aðgangs að disknum. Besta stærðin samsvarar staðlinum og er 4 kílóbæti. Til að hagræða þurfum við að stilla færibreytuna btree_chunk_size jöfn 4096 í CouchDB stillingarskránni. Fyrir BoltDB slík handvirk inngrip .
Bakþrýstingur: biðminni stefna
En það getur verið mikið af skilaboðum. Meira en kerfið ræður við að deila auðlindum með tugi annarra þjónustu fyrir utan þá sem sýndar eru á skýringarmyndinni - og allt þetta ætti að virka gallalaust jafnvel á vélum þar sem að keyra Intellij Idea væri mjög leiðinlegt.
Vandamálið með mismunandi getu samskiptakerfa, framleiðanda og neytenda, er leyst á mismunandi vegu. Við skulum sjá hvað við gætum gert.
Sleppir: Við getum fullyrt að við séum fær um að vinna í mesta lagi X færslur á T sekúndum. Öllum beiðnum sem fara yfir þessi mörk er hent. Þetta er frekar einfalt, en svo geturðu gleymt UX.
Stjórna: neytandinn verður að hafa einhvers konar viðmót þar sem hann getur, eftir álagi, stjórnað TPS framleiðanda. Ekki slæmt, en það leggur skyldur á verktaki viðskiptavinarins sem skapar álagið til að innleiða þetta viðmót. Þetta er óviðunandi fyrir okkur, þar sem blockchain mun í framtíðinni verða samþætt í fjölda kerfa sem eru til lengi.
Buffering: Í stað þess að reyna að standast inntaksgagnastrauminn, getum við biðminni þennan straum og unnið úr honum á tilskildum hraða. Augljóslega er þetta besta lausnin ef við viljum veita góða notendaupplifun. Við útfærðum biðminni með því að nota biðröð í RabbitMQ.
Tveimur nýjum aðgerðum hefur verið bætt við kerfið: (1) eftir að beiðni um API berst eru skilaboð með þeim breytum sem nauðsynlegar eru til að hringja í færslu sett í biðröðina og viðskiptavinurinn fær skilaboð um að viðskiptin hafi verið samþykkt af kerfið, (2) bakendinn les gögnin á þeim hraða sem tilgreindur er í stillingunni úr biðröð; kemur af stað færslu og uppfærir gögn í stöðugeymslunni.
Nú geturðu aukið myndunartímann og lokað fyrir afkastagetu eins mikið og þú vilt, og falið tafir fyrir notandanum.
Önnur verkfæri
Ekkert var sagt hér um keðjukóða, því að jafnaði er ekkert til að hagræða í honum. Keðjukóði ætti að vera eins einfaldur og öruggur og mögulegt er - það er allt sem þarf til hans. Ramminn hjálpar okkur að skrifa keðjukóða á einfaldan og öruggan hátt frá S7 Techlab og stöðugreiningartæki .
Að auki er teymið okkar að þróa sett af tólum til að gera vinnu með Fabric einfalt og skemmtilegt: , tól fyrir (bæta við/fjarlægja stofnanir, RAFT hnúta), gagnsemi fyrir . Ef þú vilt leggja þitt af mörkum ertu velkominn.
Ályktun
Þessi nálgun gerir þér kleift að skipta Hyperledger Fabric auðveldlega út fyrir Quorum, önnur einkanet Ethereum (PoA eða jafnvel PoW), draga verulega úr raunverulegri afköstum, en á sama tíma viðhalda eðlilegri UX (bæði fyrir notendur í vafranum og fyrir samþætt kerfi). Þegar skipt er um efni fyrir Ethereum í kerfinu þarftu aðeins að breyta rökfræði endurreynsluþjónustunnar/skreytingamannsins úr því að vinna úr MVCC átökum yfir í atóma aukningu og endursendingu. Buffun og stöðugeymsla gerði það mögulegt að aftengja viðbragðstímann frá blokkarmyndunartímanum. Nú geturðu bætt við þúsundum pöntunarhnúta og ekki verið hræddur um að kubbar myndast of oft og hlaða pöntunarþjónustunni.
Í grundvallaratriðum, það er allt sem ég vildi deila. Ég mun vera ánægður ef þetta hjálpar einhverjum í starfi.
Heimild: www.habr.com