Încheierea dezbaterii bitcoin vs blockchain

Există vreo valoare într-un blockchain fără criptomonedă?

Dezbaterea durează de ceva vreme, dar luna trecută a cunoscut o creștere serioasă. Întrebarea care se pune este:

Există vreo valoare într-un blockchain fără criptomonedă? Și aceste „registre partajate fără jetoane” pot fi numite blockchain?

Deci am citit articolul lui Bailey, privit Videoclipul lui Tim, citit această postare Nasdaq, a urmat-o pe a lui Richard fiecare cuvântși chiar l-am avut pe al meu dezbatere plină de spirit (vezi comentariile) cu Chris DeRose de la fundația Counterparty. Atât de mult aer cald.

Un lucru pe care Chris îl face bine este să se rezuma la întrebarea: este blockchain-ul o inovație economică sau informatică? Implicația este că, dacă blockchain-urile sunt o inovație pur economică, nu are rost să blockchain-urile fără criptomonede. Așa că permiteți-mi să spun poziția mea la început:

Blockchain-ul bitcoin a fost atât unul economic și o inovație în domeniul informaticii.

Permit aici să includă „inovația”. o nouă combinație de tehnici existente, mai degrabă decât ceva care nu are niciun precedent. Această definiție permite ca World Wide Web să fie considerată o inovație, chiar dacă nu a făcut altceva decât să combine hipertextul cu o răsturnare a unor protocoale de Internet existente. Dacă doriți să adoptați o definiție mai strictă a inovației, fiți invitatul meu, dar veți fi surprinși de cât de puține „inovații” adevărate au rămas. Pentru a parafraza Profesorul, există puține noi sub soare.

Ca să fiu precis, susțin că blockchains-urile fără un token au un scop, dar este un scop diferit comparativ cu blockchain-ul original bitcoin. Crypto-heads râd de blockchain-urile fără token, deoarece nu pot oferi rezistență la cenzură și securitate descentralizată prin dovezi de lucru. Capii Fintech râd de blockchain-urile publice pentru că sunt lente, scumpe și nepotrivite pentru finanțarea tradițională. Ei bine, continuă să râzi toată lumea, pentru că cred că amândoi aveți dreptate.

Voi argumenta că blockchain-urile fără jetoane sunt utile pentru a menține bazele de date descentralizate sincronizate, chiar și într-o singură organizație în care există încredere perfectă. Și apoi vom vedea ce alte caracteristici oferă blockchain-urile, care le fac potrivite pentru crearea consensului tipuri specifice de tranzacții între organizații, unde există doar încredere limitată și imperfectă.

Din păcate, pentru a urma argumentul, va trebui să te uiți cu mine despre modelul tranzacțional bitcoin, controlul concurenței multiversiune a bazei de date (MVCC) și problema rezolvării conflictelor în replicarea bazei de date multi-master. Voi face tot posibilul să rămân la engleză, dar totuși, aceasta este o chestiune tehnică și nu se poate evita.

Modelul tranzacțional al Bitcoin

Modelul tranzacțional bitcoin este simplu, dar puternic. Fiecare tranzacție bitcoin are un set de intrări și un set de ieșiri. Fiecare intrare „cheltuiește” o ieșire a unei tranzacții anterioare. Toate intrarile bitcoin din intrările unei tranzacții sunt distribuite în acea tranzacție și sunt distribuite în ieșirile sale în funcție de cantitățile scrise în interior. În acest fel, tranzacțiile formează un lanț conectat în mai multe sensuri care se termină la tranzacțiile „coinbase” în care sunt creați noi bitcoin.

Bitcoin are o mulțime de reguli suplimentare care sunt aplicate de fiecare nod din rețea:

• Fiecare intrare dintr-o tranzacție trebuie să dovedească că are dreptul de a cheltui ieșirea anterioară la care este conectată. Acest drept este restricționat de condițiile codificate în ieșirea anterioară.
• O tranzacție trebuie să aibă suficient bitcoin total în intrările sale pentru a acoperi totalul scris în ieșirile sale. Singurele excepții sunt tranzacțiile coinbase care creează noi unități ale monedei.
• Fiecare ieșire poate fi cheltuită o singură dată, cu alte cuvinte, poate fi conectată doar la o intrare într-o tranzacție ulterioară.

Din cauza acestei ultime reguli, rețeaua necesită un mecanism pentru a ajunge la un consens cu privire la tranzacțiile valide și asta face blockchain-ul. Specific:

