Zephyrnet-Logo

Polygon ZK-RollUp: Eine unglaublich einfache Erklärung 

Datum:

Lesezeit: 9 Minuten

Polygon behält seine Krone bei, indem es ZKrollup einbringt.

Problem mit Ethereum Mainnet

Ethereum ist das Rückgrat des web3-Ökosystems. Es überrascht weiterhin die brillantesten Köpfe der Welt mit dem Potenzial, das es in sich trägt. Das Potenzial diversifizierter Anwendungen würde sogar Einstein für einen Moment am Kopf kratzen lassen.

Aber ja, es ist kein Märchen. Jede tolle Sache hat eine Begrenzung oder Einschränkung. Die ständige Einschränkung, der Ethereum ausgesetzt war, sind die „Gasgebühren“, oder mit anderen Worten, die Skalierbarkeit, Ethereum Classic hat ein Limit von 15 Transaktionen pro Sekunde. ETH 2.0 wird jedoch viel schneller sein, aber wir haben noch einen langen Weg vor uns.

Lösungen ausprobiert

Nach jahrelanger Forschung, langwierigen Studien und großem Engagement gelang es der web3-Community, einige Lösungen herauszubringen, die zu einer besseren Skalierung beitragen

  1. Layer 1 Scaling:- Dies ist die Methodik, mit der wir versuchen, die Blockchain zu verbessern, indem wir einige Änderungen an der Architektur vornehmen. Beispielsweise ist ETH 2.0 eine Layer-1-Skalierungslösung, da sie versucht, PoS für PoW in ETH Classic zu etablieren. Diese Art von Lösung ist teuer und zeitaufwändig.
  2. Roll-Ups:- Dies ist eine Layer-2-Lösung, die der vielversprechendste Anwärter ist. Die Benutzer erhalten Sicherheit durch die Ethereum-Blockchain mit hohem Durchsatz.
  3. Sidechains:- Diese sind EVM-kompatibel und können allgemeine Anwendungen skalieren, haben aber Nachteile. Da Ethereum seine Sicherheit nicht unterstützt, muss sich die Web3-Community ständig darüber im Klaren sein. Dies fällt unter die Layer-2-Skalierung.

https://twitter.com/MessariCrypto/status/1377655515099062273/photo/1

Die Einstellung von Polygon

Angefangen als Ethereum-Skalierungsprojekt entwickelte sich Polygon, früher bekannt als Matic Network, zu einem leuchtenden Stern im Web3-Bereich. Es kostet Cent, eine Transaktion in einem Polygon-Netzwerk zu bestätigen, während dieselbe Transaktion im Ethereum Mainnet Dollar kosten würde. Möglich wurde dies alles durch die Sidechain, die auf dem Ethereum-Mainnet aufbaut.

Später erkundete Matic Network weitere verschiedene Möglichkeiten zur Skalierung der Ethereum-Blockchain und wurde in „Polygon“ umbenannt, um verschiedene Lösungen zur besseren Skalierung der Ethereum-Blockchain bereitzustellen.

Zum Zeitpunkt des Schreibens dieses Blogs gibt es mehrere Projekte:-

  1. Polygon-PoS
  2. Polygon-Supernetze
  3. Polygon Null
  4. Polygonmitte
  5. Polygon zkEVM

In diesem Blog werden wir Polygons neue Version zkEVM untersuchen, die eines der heißesten Projekte zur Skalierung von Ethereum ist.

Polygon zkEVM

Polygon zkEVM ist ein Produkt von Polygon, um Ethereum zu skalieren, um die Gasgebühren zu senken und den Durchsatz zu erhöhen. Das „ZK“ steht für „Zero Knowledge“, eine Art Roll-Up. Bevor wir fortfahren, müssen wir RollUps verstehen.

Was sind Rollups

Stellen Sie sich das so vor, angenommen, es gibt einen Postbriefdienst von Stadt A nach Stadt B, aber es gibt nur 1 Fahrzeug, das nur einmal am Tag 100 Umschläge aufnehmen kann. Sie finden es einschränkend und versuchen, einen Weg zu finden. Was Sie tun können, ist, nehmen Sie 10 Briefe und schreiben Sie ihre Zusammenfassung in einem einzigen Brief und stecken Sie ihn in einen Umschlag, um ihn zu versenden. damit können wir 99 + (10) Briefe versenden. Dies ist im Wesentlichen das, was Roll-Ups sind.

