Innerhalb eines Universa Smart Contract

In den letzten Wochen haben Sie möglicherweise die einführenden Artikel über einige interne Architekturen der Universa Blockchain und die Überarbeitungen intelligenter Verträge gelesen. Wie Sie jetzt wissen, werden Transaktionen nicht zu linearen Blöcken zu einer Kette hinzugefügt, sondern jede Transaktion ist eine Überarbeitung eines intelligenten Vertrags in einem Schwarm gerichteter azyklischer Diagramme.

Aber was ist eigentlich ein intelligenter Vertrag und wie sieht seine Architektur aus?

Innerhalb eines Smart Contracts

Erstens ist die Terminologie „Smart Contract“ weit verbreitet, wird aber auch nicht richtig angewendet. Es klingt so, als ob es sich um einen komplexen Vertrag handelt, der auf intelligente Weise innerhalb der Blockchain ausgeführt wird.

In der Universa Blockchain ist jede Transaktion ein (neuer) Smart Contract. Und es kann ein Vertrag sein, aber es kann auch ein Dokument, ein digitaler Prozess oder eine Vereinbarung sein. Wir können alle diese Vorgänge als „smart documents (intelligente Dokumente)“, „smart processes (intelligente Prozesse)“ oder was auch immer Sie möchten bezeichnen.

Wenn wir uns einen Smart Contract in der Universa Blockchain genauer ansehen, sehen wir, dass er drei Abschnitte hat:

  1. Definition
  2. Status
  3. Transaktion

Definition

Der erste Teil der Struktur enthält Daten, die bei jeder Überarbeitung dieses Vertrags unveränderlich sein müssen. Wenn eine Transaktion ausgeführt wird, müssen diese Daten unveränderlich sein. Eine Änderung ist nicht möglich.

Wenn die Daten geändert werden, verbieten die Universa-Knoten die Registrierung der Transaktion. Schließlich vergleichen die Knoten diese Daten der neuen Revision mit den vorherigen.

Status

Der Status enthält Daten, die bei der Überarbeitung dieses Vertrages geändert werden können. Die besonderen Details darüber, was und wie es geändert werden kann, können in definition.permissions angegeben werden. Parameter, die in der Definition oder im Status festgelegt sind, sind beispielsweise „Ersteller“, „Aussteller“ oder „Eigentümer“.

Transaktion

Der dritte Teil der Struktur enthält Daten, die nicht (notwendigerweise) im Vertrag enthalten sind, sondern nur an die jeweilige Transaktion gebunden sind. Beispiel: Wenn Sie einen Händler bezahlen, können Sie einen Datensatz über den Zahlungsgrund / Rechnungscode in die Transaktionsdaten aufnehmen.

Dies sind die drei Bereiche innerhalb eines Smart Contracts, die alle Daten zu einer bestimmten Transaktion enthalten. Wir nennen all dies „nur Daten“, aber worum kann es bei diesen Daten gehen?

Universa Token Vertrag

Nehmen wir als Beispiel den Ursprungsvertrag des Universa Tokens (UTN). Sie können diesen selbst im Universaexplorer überprüfen. Es zeigt allgemeine Daten / Informationen zu den Rollen und dem Eigentümer.

Sie können auch die Definitionsdaten lesen (die während der Überarbeitungen unverändert bleiben sollten). Unabhängig davon, welche Vertragsrevision Sie schulden, werden Ihnen immer die folgenden Daten angezeigt:

Der zweite Abschnitt sind die Zustandsdaten, die die Versorgungsmenge des UTN zeigen. Dies kann verwirrend sein, da Sie erwarten würden, dass das Angebot fest oder unveränderlich ist.

Bei einer Transaktion (oder Überarbeitung dieses Stammvertrags) eines Tokens werden jedoch die Split-Join-Funktionen verwendet. Dies ist einer der Anwendungsfälle eines Smart Contracts. Die Split-Join-Operation für einen Vertrag wird hauptsächlich für Coin(/Münz)verträge verwendet.

Einfach ausgedrückt besteht der Stammvertrag des UTN-Tokens aus der Menge von 4 997 891 952 Token.

Aufgrund der dynamisch flexiblen Menge der UTN-UTNP-Swaps verfügt Universa nicht über die genauen Angaben zu den im Umlauf befindlichen Salden und Beträgen von UTNP. Dies kann jedoch verfolgt werden, aber ein solches Tool ist noch nicht erstellt.

Wenn aus diesem Vertrag eine Zahlung ausgeführt wird, wird dieser Betrag auf, sagen wir mal 1 997 891 952 und 3 000 000 000 aufgeteilt. Dies ist möglich, weil dieser Betrag in den Zustandsdaten des Vertrags enthalten ist (daher kann er angepasst werden).