Dacă două tranzacții încearcă să cheltuiască același rezultat, atunci doar una dintre aceste tranzacții va fi acceptată în cele din urmă. Un blockchain acționează ca un mecanism unificat pentru a detecta și a preveni aceste conflicte în rețea.

Blockchain-ul este structurat ca o serie de blocuri legate, în care fiecare bloc conține un set de tranzacții care nu intră în conflict între ele sau cu blocuri anterioare, începând cu primul bloc creat în 2009. În teorie, lanțul ar putea conține un serie de tranzacții individuale, dar prin gruparea tranzacțiilor în blocuri, obținem o serie de eficiențe care fac schema mai practică.

Deci, care este scopul unei criptomonede în toate acestea? Se rezumă la întrebarea cine decide asupra blocurilor care formează lanțul. Bitcoin este descentralizat și nu are nicio autoritate care să poată lua această decizie, așa că trebuie să găsească o altă modalitate de a ajunge la un consens.

Ne-ar putea dori să folosim o abordare democratică, în care nodurile din rețea votează blocurile, iar majoritatea câștigă. Din păcate, așa cum poate demonstra orice sondaj pe internet, democrația reprezentativă nu este posibilă online, din cauza problemei uzurparei identității (cunoscută și ca Atac Sybil). O persoană poate prelua peste un milion de computere și poate decide cum votează, preluând astfel controlul asupra consensului rețelei. Nimeni altcineva nici măcar nu va ști că s-a întâmplat asta.

Pentru a rezolva acest lucru, bitcoin face în mod deliberat dificilă adăugarea unui bloc în lanț, printr-un proces numit „minerit”. Pentru a crea un bloc, trebuie să rezolvați o problemă matematică dificilă, dar fără rost, care necesită mult calcul (și, prin urmare, electricitate și bani). De asemenea, aveți nevoie de puțin noroc, deoarece sunteți în competiție cu mulți alți mineri de blocuri din întreaga lume. Nu puteți avansa mult timp cumpărând un computer de minerit mai puternic, deoarece rețeaua ajustează în mod regulat dificultatea problemei pentru a menține o rată globală constantă de un bloc la 10 minute.

Dacă este atât de dificil și costisitor să creezi un bloc, de ce s-ar deranja cineva? Răspunsul este în recompensa bloc. Minerul de succes al unui bloc controlează tranzacția coinbase care le acordă 25 de bitcoini (această sumă se înjumătățește la fiecare patru ani). Ei pot vinde acești bitcoini pe piața liberă cu 7,000 de dolari (la cursul de astăzi), își pot plăti factura de energie electrică și, sperăm, să obțină un profit. Minerii colectează și un pic suplimentar din taxele atașate tranzacțiilor, deși pentru moment aceste taxe joacă un rol minor.

Deci, bitcoin generează consens prin dovada de lucru, iar esențialul argumentului Bitcoin-heads este următorul: Fără o criptomonedă, nu există nicio modalitate de a stimula mineritul descentralizat de blocuri. Prin urmare, nu există nicio modalitate de a asigura un blockchain deschis împotriva atacurilor de uzurpare a identității. Prin urmare, oricine poate monopoliza consensul rețelei și poate face totul inutil. Nu mă voi certa cu nimic din toate astea.

Controlul concurenței multiversionale

Între timp vreau să vorbesc despre ceva care poate părea complet fără legătură.

O bază de date este un depozit de informații structurate, grupate în entități asemănătoare foilor de calcul numite tabele. Un exemplu simplu de astfel de tabel este o listă de conturi bancare, în care fiecare rând conține un număr de cont împreună cu soldul contului respectiv. Să presupunem că contul tău începe ziua cu un sold de 900 USD. Astăzi este programată o plată ipotecară automată de 750 USD și, de asemenea, trebuie să retrageți 400 USD de la un bancomat. Din păcate, nu aveți o facilitate de descoperire de cont, așa că una dintre aceste operațiuni este configurată să eșueze.

Procesele pentru plățile ipotecare și retragerile de la bancomate rulează pe sisteme separate, ambele accesând această bază de date unică de cont. Să presupunem că fiecare proces funcționează citind soldul contului dvs., verificând că acesta este suficient pentru operațiune, inițiind acea operațiune, verificând finalizarea operațiunii, calculând noul sold și apoi înscriindu-l în baza de date.

