Einleitung

Mit der rasanten Entwicklung der Blockchain-Technologie steht die monolithische Blockchain vor ernsthaften Herausforderungen in Bezug auf Skalierbarkeit und Interoperabilität. Auf Mainstream-Plattformen wie Ethereum führt der Anstieg der Benutzer zu hohen Transaktionsgebühren und beeinträchtigt die Verbreitung dezentralisierter Anwendungen erheblich. Um diesen Problemen entgegenzuwirken, suchen Entwickler ständig nach innovativen Lösungen, und die Einführung von Avail bietet eine neue Richtung zur Lösung dieses Problems. Nach dem Upgrade auf Cancun sinken die Transaktionskosten im Ethereum-Ökosystem erheblich, während modulare Technologien zu einer wichtigen Erzählung der Blockchain-Entwicklung werden. Im ersten Halbjahr führten modulare Blockchains wie Celestia und EigenDA den Trend an, und am 23. Juli startete Avail das Avail DA Mainnet und machte so einen bedeutenden Schritt im Bereich Modularisierung.

Als Kernprojekte der modularen Blockchain haben Avail, EigenDA und Celestia zwar ähnliche Dienstleistungen, unterscheiden sich jedoch in Infrastruktur, Ausführungsmodus und Token-Ökonomie-Design.

Team Background

Avail wurde aus Polygon geboren und wurde 2023 zu einer unabhängigen Entität. Bevor das Thema Datenverfügbarkeit (DA) in der Branche in den Fokus rückte, arbeitete Anurag Arjun mit anderen zusammen, um die Plasma-Chain zu entwickeln, mit dem Ziel, die Skalierbarkeitsprobleme von Ethereum zu lösen. Obwohl diese Chain Polygon geholfen hat, einen Umsatz von 19 Milliarden US-Dollar zu erzielen, erwies sie sich nicht als ideale Skalierungslösung. Während dieses Prozesses wurde Anurag allmählich bewusst, dass alle Blockchains letztendlich auf dieselben Hindernisse stoßen werden - das Problem der Datenverfügbarkeit. In Rollup-Transaktionskosten sind etwa 80% mit DA verbunden, daher überlegte er, dass der Aufbau einer kosteneffizienten DA-Schicht möglicherweise die Skalierungsprobleme mehrerer Blockchains lösen könnte.

Diese Idee ist nicht einzigartig für Anurag. Die meisten L1-Blockkettenprojekte versuchen auch, eine DA-Schicht zu werden. Ethereum erkundet DA-Lösungen über die Rollup-Roadmap, und andere L1-Projekte innovieren ebenfalls in diesem Bereich. Anurag glaubt, dass eine speziell für DA konzipierte L1-Blockkette einzigartige Vorteile bietet.

Anurag lernte während seiner Zeit bei Matic den aktuellen Mitbegründer von Avail, Prabal Banerjee, kennen, der zu dieser Zeit an seinem Doktortitel in Kryptografie und Sicherheit arbeitete und später dem Team als Forscher beitrat. Gemeinsam engagierten sie sich für den Aufbau einer skalierbaren DA-Schicht. Mit dem Aufkommen der Zero Knowledge Proof (Null-Wissens-Beweis) (ZK) -Technologie kombinierten sie das blockchain design von Gültigkeitsnachweis und nutzten Anurags Erfahrung bei der Schaffung von Protokollen auf Polygon, um die Lösung des Datenverfügbarkeitsproblems weiter voranzutreiben.

Vom Einzelstrang zur Modularisierung

Quelle: Avail Offizielle Dokumentation

Da der Wettbewerb um die zugrunde liegenden Rechenressourcen immer härter wird, werden die Probleme der gleichzeitigen Verarbeitungsausführung, Abrechnung, Sortierung und Datenverfügbarkeit der einzelnen Kette von ETH Fang allmählich offengelegt, was zu einer eingeschränkten Skalierbarkeit führt. Die Branche beginnt, die Single-Chain-Architektur zu überdenken und nach neuen Lösungen zu suchen.

Durch die Verlagerung der Ausführung off-chain führen Rollups eine modulare Architektur ein, die die Überlastung des L1-Netzwerks effektiv lindert, die Transaktionskosten der Benutzer senkt und die Transaktionsverarbeitung verbessert. Obwohl diese Architektur die Effizienz von on-chain erheblich verbessert, bleibt der begrenzte Blockraum von Ethereum ein Engpass, der bei steigender Nachfrage erneut auftreten könnte. Derzeit sind Dapps auf L1 für Datenübertragung und Abrechnung angewiesen, während Rollups L1 nutzen, um diese Prozesse zu bewältigen. Obwohl Rollups die Nutzung des Blockraums optimieren, bleibt der Blockraum weiterhin knapp.

