IOTA Tokenization Framework Spezifikationen

TL;DR:
Heute veröffentlichen wir Spezifikationen für das neue Tokenization Framework für das IOTA Mainnet. Dieses zukünftige Upgrade wird das Mainnet-Protokoll zu einem Multi-Asset-Ledger mit Smart Contracts und nahtlosen Cross-Chain-Asset-Transfers transformieren. Native Token und NFTs leben innerhalb des Tangles und erben die Gebührenfreiheit und Skalierbarkeit der Basiswährung, des IOTA Coins. Ein vertrauensloser Brückenmechanismus des Native Tokenization Frameworks stellt sicher, dass Smart Contract Token mühelos in native Token eingewickelt und aus ihnen ausgewickelt werden können. Die Protokollspezifikationen werden derzeit öffentlich geprüft, und die Arbeit an der Testnet-Implementierung hat bereits begonnen.

Tokenisierung ist eine der größten Innovationen im DLT-Bereich und ermöglicht völlig neue Anwendungsfälle und Geschäftsmodelle. IOTA hat die Tokenisierungslandschaft mit dem Native Tokenization Framework erkundet, das im Juni 2021 für das IOTA 2.0 DevNet veröffentlicht wurde.

In früheren Blogbeiträgen haben wir die neuartigen Anwendungsfälle und Möglichkeiten erläutert, die die Tokenisierung mit sich bringt, und gezeigt, wie leistungsfähig die Testnet-Implementierung des Frameworks ist. Benutzer können ihre eigenen Token und Vermögenswerte direkt auf dem Tangle prägen, die dann wie IOTA-Münzen gefühlt übertragbar sind.

Durch das Experimentieren mit digitalen Vermögenswerten im Entwicklungsnetzwerk haben wir eine Menge über die Grenzen unserer Konzepte gelernt. Wir sind einen Schritt zurück getreten und haben uns eine Welt vorgestellt, in der digitale Vermögenswerte ein wichtiger Baustein des gesamten IOTA-Technologie-Stacks sind. In diesem Token-Wunderland fließen die Vermögenswerte nahtlos und vertrauensvoll zwischen Smart-Contract-Ketten und Benutzerkonten. Sie können ohne zentralisierte Brückenlösungen verpackt oder entpackt werden. Es steht jedem frei, seine eigenen Token zu erstellen und zu verwalten. Schließlich geht es bei IOTA um Freiheit.

Wir sind stolz darauf, heute die Mainnet-Spezifikationen des IOTA Tokenization Frameworks zu präsentieren und laden die Community ein, diesen spannenden Bereich mit uns zu erforschen, während wir uns auf den Weg machen, das bisher größte Utility-Upgrade für das IOTA Mainnet durchzuführen.

Umwandlung von IOTA in ein Multi-Asset-Ledger

Die meisten DLTs fallen in die Kategorie der Single-Asset-Ledger, da sie nur in der Lage sind, das Eigentum an einer bestimmten Basiswährung innerhalb ihres Ledgers zu verfolgen. Multi-Asset-Ledger hingegen sind in der Lage, mehrere native Token in demselben Ledger zu verwalten, das auch die Basiswährung verwaltet. Da der Basis-Ledger von IOTA gebührenfreie Transaktionen ermöglicht, ist ein Multi-Asset-Ledger von IOTA in der Lage, gebührenfreie Transfers beliebiger nativer Token auszuführen, was eine einzigartige Neuerung in diesem Bereich darstellt.

Wir haben das Unspent Transaction Output (UTXO)-Modell des IOTA-Ledgers umgestaltet und erweitert, um ihn in einen vollwertigen Multi-Asset-Ledger zu verwandeln. Jedes Konto im Ledger ist in der Lage, native Token, die von Token Foundries geprägt wurden, zu halten und zu übertragen. Es ist nicht mehr notwendig, IOTA-Münzen zu „markieren“ oder zu „färben“: alle nativen Token sind eigenständige Token im Ledger, die von Foundries geprägt werden.

Multi Asset IOTA

Native Token werden von den Nutzern in das IOTA-Ledger eingespeist; daher werden sie auch als benutzerdefinierte Token bezeichnet. Sie verbrauchen wertvolle Ressourcen der Knoten, die das Netzwerk unterhalten, vor allem Speicherplatz. Infolgedessen muss jedes Konto, das native Token hält, eine Kaution in IOTA-Münzen hinterlegen, um den übermäßigen Ressourcenverbrauch auszugleichen.

Token-Foundries

Der Ersteller des benutzerdefinierten Tokens, der als Emittent bezeichnet wird, hat die Kontrolle über die Token-Foundry und regelt die Prägung oder das Brennen von Token, die zur Foundry gehören.

Jeder kann Emittent werden und mit der Prägung seiner eigenen Token beginnen. Token-Foundries überlassen es den Emittenten, eine für ihre Anwendungsfälle geeignete Angebotskontrollpolitik zu wählen. So kann ein nativer Token in IOTA je nach dem Token-Schema der Foundry einen dynamischen, festen oder begrenzten Gesamtvorrat haben. Fortschrittlichere Schemata wie Minting oder Burning Flow Control werden mit fortschreitender Implementierung iterativ in das Framework integriert.

IOTA Token Foundry 1 Layer

Die Entität des Emittenten kann eine einzelne Adresse, eine Multisignatur-Adresse, eine Schwellenwert-Multisignatur-Adresse mit beliebigen Teilnehmern und Schwellenwerten oder eine Smart-Contract-Kettenadresse sein. Es ist auch möglich, die Rechte des Emittenten auf andere Entitäten zu übertragen, aber es ist verboten, die bei der Einrichtung der „Gießerei“ definierte Angebotskontrollpolitik zu ändern, was eine unglaubliche Vielfalt von Anwendungsfällen ermöglicht, die weit über eine bloße Färbung von Token hinausgeht, die Anfang dieses Jahres eingeführt wurde.

Die Transparenz des Tokenization Framework ist für IOTA von größter Bedeutung. Foundries produzieren Token mit einer spezifischen Token-ID, die den global eindeutigen Identifikator der kontrollierenden Foundry und einige vordefinierte Token-Metadaten, wie zum Beispiel einen Namen, enthält. Basierend auf der Token-ID eines nativen Tokens ist es möglich, Informationen darüber abzuleiten:

  • Vom Emittenten definierte Token-Tags, wie Name oder Ticker
  • Kontoinformationen des Emittenten
  • Das Token-Schema, d.h. die Politik der Angebotskontrolle
  • Umlauf und maximaler Tokenvorrat
  • Auf der Chain gespeicherte Token-Metadaten

Es besteht keine Notwendigkeit für Token-Register außerhalb der on-chain; alles über einen Token kann auf der on-chain dokumentiert und gespeichert werden, direkt im UTXO-Ledger von dem Tangle. Emittenten können sich dafür entscheiden, ihr On-Chain-Konto öffentlich bekannt zu geben, um die Transparenz ihrer Token zu erhöhen. Anhand einer Liste validierter Emittentenidentitäten, die mit realen Identitäten verknüpft sind, können Wallets automatisch die Authentizität aller nativen Token feststellen.

Non-fungible Wertmarken

Token-Foundries eignen sich hervorragend für fungible Token, können aber auch nicht-fungible Token (NFTs) produzieren. Eine Token-Foundry, die das maximale Angebot auf 1 festlegt, kontrolliert im Wesentlichen nur einen Token, der im Ledger weltweit einzigartig ist; es handelt sich also um einen NFT.

Die meisten NFTs repräsentieren das Eigentum an etwas Einzigartigem, wie einem digitalen Kunstwerk oder einem Sammlerstück. Daher müssen sie einen weltweit eindeutigen Bezeichner und eine Beschreibung des zugrunde liegenden Vermögenswerts haben. Letztere wird häufig als Metadaten kodiert, die der NFT beigefügt sind. Das Eigentum an dem Token bedeutet auch das Eigentum an den Metadaten.

Eine von der „Gießerei“ kontrollierte native NFT kann auf beliebige Konten im Hauptbuch übertragen werden, die On-Chain-Metadaten verbleiben jedoch bei der „Gießerei“. Außerdem behält der Emittent die Kontrolle über das Brennen der nativen NFT, nicht der eigentliche Eigentümer. Um die Risiken zu verringern, die damit verbunden sind, dass ein Emittent anstelle des aktuellen Eigentümers die Kontrolle hat, haben wir im Tokenization Framework eine erweiterte Unterstützung für NFTs mit einem eigenen NFT-Ausgabetyp hinzugefügt.

Mit ihrem eigenen Ausgabetyp werden NFTs zu Bürgern erster Klasse im IOTA-Ledger. Jeder kann eine NFT erstellen, die Folgendes hat:

  • Eine weltweit eindeutige Kennung, die bei der Prägung zugewiesen wird. Diese Kennung fungiert auch als reguläre Iota-Adresse, sodass Ihre NFTs Fonds, native Token oder andere NFTs besitzen können.
  • Unveränderlich angebrachte Metadaten, die den dem Token zugrunde liegenden Vermögenswert beschreiben. Sie werden bei der Prägung festgelegt und dürfen während der gesamten Lebensdauer der NFT nicht geändert werden.
  • Geprüfte Emittentenadresse, die sich nie ändern darf. Das Protokoll stellt sicher, dass eine NFT mit einem verifizierten Emittenten nur in einer Transaktion erstellt werden kann, die vom Emittenten kryptografisch signiert ist.

Transaktionen mit NFTs sind gebührenfrei, wie jede andere IOTA-Transaktion, und der aktuelle Besitzer hat die volle Kontrolle darüber, ob er den Token mit den angehängten Metadaten überträgt oder brennt. Die NFT-Ausgabe wurde mit Blick auf die Interoperabilität von Smart Contracts entwickelt, daher ist es möglich, sie als Teil einer Smart-Contract-Anfrage zu senden, um sie zum Beispiel als Sicherheit in einer Smart-Contract-Kette zu hinterlegen oder sie zur Versteigerung anzubieten.

Tokenisierung von Smart Contracts

IOTA Smart Contracts sind eine Layer-2-Erweiterung des Basis-Ledgers, die die leistungsstarke Welt der Smart Contracts und der Programmierbarkeit des Ledgers für IOTA Realität werden lässt. Smart Contracts werden in Smart Contract Chains ausgeführt, die von Layer 2 Validatoren betrieben werden. Da Smart Contracts quasi eine vollständige Turing-Programmierbarkeit bieten, erwecken sie eine Fülle von komplexen Tokenisierungsschemata zum Leben.

In der Tat werden die meisten Token auf dem heutigen Markt über Smart Contracts erstellt. Jeder von ihnen führt ein lokales Ledger innerhalb des Smart Contracts, das aufzeichnet, wer was besitzt. Dies bietet umfangreiche Funktionen und Kompositionsmöglichkeiten. Allerdings gibt es auch einen Nachteil für große Blockchains: geringe Leistung und kostspielige Smart-Contract-Ausführung.

Aus diesem Grund hat IOTA seine Smart-Contract-Plattform so konzipiert, dass sie über parallele Ketten horizontal skaliert werden kann. Diese Strategie stellt jedoch eine große Herausforderung dar: Wie kommunizieren Smart-Contract-Ketten miteinander und übertragen Werte untereinander? Die Antwort liegt auf der Hand: Sie verlassen sich auf das Tangle und das Native Tokenization Framework, um diese Aufgabe zu erledigen.

IOTA Smart Contract Chain

Asset Wrapping

Es ist nicht nur möglich, native Assets in Smart-Contract-Ketten zu hinterlegen, sondern die Ketten selbst können auch als Emittenten von nativen Assets fungieren. Jeder Smart Contract kann daher native Token ausgeben, die transparent zu dem spezifischen Smart Contract auf der spezifischen Kette zurückverfolgt werden können. Dieser Mechanismus bildet die Grundlage für vertrauenswürdige, garantierte Vermögensbrücken über mehrere Ketten hinweg.

IOTA Smart Chain Token

Ein Smart Contract, der Layer-2-Token (z. B. ERC-20-Token) innerhalb einer Kette handhabt, kann mit Core Contracts interagieren, um Layer-2-Token in native Layer-1-Assets zu verpacken oder native Token, die zum Smart Contract gehören, in ihre Layer-2-Darstellung zu entpacken. Die Logik für die Umwandlung von Vermögenswerten wird von der virtuellen Maschine (VM) der Kette bereitgestellt; die Smart Contracts müssen lediglich den entsprechenden Kernvertrag in der Kette aufrufen, um den Vorgang durchzuführen.

IOTA Asset wrapping

Eine wichtige Eigenschaft dieses mehrschichtigen Tokenisierungsansatzes ist die Flexibilität:

  • Smart-Contract-Token der Schicht 2 sind vollständig programmierbar und anpassbar, aber sie sind mit möglichen Gebühren für die Ausführung von Smart Contracts verbunden.
  • Native Token der Schicht 1 nutzen die Leistung und Sicherheit des IOTA-Ledgers; außerdem fallen für sie keine Übertragungsgebühren an.
  • Smart Contract Token können nahtlos in native Token umgewandelt werden und umgekehrt. IOTA Smart Contracts bieten integrierte Unterstützung für Entwickler.

Die beiden Token-Klassen lassen sich am besten durch die Metapher von Banken und Bargeld verstehen. Smart-Contract-Ketten sind Banken, die denjenigen, die ein Konto auf der on-chain haben, eine breite Palette von finanziellen Vermögenswerten, IOUs, Produkten und Dienstleistungen (Smart-Contract-Token) anbieten. Die Bank kann sich dafür entscheiden, Bargeld (native Token) zu drucken, das die oben genannten Vermögenswerte repräsentiert, die dann unabhängig von der Kontrolle der Banken in der Wirtschaft zirkulieren können (Schicht 1, Tangle).