Atâta timp cât plata dvs. ipotecară și retragerea la bancomat nu se suprapun, această logică va funcționa bine. Prima operațiune se va executa cu succes, iar a doua se va anula deoarece contul dvs. nu are fonduri suficiente. În funcție de comandă, veți primi un apel telefonic supărat de la bancă sau un mesaj nepoliticos pe ecranul bancomat.

Dar ce se întâmplă dacă cele două procese se întâmplă să înceapă în același timp? În acest caz, fiecare va citi soldul contului dvs. și va considera că este suficient pentru a continua. La finalizarea plății ipotecare, noul dvs. sold va fi calculat la 150 USD și va fi scris în baza de date. Când se finalizează retragerea la ATM, noul dvs. sold de 500 USD va fi scris în mod similar. Una dintre aceste operațiuni de scriere o va depăși pe cealaltă și, în funcție de norocul tău, vei primi un bonus de 750 USD sau 400 USD de la banca ta. Fără îndoială, veți învăța în curând să vă cronometrați vizitele la bancomate pentru ziua creditului ipotecar.

Desigur, acest lucru nu se întâmplă în realitate, din cauza unei tehnologii de baze de date numite controlul concurentei. Controlul concurenței menține datele noastre (în special financiare) sănătoase și securizate și vine în multe forme. Dar toate împărtășesc principiul că operațiunile cu bazele de date sunt grupate în „tranzacții”, care sunt tratate atomic, ceea ce înseamnă că reușesc sau eșuează în ansamblu. Concurența păstrează consistența prin blocarea sau înghețarea părților unei baze de date în timp ce acestea sunt utilizate de o tranzacție, pentru a preveni alte tranzacții să opereze pe aceleași informații într-un mod conflictual.

Dacă nu ar fi nevoie să rulăm tranzacții în paralel, am putea bloca întreaga bază de date pe toată durata fiecărei tranzacții. Cu toate acestea, acest lucru nu este practic în majoritatea aplicațiilor din lumea reală. O schemă bună de control al concurenței permite operațiuni paralele prin blocarea cât mai puține date posibil pentru un timp cât mai scurt posibil. În exemplul de mai sus, numai rândul bazei de date corespunzător contului dvs. ar fi blocat și numai pentru fracțiunea de secundă în care a avut loc o verificare și deducere finală. O tranzacție conflictuală care funcționează în paralel ar trebui pur și simplu să aștepte până când această blocare este eliberată.

O tehnică populară de control al concurenței este numită controlul concurenței în mai multe versiuni, sau MVCC pe scurt. În MVCC, fiecare tranzacție vede un instantaneu consistent al datelor la un anumit moment în timp, chiar dacă o parte din acele date este în curs de a fi actualizată printr-o a doua tranzacție simultană. Acest izolare instantanee proprietatea asigură, de exemplu, că o declarație care arată soldul nostru total în mai multe conturi va fi întotdeauna corectă, chiar dacă unele fonduri sunt în proces de mutare de la un cont la altul. O tranzacție va afecta numai datele văzute de o a doua tranzacție dacă a doua începe după ce toate modificările primei au fost aplicate cu succes.

În culise, MVCC funcționează permițând menținerea simultană a mai multor versiuni ale unui rând, alături de un marcaj temporal care reprezintă data ultimei modificări a fiecărei versiuni. Modificarea unui rând de bază de date în MVCC marchează versiunea curentă a acelui rând pentru ștergere, în timp ce se aplică modificarea unui copie a acelui rând cu un marcaj de timp actualizat. Din perspectiva stratului de stocare al bazei de date, nu există așa ceva ca modificarea unui rând în loc. Fiecare tranzacție știe exact când a început și vede doar versiuni ale rândurilor a căror marcaj de timp este anterioară acelei perioade. Versiunile vechi de rânduri pot fi eliminate din stocare odată ce nu există tranzacții în desfășurare care ar putea avea nevoie să le acceseze.

Esențial pentru scopurile noastre aici, MVCC previne conflictele între operațiunile de scriere. Specific:

Dacă două tranzacții încearcă să ștergă aceeași versiune de rând, atunci doar una dintre aceste tranzacții va fi acceptată în cele din urmă. Controlul concurenței în mai multe versiuni acționează ca un mecanism unificat pentru a detecta și a preveni aceste conflicte în cadrul unei baze de date.

