Ende der Debatte zwischen Bitcoin und Blockchain

Gibt es einen Wert in einer Blockchain ohne Kryptowährung?

Die Debatte hat eine Weile gedauert, aber im letzten Monat gab es einen ernsthaften Anstieg. Die gestellte Frage lautet:

Gibt es einen Wert in einer Blockchain ohne Kryptowährung? Und können diese „tokenlosen gemeinsamen Hauptbücher“ überhaupt als Blockchains bezeichnet werden?

Also habe ich gelesen Baileys Artikel, schaute Tims Video, Lesen dieser Nasdaq Beitragfolgte Richards alles, Wortund hatte sogar meine eigene gutmütige Debatte (siehe Kommentare) mit Chris DeRose von der Counterparty Foundation. So viel heiße Luft.

Eine Sache, die Chris gut macht, ist, es auf die Frage zu reduzieren: Ist die Blockchain eine wirtschaftliche oder eine Informatikinnovation? Die Implikation ist, dass Blockchains ohne Kryptowährungen keinen Sinn machen, wenn Blockchains eine rein wirtschaftliche Innovation sind. Lassen Sie mich zu Beginn meine Position angeben:

Die Bitcoin-Blockchain war sowohl wirtschaftlich als auch wirtschaftlich und eine Informatik-Innovation.

Ich erlaube hier "Innovation" einzubeziehen eine neue Kombination bestehender Techniken, anstatt etwas, das überhaupt keinen Präzedenzfall hat. Diese Definition ermöglicht es, das World Wide Web als Innovation zu betrachten, obwohl es nur Hypertext mit einer Wendung einiger bestehender Internetprotokolle kombiniert. Wenn Sie eine strengere Definition von Innovation übernehmen möchten, seien Sie mein Gast, aber Sie werden überrascht sein, wie wenige echte „Innovationen“ noch übrig sind. Umschreiben Der LehrerUnter der Sonne gibt es wenig Neues.

Um genau zu sein, mache ich die Behauptung, dass Blockchains ohne Token erfüllen einen Zweck, aber es ist ein anderer Zweck im Vergleich zur ursprünglichen Bitcoin-Blockchain. Kryptoköpfe lachen über tokenfreie Blockchains, weil sie durch Arbeitsnachweise keinen Zensurresistenz und keine dezentrale Sicherheit bieten können. Fintech-Köpfe lachen über öffentliche Blockchains, weil sie langsam, teuer und für traditionelle Finanzen ungeeignet sind. Nun, lacht alle weiter, denn ich glaube, ihr habt beide Recht.

Ich werde argumentieren, dass tokenfreie Blockchains nützlich sind, um dezentrale Datenbanken synchron zu halten. selbst in einer einzigen Organisation, in der vollkommenes Vertrauen besteht. Und dann werden wir sehen, welche anderen Funktionen Blockchains bieten, die sie für die Konsensbildung geeignet machen bestimmte Arten von Transaktionen zwischen Organisationen, in denen nur begrenztes und unvollkommenes Vertrauen besteht.

Um dem Argument zu folgen, müssen Sie sich leider mit mir über das Bitcoin-Transaktionsmodell, die MVCC (Database Multiversion Concurrency Control) und das Problem der Konfliktlösung bei der Multi-Master-Datenbankreplikation informieren. Ich werde mein Bestes tun, um mich an Englisch zu halten, aber das ist immer noch technisches Zeug, und es lässt sich nicht vermeiden.

Das Transaktionsmodell von Bitcoin

Das Bitcoin-Transaktionsmodell ist einfach, aber leistungsstark. Jede Bitcoin-Transaktion hat eine Reihe von Eingaben und eine Reihe von Ausgaben. Jede Eingabe "gibt" eine Ausgabe einer vorherigen Transaktion aus. Das gesamte Bitcoin in den Eingaben einer Transaktion fließt in diese Transaktion und wird entsprechend den darin geschriebenen Mengen auf die Ausgaben verteilt. Auf diese Weise bilden Transaktionen eine in mehrere Richtungen verbundene Kette, die an den „Coinbase“ -Transaktionen endet, bei denen neue Bitcoins erstellt werden.

Bitcoin verfügt über eine Reihe zusätzlicher Regeln, die von jedem Knoten im Netzwerk durchgesetzt werden:

