Datenarchitektur der Libra Blockchain – Teil 5 – ledger state

In unserer Serie über die Datenarchitektur der Libra Blockchain haben wir bisher nicht erklären müssen, was ein «Block» ist. Tatsächlich spielt das Konzept eines «Block» oder gar das Konzept einer «Kette von Blocks» in der Libra Blockchain nur eine untergeordnete Rolle. Die Bezeichnung «Blockchain» hält sich aber hartnäckig und wir verwenden sie deshalb weiterhin, obschon die Bezeichnung Distributed Ledger treffender wäre.

In unserem letzten Blog-Beitrag haben wir gesehen, dass die Libra Blockchain einen sparse merkle tree aufbaut, über den sie den account state für einen account in ihren Datenbeständen findet. Sie bezeichnet einen derartigen Baum mit seinen inneren Knoten und den leaf nodes sowie mit den über die leaf nodes verknüpften account states als ledger state.

Wir werden aber gleich sehen, dass sie nicht den einen sparse merkle tree, sondern einen ganzen Wald davon bewirtschaftet. Die Libra Blockchain unterhält demnach nicht nur einen, sondern eine Serie von ledger states. Jede ausgeführte Transaktion führt zu einem neuen ledger state und die Libra Blockchain unterhält dafür eine ledger history, auf die wir später in einem weiteren Blog-Beitrag eingehen werden.

Zusätzlich zu den account states speichert die Libra Blockchain auch den sparse merkle tree (bzw. die sparse merkle trees) historisiert. Mehrere dieser Bäume aufbewahren – führt das nicht zu einer Explosion des Datenvolumens? Die Antwort ist – vielleicht überraschend – nein. Wir werden sehen, dass sich zwei aufeinanderfolgende Versionen des sparse merkle trees nur in einem (oder ein paar wenigen) Pfaden von der Wurzel bis zu den leaf nodes unterscheiden und dass nur dieser Unterschied zusätzlich in den Datenbeständen abgelegt wird. Im ganzen Rest besteht die spätere Version eines sparse merkle trees aus den gleichen inneren Knoten und leaf nodes wie die vorangehende Version. Das spart entscheidend Speicherplatz.

Beispiel: 5 Libra überweisen

Wenn jemand einen Betrag von 5 Libra von einem account 0xAB00 auf einen account 0xCD00 überweist, führt die Libra Blockchain eine Transaktion aus, die

Man könnte sagen, dass eine Transaktion die beiden account states «verändert», aber das trifft die Sache nicht ganz. Eine Transaktion «verändert» keine Zustände, sondern generiert neue account states ausgehend von bereits existierenden. Einmal abgelegte account states bleiben unverändert im key value store erhalten.

Sie legt auch zwei neue leaf nodes an, die die beiden accounts 0xAB00 und 0xCD00 mit den neuen account states verknüpfen. Die beiden leaf nodes, die die account states vor der Ausführung der Transaktion mit den accounts verknüpft haben, belässt sie unverändert im key value store.

Von den beiden neuen leaf nodes baut sie nun zwei vollständig neue Pfade mit inneren Knoten durch den sparse merkle tree auf. Spätestens in der Wurzel, in vielen Fällen schon auf einer tieferen Ebene, laufen diese Pfade zusammen. Maximal legt sie also zwei neue Pfade mit je 255 inneren Knoten und einem gemeinsamen neuen Wurzel-Knoten an, total also maximal rund 500 Knoten. Alle diese neuen Knoten speichert sie im key value store ab.

Anmerkung: Dank zweier Optimierungsmassnahmen sind es sogar wesentlich weniger Schlüssel/Wert-Paare, die die Libra Blockchain im key value store speichern muss. Im Idealfall sind es statt rund 500 nur 3 zusätzliche Schlüssel/Wert-Paare, um die beiden neuen Pfade im key value store abzulegen! Wir werden später darauf zurückkommen.

