Update zum Pantos-Projekt: Cross-Blockchain Konsens

Lies diesen Beitrag auf Englisch.

In den vergangenen Monaten hat das Pantos-Projekt von zahlreichen strukturellen, personellen und organisatorischen Veränderungen profitiert. Besonders hervorzuheben ist die direktere Kommunikation mit unserer Community via Telegram und den anderen Kanälen. Wir haben auch begonnen, das Projekt in neue Richtungen voranzutreiben. Zu einem guten Teil ist das natürlich der allgemeinen Weiterentwicklung des Projekts geschuldet. Wir haben unsere Kooperationen mit Unternehmen auf den traditionellen Bankensektor ausgeweitet, sehen uns derzeit Anwendungen mit Smart-Grid- und Supply-Chain-Lösungen an und wir kooperieren mit dem Austrian Blockchain Center (ABC), um weitere mögliche Anwendungsfälle zu finden. Auf der technischen Seite suchen wir noch nach Ansätzen, um die Relay-Lösung leichtgewichtiger zu machen sowie nach Nicht-Relay-Alternativen, die in Zeiten mit wenig Transaktionen besser funktionieren.

Wir führen regelmäßig unser Blockchain-Review durch, ein internes Arbeitspapier, in dem wir Aspekte von Blockchains und anderen Ledgern diskutieren, die für das Pantos-Netzwerk interessant sind. Nicht zuletzt auch mit Hilfe eines weiteren, engagierten Pantos-Entwicklers, den wir in unserem Team begrüßen dürfen, wird dies nun zu einem ersten Prototyp führen, der andere Blockchain-Netzwerke als Ethereum verbindet.

Im weiteren Verlauf dieses Blogposts werden wir über das “Wie” der Ermöglichung des Cross-Blockchain Token-Transfers in einem Multi-Ledger-Netzwerk sprechen und einen Implementierungsplan vorstellen. Wir werden auch das Prinzip des globalen Staking näher beleuchten, das wir derzeit als integralen Bestandteil unserer Cross-Blockchain Lösung sehen.

Was das Denken, Können, Wollen, Würden angeht: Liebe Leser, bitte denkt daran, dass es sich bei Pantos nach wie vor um ein Forschungsprojekt handelt. Wenn bereits bekannt wäre, wie man die Cross-Blockchain Kommunikation am besten löst, müssten wir nicht mehr forschen. Durch die Forschung gelangen wir immer wieder zu neuen Erkenntnissen, Ideen und Ansätzen. Auch wenn wir davon ausgehen, eine ganz gute Vorstellung davon zu haben, wie das Endprodukt Pantos aussehen wird, handelt es sich hier noch immer um ein “Work in progress”. Mit anderen Worten: Das Pantos-Netzwerk könnte den dargestellten Ideen in vielen Details ähneln, aber es gibt keine Garantie dafür, dass wir nicht eine ganz andere und sogar bessere Lösung für unsere Ziele finden werden.

Ein Ledger-Multiversum

Als Cross-Blockchain Kommunikationsprotokoll ist Pantos auf genau festgelegte Verfahren und Rollen von Teilnehmern angewiesen. Wir unterscheiden PAN-Holder als Individuen, die das Pantos-Netzwerk nutzen wollen, Pantos-Nodes als Agenten, die als helfende Hände am Protokoll teilnehmen und das Pantos-Orakel als Instanz zur Bereitstellung von Wissen über die Grenzen einzelner Blockchains hinweg. Als Ledger identifizieren wir Blockchains und ähnliche Strukturen, die für die Pantos-Technologie von Interesse sind und schließlich das Pantos-Netzwerk selbst als eine Sammlung von Ledgern, die über Pantos-Technologie verbunden werden sollen. Jede Rolle, PAN-Holder, Pantos-Node und Pantos-Orakel, ist mit einer Signatur versehen, die es erlaubt, signierte Informationen eindeutig mit dem ursprünglichen Unterzeichner zu verknüpfen.

Wenn wir an die Kommunikation zwischen Ledgern denken, unterscheiden wir zwischen Wissenstransfer, bei dem Informationen von einem Ursprungs-Ledger auf einem Ziel-Ledger angefordert werden können und Wissenssynchronisation, bei der Informationen auf allen Ledgern gleichzeitig generiert werden. Die Idee der Smart Contract-Interaktion im Pantos-Netzwerk kann als ein Spezialfall des Wissenstransfers eingestuft werden, bei dem der Transfer in beide Richtungen erfolgt und dabei auch Auswirkungen auf jene Informationen hat, die im Gegenzug übertragen werden. Der Token-Transfer kann wiederum als Spezialfall der Smart Contract-Interaktion betrachtet werden, bei dem Token auf einem Ledger zerstört werden, um sie im Gegenzug auf einem anderen Ledger neu zu erstellen.