• Jede Eingabe in einer Transaktion muss nachweisen, dass sie das Recht hat, die vorherige Ausgabe auszugeben, mit der sie verbunden ist. Dieses Recht wird durch Bedingungen eingeschränkt, die in der vorherigen Ausgabe codiert sind.
• Eine Transaktion muss genügend Bitcoin in ihren Eingaben enthalten, um die in ihren Ausgaben geschriebene Summe abzudecken. Die einzigen Ausnahmen sind Coinbase-Transaktionen, bei denen neue Währungseinheiten erstellt werden.
• Jeder Ausgang kann nur einmal ausgegeben werden, dh er kann in einer nachfolgenden Transaktion nur mit einem Eingang verbunden werden.

Aufgrund dieser letzten Regel benötigt das Netzwerk einen Mechanismus, um einen Konsens darüber zu erzielen, welche Transaktionen gültig sind, und genau das tut die Blockchain. Speziell:

Wenn zwei Transaktionen versuchen, dieselbe Ausgabe auszugeben, wird letztendlich nur eine dieser Transaktionen akzeptiert. Eine Blockchain fungiert als einheitlicher Mechanismus zum Erkennen und Verhindern dieser Konflikte im gesamten Netzwerk.

Die Blockchain ist als eine Reihe verknüpfter Blöcke strukturiert, in denen jeder Block eine Reihe von Transaktionen enthält, die nicht miteinander oder mit vorherigen Blöcken in Konflikt stehen, beginnend mit dem ersten 2009 erstellten Block. Theoretisch könnte die Kette a enthalten Reihe von einzelnen Transaktionen, aber durch Gruppieren von Transaktionen in Blöcke erzielen wir eine Reihe von Effizienzvorteilen, die das Schema praktischer machen.

Was ist der Zweck einer Kryptowährung in all dem? Es kommt auf die Frage an, wer sich für die Blöcke entscheidet, die die Kette bilden. Bitcoin ist dezentralisiert und hat keine Autorität, die diese Entscheidung treffen kann. Daher muss es einen anderen Weg finden, um zu einem Konsens zu gelangen.

Wir möchten vielleicht einen demokratischen Ansatz verwenden, bei dem Knoten im Netzwerk über Blöcke abstimmen und die Mehrheit gewinnt. Leider ist, wie jede Internetumfrage zeigen kann, eine repräsentative Demokratie online aufgrund des Problems des Identitätswechsels (auch bekannt als a) nicht möglich Sybil-Angriff). Eine Person kann über eine Million Computer übernehmen und entscheiden, wie sie abstimmt, wodurch die Kontrolle über den Netzwerkkonsens übernommen wird. Niemand sonst wird wissen, dass dies geschehen ist.

Um dies zu lösen, macht es Bitcoin absichtlich schwierig, der Kette über einen Prozess namens „Mining“ einen Block hinzuzufügen. Um einen Block zu erstellen, müssen Sie ein schwieriges, aber sinnloses mathematisches Problem lösen, das viel Rechenaufwand (und damit Strom und Geld) erfordert. Sie brauchen auch etwas Glück, da Sie im Wettbewerb mit vielen anderen Blockbergarbeitern auf der ganzen Welt stehen. Mit dem Kauf eines leistungsstärkeren Mining-Computers können Sie nicht lange weiterkommen, da das Netzwerk die Schwierigkeit des Problems regelmäßig anpasst, um eine konstante globale Rate von einem Block pro 10 Minuten aufrechtzuerhalten.

Wenn es so schwierig und kostspielig ist, einen Block zu erstellen, warum sollte sich jemand darum kümmern? Die Antwort ist in der Blockbelohnung. Der erfolgreiche Miner eines Blocks kontrolliert die Coinbase-Transaktion, bei der 25 Bitcoins vergeben werden (diese Summe halbiert sich alle vier Jahre). Sie können diese Bitcoins auf dem freien Markt für 7,000 US-Dollar (zum heutigen Preis) verkaufen, ihre Stromrechnung abbezahlen und hoffentlich etwas Gewinn einstecken. Bergleute erhalten auch ein kleines Extra von Gebühren, die mit Transaktionen verbunden sind, obwohl diese Gebühren vorerst eine untergeordnete Rolle spielen.

