Gemeinsame Sequenzer für die App-Ketten Starknet und Madara

Einführung

Heute sehen wir bereits Projekte, die beginnen, mit Madara für ihre App-Ketten zu experimentieren. Pragma, Kakarot, Mangata Finance und Dojo sind nur einige Beispiele. Solange wir an die Multi-Chain-Zukunft und die Leistungsfähigkeit der ZK-Skalierung glauben, werden wir in Zukunft nur noch viele weitere dieser Projekte sehen. Allerdings wirft die zunehmende Zahl an App-Ketten auch Fragen auf

1. Dezentralisierung
2. Zusammensetzbarkeit
3. Entwicklungserfahrung

In diesem Beitrag werde ich versuchen, die Probleme zu erklären, die durch die vielen App-Ketten entstehen, und auch eine mögliche Lösung des Problems aufzuzeigen, die ich für elegant und optimal für Madara und Starknet halte. Wenn Sie sich bereits gut mit App-Ketten und gemeinsamer Sequenzierung auskennen, können Sie gerne zum Abschnitt „Moment, es ist einfach wieder Polkadot“ springen.

Was passiert bei 100 App-Ketten?

Nehmen wir an, wir befinden uns in einer Zukunft, in der sich jetzt 100 verschiedene App-Ketten auf Ethereum niederlassen. Lassen Sie uns alle Probleme angehen, die dies verursachen wird.

Fragmentierte Dezentralisierung

Jede App-Kette muss die Lösung für die Dezentralisierung selbst finden. Nun ist die Dezentralisierung von App-Ketten nicht so notwendig wie die von L1s, vor allem weil wir uns aus Sicherheitsgründen auf L1s verlassen. Wir brauchen jedoch weiterhin eine Dezentralisierung, um Lebendigkeit und Zensurresistenz zu gewährleisten und monopolistische Vorteile (z. B. hohe Gebühren) zu vermeiden. Es ist jedoch auch wichtig zu beachten, dass, wenn jede App-Kette die Dezentralisierung auf ihre eigene Weise angeht, dies sehr schnell zu einer Fragmentierung der Validatorsätze führen wird. Jede App-Kette müsste wirtschaftliche Anreize entwickeln, um neue Validatoren einzubinden. Außerdem müssten Validatoren auswählen, welche Clients sie gerne ausführen möchten. Ganz zu schweigen von der enormen Eintrittsbarriere, die dadurch für Entwickler entsteht, wenn sie ihre eigenen App-Ketten starten (im Gegensatz zur Bereitstellung eines Smart Contracts, bei dem es sich lediglich um eine Transaktion handelt).

Zusammensetzbarkeit

Zusammensetzbarkeit bedeutet im Wesentlichen App-übergreifende Interaktion. Bei Ethereum oder Starknet bedeutet dies lediglich, dass ein weiterer Vertrag aufgerufen wird, und alles andere wird vom Protokoll selbst erledigt. Bei App-Ketten wird dies jedoch deutlich schwieriger. Verschiedene App-Ketten haben ihre eigenen Blöcke und Konsensmechanismen. Jedes Mal, wenn Sie versuchen, mit einer anderen App-Kette zu interagieren, müssen Sie den Konsensalgorithmus und die Endgültigkeitsgarantien sorgfältig prüfen und dementsprechend eine kettenübergreifende Brücke einrichten (direkt zur Kette oder über L1). Wenn Sie mit 10 App-Ketten mit unterschiedlichen Designs interagieren möchten, würden Sie dies 10 verschiedene Male tun.

Entwicklungserfahrung

Die Lösung für Dezentralisierung und Brückenbildung ist nicht einfach. Wenn dies eine Anforderung für jede App-Kette ist, wird es für den üblichen Smart-Contract-Entwickler sehr schwierig, jemals eine eigene App-Kette aufzubauen. Da außerdem jede App-Kette versucht, diese Probleme auf ihre eigene Weise zu lösen, werden wir bald feststellen, dass unterschiedliche Standards von verschiedenen Ketten befolgt werden, was den Beitritt zum Ökosystem noch schwieriger macht.

Shared Sequencer können dieses Problem lösen

Wenn Sie nun den App-Chain-Bereich verfolgen, haben Sie vielleicht schon von dem Begriff „Shared Sequencer“ gehört. Es geht um die Idee, einen gemeinsamen Satz von Validatoren für alle Ketten zu haben, der darauf abzielt, die oben genannten Probleme zu lösen. So funktioniert es.

