Autor: PolkaWorld

Gavin Wood, Mitbegründer von Ethereum, Schöpfer von Polkadot und Visionär für Web3.

Bevor wir offiziell anfangen, lasst uns einige von Gavins Zitaten in diesem Abschnitt teilen!

Was ist das größte Erfolg von Ethereum bis heute? – Vielleicht CryptoKitties, ich weiß es nicht, ich bin mir nicht sicher. Ich habe gehört, dass Ethereum die meisten Millionäre in der Geschichte geschaffen hat.

Ist Ethereum ein erfolgreiches Projekt? – Wenn man nach meinen Erfolgskriterien fragt? Offensichtlich erfüllt nicht jeder Standard, vielleicht nur ein kleiner Teil. Natürlich war es finanziell erfolgreich.

Mit der Einführung von JAM hat sich die Richtung von Polkadot verändert. Es kann als eine nativen Rollup-Hosting-Kette angesehen werden, während unsere entwickelten Technologien weit überlegen sind im Vergleich zu den optimistischen Rollups und Zero-Knowledge Rollups auf Ethereum.

Was ist das größte Erfolg von Polkadot bis jetzt? – Die Schaffung einer sicheren Shard-Blockchain.

Was ist das größte Problem, mit dem Polkadot heute konfrontiert ist? – Es ist das Sharding.

Wie können wir diese Probleme lösen? – JAM

Weiterlesen, um alles zu sehen!

Was ist das größte Erfolg von Ethereum bis heute?

Kevin: Also sagst du, dass du 2014 Ethereum mitbegründet hast? Warum bist du als Mitbegründer und CTO zu ihnen gekommen?

Gavin: Ich dachte, es war eine seltene Gelegenheit, und mir wurde sofort klar, dass ich sie ergreifen sollte und mein Bestes geben sollte. Vielleicht nicht für mein ganzes Leben, aber zumindest für eine Weile, um mich voll zu engagieren. Es war ein innovatives Projekt, das zur richtigen Zeit auftauchte, mit einigen talentierten und fokussierten Menschen im Team und einem kleinen, aber interessierten und experimentierfreudigen Markt. Ehrlich gesagt war ich sehr neugierig auf dieses Projekt, ich dachte, es hat großes Potenzial, weit zu wachsen und könnte zumindest zur Aufklärung der liberalen Prinzipien beitragen, wie ich sie verstehe.

Kevin: Was ist das?

Gavin: Im Grunde genommen ist es eine optimistische Sichtweise auf Gesellschaft und Entwicklung, die ungefähr vor vier- bis fünfhundert Jahren im Westen entstand.

Kevin: Was ist das größte Erfolg von Ethereum bis heute?

Gavin: Vielleicht ist es CryptoKitties, ich weiß es nicht, ich bin mir nicht sicher. Ich habe gehört, dass Ethereum die meisten Millionäre in der Geschichte geschaffen hat. Vielleicht liegt das daran, dass viele Menschen an der Crowdfunding-Kampagne teilgenommen haben und der Preis später hoch genug gestiegen ist. Vielleicht ist das also sein größter Beitrag. Aber ehrlich gesagt, es ist schwer zu sagen, wie viel Nützliches es wirklich erreicht hat. Es hat sicherlich nicht meine Erwartungen von vor zehn Jahren erfüllt.

Kevin: Also, wenn ich dich frage, denkst du, dass Ethereum ein erfolgreiches Projekt ist? Ist deine Antwort negativ?

Gavin: Meine Antwort ist, denke ich, dass es für mich persönlich erfolgreich ist? Wenn ich nach meinen Erfolgskriterien frage? Offensichtlich erfüllt nicht jeder Standard, vielleicht nur ein kleiner Teil. Natürlich war es finanziell erfolgreich. Ich denke, vielleicht haben ein oder zwei Mitbegründer von Ethereum erwartet, dass es besser abschneidet.

Kevin: Welche Standards würden dich dazu bringen zu denken, dass es erfolgreich ist?

Gavin: Nützlichkeit (Utility)

Kevin: Wie misst man Nützlichkeit?

Gavin: Der Weg, Nützlichkeit zu messen, besteht darin zu schauen, wie viele Dinge die Menschen jetzt tun können, die sie zuvor nicht tun konnten.

Kevin: Ist das nicht ein Problem für die gesamte Krypto-Branche und nicht nur für Ethereum?

