Einführung
Dies ist der letzte Teil der Interviewreihe „Decentralized Rollup“. In dieser Episode geht es um die Rollup-Dezentralisierung aus der Perspektive von „Datenverfügbarkeit und dezentraler Speicherung“. Wir haben Qi Zhou, den Gründer von EthStorage, eingeladen, zu diskutieren, wie DA die Sicherheitsattribute des Ethereum-Mainnets, EIP-4844 und Danksharding, wiederverwenden kann, sowie den Sicherheitsvergleich verschiedener DA-Modelle. Lehrer Zhou stellte außerdem vor, wie EthStorage im nächsten Ethereum-Upgrade mit EIP-4844 kombiniert werden kann.
Gastvorstellung
Ich freue mich sehr, Ihnen einige unserer Gedanken zur gesamten Ethereum-DA-Technologie und der dezentralen Speicherung, die wir darauf durchgeführt haben, mitzuteilen. Ich bin 2018 Vollzeit in die Web3-Branche eingestiegen. Ich habe als Ingenieur in großen Unternehmen wie Google und Facebook gearbeitet. Und hat einen Doktortitel vom Georgia Institute of Technology. Seit 2018 verfolge und arbeite ich an der Web3-Infrastruktur. Der Hauptgrund ist, dass ich dies zuvor auch in großen Fabriken gemacht habe, einschließlich verteilter Systeme und verteilter Speicherung. Darüber hinaus denke ich auch, dass es in diesem Aspekt der gesamten Blockchain noch viel Raum für Verbesserungen gibt. Egal, was wir am Anfang gemacht haben, zum Beispiel die Technologie namens Execution Sharding. Dies ist also Ethereums Sharding 1.0 und nun die Technologie namens Data Sharding von Ethereums Sharding 2.0 und die anschließende Datenverfügbarkeit. Tatsächlich handelt es sich bei allen um Innovationen und Arbeiten, die sich rund um die gesamte Web3-Infrastruktur bewährt haben.
Deshalb verfolgen wir auch aufmerksam die Ethereum-Roadmap, studieren und erforschen und beteiligen uns auf diese Weise an der Gemeinschaft und verbessern uns. Ende letzten Jahres hatten wir die große Ehre, eine Unterstützung der Ethereum Foundation für unsere Forschung zum Thema „Data Availability Sampling“ zu erhalten. Helfen Sie der Ethereum Foundation bei der theoretischen Arbeit und bei der Forschungsarbeit zum Thema Danksharding, einschließlich der Frage, wie man Daten effektiv wiederherstellt. Gleichzeitig entwickeln wir auch EthStorage, eine Ethereum-Datenschicht, die auf der DA-Technologie von Ethereum basiert. Wir können die intelligenten Verträge von Ethereum nutzen, um die Datenspeicherung außerhalb der Kette in großem Maßstab zu überprüfen. Dies ist auch für Ethereum von großer Bedeutung. Daher freue ich mich sehr, Ihnen heute mitzuteilen, wie EthStorage ein Netzwerk von Datenspeicherschichten auf Basis der DA-Technologie besser aufbauen kann.
Interview-Bereich
Teil 1: Diskussion zur DA-Definition
Wie Datenverfügbarkeit (DA) Rollups sicher hält
Erstens habe ich bei der Recherche zu DA auch festgestellt, dass viele Menschen die Definition von DA nicht verstehen. Ich freue mich auch sehr, heute darüber zu diskutieren. Zuvor habe ich DA auch mit vielen Mitgliedern der Ethereum Foundation, wie zum Beispiel Dankrad Feist, und der wichtigen Rolle, die DA im gesamten Ethereum L2 spielt, besprochen.
Ich habe einige grundlegende Arbeitsmechanismen des Ethereum-Rollups erwähnt, wie man diese On-Chain-Transaktionen in Off-Chain verlagert und dann eine Reihe von Beweismethoden (Betrugsnachweis und Gültigkeitsnachweis) verwendet, um dem L1-Smart-Vertrag mitzuteilen, dass diese Ausführungsergebnisse akzeptabel sind . Beweisen Sie anhand dieser Beweise, dass es wahr ist.
Dann ist ein sehr wichtiger Kern, dass sie hoffen, die Sicherheit des Ethereum-Netzwerks selbst wiederzuverwenden und gleichzeitig die gesamte Rechenleistung von Ethereum erheblich erweitern zu können. Ich habe gerade gesagt, dass die Ausweitung der Rechenleistung tatsächlich dazu führt, dass die Berechnung außerhalb der Kette erfolgt. Wie kann also gleichzeitig die Sicherheit von Ethereum realisiert werden?
Wie kann beispielsweise im Fall von Optimistic Rollup sichergestellt werden, dass jemand den Sequenzer dazu auffordern kann, bösartige Dinge zu tun? Es ist sehr wichtig zu wissen, wie die spezifische Originaltransaktion unter der Kette aussieht. Wenn die spezifischen Originaltransaktionen außerhalb der Kette nicht verfügbar sind, kann ich die Originaltransaktionsdatensätze nicht finden, um den Sequenzer in der Kette herauszufordern. Daher kann DA die Sicherheit garantieren, da es ermöglichen muss, dass die Metadaten jeder Off-Chain-Transaktion in der Kette verfügbar sind.
Blockplatz erweitern
Da alle unsere Transaktionsdaten in die Kette hochgeladen werden müssen, generieren wir auch dann große Transaktionsdaten, wenn keine Berechnung erforderlich ist. Dann ist das Kernproblem, das es zu lösen gilt: Jeder kann verstehen, dass es sich um eine sehr effektive Technologie zur Erweiterung des Blockraums handelt. Wenn Sie die Struktur der gesamten Blockchain gut verstehen, enthält jeder Block eine Menge Transaktionsinhalte. Den Block selbst dieser Transaktion nennen wir Blockraum.
Derzeit beträgt der Speicherplatz jedes Blocks in Ethereum etwa 2.300 KB. Aber eine solche Zahl ist offensichtlich nicht in der Lage, den Bedarf der nächsten Erweiterung von Ethereum zu decken. Hier kann eine sehr schnelle Berechnung durchgeführt werden: Teilen Sie den Speicherplatz von 200 kB durch die Anzahl jeder Transaktion, was etwa 100 Bytes entspricht, und erhalten Sie die Anzahl von 2000 Transaktionen. Teilen Sie 2000 Transaktionen durch die Blockzeit von Ethereum 12, was bedeutet, dass die Obergrenze der TPS von Ethereum auf etwa 100 begrenzt ist. Nun, das ist eigentlich eine sehr kleine Zahl für den gesamten Ethereum-Expansionsplan.
Daher geht es bei Ethereum L2 darum, die Sicherheit zu gewährleisten und große Mengen an Blockdaten im Blockraum unterzubringen. Unabhängig davon, ob es sich um einen Betrugsnachweis oder einen Gültigkeitsnachweis handelt, können die Daten im Blockraum von Ethereum für entsprechende Prüfungen wiederverwendet werden. Schließlich kann die Sicherheit der Berechnungsergebnisse von Off-Chain-Transaktionen durch Ethereum gewährleistet werden. Das ist also im Grunde die Beziehung zwischen DA und der Sicherheit von Ethereum.
Verstehen Sie DA aus der Perspektive der Netzwerkbandbreitenkosten und Speicherkosten
Die Hauptkosten von DA bestehen aus zwei Aspekten: Der eine wird als Kosten für die Netzwerkbandbreite bezeichnet und der andere als Speicherkosten.
In Bezug auf die Netzwerkbandbreitenkosten besteht beispielsweise im P2P-Netzwerk die aktuelle Block-Broadcast-Methode von Bitcoin und Ethereum darin, alle P2P-Knoten durch Klatsch (Broadcasting) zu senden, um allen mitzuteilen, dass ich einen neuen Block habe. So. Der Vorteil eines solchen Netzwerkansatzes besteht darin, dass er sehr sicher ist und alle Netzwerkknoten irgendwann ein Backup erhalten.
Der Nachteil besteht darin, dass es einen großen Mehraufwand an Netzwerkbandbreite und Latenz verursacht. Wir wissen, dass Ethereum nach dem POS-Upgrade innerhalb von 12 Sekunden einen Block erzeugt. Wenn der Block also zu groß ist und es länger als 12 Sekunden dauern kann, kann keine große Anzahl von Blöcken generiert werden und schließlich sinkt die gesamte Netzwerkbandbreite auf ein inakzeptables Maß. Sie können sich DA also als Lösung für das Bandbreitenproblem großer Datenmengen in der Blockchain vorstellen.
Der zweite Punkt sind die Speicherkosten. Tatsächlich führt die Ethereum Foundation viele Diskussionen zu diesem Aspekt. Beim Entwurf der Kernlösung ist es nicht möglich, die vom gesamten DA hochgeladenen Blockdaten ständig zu speichern.
Dies führt zu einer weiteren Frage. Wenn ich so viele Daten in der Kette habe, diese aber nach ein oder zwei Wochen vom Ethereum-Protokoll verworfen werden. Gibt es in diesem Prozess bessere dezentrale Lösungen zum Speichern dieser DA-Daten?
Dies ist auch eine unserer ursprünglichen Absichten bei der Gestaltung von EthStorage. Erstens müssen viele Rollups Daten über einen längeren Zeitraum speichern. Was den zweiten Aspekt angeht: Mit diesen Daten kann ich DA tatsächlich nutzen, um einige Full-Chain-Anwendungen besser abzuschließen. Zum Beispiel das NFT der gesamten Kette oder das Frontend vieler DApps, sogar einschließlich einer großen Anzahl von Artikeln oder Kommentaren, die von allen in sozialen Netzwerken geschrieben wurden. Diese können dann zu geringeren Kosten über das DA-Netzwerk in die gesamte Blockchain hochgeladen werden und erhalten die gleiche Sicherheit wie Ethereum L1.
Nachdem wir die gesamte Technologie von Ethereum DA untersucht und mit vielen Kernmitarbeitern von Ethereum diskutiert hatten, stellten wir fest, dass Ethereum in dieser Hinsicht über eine Speicherschicht verfügen muss, und es handelt sich um eine dezentrale Schicht, für die keine Verantwortung übernommen werden muss Ethereum selbst. Eine Speicherschicht, die das Protokoll aktualisiert, oder was wir als modulare Speicherschicht bezeichnen, um das Problem der langfristigen Datenspeicherung zu lösen.
Teil II: Diskussion über verschiedene DA-Systeme
Die Beziehung zwischen EIP-4844 und Danksharding und warum EIP-4844 bereitgestellt werden muss
Proto-Danksharding wird auch EIP-4844 genannt, was meiner Meinung nach als das nächste sehr große Upgrade von Ethereum angesehen werden kann. Es gibt einen sehr wichtigen Grund, warum 4844 fertig ist. Wenn Ethereum Gene die Upgrade-Route des Ethereum-Shardings, also die Zeit für Danksharding, schätzt, denken sie, dass die gesamte Upgrade-Zeit ziemlich lang ist, zum Beispiel kann es drei Jahre dauern 5 Jahre. Es war 2021, 2020.
Dabei sagen sie voraus, dass bald viele Rollups auf Ethereum laufen werden, aber aufgrund von Danksharding unterscheidet sich die von ihm bereitgestellte Datenschnittstelle völlig von der Calldata-Datenschnittstelle, die derzeit von Rollup verwendet wird. Dies führt dazu, dass viele Ethereum-Anwendungen aufgrund der neuen Schnittstelle nicht schnell aktualisiert werden können und die Vorteile von Danksharding nahtlos nutzen können.
Als ich letztes Jahr zu Devcon ging, erwähnte Vitalik auch, dass er hoffte, dass Ethereum diese Schicht 2 besser bedienen könne, damit sie ihre Verträge entwickeln und dabei dieselbe Danksharding-Schnittstelle verwenden könnten. Wenn Danksharding aktualisiert wird, können sie die neuen Vorteile von Danksharding direkt übernehmen, ohne ihre bestehenden und getesteten Verträge aktualisieren zu müssen.
EIP-4844 ist also eigentlich eine stark vereinfachte Version von Danksharding, die dieselbe Anwendungsschnittstelle wie Danksharding bietet, einschließlich eines neuen Opcodes namens Data Hash und eines neuen Datenobjekts namens Binary Large Objects, nämlich Blob.
Diese Datenobjekte sollen das Rollup im Voraus mit der von Danksharding bereitgestellten Datenstruktur kompatibel machen, d. h. Danksharding stellt ähnliche Konzepte wie denselben Daten-Hash und denselben Blob bereit. Aber durch EIP-4844 haben sie diese Ideen im nächsten Upgrade von Ethereum im Voraus umgesetzt. Daher können Sie sich in der gesamten Designfunktion von EIP-4844 deren Schnittstellen ansehen und beispielsweise Anweisungen vorkompilieren und neu hinzufügen. Dann können Sie bereits vage die Zukunft des gesamten Danksharding erkennen und sehen, wie es auf Ethereum angewendet werden kann Ein Prozess der Ebeneninteraktion.
In diesem Zusammenhang denkt Ethereum auch aus Anwendungssicht darüber nach, wie einige Upgrades im Voraus durchgeführt werden können, damit Anwendungen verschiedene Erweiterungstechnologien auf Ethereum besser nutzen können, ohne dass zusätzliche Upgrade-Kosten erforderlich sind.
Es gibt jedoch ein Problem: EIP-4844 löst nicht das Problem der Erweiterung des gesamten Blockraums, und Danksharding kann es lösen. Der aktuelle Ethereum-Blockplatz beträgt etwa 200 KB. Nach Danksharding liegt die geplante Größe in der Spezifikation bei 32 Megabyte, was einer fast 100-fachen Verbesserung entspricht. Das aktuelle EIP-4844 löst also nicht wirklich das Bandbreitenproblem der Blockchain auf dem Block.
Wie Dankharding das Problem der Blockraumerweiterung löst
Unter dem Design von 4844 wird während des Übertragungsvorgangs der Daten in der Kette immer noch die gleiche Methode wie bei den vorherigen Anrufdaten verwendet und die Übertragung erfolgt über das P2P-Netzwerk. Dann wird diese Übertragungsmethode letztendlich durch den physischen Engpass der gesamten P2P-Netzwerkbandbreite eingeschränkt. Die Entwurfsmethode von Danksharding hat die P2P-Netzwerkübertragung und dann die Datenabtasttechnologie verändert, sodass nicht jeder alle Blockdaten herunterladen muss, sondern auch weiß, dass diese Blockdaten heruntergeladen werden können.
Tatsächlich ähnelt es in gewisser Weise ein wenig der ZK-Methode. Durch Datenabtastung weiß ich, dass das Netzwerk von Danksharding bereitgestellte Blockdaten (32 Megabyte/Block) enthält. Aber ich muss nicht alle 32 Megabyte an Daten herunterladen, um sie lokal zu speichern. Dies ist auch möglich, wenn genügend Maschinenbandbreite und ausreichende Speicherplatzleistung vorhanden sind, aber für einen normalen Verifizierer muss er nicht alle 32 Megabyte an Daten herunterladen.
Einige Entwicklungen und Erfahrungen mit dem EIP-4844-Testnetz
Wir haben kürzlich unser internes EIP-4844-Testnetzwerk betrieben und den entsprechenden Testvertrag bereitgestellt, einschließlich Blob-Daten-Upload, Vertragsaufruf und Datenüberprüfung, den wir alle durchlaufen haben. Sobald EIP-4844 online ist, können wir unsere Verträge so schnell wie möglich bereitstellen.
Gleichzeitig hoffen wir auch, dass wir durch unsere aktuelle Zusammenarbeit mit einigen Entwicklern von Ethereum sowie einige unserer entwickelten Verträge Zeit für die Entwicklung verschiedener Rollups in Ethereum sowie für Schulungen und verschiedene Tools bereitstellen können.
Daher haben wir kürzlich eine Menge Code an Ethereum, das Tool-Set für EIP-4844, übermittelt, einschließlich neuer Smart Contracts zur Unterstützung von Opcode, da Solidity den Opcode von Daten-Hash immer noch nicht unterstützen kann. Wir synchronisieren uns also bereits mit einigen Entwicklern der Ethereum Foundation.
Anwendungen und Einschränkungen des Data Availability Committee (DAC)
Denn mehr als 90 % der von L2-Benutzern gezahlten Ausgaben werden für die Verfügbarkeit von Daten bezahlt. Um die Kosten für das Hochladen von Daten besser zu senken, haben viele L2-Projekte, darunter ZKSync, ZKPorter und Arbitrum Made Arbitrum Nova gestartet. Sie stellen ihre eigene Datenschicht bereit, indem sie ihr eigenes DAC Data Availability Committee bereitstellen.
Dieses Datenkomitee wird zusätzliches Vertrauen schaffen, um das gleiche zusätzliche Sicherheitsniveau wie Ethereum zu erreichen. Daher wählen sie bei der Auswahl des Datenausschusses in der Regel einige namhafte Datendienstleister oder namhafte Unternehmen aus, die sich an der Bewahrung dieser Daten beteiligen. Tatsächlich wird es jedoch viele Herausforderungen und Zweifel geben, da jeder denkt, dass dies tatsächlich ein Verstoß gegen den Grundsatz ist, dass kein Zugang zur Dezentralisierung möglich ist, was bedeutet, dass jeder teilnehmen kann. Die aktuelle Situation ist jedoch, dass die meisten Datenkomitees einige wenige Organisationen sind, die der Layer2-Projektpartei sehr nahe stehen.
Wie bei Arbitrum Nova gab es wahrscheinlich sechs oder sieben solcher Knoten, als ich es das letzte Mal betrachtete. Beispielsweise können die Datenkomitee-Knoten, die in der Cloud von Google oder Amazon laufen, diese Daten speichern und alle Ausführungskosten auf Arbitrum Nova bereitstellen. Ein Vorteil davon ist, dass seine aktuellen Ausführungskosten etwa ein Tausendstel der Kosten von Ethereum betragen. Denn er muss nicht alle Daten auf Layer 1 von Ethereum schreiben. Aber jetzt ist es immer noch relativ zentralisiert, so dass es mehr Sorgen um Anwendungen mit relativ hohem Wert geben wird, denn wenn es eine große Menge an Geldern gibt, Dutzende Millionen oder Hunderte Millionen Gelder, dann muss er davon ausgehen, dass die Daten der Datenausschuss ist nutzbar.
Als wir EthStorage entwickelten, hatten wir eigentlich keine Vorstellung von einem Datenausschuss. Während des Designprozesses hoffen wir, dass jeder teilnehmen und zum Datenlieferanten werden kann. Und sie verwenden verschlüsselte Beweise, um zu beweisen, dass sie diese Daten tatsächlich gespeichert haben. Aufgrund dieses Modells des Datenausschusses kann ich theoretisch, obwohl ich gesagt habe, dass ich sieben und acht Datenausschussknoten habe, tatsächlich nur ein Stück physischer Daten speichern, aber zeigen, dass ich sieben oder acht Adressen habe diese Daten bereitstellen.
Wie kann ich dann nachweisen, dass ich über genügend physische Kopien dieser Daten verfüge, um die Sicherheit der Daten zu gewährleisten? Tatsächlich ist es eine sehr wichtige Innovation, wenn wir EthStorage betreiben, und es ist auch das, was wir betonen, wenn wir zum ESP (Ecological Support Program) der Ethereum Foundation gehen, um zu predigen. Wir verwenden die von EthStorage verwendete ZK-Verschlüsselungstechnologie, um die von Layer2-Daten bereitgestellten Knoten zu schützen. Sie können ohne Erlaubnis beitreten und nachweisen, dass sie über so viele Kopien des Speichers verfügen, und können die Datensicherheit besser gewährleisten.
Daher denke ich, dass DAC tatsächlich eine sehr vorübergehende Lösung für die Kosten für das Hochladen von Daten auf Layer 1 ist. Wir glauben, dass wir durch einige Verschlüsselungstechnologien von EthStorage, gepaart mit einigen Beweisüberprüfungsmethoden für Layer-1-Verträge auf Basis von Ethereum, eine bessere Datenspeicherlösung bereitstellen können. Als nächstes werden wir mit der Einführung von Ethereum 4844 die Initiative ergreifen, diese innovativen Inhalte und die Ergebnisse ihrer Ausführung im Netzwerk mit Ihnen zu teilen.
Unterschied zwischen EthStorage und DAC
EthStorage ist eigentlich ein Ethereum-Speicher-Rollup, Storage Rollup. Dann können wir davon ausgehen, dass es sich bei einem Layer 2 nicht um eine Implementierung von Ethereum EVM handelt, sondern um eine sehr große Datenbank bzw. eine Schlüsselwertdatenbank. Es kann bis zu 10 TB, Hunderte von TB oder sogar Tausende sein, was einer solchen Datenbank auf PB-Ebene entspricht.
Wie stelle ich dann sicher, dass die Daten in meiner Datenbank die gleiche Sicherheit wie Ethereum erhalten? Der erste Schritt besteht zunächst darin, dass wir alle diese umfangreichen Daten in der Datenbank über DA auf Schicht 1 von Ethereum veröffentlichen müssen, damit jeder sehen kann, dass diese Daten in der gesamten DA-Schicht von Ethereum verfügbar sind. Wir können jedoch nicht garantieren, dass die Daten dauerhaft abgerufen werden können, da Ethereum DA die Daten in etwa zwei bis vier Wochen verwirft.
Der zweite Schritt erfolgt, nachdem wir die Daten hochgeladen und dann auf unseren Layer-2-Knoten gespeichert haben. Im Gegensatz zu DAC sind unsere Datenspeicherknoten nicht erlaubnisfrei und jeder kann teilnehmen. Und es beweist seine Lagerung und erhält dann die entsprechende Belohnung. Diese Methode basiert auf einer Reihe von Proof-of-Storage-Mechanismen, die wir eingerichtet haben. Natürlich ist dieser Proof-of-Storage-Mechanismus auch von einigen Entwurfsschemata von Proof-of-Storage-Systemen wie Filecoin und Arweave inspiriert. Wir benötigen jedoch ein Netzwerk und ein Beweissystem für das DA-Framework von Ethereum und die Smart Contracts von Ethereum, um entsprechende Speichernachweise zu erstellen. Daher glauben wir, dass wir in dieser Hinsicht einen ganz besonderen Beitrag zur gesamten Ökologie von Ethereum und sogar zur gesamten dezentralen Speicherung leisten.
Mechanismus des Speichernachweises
Grundsätzlich müssen alle Proof-of-Storage-Mechanismen, einschließlich Filecoin und Arweave, zunächst die Metadaten des Benutzers kodieren. Dieser Codierungsprozess muss jedoch entsprechend der Adresse des Datenanbieters codiert werden, das heißt, jeder Datenanbieter muss seine eigene unterschiedliche Adresse haben und dann entsprechend seiner Adresse und Metadaten codieren, um eine eindeutige Replik zu speichern. (nur kopieren) Sachen. Beispielsweise können die Daten von „Hello World“ auf vier oder fünf verschiedenen physischen Maschinen in einer herkömmlichen zentralen Datenbank oder in einem herkömmlichen verteilten System gespeichert werden, wobei es sich jeweils um „Hello World“ handelt. Aber in EthStorage werden vier oder fünf oder zehn oder zwanzig gespeichert, und seine Hallo-Welt wird entsprechend der Adresse jedes Datenanbieters in unterschiedliche Daten codiert und dann an verschiedenen Orten gespeichert.
Dies hat den Vorteil, dass wir mithilfe kryptografischer Mechanismen nachweisen können, dass es so viele verschiedene Adressen gibt, die unterschiedliche Speicheranbieter sind. Sie verschlüsselten die Daten und erstellten auf der Grundlage der verschlüsselten Daten entsprechende Speichernachweise. Grundsätzlich ähneln Filecoin und Arweave diesem. Aber sie beziehen sich nur auf statische Daten, wir zielen jetzt auf die heißen Daten von Ethereum DA ab. Und durch den Ethereum Smart Contract kann überprüft werden, dass es so viele physische Kopien dieser Daten gibt. Das heißt, wir werden für alle codierten Daten beweisen, dass diese codierten Daten in diesem Netzwerk gespeichert sind und die Daten, die den einzelnen codierten Daten entsprechen, unterschiedlich sind, da sie durch die Adressen verschiedener Speicheranbieter codiert werden.
Grundsätzlich optimieren und verbessern wir einige bestehende dezentrale Speicherideen während des Designprozesses. Gleichzeitig müssen wir jedoch auch viele Optimierungen an der DA-Lösung von Ethereum vornehmen, einschließlich der Änderung dynamischer Daten, um die Gaskosten für Ethereum-Verträge effektiv nachzuweisen und zu optimieren. Es gibt also viele hochmoderne Technologien und Forschungsarbeiten, die durchgeführt werden müssen.
Wie EthStorage den erlaubnisfreien Speichernachweis verwaltet
In Ethereum gibt es eine Art Knoten namens Archivknoten, der die historischen Aufzeichnungen aller Transaktionen in Ethereum, einschließlich des Zustands der Welt, speichert. Eine große Herausforderung in Danksharding besteht jedoch darin, dass der Danksharding-Plan etwa 80 TB Daten pro Jahr generieren wird. Unter der Annahme, dass Ethereum drei bis vier Jahre läuft, wird es 200 bis 300 TB an Daten generieren, Tendenz steigend. Nun, das stellt den Archivknoten tatsächlich vor große Herausforderungen, da er beim Betrieb des Archivknotens nicht über eine zusätzliche Token-Ökonomie verfügt, um alle zum Speichern dieser Daten zu motivieren.
EthStorage muss zunächst das Problem der Token-Anreize für die dauerhafte Speicherung von Daten lösen. In diesem Zusammenhang haben wir tatsächlich das Discounted-Cashflow-Modell von Arweave übernommen, um Anreize zu schaffen. Gleichzeitig ist es sehr effizient, den gesamten Smart Contract ausführen zu lassen.
Der zweite Grund ist sein erlaubnisloser Ansatz. Denn unser Anreizdesign regt 10, 50 oder sogar 100 Knoten dazu an, Daten im Netzwerk zu speichern. Jeder Knoten kann also jeden von ihnen kontaktieren, die entsprechenden Daten synchronisieren und dann zum Datenspeicherpartner werden. Möglicherweise gibt es auch einige optimierte Designs für mehr Datenanreize.
Drittens: Da der Speicherknoten alle Daten gleichzeitig speichern muss, können es auf lange Sicht Hunderte von Terabyte oder sogar ein PB an Daten sein. Für einen einzelnen Knoten sind die Kosten also sehr hoch. Deshalb haben wir hier eine weitere Sache namens Data Sharding eingeführt. Auf diese Weise muss für normale Knoten nur ein Kapazitätsraum von 4 TB vorhanden sein (unser aktuelles Design ist natürlich 4 TB, es kann jedoch in Zukunft auf 8 TB aufgerüstet werden) und es kann ein Teil der Archivierung gespeichert werden Daten im Netzwerk, aber wir verwenden auch einige Anreizmechanismen, um sicherzustellen, dass alle diese Daten, nachdem alle diese Daten schließlich zusammengestellt haben, alle in unserem Layer-2-Netzwerk gespeichert werden können.
Hier gibt es also viele Probleme, wie zum Beispiel das Problem zu vieler Daten, die durch Archivierungsknoten verursacht werden, das Anreizproblem von Token und das Problem des dezentralen Zugriffs … Wir können diese Probleme durch Ethereum lösen. Der Smart Contract wird auf Ebene 1 bereitgestellt erkenne es automatisch. Für uns stellen wir also lediglich ein Datennetzwerk bereit, sodass jeder Daten herunterladen und ein Speicherzertifikat erstellen kann, solange er über genügend Datenkosten verfügt, diese an das Ethereum-Netzwerk übermitteln und dann die entsprechende Rendite erzielen kann. Unser gesamter Vertrag wurde im Grunde entworfen und wir haben mit dem Debuggen auf dem 4844 Devnet von Ethereum begonnen.