Smart-Contract-Anfragen

Die Interaktion mit Smart-Contract-Ketten von regulären Layer-1-IOTA-Konten aus erfolgt über On-Ledger-Anfragen, die an das Layer-1-Konto der Kette gesendet werden. Solche Anfragen können native Token oder NFTs enthalten, die Teil der Anfrage sind. Ein Nutzer könnte sich dafür entscheiden, einige native Vermögenswerte in einer Kette zu hinterlegen und der Kette zu befehlen, sie zu entpacken, um ihr volles Potenzial freizusetzen.

Einige mögliche Anwendungsfälle für native Token in intelligenten Verträgen:

  • Der Eigentümer der Kette beschließt, Gebühren für die Ausführung von Smart Contracts mit einem bestimmten nativen Token zu akzeptieren.
  • Ein bestimmter Smart Contract kann nur ausgeführt werden, wenn die Gebühren mit einem bestimmten nativen Token bezahlt werden.
  • Ein intelligenter Vertrag erfordert die Hinterlegung eines bestimmten nativen Tokens, um Funktionen für den Nutzer freizuschalten.
  • Die Privilegien von Smart Contracts sind an das Vorhandensein eines bestimmten nativen Tokens gebunden. Kontrollrechte sind übertragbar, anstatt sie fest im Smart Contract zu kodieren.
  • Eine Spiele-DApp akzeptiert spielinterne Gegenstände als NFTs von einem verifizierten Emittenten.

Die obige Liste ist bei weitem nicht vollständig; sie bietet vielmehr einen kleinen Einblick in die Möglichkeiten, die mit IOTA-Smart Contracts und dem nativen Tokenization Framework möglich sind.

Was kommt als Nächstes?

Mit der Veröffentlichung der Mainnet (Chrysalis)-Protokollspezifikationen für Smart Contracts und Tokenisierung beginnt für IOTA eine spannende Zeit. Die Spezifikationen werden uns dabei helfen, die neuen Protokollfunktionen zu implementieren und sie in die bestehenden Frameworks, Client-Bibliotheken und Entwickler-Tools zu integrieren.

Unser erster Meilenstein ist ein Hornet-basiertes Testnetz, in dem das Tokenization Framework aktiviert ist. Während wir auf dem Weg dorthin sind, hat die Arbeit an der Integration von IOTA Smart Contracts mit dem neuen Protokoll bereits begonnen.

Wir laden die Community und unsere Partner ein, die vorgeschlagenen Protokolländerungen durchzulesen und uns bei der Optimierung des Designs zu helfen, indem sie uns ihr Feedback und ihre Kommentare mitteilen. Beteiligen Sie sich an der Konversation auf GitHub oder sprechen Sie direkt mit unserem Team im Channel #digital-assets auf Discord.

Original by Levante Pap: https://blog.iota.org/iota-tokenization-framework-specifications/

Die IOTA Foundation nimmt an der UZH Blockchain Center Summer School teil

TL;DR:

Im Rahmen der jüngsten Zusammenarbeit zwischen der IOTA Foundation und der akademischen Gemeinschaft hielten zwei IOTA-Experten Vorträge vor Studenten an der Blockchain Center Summer School der Universität Zürich, wo zwei Studenten auch Stipendien der Stiftung erhielten.

Am 12. Juli nahm die IOTA Foundation an der Blockchain Center Summer School der Universität Zürich teil. Die UZH Summer School ist eine führende akademische Veranstaltung, die Studenten aus verschiedenen Bereichen in die Welt der Distributed Ledger Technology (DLT) einführt. Die Schule ist multidisziplinär und deckt Bereiche wie DLT-Theorie, Ingenieurwesen, Recht und verschiedene Sozialwissenschaften ab. UZH-Professor und akademischer Leiter des UZH Blockchain Centers, Claudio J. Tessone, fungierte als Kursleiter. Die Summer School war eine wunderbare Gelegenheit für die Forscher der IOTA-Stiftung, ihre akademische Zusammenarbeit mit Professor Tessone zu vertiefen.

Die IOTA-Stiftung sponserte zwei Studenten an der Sommerschule mit einem Gesamtbetrag von 3.000 CHF. Zusätzlich hielten zwei Mitglieder des IF-Teams, Luigi Vigneri (Senior Research Scientist) und Michele Nati (Head of Telco and Infrastructure Development), Vorträge an der Sommerschule. Luigi Vigneri gab einen Überblick über das IOTA 2.0-Protokoll, wobei er sowohl die wichtigsten Anwendungsfälle und Vorteile der Technologie als auch die wichtigsten Komponenten erläuterte. Michele sprach über die Governance der IOTA Foundation, IOTA Identity, IOTA Streams, Tokenized Assets und Smart Contracts, sowie über die Anwendung von IOTA in verschiedenen Domänen. Die Studenten waren auch eingeladen, die dezentralen digitalen Identitätswerkzeuge zu testen, die die IOTA Foundation im Rahmen des ENSURESEC-Projekts entwickelt. Interessierte Leser sind eingeladen, sich die Präsentationsfolien anzusehen.

Luigi und Michele nahmen auch an einem Projekt teil, bei dem Studenten das IOTA 2.0 DevNet nutzten, um eine verteilte App (dApp) für „farbige“ Münzen zu entwickeln. Sowohl Luigi als auch Michele waren sehr ermutigt, diese Art von studentischem Engagement mit dem IOTA-Protokoll zu sehen.

Die UZH Summer School war eine lohnende Erfahrung für die Vertreter der IOTA Foundation, und es ist zu hoffen, dass die Erfahrung das Interesse der teilnehmenden Studenten an IOTA weiter anspornt. Dies war das zweite Jahr in Folge, in dem die IOTA-Stiftung aktiv an der Summer School teilgenommen hat, und wir freuen uns darauf, die Beziehungen zu dieser wachsenden akademischen Gemeinschaft zu vertiefen.

Original by William Sanders: https://blog.iota.org/the-iota-foundation-participates-in-uzh-blockchain-center-summer-school/

 

IOTA Smart Contracts Protokoll Alpha Release

Die Veröffentlichung des IOTA Smart Contracts Protocol (ISCP) Alpha markiert einen wichtigen Meilenstein in der Entwicklung des ISCP. Das Ausmaß und die Art der Verbesserungen gegenüber der vorherigen „Pre-Alpha“-Version sind signifikant und wir fühlen uns nun mit dem aktuellen Stand sicher, die „Alpha-Version“ zu veröffentlichen.

Die grundlegende und bemerkenswerteste Änderung des ISCP seit der „Pre-Alpha“-Version ist die Integration einer Multi-Chain-Umgebung, die durch den Tangle, den „Layer 1“, gesichert wird: Subnetze, bestehend aus Wasp-Knoten, die wir „Komitees“ nennen, können viele Blockchains parallel darauf laufen lassen, ohne den Blick auf die Umgebung zu verlieren, die die digitalen Vermögenswerte von IOTA sichert, den Tangle. Jede solche Kette, die ein funktionales Äquivalent einer Ethereum-Blockchain ist, ist in der Lage, viele Smart Contracts zu hosten. „IOTA Smart Contracts Protokoll Alpha Release“ weiterlesen

Tokenisierung auf dem Tangle mit IOTA Digital Assets

Das IOTA-Team hat in den letzten Wochen erhebliche Fortschritte gemacht, um Chrysalis im März auf das Mainnet zu bringen. Das größte Netzwerk-Upgrade in unserer Geschichte ist nicht nur ein Marsch in Richtung Produktionsreife, sondern auch ein Wegbereiter für aufregende neue Anwendungsfälle, Partner und Produkte, die vorher nicht möglich waren. Mit dem Chrysalis-Upgrade kommen eine Reihe von ineinandergreifenden Projekten, die das gesamte IOTA-Ökosystem umspannen, alle mit dem Ziel, die Möglichkeiten, in denen IOTA eingesetzt werden kann, weiter zu erhöhen.

Die Realisierung der Machine Economy erfordert gebührenfreie Micropayments, unveränderliche und überprüfbare Daten, dezentrale und selbstsouveräne Identitäten, Smart Contracts für die vollständige Autonomie von Prozessen und die Tokenisierung von physischen und digitalen Assets. IOTA baut all diese Komponenten im Moment auf.

Einführung in das IOTA Digital Assets Framework

„Tokenisierung auf dem Tangle mit IOTA Digital Assets“ weiterlesen

Eröffnung von Christian Doppler Labor für DLT Forschung durch IOTA, PANTOS und TU Wien

Wir sind stolz darauf, bekannt zu geben, dass die IOTA Stiftung dem neuen Christian Doppler Laboratory Blockchain Technologies for the Internet of Things (CDL-BOT) als Industriepartner beitritt. Eine am Institut für Information Systems Engineering der TU Wien angesiedelte Forschungsgruppe wird Spitzenforschung zur DLT Interoperabilität, zur Schnittstelle von DLT mit dem Internet der Dinge und zu Unterstützungsangeboten für Entwickler betreiben. Heute, am 26. November 2020, eröffnete die Bundesministerin für digitale und wirtschaftliche Angelegenheiten in Österreich, Dr. Margarethe Schramböck, das Labor offiziell in einer digitalen Zeremonie, an der auch unser Mitbegründer und Mitvorsitzender des IOTA Vorstands, Dominik Schiener, teilnahm. Gemeinsame Forschung in einem Netzwerk aus führenden Universitäten, öffentlichen Forschungseinrichtungen und Partnerschaften des privaten Sektors sind der Schlüssel zur Mission der IOTA-Stiftung bei der Entwicklung von Open-Source-Technologien und -Infrastrukturen für ein vertrauenswürdiges Internet der Dinge.

Das CDL-BOT ist ein langfristiges Forschungsprojekt mit einer voraussichtlichen Laufzeit von sieben Jahren, das mehrere Postdoktoranden und Doktoranden unter der Leitung von Prof. Stefan Schulte beschäftigt. Für die IOTA Stiftung ist der Aufbau dieses Projekts in einzigartiger Weise darauf ausgerichtet, nicht nur die Forschung über den IOTA Tangle und seine Anwendungen im Internet der Dinge selbst zu erweitern, sondern auch über das IOTA Protokoll hinauszuschauen, um das europäische DLT-Ökosystem zu fördern. Dies erfordert neuartige Mechanismen, um die DLT Interoperabilität zu ermöglichen, die von Blockchain übergreifenden Token Transfers oder atomaren Swaps bis hin zu Blockchain übergreifenden intelligenten Vertragsaufrufen (Smart Contracts) und Interaktionen reichen, sowie die Bereitstellung von clientseitiger Blockchain Interoperabilität durch Entwicklerunterstützung.

Prof. Stefan Schulte, der das neu eingerichtete Labor leitet, bemerkte dazu: „Mit der steigenden Zahl potenzieller Anwendungsbereiche für DLT basierte Zahlungen und Datenaustausch im Internet der Dinge müssen neue DLTs integriert werden und die Interoperabilität zwischen verschiedenen DLTs wird notwendig sein. Ich freue mich darauf, gemeinsam mit der IOTA Stiftung und Pantos zu forschen, um neuartige Lösungen für dieses hochaktuelle Thema zu finden“.

Das Christian-Doppler-Labor wird von der staatlich geförderten Christian Doppler Gesellschaft finanziert, einem österreichischen Pionier bei der Erleichterung einer erfolgreichen Zusammenarbeit zwischen Wissenschaft und Privatwirtschaft. Die Zusammenarbeit wird zur Entwicklung von Produkten und Verfahren bei der IOTA Stiftung und Pantos, einer Tochtergesellschaft von Bitpanda, beitragen. Mit einer Erfolgsgeschichte von 25 Jahren haben CD Laboratories ihre Effizienz bei der Förderung neuartiger Kooperationen bewiesen, die Wissenschaft, Gesellschaft und Privatwirtschaft gleichzeitig zugute kommen.

Eric Demuth, Mitbegründer und CEO von Bitpanda: „Um die Branche auf die nächste Stufe zu bringen, sollten die Interoperabilität von Blockchains sowie die Integrität von Daten höchste Priorität haben. Wir glauben, dass unsere Partnerschaft mit der Christian Doppler Gesellschaft, dem österreichischen Bundesministerium für digitale und wirtschaftliche Angelegenheiten sowie der IOTA Foundation es uns ermöglicht, an der Spitze der Interoperabilitätsentwicklung zu bleiben, um eine der größten Komplexitäten in dieser jungen, aber stetig reifenden Industrie zu lösen“.

Für die IOTA-Stiftung ist das Christian-Doppler-Labor ein weiterer Schritt, die akademische Forschung über den Tangle zu stärken und dies in Partnerschaft mit führenden europäischen Initiativen des Privatsektors zu tun, um die Relevanz solcher Aktivitäten branchenübergreifend sicherzustellen. Im Zuge der Weiterentwicklung der DLT-Branche ist die Förderung der Interoperabilität digitaler Assets und die Möglichkeit, sie über Organisationen und Prozesse hinweg miteinander zu verbinden, eine entscheidende Herausforderung, die durch die Zusammenführung der Expertise von Pantos und IOTA mit führenden Stimmen aus der akademischen Welt auf einzigartige Weise angegangen werden kann.

Dominik Schiener, Mitbegründer und Mitvorsitzender des Vorstands der IOTA Stiftung, kommentierte die Initiative: „Wir sind stolz darauf, bekannt zu geben, dass die IOTA Stiftung dem neuen Christian Doppler Laboratory Blockchain Technologies for the Internet of Things (CDL-BOT) als Industriepartner beitritt. Eine am Institut für Information Systems Engineering der TU Wien angesiedelte Forschungsgruppe wird Spitzenforschung zur DLT-Interoperabilität, zur Schnittstelle von DLT mit dem Internet der Dinge und zu Unterstützungsangeboten für Entwickler betreiben.

