Pantos-Projekt Update: Wege zur blockchainübergreifenden Kommunikation

Pantos
Pantos
Published in
13 min readDec 16, 2020

Lies diesen Beitrag auf Englisch.

Das Projektziel unserer Pantos-Reise haben wir auch 2,5 Jahre nach dem Startschuss noch gut im Blick. Die Blockchain-Branche erfindet sich jedoch beharrlich neu. Ende 2017 bis Anfang 2018 sind wir mit der Vision gestartet, etwas mehr Kooperation in die zersplitterte Blockchain-Welt zu bringen. Mittlerweile lassen viele Projekte ihre tatsächliche Anwendbarkeit schon wesentlich besser hervorblitzen. Dazu kommt, dass auch die traditionelle Finanzindustrie sich zunehmend den neuen Möglichkeiten der Blockchain-Welt öffnet. In diesem Beitrag geben wir einen Überblick über unsere bisherigen Highlights sowie einen Ausblick auf die nähere Zukunft. Wir werden in diesem Artikel überdies Gewinnmöglichkeiten für Investoren erörtern.

Gerade im Rückblick wird uns deutlich, wie intensiv die Arbeit und wie rasant unsere Fortschritte der vergangenen 2,5 Jahre waren. Aber wer hätte es gedacht… die Zukunft wird für Pantos sogar noch aufregender. Aus diesem Grund werden wir uns mit dem Rückblick auch kurz halten und nur die wichtigsten Meilensteine hervorstreichen:

Teilnehmer des Pantos Technology ICO haben über einen Zeitraum von 4 Wochen insgesamt 616 BTC als Vertrauensvorschuss in das Projekt investiert.

Wir haben das erste Technical Whitepaper zum Thema Token Atomic Swap Technology (TAST) veröffentlicht, es sollten noch 9 weitere Technical Whitepapers in diesem Teilprojekt zwischen Mai 2018 und Oktober 2020 folgen. Diese Arbeiten stellen die wissenschaftliche Basis dar, auf die nun ein produktzentrierter Ansatz folgen kann.

Die Veröffentlichung des vierten TAST Technical Whitepapers darf als Ende der ersten Forschungsphase gesehen werden. Mit diesem Update geht auch der erste Prototyp einher — Pantos Technologie als Illustration der wissenschaftlichen Erkenntnisse.

Nach der Anfangsforschungsphase und daraus gewonnenen Erkenntnissen zu Anforderungen an blockchainübergreifende Transfers sowie der Veröffentlichung des DeXTT Prototypen, stellt der TAST Forschungsprototyp eine solide Weiterentwicklung dar. Erstmals können wir damit zeigen, wie eine vollwertige Token-Transferlösung in der Praxis aussehen könnte.

Nach 2,5 Jahren Forschung und Entwicklung erreichen wir einen wesentlichen Meilenstein: die Partnerschaft mit der Raiffeisen Bank International (RBI). Im Rahmen dieser Zusammenarbeit wird die Pantos-Technologie für den RBI Coin, eine Lösung für digitales Geld der RBI, angewendet. Dieser Meilenstein bedingt auch strukturelle Neuerungen, eine deutliche Trennung zwischen Forschung und Entwicklung. Bis auf weiteres werden wir keine Technical Whitepapers mehr veröffentlichen, zur Kommunikation nach außen werden wir stattdessen dem Blogpost-Format einen höheren Stellenwert zuschreiben.

Nach — im Vergleich zur Blockchain-Welt — langer formaler Vorarbeit eröffnet im November 2020 endlich ein neues Christian Doppler Labor für Blockchain-Technologien und das Internet der Dinge (CDL-BOT), geführt von Prof. Stefan Schulte. Zusammen mit unserem neuen Partner IOTA sowie der Unterstützung des österreichischen Bundesministeriums für Digitalisierung und Wirtschaftsstandort widmet sich dieses neue Forschungslabor Anwendungen aus dem Bereich Internet der Dinge (IoT) auf Distributed Ledger Technologien (DLTs) und Blockchain-Interoperabilität.

Aktueller Prototyp und Ausblick

