esittely

Blockchain on tekniikka, joka ohjaa kaikkia kryptovaluuttoja. Jokaisessa niistä joukko validointisolmuja on vastuussa kaikkien tapahtumien validoinnista. Validoijien oletetaan olevan järkeviä ja omaehtoisia, eli he ovat kiinnostuneita vain ansaitsemaan mahdollisimman paljon rahaa itselleen. Tällaisten olettamusten perusteella oletetaan yleensä, että vaadittu enemmistö validoijista olisi samaa mieltä tapahtumien järjestyksestä, joita lohkoketjussa on koskaan tapahtunut.

Tällaiset lohkoketjun validointisolmut ovat kuitenkin yleensä kalliita niiden tarvitseman levytilan koon mukaan. Vanhin ja suosituin kryptovaluutta, esimerkiksi Bitcoin, tarvitsee noin 200 Gt levytilaa koko tapahtumalokin tallentamiseen. Tämä edellyttää nopeaa yhteyttä ja paljon aikaa jopa louhinnan tai validoinnin aloittamiseen. Tämä on ongelma, joka sai tutkijat ehdottamaan sharding-ratkaisua eli vain osan lokin tallentamista kuhunkin solmuun, mutta koko lokin tallentamista kokonaisuutena. Jakamiseen liittyy omat haasteensa tapahtumien validoinnissa.

Mutta onko järkevää, että solmu tallentaa tapahtumalokia alkaen koko matkan syntylohkosta? Tämä on tärkeä kysymys, johon on vastattava ennen tällaisten ratkaisujen luomista.

Saatat myös olla kiinnostunut: Blockchain-viittausarkkitehtuuri

Ymmärtääksemme, onko koko tapahtumalokin tallentaminen mahdollista/tarpeellista, otamme huomioon seuraavat seikat:

1. Onko tapahtumien vahvistamiseksi tarpeen tallentaa koko tapahtumaloki?
2. Onko tapahtumalokin tallentaminen turvallisempaa kuin sen tallentamatta jättäminen?
3. Onko mahdollista kannustaa validointisolmuja tallentamaan loki?

Käsittelemme näitä kohtia artikkelin loppuosassa.

Onko koko tapahtumalokin tallentaminen välttämätöntä tapahtumien vahvistamiseksi?

Tapahtuman vahvistamiseksi solmu tarvitsee vain tietää tämän lohkoketjun tilan juuri ennen tapahtumaa. On yhdentekevää, miten tämä tila saavutettiin. Joten riittää, että tallennat tilan jokaisen lohkon jälkeen. Itse asiassa voimme mennä vielä pidemmälle - koska lohkot, jotka on louhittu kauan ennen nykyistä aikaa, tuskin koskaan perutaan, on turvallista poistaa kaikki aiemmat lohkot.

Luonnollinen kysymys, joka tulee mieleemme, on, vaarantaisiko se jotenkin lohkoketjun turvallisuuden, eli saako se jotenkin lohkoketjun hyväksymään tapahtuman, joka ei ole oikea lohkoketjun nykytilan perusteella? Vastataksemme tähän kysymykseen siirrymme seuraavaan osaan.

Onko tapahtumalokin tallentaminen turvallisempaa kuin sen tallentamatta jättäminen?

Kun ajattelemme sitä, meidän on ajateltava koko tapahtumien turvallisuutta eikä vain lohkoketjun osaa. Useimmissa tapahtumissa on kaksi osaa – maksu lohkoketjussa ja jonkin arvokkaan vastaanottaminen vastineeksi. Tapahtuman toista osaa ei tallenneta lohkoketjuun. Tämä tarkoittaa sitä, että myyjä, joka myy tuotteen tai palvelun vastineeksi jostakin kryptovaluutasta, luottaa siihen, että estoketju ei palauta tapahtumaa tuotteen tai palvelun toimittamisen jälkeen. Tämä puolestaan ​​tarkoittaa, että on oltava kohtuullinen aika, jonka jälkeen tapahtumasta tulee muuttua täysin muuttumattomaksi, mikä edellyttää, että myös lohko, johon se sisältyy, on muuttumaton. 

Toisin sanoen tarvitsemme tapahtuman ja lohkon lopullisuuden. Kun lohko on viimeistelty jossain muodossa, on hyvä unohtaa mitä tapahtui ennen sitä ja jatkaa yksinkertaisesti kuin lohko olisi syntylohko. Tämä tarkoittaa yleensä sitä, että tapahtumahistoria on tallennettava vain lyhyen ajan. Bitcoinin tapauksessa ihmiset yleensä olettavat, että lohko on lähes viimeistelty tunnin kuluttua, joten on järkevää poistaa kaikki historia ennen sitä. Tämä tarkoittaa, että Bitcoinin tapauksessa validoija tarvitsee vain UTXO -luettelon muutaman viimeisen lohkon lopussa.