Über die TU Wien: Die TU Wien wurde 1815 als k.u.k. Polytechnisches Institut gegründet. Sie war die erste Technische Universität im heutigen deutschsprachigen Europa. Heute findet die Universität sowohl in der Lehre als auch in der Forschung hohe internationale und nationale Anerkennung und ist ein hochgeschätzter Partner innovationsorientierter Unternehmen. Das CDL-BOT ist an der Fakultät für Informatik der TU Wien angesiedelt, die zu den führenden Fakultäten für Informatik und Informationssysteme in Europa zählt. Neben anderen Forschungsthemen beherbergt die Fakultät für Informatik auch eine Reihe von führenden Forschern auf dem Gebiet der DLTs und Blockchains – sowohl in der Grundlagenforschung als auch in der angewandten Forschung. Ergebnisse dieser Forschung wurden vor kurzem auf der 3. Internationalen IEEE-Konferenz über Blockchains mit dem Best Paper Award ausgezeichnet.

Über Pantos: Pantos ist ein wissenschaftliches Forschungsprojekt, das darauf abzielt, eine der wichtigsten technischen Barrieren im Krypto- und Digital Asset Space zu lösen: die Interoperabilität zwischen Blockchain. Ziel des Pantos Projekts ist es, eine vereinheitlichende Lösung für die fragmentierte Blockchain und den Krypto-Währungsraum anzubieten.

Über Bitpanda: Bitpanda ist ein führender europäischer Neobroker auf der Mission, die komplexe Welt der Investitionen zu demokratisieren. Das Unternehmen wurde 2014 von Eric Demuth, Paul Klanschek und Christian Trummer gegründet. Bitpanda glaubt fest an Transparenz und daran, es für jeden so einfach wie möglich zu machen, mit dem Investieren zu beginnen. Bitpanda beseitigt komplizierte finanzielle Barrieren, indem es sich die Innovationskraft digitalisierter Anlagen und die Blockchain-Technologie zunutze macht. Mit niedrigen Gebühren, 24-Stunden-Handel rund um die Uhr und Echtzeit-Abwicklung ermöglicht Bitpanda es den Nutzern, ihre Finanztermingeschäfte selbst zu gestalten – zu ihren eigenen Bedingungen.

Über die IOTA Stiftung: IOTA ist eine globale gemeinnützige Stiftung, die die Forschung und Entwicklung neuer verteilter Ledger-Technologien (DLT), einschließlich des IOTA Tangle, unterstützt. Das IOTA Tangle löst die grundlegenden Unzulänglichkeiten der Blockchain: Skalierbarkeit, ökologische Nachhaltigkeit und Kosten. IOTA ist ein Open-Source-Protokoll, das die menschliche Wirtschaft mit der maschinellen Wirtschaft verbindet, indem es neuartige Machine-to-Machine-Interaktionen (M2M) ermöglicht, einschließlich sicherer Datenübertragung und gefühlloser Mikrozahlungen.

Um mehr zu erfahren, besuchen Sie www.iota.org, den YouTube-Kanal der IOTA-Stiftung und folgen Sie uns auf Twitter.

Original Florian Doebler: https://blog.iota.org/iota-pantos-and-tu-wien-announce-opening-of-christian-doppler-laboratory-for-dlt-research-3eb4389148bc

IOTA Smart Contracts Pre-Alpha veröffentlicht

Eine Plattform für skalierbare, Gebührenfreie und flexible intelligente Verträge

In diesem Artikel stellen wir unsere hochmoderne Implementierung des IOTA Smart Contract Protocol (ISCP) vor, die erste skalierbare, Gebührenfreie und flexible Implementierung intelligenter Verträge im IOTA-Netz. In dieser Veröffentlichung stellen wir drei intelligente PoC-Verträge vor, die von der IOTA-Stiftung entwickelt wurden, um die frühen Fähigkeiten der Plattform zu demonstrieren. Darüber hinaus stellen wir Entwicklern eine Reihe von Tools zur Verfügung, mit denen sie die Funktionalität unserer intelligenten Verträge erkunden können.

Wir führen IOTA Smart Contracts als eine technologische Entwicklung ein, so dass wir uns auf die zugrunde liegenden technischen Konzepte, die Architektur und die Eigenschaften konzentrieren werden.

Wir werden die Diskussion in künftigen Beiträgen erweitern, um spezifische Anwendungsfälle und das Marktpotenzial intelligenter Verträge und digitaler Vermögenswerte vorzustellen. Wir werden in den folgenden Monaten weiter an der erweiterten Funktionalität und der Stabilität der Software arbeiten, um sie für die Produktion und die Bedürfnisse des Marktes voll ausgereift zu machen. Für eine Einführung in IOTA Smart-Verträge lesen Sie unseren Blog-Post Einführung in IOTA Smart-Contracts.

Pre-Alpha heute verfügbar!

Ab heute steht das IOTA Smart Contracts Pre-Alpha zum Ausprobieren zur Verfügung! Anhand einer frühen Reihe von Bausteinen können Entwickler mit der Erkundung der Möglichkeiten des IOTA Smart Contracts Protocol beginnen, während wir die Funktionalität für eine vollständige Veröffentlichung in den kommenden Monaten weiter ausbauen.

Für diejenigen unter Ihnen, die gerade erst zu uns gestoßen sind: IOTA Smart Contracts ist eine flexible und Gebührenfreie Implementierung intelligenter Vertragsfunktionalität auf einem verteilten, DAG-basierten UTXO-Ledger. Dies geschieht durch die Einrichtung von Ausschüssen, die intelligente Verträge überprüfen und ihre Konsistenz und Unveränderlichkeit auf dem verteilten IOTA-Ledger garantieren.

Aufgrund ihrer Gebührenfreien und flexiblen Designs werden unsere intelligenten Verträge ideal für Unternehmensanwendungen und reale Anwendungsfälle von Organisationen auf der ganzen Welt geeignet sein – ein großer Fortschritt für unsere Branche. Wir glauben auch, dass das IOTA-Protokoll für intelligente Verträge die Grundlage für ein reichhaltiges Ökosystem legt, das sich entwickeln wird, mit einer großen Vielfalt an Erweiterungen und Bausteinen, von denen wir erwarten, dass sie von der Gemeinschaft geschaffen werden.

In diesem Release enthaltene Funktionen

Mehrere Komponenten sind in unserem ersten großen Release enthalten:

  • Wasp-Node-Software Version 0.0.1 (das frühe Alpha-Release) finden Sie hier das Repository. Der Wasp-Knoten führt ISCP im Netzwerk der Wasp-Knoten aus, einer Schicht über dem Netzwerk der Goshimmer-Knoten. Wir stellen auch das Goshimmer-Node-Plugin WaspConn zur Verfügung, das es einem Wasp-Knoten erlaubt, sich mit dem experimentellen Pollen-Netzwerk der Goshimmer-Knoten zu verbinden und auf diesem zu laufen (siehe Wasp-Zweig des Goshimmer-Repositoriums).
  • Drei Demo dApps, intelligente PoC-Verträge namens TokenRegistry, FairAuction und DonateWithFeedback. Diese einfachen dApps enthalten intelligente Vertragsprogramme, die als Go-Module im Wasp-Knoten selbst fest codiert sind. Jeder PoC umfasst bereitgestellte Demo-Instanzen von intelligenten Verträgen im Pollen-Netzwerk, ihre Web-Dashboards und Brieftaschen.
  • CLI-Brieftasche wwallet. Wie eine gewöhnliche IOTA-Brieftasche ermöglicht Ihnen die wwallet (die Wasp-Brieftasche) das Senden und Empfangen von Tokens im Pollen-Netzwerk. Darüber hinaus können Benutzer mit der Wallet auch Funktionen der PoC-Smart-Verträge anfordern. Mit wwallet können Sie z.B. digitale Assets prägen und gleichzeitig in derselben Transaktion in den TokenRegistry Smart-Vertrag eintragen lassen. Sie können auch geprägte digitale Assets verkaufen, indem Sie eine Auktion im FairAuction Smart-Vertrag erstellen und andere zur Abgabe von Geboten in dieser Auktion von jedem Netzwerkteilnehmer einladen.

Außerdem bieten wir als Teil der Wallet ein einfaches Verwaltungstool, mit dem Sie Ihre eigenen Instanzen eines der drei PoC Smart-Verträge mit Ausschüssen von Wasp-Knoten und einen Webserver für PoC Smart-Vertrags-Dashboards bereitstellen können.
In dieser Version stellen wir einen wichtigen Teil der ISCP noch nicht zur Verfügung: die Wasm VM (Virtual Machine) und die Rust-Programmierumgebung für intelligente Verträge.

Der Wasp-Knoten implementiert eine abstrakte VM-Sandbox-Schnittstelle, so dass jeder Interessierte sich damit vertraut machen und wenn er mutig genug ist, es sogar ausprobieren kann, indem er das Repository gabelt und seine eigenen hart codierten intelligenten Verträge direkt in die Wasp schreibt!

Einige wichtige Funktionen der ISCP sind deaktiviert, z.B. die Belohnungsfunktion (optionale Knotengebühren, so dass der aktuelle Smart-Kontrakt völlig Gebührenfrei ist) und die Zugriffsknotenfunktion (ein Zugriffsknoten ist ein Wasp-Knoten, der einen gültigen Smart-Kontrakt-Ledger-Status enthält, aber nicht am Komitee des Smart-Kontrakts teilnimmt).

Wasp-APIs haben noch keine Autorisierung implementiert, so dass in dieser Version jeder auf den Status jedes Smart-Vertrags zugreifen oder jeden Wespen-Knoten als Ausschussknoten für seinen Smart-Vertrag verwenden kann.

Die fehlenden Funktionen und Sicherheitslücken werden in späteren Versionen des Wasp-Knotens Schritt für Schritt ergänzt.

PoC-konforme Verträge verwenden

Wir bieten Artikel im Wasp-Repository zu Github mit einer schrittweisen Einführung in die Hauptkonzepte von IOTA Smart Contracts am Beispiel von PoC Smart Contracts.

In diesen Artikeln werden drei PoC Smart-Contracts im Detail beschrieben:

  • DonateWithFeedback implementiert einen einfachen intelligenten Vertrag, der Spenden und damit verbundene Kommentare für eine Website handhabt. Wir stellen die meisten Konzepte am Beispiel von DonateWithFeedback vor, da dies der einfachste aller 3 PoC-Smart Verträge ist.
  • TokenRegistry ermöglicht es uns, farbige IOTA-Tokens zu prägen und ihnen gleichzeitig Metadaten in derselben Transaktion zuzuweisen. Die TokenRegistry führt das unveränderliche Register der Token und ihrer Metadaten, zusammen mit kryptographischen Beweisen für den Urheber der Lieferung und die Liefermenge.
  • FairAuction implementiert einen einfachen automatisierten Marktplatz für IOTA-Farbtoken ein, die über eine Aktion zum Verkauf angeboten werden. Jeder kann seinen Token verkaufen und jeder kann mit seinem IOTAs auf den zu verkaufenden Token bieten, indem er Anfragen an die intelligente Vertragsinstanz sendet. Jede Auktion wird über den Smart-Vertrag abgewickelt. Einmal gestartet, wird garantiert, dass sie fair und prüfbar ist und bis zum Ende läuft.

Die Dashboards der Demo-Instanzen von intelligenten PoC-Verträgen finden Sie hier.

Jede Seite des Dashboards enthält minimale Anweisungen zur Installation und Verwendung der wwallet.

Wir haben auch einige technische Anleitungen entwickelt, die durch einige der Funktionen dieser Version führen und Entwicklern helfen, mit dem Testen zu beginnen. Schauen Sie sich unser Demonstrationsvideo zum Proof of Concept an und beginnen Sie, unsere Plattform zu erkunden!

Nächste Schritte für intelligente IOTA-Verträge

Der nächste große Meilenstein für das Team, das mit IOTA Smart Contracts arbeitet, ist die Implementierung von Wasm VM und der entsprechenden Entwicklungsumgebung in Rust. Wir gehen davon aus, dass sie bis Ende des Jahres zur Verfügung stehen wird.

Zusätzlich enthält ein hochrangiger Plan für den zukünftigen Umfang:

  • Reifung der Kernprotokolle: Perfektionierung des Konsenses, Zugriff auf Knotenfunktionen, Knotenbelohnungen, Zustands-Schnappschüsse, Smart Contract Verwaltung
  • Anpassung auf der Grundlage laufender Entwicklungen des Goshimmer Value Tangle Ledgers;
  • Anpassungen der Kernsicherheit: Vollständig verteilte DKG (in dieser Version teilweise verteilt), digitales Identitätssystem für Knoten, Knotenbesitzer und Smart Contract Inahber
  • Authentifizierung des API-Zugriffs, Sicherheit, Client-Bibliotheken
  • Erweiterung der eingebauten Smart-Contract-Logik, d.h. automatische Rückgabe von Geldern im Fehlerfall, erweiterte Ausnahmebehandlung
  • Migration der eingebauten Logik zu Wasm VM
  • Toolchain für die Knoten- und Smart-Contract-Verwaltung (CLI-Tools, Dashboard, Backup/Recovery)
  • Toolchain und Umgebung für die Entwicklung. Hochsprachliche Metaphern, Abbildung auf mehrere Sprachen
  • Framework für Client-Bibliotheken für dApp-APIs. Rahmenwerk für SC-Unit-Tests und Werkzeuge

Abschließend

Die heute veröffentlichte Prä-Alpha-Arbeit des IOTA Smart Contract Protocol ist der Höhepunkt monatelanger harter und engagierter Arbeit der IOTA-Stiftung. Wir betrachten diese Veröffentlichung als den ersten Schritt zur Schaffung eines großen, lebendigen Ökosystems dezentralisierter Anwendungen im IOTA-Netzwerk.