Gemeinsame Dezentralisierung

Das Wesentliche an gemeinsam genutzten Sequenzern ist, dass Sie nicht für jede App-Kette oder L2 einen anderen Satz von Validatoren benötigen. Stattdessen können Sie über einen wirklich effizienten und dezentralen Satz von Validatoren verfügen, die die Blöcke für alle Ketten sequenzieren! Stellen Sie sich Blöcke vor, die Transaktionen von 100 verschiedenen App-Ketten enthalten. Sie denken vielleicht, dass dies den Sequenzer wirklich aufblähen wird, da Sie in der Lage sein müssen, Ausführungs-Engines für jede App-Kette zu verwalten.

Nun, das tust du nicht!

Da heutzutage fast jeder Sequenzer zentralisiert ist, wird der Sequenzer als eine einzelne Anwendung betrachtet, die Transaktionen sammelt, anordnet, ausführt und die Ergebnisse auf dem L1 veröffentlicht. Diese Jobs können jedoch in mehrere modulare Komponenten unterteilt werden. Der Erklärung halber werde ich sie in zwei Teile unterteilen.

1. Auftragsmaschine: Diese ist für die Reihenfolge der Transaktionen in einer bestimmten Reihenfolge verantwortlich. Sobald diese Reihenfolge von der Bestellmaschine festgelegt wurde, MUSS sie befolgt werden. Dies wird erzwungen, indem diese Reihenfolge auf L1 festgelegt wird und L1-Verifizierer gezwungen werden, zu prüfen, ob Transaktionen in der erforderlichen Reihenfolge ausgeführt wurden.
2. Rollup-Engine: Die Rollup-Engine ist im Grunde alles, was das Rollup sonst noch tut: Transaktionen von Benutzern sammeln, ausführen, Beweise erstellen und den Status auf dem L1 aktualisieren. Im Idealfall kann dies in mehrere Komponenten zerlegt werden, wir möchten dies jedoch in diesem Beitrag vermeiden.

Hier ist die Bestell-Engine der gemeinsame Sequenzer und die Rollup-Engine ist im Grunde die gesamte Rollup-Logik. Der Transaktionslebenszyklus sieht also so aus

Die gemeinsam genutzten Sequenzer ordnen Transaktionen grundsätzlich über Rollups hinweg und übergeben sie an die L1. Wenn Sie also den gemeinsam genutzten Sequenzersatz dezentralisieren, dezentralisieren Sie im Grunde auch alle Rollups, die mit diesem Sequenzersatz verknüpft sind! Um eine detailliertere Vorstellung von der Funktionsweise gemeinsam genutzter Sequenzer zu erhalten, können Sie auch diesen erstaunlichen <a href="https://hackmd.io/@EspressoSystems/EspressoSequencer"> Artikel 17 von Espresso lesen.

Zusammensetzbarkeit

Eines der Hauptprobleme der Zusammensetzbarkeit besteht darin, zu verstehen, wann die Transaktion in der anderen App-Kette abgeschlossen wird, und entsprechend Maßnahmen in Ihrer Kette zu ergreifen. Bei gemeinsam genutzten Sequenzern teilen sich jedoch beide zusammensetzbaren Rollups Blöcke miteinander. Wenn also eine Transaktion bei Rollup B zurückgesetzt wird, wird der gesamte Block zurückgesetzt, und dies führt dazu, dass auch die Transaktion bei Rollup A zurückgesetzt wird.

Das klingt jetzt sicherlich leichter gesagt als getan. Dafür. Die Kommunikation zwischen Rollups muss effizient und skalierbar sein. Die gemeinsam genutzten Sequenzer müssen geeignete Standards dafür entwickeln, wie Rollups kommunizieren können, wie kettenübergreifende Nachrichten aussehen sollten, wie mit Rollup-Upgrades umgegangen wird usw. Obwohl es sich hierbei um lösbare Probleme handelt, sind sie kompliziert und nicht einfach zu lösen.

Entwicklererfahrung

Während die Shared Sequencer den Dezentralisierungsaspekt abstrahieren und die kettenübergreifende Nachrichtenübermittlung erleichtern, gibt es dennoch einige Standards, denen jede Kette folgen muss, um mit dem Shared Sequencer kompatibel zu sein. Beispielsweise müssen alle Rollup-Transaktionen in ein allgemeines Format umgewandelt werden, das der Sequenzer versteht. Ebenso müssen Blöcke aus dem Sequenzer gefiltert werden, um die relevanten Transaktionen abzurufen. Um dieses Problem zu lösen, würde ich davon ausgehen, dass Shared Sequencer Rollup-Frameworks oder SDKs entwickeln würden, die den Boilerplate-Code abstrahieren und den App-Chain-Entwicklern nur den Teil der Geschäftslogik zugänglich machen.