So funktionieren Roll-Ups im Wesentlichen im Ethereum-Mainnet. Wir nehmen einen Teil der Transaktionen, sammeln sie in einem „Roll-Up“, fassen sie zusammen und schieben sie dann ins Mainnet. Dadurch erhöht sich der Durchsatz. Die Transaktionsgebühr wird auf verschiedene Parteien aufgeteilt, die mit den Transaktionen in dem Stapel verbunden sind, der zusammengefasst wird. Auf diese Weise reduzieren wir die Gasgebühren in erheblichem Maße.

Aufrollmechanismen

Jedes Roll-up setzt einige Smart Contracts auf Layer 1 ein, die mit Folgendem verbunden sind:

  1. Einzahlungen bearbeiten
  2. Entnahmen
  3. Nachweise prüfen

Das Hauptanliegen hier ist der Überprüfungsmechanismus. Wie überprüfen wir, ob das an Layer 1 übermittelte Roll-up nicht betrügerisch ist? Um dies zu überprüfen, haben wir zwei Validierungsmechanismen:-

  1. Nullwissen: Dieser Mechanismus verwendet Gültigkeitsbeweise und wird durch Kryptografie unterstützt. Der Stapel von Transaktionen, die aufgerollt werden, enthält einen kryptografischen Nachweis, der als „zk-snark“ bekannt ist. Der Nachweis wird schnell von den Smart Contracts der Schicht 1 verifiziert, wenn der Transaktionsstapel übermittelt wird, und ungültige werden abgelehnt.
  2. Optimismus:- Dieser Mechanismus funktioniert betrugssicher. Das bedeutet, dass wir nachweisen müssen, dass die an Layer 1 übermittelte Charge nicht betrügerisch ist. Es sind zwei Parteien beteiligt, eine, die den Stapel an das Schicht-2-Protokoll übermittelt und sagt, dass der Stapel korrekt ist, und etwas Geld aufs Spiel setzt, wenn sich herausstellt, dass er falsch ist, und die andere Partei versucht, eine betrugssichere Angabe zu machen, dass dieser Stapel bösartig ist und mit diesem Anspruch setzt einige Einsätze. Wenn jemand einen Betrugsnachweis erhebt, wird der Stapel auf dem Schicht-1-Protokoll überprüft, und die Partei, die sich als falsch erwiesen hat, wird bestraft.

Die Architektur des zkEVM von Polygon: -

Inzwischen müssen Sie ein anständiges Verständnis dafür haben, wie Roll-Ups funktionieren, insbesondere zk-Roll-Up. Die Hauptkomponenten, die wir im zkEVM von Polygon finden, sind:-

  • Konsensvertrag (PolygonZkEVM.sol)
  • zkNode
  • zkProver

Konsensvertrag

Dieser Vertrag wird auf L1 bereitgestellt und spielt eine entscheidende Rolle, indem er Gültigkeitsnachweise verwendet, um die Robustheit von Zustandsübergängen sicherzustellen. Um dies zu tun, hat es vordefinierte Regeln, die befolgt werden, um Zustandsübergänge zu ermöglichen.

Um den erfolgreichen Abschluss des Zustandsübergangs zu verifizieren, verwendet dieser Vertrag zk-SNARK-Schaltungen. Dieses System stützt sich auf zwei Prozesse, nämlich Transaktionen, bei denen es sich um Stapelverarbeitung und Transaktionsvalidierung handelt, wie zuvor erläutert.

Zur Durchführung von Transaktions-Batching und Transaktionsvalidierung beschäftigt zkEVM zwei Teilnehmer:-

  1. Sequencer:- schlagen dem Netzwerk Transaktionsstapel vor.
  2. Aggregatoren:- Überprüfen Sie die Gültigkeit der Transaktionsstapel und liefern Sie einen gültigen Nachweis.

Mehr zu Sequenzern und Aggregatoren später zuerst, konzentrieren wir uns auf diesen Vertrag. Der Vertrag macht zwei Anrufe-

  1. um die Batches von Sequencern zu erhalten
  2. an Aggregatoren, die die Validierung von Chargen anfordern

Dieser gesamte Prozess kann im folgenden Diagramm zusammengefasst werden (hier ist PoE unser Konsensvertrag):-