Wir laden unsere Mitglieder der Gemeinschaft ein, unsere Demo-PoCs auszuprobieren, die Dokumentation durchzusehen und sogar zu versuchen, Ihre eigenen zu erstellen!

Wie immer laden wir alle ein, bei Discord auf dem Kanal #smartcontracts vorbeizuschauen, um mit unserem Team zu sprechen, das mit IOTA Smart Contracts arbeitet!

Folgen Sie uns auf Twitter, um über alle Neuigkeiten auf dem Laufenden zu bleiben!

Original Übersetzt: https://blog.iota.org/iota-smart-contracts-pre-alpha-released-40efad27994b

Eine Einführung in IOTA Smart Contracts

Original by Evaldas Drasutis: https://blog.iota.org/an-introduction-to-iota-smart-contracts-16ea6f247936 (06.05.2020)

Ich möchte mich bei meinen Kollegen in der IOTA-Stiftung bedanken, die Beiträge und Feedback zu diesem Artikel geliefert haben. Insbesondere Eric Hop, der das Qubic-Projekt leitete und jetzt zu IOTA Smart Contracts gehört, und Jake Cahill, der für den größten Teil des Wortlauts verantwortlich ist.

IOTA Smart Contracts ist eine fortlaufende Bemühung der IOTA Foundation. Das Ziel dieses Artikels ist es, die Gemeinschaft darüber zu informieren, was wir tun und wohin wir mit IOTA Smart Contracts gehen. Er bietet auch eine Gelegenheit für die Gemeinschaft, mit Fragen und Feedback zum Projekt beizutragen.

Hintergrund

Kürzlich stellte Eric Hop das Qubic-Projekt in seinem Artikel The State of Qubic vor und erläuterte unsere Entscheidung, uns vorerst ausschließlich auf intelligente Verträge zu konzentrieren. Natürlich warfen diese Entwicklungen viele Fragen aus der Gemeinschaft auf, wie sich die intelligenten Verträge der IOTA zu Qubics Vision verhalten.

Der vorliegende Artikel wird diese Fragen beantworten, indem er einen Kontext und eine technische Einführung zu den IOTA Smart Contracts bietet. Obwohl viele Aspekte der IOTA Smart Contracts vom Qubic-Projekt abgeleitet wurden, handelt es sich in vielerlei Hinsicht um ein eigenständiges, eigenständiges Projekt. Wir glauben, dass die Richtung, die wir einschlagen, viel Potenzial hat, und wir unternehmen jetzt die notwendigen Schritte, um dieses Potenzial in der Praxis unter Beweis zu stellen.

Was ist ein Vertrag?

Bevor wir einen intelligenten Vertrag definieren, ist es wichtig, zunächst zu verstehen, was ein legaler Vertrag ist.

Juristische Verträge sind nicht-deterministische Vereinbarungen, die komplexen Rechtssystemen unterliegen. Die Gesetze, die Verträge umgeben, variieren in Abhängigkeit von einer Reihe von Faktoren, wie zum Beispiel dem Land, in dem alle Parteien den Vertrag abgeschlossen haben. Das wichtigste Wort ist hier „nicht-deterministisch“. Das bedeutet, dass Verträge oft mehrdeutig sind, und ihre subjektive Auslegung kann zu Streitigkeiten führen.

Was ist ein Intelligenter Vertrag?

Im Gegensatz dazu ist ein intelligenter Vertrag eine programmierte Vereinbarung, die völlig deterministisch ist und automatisch durchgesetzt wird. Dies macht es unmöglich, zu streiten.

Das Konzept eines intelligenten Vertrags wurde von Nick Szabo in den 90er Jahren in seiner Abhandlung mit dem Titel „Forming and Securing Relationships on Public Networks“ (Beziehungen in öffentlichen Netzwerken bilden und sichern) erfunden. In diesem Papier stellte er sich Vertragsregeln vor, die als Computercode kodiert sind.

Ein intelligenter Vertrag könnte zum Beispiel für die folgende Vereinbarung programmiert werden:

Wenn Flug F mehr als 3 Stunden Verspätung hat, dann zahlen Sie den Versicherungsbetrag A auf das Konto von Alice.

„Der Flug hat Verspätung“ ist eine Bedingung der Vereinbarung, und „Versicherungsbetrag A an Alice zahlen“ ist eine Folge dieser Bedingung.

Die Folgen der Ausführung eines intelligenten Vertrags hängen von einer Reihe von Bedingungen ab, die wir seinen Zustand nennen.

Der Zustand eines intelligenten Vertrags kann zum Beispiel umfassen

  • Flug F: Pünktlichkeit
  • Das Konto von Alice: 0
  • Intelligentes Vertragskonto: 1000
  • Deckungssumme: 100
  • Ausbezahlt: Falsch

Der Status eines intelligenten Vertrags wird in einem verteilten Ledger veröffentlicht. Wenn eine Aktualisierung erfolgt und das Netzwerk einen Konsens über die Änderung erzielt, wird eine neue Transaktion an das Ledger angehängt, um den Status des Vertrags zu aktualisieren:

Flug F: Verspätet (ein Verweis auf eine andere Transaktion mit Nachweis der Verspätung)

  • Das Konto von Alice: 100
  • Intelligentes Vertragskonto: 900
  • Deckungssumme: 100
  • Ausbezahlt: Wahr

Intelligente Verträge hinterlassen einen unveränderlichen Prüfpfad auf dem verteilten Ledger, und ihre Automatisierung spart Zeit und Geld für die beteiligten Parteien. Das Konzept ist einfach und lässt sich in nahezu jeder Branche in einer Vielzahl interessanter Anwendungsfälle anwenden, von der Verfolgung von Waren in der gesamten Lieferkette bis hin zum Austausch von Eigentum an Aktien und Anleihen. Intelligente Verträge sind jedoch eine aufstrebende Technologie. Es bleibt eine offene Frage, wie sie sich in den bestehenden Rechtsrahmen einfügen werden, und es ist noch einiges zu tun, bevor sie ihr volles Potenzial erreichen.

Arten von intelligenten Verträgen

Schicht 1 („On-Chain“)
Intelligente „On-Chain“-Verträge, wie die auf Ethereum, sind Teil des Kernprotokolls. Das bedeutet, dass sie von allen Knoten im Netzwerk ausgeführt und validiert werden.

Vorteile

  • Die Sicherheit von intelligenten Verträgen ist proportional zur Größe des Netzwerks
  • Intelligente Verträge können Tokens von ihrem Konto übertragen, ohne eine Unterschrift zu leisten

Nachteile

  • Intelligente Verträge skalieren schlecht, weil ihre Programme von allen Knoten ausgeführt werden müssen
  • Intelligente Verträge unterliegen Netztransaktionsgebühren, die ebenso volatil sind wie der zugrunde liegende symbolische Preis.
  • Die durchschnittlichen Kosten eines intelligenten Vertragsabschlusses sind ungefähr proportional zum zugrunde liegenden symbolischen Preis

Schicht 2 („Off-Chain“)
„Off-chain“ intelligente Verträge werden außerhalb des Kernprotokolls ausgeführt. Nur eine Untergruppe von Knoten, ein so genannter Ausschuss, muss sie ausführen, und ein Konsens kann außerhalb des Kernprotokolls erreicht werden.

Vorteile

  • Intelligente Verträge belasten den Rest des Netzwerks nicht
  • Die durchschnittlichen Kosten für eine intelligente Vertragsabwicklung sind niedrig und vorhersehbar
  • Der notwendige Grad der Dezentralisierung (und damit die Sicherheit) eines intelligenten Vertrags kann an jeden Anwendungsfall angepasst werden.

Nachteile

  • Um Token zu übertragen, müssen intelligente Vertragsprogramme Transaktionen unterzeichnen, um nachzuweisen, dass sie Zugriff auf die Kontoadresse haben.
  • Die Dezentralisierung (und damit die Sicherheit) intelligenter Verträge hängt von der Größe des Ausschusses, den Ausschussmitgliedern und der Stelle ab, die den Ausschuss einsetzt.

Warum braucht die IOTA intelligente Verträge?

Intelligente Verträge sind in vielen Bereichen von IOTA unverzichtbar, darunter Supply Chain, Smart Cities, Industrial IoT und andere. Intelligente IOTA-Verträge können Vertragsverpflichtungen innerhalb dieser Branchen automatisieren.
Im Vergleich zu ihren Blockchain-Pendants haben IOTA Smart-Contracts dank der Tangle-Eigenschaften wie Skalierbarkeit, hoher Durchsatz und Gebührenfreie Transaktionen viele Vorteile.

Wie funktionieren intelligente Verträge in IOTA?

IOTA Smart Contracts werden als unveränderliche Zustandsmaschinen definiert:

  • Zustandsmaschine: Jeder intelligente Vertrag hat einen Zustand, der mit dem Tangle verbunden ist. Der Zustand enthält Daten wie Kontostände, Eingabebedingungen und Konsequenzen im Laufe der Zeit. Jede Zustandsaktualisierung stellt einen Zustandsübergang auf dem Tangle dar.
  • Unveränderlich: Der Zustand und der Programmcode des intelligenten Vertrags sind beide unveränderlich, da sie auf dem Tangle gespeichert sind. Der Zustand kann inkrementell aktualisiert werden, indem neue Transaktionen an das Tangle angehängt werden.

Der Tangle bietet einen verifizierbaren Prüfpfad der Zustandsübergänge. Dadurch können wir darauf vertrauen, dass die Zustandsübergänge gültig sind und nicht durch böswillige oder fehlerhafte Knoten verfälscht werden können.

Der Fall für intelligente Layer-2-Verträge

Um die Anwendungsfälle der IOTA, einschließlich des Internet der Dinge, zu erleichtern, bauen wir intelligente IOTA-Verträge auf Schicht 2, „off-Tangle“.

Obwohl die „on-chain“ intelligenten Verträge von Ethereum aufgrund ihrer Eigenschaften beliebt sind, haben sie einige bedeutende Nachteile. Der hervorstechendste ist, dass jeder Knotenpunkt für jeden intelligenten Vertrag, der existiert, eine Kopie des Programmcodes und -status des Vertrags behalten muss. Jeder Knoten im Netzwerk muss genau den gleichen Code ausführen, wenn der Smart-Vertrag ausgelöst wird.

Es gibt keine Begrenzung der Anzahl der Knoten, die diesen identischen Code ausführen müssen, nur um ein einziges Ergebnis zu erzeugen. Und je größer das Netzwerk wird, desto mehr Verarbeitung ist erforderlich, um dasselbe Ergebnis zu erzielen. Dies stellt ein enormes Hindernis für die Skalierbarkeit dar.

Zusätzlich zu den Transaktionsgebühren, die Sie zahlen müssen, um für die Aufnahme in das Hauptbuch in Betracht gezogen zu werden, müssen Sie auch Gasgebühren zahlen, um das Programm lange genug laufen zu lassen, damit es abgeschlossen werden kann. Das bedeutet, dass die Kosten für den Betrieb dieser intelligenten Verträge unerschwinglich hoch werden, wenn man von bestimmten Anwendungsfällen absieht, in denen der Kostenaufwand relativ unbedeutend ist.
Aus diesem Grund werden IOTA Smart-Contracts nicht als Teil des Kernprotokolls implementiert, sondern als ein Layer-2-Protokoll.

Infolgedessen bieten IOTA Smart-Contracts eine natürlichere Art und Weise, verteilte Berechnungen auszuführen. Jeder Smart-Contract kann in einem lokalisierten Kontext ausgeführt werden, ohne dass das gesamte Netzwerk zur Ausführung gezwungen wird. Dies bedeutet auch, dass IOTA Smart-Contracts in Zukunft nicht zu einem Hindernis für die Skalierung des IOTA-Netzwerks mit Sharing-Lösungen werden.

Der Eigentümer eines intelligenten Vertrags

Jeder Smart-Vertrag hat einen Eigentümer, der für ihn verantwortlich ist:

  • Das smart contract-Programm zu erstellen und beim Netzwerk einzureichen
  • Festlegung der Größe des Komitees (die Zahl N) und die Auswahl der Netzwerkknoten, die Teil des Komitees sein sollen
  • Entscheidung, wie viele Ausschussknoten einen Konsens über Aktualisierungen des Smart Contract-Status erreichen müssen. Diese Zahl wird als Quorum bezeichnet
  • Festlegung anderer allgemeiner Konfigurationsparameter des Smart-Vertrags

Ein Eigentümer kann eine einzelne Einheit sein, z. B. eine Organisation oder eine Person, oder es kann sich um eine dezentralisierte Sammlung von Peers handeln, z. B. ein Konsortium von Organisationen. In jedem Fall verwaltet der Eigner nur die Einrichtung und Konfiguration des Smart-Vertrags und nimmt nicht an dessen Betrieb teil.

Der Eigentümer kann je nach Kontext und Zweck wählen, wie intelligente Verträge eingerichtet werden sollen. Beispielsweise kann ein intelligenter Vertrag, der hochwertige Transaktionen abwickelt, einen großen Ausschuss von Knoten erfordern. Während ein intelligenter Vertrag, der Mikrotransaktionen abwickelt, unter Umständen nur 20-30 Knoten im Ausschuss benötigt.

Motivationen: Belohnungen und Reputation

Es gibt viele mögliche Gründe, einen intelligenten Vertrag zu erstellen oder zu betreiben. Ein Grund ist die Belohnung.

Obwohl IOTA-Transaktionen Gebührenfrei sind, bieten intelligente IOTA-Verträge den Unternehmen die Möglichkeit, eine Gebühr in IOTA-Tokens zu verlangen, z.B. zur Deckung der Betriebskosten. Wir nennen diese Gebühr eine Belohnung.