Im Pantos-Netzwerk wird immer genau ein bestimmter Ledger als Übertragungskanal (broadcast channel) ausgezeichnet. Dieser Übertragungskanal wird benötigt, um Protokollnotwendigkeiten offen zu kommunizieren, könnte aber auch durch ein benutzerdefiniertes P2P-Netzwerk oder sogar durch einen von einer vertrauenswürdigen Autorität verwalteten Server ersetzt werden. Die einzige Anforderung, die wir an den Übertragungskanal stellen, ist, dass er die Verteilung von Informationen auf transparente Weise ermöglicht und dass die Veröffentlichung von Informationen auf diesem Kanal wirtschaftlich tragbar ist. Die Integrität der über den Übertragungskanal veröffentlichten Informationen wird durch das Signaturprinzip sichergestellt, da fehlerhafte oder bösartige Informationen bis zum Urheber zurückverfolgt werden können.

Wir verwenden den Begriff On-Chain für Informationen, die auf einem bestimmten Ledger gespeichert sind sowie für Smart Contract-Funktionen, die auf einem bestimmten Ledger ausgeführt werden. Off-Chain hingegen sind Informationen, die über den Übertragungskanal geteilt werden. Off-Chain Kommunikation muss zwangsweise dem Protokoll entsprechend korrekt sein. Implizit werden nur solcherart gültige Informationsnachrichten als Teil des Protokolls betrachtet. Daher ist es für den Übertragungskanal nicht erforderlich, auch selbst Smart Contract-Funktionalität anzubieten.

Betrachten wir nun den Fall, dass ein PAN-Holder eine Menge an PAN, von einem Ledger stammend, an einen anderen PAN-Holder auf einem anderen Ledger senden möchte. Nennen wir die PAN-Holder Michael und Susanne und die Ledger Ethereum und BSC. In diesem Beispiel verwenden wir IOTAs Tangle als Übertragungskanal. Außerdem beziehen wir einen zufälligen Pantos-Node namens Bernhard mit ein, der als helfende Hand bei der Cross-Chain Transaktion dient.

Als Prämisse nehmen wir die Möglichkeit an, Funktionen On-Chain und Cross-Chain im Namen eines anderen Nutzers aufzurufen (und Assets zu übertragen). Das bedeutet, dass Bernhard mit Michaels Zustimmung in Form einer unterschriebenen Erklärung (hier ist die Signatur auch von Bedeutung) in der Lage ist, PAN von Michaels Wallet On-Chain auf eine andere Wallet zu übertragen, ohne dass Michael eigene Transaktionen direkt an den betreffenden Ledger übermitteln muss. In diesem Szenario muss Michael nicht einmal etwas von der nativen Währung des betreffenden Ledgers (Blockchain oder andere DLT) besitzen. Um eine solche Aufruf-Funktionalität zu ermöglichen, werden wir den Übertragungskanal verwenden. Dort kann Michael seine Absicht teilen, PAN von seiner Ethereum Wallet an Susannes BSC Wallet zu verschieben und Bernhard kann diese Absicht nutzen, um die Transaktion durchzuführen.

Die Cross-Chain Interaktion erfolgt in Paketen, die von einem PAN-Holder als Initiator (in unserem Beispiel Michael) erstellt werden. Ein solches Paket enthält eine maximal zu zahlende Gebühr in PAN, einen Ursprungs-Ledger, in dem der Initiator genug PAN hält, um die Gebühr zu decken, Transaktionsvorbereitungen, die es PAN-Nodes ermöglichen, die angeforderte Blockchain-Interaktion ohne weitere Beteiligung des Initiators durchzuführen, für jede solche Transaktionsvorbereitung einen designierten Ledger sowie ein auf diesen Ledger zugeschnittenes Timeout. Jede Transaktionsvorbereitung kann darüber hinaus ein gefordertes Pfand (Collateral) (in PAN oder in der nativen Währung des angeforderten Ledgers) enthalten, die es Beobachtern ermöglicht, einzuspringen, wenn der Pantos-Node, der den Transaktionsauftrag (das Paket) angenommen hat, diesen nicht zu Ende führt. Dieses Pfand sollte folglich groß genug sein, um notwendige Rückabwicklungsoperationen abzudecken.