Inzwischen haben wir zwei Verträge (Revisionen) desselben Stammvertrags, die beide ihre eigene Anzahl von Token haben (oder haben). Für jede Zahlung oder Transaktion mit diesem Token wird der Betrag aufgeteilt, gesendet und anschließend auf der Seite des Empfängers zusammengeführt (oder verbunden). Weitere Informationen darüber finden Sie auf der Knowledge-Based Website.

Übrigens ist die Ursprungs-ID (die ID des Stammvertrags für ein Token) die wichtigste in der Ideologie für Token mit vorgegebener Menge.

Wie Sie vielleicht wissen, sind in der Welt der Blockchain die Begriffe veränderlich und unveränderlich sehr wichtig. Denken Sie an die Gesamtmenge, den Eigentümer und den Emittenten eines Vertrags. Mit den beiden Abschnitten Definition und Status kann dies für jeden einzelnen Anwendungsfall garantiert werden.

Berechtigungen und Rollen

Es gibt auch Methoden, um anzugeben, wer genau die Berechtigungen eines Vertrags besitzt. Dies kann eine SimpleRole (angegeben mit nur einem privaten Schlüssel), ein RoleLink (der sich auf eine andere Rolle bezieht, z. B. „Eigentümer“) oder eine ListRole (die sich auf eine Liste mehrerer anderer Rollen bezieht) sein.

Das ist in der Tat sehr interessant. Weil es möglich ist, eine Rolle wie „eine Liste mit 5 Personen, von denen ALLE das Dokument unterschreiben müssen“ zu erstellen. Oder eine Rolle wie „Liste von 6 Personen und IRGENDEINER von ihnen muss das Dokument unterschreiben“ zu erstellen. Es ist sogar möglich, eine 15-aus-6-Konstruktion zu erstellen. Dies erhöht die Sicherheit von Operationen für z.B. Cold Storage Möglichkeiten oder Mehrparteienentscheidungen.

In der Praxis kann jede Rolle neben der grundlegenden Definition der Rolle sogar einige zusätzliche Verweise enthalten, um zu überprüfen und zusätzliche benutzerdefinierte Überprüfungslogik hinzuzufügen. Diese Referenzen können entweder in der Definition, im Status oder in der Transaktion definiert werden. Dies kann ein Verweis auf einen Namen, eine Transaktions-ID, Felder oder ein signiert_von sein.

Es gibt viele Möglichkeiten, die Daten, Rollen und Berechtigungen eines intelligenten Vertrags / Dokuments anzugeben. Sobald er registriert ist, kann der Smart-Vertrag verwendet / verifiziert / ausgeführt werden und wird für jede Transaktion überarbeitet. Dies führt zu unterschiedlichen Zuständen für jede Revision, die der DAG hinzugefügt wird.

Zustand

Kehren wir als Beispiel zum UTN-Vertrag zurück. Der Status des Elements ist UNDEFINED.

Wichtig: Dies liegt daran, dass die Split-Join-Funktion ausgeführt wird und nicht daran, dass das UTN-Token nicht mehr funktioniert oder nicht mehr vorhanden ist.

Es gibt mehrere Zustände für die Smart Contracts, basierend auf dem Konsens des Netzwerks.

  1. APPROVED, der primäre „erfolgreiche“ Status für den Vertrag
  2. LOCKED, der Konsens über den Status ist noch positiv, aber der Vertrag ist bereits während der Vorbereitung zur Archivierung gesperrt.

Es ist auch möglich, dass zwischen den Knoten ein negativer Konsens besteht:

  1. DECLINED
  2. REVOKED

Zuletzt gibt es vier Optionen für intelligente Verträge (oder Transaktionen), bei denen kein Konsens gefunden wird:

  1. UNDEFINED, weil er zum Beispiel schon vor langer Zeit widerrufen wurde.
  2. PENDING
  3. DISCARDED
  4. LOCKED_FOR_CREATION

Weitere Informationen zu diesen Status finden Sie auf der Knowledge-Based Website. Im nächsten Artikel werden wir uns eingehender mit den Anwendungsfällen dieser intelligenten Dokumente (Smart Documents) befassen. Bleiben Sie dran.

Help translating this post to Englisch Französisch Niederländisch Italienisch Spanisch Kroatisch Russisch. Contact @starnold to participate!

Related posts

Identität von Universa (und „Ricardian“) Smart Contracts

Arnold

Alexander trifft Amsterdam 2020

Arnold

Innerhalb des Universa DAG

Arnold

Leave a Comment