Sowohl Eigentümer als auch Ausschussknotenpunkte können intelligente Vertragsbelohnungen erhalten. Es ist Sache des Eigentümers, mit den Betreibern von Komitee-Knotenpunkten zu verhandeln, um die minimal akzeptable Belohnung festzulegen.

  • Ausschussknoten können Belohnungen erhalten, indem sie einen bestimmten intelligenten Vertrag bearbeiten, der eine Belohnung bietet
  • Eigentümer haben auch die Möglichkeit, intelligente Verträge zu erstellen, die dem Eigentümer einen Prozentsatz der Belohnung zukommen lassen.

Eine weitere potenzielle Motivation für die Mitgliedschaft in einem Ausschuss ist der Aufbau eines guten Rufs. Kluge Vertragsinhaber können sich dafür entscheiden, Ausschüsse nur aus Knotenpunkten mit einem guten Ruf zu bilden.
Diese Art von Reputationssystem könnte einen offenen Markt für Ausschussknoten schaffen, der gutes Verhalten im Netzwerk fördert.

Das Smart Contract Programm

Ein intelligentes Vertragsprogramm ist ein Algorithmus, der Anweisungen für eine virtuelle Maschine (VM) enthält. Wir werden WebAssembly (WASM) als Haupt-VM für IOTA Smart Contracts verwenden. Aber im Allgemeinen kann die VM in jeder Sprache oder sogar fest in der Software des Knotens programmiert sein.

Das Programm nimmt zwei Transaktionen als Input: die Anfragetransaktion und die Transaktion des aktuellen Status. Die Transaktion des nächsten Zustands verweist immer auf die Anfragetransaktion und die Transaktion des vorherigen Zustands. Auf diese Weise verfügt das intelligente Vertragsprogramm über eine deterministische Methode zum Aufbau einer Kette von Zustandsaktualisierungen, die durch eingehende Anfragen ausgelöst werden.

Der Hash des Programms wird im Tangle gespeichert und ist daher unveränderlich.
(Hinweis: Intelligente IOTA-Verträge werden durch eine Transaktion und nicht durch ein Bündel definiert, da wir sie im IOTA-Protokoll nach dem IOTA-Koordizid implementieren, das ein UTXO-Modell für Werttransaktionen verwendet)

Ein Beispiel für ein intelligentes Vertragsprogramm

Es folgt eine kurze Beschreibung des intelligenten FairRoulette-Vertrags: unser interner PoC, den wir für Tests verwenden.

Betrachten Sie einen Smart-Vertrag, der Wetten auf ein Rouletterad annimmt. Der Smart-Vertrag würde in seinem Konto gestapelte IOTA-Münzen sowie Daten über jede platzierte Wette (Summe, Farbe, Spieler) enthalten. Letzteres wird für Auszahlungen an die Gewinner von Roulette-Spielen benötigt.

Um eine Wette zu platzieren, senden Sie eine Antragstransaktion an den Smart-Vertrag. Die Transaktion würde enthalten:

  • Eine Gebührenzahlung von IOTA-Marken für die Bearbeitungskosten
  • Eine Einzahlung von IOTA-Münzen, die Sie setzen möchten
  • Die Farbe, auf die Sie wetten

Wenn die Komitee-Knotenpunkte dann diese Transaktion sehen, werden sie das Programm des intelligenten Vertrags ausführen, um den Status mit Ihrer Wette zu aktualisieren.

Die Auszahlung an die Gewinner wird nach Spielende automatisch gemäß dem Programm des Smart-Vertrags ausgeführt.

Der Ausschuss und das Quorum

Die Kontoadresse des Smart-Vertrags ist Eigentum des Ausschusses. Diese Adresse enthält die hinterlegten IOTA-Marken. Nur ein Quorum von Ausschussknoten ist in der Lage, Tokens von der Adresse weg zu übertragen. Mit anderen Worten, ein Quorum von Ausschussknoten muss zusammenarbeiten, um IOTA-Marken vom Konto zu entfernen.

Wir verwenden BLS-Adressen mit mehreren Unterschriften, um den Ausschussknoten das gleiche Eigentumsrecht an der Adresse zu geben. Diese Adressen ermöglichen Schwellenunterschriften, was bedeutet, dass eine bestimmte Anzahl von Knoten im Ausschuss, das Quorum, dieselbe Transaktion mit ihrem geheimen Schlüssel unterschreiben muss, um eine gültige Unterschrift zu erzeugen und somit den Zustand des Smart-Vertrags zu aktualisieren und die vom Smart-Vertrag kontrollierten Mittel zu bewegen.

Wie intelligente Verträge erstellt werden

Der Eigentümer eines Smart-Vertrags erstellt das Programm, und sein Binärcode wird in Ausschussknoten gespeichert. Der Hash des Programms ist durch die staatliche Transaktion immer zugänglich, so dass der Smart-Vertrag unveränderlich ist.

Der Eigentümer setzt einen Ausschuss von Knotenpunkten ein, die für die Ausführung des Programms, das Abhören des Tangle für Anfragetransaktionen und die kollektive Aktualisierung des Zustands des Smart-Vertrags verantwortlich sind.
Während der Einsetzung des Ausschusses entscheidet der Eigentümer über die Größe des Ausschusses und das Quorum und initialisiert einen Prozess der verteilten Schlüsselerzeugung (Distributed Key Generation, DKG) zwischen den Knoten des Ausschusses. Dieser Prozess erzeugt:

  • Eine durch den Smart-Vertrag kontrollierte Kontoadresse
  • Einen privaten Schlüssel für jeden Ausschussknoten (weder dem Eigentümer noch anderen Ausschussknoten bekannt)

Dieser Prozess kann entweder zentralisiert oder dezentralisiert sein. In der zentralisierten Version kann der Eigentümer bei Bedarf einen Generalschlüssel verwenden, um Ausschussbeschlüsse außer Kraft zu setzen. In der dezentralisierten Version kann der Verantwortliche Entscheidungen nicht außer Kraft setzen.

Wie der Status eines intelligenten Vertrags aktualisiert wird

Die Ausschussknotenpunkte hören immer auf den Tangle, wenn es um Anfragetransaktionen geht, die an den intelligenten Vertrag gesendet werden sollen.

Wenn ein Ausschussknoten eine Transaktion erkennt, berechnet er den nächsten Zustand, indem er das Smart-Contract-Programm ausführt. Auf diese Weise werden ehrliche und synchronisierte Knoten immer genau die gleiche Zustandsaktualisierungstransaktion erzeugen. Ausschussknoten tauschen nie echte Ergebnisse aus, sondern nur Hashes. Es besteht also kein Risiko, dass Knoten die Ergebnisse der anderen kopieren, um zu versuchen, die Belohnung auszuspielen.

Wenn sich die Knoten nicht über den aktualisierten Zustand einig sind, wird jeder Knoten eine andere Transaktion unterzeichnen, was zu einer ungültigen Signatur führt. Die Knoten müssen daher einen mehrheitlichen Konsens über den aktualisierten Zustand erreichen.

In der asynchronen Einstellung des Tangles kann jeder Ausschussknoten einen anderen Zustand sehen, je nach seiner lokalen Uhr oder seinen Nachbarn. Ausschussknoten müssen daher einen verteilten Konsensalgorithmus ausführen, um einen Konsens über das Ergebnis zu erzielen. Das Ergebnis des Konsenses ist ein Hash des Ergebniskerns, eine Sammlung von Teilunterschriften des BLS und ein Zeitstempel. Alle intelligenten Vertragstransaktionen werden mit einem Zeitstempel versehen, und der Zeitstempel stimmt mit den lokalen Uhren der meisten Knoten überein.

Wenn alle Knoten einen Konsens erreicht haben, sammelt ein Ausschussmitglied, der Leiter, alle Teil-BLS-Signaturen der Knoten, bevor die endgültige Transaktion an das Tangle übermittelt wird. Diese Transaktion muss sich auf den vorherigen Zustand beziehen, um eine Kette von Zustandsaktualisierungen zu erstellen, die als Prüfpfad dient. Wenn die Transaktion bestätigt wird, wird sie zum neuen Zustand des intelligenten Vertrags.

Herausforderungen

IOTA Smart Contracts sind äußerst flexibel, aber diese Flexibilität bringt auch Herausforderungen mit sich, für die wir zum Teil bereits Lösungen entwickelt haben.

Staatliche „Forks“

Ein State Fork ist eine widersprüchliche Kopie des Zustands des intelligenten Vertrags. Dies kann passieren, wenn zwei oder mehr Transaktionen an den Tangle angehängt werden, die beide den Zustand auf unterschiedliche Weise aktualisieren.

Obwohl wir erwarten, dass Zustandsabzweigungen selten sind, könnten sie theoretisch in einer asynchronen Umgebung auftreten. Zum Beispiel verliert der führende Knoten unmittelbar vor der Verbuchung der letzten Transaktion die Verbindung mit dem Tangle und nach einer Zeitüberschreitung übernimmt ein anderer Knoten die Führung. In diesem Fall könnten zwei führende Knoten Aktualisierungen des Tangle nach der Verbuchung der letzten Transaktion vornehmen.

Um Zustandsabzweigungen zu verhindern, wird bei der Einrichtung des Smart-Vertrags ein einzigartiges farbiges Token, das als Smart-Vertrags-Token (mit einem Gesamtvorrat von 1) bezeichnet wird, erstellt und an die Smart-Vertragsadresse übertragen. Bei jeder Statusaktualisierung wird das einzige Smart-Contract-Token an dieselbe Adresse gesendet, wodurch die entsprechende nicht ausgegebene Ausgabe in die neue Transaktion verschoben wird. Auf diese Weise bilden die Transaktionen eine nicht verarbeitbare Kette, da es unmöglich ist, den Output des intelligenten Vertragstokens aufzuteilen und zweimal auszugeben.

Schnappschüsse

Ein Schnappschuss ist eine Möglichkeit für einen Knoten, Speicherplatz zu sparen. Transaktionen vor einem bestimmten Datum werden möglicherweise „weggeschnappt“. Dabei können ältere intelligente Transaktionen und Aktualisierungen des Vertragsstatus verloren gehen.

Um dieses Problem zu entschärfen, können intelligente Verträge ihre eigenen Momentaufnahmen durchführen, indem sie alle Zustandsinformationen sammeln und sie zu einer einzigen Transaktion hinzufügen. Diese Transaktion wird zum Anfang der neuen Kette.

Große Summen von Tokens

Eine große Geldsumme über einen langen Zeitraum in einem Vertrag zu sperren, ist viel sicherer, wenn man sich darauf verlassen kann, dass das gesamte Netzwerk für die Abwicklung zur Verfügung steht, wie bei den intelligenten Verträgen von Ethereum Level 1. Es ist jedoch nicht garantiert, dass nach einem langen Zeitraum ein Ausschuss von begrenzter Größe existiert. Für diese Anwendungsfälle könnte ein intelligenter Vertragsinhaber von Fall zu Fall andere Notfallpläne aufstellen.

Schlüsselverwaltung

Die Knotenpunkte müssen für jeden Ausschuss, dem sie angehören, einen Schlüssel verwalten. Wenn ein Knotenpunkt Teil vieler Ausschüsse ist, ist daher die Speicherung und Verwaltung dieser Schlüssel eine wesentliche Aufgabe. Die Knotenpunkte benötigen eine Lösung für eine sichere und skalierbare Schlüsselverwaltung.

Schlussfolgerung

IOTA Smart Contracts sind intelligente Vertragsprogramme, die von einem genehmigten Ausschuss auf Schicht 2 (Off-Tangle) ausgeführt werden. Der Ausschuss der Knotenpunkte aktualisiert das Ledger kollektiv, indem er unterzeichnete Transaktionen (unter Verwendung von Schwellenwertunterschriften) an das Tangle einreicht.

IOTA Smart-Contracts sind sehr flexibel und benötigen viel weniger Ressourcen als die Blockketten-Alternativen. Sie ermöglichen Anwendungsfälle, die mit Gebühren als einzigem Anreiz nicht möglich gewesen wären. Dies gilt insbesondere im Bereich des IoT, wo Mikroverträge und Mikrotransaktionen die Norm sein dürften.

Wir planen, WebAssembly in der ersten Version zu verwenden, aber wir sind nicht auf eine einzige virtuelle Maschine (VM) beschränkt, mit der Möglichkeit, in Zukunft auch andere Programmiersprachen und VMs zu verwenden.

Wir laden die Gemeinschaft ein, ihre Gedanken, Ideen und ihr Feedback im Kanal #smartcontracts auf dem offiziellen IOTA-Discord zu teilen.

Dev Status Update — April 2020 – Deutsch

Original by Jakub Cech: https://blog.iota.org/dev-status-update-april-2020-ef4f4a12ac82 (24.04.2020)

Dieses Update wird jeden Monat vom IOTA-Entwicklerteam veröffentlicht und liefert Ihnen Neuigkeiten und Updates zu unseren Schlüsselprojekten! Bitte klicken Sie hier, wenn Sie das letzte Status-Update sehen möchten.

Die Forschungsabteilung gibt auch ein monatliches Update heraus, das Sie sich vielleicht ansehen möchten.

Chrysalis