Um unsere Zukunftsvision zu illustrieren, fassen wir erst noch einmal zusammen, worauf wir jetzt schon zurückgreifen können: Machbarkeitsstudien zum Thema dezentrale, zeitnahe Kommunikation unter Einbeziehung unabhängiger Blockchains. Unsere ersten Veröffentlichungen (besonders DeXTT) fallen nach unserer jetzigen Einschätzung in den Bereich gleichzeitiger Synchronisation über alle beteiligten Blockchains. Die Testimonium getaufte Relay-Lösung reduziert den notwendigen Informationstransfer auf eine Richtung zwischen nur zwei Blockchains. Unsere weiteren Arbeiten zum Thema Token-Transfer und Cross-Blockchain-Funktionsaufruf, verwenden das abstrahierte Konzept der Transaktionsverifizierung. Relay-Lösungen, oder zentralisierte Aufrufe (wie von Tether verwendet) sind dabei als zwei von vielen konkreten Anwendungen dieses Konzepts zu sehen.

Mögliche Belohnungen und Anreize für PAN-Besitzer?

Von der Pantos Community werden wir gerne nach einem Zeitplan, Monetisierungsplänen und eigentlich einem fertigen Produkt gefragt. Um das klarzustellen: wir hören euch, wir empfinden selbst sehr ähnlich. Bis jetzt war das Pantos-Projekt vor allem ein wissenschaftliches Forschungsprojekt. Wissenschaftliche Forschung ist per Definition unabhängig und nicht von wirtschaftlichen Interessen geleitet. Wissenschaftliche Forschung wird auch weiterhin ein wichtiger Bestandteil des Pantos-Projekts sein, aber zukünftig werden wir praktischen Aspekten mindestens ebenso viel Aufmerksamkeit widmen, wie den rein wissenschaftlichen.

Auf dem Weg zur blockchainübergreifenden Kommunikation und einhergehend dem Token-Transfer zwischen zwei Blockchains haben wir verschiedene Möglichkeiten untersucht. Einträge in Blockchains sind meist kostenpflichtig, weshalb wir dabei oft Off-Chain Clients als Dienstleister andenken, die von anderen Nutzern für ihre Dienste bezahlt werden. Ein möglicher intrinsischer Anwendungsfall für den PAN Token könnte daher PAN als Zahlungswährung sein.

Blockchainübergreifende Kommunikation, wie viele andere Ideen, kann auf zwei grundsätzlich unterschiedlichen Wegen erreicht werden: über einen allgemeinen oder über einen spezialisierten Ansatz.

  1. Allgemeine Ansätze dienen gerne als Startpunkt. Dabei wird nach einer möglichst umfangreichen und eleganten Lösung gesucht, die nebenbei auch Spezialfälle wie etwa den Token-Transfer ermöglicht. Allgemeine Lösungen sind tendenziell unabhängiger und von weniger Faktoren abhängig. Ein Problem mit allgemeinen Lösungen (siehe das frühe Ende von BTC-Relay) ist, dass der Betrieb so umfassender Lösungen oft nicht wirtschaftlich ist.
  2. Spezialisierte Ansätze starten mit weniger umfangreichen Anwendungsfällen, ermöglichen jedoch eventuell eine andere Lösung für die allgemeinere Fragestellung. Beispielsweise ist es denkbar über Infrastruktur, die vorerst nur den Token-Transfer zwischen verschiedenen Blockchains bedenkt, dann auch blockchainübergreifende Kommunikation ganz allgemein zu ermöglichen. Um die Betriebskosten des Pantos-Netzwerks zu reduzieren, könnte es letztlich sogar notwendig werden, einen spezialisierten Ansatz umzusetzen.

Möglichkeit: Einnahmen aus Transfergebühren im Austausch gegen Ressourcen zur Netzwerkpflege