Für den Cross-Chain Fall, in dem Michael 100 PAN von Ethereum an Susanne auf BSC senden möchte und bereit ist, dafür 2 PAN zu zahlen, die von den übertragenen PAN abgezogen werden sollen, packt Michael alle notwendigen Informationen in ein Paket und veröffentlicht dieses Paket im Übertragungskanal. Die Transaktionsvorbereitung besteht in diesem Fall aus einer “Burn”-Transaktion auf Ethereum, einer “Create”-Transaktion auf BSC und einer “Finalize”-Transaktion für Ethereum. Nun sieht Bernhard, unser Pantos-Node als helfende Hand, dieses Paket und übernimmt Michaels Auftrag, indem er eine “Claim”-Transaktion auf dem Ursprungs-Ledger Ethereum veröffentlicht, die in diesem Fall Michaels Token verbrennt. Dann verwendet Bernhard das Pantos-Orakel auf BSC, um zu verifizieren dass die “Burn”-Transaktion auf Ethereum stattgefunden hat. Dies ist für Bernhard notwendig, um die auf Ethereum zerstörten PAN auf BSC wiederherstellen zu können. Anschließend schließt Bernhard die Transaktion auf Ethereum ab, indem er das Pantos-Orakel auf Ethereum verwendet, um zu verifizieren, dass die “Create”-Transaktion tatsächlich stattgefunden hat. Mit diesem letzten Schritt ist sichergestellt, dass Susanne 98 PAN auf BSC erhalten hat und Bernhard darf sich daher mit gutem Recht 2 PAN als Gebühr auf seinem Ethereum-Konto gutschreiben.

Die Länge der Timeouts, die optimale Höhe von Gebühren und Pfändern (Collaterals) und die Frage, wie entschieden wird, welcher Pantos-Node den Anspruch auf die Anfrage gewinnt, sind noch offene Fragen. Ein wahrscheinlicher Kandidat für diesen Auswahlprozess ist eine stake-basierte Hash-Funktion über die eingereichte Anfrage, mit der Pantos-Nodekennung als Salt. Dies erzeugt eine zufällige Gebühr zwischen Null und der maximalen Transaktionsgebühr, wie vom Initiator beabsichtigt. Mit je mehr Einsatz ein Pantos-Node sich beteiligt, desto höher sollten seine Chancen auf eine höhere Gebühr sein. Je näher die Anfrage dem Zeitlimit kommt, desto höher sollte die maximale Gebühr sein, die ein Pantos-Node einkassieren kann. Auf diese Weise können die Gebührenbelohnungen unter den aktiven Pantos-Nodes gerecht verteilt werden und zusätzlich könnten die PAN-Holder am Ende weniger Gebühren zahlen, als sie es geplant hatten.

Globales Staking

Collateral bezieht sich auf ein Pfand, eine Sicherheit, die eine Pantos-Node bis zum Abschluss des Auftrags sperren muss, um sicherzustellen, dass der Abschluss schließlich erfolgt. Das bedeutet, dass eine solche Sicherheit dem Zweck dient, möglicherweise von jemand anderem eingezogen zu werden. Stake hat eine ähnliche Verwendung und bezieht sich ebenfalls auf gesperrte Sicherheiten, um die Integrität sicherzustellen. Stake wird jedoch häufiger verwendet, um eine Knappheit zu erzeugen und eine zufallsbasierte Gewinnerauswahl in Bezug auf die eingesetzten Ressourcen eines Pantos-Nodes zu ermöglichen. Stake stellt auch sicher, dass Pantos-Nodes eine Mindestanforderung erfüllen und verhindert Spam-Angriffe.