Nach der Ausführung der Transaktion kennt die Libra Blockchain einen neuen sparse merkle tree mit einer neuen Wurzel, der sich in unserem Beispiel in maximal rund 500 inneren Knoten und in zwei leaf nodes von der Vorgängerversion unterscheidet. Die Vorgängerversion des Baums ist davon unberührt. Sie wird nach Ausführung der Transaktion unverändert im key value store aufbewahrt

Die Libra Blockchain kann nun wahlweise den Abstieg durch den Baum beim alten oder beim neuen Wurzel-Knoten starten. Startet sie beim alten und steigt sie entlang der account address 0xAB00 durch den Baum hinunter (hier beschrieben), landet sie letztlich beim account state für 0xAB00 vor der Ausführung der Transaktion; startet sie bei der neuen Wurzel, landet sie entsprechende beim account state nach der Ausführung der Transaktion.

Andere accounts, zum Beispiel der account 0xEF00, die von der Transaktion nicht betroffen sind, bleiben unverändert. Unabhängig davon, ob man den account state für 0xEF00 ausgehend vom Wurzel-Knoten vor oder nach der Transaktion sucht, wird die Libra Blockchain den gleichen, unveränderten account state finden.

Versiegeln eines ledger states

Die Datenbestände eines Blockchain-Systems gelten als unveränderlich. Das heisst nicht, dass sie technisch vor Überschreiben oder Veränderung geschützt sind, indem sie zum Beispiel auf einem Nur-Lese-Medium wie einer CD abgespeichert sind. Es bedeutet vielmehr, dass niemand unbemerkt einmal gespeicherte Daten verändern kann, obschon die Datenbestände wie bei der Libra Blockchain für jedermann zugänglich und einsehbar sind. Die Datenbestände sind mit kryptografischen Mitteln versiegelt (nicht verschlüsselt), so dass jede Veränderung der Daten zu einem einfach überprüfbaren Bruch dieses Siegels führt.

In der Libra Blockchain versiegelt der elektronisch unterschriebene Hash-Wert der Wurzel des sparse merkle trees einen ledger state. Ausgewählte Akteure, die als validators bezeichnet werden, leisten die benötigten elektronischen Unterschriften – wir werden später darauf zurückkommen.

Die elektronisch unterschriebenen 32 Bytes, die den Hash-Wert der Wurzel des sparse merkle trees ausmachen, versiegeln den ganzen Baum der inneren Knoten, leaf nodes und der über die leaf nodes verknüpften account states. Kompakte 32 Bytes versiegeln einen beliebig umfangreichen ledger state, der Giga- oder Terabytes an Daten umfassen kann. Jede Veränderung in einem der account states, leaf nodes oder inneren Knoten würde zu einem Bruch dieses Siegels führen.

Wer beispielsweise einen Weg fände, in einem versiegelten ledger state den Saldo seines Libra accounts um 5 zu erhöhen und im key value store zu speichern, könnte trotzdem nicht nachweisen, dass dieser neue, um 5 Libra erhöhte Saldo legitim, das heisst, das Ergebnis einer nach den Regeln der Libra Blockchain ausgeführten Transaktion, ist.

Ein vertrauenswürdiger Nachweis (ein proof) müsste aus einem vollständigen, im key value store überprüfbaren Pfad vom account state über einen leaf node durch den ganzen sparse merkle tree bis zur Wurzel bestehen. Weil alle Knoten in diesem Pfad über kryptografische Hash-Werte verknüpft sind, würde jede Veränderung im account state letztlich zu einem neuen Hash-Wert für die Wurzel des sparse merkle trees führen, einem Hash-Wert, der nicht dem elektronisch unterschriebenen Hash-Wert der Wurzel entspräche. Das Siegel wäre gebrochen und die Behauptung, der Libra Saldo für den account sei 5 Libra höher, wäre widerlegt.

Die mathematischen Eigenschaften der eingesetzten kryptografischen Hash-Funktion SHA-3 (Einwegfunktion, Kollisionsresistenz) verunmöglichen, dass jemand mit Grips und/oder viel Rechenkraft fake account states, fake leaf nodes oder fake innere Knoten finden und in den key value store einspeisen kann, ohne das Siegel zu brechen.