Bisher haben wir uns vor allem allgemeinen Ansätzen gewidmet. Blockchainübergreifende Kommunikation als übergeordnete Frage tendiert zur Verwendung nativer Währungen (z.B. BTC, ETH) im Gegensatz zu spezialisierten Token (z.B. PAN). Als Alternative planen wir auch spezialisierte Ansätze genauer auf ihre Eignung zu untersuchen. Manche der möglichen Lösungen bauen auf Proof-of-Stake Konsensprotokollen auf. Dabei könnten sich Besitzer des Ecosystem Tokens am Betrieb des Netzwerks beteiligen und dafür an den entstehenden Transaktionsgebühren mitverdienen.

Disclaimer: Die in diesem Artikel repräsentierten Ideen stellen mögliche Lösungsansätze dar, es ist aber noch keine Entscheidung für oder gegen einen bestimmten Ansatz gefallen. Es ist unser erklärtes Ziel PAN-Investoren auf die eine oder andere Art zu honorieren, wir können jedoch weder zu Umsetzung noch zu Ausrichtung konkrete Ausformungen versprechen.

Neben strukturellen Notwendigkeiten wird es vermutlich auch weitere Pantos Anwendungsfälle geben, diese sind jedoch nicht Teil unserer aktuellen Arbeit. Beispielsweise träumen wir manchmal von der Möglichkeit, ausschließlich PAN zu verwenden, um auf irgendeiner Blockchain irgendeine Aktivität auszuführen. Mit einem dafür notwendigen Pantos-P2P-Netzwerk wäre es dann etwa möglich, eine komplexe Transaktion ebendort anzustoßen, in deren Verlauf PAN von der Ethereum-Blockchain gegen RBI Euro auf dem Billon TLD getauscht werden.

Blockchainübergreifende Kommunikation

Zur groben Einordnung einer blockchainübergreifenden Kommunikationslösung (worunter auch der Token-Transfer fällt) betrachten wir drei Faktoren: Dezentralisierung, Transaktionszeit und Wartungskosten. Wie immer streben wir nach optimalen Werten für alle drei Faktoren, erwarten aber, dass bessere Werte für einen Faktor mit schlechteren Werten für einen anderen Faktor einhergehen.

  1. Dezentralisierung ist wohl das wichtigste Schlagwort der Blockchain-Welt. Idealerweise sind Blockchain-Lösungen transparent und ohne Einschränkungen öffentlich verifizierbar. Es gibt keine zentral wichtige Rolle und jedem steht es offen, das Netzwerk zu unterstützen und dadurch an der Wertschöpfung beteiligt zu sein.
  2. Die Transaktionszeit setzt sich aus der Block-Erzeugungs-Zeit und Sicherheitsüberlegungen zusammen. Höhere Durchsätze bei gleichbleibender Blockzeit wären zwar theoretisch möglich, würden aber eine Auslagerung der Sicherheitsüberprüfung auf externe Faktoren bedingen.
  3. Bei Wartungskosten handelt es sich nicht direkt um Transferkosten, sondern um den Aufwand, die für Transferbestätigungen notwendige Infrastruktur am Laufen zu erhalten. Es darf allerdings erwartet werden, dass sich die Wartungskosten in den Transferkosten widerspiegeln. Eine höhere Transferfrequenz kann dabei für einzelne Transfers je nach Umsetzung niedrigere (etwa bei einem Relay) oder höhere (etwa bei den meisten Blockchains) Kosten verursachen.

Testimonium, unsere Relay-Lösung, ist, was Dezentralisierung betrifft, bereits optimal, da es jede beteiligte Blockchain gleich behandelt. Je nachdem wie sicher die Kommunikation sein soll, werden mehrere oder weniger bestätigte Blöcke auf Quell- und Zielblockchain benötigt, die Transferzeit hängt also von der gewünschten Sicherheit ab. Wir haben hart an der Optimierung der Wartungskosten gearbeitet. Wenn wir davon ausgehen, dass jeder Block der Quellblockchain so bald als möglich auch auf der Zielblockchain abrufbar sein soll, dann errechnet sich das untere Kostenlimit über den On-Chain Speicherbedarf des Block Headers. Dieses Minimum erreichen wir eigentlich auch bereits durch ein einstufiges Disputsystem, also eine Einspruchsmöglichkeit mit gegebenenfalls nachträglicher Überprüfung des übermittelten Block Headers auf Korrektheit.