Bitcoin erzeugt also einen Konsens durch Arbeitsnachweise, und der Kern des Arguments der Bitcoin-Köpfe ist folgender: Ohne eine Kryptowährung gibt es keine Möglichkeit, Anreize für das dezentrale Mining von Blöcken zu schaffen. Daher gibt es keine Möglichkeit, eine offene Blockchain gegen Identitätswechselangriffe zu sichern. Daher kann jeder den Netzwerkkonsens monopolisieren und das Ganze unbrauchbar machen. Ich werde damit nicht streiten.

Multiversions-Concurrency-Steuerelement

In der Zwischenzeit möchte ich über etwas sprechen, das völlig unabhängig zu sein scheint.

Eine Datenbank ist ein Repository mit strukturierten Informationen, die in Tabellenkalkulationselementen zusammengefasst sind, die als Tabellen bezeichnet werden. Ein einfaches Beispiel für eine solche Tabelle ist eine Liste von Bankkonten, in der jede Zeile eine Kontonummer zusammen mit dem Kontostand dieses Kontos enthält. Angenommen, Ihr Konto beginnt den Tag mit einem Kontostand von 900 USD. Heute ist eine automatische Hypothekenzahlung von 750 USD geplant, und Sie müssen außerdem 400 USD an einem Geldautomaten abheben. Leider haben Sie keine Überziehungsfazilität, sodass eine dieser Operationen fehlschlägt.

Die Prozesse für Hypothekenzahlungen und Geldautomatenabhebungen werden auf separaten Systemen ausgeführt, die beide auf diese Einzelkontodatenbank zugreifen. Angenommen, jeder Prozess funktioniert, indem der Kontostand Ihres Kontos gelesen, überprüft wird, ob er für den Vorgang ausreicht, dieser Vorgang eingeleitet, der Abschluss des Vorgangs überprüft, der neue Kontostand berechnet und schließlich in die Datenbank geschrieben wird.

Solange sich Ihre Hypothekenzahlung und Ihr Geldautomaten nicht überschneiden, funktioniert diese Logik einwandfrei. Die erste Operation wird erfolgreich ausgeführt und die zweite wird abgebrochen, da Ihr Konto nicht über ausreichende Mittel verfügt. Abhängig von der Bestellung erhalten Sie einen verärgerten Anruf von der Bank oder eine unhöfliche Nachricht auf dem Geldautomatenbildschirm.

Aber was passiert, wenn beide Prozesse gleichzeitig starten? In diesem Fall liest jeder den Kontostand Ihres Kontos und hält ihn für ausreichend, um fortzufahren. Wenn die Hypothekenzahlung abgeschlossen ist, wird Ihr neues Guthaben mit 150 USD berechnet und in die Datenbank geschrieben. Wenn die Abhebung am Geldautomaten abgeschlossen ist, wird Ihr neues Guthaben von 500 USD ebenfalls geschrieben. Eine dieser Schreibvorgänge überschreibt die andere und je nach Glück erhalten Sie von Ihrer Bank einen Bonus von 750 oder 400 US-Dollar. Zweifellos werden Sie bald lernen, Ihre Geldautomatenbesuche für den Hypothekentag zu planen.

Natürlich passiert dies in der Realität aufgrund einer Datenbanktechnologie namens nicht Parallelitätskontrolle. Die Parallelitätskontrolle hält unsere Daten (insbesondere finanzielle) gesund und sicher und gibt es in vielen Formen. Alle teilen jedoch das Prinzip, dass Datenbankoperationen in „Transaktionen“ gruppiert werden, die atomar behandelt werden, was bedeutet, dass sie insgesamt erfolgreich sind oder fehlschlagen. Parallelität bewahrt die Konsistenz, indem Teile einer Datenbank gesperrt oder eingefroren werden, während sie von einer Transaktion verwendet werden, um zu verhindern, dass andere Transaktionen auf widersprüchliche Weise mit denselben Informationen arbeiten.

Wenn wir keine Transaktionen parallel ausführen müssten, könnten wir die gesamte Datenbank für die gesamte Dauer jeder einzelnen Transaktion sperren. Dies ist jedoch in den meisten realen Anwendungen nicht praktikabel. Ein gutes Parallelitätskontrollschema ermöglicht parallele Operationen, indem so wenig Daten wie möglich für so kurze Zeit wie möglich gesperrt werden. Im obigen Beispiel wird nur die Ihrem Konto entsprechende Datenbankzeile gesperrt, und zwar nur für den Bruchteil einer Sekunde, in der eine endgültige Überprüfung und ein Abzug stattgefunden haben. Eine parallel ablaufende widersprüchliche Transaktion müsste einfach warten, bis diese Sperre aufgehoben wird.