Gavin: Das ist es in der Tat. Das ist ein Problem, mit dem die gesamte Krypto-Branche konfrontiert ist. 2014 und 2015 haben wir viele Ideen eingebracht, um einige wirtschaftliche Bereiche zu erschließen, die zuvor nicht zugänglich waren, und zwar auf eine „vertrauenslose“ Weise. Ein Beispiel, das ich besonders mag, ist die Lieferkette. Zum Beispiel, wenn du in einen Supermarkt gehst, gibt es einen QR-Code auf jedem Produkt, den du scannen kannst, um alle Bestandteile des Produkts zu erfahren: wann, wo und in welcher Menge usw. Ich hoffe, dass ich beim Kauf eines T-Shirts wissen kann, wo die Baumwolle herkommt.

Jetzt ist es sehr schwierig und kostspielig, so etwas in einem zentralisierten Modell zu erreichen. Aber ich denke, es könnte möglich sein, wenn wir es dezentralisieren. Dennoch sind diese Anwendungen nicht wirklich umgesetzt worden. Es gibt zwar einige Krypto-Projekte in Bezug auf Lieferketten, aber sie sind sehr nischenspezifisch und auf bestimmte Marktsegmente beschränkt. Es hat das Versprechen in dieser Richtung nicht eingelöst.

Und es ist nicht nur ein Problem der Lieferkette, ich denke, die Vorstellungskraft der Krypto-Branche ist reichlich, aber es ist schwierig, diese Vorstellungen in reale Aktionen und echte Marktanwendungen umzusetzen, was wirklich bedauerlich ist. Ich denke, der Hauptgrund ist kein technisches Problem, obwohl die Technologie hinter unseren Vorstellungen zurückbleibt, insbesondere die zugrunde liegende Technologie muss erheblich verbessert werden. Das ist auch der Grund, warum ich jetzt an JAM arbeite, um die zugrunde liegende Technologie zu verbessern, damit sie die Ideen unterstützen kann, die ich für wertvoll halte, und der Krypto-Branche helfen kann, eine größere Rolle zu spielen.

Aber nur die Technologie zu verbessern, reicht nicht aus. Du musst den Menschen auch den Wert erklären. Und das ist schwierig, zum Teil weil du gegen die Aufmerksamkeitsökonomie kämpfst.

Warum hast du Ethereum verlassen?

Kevin: Warum bist du 2016 von Ethereum gegangen?

Gavin: Tatsächlich war es Ende 2015. Zu diesem Zeitpunkt haben wir entschieden, dass Ethereum viele Dinge tun muss, um breiter verbreitet zu werden. Wir haben nach externen Investoren gesucht, und eine der offensichtlichsten Möglichkeiten war die Gründung eines Startups, das mit Ethereum verbunden ist, und externe finanzielle Unterstützung dafür zu suchen. Das war ursprünglich eine Entscheidung von Vitalik und Jeff (dem Kernentwickler und Ingenieur).

Später fühlte sich Jeff nicht wirklich wohl im Startup-Leben. Tatsächlich verließ er Ethereum ziemlich schnell, um seiner Karriere in der Videospielbranche nachzugehen. Damit blieb letztendlich nur Vitalik übrig. Vitalik fand, dass es notwendig war, im Ethereum-Stiftungsrat zu bleiben und eine akademischere Rolle zu übernehmen, während er auch als Berater für das Tochterunternehmen Ethcore, das wir damals gegründet hatten, fungierte.

Wir haben damals etwas Geld gesammelt und etwa die Hälfte des technischen Teams der Ethereum-Stiftung zu Ethcore gebracht und einen Ethereum-Client entwickelt. Ich habe die Ethereum-Stiftung Ende 2015 verlassen, um dieses Tochterunternehmen zu gründen, mit dem Ziel, eine von privatem Kapital unterstützte Einheit im Ethereum-Ökosystem zu schaffen.

Aber ich habe das Ethereum-Ökosystem erst Ende 2017 vollständig verlassen, als ich Polkadot gründete.

Polkadot entwickelt eine Rollup-Technologie

Kevin: Wie würdest du deiner Mutter erklären, was Polkadot ist?