https://wiki.polygon.technology/docs/zkEVM/protocol/consensus/

zkNode

Wir wurden in Consensus Contract mit Sequencer und Aggregator bekannt gemacht, diese beiden sind entscheidende Teile der zkEVM-Architektur, und zkNode ist die Software, die sie dazu befähigt. zkNode ist ein Client, der zum Implementieren der Synchronisation und zum Steuern von Sequencern und Aggregatoren erforderlich ist. Die zkNode-Software erleichtert also 4 Aspekte:-

  1. Sequencer:- Ein Sequencer ist derjenige, der L2-Transaktionen von den Benutzern empfängt und sie zu einem neuen L2-Batch vorverarbeitet, der dann dem Concensous Contract vorgeschlagen wird. Der Sequenzer erhält die von den Benutzern für ihre Transaktionen auf L2 eingereichte Gebühr. Um diesen Batch an L1 zu veröffentlichen, muss der Sequencer L1-Gebühren und auch einige MATIC-Token zahlen, die als Anreiz für die Aggregatoren dienen, diesen Batch zu validieren. Der Sequenzer ist also rentabel, wenn: - txn-Gebühren (die die Benutzer in L2 für ihre Transaktion erhalten) > L1-Anruf (Gasgebühr zur Veröffentlichung auf L1) + MATIC-Gebühr (um die Aggregatoren zur Validierung anzuregen)
  2. Aggregatoren:- Aggregatoren sind entscheidend, um die Integrität des Stapels zu überprüfen. Aggregatoren erhalten alle Transaktionsinformationen und senden sie dann an „zkProver“ (dazu später mehr), der wiederum einen „zk-Proof“ liefert, der das Ergebnis komplexer Polynomberechnungen ist. Der „zk-Proof“ wird dann an den Smart Contract gesendet, um zu überprüfen, ob der Nachweis korrekt ist. Dieser Stapel wird dann als korrekt markiert und kann hinzugefügt werden. Der Aggregator ist rentabel, wenn: - MATIC-Gebühr (durch Sequencer) > L1-Anruf (Gasgebühr) + Serverkosten (um Beweis zu erstellen)
  3. Synchronizer:- Der Hauptaspekt des Synchronizers besteht darin, Ereignisse aus der Ethereum-Blockchain zu lesen und die neuen Batches einzuschließen, um den Status synchronisiert zu halten. Die Informationen aus diesen Ereignissen werden in der Datenbank gespeichert. Synchronizer erhält die Daten von Smart Contracts. Alle diese Daten werden dann über den JSON-RPC-Dienst an Dritte weitergegeben.
  4. RPC:- JSON-RPC ist eine entscheidende Schnittstelle, die mit Ethereum kompatibel ist. Wenn wir eine Softwareanwendung benötigen, um eine Verbindung zur Ethereum-Blockchain herzustellen, verbindet sie sich mit einem Ethereum-Knoten. So kommt RPC ins Spiel. Es ermöglicht zkEVM die Integration von Metamask und Etherscan und interagiert mit Pool- und State-Transaktionen.

https://wiki.polygon.technology/assets/images/fig3-zkNode-arch-aa4d18996fba1849291ea18e3f11d955.png

zkProver

Dieser Teil der zkEVM-Architektur ist der technologisch orientierteste und komplexeste. Es wird Sie überraschen, das zu wissen, um dies auszuführen. Die Entwickler mussten zwei neue Programmiersprachen entwickeln, um die benötigten Elemente zu implementieren:-

  1. Zero – Knowledge Assembly: – Einfach ausgedrückt bildet diese Sprache Anweisungen von der Hauptzustandsmaschine von zkProver auf andere Zustandsmaschinen ab. Um mehr über diese Sprache zu erfahren, überprüfen Sie fehlen uns die Worte..
  2. Polynomial Identity Language (PIL):- Es wurde viel geforscht, um das Blockchain-Trilemma aus Datenschutz, Sicherheit und Skalierbarkeit zu lösen. Bis heute gab es mehrere Versuche und verschiedene Theorieversuche, aber der bis heute am meisten akzeptierte ist das „Polynomial Commitment Scheme“. Daher ist es nur zweckmäßig, Berechnungen in einer Polynomsprache durchzuführen. PIL-Codes bilden somit die Basis des Prüfcodes des zkProver. Um mehr darüber zu erfahren, folgen Sie hier.