Die gesamte Blockchain-Technologie befindet sich nach wie vor im Anfangsstadium. Es kann daher keine verlässliche Auskunft gegeben werden, welche Ausprägungen blockchainübergreifender Kommunikation zukünftig von Bedeutung sein werden. Aus unserer Sicht ist die dringendste Frage quantitativer Natur. Wie viele blockchainübergreifende Transaktionen dürfen wir erwarten? Sollte so gut wie jeder Block von so gut wie jeder Blockchain Informationen beinhalten, die auf so gut wie jeder anderen Blockchain überprüft werden wollen, dann wäre unsere Relay-Lösung auch kostenoptimiert. Wäre jedoch ein wesentlich geringeres Transferintervall zu erwarten, dann sind reine Relay-Lösungen zu kostspielig, da sie gesamte Blockchains auf anderen Blockchains widerspiegeln. Das Problem lässt sich auch als Unfähigkeit zur Pause umschreiben.

Batching, der Ansatz zur stapelweisen Verarbeitung

Finden blockchainübergreifende Transaktionen nur selten statt, dann bieten sich Batching-Ansätze an. Dazu werden erst ein paar Blöcke abgewartet, um sie dann gesammelt an die Zielblockchain weiterzuleiten. Im strengeren Sinne handelt es sich dann um kein Relay mehr, jedoch ermöglicht dieser Ansatz Pausen und verhindert unnötige Transaktionen auf der Zielblockchain. Klar ist allerdings, dass Batching zulasten der Reaktionszeit und damit der Transaktionszeit geht. Eine ordentliche Überprüfung braucht Zeit und es macht einen Unterschied, ob nur ein Block oder 100 Blöcke überprüft werden sollen. Die große Frage ist jetzt: wie stellen wir sicher, dass die 100 übermittelten Blöcke auch alle korrekt sind, ohne sie eben einen nach dem anderen an die Zielblockchain zu übermitteln?

Eine mögliche Batching-Variante sind Zero Knowledge Proofs, durch welche direkt auf der Zielblockchain gespeicherte Daten minimiert werden können, ohne dabei die unmittelbare Überprüfbarkeit zu beeinträchtigen. Ein Zero Knowledge Proof ist ein mathematisches Konstrukt, das es bei bestimmten Anwendungsfällen erlaubt, die Korrektheit einer Überprüfung zu zeigen, ohne den Überprüfungsweg im Detail darzulegen. Im Falle der Block Header-Überprüfung könnte das etwa dazu genutzt werden zu zeigen, dass es zu einem Anfangs- und einem Endblock noch 98 weitere Blöcke gibt, die den formalen Sicherheitsnotwendigkeiten gereichen. Dabei müssten die 98 Zwischenblöcke nur Off-Chain, nicht jedoch On-Chain überprüft werden. Ähnliche Techniken werden bei Blockchains verwendet, die die Privatsphäre betonen, wie etwa Monero und ZCash, um Transaktionen zu ermöglichen, die überprüfbar korrekt sind, ohne bei der Überprüfung Rückschlüsse auf Transaktionsvolumen oder Kontostände ziehen zu können. Für unseren Anwendungsfall muss sich allerdings erst zeigen, ob der beachtliche Rechenaufwand passende Zero Knowledge Proofs zu erstellen den Wartungskostenersparnissen gerecht wird, also ob die eingesparten Blockchaingebühren die zusätzlichen Stromkosten aufwiegen.