Gavin: Nun... Polkadot hat sich im Laufe der Jahre verändert. Die ursprüngliche Vision war es, verschiedene Blockchain-Architekturen zusammenzuführen, damit sie miteinander kompatibel sind und denselben Sicherheitsrahmen teilen. Durch einen solchen gemeinsamen Sicherheitsrahmen kann die wirtschaftliche Effizienz erheblich gesteigert werden. Wenn es richtig gestaltet ist, kann man mit den gleichen Kosten gleichzeitig 100 Ketten schützen, anstatt jede Kette wie andere Designs (zum Beispiel Cosmos) unabhängig abzusichern.

Im Laufe der Jahre hat Polkadot versucht, sich in diesem Bereich von Cosmos zu unterscheiden. Denn im Cosmos-Modell muss jede Kette ihre eigene Sicherheit übernehmen. Polkadot löst dieses Problem durch geteilte Sicherheit. Leider lösen beide in Wirklichkeit sehr unterschiedliche Probleme. Rückblickend neige ich vielleicht dazu, Polkadot eher als 'Shard-System' als als 'Multi-Chain-System' zu beschreiben. Diese Unterscheidung ist besonders wichtig, wenn es darum geht, Polkadot zu kommunizieren oder zu fördern, da sie hilft, die technischen Merkmale und die Unterschiede zu anderen Projekten (wie Cosmos) klarer zu beschreiben.

Jetzt hat sich mit der Einführung von JAM diese Richtung etwas geändert. Die Technologien, die wir für Polkadot entwickeln, können als Rollup-Technologie angesehen werden, während Polkadot selbst als eine speziell entwickelte Rollup-Hosting-Kette betrachtet werden kann. Die Entwicklung und das Design dieser Technologie sind nicht einfach, daher ist es nicht überraschend, dass wir sehen, dass andere zwei konkurrierende Technologien in ihrer Wirkung weit hinter den Technologien zurückbleiben, die wir für Polkadot entwickelt haben. Genauer gesagt, sind es Optimistic Rollups und Zero-Knowledge Rollups, die beide auf Ethereum verwendet werden. Daher können wir Polkadot als eine native Rollup-Hosting-Kette beschreiben – natürlich könnte diese Aussage nicht geeignet sein, um sie meiner Mutter zu erklären, aber für Menschen, die sich im Krypto-Bereich auskennen, ist es akzeptabel.

Durch JAM, also dem nächsten Entwicklungsschritt von Polkadot, versuchen wir, Polkadot von einem Multi-Chain-Modell in ein allgemeineres Ressourcenmodell zu transformieren. Im Multi-Chain-Modell teilen die verschiedenen Ketten von Polkadot (die innerhalb des Polkadot-Systems als Parachains bezeichnet werden) denselben Sicherheitsrahmen und können miteinander interagieren. Im neuen Modell besteht unser Ziel darin, die Anwendbarkeit von Polkadot weiter zu erweitern, ähnlich wie Ethereum die grundlegenden Funktionen von Bitcoin in eine allgemeine Ressource für Berechnungen erweitert hat. Wir möchten übermäßige subjektive Designbeschränkungen entfernen, damit Polkadot eine breitere Palette von Anwendungsfällen unterstützen kann.

Was ist also die Zukunft von Polkadot? Grundsätzlich wird es zu einem großen, gemeinsamen Computer, der immer auf die Weise funktioniert, die du erwartest. Auf diesem gemeinsamen Computer kannst du Programme hochladen, die Dienste zur Lösung spezifischer Probleme sein können. Da dies ein gemeinsamer Computer ist, können diese Dienste zusammenarbeiten und koordiniert werden.

Der Schlüssel ist, dass es ein einzelner großer gemeinsamer Computer ist. Was wir nicht wollen, ist, ihn in verschiedene Teile zu zerlegen, die nicht wirklich miteinander interagieren können.

Was ist das größte Erfolg von Polkadot? Es ist sein größtes Problem.

Kevin: Ich denke, du spielst auf eine Tatsache an, die uns allen bekannt ist und die in der heutigen Ethereum-Ökosystem tatsächlich viel Verwirrung ausgelöst hat. Was ist also das größte Erfolg von Polkadot bis jetzt?

Gavin: Die Schaffung einer sicheren Shard-Blockchain.

Kevin: Was ist das größte Problem, mit dem Polkadot heute konfrontiert ist?

Gavin: Es ist das Sharding.

Kevin: Was bedeutet das konkret?