Bei der Analyse der L1-Transaktionen von ETH Rollups stellte sich heraus, dass die DA-Kosten 90% der Gesamtkosten ausmachen, was auch die größte Ausgabequelle für Rollups ist. Der Großteil der Einnahmen wird für die Bezahlung der Gebühren für die Veröffentlichung von L1-Transaktionsdaten verwendet.

Ähnlich wie Rollups, die die Ausführung off-chain durchführen, ermöglicht die Avail-Architektur die Verlagerung der Datenverfügbarkeit auf eine dedizierte Ebene. Avail bietet Entwicklern eine flexible, benutzerfreundliche und sichere Datenverfügbarkeitsschicht, die die Herausforderungen der Skalierbarkeit, Governance und Dezentralisierung löst.

Die modulare Struktur von Avail

Avail zielt darauf ab, mit seinem modularen Technologie-Stack, der Datenverfügbarkeit, Aggregation und gemeinsamer Sicherheit kombiniert, die Web3 zu beschleunigen. Mit Hilfe von Avail wird ein Rollup veröffentlicht, das Daten für Transaktionen außerhalb der Chain bereitstellt (für Optimistic Rollup wird es als Optimium bezeichnet). Validiums und Sovereign Rollups können auf die von Avail bereitgestellten Dienste zur Datenverfügbarkeit und Sortierung mit geringem Vertrauen angewiesen sein.

Hier ist der kurze Ablauf, wie Avail Validiums und Souveräne Rollups unterstützt.

1. Transaktion einreichen: Wie bei den meisten vorhandenen Rollups werden Transaktionsaufrufdaten chargenweise verarbeitet, und der Status-Root wird an Avail DA übermittelt und durch eine eindeutige App-ID dargestellt, die die Herkunft des Rollups kennzeichnet.
2. Datenexpansion und Löschcodierung: Die an Avail DA übermittelten Transaktionen werden mittels Löschcodierung verarbeitet, wobei der Block in n ursprüngliche Blöcke aufgeteilt und auf 2n Blöcke erweitert wird. Es können beliebige n Blöcke aus den 2n Blöcken ausgewählt werden, um die Daten wiederherzustellen.
3. Die Verpflichtung zur Erstellung: Avail DA erhält redundante Daten und wendet KZG-Polynomverpflichtungen auf jeden Block an. Diese Verpflichtungen dienen als Verschlüsselungsnachweis für die Datenintegrität, um sicherzustellen, dass die gespeicherten Daten korrekt und unveränderlich sind.
4. Blockverbreitung: Prüfer erhält Blocks mit KZG-Verpflichtungen und generiert diese Verpflichtungen neu, um ihre Richtigkeit zu überprüfen und einen Konsens über den Block zu erzielen.
5. Light Client'网络：Light Client'利用 DAS 验证Block数据的完整性。这是通过对每个采样单元的Block头中的承诺，进行 KZG 多项式开口验证来实现。这消除了重建完整 KZG 承诺或依赖Betrugsnachweis的需求。
6. Nachweisprüfung: Der Light Client' führt die Nachweisprüfung durch, indem er Nachweise auf Einheitsebene generiert, die aus der Datenmatrix stammen.

Da Avail Gültigkeitsnachweis anstelle von Betrugsnachweis verwendet, kann der Light Client die Verfügbarkeit und Korrektheit der Daten nach Abschluss des endgültigen Status überprüfen. Darüber hinaus gewährleistet das Light Client-Netzwerk die hohe Verfügbarkeit der Daten durch die Stichprobenahme der Datenverfügbarkeit. Mit der Zunahme von weiteren Light Clients wird die Fähigkeit zur Stichprobenahme gestärkt, um größere Blockgrößen zu unterstützen. Benutzer können sogar diese Light Clients auf Laptops oder Mobiltelefonen ausführen, um die Netzwerkeffizienz weiter zu verbessern.

Quelle: Avail Offizielle Dokumentation

Technische Merkmale

Anwendungsszenarien von Light Client'

