Pantos Projekt-Update — Oracles und Skalierbarkeitsmagie
Lies diesen Artikel auf Englisch.
Heute wollen wir über einen kostenreduzierenden Oracle-Ansatz sprechen, der im Hinblick auf seine Effizienz regelrecht wie Magie wirkt. Wir werden nicht genauer auf die technischen Details eingehen, aber die Motivation für diesen Ansatz besteht darin, eine Gruppe unabhängiger Signaturen zu einer einzigen Signatur zusammenzufassen. Die Verifizierung der resultierenden Signatur dient dann als Beweis dafür, dass eine ausreichende Anzahl von Unterzeichnern mit der signierten Nachricht einverstanden ist. Auf diese Weise bleiben die Kosten für Oracle-Antworten unabhängig von der Anzahl der validierenden Oracle-Nodes immer gleich. Bevor wir mit dem eigentlichen Thema beginnen, wollen wir zunächst einen kurzen Blick hinter die Kulissen seit unserem letzten Projekt-Update werfen.
In den vergangenen Monaten haben wir mehrere große Schritte in Richtung einer besseren Zukunftsgestaltung für Pantos unternommen. Neben der Vertiefung unserer Forschung und der Stärkung unserer Unternehmens- und Forschungspartnerschaften (mehr darüber in unserer CDL-BOT-Erweiterung), haben wir mit der Entwicklung eines Proof of Concept (PoC) begonnen, um uns mehr auf die praktischen Aspekte und Erfahrungen zu konzentrieren.
In unserem letzten Projekt-Update haben wir einen genaueren Blick auf globale Staking- und Protokollschemata geworfen, um ein blockchainübergreifendes Pantos-Netzwerk zu ermöglichen. Aufbauend darauf wollen wir heute einen genaueren Blick auf einen integralen Bestandteil des Pantos-Protokolls werfen: Oracle-Lösungen. Das geplante Pantos-Netzwerk beinhaltet Pantos-Nodes und Pantos-Oracles als Bausteine. Pantos-Nodes stellen sicher, dass Infrastruktur-Aufgaben abgearbeitet werden. Pantos-Oracles dienen dazu Informationen von einer Blockchain zur anderen zu übertragen. Durch die Unterscheidung zwischen Pantos-Nodes und Pantos-Oracles ist es möglich, die Pantos-Nodes mit sicherheitsunkritischen Wartungsaufgaben zu beauftragen. Da in der Anfangsphase für die Pantos-Oracles standardmäßig vertrauenswürdige Instanzen eingesetzt werden, ermöglicht diese Unterscheidung im weiteren Verlauf eine schnellere Einführung und Implementierung stufenweiser System-Upgrades.
Oracle-Schemata
Bei einem “Oracle” (dt. Orakel) handelt es sich in diesem Kontext um ein Abfragetool. In einfachen Worten bedeutet das, dass jeder Pantos Client das Oracle auf Blockchain A abfragen kann, um festzustellen, ob eine bestimmte Transaktion auf Blockchain B enthalten ist. In der Vergangenheit haben wir uns bereits genauer mit Abstimmungsmechanismen und Relay-Lösungen beschäftigt (Whitepaper 5). Relay-Lösungen scheinen in der Praxis bisher nicht langfristig zu funktionieren, wie vor allem am Beispiel von “BTC-Relay” deutlich wird. Unseren Beobachtungen zufolge ist dies vor allem auf die auch im Leerlauf beständig anfallenden Kosten zurückzuführen. Um mit dem Bedarf an weniger häufigen Validierungsperioden besser umgehen zu können, benötigen wir ein bedarfsorientiertes Konsensprotokoll. Dies läuft auf eine eher Node-zentrierte Lösung hinaus. Reine On-Chain-Abstimmungsmechanismen (und in ähnlicher Weise das Sammeln und die Masseneinreichung von Signaturen) skalieren nicht mit der Anzahl der teilnehmenden Nodes. Je größer das Netzwerk wird, desto teurer wird der tägliche Betrieb. Bevor wir weiter über die “Magie” sprechen, die skalierbare Oracle-Transaktionen ermöglicht, wollen wir zunächst auf eine gemeinsame Eigenschaft aller praktischen Protokolle hinweisen, die wir bisher gesehen haben.
Wenn wir in diesem Blogpost über Skalierbarkeit und Kosten sprechen, sprechen wir (sofern nicht anders angegeben) immer von On-Chain-Operationen und die dadurch entstehenden Gaskosten. Während On-Chain-Operationen aus computertechnischer Sicht trivial sein mögen, sind die Öffentlichkeit und die dezentralisierte Validierung die dabei kostspieligen Faktoren von Blockchain-basierten Smart Contracts.
Dieser Blockchain-intrinsische Kostenfaktor lässt sich nicht einfach skalieren. Wir wollen, dass Transaktionen öffentlich sind, und diese öffentliche Verifizierung hat ihren Preis. Dezentrale Blockchains erlauben nur einen sehr begrenzten Durchsatz. Dieses Problem lässt sich auch gut mit einem Gedankenspiel illustrieren. Wir alle kennen Spam, das Problem der ungerichteten Massenwerbung bei E-Mails. Auf Blockchains umgesetzt würde außerdem jeder Empfänger dasselbe Postfach lesen. Kostenfrei kann so ein global einsehbarer Kommunikationskanal nicht funktionieren und bedeutungsvoll bleiben. Als Gegenmaßnahme im Blockchainbereich haben sich zu den Datenmengen proportionale Gebührenstrukturen (Gaskosten) etabliert. Damit wird Spam nicht unmöglich, aber sehr teuer. Derartige Durchsatzgrenzen werden nicht so einfach verschwinden. Aus diesem Grund kommen bei Blockchain-Protokollen, die angeben, nachhaltiger zu sein, und die Abfrage von Off-Chain-Informationen ermöglichen, Streitschlichtungsmechanismen zum Einsatz. Diese erfordern eine Form von Staking-Währung als Sicherheit und/oder Zugangsberechtigung. In unserem Fall der Blockchain-Interoperabilität, wo das Protokoll auf mehreren Blockchains arbeitet, haben wir zwei Möglichkeiten. Entweder nutzen wir native Blockchain-Währungen für das Staking oder wir verwenden ein Asset, das auf jeder relevanten Blockchain verfügbar ist.
Einfache Oracle-Implementierungen, insbesondere Relay-Lösungen, neigen dazu, native Blockchain-Währungen zu verwenden. Aus technischer Sicht besteht der Zweck des Stakes darin, sicherzustellen, dass Nodes im Falle eines vorgebrachten Widerspruchs nicht auf den Transaktionskosten sitzen bleiben, bzw. für diese Wartungsleistung sogar entlohnt werden. Die Verwendung von nicht nativen Blockchain-Währungen erscheint daher eher unnatürlich, da die Blockchain dann Wechselkursinformationen erfassen müsste, um sicherzustellen, dass solche Wartungskosten auch bezahlt werden können. Die Notwendigkeit, die Wechselkurse von nicht nativen Blockchain-Währungen zu verfolgen, kann durch flexible Gebührenstrukturen gelöst werden, bei denen die Wechselkurse implizit durch angepasste Preise aktualisiert werden. Solche Gebührenstrukturen erhöhen jedoch die spieltheoretische Komplexität, was im Falle von Relay-Lösungen als unnötiger Mehraufwand betrachtet werden kann.
Direkte Oracle-Implementierungen beginnen mit einem Anwendungsfall, bei dem zwei unterschiedliche Blockchains verbunden werden. Wenn immer mehr Blockchains dem Interoperabilitätsnetzwerk beitreten, kann einer der Vorteile des Stakings mit blockchainübergreifenden Währungen (wie PAN) und globalen Stakes wie folgt skizziert werden: Böswillige Akteure könnten das Interoperabilitätsnetzwerk manipulieren, indem sie eine ausreichende Anzahl von Oracle-Nodes übernehmen, mit dem Ziel falsche Informationen zu propagieren. Dies ist grundsätzlich unabhängig davon möglich, wie hoch der Einsatz für das Staking ist. Im Falle nativer Blockchain-Währungen ist diese Form des Angriffs jedoch relativ risikofrei (für den Angreifer). Der Wert der Stakes ändert sich nicht, wenn sie in nativen Blockchain-Währungen bereitgestellt werden. Für eine blockchainübergreifende Währung sieht das etwas anders aus. Im Falle eines Angriffs wird eine solche, insbesondere eine, die hauptsächlich als Gas für den Betrieb des Interoperabilitätsnetzwerks verwendet wird, zusammen mit dem Netzwerk vom Markt abgewertet. Der Wert von PAN ist an die Vertrauenswürdigkeit des Pantos-Netzwerks gebunden, sodass Investitionen in PAN-Stakes eine kostspielige Sache sind, wenn die Motivation einen Stake anzulegen eine Entwertung des Netzwerks nach sich zieht.
Eine einfache Implementierung von Protokollen für das Staking nicht nativer Währungen würde auf unabhängigen Smart Contracts auf jeder teilnehmenden Blockchain aufbauen. Dies kann ein Problem darstellen, da es so zu einer Fragmentierung kommen könnte, welche die Kosten für böswillige Angriffe senken würde. Um dieses Problem zu lösen, planen wir derzeit, globales Staking als verhältnismäßig teure Multi-Blockchain-Operation zu ermöglichen. Globale Operationen müssen zeitgleich auf allen teilnehmenden Blockchains stattfinden. Globale Status beziehen sich dann auf Parameter, die auf diese Weise synchronisiert werden. Ein Token (und jeder andere On-Chain-Parameter) kann in einen globalen Status versetzt werden und kann dann als globaler Stake verwendet werden, der überall gleichzeitig synchronisiert wird. Globales Staking stellt somit sicher, dass sich die Stakes nicht nur auf die meistgenutzten Blockchains konzentrieren.
Die Magie von Oracles
“Jede hinreichend fortgeschrittene Technologie ist von Magie nicht mehr zu unterscheiden.” - Arthur C. Clarke
Wie oben beschrieben, lassen sich Oracle-Lösungen nicht so einfach skalieren. Wir gehen von einer Reihe von Oracle-Nodes aus und nehmen an, dass für die korrekte Beantwortung einer Oracle-Anfrage ein Konsens zwischen diesen Oracle-Nodes erforderlich ist. Um diesen Konsens zu erreichen, müssen sich die Oracles auf der Chain einigen, was (möglicherweise) mehrere Transaktionen von mehreren Oracle-Nodes erfordert. Alternativ könnte ein bestimmter Oracle-Node für eine bestimmte Zeitspanne die Signaturen anderer Oracle-Nodes sammeln und diese gesammelt einreichen. Für die Ethereum-Blockchain und ECDSA-Signaturen ist dieser zweite Ansatz bereits deutlich kostengünstiger, da solche Signaturen fest im Ethereum-Protokoll verankert und somit einigermaßen erschwinglich sind. Wenn jedoch mehr und mehr Nodes zu diesem Konsensprotokoll beitragen, wird die On-Chain-Validierung um denselben Faktor teurer.
Die Mathematik und insbesondere die Kryptographie bieten wunderbare Lösungen für praktische Probleme. In diesem Blogpost verzichten wir auf fortgeschrittene technische Details und diskutieren stattdessen die Eigenschaften und Vorteile einer bestimmten Methode zur Lösung unseres Skalierbarkeitsproblems. Für den interessierten Leser auf der Suche nach Stichworten für weitere Literatur dürfen wir anmerken, dass es sich um Boneh-Lynn-Shacham (BLS)-Schwellenwert-Signaturverfahren und Distributed Key Generation (DKG)-Protokolle handelt.
Die Kryptographie ist für unseren Fall asymmetrischer Natur. In der Regel gibt es zusammengehörige Private und Public Keys, wobei Nachrichten, die mit dem einen verschlüsselt wurden, mit dem anderen wieder entschlüsselt werden können. In einigen Fällen ist der Unterschied zwischen Public und Private Keys lediglich eine Frage des Zugriffs. Die Entschlüsselung einer verschlüsselten Nachricht mit einem Public Key beweist, dass jemand, der Zugriff auf den passenden Private Key hat, für die Verschlüsselung dieser Nachricht verantwortlich ist. Eigentum bedeutet in diesem Zusammenhang, dass jemand Zugang zu einem Private Key hat, und dieser Zugang sollte mit äußerster Vertraulichkeit behandelt werden. Input und Output der Verschlüsselung/Entschlüsselung sind asymptotisch gleich groß. Mit Hilfe von Hash-Funktionen können Private/Public-Key-Paare schließlich dazu verwendet werden, Signaturen fester Größe aus beliebigen Datensätzen zu erstellen, bei denen Eigentum immer noch die gleiche Bedeutung hat.
Hash-Funktionen und Private/Public-Key-Paare können bereits als eine Form von Magie betrachtet werden. Mit BLS-Schwellensignaturverfahren gehen wir noch einen Schritt weiter. Mit solchen Protokollen können wir einen Distributed Private Key erstellen, bei dem eine Reihe von Nodes jeweils ihre eigenen Anteile an einem Private Key hält, jedoch keiner von ihnen Eigentümer des Distributed Private Key ist. Der Distributed Private Key ist wiederum mit einem Public Key verknüpft. Kombiniert man also die Ergebnisse der Nodes, die ihre Anteile an dem Private Key verwenden, um dieselbe Nachricht zu verschlüsseln, erhält man eine verschlüsselte Nachricht, die einfach mit dem Public Key entschlüsselt werden kann. Das gleiche Verfahren gilt für Signaturen. Und noch besser: “Schwellenwert” bedeutet in diesem Zusammenhang, dass die von uns verwendete BLS-Variante Schwellensignaturen zulässt. Eine festgelegte Anzahl verschiedener Private Key-Anteile erlaubt es, eine Nachricht so zu signieren, als wäre sie mit dem Distributed Private Key signiert worden. Dies ermöglicht ein Szenario mit z. B. 101 verifizierten Oracles, bei dem es für die Bestätigung einer gültigen Signatur ausreicht, dass die übereinstimmenden Antworten von 51 dieser Oracles kombiniert werden.
Bei BLS-Schwellensignaturverfahren ändern sich jedes Mal, wenn sich die Menge der Oracle-Nodes ändert, auch der Distributed Private Key, die Private Key-Anteile und der Public Key. Einfache Implementierungen erfordern eine vertrauenswürdige Instanz, die die Erstellung dieser Schlüssel überwacht. Diese vertrauenswürdige Instanz würde dann jedoch den Distributed Private Key kennen und könnte eine gültige Signatur erstellen, ohne einen der Oracle-Nodes befragen zu müssen. An dieser Stelle kommen die DKG-Protokolle ins Spiel. Mit DKG-Protokollen entfällt die Notwendigkeit einer allwissenden Überwachung. Während BLS-Schwellenwert-Signaturverfahren selbst bereits als magisch angesehen werden sollten, ist das DKG-Protokoll der Teil dieses Ansatzes, der es ermöglicht, dass diese Art von Magie für unsere Bedürfnisse von praktischem Nutzen ist.
Eine funktionierende Implementierung dieses magischen Ansatzes kann hier gefunden werden: https://github.com/pantos-io/ioporacle. Dieser Proof of Concept läuft auf einem privaten Ethereum-Testnetzwerk und nutzt IOTA als Broadcast-Kanal für einen Teil der notwendigen Off-Chain-Oracle-Kommunikation. Die On-Chain-Verifizierungskosten sind bei diesem Ansatz im Durchschnitt konstant, unabhängig von der Anzahl der teilnehmenden Oracle-Nodes. Bereits bei mehr als drei Oracle-Nodes ist das spontane On-Chain-Voting teurer als unser Ansatz. Die Massenübermittlung von ECDSA-Signaturen ist bei 15 oder mehr Nodes teurer. Unser Ansatz ermöglicht immer noch die gleichen On-Chain-Kosten für die Beantwortung von Anfragen, selbst für 1.000 oder mehr Oracle-Nodes.
Es ist anzumerken, dass die Kosten in Form von Off-Chain-Kommunikation und -Rechenleistung nicht konstant sind. Um eine ordnungsgemäß signierte Nachricht zu erstellen, muss jemand signierte Nachrichten von einer ausreichenden Anzahl anderer Nodes sammeln. Um ein neues Private/Public Key-Paar zu erstellen, müssen alle Nodes maßgeschneiderte Nachrichten an alle anderen Nodes senden. Diese Kosten können im Vergleich zu den On-Chain-Kosten immer noch als gering angesehen werden, dennoch sollte bedacht werden, dass selbst bei konstanten On-Chain-Kosten eine Begrenzung der Anzahl zugelassener Oracle-Nodes durchaus sinnvoll ist.
Schlussworte und Aussichten
Zusammenfassend haben wir heute Schwellenwert-Signaturverfahren diskutiert, mit denen Blockchain-Oracles gleichbleibende Gaskosten für On-Chain-Antworten haben können, unabhängig von der Anzahl der verifizierten Oracle-Nodes. In unserer Beispielimplementierung beantworten wir Anfragen zur Verifizierung von Miteinbeziehung von Transaktionen. Es sei darauf hingewiesen, dass weitere Kostensenkungen durch Batching-Lösungen erreicht werden können, die entweder Block-Header oder Meilensteine aus der Quell-Blockchain verwenden.
Wir suchen derzeit nach weiteren Pantos-Developern, um Pantos auf die nächste Ebene zu bringen (Front-End-Developer, Blockchain-Developer). Außerdem suchen sowohl die TU Wien als auch die TU Hamburg nach PhD-Kandidaten, um die Forschungsziele von CDL-BOT weiter voranzutreiben (Seite für Neuigkeiten rund um CDL-BOT).
Wie bereits erwähnt, arbeiten wir derzeit an einem praktischeren PoC, um die kontinuierliche Testung eines vorläufigen Pantos-Netzwerks zu ermöglichen. Für das nächste Projekt-Update planen wir, einen kleinen Einblick in diesen PoC zu geben. Genauer gesagt werden wir darin ausführen, was uns im Detail erwartet und wie interessierte Leser diesen PoC testen können. Nach einer internen Alpha-Test-Phase werden wir nach und nach Funktionen für öffentliche Beta-Tests in den Testnetzen von Ethereum und der Binance Smart Chain zur Verfügung stellen. Zunächst werden die Beta-Tests für Developer und technisch versierte Power-User verfügbar sein. Später, nach der Freigabe von Clients mit verbesserter Benutzerfreundlichkeit und mit grafischen Benutzeroberflächen, werden auch reguläre Nutzer das vorläufige Pantos-Netzwerk testen können.
