Hei, työskentelen DRD KP -projektin tiimissä (hajautettu tietorekisteri pyöräsarjojen elinkaaren seurantaan). Täällä haluan jakaa tiimimme kokemuksen yrityslohkoketjun kehittämisestä tätä projektia varten teknologian rajoitusten alaisena. Puhun enimmäkseen Hyperledger Fabricista, mutta tässä kuvattu lähestymistapa voidaan ekstrapoloida mihin tahansa sallittuun lohkoketjuun. Tutkimuksemme perimmäisenä tavoitteena on valmistaa yritysten lohkoketjuratkaisuja niin, että lopputuote on miellyttävä käyttää eikä liian vaikea ylläpitää.
Täällä ei tule esiin löytöjä, odottamattomia ratkaisuja, eikä mitään ainutlaatuista kehitystä korosteta (koska minulla ei ole niitä). Haluan vain jakaa vaatimattoman kokemukseni, näyttää, että "se oli mahdollista" ja kenties lukea kommenteista muiden kokemuksia hyvien ja ei niin hyvien päätösten tekemisestä.
Ongelma: Lohkoketjut eivät skaalaudu vielä
Nykyään monien kehittäjien ponnistelut tähtäävät siihen, että lohkoketjusta tulee todella kätevä tekniikka, ei aikapommi kauniissa kääreessä. Tilakanavat, optimistinen rullaus, plasma ja sirpalointi tulevat luultavasti yleisiksi. Jonain päivänä. Tai ehkä TON lykkää jälleen julkaisua kuudella kuukaudella, ja seuraava Plasma Group lakkaa olemasta. Voimme uskoa seuraavaan tiekarttaan ja lukea loistavia valkoisia papereita öisin, mutta tässä ja nyt meidän on tehtävä jotain sille, mitä meillä on. Tee paskaa.
Tiimillemme asetettu tehtävä nykyisessä projektissa näyttää yleisesti tältä: on monia, useita tuhansia tutkittavia, jotka eivät halua rakentaa suhteita luottamukselle; On tarpeen rakentaa DLT:lle ratkaisu, joka toimii tavallisissa tietokoneissa ilman erityisiä suorituskykyvaatimuksia ja tarjoaa käyttökokemuksen, joka ei ole huonompi kuin mikään keskitetty kirjanpitojärjestelmä. Ratkaisun takana olevan teknologian on minimoitava tietojen haitallisen manipuloinnin mahdollisuus – siksi lohkoketju on täällä.
Lehtien ja median iskulauseet lupaavat meille, että seuraava kehitys mahdollistaa miljoonien transaktioiden tekemisen sekunnissa. Mikä se todella on?
Mainnet Ethereum toimii tällä hetkellä ~30 tps:llä. Pelkästään tästä johtuen sitä on vaikea hahmottaa lohkoketjuna millään tavalla yritysten tarpeisiin sopivaksi. Sallittujen ratkaisujen joukossa on vertailuarvoja, jotka näyttävät 2000 tps () tai 3000 tps (, julkaisussa on hieman vähemmän, mutta sinun on otettava huomioon, että vertailu suoritettiin vanhalla konsensusmoottorilla). Oli , joka ei antanut pahimpia tuloksia, 20000 XNUMX tps, mutta toistaiseksi tämä on vain akateemista tutkimusta, joka odottaa sen vakaata toteutusta. On epätodennäköistä, että yritys, jolla on varaa ylläpitää blockchain-kehittäjien osastoa, sietää tällaisia indikaattoreita. Mutta ongelma ei ole vain suorituskyvyssä, vaan myös latenssissa.
Viive
Viive tapahtuman aloittamisesta sen lopulliseen hyväksyntään järjestelmän toimesta ei riipu pelkästään nopeudesta, jolla sanoma kulkee kaikkien vahvistus- ja tilausvaiheiden läpi, vaan myös lohkon muodostusparametreista. Vaikka lohkoketjumme sallii sitoutumisen 1000000 10 488 tps:n nopeudella, mutta vaatii XNUMX minuuttia XNUMX Mt:n lohkon luomiseen, tuleeko siitä meille helpompaa?
Tarkastellaan lähemmin tapahtuman elinkaaria Hyperledger Fabricissa ymmärtääksemme, mihin aika kuluu ja miten se liittyy lohkon luomisen parametreihin.
otettu täältä:
(1) Asiakas luo tapahtuman, lähettää sen hyväksyville vertaisille, jotka simuloivat tapahtumaa (ottavat käyttöön ketjukoodilla tehdyt muutokset nykyiseen tilaan, mutta älä sitoudu pääkirjaan) ja vastaanottavat RWSet - avainten nimet, versiot ja arvot otettu CouchDB:ssä olevasta kokoelmasta, (2) vahvistajat lähettävät allekirjoitetun RWSetin takaisin asiakkaalle, (3) asiakas joko tarkistaa kaikkien tarvittavien vertaiskumppanien (endosaajien) allekirjoitukset ja lähettää sitten tapahtuman tilauspalveluun. , tai lähettää sen ilman vahvistusta (tarkistus tapahtuu edelleen myöhemmin), tilauspalvelu muodostaa lohkon ja (4) lähettää takaisin kaikille vertaisille, ei vain hyväksyjille; vertaiset tarkistavat, että lukujoukon avainversiot vastaavat tietokannan versioita, että kaikilla hyväksyjillä on allekirjoitukset, ja lopuksi sitovat lohkon.
Mutta siinä ei vielä kaikki. Sanat "tilaaja muodostaa lohkon" piilottavat paitsi tapahtumien järjestyksen, myös 3 peräkkäistä verkkopyyntöä johtajalta seuraajille ja takaisin: johtaja lisää viestin lokiin, lähettää sen seuraajille, jälkimmäinen lisää sen. heidän lokiinsa lähettää vahvistuksen onnistuneesta replikaatiosta johtajalle, johtaja sitoo viestin, lähettää sitoumusvahvistuksen seuraajille, seuraajat sitoutuvat. Mitä pienempi lohkon muodostamisen koko ja aika, sitä useammin tilauspalvelun on päästävä yhteisymmärrykseen. Hyperledger Fabricilla on kaksi parametria lohkon muodostamiseen: BatchTimeout - lohkon muodostusaika ja BatchSize - lohkon koko (tapahtumien määrä ja itse lohkon koko tavuina). Heti kun yksi parametreista saavuttaa rajan, uusi lohko vapautetaan. Mitä enemmän tilaussolmuja, sitä kauemmin tämä kestää. Siksi sinun on lisättävä BatchTimeout- ja BatchSize-arvoja. Mutta koska RWSets on versioitu, mitä suuremman lohkon teemme, sitä suurempi on MVCC-ristiriitojen todennäköisyys. Lisäksi BatchTimeoutin kasvaessa UX heikkenee katastrofaalisesti. Seuraava malli näiden ongelmien ratkaisemiseksi vaikuttaa minusta järkevältä ja ilmeiseltä.
Kuinka välttää odottamasta lohkon viimeistelyä ja menettämättä kykyä seurata tapahtuman tilaa
Mitä pidempi muodostusaika ja lohkokoko, sitä suurempi lohkoketjun läpimenokyky. Toinen ei suoraan seuraa toisesta, mutta on muistettava, että konsensuksen saavuttaminen RAFT:ssa vaatii kolme verkkopyyntöä johtajalta seuraajille ja takaisin. Mitä enemmän tilaussolmuja, sitä kauemmin tämä kestää. Mitä pienempi lohkojen muodostumisen koko ja aika, sitä enemmän tällaisia vuorovaikutuksia on. Kuinka pidentää sukupolven aikaa ja lohkon kokoa lisäämättä järjestelmän vasteaikaa loppukäyttäjälle?
Ensinnäkin meidän on jollakin tavalla ratkaistava suuren lohkokoon aiheuttamat MVCC-konfliktit, jotka voivat sisältää erilaisia RWSettejä samalla versiolla. Ilmeisesti asiakaspuolella (suhteessa lohkoketjuverkkoon tämä voisi hyvinkin olla taustajärjestelmä, ja tarkoitan sitä) tarvitset MVCC konfliktien käsittelijä, joka voi olla joko erillinen palvelu tai tavallinen koristelu puhelun yläpuolella, joka käynnistää tapahtuman uudelleenyrityslogiikalla.
Uudelleenyritys voidaan toteuttaa eksponentiaalisella strategialla, mutta silloin latenssi heikkenee yhtä eksponentiaalisesti. Joten sinun tulee käyttää joko satunnaistettua uudelleenyritystä tietyissä pienissä rajoissa tai jatkuvaa. Ensimmäisen vaihtoehdon mahdollisia törmäyksiä silmällä pitäen.
Seuraava askel on tehdä asiakkaan vuorovaikutus järjestelmän kanssa asynkroniseksi, jotta se ei odota 15, 30 tai 10000000 sekuntia, jonka asetamme BatchTimeoutiksi. Mutta samalla on välttämätöntä säilyttää mahdollisuus varmistaa, että tapahtuman käynnistämät muutokset tallennetaan/ei ole tallennettu lohkoketjuun.
Tietokantaa voidaan käyttää tapahtuman tilan tallentamiseen. Yksinkertaisin vaihtoehto on CouchDB sen helppokäyttöisyyden vuoksi: tietokannassa on käyttöliittymä, REST API, ja voit helposti määrittää sen replikoinnin ja jakamisen. Voit yksinkertaisesti luoda erillisen kokoelman samaan CouchDB-instanssiin, joka käyttää Fabricia maailmantilan tallentamiseen. Meidän on säilytettävä tämän tyyppisiä asiakirjoja.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Tämä dokumentti kirjoitetaan tietokantaan ennen tapahtuman lähettämistä vertaisille, entiteettitunnus palautetaan käyttäjälle (samaa tunnusta käytetään avaimena), jos kyseessä on luontitoiminto, ja sitten Status-, TxID- ja Error-kentät päivitetään, kun asiaankuuluvaa tietoa saadaan vertaisilta.
Tässä järjestelmässä käyttäjä ei odota, että lohko lopulta muodostuu, katsomalla pyörivää pyörää näytöllä 10 sekunnin ajan, hän saa välittömän vastauksen järjestelmältä ja jatkaa työskentelyä.
Valitsimme BoltDB:n tapahtumien tilojen tallentamiseen, koska meidän täytyy säästää muistia emmekä halua tuhlata aikaa verkkovuorovaikutukseen erillisen tietokantapalvelimen kanssa, varsinkin kun tämä vuorovaikutus tapahtuu tekstiprotokollalla. Muuten, käytätkö CouchDB:tä yllä kuvatun järjestelmän toteuttamiseen tai yksinkertaisesti maailmantilan tallentamiseen, on joka tapauksessa järkevää optimoida tapa, jolla tiedot tallennetaan CouchDB:hen. Oletusarvoisesti CouchDB:ssä b-puun solmujen koko on 1279 tavua, mikä on paljon pienempi kuin sektorin koko levyllä, mikä tarkoittaa, että sekä puun lukeminen että tasapainottaminen vaatii enemmän fyysistä pääsyä levyyn. Optimaalinen koko vastaa standardia ja on 4 kilotavua. Optimointia varten meidän on asetettava parametri btree_chunk_size on 4096 CouchDB-määritystiedostossa. BoltDB:lle tällainen manuaalinen puuttuminen .
Vastapaine: puskuristrategia
Mutta viestejä voi olla paljon. Enemmän kuin järjestelmä pystyy jakamaan resursseja kymmenien muiden palveluiden kanssa kaaviossa esitettyjen lisäksi - ja kaiken tämän pitäisi toimia moitteettomasti myös koneissa, joissa Intellij Idean käyttäminen olisi erittäin työlästä.
Viestintäjärjestelmien, tuottajan ja kuluttajan, erilaisen kapasiteetin ongelma ratkaistaan eri tavoin. Katsotaan mitä voimme tehdä.
pudottamalla: Voimme väittää, että pystymme käsittelemään enintään X tapahtumaa T sekunnissa. Kaikki tämän rajan ylittävät pyynnöt hylätään. Tämä on melko yksinkertaista, mutta sitten voit unohtaa UX: n.
Hallinta: kuluttajalla täytyy olla jonkinlainen rajapinta, jonka kautta hän voi kuormasta riippuen ohjata tuottajan TPS:ää. Ei paha, mutta se asettaa velvollisuuksia kuorman luovan asiakkaan kehittäjille tämän käyttöliittymän toteuttamiseksi. Tämä on meille mahdotonta hyväksyä, koska lohkoketju integroidaan tulevaisuudessa moniin pitkään olemassa oleviin järjestelmiin.
Puskurointi: Sen sijaan, että yrittäisimme vastustaa syötetietovirtaa, voimme puskuroida tämän virran ja käsitellä sitä vaaditulla nopeudella. Tämä on tietysti paras ratkaisu, jos haluamme tarjota hyvän käyttökokemuksen. Otimme puskurin käyttöön jonon avulla RabbitMQ:ssa.
Kaavaan on lisätty kaksi uutta toimintoa: (1) kun API-pyyntö saapuu, jonoon asetetaan viesti tapahtuman kutsumiseen tarvittavista parametreistä ja asiakas saa viestin, että tapahtuma on hyväksynyt järjestelmä, (2) taustaosa lukee tiedot kokoonpanossa määritetyllä nopeudella jonosta; käynnistää tapahtuman ja päivittää tiedot tilasäilössä.
Nyt voit pidentää muodostusaikaa ja estää kapasiteettia niin paljon kuin haluat piilottaen viiveet käyttäjältä.
Muut työkalut
Tässä ei puhuttu mitään ketjukoodista, koska siinä ei yleensä ole mitään optimoitavaa. Ketjukoodin tulee olla mahdollisimman yksinkertainen ja turvallinen - siinä kaikki, mitä siltä vaaditaan. Kehys auttaa meitä kirjoittamaan ketjukoodia yksinkertaisesti ja turvallisesti S7 Techlabista ja staattisesta analysaattorista .
Lisäksi tiimimme kehittää sarjaa apuohjelmia, jotka tekevät työskentelystä Fabricin kanssa yksinkertaista ja nautinnollista: , apuohjelma (organisaatioiden lisääminen/poistaminen, RAFT-solmut), apuohjelma for . Jos haluat osallistua, olet tervetullut.
Johtopäätös
Tämän lähestymistavan avulla voit helposti korvata Hyperledger Fabricin Quorumilla, muilla yksityisillä Ethereum-verkoilla (PoA tai jopa PoW), vähentää merkittävästi todellista suorituskykyä, mutta samalla ylläpitää normaalia käyttökokemusta (sekä käyttäjille selaimessa että integroiduissa järjestelmissä). Kun korvaat kankaan Ethereumilla järjestelmässä, sinun tarvitsee vain muuttaa uudelleenyrityspalvelun/sisustajan logiikka MVCC-ristiriitojen käsittelystä atomien lisäykseen ja uudelleenlähetykseen. Puskurointi ja tilan tallennus mahdollistivat vasteajan irrottamisen lohkon muodostusajasta. Nyt voit lisätä tuhansia tilaussolmuja ja olla pelkäämättä, että lohkoja muodostuu liian usein ja lataat tilauspalvelun.
Periaatteessa tämä on kaikki, mitä halusin jakaa. Olen iloinen, jos tämä auttaa jotakuta hänen työssään.
Lähde: will.com