Eine andere Batching-Variante wäre eine Erweiterung unseres Einspruchsmechanismus. Bisher können eingereichte Block Header direkt mit einer simplen (wenn auch relativ teuren) Überprüfung beanstandet werden. Wie in der Arbeit um Dogethereum aufgezeigt, könnte dieser Mechanismus allerdings auch zu einer längeren Diskussion ausgedehnt werden. Also zuerst eine Behauptung, dann ein Widerspruch, dann ein Beleg für die ursprüngliche Behauptung, dann vielleicht wieder ein Widerspruch gegen einen anderen Aspekt der Behauptung oder gegen den Beleg und so weiter und so fort. Naiv umgesetzt könnte das bei einer Block Header-Überprüfung bedeuten, dass letztlich alle Block Header bis zum gemeinhin zuletzt akzeptierten Block Header nachgereicht werden müssen. Dieser Ansatz funktioniert nur mit einem ausgefeilten Pfand- und Belohnungsmechanismus. Auch müssten die eventuell auftretenden Sicherheitsprobleme sauber spieltheoretisch abgehandelt werden. Wenn man bedenkt, dass für diesen Ansatz als erste Behauptung etwa im Falle des Token-Transfers schon die Einforderung des Betrags auf der Zielblockchain genügen könnte, wird klar, dass damit die Wartungskosten bis zum Äußersten minimiert wären.

Als letzten Vertreter der Batching-Ansätze ist es uns in diesem Beitrag noch wichtig auf “stateless SPV proofs” zu verweisen, die bereits effizientere Kommunikation von Bitcoin zu Ethereum ermöglichen. Anstatt jeden Blockheader zu übermitteln, wird dabei zu einer Transaktion eine festgelegte Anzahl an vorhergehenden Block Headern mitgeschickt. Die Sicherheit dieser Methode hängt direkt mit Schwierigkeit und Eigenheiten des Bitcoin-Minings zusammen. Es muss sich also erst zeigen, ob ähnliche Lösungen für andere Quell- und Zielblockchains sinnvoll sind.

Pantos Netzwerk auf einer Trägerblockchain

In gewisser Weise stellen Relay-Lösungen die Minimierung der Wartungskosten hinten an. Man könnte weiters argumentieren, dass Batching-Ansätze den Transferzeiten weniger Priorität zusprechen. In einem dritten Schritt betrachten wir daher im Folgenden ein heikles Thema: Ansätze zur Lockerung des Dezentralisierungsfaktors.

Wir schicken voraus, dass das Ideal eines betriebsfähigen Pantos-Netzwerks verschiedene Charakteristiken aufweist. Der Einfachheit halber bezeichnen wir für diese Charakterisierung die kleinste Einheit des PAN Token als Münze.

  • Jede Münze hat zu jedem Zeitpunkt höchstens einen eindeutigen Besitzer
  • On-Chain sowie Cross-Chain Transfer von Münzen kann nur mit vorheriger Zustimmung des Besitzers erfolgen
  • Der Besitzstatus jeder Münze kann über Blockchaingrenzen hinaus genau bestimmt werden

Mit diesen Betrachtungen geht die Beobachtung einher, dass das Pantos-Netzwerk selbst als eine abstrakte Form einer Buchhaltung gesehen werden kann, sozusagen als virtuelle Blockchain. Davon ausgehend widmen wir uns nachfolgend dem Thema Zentralisierung in Abstufungen.

Wenn wir Dezentralisierung als Bedingung vollständig außer Acht lassen, dann können wir blockchainübergreifende Kommunikation über simple Smart Contracts implementieren und die Validierung über direkte Autorisierung von ermächtigten Instanzen als kryptographische Unterschrift erhalten. Das wären in unserem Fall wohl Bitpanda oder andere vertrauenswürdige Quellen. Durch Verwendung solcher Instanzen wäre es eventuell sogar möglich, die über Blockzeiten vorgegebenen Transferzeiten zu reduzieren. Zentralisierte Instanzen sind allerdings das extreme Gegenteil zur Idee der Dezentralisierung.

Über Verwendung eines Komitees von autorisierten Instanzen kann die eben beschriebene Zentralisierung etwas aufgeweicht werden. Solche Komitees könnten über Abstimmungen ernannt werden, deren Umsetzung wiederum mittels Blockchain-Technologien erfolgen könnte. Mit anderen Worten ist es durchaus denkbar, eine bereits existierende aber hausfremde Blockchain als Autoritätsverwalter zu installieren. Dementsprechend wird unsere Arbeit in den kommenden Monaten teilweise auch darin bestehen, verschiedene Blockchains hinsichtlich ihrer Eignung als Trägerblockchain für das Pantos-Netzwerk zu untersuchen. Wie etwa im Waterloo-Projekt ausgeführt, ist eine Relay-Lösung zwischen Ethereum und EOS in beiden Richtungen durchaus denkbar, gerade hinsichtlich entstehender Wartungskosten. Der Grund dafür liegt vor allem im von EOS verwendeten Delegated Proof-of-Stake Verfahren. Es bleibt zu vermerken, dass die Verwendung einer Trägerblockchain natürlich auch eine starke Abhängigkeit mit sich bringt, die der Idee der Blockchainunabhängigkeit zuwiderläuft.