Sună vreun clopote? Mai este o bucată de fundal pe care trebuie să o discutăm.

Replicarea bazei de date multi-master

Acum să vorbim despre replicarea bazei de date, în care o bază de date există în mai multe copii. Există o serie de motive bune pentru a replica o bază de date, cum ar fi:

• Pentru a crește fiabilitatea, astfel încât dacă o copie a bazei de date este pierdută (de exemplu, din cauza unei defecțiuni a discului), putem trece instantaneu la oa doua copie.
• Pentru a crește debitul, dacă volumul operațiunilor depășește capacitatea unui singur server de baze de date.
• Pentru a reduce latența, astfel încât procesele care rulează în biroul din Singapore nu trebuie să aștepte răspunsuri de la o bază de date aflată în Toronto.

Când vine vorba de lectură date din baze de date, replicarea este o tehnică ideală, deoarece toate replicile conțin aceleași informații. Cu toate acestea, lucrurile devin mai lipicioase când vine vorba de operațiuni de scriere, deoarece trebuie să decidem unde sunt efectuate acele operațiuni de scriere și cum sunt transferate în alte copii ale bazei de date.

Cel mai obișnuit răspuns este utilizarea replicării master-slave, în care o singură bază de date („master”) este considerată autoritară. Orice modificări ale datelor sunt efectuate exclusiv pe master și apoi se scurg către toate celelalte baze de date „slave” printr-un jurnal de tranzacții. Acest lucru menține toate copiile bazei de date (mai mult sau mai puțin) instantaneu sincronizate.

Din păcate, dacă operațiunile de scriere sunt frecvente, replicarea master-slave ne readuce imediat la problema pe care replicarea a fost concepută pentru a o rezolva. Baza de date master devine un blocaj în ceea ce privește fiabilitatea, debitul și latența, deoarece fiecare operație de scriere este efectuată numai pe ea.

O strategie mai complexă se numește replicare multi-master, în care scrierile pot fi efectuate pe oricare dintre copiile bazei de date, mai degrabă decât pe un singur master. În acest caz, copiile partajează actualizări între ele într-un mod peer-to-peer pentru a rămâne sincronizate.

Acest lucru sună simplu în teorie, dar replicarea multi-master introduce o nouă problemă, deoarece pot apărea conflicte. Ce se întâmplă dacă două copii ale unei baze de date actualizează același rând în același timp, apoi încearcă să schimbe aceste actualizări între ele? Ambele baze de date vor observa că a avut loc o actualizare conflictuală și trebuie să aplice o strategie agreată pentru rezolvarea acestor conflicte. Și aici devin lucrurile destul de complex – vezi documentele pentru MySQL, SQL Server or Oracol pentru câteva exemple de strategii de rezolvare a conflictelor. (Ignorez replicarea multi-master sincronă sau așa-numita „doritoare”, în care toate replicile trebuie să se angajeze într-o operațiune de scriere înainte ca aceasta să aibă loc, deoarece aceasta se transformă fiecare copie a bazei de date într-un blocaj.)

Așadar, iată unde duce tot acest fundal:

Nu ar fi frumos dacă am fi putut distribui controlul concurenței multiversiune, pentru a preveni conflictele care apar în replicarea multi-master?

Ei bine, da, îmi imaginez că ar fi foarte frumos. Și cred că exact asta fac blockchains-urile.

Blockchains ca MVCC distribuit

Să copiem câteva propoziții pe care le-am scris cu aldine mai sus:

Dacă două tranzacții încearcă petrece la fel producție, atunci doar una dintre aceste tranzacții va fi acceptată în cele din urmă. Un blockchain acţionează ca un mecanism unificat de detectare şi prevenire a acestor conflicte prin rețea.

Dacă două tranzacții încearcă șterge la fel versiunea pe rând, atunci doar una dintre aceste tranzacții va fi acceptată în cele din urmă. Controlul concurenței multiversionale acţionează ca un mecanism unificat de detectare şi prevenire a acestor conflicte în cadrul unei baze de date.

Aceste propoziții sunt identice, cu excepția termenilor aldine. Deci, iată ce voi pretinde:

Un blockchain oferă MVCC distribuit (cu câteva clopote și fluiere suplimentare).