Hier ist ein Diagramm, wie App-Ketten mit gemeinsam genutzten Sequenzern aussehen werden

Moment, es ist einfach wieder Polkadot

Polkadot begann lange vor Ethereum mit der Arbeit an der Multi-Chain-Zukunft. Tatsächlich arbeiten sie nun schon seit mehr als 5 Jahren daran und wenn Sie mit Polkadot vertraut sind, ist Ihnen vielleicht aufgefallen, dass das obige Design im Grunde viele Dinge neu erfindet, die Polkadot bereits getan hat!

Die Relay Chain (gemeinsame Dezentralisierung)

Die Relaiskette ist im Grunde die Bestellmaschine + L1 im obigen Sequenzdiagramm. Die Relaiskette

1. Bestellt Transaktionen über alle Parachains hinweg (Rollups)
2. Es überprüft die korrekt ausgeführten Transaktionen (anstelle der ZK-Überprüfung führt es tatsächlich den Ausführungscode des Rollups erneut aus, um die Statusunterschiede zu überprüfen).

Sie haben vielleicht bemerkt, dass es sich bei dem Relais im Grunde um den oben besprochenen gemeinsamen Sequenzer handelt. Abgesehen davon, dass die Relay-Kette auch die Ausführung überprüfen muss (da Polkadot ein L1 ist), überlassen wir das Ethereum.

XCM und XCMP

Wir haben im vorherigen Abschnitt erwähnt, dass wir bald mit unterschiedlichen Standards und Formaten über alle Ketten hinweg aufgebläht wären, wenn jede Kette ihre eigenen Methoden für die Zusammenarbeit mit anderen Ketten entwickeln würde. Sie müssen alle diese Formate für jede Kette, mit der Sie interagieren, im Auge behalten. Darüber hinaus müssen Sie auch Fragen beantworten wie: Was passiert, wenn eine Kette aktualisiert wird? Diese Probleme können jedoch elegant angegangen werden, indem Standards eingeführt werden, denen alle Ketten folgen müssen.

Wie Sie vielleicht erraten haben, hat Polkadot dies bereits getan. XCM ist das Nachrichtenformat und XCMP ist das Nachrichtenprotokoll, über das alle Substratketten miteinander kommunizieren können. Ich werde nicht näher darauf eingehen, aber Sie können es hier nachlesen 5.

Substrat und Cumulus

Substrate ist ein von Parity entwickeltes Framework, das zum Aufbau von Blockchains verwendet werden kann. Während alle Parachains auf Polkadot Substrat verwenden, ist Substrat tatsächlich kettenunabhängig aufgebaut. Das Framework abstrahiert alle gemeinsamen Aspekte einer Blockchain, sodass Sie sich ganz auf Ihre Anwendungslogik konzentrieren können. Wie wir wissen, basiert Madara auf Substrate, ebenso wie Polkadot, Polygon Avail und viele andere Projekte. Darüber hinaus ist Cumulus eine Middleware auf Substrate, die es Ihnen ermöglicht, Ihre Kette mit Polkadot zu verbinden.

Wenn wir unsere Analogie wie zuvor fortsetzen, können wir uns Substrate und Cumulus als Ersatz für die Rollup-Frameworks vorstellen, mit denen Sie App-Ketten erstellen und diese mit den gemeinsam genutzten Sequenzern verbinden können.

Gemeinsame Sequenzer → Relaisketten
Zusammensetzbarkeit → XCM und XCMP
Rollup-Frameworks/Stacks → Substrate und Cumulus

Also ja, es ist quasi wieder Polkadot! Darüber hinaus verfügen Polkadot und Parity über einige der erfahrensten und finanziertesten Teams, die Substrate und Polkadot weiterentwickeln, um weitere Funktionen hinzuzufügen und es skalierbarer zu machen. Die Technologie ist bereits seit Jahren kampferprobt und verfügt über eine Menge sofort einsatzbereiter Entwicklungstools.

Polkadot auf Ethereum abrechnen?