Der PAN Token soll natürlich eine wichtige Rolle für das Pantos-Netzwerk spielen. Unsere Arbeit zu Relay-Lösungen legt nahe, dass dazu als Bezahlwährung Fremd-Token (z.B. PAN) nur bedingt, sondern eher blockchaineigene Währungen (z.B. BTC, ETH) geeignet sind. Andernfalls wären noch stets aktuelle Umrechnungskurse sowie zusätzliche Kosten für die Tauschvorgänge notwendig. Diese Überlegung zusammen mit der Idee der Trägerblockchain führt direkt auch zur Frage, ob eine eigene Pantos-Blockchain sinnvoll sein könnte. Eine eigene Pantos-Blockchain hätte verschiedene Vorteile: man könnte die Blockchainlogik den für andere Blockchains benötigten kryptographischen Konzepten anpassen, PAN hätte sofort einen eigenen Anwendungsfall zur Bezahlung von Gebühren als Infrastrukturwährung, und es wäre möglich, Blockzeit und Konsensalgorithmus genau passend für unseren Anwendungsfall zu gestalten. Weiters wäre es mit einer Pantos-Blockchain als Trägerblockchain für das Pantos-Netzwerk einfach, beliebige Aktionen auf beliebigen verbundenen Blockchains nur mit PAN zu bezahlen.

Schließlich müssen wir noch festhalten, dass Trägerblockchains von Dritten oder eine eigene Pantos-Blockchain zwar mögliche Lösungen sind, aber doch besser als Platzhalter zu betrachten sind. Idealerweise entsteht mit dem Pantos-Netzwerk eine virtuelle Blockchain, ein Netzwerk das verschiedene unabhängige Blockchains verwendet und deren jeweilige besondere Eigenschaften gekonnt vereint. Blockchainübergreifende Synchronisation wie bei DeXTT (das Konzept hinter unseren ersten Whitepapern) könnte genau dafür wieder ein wichtiges Werkzeug werden, als Möglichkeit der teuren jedoch seltenen Synchronisation von Berechtigungslisten.

Projektstatus und Zeitplan

Zur Zeit sind wir weiter mit Testen, Reevaluierung und Verbesserungen der Prototypen sowie notwendiger Forschung beschäftigt. Was den Plan für das Gesamtprojekt Pantos betrifft, wird aber schon deutlich, dass wir mit diesem Blogpost auch eine neue Phase einläuten: praktische Entwicklung gewinnt einen höheren Stellenwert. Die Evaluierungsarbeit der kommenden Monate wird uns darüber hinaus erlauben, die oben vorgestellten Lösungsansätze noch genauer einzuordnen und für unseren Anwendungsfall zu bewerten. Bis auf Weiteres sind keine neuen Technical Whitepaper geplant, als Ersatz denken wir eher nicht ganz so formale Blogposts an. Die im Rahmen des Pantos-Projekts zukünftig entstehende wissenschaftliche Forschung wird im regulären wissenschaftlichen Betrieb veröffentlicht. Wir beraten uns momentan noch über Möglichkeiten und Kanäle, um Pantos mehr Reichweite zu verschaffen. Die Kommunikation mit der Community und das dabei erhaltene Feedback waren für uns immer schon sehr wichtige Kommunikationskanäle, denkbar sind auch häufigere Twitter Updates und detailliertere Blogposts. Für Twitter würden sich etwa Fragen aus der Community als Basis anbieten, für Blogposts könnten wir uns vorstellen, Themen wie “Mehrstufige Konsensfindungsmechanismen” oder “Das virtuelle Pantos-Netzwerk” genauer zu erläutern. Die vollständige Veröffentlichung eines Blogposts auf Deutsch und auf Englisch ist allerdings mit ziemlicher Sicherheit eine einmalige Angelegenheit. Da sind in Zukunft eher mehrsprachige Fact Sheets zu erwarten.