Derzeit verlassen sich viele Anwendungsszenarien auf Mittelsmann, um einen vollständigen Knoten zu unterhalten, und die Benutzer interagieren indirekt über diese Mittelsmann mit der Blockchain, anstatt direkt darauf zuzugreifen. Aufgrund fehlender Garantien für die Datenverfügbarkeit hat sich Light Client noch nicht zu einer idealen Alternative zu herkömmlichen Architekturen entwickelt. Durch die Lösung dieses Problems ermöglicht Avail mehr Anwendungen, direkt mit dem Blockchain-Netzwerk zu interagieren, ohne auf Mittelsmann angewiesen zu sein. Obwohl Avail den Betrieb mit vollen Knoten unterstützt, müssen die meisten Anwendungen keine vollständigen Knoten ausführen oder benötigen nur wenige Knoten, um reibungslos zu funktionieren.

Datenverfügbarkeitsstichproben (DAS)

Ähnlich wie bei traditionellen Light Clients muss der Light Client von Avail nur Blockheader-Daten herunterladen. Darüber hinaus überprüfen sie die Korrektheit, indem sie einen Teil der Blockdaten für die Datenverfügbarkeitsprüfung zufällig auswählen. Durch die Kombination von Fehlerkorrekturcodes und KZG-Polynomverpflichtungen garantiert der Light Client nahezu 100%ige Datenverfügbarkeit ohne Betrugsnachweis und erfordert nur wenige feste Abfragen.

Lösch-Codierung与数据可用性

Lösch-Codierung stellt durch Aufsplittung der Daten sicher, dass der ursprüngliche Inhalt auch dann wiederhergestellt werden kann, wenn ein Teil der Daten verloren geht. In einer Blockkettenanwendung bedeutet dies, dass das System in der Lage ist, Daten wiederherzustellen, selbst wenn ein bösartiger Akteur versucht, einen Teil der Daten zu verbergen. Dieser Mechanismus erhöht die Zuverlässigkeit der Datennutzung erheblich, stärkt die Fähigkeit zur Verhinderung von Datenmanipulation und erhöht die Verlässlichkeit der Datenintegrität.

KZG Verpflichtung

Das KZG-Verfahren wurde 2010 von Aniket Kate, Gregory M. Zaverucha und Ian Goldberg entwickelt und ist eine effiziente Methode der Polynomverpflichtung, die in den letzten Jahren in der Architektur des Null-Wissens-Beweis (Zero Knowledge Proof) weit verbreitet ist. Im Avail-Framework hat das KZG-Verfahren folgende Vorteile:

1. Versprechen Sie den Wert auf einfache Weise und zeichnen Sie ihn in der Kopfzeile des Blocks auf;
2. Ermöglicht es dem 'Light Client', die Verfügbarkeit der Daten zu überprüfen;
3. Seine Bindungseigenschaften zur Verschlüsselung machen die Erzeugung falscher Versprechen nahezu unmöglich und reduzieren den Bedarf an Betrugsnachweis.

Avail 的统一层

Avail hat kontinuierlich an der Entwicklung der Avail-Plattform gearbeitet, die aus einem einheitlichen Technologie-Stack besteht, beginnend mit der Verfügbarkeit von Grunddaten (DA) über die Nexus-Einheitsschicht und der zusätzlichen Sicherheitsschicht Fusion. Durch die Unterstützung einer erweiterbaren Datenverfügbarkeitsschicht wird Avail das gesamte Web3-Ökosystem nutzen, um eine sofortige und zuverlässige Datenverfügbarkeit zu gewährleisten, indem der Gültigkeitsnachweis mit Hilfe von KZG-Polynom-Verpflichtungen genutzt wird, um das Zusammenführen zu ermöglichen, zu verbinden, sicher zu halten und anzupassen.

Avail DA

Quelle: Avail Offizielle Dokumentation

Avail DA ist eine grundlegende Architektur, die speziell für die Optimierung der Datenverfügbarkeit entwickelt wurde und die GRANDPA- und BABE-Konsens-Algorithmus verwendet, im Gegensatz zu anderen DA-Schichten. Diese Gestaltung ermöglicht es Avail DA, hoch skalierbar zu sein und durch Datenverfügbarkeitsstichproben (DAS) und Gültigkeitsnachweis eine zuverlässige Datensicherung zu niedrigen Kosten zu gewährleisten.

