„Theoretisch könnte eine Blockchain durch UTXO-Commitments lernen, zu vergessen …“
Der Bitcoin-Cash-Entwickler Tomas van der Wansem hat vor kurzem ein UTXO-Commitment ins Testnet gestellt. Wir reden mit ihm über die als Meilenstein der Skalierbarkeit diskutierte Lösung.
Tomas van der Wansem ist Entwickler von Bitcrust, einer noch nicht fertigen Implementierung von Bitcoin in der Programmiersprache Rust. Tomas ist einer der aktivsten Entwickler von Bitcoin Cash (BCH), und er scheint ein umtriebiger Geist zu sein, der sich auf die verschiedensten Themen stürzt. Aktuell arbeitet er mit den anderen BCH-Entwickler an UTXO-Commitments, einem Werkzeug, das massiv dabei helfen kann, eine Blockchain zu skalieren. Vor kurzem hat er die erste Implementierung in die Blockchain im Testnet geschrieben. Wir haben mit dem Amsterdamer geskypt, um zu erfahren, was es damit auf sich hat.
Was ist die Idee hinter UTXO-Commitments?
UTXO ist die Abkürzung für „unspent outputs“ und meint die Münzen bei Bitcoin, die ausgegeben werden können. Das UTXO-Set ist die Gesamtheit dieser Münzen, es ist der Zustand aller Coins, also sämtliche Guthaben von Adressen. Es wird benötigt, um neue Blöcke und neue Transaktionen zu validieren. Die Idee von UTXO-Commitments ist es nun, den Hash des UTXO-Sets zu berechnen und in jeden neuen Block zu stecken. Es gibt verschiedene Methoden, um das zu machen.
Welchen Nutzen hätte das?
Es gibt zwei Gründe, warum UTXO-Commitments nützlich sind. Erstens muss ein neuer Full Node damit nicht mehr die gesamte Blockchain herunterladen, sondern nur das UTXO-Set. Heute muss er die gesamte Blockchain laden, um das UTXO-Set zu validieren und aufzubauen. Wenn es ein UTXO-Commitment gibt, hat man durch die Hash einen Beweis, ob ein UTXO-Set korrekt ist. Also kann man es einfach herunterladen und prüfen. Dadurch kann man einen Node viel schneller starten, und theoretisch wäre es sogar in Ordnung, wenn die historische Blockchain „vergessen“ wird.
Der zweite Nutzen ist, dass man in UTXO-Commitments einen Beweis unterbringen kann, dass ein UTXO Teil des Sets ist. Um heute zu prüfen, ob die Inputs einer Transaktion valide sind, muss man sie mit dem gesamten UTXO-Set abgleichen. Wenn wir einen Beweis dafür hätten, dass ein UTXO ein Teil des Sets ist, bräuchte man für diese Prüfung nicht mehr das gesamte UTXO-Set. Das könnte helfen, eine ganz neue Art von Light-Clients zu entwickeln.
Das UTXO-Set bei Bitcoin Cash ist derzeit etwa 2 Gigabyte groß. Ich kann mir vorstellen, dass es eine Menge Arbeit macht, das zu hashen und zu prüfen …
Oh ja, es ist eine Menge an Daten, und es dauert einige Minuten, es zu hashen. Die Herausforderung ist, dass man das UTXO-Commitments so bildet, dass es nicht für jeden Block komplett neu berechnet werden müssen, sondern dass man es, nachdem es einmal gebildet wurde, einfach nur updatet.
Die Idee ist nicht neu. Das Problem ist, dass es viele Methoden gibt, es zu tun, und bisher gab es noch keine Einigung, welche davon die beste ist. Wir bauen auf einem Vorschlag des Core-Entwicklers Pieter Wuille auf, den wir verbessern. Die Methode benutzt keine Merkle Trees oder andere kryptographische Bäume, sondern ist „flach“. Wir nehmen einfach die Hash von jedem UTXO, verbinden sie und errechnen die Summe davon. Anstatt einer normalen Addition benutzen wir dagegen eine Gruppenoperation von elliptischen Kurven, das hat einen sehr ähnlichen Effekt, ist aber sicherer.
Weißt du, warum die Core-Entwickler den Vorschlag von Pieter Wuille nicht weiter entwickelt haben?
Ich weiß es nicht genau, aber ich vermute, dass sie besorgt waren, dass es nicht schnell genug sein wird, wenn das UTXO-Set weiter wächst. Wir haben aber eine Methode gefunden, es zu verbessern. Ich denke auch, dass es etwas mit Prioritäten zu tun hat. Konzeptionell passen UTXO-Commitments besser zur Roadmap von Bitcoin Cash.
Du hast vor kurzem ein UTXO-Commitments ins Testnet von Bitcoin Cash geschrieben. Wie weit ist die Entwicklung bereits vorangeschritten?
Der Code ist derzeit noch im Peer-Review mit den Entwicklern von BitcoinABC und BitcoinXT. Bitcoin Unlimited wird es sich auch bald anschauen. Das Commitment im Testnet war nur ein erster Test, und es ist auch noch nicht Teil der Konsensregeln im Testnet. Um die Idee des schnellen Synchronisierens zu verwirklichen, müssen wir einige Schritte weiter gehen. Der erste ist die Entwicklung der Commitments selbst, an denen wir derzeit arbeiten, aber um schnell zu synchronsieren, brauchen wir noch P2P-Nachrichten, die es erlauben, UTXOs zu übertragen, und wir müssen auch noch den Synchronisierungs-Modus entwickeln …
Und die neue Art der Light Wallets, wann ist sie zu erwarten?
Die Version, die wir aktuell erarbeiten, ist nur für das schnelle Synchronisieren geeignet, aber nicht für die Light Wallet. Es gibt Entwürfe, die beides können, etwa die von Amaury vorgeschlagenen Merklix Trees, aber sie sind noch in einer frühen Phase der Entwicklung und verlangen den Nodes sehr viel Rechenleistung ab. Wir finden alle, dass neue Light Wallets toll wären, aber das schnelle Synchronisieren ist derzeit wichtiger. Also konzentrieren wir uns zunächst darauf.
Kannst du abschätzen, ab wann das schnelle Synchronisieren möglich sein wird?
Oh, grob geschätzt … Im November werden wir Bitcoin Cash per Hardfork upgraden, und ich hoffe, dass wir damit UTXO-Commitments in die Chain bringen werden. Ich habe es bisher im Testnet zwar in die Coinbase geschrieben, aber wir brauchen ja noch die Regel, dass alle Miner und Nodes die UTXO-Commitments in der Coinbase validieren. Wenn wir das im November in die Chain bringen, wäre das ein wichtiger Schritt. Die nächsten würden danach folgen.
Was meinst du, wie weit kann man mit UTXO-Commitments skalieren?
Das ist eine schwierige Frage. Es ist derzeit schon ziemlich ärgerlich, dass man mehr als 100 Gigabyte an Daten herunterladen muss. Es ist eine Last dabei, einen Node zu starten, und ein wichtiger Flaschenhals bei der Skalierbarkeit. Auf den ersten Blick hilft es nur beim Synchronsieren eines Nodes, aber wenn man sich anschaut, wofür die Nodes ihre Bandbreite hergeben, etwa den Upload, stellt man fest, dass ein großer Teil dafür verwendet wird, um die alten Blocks an neue Nodes zu verteilen. UTXO-Commitments können also auch hierbei helfen. Aber konkrete Angaben, wie weit man skalieren könnte, kann ich nicht abgeben.
Tomas, vielen Dank für die vielen Infos!
Normalerweise sind die Artikel über die Entwicklung der prominentesten Bitcoin-Fork wenigstens insoweit interessant, als dass die vorgestellten Projekte und Ideen schon nutzbar sind. Aber hier wird ein Programmierer interviewt, der weder eine fertige Software noch ein fertiges Konzept hat. Ein bisschen dünn.
Ich finde das Konzept spannend, darum habe ich Tomas gefragt, ob er mir mehr darüber erzählt. Aber du hast recht, UTXO-Commitments sind noch sehr am Anfang …
Ich weiß nicht, wie hoch die Wahrscheinlicheit ist, dass sowas tatsächlich mal umgesetzt wird, aber das ist für mich der erste interessante Artikel über BCH, weil hier mal eins der zentralen Probleme der Blockchains angegangen wird.
Zur Nachverfolgung reicht es ja auch aus, wenn nur eine Untergruppe von „Permanodes“, sagen wir z.B. 100, die komplette Historie behält.
Diese „Permanodes“ würden Miner sein. Für alle non-mining Nodes sind UTXO Commitments interessant.
Gerade Miner können sich den Speicher leisten. Ic habe mal eine Rechnung gesehen:
Der Speicher, um eine 20 Jahre alte Bitcoin Chain mit 1 TB Blöcken zu speichern kostet nach heutigen Verhältnissen gerade mal 11 Mio. USD.
@Anonymous „Der Speicher, um eine 20 Jahre alte Bitcoin Chain mit 1 TB Blöcken zu speichern kostet nach heutigen Verhältnissen gerade mal 11 Mio. USD.“
Das Schlüsselwort ist „heutigen“. Glaubst du wirklich im Ernst, dass der Speicher in 20 Jahren soviel wie heute kosten wird?
@Telesfor Ich habe doch nicht behauptet, dass es in 20 Jahren nicht günstiger sein wird. Ich wollte nur deutlich machen, dass es schon mit heutigem Speicher machbar ist, 1TB Blöcke zu speichern. Sicher, in 20 Jahren lachen wir darüber.
Speicherplatz war noch nie das Bottleneck. Bandbreite und Validierungszeit sind da deutlich relevanter. Ersteres ist übrigens nicht beliebig skalierbar, da gibt es noch sowas wie physikalische Grenzen wie z.B. die Lichtgeschwindigkeit, die bei Entfernungen zwischen Europa und Australien schon eine gewisse Relevanz bekommen, vor allem wenn man sich das weltweite Routing mal genauer ansieht…
@Paul Bandbreite ist auch kein sehr großes Problem: In großen Rechenzentren gibt es bereits Glasfaseranschlüsse, die Gigabytes in Millisekunden übertragen. Außerdem muss ein Miner ja nicht den ganzen Block kennen, um weiter zu minen, sondern es reicht der wenige Byte große Blockheader, der durch PoW gesichert ist. Zudem wird an Graphene gearbeitet, um die Propagation auf Protokollebene zu optimieren.
Die Validierungszeit lässt sich auch durch Parallelcomputing reduzieren. Eventuell würden in Jahrzehnten spezielle Chips nur für Transaktionasvalidierung entwickelt werden.
Es ist nicht ganz billig, wenn man einen VPS benutzt, aber für ~100$/Monat bekommt man einen Server, der noch sehr sehr lange läuft, mit 1gbps, 16-32GB Ram, Terabyte Festplatte, unlimitiertem Traffic …
Angenommen man hat einen Privatekey erstellt und hält diesen geheim, die dazugehörige Adresse wird aber NUR benutzt um einzuzahlen, und zwar ohne Wallet (!!!). Dann, sagen wir mal 30 Jahre später, möchte man auf die Coins zugreifen. Man erstellt eine Wallet und importiert den Privatekey. Wie bekommt man die Coins zu Gesicht, welche dort gelagert sind, d.h. wie synchronisiert man die Wallet, wenn alle Fullnodes nur noch den Hash der Ausgebbaren Coins vorhalten?
Oder ist es eher so, dass man die Transaktionshistorie löscht, aber die UTXOs vorhält. Die Korrektheit der UTXOs wird über den Hash garantiert. Dann wäre zumindest die Adresse und damit die darauf gelagerten Coins bekannt und die Zuordnung Privatekey-Adresse wäre trivial. Die Gesamtmenge der UTXOs ist immer noch ein Fliegenschiss gegenüber der Transaktionshistorie und solch ein Ansatz wäre sicherlich ein Fortschritt.
Insofern ich das richtig verstanden haben …
Genau richtig verstanden. Die Transaktionshistorie ist für das System an sich nur wichtig, um das UTXO-Set zu validieren. Wenn man umgeht, durch UTXO-Commitments, braucht man die Transaktionshistorie an sich nicht mehr.
BCash. LOL.
Du wirst deine „Argumentationsweise“ sicherlich selber anhand dieser Grafik einordnen können
https://twitter.com/DavidShares/status/1010235342576914433?s=19
Kannst du mich irgendwann aufklären, was du mit dem Kommentar eigentlich kommunizieren mochtest?
Christoph, bitte tiefer nachfragen, wie solche Dinge geplant sind, denn damit steht und fällt die ganze Methode. Ein Hash lässt sich nicht updaten, nur eventuell ein neuer addieren, aber man kommt wohl um das neu hashen alle paar Blocks nicht herum. Vielleicht haben die aber eine bessere Lösung?
Ich fand die Erklärung einigermaßen ausreichend:
„Wir nehmen einfach die Hash von jedem UTXO, verbinden sie und errechnen die Summe davon“
Beispiel mit SHA-1:
UTXO1 = aa7f669ec9e1472e8a89a61c7be9fdc7eec4b262. Wenn wir davon ersten fünf Stellen nehmen, aa7f6, könnte man das als 10+10+7+15+6 = 48 wiedergeben.
Dann nehmen wir UTXO02 = 9a4c0ad29aba8f7244abb2819a531c82b43a7b0c. Davon die ersten fünf Stellen, 9a4c0a = 9+10+4+12+0+10 = 45. Das gesamte UTXO-Commitment wäre demnach 48 + 45 = 93.
Ist natürlich alles viel viel komplizierter und ich weiß auch nicht, wie es genau funktioniert. Aber ich kann mir vorstellen, dass es ungefähr so funktioniert. Die Miner bzw. Nodes müssten halt noch irgendwo eine Datenbank mit den Hashes der UTXO haben, um es nachzuprüfen bzw. um sich das erneute Hashen zu ersparen.
Edit: Bei Etheruem gibt es den State-Root, das ist so ähnlich, FWOW.
Ein Output bei Bitcoin benötigt 34 Byte, diesen jeweils (per SHA1) auf 20 Byte zu hashen ergibt in meinen Augen wenig Sinn, denn die knapp 3GB würden dann auf ca. 2 schrumpfen, was immer noch eine Menge ist, die man verarbeiten muss. Details wären also wirklich interessant, ohne dass man irgendwo in Dev Logs eintauchen muss, um das beurteilen zu können.
Den Hash braucht man glaube ich, damit man die UTXO nicht faken kann.
Details gibt es in dem Artikel von Tomas:
https://www.yours.org/content/first-utxo-commitment-on-testnet-db7bf45bf83d
Paul, komm mal in die moneroger Gruppe zurück 😀
Nächste Woche, bin gerade etwas unter Strom, Affi ist da am besten unterrichtet… Auf Telegram warten gleich wieder 100e neue Tasks auf mich und das geht aktuell nicht, RL muss Vorrang haben…
„Beim Bergmann“ bleibe ich etwas am Ball, wenn ich gerade kurz Zeit habe, auch wenn das mit der Zeit leider ähnlich ausufert wie in Telegram, wenn man sich mal einbringt.
Wenn man auf den langen DatenSchwanz der Transaktionshistorie verzichten will, um besser skalieren zu können, würde ich mir wünschen, dass dies akkurat und möglichst fehlerfrei abläuft. Was der InterviewPartner von sich gibt, überzeugt mich nicht, da es in meinen Augen fragwürdig erscheint, ob seine angedachte Methode tatsächlich so ausfällt, dass die Transaktionshistorie weiterhin transparent, für jeden nachvollziehbar und unveränderbar bleibt.
Langfristig soll ja sowieso kaum jemand eine Full Node betreiben. Wozu optimiert man dann überhaupt das Syncen? Hier handelt es sich ja auch nicht um das Syncen einer Full Node, sondern nur des UTXO sets.
Mir scheint außerdem, dass mit steigender Nutzung und evtl. Smart Contracts das UTXO set auch extrem groß werden wird und selbst dieses nicht mehr von einem normalen Heimanwender geladen werden kann. Was also soll langfristig der Use Case sein, wenn sowieso kein normaler User mehr diese Daten nutzen kann?
Es ist so angesetzt, dass Miner und Merchants Nodes betreiben. Miners halten die ganze Chain und Merchants betreiben eine pruned Node. UTXO Commitments würden die initiale Synchronisation für Merchants beschleunigen.
Woher weiss man, dass ein Block mit einem UTXO Commit valide ist? Doch nur, weil er Teil der laengsten Kette an Bloecken ist, beginnend mit dem Genesisblock, also brauche ich doch die gesamte Blockchain, um festzustellen, dass der UTXO-Commit Block valide ist und kann sie daher nicht loeschen. Oder habe ich etwas falsch verstanden?
Eigentlich kannst Du nach einmaliger Validierung alles außer das UTXO Set löschen, denn Du hast die Blockchain selbst validiert und kannst mit Sicherheit sagen, dass das UTXO Set, welches Du gespeichert hast, nicht manipuliert wurde. Wenn Du allerdings nicht die gesamte Blockchain selbst syncst und validierst, sondern auf ein veröffentlichtes UTXO Set zurückgreifst, ist es nicht trustless. Indem man es aber in einen Block schreibt und es zur Bedingung für einen validen Block macht, wird dieses durch die nächsten Blöcke entweder validiert oder orphaned. Ein UTXO Set von vor z.B. 10 Blöcken + die aktuellen Transaktionen sollte sehr sicher sein, denn einen Chain Reorg dieser Größenordnung hatte Bitcoin allemal in den Anfängen.
Du brauchst nicht die gesamten Blöcke, die Header reichen aus. Eben genau so, wie ein SPV Client das macht.
Abwarten; wenn die Methode von BCH funktioniert und tatsächlich Vorteile mit sich bringt, gibt es auch keinen Grund das nicht in Bitcoin nutzbar machen zu können. Aber bevor wir darübe nachdenken müssen, vergeht noch viel Zeit.
Und gab es einen Grund Bitcoin-Blockgröße von 1MB auf 8MB nicht erhöhen zu wollen?