Eine beliebte Technik zur Steuerung der Parallelität wird genannt Multiversion-Parallelitätskontrolleoder kurz MVCC. In MVCC sieht jede Transaktion zu einem bestimmten Zeitpunkt eine konsistente Momentaufnahme der Daten, selbst wenn ein Teil dieser Daten gerade durch eine zweite gleichzeitige Transaktion aktualisiert wird. Dies Snapshot-Isolation Die Eigenschaft stellt beispielsweise sicher, dass eine Abrechnung, die unseren Gesamtbetrag über mehrere Konten hinweg anzeigt, immer korrekt ist, selbst wenn einige Gelder gerade von einem Konto auf ein anderes wechseln. Eine Transaktion wirkt sich nur dann auf die Daten aus, die von einer zweiten Transaktion angezeigt werden, wenn die zweite beginnt, nachdem alle Änderungen der ersten erfolgreich angewendet wurden.

Hinter den Kulissen ermöglicht MVCC die gleichzeitige Verwaltung mehrerer Versionen einer Zeile sowie eines Zeitstempels, der das Datum der letzten Änderung jeder Version darstellt. Durch Ändern einer Datenbankzeile in MVCC wird die aktuelle Version dieser Zeile zum Löschen markiert, während die Änderung auf a angewendet wird Kopie dieser Zeile mit einem aktualisierten Zeitstempel. Aus Sicht der Speicherebene der Datenbank gibt es keine Möglichkeit, eine vorhandene Zeile zu ändern. Jede Transaktion weiß genau, wann sie gestartet wurde, und sieht nur Versionen von Zeilen, deren Zeitstempel vor dieser Zeit liegt. Alte Versionen von Zeilen können aus dem Speicher entfernt werden, sobald keine laufenden Transaktionen vorhanden sind, auf die möglicherweise zugegriffen werden muss.

Entscheidend für unsere Zwecke ist, dass MVCC Konflikte zwischen Schreibvorgängen verhindert. Speziell:

Wenn zwei Transaktionen versuchen, dieselbe Zeilenversion zu löschen, wird letztendlich nur eine dieser Transaktionen akzeptiert. Die Multiversion-Parallelitätskontrolle fungiert als einheitlicher Mechanismus zum Erkennen und Verhindern dieser Konflikte innerhalb einer Datenbank.

Glocken läuten? Es gibt noch einen Hintergrund, den wir diskutieren müssen.

Multi-Master-Datenbankreplikation

Lassen Sie uns nun über die Datenbankreplikation sprechen, bei der eine Datenbank in mehreren Kopien vorhanden ist. Es gibt eine Reihe guter Gründe, eine Datenbank zu replizieren, z.

• Um die Zuverlässigkeit zu erhöhen, können wir sofort auf eine zweite Kopie umschalten, wenn eine Kopie der Datenbank verloren geht (z. B. aufgrund eines Festplattenfehlers).
• Erhöhung des Durchsatzes, wenn das Betriebsvolumen die Kapazität eines einzelnen Datenbankservers überschreitet.
• Um die Latenz zu verringern, müssen Prozesse, die im Büro in Singapur ausgeführt werden, nicht auf Antworten aus einer Datenbank in Toronto warten.

Wenn es um die Lesen Daten aus Datenbanken, Replikation ist eine ideale Technik, da alle Replikate die gleichen Informationen enthalten. Bei Schreibvorgängen wird es jedoch schwieriger, da wir entscheiden müssen, wo diese Schreibvorgänge ausgeführt werden und wie sie auf andere Kopien der Datenbank übertragen werden.

Die häufigste Antwort ist die Verwendung der Master-Slave-Replikation, bei der eine einzelne Datenbank (der „Master“) als maßgeblich angesehen wird. Alle Änderungen an den Daten werden ausschließlich auf dem Master durchgeführt und gelangen dann über ein Transaktionsprotokoll zu allen anderen „Slave“ -Datenbanken. Dadurch werden alle Datenbankkopien (mehr oder weniger) sofort synchronisiert.