Sharding wird seit langem als der 'Heilige Gral' der Blockchain-Skalierung betrachtet, und sein Konzept stammt aus dem Datenbankdesign. In einer Datenbank kannst du eine Datenbank (die im Wesentlichen eine Menge von Datensätzen ist) in mehrere Shards aufteilen. Jeder Shard läuft unabhängig, und die Interaktion zwischen Shards kann nur unter sehr klaren Schnittstellenbedingungen erfolgen, wie zum Beispiel, dass ein Datensatz von einem Shard zu einem anderen Shard verschoben werden kann.

Ein einfaches physisches Beispiel kann helfen, das zu verstehen. Stell dir ein Büro in den 60er Jahren vor, zum Beispiel eine Arztpraxis, in der die medizinischen Aufzeichnungen der Patienten aufbewahrt werden. Diese Aufzeichnungen werden normalerweise in alten Schubladen aufbewahrt. Wenn die Aufzeichnungen nur 20 Personen umfassen, passt wahrscheinlich eine Schublade gut und lässt sich leicht alphabetisch sortieren. Aber wenn die Aufzeichnungen mehr als die Kapazität einer Schublade überschreiten, zum Beispiel mehr Menschen, musst du die Aufzeichnungen auf mehrere Schubladen verteilen. Wenn die Anzahl der Schubladen weiter zunimmt, zum Beispiel vier oder fünf Schubladen benötigt werden, benötigst du auch mehrere Aktenschränke.

Jede Schublade in einem Aktenschrank kann als ein Shard betrachtet werden. Sie laufen unabhängig voneinander: Du kannst eine Schublade öffnen, ohne die anderen zu öffnen, und in einer Schublade suchen, ohne alle Schubladen auf einmal überprüfen zu müssen. Das steht im Kontrast zu einer besonders langen Schublade (zum Beispiel einer 10 Meter langen Schublade). Wenn es nur eine lange Schublade gibt, ist es offensichtlich nicht praktikabel, weil du einen 10 Meter langen Raum brauchst, um sie unterzubringen. Und wenn du nach jemandem suchst, dessen Name mit 'W' beginnt, musst du möglicherweise die gesamte Schublade herausziehen und dann entlang der Schublade bis zur Position von 'W' gehen, was offensichtlich ineffizient ist.

Von diesem Standpunkt aus ist das Design von Sharding sinnvoll. Allerdings bringt es auch Probleme mit sich. Zum Beispiel, was passiert, wenn eine Schublade voll ist? Du musst möglicherweise die Verteilung der Aufzeichnungen anpassen, zum Beispiel die Aufzeichnungen von A bis E in A bis D ändern und die mit E beginnenden Aufzeichnungen in die darunterliegende Schublade verschieben. Das kann dazu führen, dass die nächste Schublade ebenfalls nicht genug Platz hat, also musst du erneut anpassen, und jedes Mal musst du auch das Etikett außen an der Schublade ändern. Dieser gesamte Prozess kann komplex und mühsam werden.

Somit bringt Sharding auch eine Reihe eigener Probleme mit sich.

Der Kern ist, dass diese 'Schubladen' (Shards) unabhängig laufen, sowohl im Design von Shard-Blockchains als auch im Design von Datenbanken. Im Wesentlichen bleibt die Daten nach der Aufteilung immer in Shard-Form, es sei denn, du führst eine sehr spezifische Operation aus, die normalerweise sehr zeitaufwendig, kostspielig und ressourcenintensiv ist, um einen Datensatz oder Daten von einem Shard zu einem anderen Shard zu verschieben. Das bedeutet, dass es einfach sein kann, Aufzeichnungen in einer einzelnen Schublade neu zu organisieren, aber sehr schwierig, Aufzeichnungen zwischen verschiedenen Schubladen neu zu organisieren. Das ist das Problem von Sharding. Für Daten ist dieses Problem vielleicht nicht so schwerwiegend, und das ist auch der Grund, warum Sharding im Datenbankdesign weit verbreitet ist. Aber für Dienste, wie zum Beispiel häufig interagierende und sich ändernde Smart Contracts, ist dieses Modell nicht ideal. Wenn Smart Contracts als Objekte in einer Schublade betrachtet werden, und du möchtest, dass ein Smart Contract in einer Schublade mit einem Smart Contract in einer anderen Schublade interagiert, musst du beide Schubladen gleichzeitig öffnen. Das bedeutet, dass du beide Schubladen herausziehen musst, um sie miteinander zu verbinden und alle Interaktionen durchzuführen, die die Smart Contracts benötigen, und sie dann wieder trennen und in ihre jeweiligen Schubladen zurücklegen musst. Dieser Prozess ist komplex und ineffizient und sehr ungeeignet für Anwendungen, die häufige Interaktionen erfordern.

