Sie haben vielleicht bemerkt, dass fast jeder Entwickler an der KZG-Zeremonie teilnimmt und sie retweetet. Was ist also die KZG-Zeremonie?

Vereinfacht ausgedrückt handelt es sich bei der KZG-Zeremonie um die Vertrauenseinrichtung des EIP-4844-KZG-Engagements, und EIP-4844 ist die Vorabversion des vollständigen Ethereum-Shardings.

1. Sharding: Eine langfristige Lösung für die Skalierung von Ethereum

  • Während Rollups Ethereum von der Ausführungsebene aus skalieren, verbessert Sharding die Skalierbarkeit und Kapazität von Ethereum im Hinblick auf die Datenverfügbarkeit.

  • Das folgende Trenddiagramm zeigt, dass die durchschnittliche Blockgröße trotz der schnellen Iteration von Ethereum in diesen Jahren um etwa 90 KB schwankt. Obwohl Rollups die Netzwerküberlastung erheblich verringern, wird die Gesamtleistung immer noch durch die Datenspeicherkapazität der Schicht 1 eingeschränkt.

  • Unter Berücksichtigung der Sicherheit und der Komplexität der Implementierung wird das Sharding in mehrere Phasen unterteilt, zu denen Proto-Danksharding und Danksharding gehören. Der gesamte Prozess könnte mehrere Jahre dauern.

  • Angesichts des aktuellen Speicherschemas können nur wenige Hochleistungshardware als Knoten teilnehmen. Nach der Implementierung des Shardings müssen Knoten nicht mehr den gesamten Inhalt historischer Daten speichern, was die Sicherheit von Ethereum nutzt, indem die Schwelle, ein Knoten zu werden, gesenkt wird (niedrigere Datenspeicherkosten und ein höherer Grad an Dezentralisierung).

2. EIP-4844: Bemerkenswerte kurzfristige Rendite, eine Vorabversion des vollständigen Ethereum-Shardings

EIP-4844 = Proto-Danksharding；

Da die vollständige Implementierung von Sharding noch zu komplex ist und Jahre dauern könnte, ist Proto-Danksharding der beste Zwischenplan, um die Überlastung von Ethereum kurzfristig zu reduzieren.

2.1 Proto-Danksharding-Zusammenfassung

Proto-Danksharding führt einen neuen Transaktionstyp namens Blob-Carry-Transaktion ein. Rollups profitieren von diesem Update und können „Blob“ verwenden, um Daten zu L1 zu übertragen und sie zu relativ geringeren Kosten provisorisch zu speichern. Die Größe eines Blobs ist viel größer als die aktuellen Aufrufdaten.

Über Blob:

  • Jede Transaktion kann höchstens 2 Blobs enthalten

  • Jeder Block enthält normalerweise 8 Blobs mit einer Kapazität von 1 MB.

Ein Block kann 16 Blobs enthalten, was einer Blockgröße von 2 MB entspricht.

  • Ein Blob wird nicht wie Anrufdaten dauerhaft als Verlaufsprotokoll gespeichert.

  • Beim Entwurf von Proto-Danksharding müssen Knoten weiterhin den vollständigen Dateninhalt herunterladen und die Datenverfügbarkeit überprüfen.

2.2 Blob-tragende Transaktion im Detail

Funktionalität

Die Funktionalität eines Daten-Blobs ähnelt der von Calldata, wodurch das Rollup Transaktionsdaten und Nachweise an L1 übertragen kann.

Kosten

Die ursprüngliche Absicht des Blobs besteht darin, hohe TPS in Rollups zu unterstützen. Im Vergleich zu Anrufdaten, die On-Chain-Speicher verwenden, werden diese Daten-Blobs nur heruntergeladen und für einen bestimmten Zeitraum gespeichert. Daher werden die Gasausgaben für Rollups zur Sicherstellung der Datenverfügbarkeit voraussichtlich geringer ausfallen.

Kapazität

Die Größe jedes Blobs beträgt 125 KB.

2.3 Der Wert und die Herausforderung einer Blob-tragenden Transaktion

Wert

Es ist sicher, dass die Entstehung von Blobs dazu führt, dass Transaktionsdaten zu einer Art Cache werden, was den Bedarf an Speicherhardware für Knoten weiter senkt und die Gasgebühr senkt, indem Ethereum zusätzlichen Datenspeicher zur Verfügung stellt.