Wenn häufige Schreibvorgänge durchgeführt werden, bringt uns die Master-Slave-Replikation leider direkt zu dem Problem zurück, für das die Replikation entwickelt wurde. Die Master-Datenbank wird zu einem Engpass in Bezug auf Zuverlässigkeit, Durchsatz und Latenz, da jede Schreiboperation nur für sie ausgeführt wird.

Eine komplexere Strategie wird als Multi-Master-Replikation bezeichnet, bei der Schreibvorgänge auf jeder Datenbankkopie und nicht auf einem einzelnen Master ausgeführt werden können. In diesem Fall teilen die Kopien Aktualisierungen Peer-to-Peer miteinander, um synchron zu bleiben.

Theoretisch klingt dies einfach, aber die Multi-Master-Replikation führt zu einem neuen Problem, da Konflikte auftreten können. Was passiert, wenn zwei Kopien einer Datenbank dieselbe Zeile gleichzeitig aktualisieren und dann versuchen, diese Aktualisierungen miteinander auszutauschen? Beide Datenbanken werden feststellen, dass ein widersprüchliches Update stattgefunden hat, und müssen eine vereinbarte Strategie zur Lösung dieser Konflikte anwenden. Und hier wird es ziemlich komplex - siehe die Dokumente für MySQL, SQL Server or Oracle für einige Beispiele für Konfliktlösungsstrategien. (Ich ignoriere die synchrone oder sogenannte "eifrige" Multi-Master-Replikation, bei der alle Replikate eine Schreiboperation ausführen müssen, bevor sie stattfinden kann, da sich dies ändert alles, Kopie der Datenbank in einen Engpass.)

Hier führt also all dieser Hintergrund hin:

Wäre es nicht schön, wenn wir die Kontrolle der Parallelität mehrerer Multiversionen verteilt hätten, um Konflikte bei der Multi-Master-Replikation zu vermeiden?

Ja, ich stelle mir vor, das wäre wirklich sehr schön. Und ich glaube, genau das tun Blockchains.

Blockchains als verteiltes MVCC

Lassen Sie uns ein paar Sätze aufschreiben, die ich oben fett geschrieben habe:

Wenn zwei Transaktionen versuchen verbringen gleiche Figure Möglichkeiten für das Ausgangssignal:Dann wird letztendlich nur eine dieser Transaktionen akzeptiert. Eine Blockchain fungiert als einheitlicher Mechanismus zur Erkennung und Verhinderung dieser Konflikte über das Netzwerk.

Wenn zwei Transaktionen versuchen löschen gleiche Figure ZeilenversionDann wird letztendlich nur eine dieser Transaktionen akzeptiert. Multiversions-Concurrency-Steuerelement fungiert als einheitlicher Mechanismus zur Erkennung und Verhinderung dieser Konflikte innerhalb einer Datenbank.

Diese Sätze sind bis auf die fett gedruckten Begriffe identisch. Also hier ist, was ich behaupten werde:

Eine Blockchain bietet verteiltes MVCC (mit ein paar zusätzlichen Schnickschnack).

Lassen Sie uns den Vergleich etwas weiter ausarbeiten. Aus der Sicht eines Blockchain-Knotens bildet der aktuelle Satz nicht ausgegebener Bitcoin-Transaktionsausgaben eine Datenbank, in der jede Zeile eine einzelne nicht ausgegebene Ausgabe ist. Dies ähnelt der zuvor beschriebenen Datenbank mit Bankkonten, mit dem geringfügigen Unterschied, dass der Kontostand jedes Kontos auf mehrere Zeilen aufgeteilt werden kann, von denen jede mit derselben Kontonummer gekennzeichnet ist.

Eine Bitcoin-Transaktion gibt eine oder mehrere dieser Ausgaben aus und erstellt dadurch eine oder mehrere neue Ausgaben. Dies ist genau wie bei einer Datenbanktransaktion, bei der eine oder mehrere Zeilenversionen gelöscht und eine oder mehrere neue Zeilen erstellt werden (denken Sie daran, dass in MVCC keine Zeile geändert werden kann). Die Bitcoin-Blockchain stellt sicher, dass eine einzelne Ausgabe nicht von mehr als einer Transaktion ausgegeben werden kann. Dies entspricht der Sicherstellung, dass eine einzelne Zeilenversion nicht von mehr als einer Datenbanktransaktion gelöscht werden kann.

