Strategien zur Datenspeicherung auf der Blockchain
Es gibt mehrere Möglichkeiten, Informationen entweder direkt auf der Blockchain oder auf eine durch die Blockchain gesicherte Weise zu speichern:
- EIP-4844-Blobs
- Calldata
- offchain mit Layer-1-Mechanismen (L1)
- Vertrags-„Code“
- Ereignisse
- EVM-Speicher
Die Wahl der zu verwendenden Methode hängt von mehreren Kriterien ab:
- Die Quelle der Informationen. Informationen in Calldata können nicht direkt von der Blockchain selbst stammen.
- Das Ziel der Informationen. Calldata ist nur in der Transaktion verfügbar, die sie enthält. Ereignisse sind Onchain überhaupt nicht zugänglich.
- Wie viel Aufwand ist akzeptabel? Computer, die einen vollwertigen Knoten (Full Node) ausführen, können mehr Verarbeitungsleistung erbringen als ein Light-Client in einer Anwendung, die in einem Browser läuft.
- Ist es notwendig, einen einfachen Zugriff auf die Informationen von jedem Knoten aus zu ermöglichen?
- Die Sicherheitsanforderungen.
Die Sicherheitsanforderungen
Im Allgemeinen besteht die Informationssicherheit aus drei Attributen:
-
Vertraulichkeit: Unbefugte Entitäten dürfen die Informationen nicht lesen. Dies ist in vielen Fällen wichtig, hier jedoch nicht. Es gibt keine Geheimnisse auf der Blockchain. Blockchains funktionieren, weil jeder die Zustandsübergänge verifizieren kann, daher ist es unmöglich, sie zur direkten Speicherung von Geheimnissen zu verwenden. Es gibt Möglichkeiten, vertrauliche Informationen auf der Blockchain zu speichern, aber sie alle verlassen sich auf eine Offchain-Komponente, um zumindest einen Schlüssel zu speichern.
-
Integrität: Die Informationen sind korrekt, sie können nicht von unbefugten Entitäten oder auf unbefugte Weise geändert werden (zum Beispiel die Übertragung von ERC-20-Token (opens in a new tab) ohne ein
Transfer-Ereignis). Auf der Blockchain verifiziert jeder Knoten jede Zustandsänderung, was die Integrität sicherstellt. -
Verfügbarkeit: Die Informationen stehen jeder autorisierten Entität zur Verfügung. Auf der Blockchain wird dies normalerweise erreicht, indem die Informationen auf jedem Full Node (opens in a new tab) verfügbar sind.
Die verschiedenen hier vorgestellten Lösungen weisen alle eine hervorragende Integrität auf, da Hashes auf Layer 1 (L1) gepostet werden. Sie haben jedoch unterschiedliche Verfügbarkeitsgarantien.
Voraussetzungen
Sie sollten ein gutes Verständnis der Blockchain-Grundlagen haben. Diese Seite setzt außerdem voraus, dass der Leser mit Blöcken, Transaktionen und anderen relevanten Themen vertraut ist.
EIP-4844-Blobs
Beginnend mit dem Dencun-Hardfork (opens in a new tab) beinhaltet die Ethereum-Blockchain EIP-4844 (opens in a new tab), was Ethereum um Daten-Blobs mit einer begrenzten Lebensdauer (anfänglich etwa 18 Tage (opens in a new tab)) erweitert. Diese Blobs werden separat vom Ausführungs-Gas bepreist, obwohl ein ähnlicher Mechanismus verwendet wird. Sie sind eine günstige Möglichkeit, temporäre Daten zu posten.
Der Hauptanwendungsfall für EIP-4844-Blobs besteht darin, dass Rollups ihre Transaktionen veröffentlichen. Optimistic Rollups müssen die Transaktionen auf ihren Blockchains veröffentlichen. Diese Transaktionen müssen während der Anfechtungsfrist (Challenge Period) (opens in a new tab) für jeden verfügbar sein, um es Validatoren (opens in a new tab) zu ermöglichen, den Fehler zu beheben, falls der Sequencer (opens in a new tab) des Rollups eine falsche Zustands-Wurzel (State Root) postet.
Sobald jedoch die Anfechtungsfrist abgelaufen ist und die Zustands-Wurzel endgültig ist, besteht der verbleibende Zweck für die Kenntnis dieser Transaktionen darin, den aktuellen Zustand der Chain zu replizieren. Dieser Zustand ist auch von Chain-Knoten verfügbar, wobei viel weniger Verarbeitungsaufwand erforderlich ist. Transaktionsinformationen sollten also weiterhin an einigen Orten aufbewahrt werden, wie z. B. in Block-Explorern, aber es besteht keine Notwendigkeit, für das Maß an Zensurresistenz zu bezahlen, das Ethereum bietet.
Zero-Knowledge-Rollups posten ebenfalls ihre Transaktionsdaten, um es anderen Knoten zu ermöglichen, den bestehenden Zustand zu replizieren und Gültigkeitsnachweise zu verifizieren, aber auch das ist eine kurzfristige Anforderung.
Zum Zeitpunkt des Schreibens kostet das Posten auf EIP-4844 ein Wei (10-18 ETH) pro Byte, was im Vergleich zu den 21.000 Ausführungs-Gas, die jede Transaktion kostet (einschließlich derer, die Blobs posten) (opens in a new tab), vernachlässigbar ist. Sie können den aktuellen EIP-4844-Preis auf blobscan.com (opens in a new tab) einsehen.
Hier sind die Adressen, um die von einigen bekannten Rollups geposteten Blobs zu sehen.
Calldata
Calldata bezieht sich auf die Bytes, die als Teil der Transaktion gesendet werden. Sie werden als Teil der permanenten Aufzeichnung der Blockchain in dem Block gespeichert, der diese Transaktion enthält.
Dies ist die günstigste Methode, um Daten dauerhaft in der Blockchain abzulegen. Die Kosten pro Byte betragen entweder 4 Ausführungs-Gas (wenn das Byte null ist) oder 16 Gas (jeder andere Wert). Wenn die Daten komprimiert sind, was gängige Praxis ist, ist jeder Bytewert gleich wahrscheinlich, sodass die durchschnittlichen Kosten bei etwa 15,95 Gas pro Byte liegen.
Zum Zeitpunkt des Schreibens liegen die Preise bei 12 Gwei/Gas und 2300 $/ETH, was bedeutet, dass die Kosten etwa 45 Cent pro Kilobyte betragen. Da dies vor EIP-4844 die günstigste Methode war, ist dies die Methode, die Rollups verwendeten, um Transaktionsinformationen zu speichern, welche für Fehleranfechtungen (Fault Challenges) (opens in a new tab) verfügbar sein müssen, aber nicht direkt Onchain zugänglich sein müssen.
Hier sind die Adressen, um die von einigen bekannten Rollups geposteten Transaktionen zu sehen.
Offchain mit L1-Mechanismen
Abhängig von Ihren Sicherheitskompromissen kann es akzeptabel sein, die Informationen an einem anderen Ort abzulegen und einen Mechanismus zu verwenden, der sicherstellt, dass die Daten bei Bedarf verfügbar sind. Damit dies funktioniert, gibt es zwei Anforderungen:
-
Posten Sie einen Hash (opens in a new tab) der Daten auf der Blockchain, der als Input-Commitment bezeichnet wird. Dies kann ein einzelnes 32-Byte-Wort sein, ist also nicht teuer. Solange das Input-Commitment verfügbar ist, ist die Integrität gewährleistet, da es nicht machbar ist, andere Daten zu finden, die denselben Hash-Wert ergeben würden. Wenn also falsche Daten bereitgestellt werden, kann dies erkannt werden.
-
Ein Mechanismus, der die Verfügbarkeit sicherstellt. Zum Beispiel kann in Redstone (opens in a new tab) jeder Knoten eine Verfügbarkeitsanfechtung (Availability Challenge) einreichen. Wenn der Sequencer nicht bis zur Frist Onchain antwortet, wird das Input-Commitment verworfen, sodass die Informationen als nie gepostet gelten.
Dies ist für ein Optimistic Rollup akzeptabel, da wir uns bereits darauf verlassen, dass es mindestens einen ehrlichen Verifizierer für die Zustands-Wurzel gibt. Ein solcher ehrlicher Verifizierer wird auch sicherstellen, dass er über die Daten zur Verarbeitung von Blöcken verfügt, und eine Verfügbarkeitsanfechtung ausgeben, wenn die Informationen nicht offchain verfügbar sind. Diese Art von Optimistic Rollup wird Plasma genannt.
Vertragscode
Informationen, die nur einmal geschrieben werden müssen, nie überschrieben werden und Onchain verfügbar sein müssen, können als Vertragscode gespeichert werden. Das bedeutet, dass wir einen „Smart Contract“ mit den Daten erstellen und dann EXTCODECOPY (opens in a new tab) verwenden, um die Informationen zu lesen. Der Vorteil ist, dass das Kopieren von Code relativ günstig ist.
Abgesehen von den Kosten für die Speichererweiterung kostet EXTCODECOPY 2600 Gas für den ersten Zugriff auf einen Vertrag (wenn er „kalt“ ist) und 100 Gas für nachfolgende Kopien aus demselben Vertrag plus 3 Gas pro 32-Byte-Wort. Verglichen mit Calldata, die 15,95 pro Byte kosten, ist dies ab etwa 200 Bytes günstiger. Basierend auf der Formel für Speichererweiterungskosten (opens in a new tab) sind die Speichererweiterungskosten geringer als die Kosten für das Hinzufügen von Calldata, solange Sie nicht mehr als 4 MB Speicher benötigen.
Natürlich sind dies nur die Kosten, um die Daten zu lesen. Die Erstellung des Vertrags kostet etwa 32.000 Gas + 200 Gas/Byte. Diese Methode ist nur dann wirtschaftlich, wenn dieselben Informationen viele Male in verschiedenen Transaktionen gelesen werden müssen.
Vertragscode kann unsinnig sein, solange er nicht mit 0xEF beginnt. Verträge, die mit 0xEF beginnen, werden als Ethereum Object Format (opens in a new tab) interpretiert, welches viel strengere Anforderungen hat.
Ereignisse
Ereignisse (opens in a new tab) werden von Smart Contracts ausgegeben und von Offchain-Software gelesen. Ihr Vorteil ist, dass Offchain-Code auf Ereignisse lauschen kann. Die Kosten betragen Gas (opens in a new tab), 375 plus 8 Gas pro Byte an Daten. Bei 12 Gwei/Gas und 2300 $/ETH entspricht dies einem Cent plus 22 Cent pro Kilobyte.
Speicher
Smart Contracts haben Zugriff auf persistenten Speicher (opens in a new tab). Dieser ist jedoch sehr teuer. Das Schreiben eines 32-Byte-Wortes in einen zuvor leeren Speicher-Slot kann 22.100 Gas kosten (opens in a new tab). Bei 12 Gwei/Gas und 2300 $/ETH sind das etwa 61 Cent pro Schreibvorgang oder 19,5 $ pro Kilobyte.
Dies ist die teuerste Form der Speicherung in Ethereum.
Zusammenfassung
Diese Tabelle fasst die verschiedenen Optionen, ihre Vorteile und Nachteile zusammen.
| Speichertyp | Datenquelle | Verfügbarkeitsgarantie | Onchain-Verfügbarkeit | Zusätzliche Einschränkungen |
|---|---|---|---|---|
| EIP-4844-Blobs | Offchain | Ethereum-Garantie für ~18 Tage (opens in a new tab) | Nur Hash ist verfügbar | |
| Calldata | Offchain | Ethereum-Garantie für immer (Teil der Blockchain) | Nur verfügbar, wenn in einen Vertrag geschrieben, und bei dieser Transaktion | |
| Offchain mit L1-Mechanismen | Offchain | „Ein ehrlicher Verifizierer“-Garantie während der Anfechtungsfrist | Nur Hash | Garantiert durch den Anfechtungsmechanismus, nur während der Anfechtungsfrist |
| Vertragscode | Onchain oder offchain | Ethereum-Garantie für immer (Teil der Blockchain) | Ja | Wird an eine „zufällige“ Adresse geschrieben, darf nicht mit 0xEF beginnen |
| Ereignisse | Onchain | Ethereum-Garantie für immer (Teil der Blockchain) | Nein | |
| Speicher | Onchain | Ethereum-Garantie für immer (Teil der Blockchain und des aktuellen Zustands, bis er überschrieben wird) | Ja |