Să dezvoltăm puțin mai departe comparația. Din perspectiva unui nod blockchain, setul actual de ieșiri ale tranzacțiilor bitcoin necheltuite formează o bază de date, în care fiecare rând este o singură ieșire necheltuită. Aceasta este similară cu baza de date de conturi bancare pe care am descris-o mai devreme, cu diferența minoră că soldul fiecărui cont poate fi împărțit pe mai multe rânduri, fiecare dintre acestea fiind marcat cu același număr de cont.

O tranzacție bitcoin cheltuiește una sau mai multe dintre aceste ieșiri și creează una sau mai multe rezultate noi ca rezultat. Aceasta este exact ca o tranzacție de bază de date care șterge una sau mai multe versiuni de rând și creează unul sau mai multe rânduri noi ca rezultat (reamintim că în MVCC nu există așa ceva cum ar fi modificarea unui rând în loc). Blockchain-ul bitcoin asigură că o singură ieșire nu poate fi cheltuită de mai mult de o tranzacție. Acest lucru este echivalent cu asigurarea faptului că o singură versiune de rând nu poate fi ștearsă de mai mult de o tranzacție a bazei de date.

Acum, înainte de a ne lăsa duși de cap, nu pretind că blockchain-urile sunt o tehnologie excelentă de uz general pentru sincronizarea bazelor de date distribuite într-un mediu de încredere. Există o mulțime de alte tehnologii, cum ar fi paxos, Plută și Comitare în două faze care îndeplinesc treaba foarte frumos. Dar cred că blockchain-urile au un punct dulce, care poate fi caracterizat ca aplicații în care:

• Putem accepta o scurtă întârziere între momentul în care o tranzacție este probabil acceptată și momentul în care aceasta este acceptată cu siguranță. (Această întârziere poate fi o chestiune de secunde mai degrabă decât de 10 minute ca în bitcoin.)
• Tranzacțiile conflictuale nu ar trebui să aibă loc niciodată dacă toată lumea este sinceră și sistemele lor funcționează corect.
• Fiecare tranzacție modifică doar câteva rânduri simultan (în caz contrar, tranzacțiile noastre blockchain vor avea un număr greoi de intrări).
• Dimensiunea fiecărui rând de bază de date este destul de mică (din nou, pentru a preveni creșterea dimensiunii tranzacțiilor noastre blockchain).

Toate aceste criterii sunt îndeplinite de aplicațiile financiare. Lumea financiară este deja obișnuită cu întârzierile (de până la 3 zile!) între efectuarea unei tranzacții și decontarea finală a acesteia. În ceea ce privește prevenirea conflictelor, are contracte și reglementări în vigoare pentru a detecta frauda, ​​iar consecințele pot fi grave. Iar cantitatea de date implicată în fiecare tranzacție este destul de mică – gândiți-vă la exemplul de cont bancar de mai sus.

Până acum, tot ce am demonstrat este că blockchain-urile sunt încă un alt mecanism de sincronizare pentru bazele de date distribuite. Mare wow. Lucrurile devin cu adevărat interesante doar dacă luăm în considerare caracteristicile suplimentare pe care le oferă blockchain-urile.

Blockchain-uri dincolo de MVCC

O tranzacție bitcoin face mult mai mult decât doar să indice unele rezultate ale tranzacțiilor anterioare și să creeze unele noi în locul lor. Chiar și cea mai simplă tranzacție cu bitcoin servește la două scopuri suplimentare.

În primul rând, regulile privind tranzacțiile valide conțin o parte din logica aplicației pentru baza noastră de date de cont. Reamintim că cantitatea totală de bitcoin din intrările unei tranzacții trebuie să acopere cantitatea totală din ieșiri. Tradusă în logica aplicației bazei de date, aceasta este o regulă care prevede că tranzacțiile cu baze de date (cu excepția bazelor de monede) nu au voie să crească cantitatea totală de bitcoin din baza de date. Acest tip de constrângere depășește baza de date obișnuită proceduri stocate deoarece nu poate fi ocolită sub nicio formă.

În al doilea rând, amintiți-vă că fiecare tranzacție bitcoin codifică condițiile în care poate fi cheltuită. Pentru ieșirile Bitcoin obișnuite, această condiție se bazează pe criptografia cu cheie publică. O adresă publică este încorporată în „scriptul” de ieșire, astfel încât să poată fi cheltuită numai folosind cheia privată corespunzătoare acelei adrese publice. Dacă considerăm că această ieșire este un rând de bază de date, ceea ce avem este o bază de date cu permisiuni pe rând care se bazează pe criptografia cu cheie publică. În plus, fiecare tranzacție prezintă o dovadă care poate fi auditată public că creatorii ei au avut dreptul de a șterge/modifica rândurile anterioare. Aceasta (cred) este o adevărată noutate în tehnologia bazelor de date.

