Rollups: Der schwierige Weg, Bitcoin zu skalieren

Rollups sind in letzter Zeit zum erzählerischen Mittelpunkt der Skalierung von Bitcoin geworden und sind das erste Ding, das dem Lightning Network wirklich „das Rampenlicht“ stiehlt

Rollups have become a hot topic in the Bitcoin scaling discussion lately, being the first thing to truly “steal the limelight” from the Lightning Network in terms of wider mindshare. Rollups aim to be an off-chain layer two that is not bound or constrained by the liquidity limitations that are central to the Lightning Network, i.e. end users required someone allocate (or “lend”) them funds ahead of time in order to be able to receive money, or intermediary routing nodes requiring channel balances that can facilitate the movement of the payment amount all the way from sender to receiver.

Rollups sind in letzter Zeit zu einem heißen Thema in der Bitcoin-Skalierungsdiskussion geworden und waren das erste, was dem Lightning Network wirklich „das Rampenlicht“ gestohlen hat, was einen breiteren Meinungsaustausch angeht. Rollups zielen darauf ab, eine Off-Chain-Schicht zwei zu sein, die nicht an die Liquiditätsbeschränkungen gebunden oder eingeschränkt ist, die für das Lightning Network von zentraler Bedeutung sind, d um Geld zu empfangen, oder zwischengeschaltete Routing-Knoten, die Kanalsalden benötigen, die die Bewegung des Zahlungsbetrags vom Sender zum Empfänger erleichtern können.

These systems were originally developed to function on Ethereum and other Turing complete systems, but as of late the focus has shifted to porting them to UTXO based blockchains such as Bitcoin. This article is not going to discuss the current state of things being implemented on Bitcoin currently, but going to discuss the function of an idealized rollup that people are aiming for in the long term depending on features Bitcoin currently does not support, namely the ability to verify Zero Knowledge Proofs (ZKPs) on Bitcoin directly.

Diese Systeme wurden ursprünglich für den Betrieb auf Ethereum und anderen Turing-Komplettsystemen entwickelt, aber in letzter Zeit hat sich der Schwerpunkt auf die Portierung auf UTXO-basierte Blockchains wie Bitcoin verlagert. In diesem Artikel geht es nicht darum, den aktuellen Stand der Dinge zu diskutieren, die derzeit auf Bitcoin implementiert werden, sondern um die Funktion eines idealisierten Rollups, die Menschen langfristig anstreben, abhängig von den Funktionen, die Bitcoin derzeit nicht unterstützt, nämlich die Fähigkeit dazu Überprüfen Sie Zero Knowledge Proofs (ZKPs) direkt auf Bitcoin.

The basic architecture of a roll is as follows: a single account (or in Bitcoin’s case UTXO), holds the balances of all users in the rollup. This UTXO contains a commitment in the form of a merkle root of a merkle tree that commits to all the current balances of existing accounts in the rollup. All of these accounts are authorized using public/private key pairs, so in order to propose an off-chain spend a user must still sign something with a key. This part of the structure allows users to leave without permission whenever they want, simply by crafting a transaction proving their account is part of the merkle tree, they can unilaterally exit the rollup without the operator's permission.

Die grundlegende Architektur eines Rollups ist wie folgt: Ein einzelnes Konto (oder im Fall von Bitcoin UTXO) speichert die Guthaben aller Benutzer im Rollup. Dieses UTXO enthält eine Verpflichtung in Form einer Merkle-Wurzel eines Merkle-Baums, die sich auf alle aktuellen Salden bestehender Konten im Rollup bezieht. Alle diese Konten werden mit öffentlichen/privaten Schlüsselpaaren autorisiert. Um also eine Off-Chain-Ausgabe vorzuschlagen, muss ein Benutzer noch etwas mit einem Schlüssel signieren. Dieser Teil der Struktur ermöglicht es Benutzern, das Konto jederzeit ohne Erlaubnis zu verlassen. Indem sie einfach eine Transaktion erstellen, die beweist, dass ihr Konto Teil des Merkle-Baums ist, können sie das Rollup ohne Erlaubnis des Betreibers einseitig verlassen.

The operator of the rollup must include a ZKP in transactions that update the merkle root of account balances on-chain in the process of finalizing off-chain transactions, without this ZKP the transaction will be invalid and therefore not includable in the blockchain. This proof allows people to verify that all changes to off-chain accounts were properly authorized by the account holder(s), and that the operator has not conducted a malicious update of balances to steal money from users or reallocate it to other users dishonestly.

Der Betreiber des Rollups muss einen ZKP in Transaktionen einbeziehen, die die Merkle-Wurzel der Kontostände in der Kette aktualisieren, während Off-Chain-Transaktionen abgeschlossen werden. Ohne diesen ZKP ist die Transaktion ungültig und kann daher nicht in die Blockchain aufgenommen werden. Mit diesem Nachweis können Benutzer überprüfen, ob alle Änderungen an Off-Chain-Konten ordnungsgemäß von den Kontoinhabern genehmigt wurden und dass der Betreiber keine böswillige Aktualisierung der Guthaben durchgeführt hat, um den Benutzern Geld zu stehlen oder es unredlich anderen Benutzern zuzuweisen.

The problem is, if only the root of the merkle tree is posted on-chain where users can view and access it, how do they get their branch in the tree in order to be capable of exiting without permission when they want to?

Das Problem ist: Wenn nur die Wurzel des Merkle-Baums in der Kette veröffentlicht wird, wo Benutzer sie sehen und darauf zugreifen können, wie erhalten sie dann ihren Zweig im Baum, um ihn ohne Erlaubnis verlassen zu können, wenn sie wollen?