Herausforderung: Berechnen wir den Hardwarebedarf

Tatsache ist, dass die aktuelle Blockgröße etwa 90 KB beträgt, die Größe eines Blobs jedoch 125 KB erreichen kann

Gemäß dem Design von EIP-4844 beträgt die Größe jedes Steckplatzes normalerweise 1 MB, was bedeutet, dass die Gesamtdatengröße wie folgt berechnet werden kann:

1 MB/Block * 5 Block/Minute * 43200 Minuten/Monat * 12 Monate/Jahr = 2,47 TB pro Jahr

Es ist offensichtlich, dass der jährliche Datenzuwachs weitaus größer ist als die gesamten Ethereum-Daten, was darauf schließen lässt, dass dieser naive Datenspeicherplan nicht effizient ist.

Was kann optimiert werden?

Kurzfristig muss jeder Knoten immer noch den gesamten Inhalt historischer Daten speichern, aber die Konsensschicht ist mit einem Schema implementiert, das vorsieht, dass die Blob-Daten in einem bestimmten Zeitraum (30 Tage oder 1 Jahr, TBD) gelöscht werden.

Für den langfristigen Nutzen muss EIP-4444 implementiert werden, was darauf hinweist, dass Knoten nicht mehr zur Speicherung vollständiger Daten verpflichtet sind. Stattdessen wird ein neuer Mechanismus eingeführt, der es den Knoten ermöglicht, nur Teile der Daten für eine bestimmte Zeit zu speichern, was auf ein sogenanntes Verlaufsablaufschema zurückgreift.

2.4 KZG-Verpflichtung

KZG Commitment ist ein Polynom-Commitment-Schema, das von EIP-4844 Proto-Danksharding übernommen wurde

Die KZG-Zeremonie ist der Prozess der Vertrauensbildung für das KZG-Engagement, an dem mehr als 30.000 Teilnehmer teilnehmen.

2.4.1 Was ist KZG-Engagement?

KZG ist eine Abkürzung von Aniket Kate, Gregory M. Zaverucha und Ian Goldberg, die 2010 den Aufsatz „Constant-Size Commitments to Polynomials and Their Applications“ über Polynom-Commitments veröffentlicht haben. KZG Commitment wird im Plonk-Stil zk-snark wild angewendet Protokoll.

Bezugnehmend auf das Diagramm aus Dankrads Präsentation ähnelt die KZG-Wurzel der Merkle-Wurzel, außer dass die KZG-Wurzel auf ein Polynom festlegt, bei dem jede Position auf diesem Polynom liegt. Basierend auf dem Proto-Danksharding-Szenario schreibt KZG Root einen Datensatz vor, bei dem jeder einzelne Datenpunkt als Teil des gesamten Satzes verifiziert werden kann.

Ein kurzer Blick darauf, wie das KZG-Engagement intern funktioniert

  • Prüfer: Verantwortlich für die Berechnung des Engagements. Aus Sicherheitsgründen kann ein Prüfer das gegebene Polynom nicht ändern und die Verpflichtung gilt nur für das aktuelle Polynom;

  • Prüfer: Verantwortlich für die Überprüfung der vom Prüfer gesendeten Verpflichtung.

2.4.2 KZG-Zeremonie (vertrauenswürdiges Setup)

Der Ablauf der KZG-Zeremonie

Jeder kann als Teilnehmer an der KZG-Zeremonie teilnehmen und das Geheimnis einbringen. Das neu hinzugefügte Geheimnis wird mit der vorherigen Ausgabe gemischt, um ein neues Ergebnis zu bilden und schließlich einen SRS für die KZG-Commitment-Trust-Einrichtung zu generieren. (Schauen Sie sich zum besseren Verständnis das von Vitalik bereitgestellte Diagramm an.)

Vertrauenseinrichtung

  • Bei der KZG-Zeremonie handelt es sich um eine weit verbreitete Vertrauensstruktur mit mehreren Teilnehmern namens „Power-of-Tau“.

  • Dieses Setup folgt dem 1-von-N-Vertrauensmodell, was bedeutet, dass die Gültigkeit des Setups garantiert werden kann, egal wie viele Teilnehmer zum Prozess der Generierung des endgültigen Setups beitragen, solange eine Person ihr Geheimnis behält.