Wenn du nur zwischen zwei Schubladen arbeitest, ist das schon schwierig genug, aber wenn du möchtest, dass mehrere Schubladen gleichzeitig interagieren, wird es sehr komplex und schwierig. Ein Problem dabei ist, dass du die freie Interaktion zwischen den Schubladen verhinderst, was bedeutet, dass andere Smart Contracts in der Schublade nur diesem einen Interaktionsmuster folgen können. Das gesamte System wird schnell komplex, schwierig und ineffizient.

Eine andere Möglichkeit besteht darin, dass die Schubladen durch das Senden von Nachrichten kommunizieren. Eine Schublade (Shard) kann eine Nachricht veröffentlichen, die später an eine andere Schublade übermittelt wird. Genau das macht Polkadot mit XCM (Cross-Consensus Messaging). Obwohl dieses Verfahren möglich ist, besteht das Problem darin, dass es nicht die enge, effiziente und flexible Interaktion ermöglicht, die viel flüssiger ist, wenn alles im selben Raum oder 'Spielplatz' läuft.

Ein Beispiel: Angenommen, eine Schule hat vier verschiedene Spielplätze, was vier verschiedenen Blockchains entspricht. Wenn du auf einem Spielplatz 'Verstecken' spielst, ist das kein Problem; das Spiel kann reibungslos ablaufen. Aber wenn du über zwei Spielplätze hinweg 'Verstecken' spielen willst, wird es sehr schwierig. Du musst eine Nachricht an den anderen Spielplatz senden, wie 'Ich bin jetzt der Suchende, wenn du in diesen Bereich gehst, werde ich dich fangen.' Und die Spieler auf dem anderen Spielplatz müssen das wissen, aber können es nicht vollständig verstehen, und das gesamte Spiel wird schnell chaotisch.

So ist 'Verstecken' ein Spiel, das nur auf demselben Spielplatz gespielt werden kann. Das ist das Problem zwischen Shards; die Interaktion über Shards hinweg ist wie der Versuch, über Spielplätze hinweg ein Spiel zu spielen, und ist schwer effizient durchzuführen.

Wenn einige Lösungen in einer sehr asynchronen Weise betrieben werden müssen, wird es sehr schwierig, sie zum Laufen zu bringen. Es ist, als könnte man nur durch Nachrichten spielen. Wenn es ein Spiel wie Schach ist, könnte es nicht allzu schwierig sein; aber wenn es ein Spiel wie Verstecken ist, wäre es praktisch unmöglich.

Das Gleiche gilt für Smart Contracts. Einige Smart Contracts laufen in diesem Modell nicht allzu schwierig, vielleicht nur etwas langsamer als normal, aber das ist nicht allzu schlimm. Und einige Anwendungsszenarien, wie die Identitätsüberprüfung (KYC), sind relativ einfach. Zum Beispiel könntest du eine Kette haben, die speziell für die Identitätsüberprüfung zuständig ist, und eine andere Kette, die die Überweisungen abwickelt. Die Überweisungskette könnte bestätigen müssen, ob die Zieladresse die KYC- und AML-Prüfung bestanden hat, bevor sie die Überweisung ausführt. Sie könnte eine Nachricht senden und fragen: 'Hat diese Adresse die KYC- und AML-Prüfung bestanden?' Die Identitätsprüfungs-Kette antwortet: 'Ja', und dann führt die Überweisungskette die Überweisung aus. Der gesamte Prozess könnte einige Sekunden länger dauern, aber das ist nicht schlimm.

Es gibt jedoch auch andere Anwendungsfälle, wie dezentrale Börsen (DEX), die viel komplexer sind. Zum Beispiel musst du den aktuellen Preis abfragen und dann entscheiden, ob du handeln willst. Zu diesem Zeitpunkt musst du möglicherweise eine Nachricht an eine andere Kette senden, die dann antwortet: 'Der aktuelle Preis ist dieser, der Handel kann so erfolgen.' Dann wird die Nachricht zurück an die ursprüngliche Kette gesendet, die dann bestätigt: 'Ich akzeptiere diesen Preis, bitte führe den Handel durch.' Aber wenn der Handel kurz vor der Ausführung steht, könnte die andere Kette sagen: 'Der Preis hat sich geändert, jetzt ist es dieser Preis.' Die Nachrichten werden schnell hin und her gesendet, und der gesamte Prozess wird sehr ineffizient und kann sogar nicht effektiv abgeschlossen werden.