Bevor wir uns hinreißen lassen, behaupte ich nicht, dass Blockchains eine großartige Allzwecktechnologie für die verteilte Datenbanksynchronisation in einer vollständig vertrauenswürdigen Umgebung sind. Es gibt viele andere Technologien wie Paxos, Raft und Zwei-Phasen-Commit die den Job sehr gut ausführen. Aber ich glaube, dass Blockchains einen Sweet Spot haben, der als Anwendungen charakterisiert werden kann, bei denen:

• Wir können eine kurze Verzögerung zwischen der Annahme einer Transaktion und der endgültigen Annahme akzeptieren. (Diese Verzögerung kann eine Frage von Sekunden sein, anstatt wie bei Bitcoin 10 Minuten.)
• Widersprüchliche Transaktionen sollten niemals stattfinden, wenn alle ehrlich sind und ihre Systeme ordnungsgemäß funktionieren.
• Jede Transaktion ändert nur wenige Zeilen gleichzeitig (andernfalls haben unsere Blockchain-Transaktionen eine unhandliche Anzahl von Eingaben).
• Die Größe jeder Datenbankzeile ist relativ klein (um zu verhindern, dass unsere Blockchain-Transaktionen immer größer werden).

Alle diese Kriterien werden von Finanzanträgen erfüllt. Die Finanzwelt ist bereits an Verzögerungen (von bis zu 3 Tagen!) Zwischen der Durchführung einer Transaktion und ihrer endgültigen Abwicklung gewöhnt. In Bezug auf die Verhinderung von Konflikten gibt es Verträge und Vorschriften zur Aufdeckung von Betrug, und die Folgen können schwerwiegend sein. Und die Datenmenge, die mit jeder Transaktion verbunden ist, ist ziemlich gering - denken Sie an das obige Beispiel für ein Bankkonto.

Bisher habe ich nur gezeigt, dass Blockchains ein weiterer Synchronisationsmechanismus für verteilte Datenbanken sind. Großes Wow. Wirklich interessant wird es nur, wenn wir die zusätzlichen Funktionen berücksichtigen, die Blockchains bieten.

Blockchains jenseits von MVCC

Eine Bitcoin-Transaktion kann viel mehr als nur auf einige frühere Transaktionsausgaben verweisen und an ihrer Stelle neue erstellen. Selbst die einfachste Bitcoin-Transaktion dient zwei zusätzlichen Zwecken.

Erstens enthalten die Regeln für gültige Transaktionen einen Teil der Anwendungslogik für unsere Kontodatenbank. Denken Sie daran, dass die Gesamtmenge an Bitcoin in den Eingaben einer Transaktion die Gesamtmenge in den Ausgaben abdecken muss. In die Datenbankanwendungslogik übersetzt, ist dies eine Regel, die besagt, dass Datenbanktransaktionen (mit Ausnahme von Coinbases) die Gesamtmenge an Bitcoin in der Datenbank nicht erhöhen dürfen. Diese Art von Einschränkung geht über die reguläre Datenbank hinaus Gespeicherte Prozeduren weil es unter keinen Umständen umgangen werden kann.

Denken Sie zweitens daran, dass jede Bitcoin-Transaktionsausgabe die Bedingungen codiert, unter denen sie ausgegeben werden kann. Bei regulären Bitcoin-Ausgaben basiert diese Bedingung auf der Kryptografie mit öffentlichen Schlüsseln. Eine öffentliche Adresse ist in das Ausgabeskript eingebettet, sodass sie nur mit dem privaten Schlüssel ausgegeben werden kann, der dieser öffentlichen Adresse entspricht. Wenn wir diese Ausgabe als Datenbankzeile betrachten, verfügen wir über eine Datenbank mit zeilenweisen Berechtigungen, die auf der Kryptografie mit öffentlichen Schlüsseln basieren. Darüber hinaus enthält jede Transaktion einen öffentlich überprüfbaren Beweis dafür, dass der / die Ersteller das Recht hatte, seine vorherigen Zeilen zu löschen / zu ändern. Dies ist (glaube ich) eine echte Neuheit in der Datenbanktechnologie.