Avail DA hat den Kernpriorisierung und Veröffentlichung von Transaktionen, während es den Benutzern ermöglicht, die Verfügbarkeit von Blockdaten zu überprüfen, ohne den gesamten Block herunterzuladen. Die Datenunabhängigkeit von Avail DA ist eine seiner definierten Funktionen. Es unterstützt verschiedene Ausführungsumgebungen, einschließlich EVM, WASM und benutzerdefinierte neue Laufzeiten, um vielseitige Grundlagen für verschiedene Blockkettenanwendungen bereitzustellen.

Avail Nexus

Quelle: Avail Offizielle Dokumentation

Avail Nexus ist als zweite Säule konzipiert und bietet ein ungenehmigtes Framework, das darauf abzielt, das Web3-Ökosystem zu vereinheitlichen. Es verbindet interne und externe Blockchains, stützt sich auf Avail DA als Vertrauensgrundlage und fungiert als Validierungszentrum. Nexus umfasst ZK-rollup, das Proof-Aggregation, Validierungsschicht, Sortierauswahlmechanismus und Slot-Auktionsmechanismus integriert. Nexus reicht regelmäßig aggregierte Beweise zur Überprüfung an die Ethereum- und Avail DA-Schicht ein, um die Zuverlässigkeit von Cross-Chain-Interaktionsoperationen zu gewährleisten.

Avail Fusion

Quelle: Avail Offizielle Dokumentation

Der dritte Pfeiler, Avail Fusion, bietet zusätzliche Sicherheit für das Avail-Ökosystem und das gesamte Web3. Die Kernidee besteht darin, dass auf makroökonomischer Ebene ein einheitliches System einheitliche Sicherheit benötigt. Die Fusion Security trägt durch die Nutzung von lokalen Vermögenswerten in etablierten Ökosystemen wie BTC und ETH zur Sicherheit des Avail-Konsenses bei. Dieser Mechanismus versucht erstmals, durch externe Token in verschiedenen On-Chain-Blöcken Konsens zu erzielen.

Avail Fusion unterstützt zwei Arten von Staken': etablierte Krypto-Vermögenswerte und aufstrebende Rollup-Token. Derzeit enthält der Prototyp von Fusion zwei Staken'-Module: eines wird on-chain im Avail-Block ausgeführt, das andere ist ein Modul für die Asset-Konvertierung. Beachten Sie, dass der erste öffentliche Prototyp von Avail Fusion noch in Entwicklung ist.

Node-Typ von Avail

Obwohl die Architektur von Avail sich von herkömmlichen monolithischen Blockchains unterscheidet, unterstützt sie dennoch verschiedene Knotentypen, einschließlich Full Node, Light Client' , Archivknoten und Validierungsknoten.

• Full Node：Full Node ist für das Herunterladen und Überprüfen der Korrektheit des Blocks verantwortlich, nimmt jedoch nicht am Konsensprozess teil. Ihre Existenz bietet dem System zusätzliche Redundanz und Elastizität, ist jedoch keine notwendige Komponente.
• 验证Node：验证Node通过生成Block、决定交易是否包含并维护交易顺序，帮助网络达成Konsens。
• Light Client': Light Client' ermöglicht es Benutzern, ohne die Ausführung eines Full Nodes mit der Datenverfügbarkeitsschicht (DA) von Avail zu interagieren und remote Peers nicht vertrauen zu müssen. Dies wird durch die Ausführung von Datenverfügbarkeitsstichproben (DAS) bei jedem neu erstellten Block erreicht.
• RPC Node：RPC Node provides a remote interactive API, serving as a gateway for developers and external users to interact with the Avail network.

'Light Client' überwacht bestätigte Blöcke im Avail-Netzwerk und führt eine Datenverfügbarkeitsstichprobe (DAS) für voreingestellte Datenknoten im neuen Block durch. Nach erfolgreicher Validierung berechnet das System die Bestimmtheit einer bestimmten Anzahl von Datenknoten im Block basierend auf dem vom Benutzer benötigten Vertrauensniveau.

Wirtschaftsmodell

Token分配

Mit der Veröffentlichung von AvailDA Mainnet hat das Team AVAIL Token an berechtigte Benutzer Airdrop gesendet, mit einer Gesamtversorgung von 100 Milliarden. Davon wurden 6% für Airdrop und öffentliche Zuteilung, 30% für die Entwicklung des Ökosystems, 23,88% für die Gemeinschaft und Forschung, 14,12% für Investoren und 20% für Kernbeitragende verteilt.

Quelle: Avail Offizielle Dokumentation