In solchen Fällen müssen die Transaktionen fast gleichzeitig abgeschlossen werden, sonst können sie nicht durchgeführt werden. Dieses Phänomen gleicht dem Spiel auf einem Spielplatz. Bestimmte Spiele, wie Verstecken, können nur in demselben Raum abgeschlossen werden; asynchrone Interaktionen machen das Spiel unmöglich.

Die Lösung ist JAM.

Kevin: Was ist eine praktikable Lösung?

Gavin: Nun, JAM ist mein Vorschlag, die Join Accumulate Machine (JAM).

Kevin: Was ist JAM?

Gavin: JAM ist eine flexible Möglichkeit, die Spieler verschiedener 'Spielplätze' zusammenzubringen und einen temporären Spielplatz zu schaffen, auf dem sie das Spiel 'Verstecken' spielen können. Hier ist ein improvisiertes Beispiel (vielleicht ein wenig verrückt, tut mir leid). Weiter mit dem Beispiel 'Verstecken': Angenommen, es gibt ursprünglich vier feste Spielplätze; in der JAM-Design gibt es keine festen Spielplätze mehr.

Die Spielplätze sind nicht mehr fest, und die Spieler sind nicht mehr an einen bestimmten Spielplatz gebunden. Auch die Kosten für das Bewegen zwischen verschiedenen Spielplätzen sind nicht mehr so hoch. Stattdessen haben wir ein großes Spielgebiet, in dem die Spielplätze schnell entstehen und verschwinden können. In diesem Fall konzentrieren wir uns auf die Spieler im Spiel und bringen vorübergehend die Spieler zusammen, die nahe beieinander sind und sich möglicherweise gegenseitig 'fangen' können, und schaffen einen temporären Spielplatz, auf dem sie weiterhin 'Verstecken' spielen können.

Wenn ein Teil dieser Spieler aus diesem temporären Spielplatz herausläuft, passen wir den Standort des Spielplatzes neu an und definieren den neuen Spielplatzbereich basierend auf den Spielern, die weiterhin nah beieinander sind. Wenn einige Spieler weit voneinander entfernt sind, wissen wir, dass sie sich in naher Zukunft nicht 'fangen' werden, also müssen sie nicht an diesem Spielplatz teilnehmen. Sie sind vorübergehend im 'Spiel außerhalb'-Status, bis sie wieder in die Nähe anderer Spieler kommen und am Spiel teilnehmen müssen, dann werden sie in den neuen Spielplatz aufgenommen.

Wenn wir das System auf diese flexiblere Weise umsetzen, können wir uns ein System vorstellen, das sowohl skalierbar als auch synchronisiert kombinierbar ist. Der Kern ist, dass der sogenannte 'Zustand' (state) nicht dauerhaft aufgeteilt wird. Mit anderen Worten, die Spieler sind nicht fest an einen bestimmten Spielplatz gebunden, sondern werden dynamisch nach Bedarf gruppiert.

Im Szenario der Smart Contracts ähnelt die Umsetzung dieses Konzepts der Platzierung aller Smart Contracts in einem großen gemeinsamen 'Schmelztiegel', aber dieser Schmelztiegel ist nicht dafür da, dass alle Verträge ständig miteinander interagieren, sondern um dynamisch zu partitionieren. Zum Beispiel könnte das System 10, 50 oder 2 Smart Contracts aus diesem Schmelztiegel herausziehen, sie kombinieren und synchron interagieren und laufen lassen, bevor sie wieder getrennt werden. Dann wird neu bewertet und eine andere, unterschiedliche Sammlung von Smart Contracts ausgewählt, die erneut kombiniert und ausgeführt werden, bevor sie wieder getrennt werden.

Diese Methode ermöglicht es uns, mehrere parallele Gruppen von Smart Contracts zur gleichen Zeit zu bearbeiten, anstatt nur eine Gruppe von Smart Contracts synchron zu kombinieren und auszuführen. Durch diese parallele Verarbeitung können wir die Interaktionsverarbeitungskapazität des Systems erheblich erhöhen und eine Interaktionsmenge unterstützen, die Hunderte von Malen mehr als bei herkömmlichen Methoden ist, wodurch echte Skalierbarkeit erreicht wird.