Bedeutung der KZG-Zeremonie

  • Der Wert des Vertrauensaufbaus der KZG-Verpflichtung kann wie folgt interpretiert werden: einen Parameter zu generieren, der für jede einzelne Ausführung des kryptografischen Protokolls notwendig ist

  • Wenn der Prüfer die Verpflichtung berechnet, ist die KZG-Verpflichtung C = f(s)g1, wobei f die Bewertungsfunktion und s das Endergebnis des KZG-Vertrauensaufbaus ist. Daher ist das letzte Geheimnis, das durch die aktuelle KZG-Zeremonie generiert wird, von entscheidender Bedeutung für die folgende Implementierung des Shardings.

2.4.3 Vorteil des KZG-Engagements

  • Kosten

  • Das KZG-Engagement weist eine geringere Komplexität auf und kann effizient überprüft werden.

  • Es ist kein zusätzlicher Nachweis erforderlich, was zu geringeren Kosten führt und den Bandbreitenbedarf verringert.

  • Noch geringere Kosten durch Nutzung der Punktevaluierungs-Vorkompilierung.

  • Sicherheit

  • Wenn der Fehler auftritt, wird nur der Blob infiziert, der der aktuellen Verpflichtung entspricht, und es gibt keinen weiteren Ketteneffekt.

  • Kompatibilität

  • Das KZG-Engagement ist DAS-freundlicher, wodurch Redundanzen in der Entwicklung vermieden werden.

2.5 Der Nutzen von EIP-4844

Aufrollen

Wie in der Abbildung unten gezeigt, muss das Rollup das Statusdelta und den versionierten Hash der KZG-Verpflichtung über Calldata übermitteln (zk-rollup muss das ZKP noch hochladen).

Nach der Implementierung von EIP-4844 enthalten die teuren Anrufdaten nur einige kleine Daten wie Statusdelta und Verpflichtungen, während große Daten wie Transaktionsstapel im Blob abgelegt werden.

  • die Kosten senken;

  • Reduzieren Sie die Blockspeicherplatznutzung.

Verbesserung der Sicherheit

  • Datenverfügbarkeit: Blob wird in der Beacon-Kette gespeichert, die die gleiche Sicherheit wie Ethereum L1 aufweist.

  • Historische Daten: Knoten speichern Blobs nur für einen bestimmten Zeitraum, und das Layer-2-Rollup ist für die permanente Datenspeicherung verantwortlich, was darauf hinweist, dass die Sicherheit historischer Daten vom Rollup abhängt.

Kosten

Die kostengünstige Funktion der Blob-tragenden Transaktion kann die Gesamtkosten um das 10- bis 50-fache optimieren.

Mittlerweile führt EIP-4844 eine Blob-Gebühr ein

  • Für Gas und Blob gelten getrennt einstellbare Gaspreise und -grenzen.

  • Die Preiseinheit eines Blobs ist Gas, die Gasmenge schwankt entsprechend dem Netzwerkverkehr, der darauf abzielt, die Zahl beizubehalten, die jeder Block trägt (durchschnittlich 8).

Implementierung der Vorkompilierung

Die EVM-Ausführung kann nur die Verpflichtung eines vom Prüfer generierten Blobs anzeigen und nicht direkt auf Blob-Daten zugreifen. Daher muss beim Rollup ein Vorkompilierungsschema verwendet werden, um die Gültigkeit der Verpflichtung zu überprüfen.

In EIP-4844 werden zwei Vorkompilierungsalgorithmen erwähnt

  • Punktauswertung vorkompilieren

  • Beweisen Sie, dass mehrere Verpflichtungen für denselben Datensatz gelten.

  • Die vorkompilierte Punktbewertung wird hauptsächlich von ZK-Rollup übernommen. Das Rollup muss zwei Verpflichtungen bereitstellen, KZG-Verpflichtung und ZK-Rollup-Verpflichtung

  • Was das optimistische Rollup betrifft, haben die meisten von ihnen Multi-Round-Betrugssicherheit eingeführt, und die Endrunde-Betrugssicherheit enthält eine kleinere Datengröße, was bedeutet, dass sie auch die Punktbewertungs-Vorkompilierung zu geringeren Kosten verwenden können.

  • Vorkompilierung der Blob-Überprüfung

  • Beweisen Sie, dass der versionierte Hash für den entsprechenden Blob gültig ist

  • Für die fälschungssichere Übermittlung ist beim optimistischen Rollup der Zugriff auf die vollständigen Daten erforderlich. Daher ist es sinnvoll, die Gültigkeit des versionierten Hashs und anschließend die fälschungssichere Überprüfung zu überprüfen.