Glossar

  • Batching: Wie bei der Fließbandarbeit, wo Arbeit in Arbeitsschritte unterteilt wird, ist es auch in der digitalen Welt oft effizienter Arbeitspakete (Batches) zu bündeln. Prozessoren mit mehreren Kernen können überhaupt erst so ihre Stärken entfalten. Auf der Blockchain, wo Transaktionen eventuell unabhängig vom Inhalt gleich viel kosten, kann man je nach Anwendungsfall über das Zusammenfassen von vielen Transaktionen ordentlich Gebühren sparen.
  • Off-Chain Clients: Als “On-Chain” bezeichnen wir grundsätzlich Daten, die direkt auf einer Blockchain verfügbar und vor allem überprüfbar sind. “Off-Chain” betrifft folgerichtig Daten, die (noch) nicht auf der betreffenden Blockchain sind, dabei kann es sich beispielsweise um Sidechannels (eigentlich Transaktionsvereinbarungen), tagesaktuelle Temperaturen oder Information von fremden Blockchains handeln. Für unseren Anwendungsfall sind Off-Chain Clients meist Teilnehmer am Pantos-Netzwerk, die mehrere verschiedene Blockchains bedienen und darüber hinaus zur Abstimmung untereinander eventuell auch zusätzliche Kommunikationskanäle verwenden.
  • Orakel: Das aus der Antike bekannte Orakel beantwortet beliebige Fragen mit oft kryptischen Antworten. In der Informationswissenschaft beantworten Orakel genau definierte Fragestellungen mit klaren Antworten. Für die Blockchain verwendet man den Begriff Orakel für nicht näher spezifizierte Methoden, um Off-Chain Daten abzufragen.
  • Staking: Prominenz hat der Staking-Begriff vor allem durch sogenannte Proof-of-Stake Konsensalgorithmen erlangt. Ähnlich einer Unternehmens-Beteiligung über Aktien können dabei Investoren die Sicherheit einer Blockchain unterstützen. Normalerweise bedeutet das, dass ein Investor, je nach zur Verfügung gestelltem Anteil, Blöcke hauptverantwortlich unterschreibt und die Gebühren zu diesen Blöcken im Gegenzug überschrieben bekommt. Der zur Verfügung gestellte Anteil wird dabei gerne auch als Pfand verwendet, damit der Investor keinen Schabernack treibt und muss daher für entsprechende Zeiträume gesperrt werden.
  • Virtuelle Blockchain: Eine Blockchain ist im einfachsten Sinn eine verifizierte und geordnete Abfolge von Informationseinheiten. Dazu gibt es meist ein der Blockchain zugehöriges P2P-Netzwerk, um Informationen zur Abspeicherung vorzuschlagen sowie einen Konsensalgorithmus, der es den Teilnehmern der Blockchain erlaubt, die Verifizierung sowie die Abfolge der Informationseinheiten dem Protokoll gemäß sicher zu erstellen. Eine virtuelle Blockchain darf dann im Wesentlichen als das gleiche gesehen werden, verwendet jedoch weniger eigene Infrastruktur und mehr die von anderen Blockchains zur Verfügung gestellte Funktionalität. Sinngemäß kann man daher etwa Cryptokitties als virtuelle Blockchain bezeichnen, in diesem Fall eine echte Teilmenge der Ethereum-Blockchain. Auch die Menge der Tether-Transaktionen ist eine virtuelle Blockchain und als solche auf die Bitcoin-, Ethereum-, EOS-, TRON-, Algorand-, OMG- und Solana-Blockchains sowie interne Unternehmens-Informationen von “Tether Limited” aufgeteilt.

--

--

Pantos
Pantos
Editor for

The first multi-blockchain token system. Made with ♥ and care in Vienna by @bitpanda.