Die Forschungs- und Ingenieurteams haben zusammen mit dem Hornet-Team an der Fertigstellung der Spezifikationen für die ersten Chrysalis-Änderungen gearbeitet. Sie können die Spezifikationen in den verknüpften RFCs einsehen, aber auch selbst kommentieren und beitragen:

  • Gewichtete einheitliche zufällige Spitzenauswahl (Protokoll RFC #8)
  • Weiße Flagge (Protokoll RFC #5)
  • Die Spezifikation des Ed25519-Signaturschemas muss angepasst werden, da es mit UTXO gekoppelt wird

Die restlichen Chrysalis-Spezifikationen werden in den kommenden Wochen entworfen, und das Ziel ist es, sie im Mai fertigzustellen und in das Protokoll-rfc-Repository zu integrieren.

Autopeering, ebenfalls ein Teil von Chrysalis, wird bereits in der Hornet-Knoten-Software getestet. Es ist geplant, Autopeering bereits in die nächste Version von Hornet aufzunehmen.

Bee

Das Team schließt gerade die Arbeiten am ersten Bee-Prototypen ab. Das Team hat an den letzten Teilen des Puzzles gearbeitet: der Meilenstein-Erkennung und dem Durchqueren von Verwicklungen. In unseren internen Tests hat Bee seinen ersten Meilenstein bereits gefestigt. Der Prototyp wird im Mai freigegeben und für Tests zur Verfügung stehen. Das Hauptziel ist die Fertigstellung der Meilenstein-Erkennung und der Verwicklungswerkzeuge, die eine vollständige Verfestigung des Knotens ermöglichen werden.

Sie können alle Bee-RFCs in ihrem jeweiligen GitHub-Repository finden.

IRI

Das Team hat im vergangenen Monat IRI 1.8.5 veröffentlicht. Die Version enthielt wichtige Änderungen an den Bundle-Validierungsregeln, mit denen potenzielle Schwachstellen behoben wurden. Das Team konzentriert sich nun auf die nächste Minor-Version, IRI 1.8.6. Diese Version wird hauptsächlich eine neue Erstarrungslogik und andere Korrekturen enthalten, z.B. sollte die Erstellung lokaler Schnappschüsse schneller als bisher sein.

Wir gehen davon aus, dass das RC von IRI 1.8.6 nächste Woche herauskommen wird.

Intelligente Verträge

Wie letzte Woche angekündigt, haben wir unsere Aufmerksamkeit auf die Entwicklung eines neuen Smart Contract-Ansatzes als Layer-2-Lösung verlagert, der auf der Entwicklung von Koordizid in GoShimmer aufbaut. Wir planen, in den kommenden Wochen einen detaillierteren Beitrag über die entwickelte Lösung zu veröffentlichen. Eine kurze Einführung finden Sie hier.

Trinity

Das Trinity-Team hat in drei Schlüsselbereichen gearbeitet. In letzter Zeit lag ein Schwerpunkt auf der Erstellung einer PoC-App und einer Website, um die Möglichkeiten des Unified Identity Protocol zu demonstrieren. Weitere Informationen zu diesem Projekt werden folgen.

Auf der Trinity-Seite hat das Team Fragen geklärt, Abhängigkeiten aktualisiert und einige Reibungspunkte gelöst. Der jüngste Spam hat für Trinity-Benutzer ein Ärgernis verursacht und das Team hat Schritte unternommen, um dieses Problem zu lösen, einschließlich der Hinzufügung von Filtern für mobile Transaktionen. Eine neue Version wird bald verfügbar sein.

Schließlich hat das Team die Planung für die Brieftasche nach Trinity fortgesetzt. Es wurde ein Workshop „Jobs to be Done“ abgehalten, um sicherzustellen, dass die Spezifikation den aktuellen und zukünftigen Benutzerbedürfnissen entspricht. Der Schwerpunkt liegt nun auf der Unterstützung bei der Definition der Client-Bibliotheken für Chrysalis, wobei wiederverwendbare Adressen einen großen Teil der Möglichkeiten der neuen Brieftasche ausmachen. Das Team arbeitet hart daran, das DID-Projekt zum Abschluss zu bringen und Trinity in einen wartungsarmen Modus zu versetzen, damit sie sich auf die nächste Generation der Brieftasche konzentrieren können.

GoShimmer

Das GoShimmer-Team arbeitet derzeit an der Entwicklung weiterer Komponenten, die Werttransaktionen mit einer Konfliktlösung durch das angeschlossene FPC-Protokoll unterstützen werden. Mehr über die Entwicklung können Sie im letzten Forschungs-Update nachlesen.

Wir planen derzeit, die neue Version von GoShimmer in der ersten Junihälfte zu veröffentlichen.

Sie können das Projekt auf seinem GitHub-Repository verfolgen. Wenn Sie sich beteiligen möchten, sehen Sie sich unsere aktualisierten Beitragsrichtlinien an.

IOTA-Streams

Wir haben kürzlich die erste Alpha-Version von IOTA Streams (früher MAM) veröffentlicht. Wir arbeiten nun daran, mehr Dokumentation und Beispiele auf unserer Website zu veröffentlichen, damit mehr von Ihnen einsteigen und die Funktionalität testen können. Wir freuen uns über jedes Feedback, sowohl zur Implementierung als auch zur Dokumentation.

Permanode

Das Team arbeitet nun an der Fertigstellung der CLI-Funktionalität für die neue Permanode und wird sich als nächstes auf die Verfestigung konzentrieren. Wir haben in der Roadmap auch die Tatsache berücksichtigt, dass das Team beschlossen hat, die Rust Tokio-Laufzeitumgebung zu verwenden, anstatt eine benutzerdefinierte Laufzeitumgebung für den Permanode zu entwickeln. Die Tokio-Laufzeit erwies sich für die aktuelle Implementierung als ausreichend.

Das aktuelle Ziel ist es, die neue Version des Permanode Ende Mai oder in der ersten Junihälfte auf den Markt zu bringen.

Aktualisierungen der Roadmap

Wir haben einige bedeutendere Aktualisierungen unseres Fahrplans sowie Anpassungen der allgemeinen Zeitpläne der verschiedenen Projekte vorgenommen. Die Höhepunkte sind:

  • Der Abschnitt Qubic wurde in IOTA Smart Contracts geändert. Der Abschnitt zeigt jetzt die fertiggestellten Qubic-PoCs und konzentriert sich künftig nur noch auf die IOTA Smart Contracts
  • Kundenbibliotheken – die Zeitachse wurde verschoben, um mit der Chrysalis-Aktualisierung übereinzustimmen. Die Client-Bibliotheken erfordern erhebliche Änderungen zur Unterstützung von Chrysalis
  • Permanode – die optimierte Permanode-Laufzeit wurde gestrichen. Die anfängliche Implementierung des Permanentmodus wird auf der Tokio-Laufzeit aufbauen
  • MAM wurde in IOTA Streams umbenannt
  • Die Alpha-Implementierung von IOTA Streams wurde als abgeschlossen markiert. Die nachfolgenden Entwicklungen, Korrekturen und Änderungen beziehen sich auf die Implementierungselemente C und Rust.

Wie immer heißen wir jeden willkommen, bei Discord vorbeizuschauen – jedes hier erwähnte Projekt hat einen Kanal (oder mehr) für Diskussionen mit den Entwicklern!

Folgen Sie uns auf Twitter, um über alle Neuigkeiten auf dem Laufenden zu bleiben: https://twitter.com/iotatoken

Der Zustand von Qubic und die Zukunft der Smart Contracts auf IOTA

Original by Eric Hopp: https://blog.iota.org/the-state-of-qubic-63ffb097da3f

TL;DR:

Die IOTA-Stiftung hat beschlossen, unseren Schwerpunkt auf einen neuen Ansatz für Smart Contracts zu verlagern, der sich aus unserer früheren Arbeit ableitet. IOTA Smart Contracts ist eine „Layer-2-Lösung“, die auf der Entwicklung von Coordicide in GoShimmer aufbaut. Eine kurze Einführung finden Sie hier. Die Weiterentwicklung von Qubic erfordert erhebliche Ressourcen und Zeit, und unser neuer Ansatz wird eine breitere und schnellere Anwendung ermöglichen. Wir haben einen funktionierenden Proof of Concept der Programmiersprache Qupla, der auf FPGA-Hardware ausgeführt werden kann, als Open Source zur Verfügung gestellt. Wir laden die Open-Source-Gemeinschaft ein, ihn zu erforschen.

Der Zustand von Qubic

Es ist schon eine Weile her, dass wir uns umfassend mit dem aktuellen Stand des Qubic-Projekts befasst haben. Dieser Artikel wird hier Abhilfe schaffen, indem er eingehend darauf eingeht, wo wir das Projekt derzeit sehen, wie weit wir gekommen sind, welche Lektionen wir gelernt haben und wie die IOTA-Stiftung die Entwicklung von Smart Contracts weiter vorantreiben wird.

Bitte beachte: Wir gehen davon aus, dass der Leser über ein grundlegendes Verständnis des Qubic-Systems sowie der Artikelserie über das Qubic-Berechnungsmodell verfügt. Einige der in diesen Ressourcen verwendeten Begriffe haben sich möglicherweise im Laufe der Zeit aus Gründen der Klarheit etwas geändert.

Qubic: ein layered-System

Wenn man sich Qubic genauer ansieht, dann besteht es eigentlich aus zwei sehr lose gekoppelten Schichten, die sich gegenseitig nicht so sehr zu brauchen scheinen. Diese beiden Schichten sind:

  • Die „Nachrichtenschicht“ Smart Contract (SC), die als Level-2-Protokoll über dem IOTA Tangle läuft. Diese Schicht regelt die Ausführung von SCs durch ein Komitee von Verarbeitungsknoten (Nodes). Die Nodes erzeugen einen beschlussfähigen Konsens über die Verarbeitungsergebnisse und bieten einen Prüfpfad für das Tangle. Diese Schicht kümmert sich nicht darum, wie die Verarbeitung erfolgt, sondern nur darum, dass die Ergebnisse durch den Prüfpfad, den SC-Code, die Eingabedaten und die Ausgabedaten nachweislich korrekt und überprüfbar sind.
  • Die Ebene der virtuellen Maschine (VM) von Abra. Diese Schicht regelt die tatsächliche Ausführung des SC-Codes. Sie hat einen besonderen Schwerpunkt auf der Fähigkeit, auf IoT-Geräten mit geringem Ressourcenbedarf ausgeführt werden zu können. Die Schicht nimmt Eingabedaten entgegen, führt den (möglicherweise hardwarebeschleunigten) Code aus und gibt Ergebnisse aus. Dieser Schicht ist es gleichgültig, woher die Eingabedaten kommen und wohin die Ergebnisse gesendet werden.

Diese beiden separaten Schichten werden durch das Qubic Computation Model (QCM), ein Ereignisverarbeitungssystem, zusammengeklebt. Das QCM regelt die Weiterleitung der Eingabedaten von der SC-Schicht an die VM-Schicht und die Rückgabe der Ergebnisse von der VM-Schicht an die SC-Schicht. Das QCM ist ein sehr generisches Modell. Es nimmt nichts über die Ereignisverarbeitung an, woher die Ereignisdaten kommen oder wohin die Verarbeitungsergebnisse gehen. Es handelt sich lediglich um einen einfachen Dispatching-Mechanismus, der eine vollständige Entkopplung zwischen den Schichten, die miteinander reden müssen, sicherstellt.

Verbinden der Schichten

Wo also findet die Kopplung dieser beiden Systeme statt, wenn sie fast vollständig entkoppelt sind? Zunächst besteht die Notwendigkeit, Berechnungsergebnisse unabhängig voneinander verifizieren zu können. Das bedeutet, dass Sie neben einem Audit-Trail für die Eingabedaten und Ergebnisse von SC-Aufrufen auch den entsprechenden SC-Code benötigen, der aufgerufen wurde, um Teil dieses Audit-Trails zu sein. Auf diese Weise weißt du genau, welchen Code du mit den Eingabedaten ausführen musst, wenn du das Ergebnis verifizieren willst.

Beachte, dass dies immer noch nicht die Verwendung des Qubic-spezifischen Qupla-Codes und des entsprechenden Abra VM zur Ausführung des SC erfordern würde. Du könntest im Wesentlichen jede VM und jede Programmiersprache verwenden, solange der SC-Code mit diesen kompatibel ist. Unsere erste Proof-of-Concept-Implementierung des QCM vermischt in der Game of Life-Demo tatsächlich Qubic-spezifischen Abra-Code mit Standard-Java-UI-Code. Es gibt jedoch einen ganz bestimmten Grund, bei der Auswahl einer VM zur Ausführung Ihres SC-Codes vorsichtig zu sein. Da Knoten diesen Code immer dann ausführen, wenn Daten für die SC automatisch und unbeaufsichtigt ankommen, möchten Sie verhindern, dass laufende SC-Programme in der VM-Schicht ausgeführt werden (unbegrenzte Schleifen/Rekursionen). Du benötigst einen Mechanismus, um das SC-Programm in Schach zu halten, so dass es nur für eine vernünftige, vorhersehbare Zeitspanne läuft.

In Ethereum wird dieses Runaway-Problem durch die Einführung von Gasgebühren (Gas) gelöst. Die Höhe der vorgesehenen Gebühren entspricht einem bestimmten Höchstbetrag für die SC-Verarbeitung. Sobald dieses Maximum überschritten wird, wird die SC-Ausführung abgebrochen, wodurch verhindert wird, dass der unkontrollierte SC-Code unbegrenzt weiterläuft. Der Nachteil dieser Methode besteht darin, dass es schwierig sein kann, die Höhe der Gasgebühren, die Sie für Ihre SC benötigen werden, im Voraus vorherzusagen, wenn die SC irgendeine Art von nicht-trivialer Verarbeitung durchführt. Und wenn Sie zu wenig Gasgebühren bereitstellen, könnte dies dazu führen, dass Ihre SC-Ausführung abgebrochen wird, bevor sie abgeschlossen ist. In diesem Fall haben Sie die Gasgebühren verloren, ohne dass die Vollstreckung zu einem Vollstreckungsergebnis geführt hätte.

In Qubic lösen wir dieses Problem deterministisch, indem wir ein funktionales Datenflussprogrammierungsmodell in der Abra VM haben, das keine unbegrenzten Schleifen/Rekursion zulässt und daher an und für sich nicht Turing-fähig ist. Jede Funktion definiert klar, wie viel Verarbeitung sie leisten wird. Es gibt keine direkte Verzweigung oder Schleifenbildung in der Abra VM, was bedeutet, dass jede Funktion immer genau die gleiche Anzahl von Anweisungen ausführt. Selbst wenn eine Funktion rekursiv aufgerufen wird, ist sie auf eine bestimmte maximale Anzahl von Aufrufen beschränkt. Unbegrenzte Schleifen können auf einer höheren Ebene, durch das QCM, aktiviert werden, aber die Einheit der Ausführung ist absolut klar und garantiert auf Funktionsebene begrenzt. Wenn du erwartest, dass dir die Aufrufe für eine Funktion ‚ausgehen‘, kannst du deinen Code so gestalten, dass der Fortsetzungszustand des SC Teil der resultierenden Ausgabe ist. Und das wiederum ermöglicht es dir, die Ausführung von diesem Punkt aus in einer nächsten Runde begrenzter Aufrufe fortzusetzen. Wir sagen daher, dass die Ausführung durch den QCM Quasi-Turing-Abschluss ist.

Beachte, dass, obwohl die Möglichkeit der Bereitstellung von Belohnungen als potenzieller Anreiz für die Verarbeitung besteht, es in Qubic nicht erforderlich ist, das Äquivalent der Ethereum-Gebühren für die Verarbeitung bereitzustellen. Es könnte andere Anreize geben, die genauso gut oder sogar besser funktionieren. Zum Beispiel, wenn eine Baugruppe speziell dafür ausgelegt ist, bestimmte Sensordaten zu aggregieren. Ein Prüfpfad oder sogar redundante Berechnungen könnten in einem solchen Fall Anreiz genug sein.

Virtuelle Maschine Abra

Das Abra VM-Programmiermodell ist insofern sehr ehrgeizig, als dass es uns nicht nur ein Programmiermodell zur Verfügung stellt, das Quasi-Turing-fähig gemacht werden kann, sondern es entfernt sich auch von Standard-Opcode-basierten sequentiellen Befehlen, die von einer komplexen CPU verarbeitet werden. Stattdessen bietet es uns eine maximale Parallelisierung von Operationen durch ein Datenflussmodell, das letztlich nur zwei Arten von Operationen hat, mit denen jede Funktion implementiert werden kann: Lookup-Tabellen (LUTs) und Fusionen. Diese Operationen wurden speziell wegen ihrer Fähigkeit ausgewählt, einfach direkt in der Schaltung instanziiert zu werden. Die maximale Parallelisierung von Operationen wird nur bei der Instantiierung in Schaltkreisen erreicht. Die einzigen sequentiellen Datenflusspfade werden durch Operationen gebildet, die direkt von den Ergebnissen früherer Operationen abhängen. Alles andere kann parallel ausgeführt werden. Sie erhalten also maximal parallele sequentielle Datenflusspfade.

Die Einfachheit des Abra VM-Programmiermodells bedeutet auch, dass es sehr einfach ist, einen Software-Emulator (Interpreter) zu erstellen, der diese VM auf einem Standardprozessor ausführen kann. In diesem Fall gehen viele Möglichkeiten der Parallelverarbeitung verloren, aber es werden trotzdem korrekte Verarbeitungsergebnisse geliefert. Für einfache SCs, die nur spärlich aufgerufen werden, könnten Sie also auf eine software-emulierte Abra-VM zurückgreifen. Wenn Sie jedoch Hardware-Beschleunigung benötigen, müssen Sie die VM tatsächlich in einer Schaltung implementieren. An dieser Stelle stellen wir uns drei Ebenen der Hardware-Implementierung vor.

  1. Verwenden Sie vorhandene FPGAs, um die Abra-VM zu implementieren. Dies hat den Vorteil, dass Sie den VM-Schaltkreis nur einmal für jeden unterschiedlichen FPGA-Typ erstellen müssen und Sie anschließend beliebigen Abra-VM-Code auf einem solchen Gerät ausführen können. Allein diese Fähigkeit ist bahnbrechend. Derzeit benötigen Sie einen sehr leistungsfähigen PC, der lange Zeit läuft, um die Schaltung für ein Programm zu entwerfen, das auf einem bestimmten FPGA-Typ läuft. Und das ist etwas, das Sie jedes Mal tun müssen, wenn Sie etwas an Ihrem Programm ändern oder wenn Sie einen anderen FPGA-Typ anvisieren. Stattdessen layouten Sie jetzt die Schaltung für unsere Open Source Abra VM nur einmal für jeden FPGA-Typ. Danach können Sie das Programm, das Sie auf der VM ausführen möchten, einfach ändern, neu kompilieren, laden und auf jedem FPGA ausführen, der die Abra-VM ohne weitere Änderungen implementiert hat.
  2. Verwenden Sie ein ASIC, um die Abra-VM direkt zu implementieren. Das bedeutet, dass wir ein Open-Source-ASIC-Design für eine Abra-VM erstellen werden. Der Vorteil besteht darin, dass wir die Erstellung eines programmierbaren Bausteins vermeiden, der auf einem anderen (proprietären) programmierbaren Baustein (FPGA) läuft. Statt die Bausteine des FPGA zu programmieren, können wir direkt eine ASIC-Schaltung erstellen, die die Abra-VM implementiert. Das bedeutet nicht nur eine Geschwindigkeitssteigerung, sondern auch eine enorme Verringerung der erforderlichen Schaltungsmenge. Ein solcher Abra VM ASIC könnte leicht als Koprozessor für aktuelle Hardware oder als Hauptprozessor für bestimmte IoT-Anwendungen eingesetzt werden.
  3. Wenn Sie einen spezifischen Code für den Abra VM programmiert haben und überprüft haben, dass er korrekt funktioniert, könnten Sie auch einen ASIC erstellen, der die Operationen für diesen spezifischen Code als dedizierte Schaltung implementiert. Sie würden den allgemeinen Aspekt der Programmierbarkeit der VM-Implementierung verlieren, aber es gibt viele Anwendungsfälle, in denen Sie die einmal eingesetzte Hardware nie mehr ändern werden. Vor allem bei Sensoren und anderen Geräten, die Sie in Bereichen einsetzen, in denen Sie nach dem Einsatz nicht mehr so leicht darauf zugreifen können. Dies ist die IoT-Vision, auf die wir letztendlich hinarbeiten. Die Einfachheit der Operationen, aus denen sich der spezifische Programmcode zusammensetzt, macht die Erstellung eines ASICs relativ einfach. Und der generierte Schaltkreis erlaubt tatsächlich eine Reihe verrückter Optimierungen auf der Ebene der Logikgatter, da er keine programmierbaren Allzweck-Schaltkreise mehr verwendet.

Die wirklichen Verbesserungen des Abra-VM-Programmiermodells, wie der reduzierte Energiebedarf, die Aspekte des Datenflusses und die Möglichkeit des Wave-Pipelining werden diese letzte Implementierungsebene benötigen, um wirklich zu glänzen. Die allgemeineren programmierbaren Ebenen sind mit bestimmten Designeinschränkungen verbunden, die zusätzlichen „Overhead“ verursachen werden.

Ternäre Kodierung

Vielleicht ist Ihnen aufgefallen, dass in all dem oben Gesagten das Wort ternär noch nicht erwähnt wurde. Und natürlich wäre es möglich, diese gesamte Vision binär umzusetzen. Aber ein Teil der Qubic-Vision war schon immer die Fähigkeit, über die Grenzen der aktuellen Ausführungsmodelle hinauszugehen und die Hardware über das Mooresche Gesetz hinaus zu erweitern, das wohl ausgelaufen ist. Zu diesem Zweck haben wir immer die Vision eines ternären Ausführungsmodells gehabt. Auch wenn es noch keine nativen ternären Prozessoren gibt, kann dieses Modell dennoch einige Vorteile bieten. Die bemerkenswertesten unmittelbaren Vorteile sind: Datendichte und Berechnungsgeschwindigkeit.

Unser Programmiermodell arbeitet mit Schaltungen und daher mit der Informationseinheit der untersten Ebene. Bei binären Systemen wäre das nur ein bisschen. Aber das Abra-Datenflussmodell erfordert auch eine Darstellung der „Abwesenheit von Daten“ (Null), die für seinen Entscheidungslogikmechanismus entscheidend ist. Die normale Art und Weise, dies in binären Systemen darzustellen, wäre, ein zusätzliches Bit zu haben, um diesen Zustand anzuzeigen. Das bedeutet, dass jedes Informationsbit durch zwei Bits repräsentiert werden muss, um alle drei möglichen sich gegenseitig ausschließenden Zustände (0, 1 und null) kodieren zu können. Da aber 2 Bits 4 Zustände repräsentieren können, erscheint es nur natürlich, dies in vollem Umfang zu nutzen. Durch die Verwendung der ternären Kodierung benötigen wir immer noch nur 2 Bits, um die 4 sich gegenseitig ausschließenden Zustände (-, 0, 1 und null) darzustellen. Das bedeutet, dass wir Werte im Vergleich zur binären Kodierung, die sonst einen dieser 4 möglichen Zustände verschwenden würde, effizienter kodieren können. Im Vergleich zur ternären Kodierung benötigt die binäre Kodierung etwa 50% mehr 2-Bit-Informationseinheiten, um den gleichen Wertebereich darstellen zu können. Beispielsweise können 16 Bit Werte von -32768 bis +32767 kodieren, während nur 11 Trits bereits Werte von -88573 bis +88573 kodieren können.

Sobald Sie weniger Informationseinheiten zur Darstellung desselben Wertebereichs benötigen, sind auch bestimmte Berechnungen so viel schneller. Nehmen Sie zum Beispiel einen einfachen Ripple-Carry-Addierer. Um zwei Werte zu addieren, addiert er zwei entsprechende Informationseinheiten, was jedoch zu einem Übertrag auf die Addition der nächsten Einheit führen kann. Das heißt, wenn Sie 50% mehr Einheiten benötigen, um einen Wertebereich darzustellen, dauert die Ausführung einer solchen Addition ebenfalls 50% länger. Der Engpaß hierbei ist die Tatsache, daß jede Addition von der vorhergehenden Addition abhängt, da sie den Übertrag berücksichtigen muß. Die nächste Addition kann also erst dann erfolgen, wenn die vorhergehende vollständig ist und der Wert des Übertrags bekannt ist. Bringen Sie dies nun auf eine andere Ebene: die Multiplikation. Wenn Sie die einfache Methode verwenden, jede Einheit mit jeder Einheit zu multiplizieren, erhalten Sie eine zweidimensionale Abhängigkeit, was bedeutet, dass die Verarbeitungszeit bei Verwendung desselben Algorithmus mit binärer Kodierung 150% x 150% oder 225% der Zeit benötigt, die der Algorithmus bei Verwendung einer ternären Kodierung benötigen würde.

Die ternäre Kodierung, die wir für unsere Prototyp-FPGA-Implementierung verwendet haben, nennen wir 2b-Kodierung. Diese kodiert die 4 Zustände (-, 0, 1 und null) jeweils als (10, 11, 01 und 00). Wir nennen diese 2b-Kodierung, weil sie, wie oben diskutiert, 2 Bits pro Informationseinheit verwendet. Wir haben auch eine Alternative entwickelt, die wir 3b-Kodierung nennen, die 3 Bits pro Informationseinheit verwendet und die 4 Zustände jeweils als (100, 010, 001 und 000) kodiert. Die 3b-Kodierung mag vielleicht verschwenderischer erscheinen, aber sie hat eine Reihe interessanter Eigenschaften, die für die dritte Ebene der Hardware-Implementierung (direkter Code zur Schaltung) von größerer Bedeutung sind und in Zukunft noch eingehender untersucht werden sollen. Der Abra-Code ist völlig unabhängig von der verwendeten Kodierung. Die tatsächlich verwendete Kodierung wird letztlich von der spezifischen Implementierung der Abra-VM diktiert.

Sowohl die 2b- als auch die 3b-Kodierung verwenden alle Nullen, um den Nullzustand zu kodieren. Dies sollte dazu beitragen, den Energiebedarf der Hardware zu reduzieren, da der Null-Zustand der Standardzustand für alle Schaltkreise ist und normalerweise die meiste Energie darauf verwendet wird, den Zustand zu ändern. Abra ist so konzipiert, dass Entscheidungspfade so früh wie möglich zur Verwendung des Null-Zustands gezwungen werden, so dass keine Daten durch den größten Teil der Schaltung wandern und nicht verwendete Schaltungen ohne Umschalten im Standard-Null-Zustand bleiben können.

„Echte“ ternäre Hardware

Wie die Kodierung auf tatsächlich nativer ternärer Hardware aussehen wird, ist derzeit schwer vorstellbar, da wir noch kein funktionierendes ternäres System haben, mit dem wir arbeiten könnten. Eine interessante Idee, die aus der Qubic-Forschung hervorging, ist, dass man, da ternäre Prozessoren angeblich mit 3 Zuständen arbeiten, ein binäres Bit und den erforderlichen Nullzustand mit einem einzigen ternären Trit kodieren könnte. Dies würde bedeuten, dass ternäre Hardware unser Datenflussmodell direkt mit binärer Informationskodierung unterstützen kann. Anstatt also 2 Leitungen und alle zugehörigen Schaltkreise pro Leitung zu benötigen, um ein Bit und ein Null-Flag darzustellen, würden Sie nur eine einzige Leitung und die zugehörigen Schaltkreise benötigen, wodurch vielleicht sogar die Schaltungstechnik/Energie halbiert würde, die sonst für die gleiche binär codierte Verarbeitung in binärer Hardware erforderlich wäre. Ternäre Hardware ist derzeit in erster Linie eine Denksportaufgabe, aber es ist definitiv ein aufregendes Unterfangen für die Zukunft.

Hardware-Operationen

Das Abra-Programmiermodell hat ursprünglich 5 verschiedene explizite Operationen. 3 dieser Operationen reduzieren sich auf eine einfache Verdrahtung, sobald man sie auf Schaltungsebene implementiert. Sie sind nur notwendig, um Informationen als Trit-Vektoren zu gruppieren und weiterzugeben. Da aber auf der Schaltungsebene alles auf einzelnen Trits arbeitet, sind diese Trit-Vektoren meist konzeptionell. Daher erzwingen die Verkettungs- und Slicing-Operationen lediglich die korrekte Gruppierung von Informationen. Die Aufrufoperation ist nur vorhanden, um den Code effizient in einen Aufrufbaum zu reduzieren, aber sobald sie in einer Schaltung implementiert ist, erzwingt jede Aufrufoperation die Instantiierung des gesamten aufgerufenen Funktionsbaums in der Schaltung und verknüpft die Eingangs- und Ausgangs-Trit-Vektoren mit ihren Quell- und Zielvektoren.

Damit bleiben nur noch 2 Operationen übrig, die tatsächlich als logische Schaltung implementiert werden. Die erste ist die ternäre Lookup-Operation, die 3 Eingangstrits nimmt und einen einzelnen Trit gemäß der entsprechenden Lookup-Tabelle ausgibt. Die zweite ist die Merge-Operation, die getrennte Datenfluss-Eingänge zu einem einzigen Ausgang kombiniert und entweder als eine sehr spezielle Lookup-Operation oder durch Verwendung einfacher ODER-Gatter implementiert werden kann. Nur eine Eingabe darf ungleich Null sein und wird zur Ausgabe. Die Sprache Qupla, die den Abra-Code generiert, stellt sicher, dass nur ein Pfad ungleich Null sein kann. Alle anderen Werkzeuge, die direkt Abrac-Code erzeugen würden, sind erforderlich, um dies sicherzustellen.

Der FPGA-Konzeptnachweis

Um das Programmiermodell auf FPGA zu erleichtern, haben wir den FPGA so programmiert, dass er eine Bank von so genannten QLUTs (Qubic Look-Up Tables) bereitstellt. Jeder QLUT nimmt drei 2b-kodierte Trits als Eingabe und gibt dann einen weiteren 2b-kodierten Trit über eine konfigurierbare Nachschlagetabelle aus. Fusionen werden innerhalb der QLUTs durch Setzen eines speziellen Konfigurationsbits implementiert, das sie veranlasst, eine vordefinierte Lookup-Operation mit leicht unterschiedlicher Semantik zu verwenden.

Natürlich enthält der FPGA auch die zusätzliche Konfigurationslogik, die notwendig ist, um jede Eingangsoperation mit jeder Ausgangsoperation verbinden zu können. Diese Logik kann durch eine spezielle binäre Konfigurationsdatei konfiguriert werden, die leicht direkt aus dem auszuführenden VM-Code generiert werden kann. Der Code wird derzeit „on the fly“ konvertiert, wenn er an den FPGA gesendet wird. Sie enthält die Konfigurationsdaten für jedes einzelne QLUT und die Konfigurationsdaten für die Verbindungen zwischen den QLUTs.

Die QLUTs wurden bereits getestet, indem die gesamte Qupla-Testsuite im Emulator ausgeführt wurde, während eine bestimmte Funktion hardwarebeschleunigt wurde. Wir erlauben dem Benutzer, eine Funktion als hardwarebeschleunigt zu markieren, und die Qupla-Umgebung lädt automatisch die Konfigurationsdaten für diese Funktion in den FPGA. Wenn der Emulator dann den Emulator ausführt, übergibt er jedes Mal, wenn er auf diese spezifische Funktion trifft, die Eingangsdaten der Funktion an das FPGA und verwendet die resultierenden Ausgangsdaten, anstatt das Ergebnis für diese Funktion vom Emulator berechnen zu lassen. Wir haben mehrere repräsentative Funktionen auf diese Weise getestet und freuen uns, berichten zu können, dass dies perfekt funktioniert.

Als Nächstes benötigen wir eine FPGA-Version des Qubic Supervisors, d.h. der Entität, die Eingangsdatenereignisse an den korrekten VM-Code sendet und die berechneten Ergebnisse weiterleitet. Um zu vermeiden, dass wir ein Miniaturbetriebssystem schreiben müssen, werden wir zunächst eine einfache Embedded-Linux-Version verwenden, die auf einer CPU laufen kann, die auf dem FPGA eingebettet ist. Auf diese Weise können wir bestimmte Funktionen out of the box nutzen, ohne sie selbst entwickeln zu müssen. Wir haben es geschafft, dieses Linux bereits auf dem FPGA zu booten und es zu benutzen, um die Kommunikation zwischen dem Emulator und dem FPGA über ein einfaches Socket-Protokoll abzuwickeln. Der nächste Schritt wird die Implementierung des Supervisors und einiger zusätzlicher Glue-Code sein, um stattdessen die Kommunikation mit der Außenwelt über HTTP zu ermöglichen.

Der nächste Schritt wäre die Implementierung eines HTTP-Listeners auf dem Embedded-Linux des FPGAs, der auf zwei Arten von Anfragen reagieren kann. Der erste Anfragetyp kann verwendet werden, um die Konfigurationsdatei auf den FPGA zu übertragen, und dieser wird dann zur Konfiguration des Programmiermodells, zur Einrichtung einer HTTP-Callback-Adresse und zur Initialisierung des Supervisors verwendet. Der zweite Anforderungstyp ist eine Eingabedatenanforderung, die verwendet werden kann, um die Ausführung einer Funktion mit den vom Supervisor bereitgestellten Eingabedaten auszulösen. Nach der Berechnung des Ergebnisses sendet der Supervisor die resultierenden Ausgabedaten asynchron an die HTTP-Callback-Adresse.

Beachten Sie, dass dies bedeutet, dass der anfängliche End-to-End-Konzeptnachweis (Qupla-to-FPGA, der ursprünglich für Ende Januar 2020 geplant war) noch nicht die volle Supervisor-Funktionalität haben wird, sondern nur in der Lage sein wird, eine einzige beliebige Funktion auf dem FPGA einzurichten und aufzurufen und das Ergebnis zurückzugeben. Das Laden und Aufrufen mehrerer Funktionen und komplexere Planung durch EEE wird der nächste Schritt für die Implementierung im Supervisor-Code sein.

Auf der Softwareseite ist der Qupla-Compiler jetzt in der Lage, eine spezifische Version des Abra-Codes zu erzeugen, die leichter eine 1-zu-1-Konvertierung in die binäre Konfigurationsdatei ermöglicht, indem alle Verkettungs-, Slice- und Aufrufoperationen eliminiert werden. Wir haben überprüft, dass der resultierende transformierte Code immer noch korrekt funktioniert, indem wir die Testsuite mit diesem Code im Emulator ausgeführt haben. Der Emulator selbst ist nun in der Lage, über die Socket-Schnittstelle eine Schnittstelle zum FPGA herzustellen. Er sendet die generierte Konfigurationsdatei an das FPGA und ruft diese Funktion bei Bedarf auf. In Zukunft wird der Qupla-Supervisor in der Lage sein, Ereignisse über die HTTP-Schnittstelle zum und vom FPGA zu senden.

Erste Lehren aus dem PoC

Bis jetzt funktioniert alles wie vorgesehen. Wir haben ein völlig neues Verarbeitungsmodell geschaffen, das jede Art von allgemeiner Verarbeitung durchführen kann. Das Modell behandelt die RAM-Speicherung genauso wie jede andere Art von E/A, d.h. es liegt außerhalb des Geltungsbereichs des Abra-Codes und wird an Entitäten weitergegeben, die Daten für uns mit Hilfe von EEE speichern/abrufen können. Dies erfordert eine andere Art der Problembetrachtung, und es wird wichtig sein, die resultierende Komplexität zu bewerten und/oder zu sehen, ob es eine Möglichkeit gibt, die Komplexität in Qupla-Sprachkonstrukten zu verbergen, oder ob eine noch höhere Computersprache erforderlich ist. So wurde beispielsweise bereits die Notwendigkeit einer Art von Schleifenkonstrukt gesehen.

Zwei unmittelbare Hürden zeichnen sich derzeit ab und erfordern eine Lösung:

  1. Der derzeitige Ressourcenbedarf der QLEs auf dem ausgewählten FPGA (DE10-Nano) begrenzt uns auf insgesamt nur 512 QLEs. Dies mag ein wenig optimiert werden, aber wir erwarten nicht, dass sich dieser Bedarf auf mehr als etwa das Doppelte erhöht. Natürlich könnten wir einen größeren, teureren FPGA auswählen, aber für das Prototyping wollen wir es einfach und erschwinglich halten für Leute, die unsere Anstrengungen verdoppeln und damit herumspielen möchten. Eine direkte Folge davon ist, dass wir nur einige kleinere Funktionen auf den FPGA laden können, und der Kommunikations-Overhead beim Aufruf dieser Funktionen überwiegt meist den Verarbeitungsgewinn. Das war zu erwarten, und wir hoffen, dass wir, sobald wir zum nächsten Schritt übergehen, einem ASIC Abra VM, Größenordnungen darüber hinaus gehen können.
  2. Die Instantiierung von Funktionsaufrufen wird sehr schnell unerschwinglich. Aufgrund der „Call-Tree-Natur“ des Codes hat die Expansion eines solchen Aufrufbaums ein exponentielles Wachstum. Wenn X dreimal Y aufruft, was wiederum viermal Z aufruft, erhalten Sie drei vollständige Y-Instanziierungen, die 3×4 oder 12 vollständige Z-Instanziierungen verursachen. Sie können sehen, wie schnell dies eskaliert. Die Lösung dieses Problems wird unser Hauptaugenmerk sein müssen. Derzeit schwirren einige Ideen herum, aber wir haben uns noch nicht mit allen Konsequenzen für das Datenflussmodell befasst.

Übrigens leidet der Abra-Emulator nicht unter diesen Problemen, da er die Funktionsinstantiierung durch einen gewöhnlichen stapelbasierten Funktionsaufrufmechanismus emuliert und die Lookup-Tabellen in einem von den Lookup-Anweisungen getrennten Speicher ablegt. Heutige Gigabyte RAM-Größen würden Millionen von Abra VM-Befehlen ohne Probleme ermöglichen.

Schlussfolgerung

Nach einem langen Weg mit vielen unvorhergesehenen Hürden haben wir bewiesen, dass das Abra-Datenflussprogrammiermodell durchgängig funktioniert, von der Programmiersprache Qupla bis zur Ausführung des generierten Codes auf dedizierter FPGA-Hardware. Wir laden alle ein, mit dem Qupla-Repository herumzuspielen und zu sehen, was Qupla kann und wie es im Emulator läuft. Diejenigen, die sich mehr für Hardware interessieren, können mit dem Qubic HDL-Repository herumspielen und tatsächlich Code auf einem DE10-Nano ausführen, so wie wir es tun, oder sogar den Code an Ihr eigenes bevorzugtes FPGA-System anpassen.

Eine neue Richtung für intelligente Verträge auf IOTA

Auch wenn diese Arbeit die Vision hinter Qubic beweist und einen großen Schritt nach vorn darstellt, sind noch weitere Fragen zu lösen und es sind noch erhebliche Entwicklungsinvestitionen erforderlich, um Qubic produktionsreif zu machen. Unsere umfangreiche Arbeit an Qubic hat viel wertvolle Forschung und Entwicklung hervorgebracht und bildet die Grundlage für unseren weiteren Ansatz. Dementsprechend hat die IOTA-Stiftung die Entscheidung getroffen, die Entwicklung von Qubic einzustellen und unseren Schwerpunkt speziell auf die Ebene der intelligenten Verträge zu legen.

Der Hauptgrund für diese Entscheidung besteht darin, dass IOTA mit einer neuartigen intelligenten Vertragslösung, die in Verbindung mit der Coordicide-Knotenpunkt-Software arbeitet, schneller auf den Markt kommen kann. Am Ende verfügen wir über ein komplettes System – bereit für eine breitere und schnellere Einführung.

IOTA Smart Contracts ist das, was wir unsere intelligente Layer-2-Vertragslösung nennen. Sie ist aus der in diesem Beitrag beschriebenen Arbeit hervorgegangen und wurde von Grund auf neu konzipiert. Mit IOTA Smart Contracts wollen wir eine Vision für intelligente Verträge verfolgen, die skalierbar sind und niedrige Transaktionskosten haben.

Wir arbeiten derzeit an einer Alpha-Version von IOTA Smart Contracts durch die GoShimmer-Implementierung, und wir werden in Kürze weitere Informationen über diesen neuen Weg veröffentlichen. Wenn die Alpha-Version fertig ist, wird sie von einer Reihe einfacher intelligenter Vertrags-PoCs begleitet werden, um Gemeinschaftsentwickler auf den Weg zu bringen und zu demonstrieren, was möglich ist, um eine neue Ära von Anwendungen auf der Grundlage von IOTA anzustoßen.

Fühlen Sie sich frei, unser Ingenieursteam direkt in den Smart Contract-Kanälen über den IOTA-Discord zu erreichen und Fragen zu diesem neuen Weg, den wir beschreiten, zu stellen.

Spenden: OOXKDDPERSTNHSCQGYDYEWGDRLQEUZCIBDLYCDKSKIHGWAG9WFPVDVSRAUN9GDUOJ9INP9LMSMHYKNLNCOKMGFBZFA