Und wieder ist es einfach so, dass diese beiden Funktionen für Finanzanwendungen unglaublich nützlich sind. Wir mögen die Tatsache, dass unsere Datenbank auf der niedrigstmöglichen Ebene sicherstellt, dass Geld nicht aus dem Nichts geschaffen werden kann. Und wir freuen uns über einen unbestreitbaren Prüfpfad, der zeigt, dass jede Transaktion vom Inhaber der von ihm bewegten Mittel genehmigt wurde. Wie hier ausführlich besprochenMöglicherweise möchten wir auch sichere atomare Peer-to-Peer-Austauschtransaktionen durchführen (Lieferung versus Zahlung im Finanzgespräch), ohne die Identität unserer Gegenpartei zu kennen.

Wo ist der Token?

Natürlich ist nichts davon ein Zufall, denn Bitcoin selbst ist eine schöne Peer-to-Peer-Finanzanwendung. Dennoch hängt keines der oben genannten Merkmale einer Blockchain überhaupt vom Token ab. Wenn wir unser "Datenbank" -Schema so ändern, dass jede Zeile mehrere Assets darstellen kann und nicht die native Währung der Blockchain, können wir diese Währung vollständig entfernen. Dies lässt uns eine Blockchain als Möglichkeit, Konsens und Sicherheit in einer Peer-to-Peer-Finanzanwendung für zu erreichen jede Klasse von Vermögenswerten.

Nur eine kleine Frage: Wer macht den Bergbau, um diesen Konsens zu generieren? Bei Bitcoin müssen anonyme Bergleute teure, nutzlose Berechnungen durchführen und werden durch die Blockbelohnungen (und Transaktionsgebühren), die auf die Heimatwährung oder den Token der Blockchain lauten, dazu angeregt. Haben wir noch andere Möglichkeiten?

Es stellt sich heraus, dass wir es tun. Wir können eine geschlossene Liste zugelassener Bergleute haben, die sich durch Signieren der von ihnen erstellten Blöcke identifizieren. Regeln über verteilten Konsens (oder „Bergbauvielfalt“, wie wir es nennen Multichain) eine andere Möglichkeit bieten, die Kontrolle von Minderheiten über die Blockchain zu verhindern, solange Sie akzeptieren können, dass Bergleute vorab zugelassen sind. Für Bitcoin ist dies natürlich nicht akzeptabel, da ein Teil des Punktes darin besteht, anonymes Mining zuzulassen, sodass es nicht möglich ist, Transaktionen zentral zu zensieren. Aber wenn wir zum Beispiel ein stark reguliertes Finanzsystem hätten, in dem das Bitcoin-Modell nicht anwendbar wäre, könnten wir vielleicht doch eine vorab genehmigte Liste von Bergleuten akzeptieren? Wenn wir genug von ihnen haben und sie gut genug zwischen den Institutionen verteilen und rechtliche Verträge mit allen haben, werden sie dann wirklich das Netzwerk, von dem sie abhängig sind, zusammenschließen und untergraben, wenn sie dies tun, werden sie dann ins Gefängnis kommen?

Epilog

Ich hoffe, ich habe gezeigt, dass Blockchains ohne Token einige nützliche Anwendungen haben, auch wenn diese sich stark von der Bitcoin-Blockchain unterscheiden. Dennoch bleibt eine Frage offen:

Sind diese genehmigten, tokenfreien Shared-Ledger-Systeme wirklich den Namen "Blockchain" wert?

Die kurze Antwort lautet: Wen interessiert das? Es lohnt sich selten, über die Bedeutung von Wörtern zu streiten, weil es sie gibt keine richtige Antwort.

Aber um etwas tiefer zu gehen, nehmen wir an, ich akzeptiere die Prämisse, dass die Bitcoin-Blockchain die archetypische Blockchain ist. In diesem Fall sollten wir wirklich fragen:

Sind diese gemeinsam genutzten Hauptbücher Bitcoin ähnlich genug, um den Namen "Blockchain" zu verdienen?

Meine persönliche Meinung hier ist ja. Weil sie eine Vielzahl technischer Ähnlichkeiten aufweisen, auch wenn sie sich im Berechtigungsmodell und in den wirtschaftlichen Anreizen unterscheiden. Und vor allem, weil beide über a einen Konsens in einer verteilten Datenbank generieren Kette von Blöcken.

Vielen Dank für das Lesen.

Du kannst dich folge mir hier auf Twitter. Siehe auch: Lieferung versus Zahlung in einer Blockchain.

Hier sind ein paar andere lesenswerte Stücke zu diesem Thema von Piotr Piasecki und Campbell ausgegraben.