Maxim Orlovsky, LNP/BP Standards Association
In dem Papier schlagen wir eine Möglichkeit vor, Bitcoin Layer 1 (Blockchain/Timechain) ohne erforderliche Softfolk zu verbessern. Das Upgrade nutzt Eigenschaften der clientseitigen Validierung, kann schrittweise sein, verfügt
Das Wort Bitcoin hat mehrere Bedeutungen erworben, daher unterscheiden wir sie durch spezifischere Begriffe. Wir verwenden Bitcoin als generisches Regenschirmbegriff, der das System als Ganzes bezeichnet, das mehrere Ebenen (einschließlich einiger Zukunft) und die Gesamtidee des Peer-to-Peer-elektronischen Cash-Systems aus Satoshi Nakamoto umfassen kann. Gleichzeitig verwenden wir BTC , um Bitcoin als digitale Knappheit, Geld und Währung zu bezeichnen. Wir unterscheiden auch den Bitcoin -POW -Konsens (die Regel für die Auswahl des nächsten Blockproduzenten), Nakamoto -Konsens (einschließlich POW -Konsens, das mit kryptoökonomischen Mitteln zur Bestrafung der Bergmanns verbessert wurde), Bitcoin -Blockchain (alternativ Timechain bezeichnet) als spezifische aktuelle Implementierung von Bitcoin -Schicht 1 und Bitcoin -Schicht 1 und Bitcoin-Protokoll (BP) als Satz von Standards, Technologien und Tools zur Arbeit mit Bitcoin-Transaktionen on-Chain (in einer möglichen Schicht 1).
Die ursprüngliche Implementierung von Bitcoin von Satoshi Nakamoto brachte die seltsame Idee, dass jeder Transaktionen für die ganze Welt überprüfen muss. Diese Idee erhielt den Namen Blockchain oder manchmal auch Timechain - was zu einem Euphemismus für ein Hauptbuch mit öffentlichem Zugang wurde. Die Einführung des Hauptbuchs hat zwei Probleme verursacht: Abwesenheit von Skalierbarkeit und schlechte Privatsphäre; Der erste verhindert die Einführung von Akzeptanz- und Networking -Effekten. Der andere widerspricht dem ursprünglichen Cypherpunk -Geist von Bitcoin und stellt ein strategisches Zivilisationsrisiko dar (siehe Unvermeidlichkeit von Cypherpunk für eine ordnungsgemäße Zivilisation und ein Cyphernox -Manifest).
Die Skalierbarkeit und teilweise Datenschutzprobleme wurden später durch die Einführung von Layer -2 -Systemen wie dem Blitznetz und anderen vorgeschlagenen Lösungen behandelt. Unter diesen war am wenigsten fruchtbar die Idee von Sidechain, das die meisten (wenn nicht alle) der ursprünglichen Blockchain -Technologiebeschränkungen erbte und gleichzeitig nur ein Problem mit geringer Programmierbarkeit löste, eine Sandkasten für Experimente und teilweise einige Aspekte der Privatsphäre erstellte. Lightning Network - eine erfolgreichere Layer -2 Unter hohen Basisschichtbedingungen [..]. Andere vorgeschlagene Alternativen wie Arche erfordern mehrere Änderungen der Basisschicht (ein oder zwei Softgiften), was Herausforderungen für den Einsatz darstellt. Schließlich löst keine der vorhandenen oder vorgeschlagenen Lösungen der zweiten Schicht die ursprünglichen Bitcoin-Basisschichtprobleme-und andere von Privatsphäre fokussierte Schicht-1-Lösungen (wie Coinjoin) immer noch nicht vor den Rechtsbehörden und führen zusätzliche BTC-Pilzprobleme ein.
Daher kann der Schluss gezogen werden, dass es sich um den Blockchain-Ansatz basierend auf Ledger-basierten Blockchain zum Aufbau von Schicht 1 handelt, der vollständig überdacht werden muss, um die oben genannten Probleme zu lösen. Die ersten Ideen in diesem Bereich kamen mit Peter Todd in den Jahren 2016 und 2017, als er darauf hinwies, dass die Eigentümer eines Staates (zum Beispiel BTC oder einen anderen staatlichen Vertrag) nur einen Teil der Transaktionsgeschichte überprüfen müssen - den Teil, der ist direkt im Zusammenhang mit ihrem Eigentum - und lassen Sie den Rest weg. Er nannte seine Annäherung an die kundenseitige Validierung . Giacomo Zucco entworfene Protokoll, das mit diesem Ansatz mit dem Namen RGB Vermögenswerte erstellen kann. In meinen früheren Arbeiten bei der LNP/BP Standards Association konnte ich RGB weiter entwickeln und es in das erste generische clientseitig validierte Smart-Contract-System mit reichem Zustand und begrenzten Turing-Complete-Computing umwandeln, was ausreichende Funktionalität bietet, um alles auszuführen, was was ausführt, was ausführen Kann mit Blockchain-basierten intelligenten Verträgen erfolgen-aber ohne das öffentliche Ledger/Blockchain-Speichern von Benutzerdaten, wobei direkt die Eigenschaften des Bitcoin-POW-Konsensprotokolls gegen Doppelausgaben verwendet werden. Dieses System wurde im Laufe von vier Jahren öffentlich entwickelt und im April 2023 veröffentlicht.
In dem aktuellen Vorschlag zeigen wir, dass Bitcoin, wenn sie mit einer staatlich kundenseitig validierten Schicht (wie RGB) versehen sind, ohne die einschränkenden Eigenschaften des öffentlichen Hauptbuchs (Blockchain) auf ein System aufgerüstet werden kann und gleich Es kann auf eine neue skalierbare Nicht-Blockchain-Schicht 1 (Codenamen Prime ) basieren. Diese Schicht wird in der Lage sein, eine theoretisch unbestimmte Anzahl von Transaktionen (mindestens Milliarden pro Minute) zu hosten, da die Speicherung von Zustand, Computer und Validierung auf die clientseitige validierte Schicht oben verschoben werden. Ein solches Design erfordert kein Blitznetz oder andere Skalierbarkeits- und Zahlungsschichten oben und skaliert im Worst-Case-Szenario wie
Das Protokoll verfügt über drei Bereitstellungsoptionen (ohne Berechtigung, Miner-aktiviert und Softfork), wobei die ersten beiden keine weich- (oder harte) Gabel benötigen. Optionen sind unabhängig, können aber auch konsequent eingesetzt werden.
Der Vorschlag bietet Bitcoin als digitales Bargeld mehrere Vorteile:
Einige relative Nachteile des vorgeschlagenen Systems sind:
Das vorgeschlagene System (Codenamed Prime ) besteht aus vier Hauptkomponenten:
Diese Komponenten entsprechen gemeinsam mit einem Blockchain-Hauptbuch. In unserem Design werden sie jedoch abstrahiert und bieten viel mehr Skalierbarkeit und Privatsphäre als jedes andere Blockchain -System.
An seiner Foundation wird Prime einen Zeitstempelservice durchführen und eine Abfolge von Headern erstellen, wobei jeder eine Merkle-Baumwurzel externer clientseitiger validierter Daten verpflichtet hat:
ClassDiagram
Richtung LR
`Header n` <|-` Header n+1`
Klasse `Header n` {
PREV_COMMITMENT
Merkle_root
Merkle_Tree_Height
Zeitstempel
// POW Fields
tlv_extensions
}
Klasse `Header N+1` {
PREV_COMMITMENT
Merkle_root
Merkle_Tree_Height
Zeitstempel
// POW Fields
tlv_extensions
}
Jeder Header ist mit einer optionalen TLV -Erweiterung ausgestattet, die für zukünftige Protokollaufrüstungen verwendet werden kann. Seine Größe ist unabhängig von der Anzahl der Transaktionen, die im Merkle-Baum der clientseitigen validierten Daten enthalten sind, und liegt in der Größenordnung von 100 Bytes (abhängig von den TLV-Daten).
Prime bietet keinen Schutz vor Doppelausgaben. Es wird vom kundenseitigen Teil des Systems bereitgestellt. Die einzigen Teile des Zeitstempelsystems, die validiert werden (Konsensregeln), sind:
Prime Header sind die einzigen Informationen, die öffentlich und global verfügbar sein müssen. Dies kann durch die Verwendung eines verteilten P2P -Netzwerks erreicht werden.
Proof Merkle Trees ( PMT ) sind eine intermediäre und kurzlebige Struktur, die clientseitig validierte Daten mit den Headern verknüpfen. PMTs werden von Bergleuten produziert und der Öffentlichkeit über die gleichen oder andere Mittel wie die Header zur Verfügung gestellt. Im Gegensatz zu den Kopfzeilen müssen sie jedoch nicht bestehen. Jeder Netzwerkbenutzer verfolgt alle neuen PMTs, extrahiert einen Teil der Informationen, die sich auf den Zustand beziehen, den er besitzt, spart es in einen eigenen Vorrat an clientseitig validierten Daten und speichert den Rest des PMT.
Aufgrund der kurzlebigen Natur, des Fehlens von Validierung und nicht erforderlich, um den PMT -Inhalt für den nächsten Header zu kennen, hat die PMT -Größe keinen Einfluss auf die Skalierbarkeit von Systemen. Somit kann das PMT eine (mehrere) Gigabyte -Größe haben und sich zu Milliarden und Milliarden Transaktionen verpflichten.
Die Blätter der Bäume enthalten Zeugen, die ein Verwendungsvertiefungen schließen: einen im nächsten Abschnitt ausführlichen Mechanismus. PMTs werden gemäß dem Multi-Protokoll-Deterministischen Verpflichtungsschema LNPBP-4-Standard erstellt und heute in RGB verwendet, um Verpflichtungen in den Bitcoin-Transaktionen zu veranstalten (sowohl auf Ketten als auch in Offchain-Protokollen wie Blitz). Dies bedeutet, dass jeder einzelne Gebrauchsseal eine einzigartige vordefinierte Platzierung im PMT hat, so dass ein einzelner Merkle-Pfad und ein Blattzeuge ausreichen, um das Schließen oder Fehlen von Schließen eines bestimmten Einzelnutzungsseals in der zu beweisen gegebener Kopfzeile. Benutzer verfolgen eine Reihe ihrer Einzelnutzungswinsen, die noch nicht geschlossen wurden (Analogon von UTXO-Set) und relative Beweise von jedem neu produzierten PMT extrahieren. Wenn ihre Robben nicht geschlossen wurden, sind dies der Beweis für eine Nichtoperation (da der Zeuge ein anderer Einwegseal zeigt, der auf diesem Weg geschlossen wird).
Die Beweise stellen einen zeitabhängigen wachsenden Teil der kundenseitigen validierten Geschichte dar. Speicheranforderungen für einen Knoten werden zeitabhängig als
Wo
Dies ist logarithmisch besser als die Skalierbarkeit eines Blockchain -Knoten
Wo
Wo
Der
Wo
Ein Einsatzversiegelprotokoll verhindert Doppelausgabenangriffe auf das System.
Einwendungsversiegelungen (oder Siegel ) sind eine besondere Form des von Peter Todd vorgeschlagenen kryptografischen Engagements. Der Primitive kann mit anderen Formen kryptografischer Verpflichtungen verglichen werden, zu denen Hash -Funktionen und Zeitstempel gehören:
Weitere Informationen zur Einweg-Versimole sind im LNPBP-8-Standard angegeben. Prime verwendet eine speziell entworfene Form von Einwendungs-Versimassen, die sich von der in vorhandenen Protokollen verwendeten (wie RGB) unterscheidet.
Die Definition eines Einwegseals besteht aus zwei Komponenten:
unique_id : Global-Eingliederung benutzergenerierte Kennung, die aus der Ausgangsnummer von Contract_ID, Vertragsbetrieb und Vertragsbetriebsnummer bestimmt generiert werden kann.spending_conditions_cmt : Engagement (Hash) der Bedingungen, unter denen das Siegel in Zukunft geschlossen werden kann (ähnlich wie scriptPubkey in der Bitcoin -Transaktionsausgabe). Robben sind im kundenseitigen Smart-Vertragssystem (RGB oder RGB-ähnlich) definiert. Jedes Siegel kann einen zugewiesenen Zustand (wie in RGB) haben, z. B. BTC -Gleichgewicht oder andere reichhaltige Daten. Wenn ein Benutzer diesen Status gerne aktualisiert oder sein Eigentum an einen anderen Benutzer überträgt, muss ein staatlicher Übergang vorbereitet werden, wodurch neue Einzelnutzungssegel und den neuen Staat definiert werden. Als nächstes wird ein Zeuge , das das Einzelnutzungsversiegel schließt, konstruiert wird, sich zu den staatlichen Übergangsdaten verpflichtet und das Quellskript bereitstellt, das Engagement der Ausgabenverhältnisse entspricht und Daten, die das Skript/diese Bedingungen erfüllen. Der Vorschlag ist abstrahiert aus einem spezifischen Skriptsystem, das verwendet wird (es kann ein einfacher sein, Aluvm wie in RGB heute und in der Hoffnung nicht EVM :); Die Scripting -Engine kann mit dem Versionsfeld version angegeben werden, sodass neue Engines oder Opcodes im Laufe der Zeit eingeführt werden können (siehe Abschnitt zur Aufrüstungbarkeit):
ClassDiagram
Richtung LR
Definition <|- Zeuge: Unique_id
Klassendefinition {
Unique_id
Ausgeben_Conditions_cmt
}
Klassenzeuge {
Version
Unique_id
STATE_TRANSITION_CMT
Ausgeben_Conditions_Src
Zufriedenheit_Data
}
Der Zeuge wird in der expliziten Form in einem Blatt eines Ptree eingesetzt und den Bergleuten zur Verfügung gestellt, wobei Ptree und Header gebaut werden. Das Blatt muss in den Merkle -Baum in unique_id
Merkle-Pfad zum Blatt Matching unique_id , zusammen mit dem Blattgehalt (Bereitstellung von Zeugendaten) zu ermöglichen zu überprüfen Bedingungen. Bitte beachten Sie, dass die Beweise für jeden einzelnennegativen unique_id von der Definition bis zum Schließen gesammelt werden müssen-eine Voraussetzung, um zu beweisen, dass das Siegel nicht dazwischen geschlossen wurde. Diese Beweise, so lange sie unterschiedliche unique_id zeigen, können die Datenschutzbedingungen für Datenschutz-sensitive Ausgaben aus den Quellcode und Zufriedenheit auslassen und nur ihren Hash bereitstellen. Somit können die historischen Zeugen von fester Größe sein. Wie bereits erwähnt, kann für Skalierbarkeitszwecke die Geschichte der Beweise auch mit Null-Wissen-Proofs komprimiert werden.
Das System erfordert, wenn er mit einer berechtigten Option bereitgestellt wird, ein eigenes Konsensprotokoll. Die Sicherheit des Protokolls ist nicht kritisch, da es mit einem dedizierten Mechanismus, der nachstehend beschrieben wurde, an die Bitcoin -POW -Sicherheit festgelegt ist. Die einzige Voraussetzung für den Konsens ist, zensurresistent zu sein, was ein offener Satz von Bergarbeitern/Validatoren ohne Identitätsdauer bedeutet. Die einzigen zwei Konsensprotokolle, von denen bekannt ist, dass sie diese Eigenschaften erfüllen, sind POW und Ouroboros Crypsinous -Variante von BFT -Konsenskryptoökonomisch durch die Miner -Belohnungen.
Der Zeitstempelservice wird keine Kryptowährung gemildert, und die Bergleute werden ab Tag 1. 1. Eindrucksgebühren belohnt. Ein spezieller Vertrag über die Bergmann-Gebühren wird von RGB oder einem anderen kundenseitigen Smart-Vertragsprotokoll bereitgestellt, das Zahlungsmittel (BTC) festlegt (BTC , Stablecoin oder tokenisierte Zahlungen). Bergleute müssen an einem anonymen P2P -Netzwerk mit freundlicher Genehmigung teilnehmen, in dem Benutzer der Protokolle ihre Zeugen veröffentlichen, die mit Transaktionen ausgestattet sind, die eine Gebühr für "wer auch immer die nächste Header" zahlen. Bergarbeiter enthalten diese Transaktionen in ihre kundenseitige validierte Geschichte und können in Zukunft die verdienten Mittel verwenden.
Im Moment des Systems starten Sie eine dedizierte Ausgabe "Anywish-Can-Spend" mit einer Anzahl der SATs über dem Staub auf der Bitcoin-Blockchain. Die Informationen zu diesem UTXO werden zu einem Teil der Entstehung und dienen als Definition eines Minen-Einwegseals . Ein Bergmann, der die POW-Herausforderung löst, muss diese Ausgabe ausgeben, und innerhalb der Bitcoin-Transaktion verpflichtet sich in der Bitcoin-Transaktion für den abgebauten Header und einen neuen "Anything-Can-Spend" -Ledien-Seal für den nächsten Bergmann. Dies verankert den erstellten Header auf einzigartige Bitcoin-Blockchain, so dass die einzig gültige Zeitstempel-Header-Sequenz diejenige ist, die dieser Abfolge von Einzelnutzungsversiegern folgt.
Wenn eine Partei den aktuellen Miner-Single-Use-Versimgel ausgibt, ohne eine Verpflichtung zu schaffen oder sich ohne ausreichend über ausreichende Kriegsgefangene zu einem Header zu verpflichten, wird ein solches Abschluss als ungültig angesehen. In diesem Fall darf jede Partei eine spezielle Bitcoin-Transaktion erstellen, die öffentlich identifizierbare OP_RETURN Informationen ("Ankündigung") über einen neuen Miner-Ein-Use-Seal ( Protokoll-Reset ) bietet. Nur die erste OP_RETURN -Ankündigung, die mit einem ordnungsgemäßen Verfahren geschlossen ist, wird nach den Konsensregeln als gültig angesehen.
Die Verankerung von POW-Einzelnutzung stellt ein vollständiges Konsensprotokoll dar, das vom System ohne einen anderen zusätzlichen Konsens (POW oder BFT) ausgeführt werden kann. Alternativ kann es mit einem sekundären Konsens mit einer Regel kombiniert werden, sofern die Sicherheit des zweiten Konsensprotokolls niedriger ist als die Bitcoin -POW -Sicherheit, die Bitcoin POW hat Priorität - mit einem automatischen Umschalter zum sekundären Konsens als Hauptkonsens, wenn dieser Der Zustand wird nicht erfüllt.
In diesem Vorschlag befassen wir uns bewusst nicht auf die Frage der P2P-Netzwerkstruktur, da mehrere alternative Systeme auf marktorientierter Weise koexistieren und konkurrieren können. Da die Netzwerkeigenschaften für die Ziele des Projekts wichtig sind, definieren wir stattdessen die allgemeinen Anforderungen für die Auswahl eines P2P -Netzwerks:
Zum aktuellen Moment sehen wir kein Netzwerk, das die oben genannten Eigenschaften begegnet ist. Wir sehen jedoch mehrere Netzwerke mit dem Potenzial für die Entwicklung gegenüber ihnen:
Wir planen, am Renostr-Projekt zu arbeiten, unsere früheren Arbeiten aus dem Storm-Protokoll und die End-to-End-Verschlüsselung im BIP-324-Stil zu verwenden. Andere Projekte können alternative Lösungen aufbauen, und die beste Option sollte vom Markt ausgewählt werden.
Wir sehen drei Schritte - oder Optionen -, wie die vorgeschlagene Lösung in Bitcoin bereitgestellt werden kann. Jeder der Schritte ist optional; Das System kann ohne ein oder zwei von ihnen arbeiten. Jede Option hat jedoch ihre eigenen Kompromisse. Wenn diese Kompromisse als konsequente Schritte eingesetzt werden, werden diese Kompromisse allmählich gelöst.
Das System kann unabhängig vom Bitcoin Timechain aus gestartet werden, wobei der Konsens über einen speziellen Mechanismus auf der Basis von Bitcoin-POW auf der Grundlage von Einweg-Versimassen (die wir im Papier beschreiben) verankert werden können. Dies erfordert keine Änderungen auf der Bergmann -Seite oder auf Bitcoin -Soft/Hardfabks. Mit diesem Setup kann BTC jedoch nur auf eine Weise in das neue System übertragen werden - und die andere Weise erfordert eine Föderation.
Bitcoin -Bergleute beginnen mit der Verarbeitung von Prime -Transaktionen und verpflichtet sich für die Timestamping -Service -Header für die Bitcoin -Blockchain -Coinbase - wie in einem Fall von Fusions -Bergbau. Dies beseitigt die Notwendigkeit eines dedizierten Prime -Konsens, ist jedoch anfällig für Hash -Power -Angriffe, wobei die große Mehrheit der Bergleute vor dem Einsatz dem Protokoll beitreten muss.
Der Vorschlag erfordert jedoch keine spezifische Softfork, wobei die aktuellen Bitcoin -Konsensregeln keine vertrauenslose Möglichkeit bieten können, dass BTC vom neuen Prime -System zurück in die Bitcoin -Blockchain verschoben wird. Obwohl wir dies nicht als Voraussetzung betrachten (Prime hat zu viele Vorteile gegenüber Blockchain, so dass wir Blockchain als langfristig bereits tot sein), kann dies kurzfristig eine Herausforderung für die Einführung der Plattform darstellen.
Es gibt viele verschiedene Vorschläge für Softchenbacken, die eine solche Funktionalität ermöglichen können. Sie fallen in zwei Hauptkategorien:
Die Übernahme eines dieser Vorschläge ermöglicht eine vertrauenslose Peg-Out für BTC auf der Prime-Plattform. Unsere eigenen Vorlieben dauern null-kennerverzinslichen OP-Codes, da sie viele andere Vorteile haben und in Antriebsangaben nicht unvermeidlich sind.
Das Upgrade eines clientseitig-validierten Systems unterscheidet sich stark von Blockchain- oder P2P-Netzwerk (wie Lightning). Dies wird durch die Tatsache verursacht, dass Blockchains Konsensprotokolle sind, die vollständig replizierte Zustandsmaschinen sind, während die clientseitige Validierung eine teilweise Replikation verwendet. Dies erleichtert es einerseits, das System in Teilen zu verbessern, die mit dem unbekannten Zustand zusammenhängen-andererseits aufgrund des Fehlens von nicht kryptoökonomisch gesteuerten Garantien für einen vom Netzwerk bereitgestellten global zugänglichen Zustand Es ist viel schwieriger, ein Upgrade zu koordinieren.
Mit anderen Worten, Client-Side-Validation-Upgrades unterscheiden sich grundlegend von Blockchain-Hardführen und Softfuns und erfordern die Einführung neuer Konzepte und Begriffe.
Wenn etwas ungültig war und nach einem Upgrade gültig ist (wir nennen diese Fast-Forward-Änderung ), sind alle vorhandenen Benutzer nicht betroffen: Sie besitzen und verwalten den gültigen Zustand bereits. Möglicherweise können sie jedoch nicht mit Benutzern interagieren, die ältere Versionen der Software ausführen - ein Problemlösbar, wenn ihre Kollegen ein Upgrade einstellen. Das Upgrade stellt kein Risiko für diese Kollegen dar, da sie keinen der Staaten verwenden, den sie besitzen - und das Upgrade die historischen Daten nicht berührt.
Andererseits ist die Situation, in der etwas gültig war - und nach den neuen Regeln ungültig wurde - sehr unterschiedlich: Benutzer können für immer ihren bestehenden Zustand verlieren und müssen sich einem Upgrade so weit wie möglich widersetzen. Wir nennen solche Upgrades Push-Backs und sehen sie nur als akzeptabel an, wenn ein kritischer Fehler entdeckt wurde: Das Upgrade wird durch den Wunsch von aufrichtigen/nicht schäbigen Benutzern "koordiniert", um Probleme zu vermeiden, die durch den Fehler eingeführt wurden.
Wenn RGB- oder RGB-inspiriertes System als intelligente Vertragskomponente verwendet wird, haben Upgrades dieses Teils eine weitere charakteristische Funktion. RGB isoliert jedes Programm ("Smart Contract") in einen Sandkasten. und ein Vertrag, sobald er ausgestellt wurde, kann nicht auf die neue Version des Protokolls aufgerüstet werden. Die einzige Möglichkeit zum Aufrüsten besteht darin, einen neuen Vertrag abzuschließen, wenn ein Emittent (oder Parteien, an den er von den Emittenten, einschließlich der Community, delegiert wurde) Die Besitzer werden sich darauf einigen.
Als Nebennutzen ermöglicht dieser Ansatz die allmähliche Einführung neuer Funktionen, Anweisungen usw., die in der Blockchain -Welt nicht erreichbar sind: Emittenten der neuen Verträge hängen nicht von den vorherigen Protokollversionen ab und können fortschrittlichere Lösungen ohne zusätzliches Upgrade -Risiko oder vorschlagen Gemeinschaftskoordination.
Der Autor ist Giacomo Zucco dankbar, der die Person war, die sich mit der Idee befasste, die Bitcoin-Abhängigkeit von der eingeschränkten Blockchain zu beseitigen und die Kunden-Seite als Weg nach vorne zu sehen. Mehrere Diskussionen mit ihm und Peter Todd hatten im Laufe der Jahre dazu beigetragen, viele Teile des Systems zu entwerfen. Unter anderem möchte der Autor Alex Kravets, Federico Tenga, Olga Ukolova, erwähnen, die die Gesprächspartner waren, die viele Stunden damit verbrachten, Angelegenheiten im Zusammenhang mit der Kunden-Seite-Validation, Blockchain-Fehler und Blockchain-freien Designs zu diskutieren.