3. Danksharding: Ein entscheidender Schritt in Richtung Full Sharding

Skalierung

Dank des neuen Transaktionstypdesigns von Proto-Danksharding, das einen Datenblob einführt, verfügt jeder Block jetzt über einen zusätzlichen 1-MB-Cache. Diese Zahl wird nach der Einführung von Danksharding um das 16- bis 32-fache steigen.

Datenverfügbarkeit: Hochleistungsfähige Datenspeicherung und -verifizierung

Im Vergleich zum Proto-Danksharding, bei dem Knoten den gesamten Inhalt historischer Daten speichern müssen, ermöglicht Danksharding den Knoten, Daten erst nach der Stichprobe zu speichern.

DAS

Der Danksharding-Vorschlag nutzt die Erasure-Coding-Technologie und macht es für Knoten einfacher (jeder Knoten muss nur Teile der Daten herunterladen), den Verlust von Daten zu erkennen.

Sicherheit: Fast gleich

Da Knoten nicht mehr den gesamten Inhalt historischer Daten speichern müssen, wird die Sicherheit nicht nur durch einen einzelnen Knoten gewährleistet, sondern hängt von mehreren Knoten ab, die Teile der Daten speichern und weiter zusammenfassen und die gesamten Daten wiederherstellen können.

Obwohl ein Einzelpunkt-Abhängigkeitsschema sicherer ist als eine Mehrpunkt-Abhängigkeit, ist die Anzahl der Knoten im Ethereum-Netzwerk weitaus mehr als ausreichend, was geeignet ist, das Ziel der Gewährleistung der Datenverfügbarkeit zu erreichen.

Neue Herausforderung: der höhere Bedarf an Blockbauern

Während Validatoren nur Teile der gesamten Daten herunterladen und speichern, muss der Blockbuilder dennoch den gesamten Dateninhalt hochladen, also den Blob, der alle Transaktionsdaten enthält.

Anhand des Diagramms aus Dankrads Folien können wir sehen, wie PBS (Proposer/Builder Separation), das ursprünglich für Anti-MEV entwickelt wurde, dabei hilft, den Bandbreitenbedarf beim Blockaufbau zu reduzieren.

4. Ein weiteres Sharding-Schema: dynamisches State-Sharding von Shardeum

Shardeum ist eine EVM-kompatible L1-Blockchain, die dynamisches State-Sharding nutzt, um Skalierbarkeit und Sicherheit zu verbessern. Mittlerweile ist das Shardeum-Netzwerk in der Lage, einen höheren Grad an Dezentralisierung zu gewährleisten.

Dynamisches Zustands-Sharding

Vorteile

Der intuitivste Vorteil des Dynamic State Sharding ist die lineare Skalierung. Jeder Knoten enthält einen anderen Adressbereich und es gibt eine erhebliche Überlappung zwischen den von den Knoten abgedeckten Adressen. Der Sharding-Algorithmus gruppiert Knoten dynamisch, was bedeutet, dass neu hinzugefügte Knoten im Shardeum-Netzwerk sofort daran arbeiten, die TPS zu erhöhen

Implementierung

Die Komplexität der Implementierung von dynamischem Zustands-Sharding ist schwieriger als die von statischem Sharding. Das technische Team von Shardeum hat sich eingehend mit Sharding-Technologien beschäftigt. Auch die bisherigen Forschungs- und Entwicklungsleistungen des Shardeum-Teams (vormals Shardus-Technologie) leisten einen wesentlichen Beitrag, der die lineare Skalierung des Dynamic State Sharding in einer frühen Entwicklungsphase verdeutlichen kann.

Zusammenfassung

Produkt

In Anlehnung an das Prinzip „Teile und herrsche“ teilt das Shardeum Dynamic State Sharding die Arbeitslast der Berechnung und Speicherung auf, was einen höheren Grad an Parallelisierung ermöglicht. Daher kann das Netzwerk mehr Knoten aufnehmen, was den Durchsatz und den Grad der Dezentralisierung weiter verbessert.