Das Pantos-Orakel kann auf recht unterschiedliche Weise implementiert werden. Es ist möglich, eine Orakel-Implementierung zu haben, die nur aus Relay-Lösungen besteht und damit aus Replikationen jedes Ledgers auf jedem anderen Ledger im Pantos-Netzwerk. Aus Gründen der Kosteneffizienz untersuchen wir derzeit auch andere Orakellösungen, die meist auf Abstimmungsverfahren basieren. Für den Fall, dass vertrauenswürdige Pantos-Nodes als Pantos-Orakel teilnehmen, scheint es sogar möglich zu sein, optimistische Orakel mit Disputmöglichkeiten einzusetzen. Das bedeutet, dass die von einem Pantos-Node gegebene Antwort nach einem vordefinierten Timeout als korrekt angesehen werden kann, wenn kein anderer Pantos-Node in der Zwischenzeit einen Disput gestartet und einen Abstimmungswettbewerb ausgelöst hat. Vorerst gehen wir davon aus, dass das Pantos-Orakel unterschiedliche Ansätze für verschiedene Ledger und unterschiedliche Durchlaufzeiten beinhalten wird. Deshalb verweisen wir lediglich auf die Notwendigkeit von transaction inclusion verifications mit der Möglichkeit von allgemeinen Orakellösungen.

In einem Pantos-Netzwerk mit mehreren Blockchains könnte man naiv betrachtet, jeden Ledger mit jedem anderen Ledger über eine Orakellösung verbinden und für jede dieser Verbindungen von Pantos-Nodes verlangen, gesperrte Einsätze (Stakes) auf beiden Ledgern bereitzustellen. Bei näherer Betrachtung kann ein allgemeines Orakel oder eine On-Chain Orakel-Schnittstelle eine Vielzahl von eingehenden Verbindungen bedienen. Auf diese Weise genügt schon ein gesperrter Einsatz (Stake) auf jedem Ledger des Pantos-Netzwerks. Wir haben bereits die Möglichkeit der Wissenssynchronisation vorgestellt, wie sie zum Beispiel in unseren frühen Whitepapers genutzt wurde. Wir werfen nun einen Blick auf die Implikationen dieser Idee für unseren Bedarf an Sicherheit im Pantos-Netzwerk.

Nehmen wir als gegeben an, dass PAN und andere Token frei von einer Blockchain auf eine andere bewegt werden können. Dies ergibt zwei Zustände, in denen ein Token sein und übertragen werden kann. On-Chain und Cross-Chain. Ein Asset existiert entweder vollständig auf einem bestimmten Ledger und bei einer On-Chain Transaktion verlässt dieses Asset niemals seinen Ledger, das Asset befindet sich also in einem lokalen Zustand. Oder dieses Asset wird von einem Ledger auf einen anderen übertragen, dann gibt es einen Übergangszustand, bei dem das Asset weder auf dem einen noch auf dem anderen Ledger existiert. Der Schritt von dort zu globalen Einsätzen besteht in der Frage nach einem globalen Zustand, in dem ein Asset über alle Ledger im Pantos-Netzwerk gleichzeitig synchronisiert wird und sich auf all diesen Ledgern gewissermaßen gleichzeitig befindet. Solche globalen Zustände und globalen Einsätze sind natürlich eher auf der teuren Seite, da zumindest das Status-Update auf jedem Ledger separat kommuniziert werden muss.

Globale Zustände sind also eher teuer und eher langsam, aber aus demselben Grund sind sie ziemlich zuverlässig. Ein weiterer Vorteil des globalen Zustands ist, dass er uns erlaubt, die Einsätze (Stakes) in diesem globalen Zustand zu haben. Das bedeutet dann auch, dass wir statt verteilter gesperrter Assets auf jedem Ledger eine Sammlung von gesperrten Assets auf allen Ledgern gleichzeitig haben, was den Gesamtwert dieses Einsatzes (Stakes) und das damit verbundene Sicherheitsniveau enorm erhöht.

Eine der verbleibenden Fragen in Bezug auf solche globalen Einsätze ist, wie man mit sich unehrlich verhaltenden Pantos-Nodes umgeht. Für den Fall, dass Pantos-Nodes einfach nur helfende Hände sind und ihre On-Chain Aktionen im Guten wie im Schlechten aufgezeichnet werden, reichen die lokalen Pfände, die notwendigerweise mit jedem Claim bereitgestellt werden, aus, um ehrliches Verhalten sicherzustellen. Orakel jedoch, insbesondere wenn Abstimmungen ins Spiel kommen, können nicht so einfach verfolgt werden und globale Operationen können nicht mit lokalem Pfand gelöst werden. Damit Pantos-Nodes auch Pantos-Orakel-Dienste anbieten können, muss daher die Möglichkeit bestehen, ihnen ihren globalen Einsatz im Falle von Fehlverhalten abzuziehen.