Nyt käännymme kohti viimeistä kohtaa.

Onko mahdollista kannustaa validointisolmuja tallentamaan loki?

Kuten aiemmin todettiin, validaattoreiden oletetaan olevan itsekkäitä ja rationaalisia. Tämä tarkoittaa, että heille on maksettava tai palkittava kaikesta tekemisestä. Koska validoijat maksavat vain kryptovaluutassa lohkojen louhimisesta kaikissa julkisissa lohkoketjuissa, se on ainoa asia, jonka heidän pitäisi tehdä. Olemme myös nähneet, että tietojen tallentaminen ei ole tarpeen validointityön suorittamiseksi. Siksi millään validaattorilla ei ole kannustinta tallentaa kaikkia tapahtumalokeja niiden synnystä alkaen. 

Jos todella haluamme, että järkevä validoija tallentaa tapahtumien koko historian, meidän on kannustettava validoijia siihen riittävästi. Voimme vaatia todisteita kaikkien lohkon tapahtumien tallentamisesta, jotta se katsotaan päteväksi. Onko mahdollista tehdä se? Kyllä, jos muutamme työtodistuksen konsensusprotokollaa seuraavasti:

1. Olkoon ehdotettu lohko B: ksi ja vastaava työtodistus p. Tämä tarkoittaa, että p on nonce sellainen, että hash (B || p) <kynnys.
2. Olkoon tapahtumia ennen kyseistä lohkoa N.
3. Olkoon h = hash(B||hash(p)), missä || tarkoittaa ketjutusta.
4. Laske loppuosa r, kun h jaetaan N. satunnainen otos luonnollisten numeroiden joukosta, joka on pienempi kuin N.
5. Olkoon tapahtuma järjestysnumerolla r tr. Tapahtumat indeksoidaan 0: sta N-1: een.
6. Lohkoehdotuksen on nyt oltava (B || p || tr), jotta sitä voidaan pitää pätevänä.

On helppo nähdä, että jos validoija ei tallenna kaikkia tapahtumalokeja, se tarvitsee enemmän vaivaa kelvollisten lohkojen luomiseksi, koska sen on heitettävä pois kaikki todisteet ja aloitettava alusta, jos vastaavaa tapahtumaa ei ole sen tallentamia. Tarkemmin sanottuna, jos validaattori tallentaa murto-osan f kaikesta historiasta, sen täytyy heittää pois työtodistus keskimäärin 1/f kertaa, mikä vähentää merkittävästi sen keskimääräistä kaivospalkkiota samasta prosessointitehon määrästä. 

Siksi on tehokkainta, että jokainen validoija tallentaa yksinkertaisesti kaikki tapahtumat geneesilohosta. Mutta tällaista järjestelmää ei tällä hetkellä käytetä, joten validaattorit tekevät todella sosiaalista palvelua tallentamalla edelleen kaikki tapahtumat. Turvallisuudesta käytävän keskustelumme perusteella on kuitenkin selvää, että tällainen muutos voi olla aivan tarpeeton.

Toinen ongelma on, että kun uusi validoija liittyy, sen on ladattava koko tapahtumaloki vertaisilta. Vertaisryhmiä ei kuitenkaan kannusteta toimittamaan näitä tietoja uudelle vertaisryhmälle. He yksinkertaisesti lisäävät kilpailevaa kaivosvoimaa ja rasittavat samalla omaa kaistanleveyttään tietojen lähettämiseksi. Vähintään mitä voimme tehdä, on vapauttaa heidät joutumasta lähettämään koko tapahtumahistoria.

Yhteenveto

Voimme nähdä, että on mahdollista velvoittaa tallentamaan koko tapahtumahistoria, jos päätämme suunnitella lohkoketjun tällä tavalla. Se näyttää kuitenkin melko tarpeettomalta ja hankalalta. Se voi jopa tarjota enemmän motivaatiota nykyisille kaivostyöläisille toimittaa tarvittavat tiedot uusille liittijöille. Olemme myös nähneet, että tapahtumahistorian tallentamisesta ei ole hyötyä lohkoketjun turvallisuuden kannalta, joten emme ehkä halua tehdä niin.

Kirjallisuutta

Opas Blockchainin muuttumattomuuteen ja haasteisiin

11 parasta työkalua lohkoketjun kehittämiseen