Team

Das Shardeum-Team verfügt über starke Marketingerfahrung und erzählerische Fähigkeiten. Sie verfügen außerdem über ein tiefes Verständnis für technische Details, insbesondere für dynamisches State Sharding.

Technologie

Das Technikteam ist in der Lage, auf der Grundlage seines Verständnisses des Szenarios ein geeignetes Sharding-Schema und einen effizienten Konsensalgorithmus (Proof of Stake + Proof of Quorum) zu entwerfen, bei dem Skalierung und Durchsatz an erster Stelle stehen und die Sicherheit und der Grad der Dezentralisierung gewährleistet werden so weit wie möglich.

Fortschritt

Betanet wurde am 02.02.2023 gestartet.

5. Der Ausblick

  • Sharding ist eine langfristige Skalierungslösung für Ethereum, es hat einen enormen Wert und eine tiefgreifende Bedeutung für das gesamte Netzwerk. Es ist noch schlimmer, genau darauf zu achten, da die Implementierung von Sharding ein iterativer Prozess ist. Alle aktuellen Vorschläge, einschließlich Proto-Danksharding und Danksharding, können aktualisiert/geändert werden.

  • Während es wichtig ist, die allgemeine Methode zur Sharding-Implementierung zu verstehen, lohnt es sich auch, die technischen Vorschläge wie PBS, DAS, mehrdimensionaler Gebührenmarkt usw., die während des Prozesses entstehen, zu beachten. Es könnte viele herausragende Projekte geben, die diese Vorhaben begleiten.

  • Es ist wichtig zu wissen, dass Sharding ein allgemeiner Begriff ist, der eine Reihe von Skalierungstechnologien beschreibt, und dass es je nach spezifischen Szenarien unterschiedliche Anwendungsschemata gibt. Beispielsweise könnte das Design von Danksharding nur für Ethereum geeignet sein und bei der Anwendung in anderen L1s wahrscheinlich zu negativen Auswirkungen führen, da die Sicherheit durch eine große Anzahl von Knoten im Netzwerk gewährleistet werden muss.

  • Durch eine sinnvolle Kombination von Sharding und anderen Skalierungslösungen kann ein Multiplikationseffekt erzielt werden. Der aktuelle Danksharding-Vorschlag wird allein nicht funktionieren. Stattdessen ergänzen sich Rollups und Danksharding gegenseitig, um die Skalierbarkeit und Kapazität von Ethereum besser zu verbessern.

Referenz

https://notes.ethereum.org/@dankrad/kzg_commitments_in_proofs

https://notes.ethereum.org/@dankrad/new_sharding

https://vitalik.ca/general/2022/03/14/trustedsetup.html

https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly

https://ethresear.ch/t/easy-proof-of-equivalence-between-multiple-polynomial-commitment-schemes-to-the-same-data/8188

https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html

https://eips.ethereum.org/EIPS/eip-4844

https://www.eip4844.com/

https://biquanlibai.notion.site/Data-Availability-caa896aae59d489b98f2448f17b01640

https://ethresear.ch/t/a-design-of-decentralized-zk-rollups-based-on-eip-4844/12434

Über Foresight Ventures

Foresight Ventures widmet sich der Unterstützung der bahnbrechenden Innovation der Blockchain in den nächsten Jahrzehnten. Wir verwalten mehrere Fonds: einen VC-Fonds, einen aktiv verwalteten Sekundärfonds, einen Multi-Strategie-FOF und einen Privatmarkt-Sekundärfonds mit einem verwalteten Vermögen von über 400 Millionen US-Dollar. Foresight Ventures vertritt die Überzeugung einer „einzigartigen, unabhängigen, aggressiven und langfristigen Denkweise“ und bietet umfassende Unterstützung für Portfoliounternehmen innerhalb eines wachsenden Ökosystems. Unser Team besteht aus Veteranen führender Finanz- und Technologieunternehmen wie Sequoia Capital, CICC, Google, Bitmain und vielen anderen.

Website: https://www.foresightventures.com/

Twitter: https://twitter.com/ForesightVen

Medium: https://foresightventures.medium.com

Substack: https://foresightventures.substack.com

Discord: https://discord.com/invite/maEG3hRdE3

Linktree: https://linktr.ee/foresightventures