Eine weitere Frage ist, wie man mit dem Dilemma der “No-Bad-Actors” umgeht. Für den Fall, dass sich Pantos-Nodes nie daneben benehmen, könnten sich andere Pantos-Nodes dafür entscheiden, ihre Betriebskosten zu senken, indem sie ihre Peers einfach nicht mehr auf Fehlverhalten überwachen, was ein schwerwiegendes Sicherheitsproblem für das Pantos-Netzwerk darstellt. Gängige Lösungen für dieses Problem sind die Möglichkeit von zufälligen Verstößen durch Pantos-Nodes, die insgeheim Tests für ihre Peers sind. Dann sollten sowohl der testende Node als auch der reagierende Node belohnt werden und der Anreiz, das Verhalten anderer Nodes zu verfolgen, bleibt intakt. Die Idee solcher Belohnungen kann umgesetzt werden, indem zusätzliche (aber eher minimale) Wartungsgebühren zu jeder Transaktion hinzugefügt werden, die in lokalen Pools gesammelt und für solche Tests verwendet werden.

Zeitplan für die Implementierung

Werfen wir noch einen Blick auf die Zukunft des Pantos-Projekts. Dieser Ausblick ist keineswegs vollständig und da wir noch viele offene Fragen zu lösen haben, könnte das tatsächliche Ergebnis anders ausfallen als derzeit geplant.

• Im Moment arbeiten wir daran, zwei Blockchains zu verbinden, wobei nur eine davon Ethereum ist. Wie immer wird jeder Prototyp zunächst für Testnetzwerke veröffentlicht und erst wenn er sich als funktionstüchtig erweist, wird er auf die öffentlichen Netzwerke ausgerollt
• In einem ersten Schritt konzentrieren wir uns notwendigerweise hauptsächlich auf On-Chain Smart Contracts. Das bedeutet, dass Pantos-Nodes, aber vor allem Pantos-Orakel, am Anfang vertrauenswürdige Autoritäten sein werden
• Pantos-Nodes als helfende Hände, die Pantos-Orakel nutzen, um PAN-Holdern die Möglichkeit zu geben, ihre Assets über verschiedene Blockchains hinweg zu bewegen, werden ebenfalls recht früh implementiert werden. Sobald diese Möglichkeit zur Verfügung steht, werden PAN-Holder in der Lage sein, an der Cross-Blockchain Interaktion teilzunehmen und dafür Gebühren zu verdienen
• Damit PAN-Holder aktiv am Testen der Cross-Blockchain Interaktion teilnehmen können, benötigen wir eine Wallet-Lösung, die höchstwahrscheinlich eine Browser-Plugin-Lösung sein wird
• Sobald wir ein paar helfende Hände in Form von Pantos-Nodes haben, werden wir damit beginnen, eine dritte Blockchain zu implementieren und Tests durchzuführen, damit Pantos-Nodes auch Orakeldienste von geringerer Wichtigkeit anbieten können
• Sobald das Netzwerk der Pantos-Nodes ausreichend zuverlässig ist, werden wir den Pantos-Nodes erlauben, aktiv an der Pantos-Orakel-Lösung teilzunehmen, wodurch die vertrauenswürdige Autorität der früheren Implementierungen zu einer unter vielen reduziert wird. Für Erweiterungen des Pantos-Netzwerks in Form zusätzlicher Blockchains benötigen wir möglicherweise jeweils eine Anfangsphase, in der nur die vertrauenswürdige Instanz bestimmte Orakelfragen bearbeiten kann, aber schließlich werden die Pantos-Nodes in ihrer Gesamtheit selbst zum Pantos-Orakel

Wie bereits in unseren Social-Media-Kanälen angedeutet, bereiten wir einen Lightning Talk vor, um Details zu diesem Pantos-Update zu liefern sowie Fragen zu beantworten.

Tritt unserer Telegram-Gruppe bei und bombardiere uns mit Fragen, die beim Lesen dieses Artikels aufgetreten sind:

- Deutsche Gruppe https://t.me/PantosIO_DE

- Englische Gruppe https://t.me/PantosIO_EN

Abschließend möchten wir euch noch verraten, was wir für den nächsten Blogpost geplant haben. Darin werden wir einen Ansatz zur Lösung des Skalierbarkeitsproblems von Abstimmungsorakeln vorstellen. Wenn die Abstimmung On-Chain stattfindet, wird dies naiverweise teurer, wenn es mehr Nodes gibt, die teilnehmen wollen. Mit unserem Ansatz bleibt das Sicherheitsniveau unverändert, aber die On-Chain Kosten bleiben unabhängig von der Teilnehmeranzahl konstant.