Și din nou, se întâmplă că ambele aceste funcții sunt incredibil de utile pentru aplicațiile financiare. Ne place faptul că baza noastră de date asigură, la cel mai scăzut nivel posibil, că banii nu pot fi creați din aer. Și ne place să avem o pistă de audit incontestabilă care să demonstreze că fiecare tranzacție a fost autorizată de către deținătorul fondurilor pe care le-a mutat. La fel de discutat în detaliu aici, ne-ar putea plăcea, de asemenea, să efectuăm tranzacții de schimb atomic peer-to-peer sigure (livrare-versus-plată în discuții financiare), fără să știm măcar identitatea contrapărții noastre.

Deci unde este simbolul?

Desigur, nimic din toate acestea nu este o coincidență, deoarece bitcoinul în sine este o aplicație financiară peer-to-peer frumoasă. Cu toate acestea, niciuna dintre caracteristicile de mai sus ale unui blockchain nu depinde deloc de token. Dacă ne modificăm schema „bazei de date” astfel încât fiecare rând să poată reprezenta mai multe active, mai degrabă decât moneda nativă a blockchain-ului, atunci ne putem scăpa de acea monedă în întregime. Acest lucru ne lasă cu un blockchain ca modalitate de a obține consens și securitate într-o aplicație financiară peer-to-peer pentru orice clasă de active.

O singura intrebare mica insa: Cine face mineritul pentru a genera acest consens? În bitcoin, minerii anonimi trebuie să efectueze calcule inutile și costisitoare și sunt stimulați să facă acest lucru prin recompensele bloc (și taxele de tranzacție) exprimate în moneda sau tokenul nativ al blockchain-ului. Avem alte variante?

Se dovedește că o facem. Putem avea o listă închisă de mineri autorizați, care se identifică prin semnarea blocurilor pe care le creează. Reguli despre consensul distribuit (sau „diversitatea minieră”, așa cum o numim noi multicatenari) oferă o modalitate diferită de a preveni controlul minoritar al blockchain-ului, atâta timp cât poți accepta că minerii sunt pre-aprobați. Desigur, pentru bitcoin acest lucru nu este acceptabil, deoarece o parte a scopului este să permită mineritul anonim, deci nu există nicio modalitate de a cenzura tranzacțiile la nivel central. Dar dacă, să zicem, am avea un sistem financiar foarte reglementat, în care modelul bitcoin era inaplicabil, poate am putea accepta până la urmă o listă de mineri preaprobată? Dacă ne-am săturat de ei, și le-am răspândit suficient de bine între instituții și am avea contracte legale cu toate, sunt într-adevăr probabil ca ei să se unească și să submineze rețeaua de care depind, atunci când acest lucru îi va duce la închisoare?

Epilog

Sper că am demonstrat că blockchain-urile fără jetoane au unele aplicații utile, chiar dacă acestea sunt foarte diferite de blockchain-ul bitcoin. Cu toate acestea, rămâne o întrebare:

Sunt aceste sisteme de registru partajat cu permisiuni, fără jetoane, într-adevăr demne de numele „blockchain”?

Răspunsul scurt este: cui îi pasă? Rareori merită să ne certăm despre sensul cuvintelor, pentru că există nici un raspuns corect.

Dar pentru a merge puțin mai adânc, să spunem că accept premisa că blockchain-ul bitcoin este blockchain-ul arhetipal. În acest caz, ceea ce ar trebui să ne întrebăm cu adevărat este:

Sunt aceste registre partajate suficient de asemănătoare cu bitcoin pentru a merita numele „blockchain”?

Viziunea mea personală este aici da. Pentru că au un număr mare de asemănări tehnice, chiar dacă diferă în ceea ce privește modelul de permisiuni și stimulentele economice. Și cel mai important, pentru că ambele generează consens într-o bază de date distribuită prin a lanț de blocuri.

Vă mulțumesc pentru lectură.

Poti urmăriți-mă pe Twitter aici. Vezi si: Livrare versus plată pe un blockchain.

Iată câteva alte articole care merită citite despre acest subiect Piotr Piasecki și Dug Campbell.