Staken'

Die Verwendung von AVAIL Token umfasst Öko-Governance und Staken' von Liquidität. Obwohl das Governance-Konzept vom offiziellen noch nicht detailliert bekannt gegeben wurde, kann jeder AVAIL in der gesamten Infrastruktur von Avail staken', um Staken'-Belohnungen zu erhalten.

Im Hinblick auf Staken' hat Avail den Nominierter Proof of Stake (NPoS) Konsens-Mechanismus übernommen, der aus dem Substrat-Ökosystem stammt. Staken' spielt eine entscheidende Rolle bei NPoS. Durch Staken' AVAIL Token unterstützen Benutzer die Netzwerksicherheit und erhalten entsprechende Belohnungen. Je mehr Staken'-Tokens vorhanden sind, desto höher ist die Netzwerksicherheit, da die Kosten für einen Angriff auf das Netzwerk steigen.

Die Anwendungsszenarien von Staken' sind wie folgt:

• Avail DA Staken': Benutzer können AVAIL Token an Prüfer oder Staken'-Pools staken, um die Netzwerksicherheit zu gewährleisten und verschiedene Anwendungsfälle wie Web3-Spiele und Dezentrales Finanzwesen-Plattformen zu unterstützen. Staken'-Teilnehmer erhalten Belohnungen.
• Avail Nexus Staken': Der Sortierer muss AVAIL Token staken, um an der Einreichung und Sortierung von Transaktionen teilzunehmen. Sortierer, die sich gut bewähren, erhalten Belohnungen, während solche, die sich schlecht bewähren, bestraft werden.
• Avail Fusion Staken': Neben AVAIL Token kann auch andere Hauptverschlüsselungswerte wie BTC und ETH gestaken' werden, um die Netzwerksicherheit weiter zu verbessern. Staker erhalten entsprechende Rückzahlungen.

Zu beachten ist, dass Benutzer, die Staken' aufheben möchten, den Entbindungsprozess von 28 Tagen abschließen müssen, währenddessen AVAIL Token nicht verwendet oder übertragen werden können.

Herausforderungen, vor denen wir stehen

Rollup Wettbewerbsrisiko

Die Entwicklung von Avail könnte durch große allgemeine Rollups beeinflusst werden, die über ein etabliertes Ökosystem und interne Interoperabilitätslösungen verfügen und möglicherweise nicht mehr von externen Interop-Systemen abhängig sind, was den Wert des Avail Nexus schwächen könnte. Die hohe Anzahl an anwendungsspezifischen Rollups und die hohe Fragmentierung, mit der Benutzer konfrontiert werden, machen dies jedoch unwahrscheinlich.

Wettbewerb um DA-Lösungen

Mit der Einführung mehrerer DA-Lösungen auf dem Markt wie Celestia und EigenDA hat Ethereum auch über EIP-4844 die Verwendung von Blobs als Datenveröffentlichungsoption eingeführt. Der harte Wettbewerb zwischen den DA-Schichten und die Sensibilität von Rollup gegenüber den Kosten für die Datenveröffentlichung könnten zu einem Rückgang führen, was Rollup dazu zwingt, sich für bewährte DA-Lösungen zu entscheiden oder sich nach der vollständigen Umsetzung von Danksharding auf Ethereum zu verlassen.

Risiken der gemeinsamen Sicherheit

Der von Avail Fusion bereitgestellte gemeinsame Sicherheitsmodus hängt von verschiedenen Token und dem Staken' von AVAIL Token ab, was möglicherweise Bedenken der Benutzer hinsichtlich der Sicherheit verschiedener Vermögenswerte mit sich bringt. Einige Entwickler bevorzugen möglicherweise eine Sicherheitsgarantie für einzelne Vermögenswerte wie ETH oder BTC anstatt auf mehrere Token angewiesen zu sein. Darüber hinaus könnten Entwickler auf wirtschaftlich sicherere DA-Lösungen umsteigen, wenn Avail Fusion nicht genügend Sicherheit bietet.

Wettbewerb im Wertschöpfungsdienste-Ökosystem

Andere Staken' oder Sicherheitsprodukte können möglicherweise spezielle Mehrwertdienste für Rollup-Ökosysteme bieten. Zum Beispiel könnte EigenLayer Funktionen wie Dezentralisierung der Sortierung, Datenverfügbarkeit und schnelle Endgültigkeit bieten, was seine Wettbewerbsfähigkeit steigern würde.