Es stimmt zwar, dass Polkadot schon lange vor Ethereum mit dem Aufbau der Multi-Chain-Zukunft begonnen hat, aber es lässt sich nicht leugnen, dass Ethereum heute die am stärksten dezentralisierte Blockchain ist und der Ort, an dem sich die meisten Apps und Liquidität befinden. Was wäre jedoch, wenn es eine Möglichkeit gäbe, die gesamte Polkadot-Technologie in das Ethereum-Ökosystem zu integrieren?

Es gibt! Tatsächlich haben wir mit Madara bereits damit begonnen. Madara nutzt das Substrate-Framework, um es jedem zu ermöglichen, seine eigene zk-basierte L2/L3-Lösung auf Ethereum aufzubauen. Als nächstes brauchen wir die Polkadot-Relay-Kette in Form eines gemeinsamen Sequenzers. Also im Grunde genommen, wenn wir die Polkadot-Relay-Kette wiederverwenden können, aber

1. Entfernen Sie den Verifizierungsteil, da dies auf L1 über ZK-Proofs geschieht
2. Übergeben Sie die Reihenfolge der Transaktionen an L1
3. Optimieren Sie die Knoten und Konsensalgorithmen, um Tendermint/HotStuff zu unterstützen

Wir können wie bereits erwähnt gemeinsame Sequenzer erhalten. Offensichtlich ist das leichter gesagt als getan. Ich glaube jedoch, dass dieser Weg pragmatischer ist, als die Sequenzer, Standards und Frameworks von Grund auf neu aufzubauen. Polkadot hat bereits viele Probleme auf kettenunabhängige Weise gelöst, die wir für Ethereum übernehmen können. Als Nebenprodukt erhalten wir

1. Eine aktive Gruppe von Entwicklern, die weiterhin Substrate aufbauen und die Welt darüber aufklären
2. Ein aktiver Entwickler-Toolsatz und eine starke Community
3. Viele aktive Parachains können sich auch dafür entscheiden, sich auf Ethereum niederzulassen, wenn sie dies wünschen (wir haben kürzlich gesehen, wie Astar dasselbe mit dem Polygon CDK tat).

Abschluss

Meine Hauptidee beim Schreiben dieses Beitrags besteht darin, die Diskussion im breiteren Ökosystem von Starknet und Ethereum zu eröffnen. Ich glaube, dass das Shared-Sequencing-Modell eine wichtige Rolle bei der Dezentralisierung nicht nur von Starknet, sondern auch aller App-Ketten spielen wird, die darüber nachdenken, darauf aufzubauen. Solange wir von der App-Chain-These und der ZK-Skalierung überzeugt sind, ist eine gründliche Analyse des Shared-Sequencing-Modells unumgänglich. Darüber hinaus halte ich es für wichtig, dass dieses Thema jetzt angegangen wird, da Madara sich der Produktion zuwendet und Starknet mit der Arbeit an der Dezentralisierung begonnen hat. Daher bitte ich jeden, der dies liest, Feedback/Vorschläge zu diesem Thema zu hinterlassen. Ich freue mich darauf, Ihre Gedanken zu lesen!

Anhang

Polkadot vs. Cosmos

Cosmos arbeitet, ähnlich wie Polkadot, seit vielen Jahren an einer Multi-Chain-Zukunft. Infolgedessen hat es mit dem Cosmos SDK und IBC viele Entwicklungen gegeben und wir sehen auch viele App-Ketten, die auf dem Cosmos-Ökosystem aufbauen. Daher ist es nur fair, bei diesem Ansatz auch Cosmos in Betracht zu ziehen. Meine persönliche Meinung zu diesem Thema ist, dass Polkadot relevanter ist, da es das Problem der gemeinsam genutzten Sequenzer löst, während Cosmos verlangt, dass jede App-Kette ihren eigenen Validatorsatz erstellt. Darüber hinaus wurde Substrate schon immer kettenunabhängig aufgebaut, um Entwicklern den Aufbau von Blockchains ohne Annahmen über Konsensalgorithmen oder das Polkadot-Ökosystem zu ermöglichen. Dies ist auch der Grund, warum wir uns für Substrate für Madara entschieden haben. Allerdings ist meine Erfahrung mit Cosmos begrenzt und ich würde gerne mehr darüber von den erfahreneren Leuten hören! Mehr zum Vergleich der beiden Netzwerke finden Sie auch hier

Haftungsausschluss:

1. Dieser Artikel wurde von [starknet] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [apoorvsadana]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.