In a proper rollup, the information is put directly into the blockchain everytime that new off-chain transactions are confirmed and the state of the rollup accounts change. Not the entire tree, that would be absurd, but the information necessary to reconstruct the tree. In a naive implementation, the summary of all existing accounts in the rollup would have balances and accounts simply added in the transaction updating the rollup.

Bei einem ordnungsgemäßen Rollup werden die Informationen jedes Mal direkt in die Blockchain eingegeben, wenn neue Off-Chain-Transaktionen bestätigt werden und sich der Status der Rollup-Konten ändert. Nicht der gesamte Baum, das wäre absurd, sondern die Informationen, die zur Rekonstruktion des Baums notwendig sind. In einer naiven Implementierung würden die Salden und Konten der Zusammenfassung aller vorhandenen Konten im Rollup einfach in der Transaktion hinzugefügt, die den Rollup aktualisiert.

In more advanced implementations, a balance diff is used. This is essentially a summary of what accounts have had money added to or subtracted from them during the course of an update. This allows each rollup update to only include the changes to account balances that occur. Users can then simply scan the chain and “do the math” from the beginning of the rollup to arrive at the current state of account balances, which allows them to reconstruct the merkle tree of current balances.

In fortgeschritteneren Implementierungen wird ein Balancediff verwendet. Hierbei handelt es sich im Wesentlichen um eine Zusammenfassung der Konten, denen im Verlauf einer Aktualisierung Geld hinzugefügt oder abgezogen wurde. Dadurch kann jede Rollup-Aktualisierung nur die vorgenommenen Änderungen an den Kontoständen umfassen. Benutzer können dann einfach die Kette scannen und vom Beginn des Rollups an „rechnen“, um den aktuellen Stand der Kontostände zu ermitteln, wodurch sie den Merkle-Baum der aktuellen Kontostände rekonstruieren können.

This saves a lot of overhead and blockspace (and therefore money) while still allowing users to guarantee access to the information needed for them to exit unilaterally. Including this data in a formal rollup that uses the blockchain to make it available to users is mandated by the rules of the rollup, i.e. a transaction that does not include the account summary or account diff is considered an invalid transaction.

Dies spart viel Overhead und Blockplatz (und damit Geld) und ermöglicht es den Benutzern gleichzeitig, den Zugriff auf die Informationen zu gewährleisten, die sie für einen einseitigen Ausstieg benötigen. Die Einbeziehung dieser Daten in ein formelles Rollup, das die Blockchain nutzt, um sie den Benutzern zur Verfügung zu stellen, ist durch die Regeln des Rollups vorgeschrieben, d. h. eine Transaktion, die keine Kontoübersicht oder Kontodifferenz enthält, wird als ungültige Transaktion betrachtet.

The other way to handle the problem of data availability for users to withdraw is to put the data somewhere else besides the blockchain. This introduces subtle issues, the rollup still needs to enforce that the data was made available somewhere else. Traditionally other blockchains are used for this purpose, specifically designed to function as data availability layers for systems like rollups.

Die andere Möglichkeit, das Problem der Datenverfügbarkeit für Benutzer zum Abheben zu lösen, besteht darin, die Daten an einem anderen Ort als der Blockchain abzulegen. Dies führt zu subtilen Problemen. Beim Rollup muss immer noch sichergestellt werden, dass die Daten woanders verfügbar gemacht wurden. Traditionell werden zu diesem Zweck andere Blockchains verwendet, die speziell als Datenverfügbarkeitsschichten für Systeme wie Rollups konzipiert sind.

This creates the dilemma of security guarantees being as strong. When the data is posted directly to the Bitcoin blockchain, consensus rules can guarantee it is correct with absolute certainty. However when it is posted to an external system, the best it can do is verify an SPV proof that the data was posted to another system.

Dadurch entsteht das Dilemma, dass die Sicherheitsgarantien genauso stark sein müssen. Wenn die Daten direkt in der Bitcoin-Blockchain gepostet werden, können Konsensregeln mit absoluter Sicherheit garantieren, dass sie korrekt sind. Wenn die Daten jedoch in ein externes System gebucht werden, besteht die beste Möglichkeit darin, einen SPV-Nachweis zu verifizieren, dass die Daten in ein anderes System gebucht wurden.

This entails verifying an attestation that data exists on other chains, which is ultimately an oracle problem. Bitcoin’s blockchain cannot verify anything completely except what occurs on its own blockchain, the best it can do is verify a ZKP. A ZKP however cannot verify that a block containing rollup data was actually publicly broadcast after being produced. It cannot verify that external information is actually publicly available to everyone.

Dies erfordert die Überprüfung einer Bescheinigung, dass Daten in anderen Ketten vorhanden sind, was letztendlich ein Oracle-Problem ist. Die Bitcoin-Blockchain kann nichts vollständig verifizieren, außer das, was auf ihrer eigenen Blockchain geschieht. Das Beste, was sie tun kann, ist die Verifizierung eines ZKP. Ein ZKP kann jedoch nicht überprüfen, ob ein Block mit Rollup-Daten nach seiner Erstellung tatsächlich öffentlich ausgestrahlt wurde. Es kann nicht überprüft werden, ob externe Informationen tatsächlich für jedermann öffentlich zugänglich sind.

This opens the door to data withholding attacks, where a commitment

Dies öffnet die Tür für Angriffe zur Zurückhaltung von Daten, bei denen eine Verpflichtung besteht