Hinter zkProver stehen viele Jahre Forschung in verschiedenen Abteilungen, die seine Komplexität rechtfertigen. Es gibt hauptsächlich einige Hauptkomponenten von zkProver:-

  1. Der Executor: Dieser Teil befasst sich mit der Ausführung des zkEVM von der Main State Machine. Hier werden die EVM-Bytecodes mit der zuvor besprochenen neuen „Zero-Knowledge Assembly Language“ (zkASM) interpretiert. In diesem Teil befassen wir uns mit der Einrichtung von Polynombeschränkungen, die jeder gültige Stapel von Transaktionen erfüllen und mit Eingaben wie Transaktionen, altem/neuem Status, Ketten-ID usw. füttern muss. Hier ist die PIL (Polynomial Identity Language), um die zu codieren Polynomische Nebenbedingungen. Die Ausgabe dieses Schritts sind die „Commitment Polynomials“, die ein Ergebnis der Ausführung aller Anweisungen auf der PIL-Hardware sind.
  2. Stark-Rekursionskomponente: Dieser Schritt beinhaltet die Wechselwirkung von drei Haupteingaben, festgelegten Polynomen, konstanten Polynomen und einer Liste von Anweisungen. Diese drei Eingaben werden gemischt, um zk-STARK-Beweise zu erzeugen. Diese mehreren zk-STARK-Proofs werden in Bündeln von wenigen zk-STARK-Proofs zusammengestellt und erzeugen einen zk-STARK-Proof von jedem Bündel. Anschließend werden diese Proofs gebündelt und zu einem einzigen zk-STARK-Proof zusammengeführt. So werden Hunderte von zk-STARK-Beweisen dargestellt und mit nur einem zk-STARK-Beweis bewiesen.
  3. CIRCOM-Bibliothek:- Dieser Schritt beinhaltet die Interaktion mit den Verifier-Daten und dem einzelnen zk-STARK-Beweis, der durch Stark Recursion Componenet erstellt wurde, um einen „Zeugen“ zu generieren. Dieser Schritt ist für den nächsten Schritt erforderlich, um den zk-STARK-Beweis in den zk- SNARK-Beweis.
  4. Rapid Snark:- Dies ist die letzte Komponente des zkProver. Dies ist die Phase, in der der „Zeuge“ die Ausgabe der CIRCOM-Bibliothek zusammen mit den STARK-Verifiziererdaten einspeist, um den zk-SNARK-Beweis zu erstellen.

Die zk-STARK-Proofs werden wegen ihrer Geschwindigkeit verwendet, aber sie sind viel größer als zk-SNARK-Proofs. Aus diesem Grund verwendet zkProver das im letzten Schritt erstellte zk-SNARK unter Verwendung der Daten aus zk-STARK-Proofs. Das Zusammenspiel dieser vier Komponenten kann wie folgt gesehen werden:

https://wiki.polygon.technology/assets/images/fig5-main-prts-zkpr-042cd579e903d351ced9ec16a8ee7d9c.png

Blick auf den Sicherheitsaspekt

Sicherheitstechnisch befindet sich das zkEVM-Projekt in seiner mittelalterlichen Phase, und das Polygon-Team war kontinuierlich an internen und externen Audits beteiligt. Die Informationen über die Ergebnisse interner Audits sind größtenteils geheim, aber Polygon hat sich von zwei externen Auditoren (Hexens und Spearbit) helfen lassen. Präsentieren der müssen intelligente Vertragsprüfungen erhalten auch von den großen Giganten. Es stimmt, dass „Hacks unerwartet kommen“. In der Tat können Sie nie so sicher und sicher sein. Die meisten Giganten im Web3-Ökosystem verstehen dies und bemühen sich sehr, sich zu sichern.

Jetzt müssen wir mehr denn je web3 sichern. In dieser Phase ist eine professionelle Codeüberprüfung von Smart Contracts unerlässlich, was Entwicklern unzählige Arbeitsstunden erspart. Die Sicherheit Ihrer Verträge ist wichtiger denn je. Gemeinsam können wir Web3 zu einem sichereren Raum machen. Besuchen Sie QuillAudits um verschiedene Dienste und Lösungen zu erkunden.

16 Views

spot_img

VC-Café

VC-Café

Neueste Intelligenz

spot_img