Framework: Analyse von DLT-Systemen

Diese Arbeit zielt darauf ab festzustellen, ob das analysierte Objekt ein DLT-System ist. Die erzielten Ergebnisse eignen sich gut für die vergleichende Analyse verschiedener Projekte, die von der Managementstruktur bis zur Definition von Links reichen, auf die sich Transaktionen beziehen.

Die Distributed-Ledger-Technologie ist eine Technologie zum Speichern von Informationen, deren Hauptmerkmale die gemeinsame Nutzung und Synchronisierung digitaler Daten gemäß dem Konsensalgorithmus, die geografische Verteilung gleichwertiger Kopien an verschiedenen Orten auf der ganzen Welt und das Fehlen eines zentralen Administrators sind.

Technische Analyse

Protokollebene

Genesis

Protokollebene bezieht sich auf die Prozesse, die entwickelt und ausgeführt werden müssen, bevor das Netzwerk gestartet wird.

Abhängigkeit von anderen Netzwerken.

Die Abhängigkeit von anderen Protokollen hängt von den Grenzen des analysierten Projekts ab. Dies bestimmt, ob das System als unabhängiges System betrieben werden kann (um autark zu sein) oder von einem anderen Netzwerk abhängig ist.

Tabelle 1. Abhängigkeit von anderen Systemen



Programmcode

Der Code kann auf einem vorhandenen Framework basieren oder von Grund auf neu geschrieben werden. Die beliebtesten Frameworks sind Codebasen aus Open Source-Systemen (Bitcoin / Ethereum). Es gibt auch Closed-Source-Datenbanken für geschlossene Plattformen, die von Projekten wie Digital Asset / Clearmatics und SETL bereitgestellt werden.

Tabelle 2. Programmcode



Regeln definieren

Die Einführung von Regeln bezieht sich auf die Definition eines Regelsatzes, nach dem ein DLT-System arbeiten soll. Dieser Prozess kann von verschiedenen Teilnehmern durchgeführt werden und ist für ein bestimmtes DLT-System individuell.

Protokollaktualisierung

Protokollaktualisierungen gelten für vorhandene Prozesse, mit denen Sie Systemregeln ändern können. Das Aktualisieren des Protokolls kann die Beseitigung technischer Fehler (Bugs), die Verbesserung der Sicherheit und Funktionalität des Systems sowie die Erweiterung oder Einschränkung bestehender Protokollregeln umfassen.

Protokollverwaltung

Protokollverwaltung bezieht sich auf eine Reihe von Entscheidungsprozessen, mit denen Sie ein Protokoll ordnungsgemäß und legal ändern können. Dies ist eine Teilmenge des umfassenderen Projektmanagements, die eine vollständige Reihe von Prozessen und Normen umfasst, die Koordination und Maßnahmen beschreiben und definieren, die jedoch nicht formal in das DLT-System integriert werden können.

Ein wichtiges Element jeder vorgeschlagenen Änderung des Protokolls ist die Art und Weise, wie es angenommen und ratifiziert wird - oder mit anderen Worten, wie die Legitimität auf Vorschlag der Netzwerkteilnehmer gewährleistet wird. Da Legitimität in diesem Zusammenhang ein soziales Konzept ist, erscheint es vernünftig, einige der möglichen „gesellschaftspolitischen“ Beziehungen zu identifizieren, die in DLT-Systemen zu finden sind.

Tabelle 3. Protokollverwaltung



Das Protokollmanagement hat viele Formen und ist oft unklar. Anfänglich sind DLT-Systeme durch anarchistische Macht (frei) gekennzeichnet, es gibt keine Unternehmen oder Personengruppen, die für Entscheidungen verantwortlich sind. Vor allem ähneln sie Open-Source-Verkehrsmanagementprozessen. Ein Beispiel für eine Diskussion über Protokolländerungen kann die Kommunikation von Entwicklern in einem Chat / GitHub / einer Konferenz sein. Unter diktatorischen Bedingungen kann der Prozess der Diskussion von Änderungen genau der gleiche sein, aber die endgültige Entscheidung wird von einer Person getroffen. In einigen Fällen kann ein Protokollverwaltungsformular von mehr als einem Kartentyp definiert werden. Beispielsweise fungiert die EOS-Blockchain als Zusammenschluss von Blockherstellern, die von Benutzern ausgewählt werden, die ein EOS-Asset besitzen. Das Gewicht der Abstimmung wird durch die Anzahl der an der Adresse gespeicherten Token bestimmt. Diese Art von Regierung teilt das Protokoll in zwei Parteien: die "Elite" und "normale" Benutzer, die die Merkmale eines hierarchischen Systems annehmen: Föderation, Demokratie und Plutokratie.

On-Chain-Management bedeutet die Einbeziehung von Managementfunktionen auf Datenebene. Ziel ist es, die Governance zu formalisieren, wodurch die Legitimität erhöht und eine Netzwerkfragmentierung aufgrund von Streitigkeiten oder inkonsistenten Protokollaktualisierungen vermieden wird. Für DLT-Systeme wurde eine Reihe von Abstimmungsschemata in der Kette entwickelt, die von einem Community-Stimmungsbarometer bis zu Referenden reichen. On-Chain-Management-Funktionen sind jedoch in der Regel nur eine Ergänzung zu anderen Managementformen.

Protokolländerung

Der eigentliche Prozess der Aktualisierung des Protokolls impliziert:

1. Aktualisieren des Codes auf GitHub, wenn es sich um ein Open-Source-Projekt handelt;
2. Client-Update, wenn es sich um ein Closed-Source-Protokoll handelt;
3. Clients, die am alten Programmcode arbeiten, können als irrelevant und auf die schwarze Liste gesetzt betrachtet werden.
4. Clients, die mit dem alten Programmcode ausgeführt werden, bilden eine Abzweigung, die zur Erstellung einer alternativen Version des Protokolls führt.

Tabelle 4. Formular zur Protokolländerung



Verschiedene DLT-Systeme verwenden unterschiedliche Methoden, um das Netzwerk zu aktualisieren. Beispielsweise nimmt Ethereum Spenden zur Finanzierung der Entwicklung entgegen und aktualisiert das Netzwerk mithilfe von Software von Entwicklern, die durch Zuschüsse finanziert werden.

Netzwerkebene

Das DLT-Protokollnetzwerk ist ein direktes Ergebnis der Implementierung von Protokollregeln. Das Netzwerk besteht aus der koordinierten Arbeit von Teilnehmern und Prozessen, die einem technologischen Standard (Protokoll) entsprechen und aktiv am Austausch von Daten und Informationen über bestimmte Kommunikationskanäle beteiligt sind.

Kommunikationsprozess

Der Prozess der Datenübertragung zwischen Teilnehmern in einem DLT-System.

Netzwerkzugriff

Der Zugriff auf das Netzwerk impliziert die Möglichkeit, eine Verbindung zum Protokoll herzustellen. Er kann begrenzt oder unbegrenzt sein.

• Unbegrenzter Zugriff - Jeder Benutzer kann jederzeit frei verbinden / trennen.
• Eingeschränkter Zugriff - Nur bestimmte Benutzer können eine Verbindung zum Netzwerk herstellen. Dies wird normalerweise von der angegebenen Entität gesteuert.

Systeme mit uneingeschränktem Zugriff unterliegen in der Regel keinen Einschränkungen hinsichtlich der Teilnehmerzahl, während geschlossene Netzwerke eine begrenzte Teilnehmerzahl festlegen können.

Normalerweise erhalten die Teilnehmer direkten Zugriff auf das Netzwerk, indem sie vollständige Knoten starten: Sie gelten als „Elite“ mit einer Vielzahl von Rechten, da sie Datensatzdaten senden / überprüfen und übertragen können. Netzwerkteilnehmer können auch indirekten Zugriff auf das Netzwerk erhalten, indem sie „Light Clients“ ausführen, die Daten von vollständigen Knoten anfordern, indem sie eine Verbindung über einen speziellen Dienst (API) herstellen.

Tabelle 5. Netzwerkzugriffsformular



Je offener das System ist, desto anfälliger ist es in der Regel für Angriffe. Insbesondere sind diese Systeme für den Sibyl-Angriff anfällig, wenn der Angreifer viele gefälschte Identitäten erstellt, um den Einfluss auf das Netzwerk zu erhöhen.

Der Sibyl-Angriff ist eine Art von Angriff, wenn ein Angreifer Zugriff erhält oder eine Änderung im Protokoll verbirgt, wodurch viele falsche Identitäten entstehen.

Da die Identifizierung eine exogene (dh „echte“) Eigenschaft ist, kann das DLT-System diese Angriffe nicht verhindern. Es muss sich auf externe Teilnehmer (Zertifizierungssystem) oder Mechanismen stützen, die die Wahrscheinlichkeit eines Angriffs verringern (PoW / PoS).

Daten senden

Bei der Datenübertragung werden Daten an verbundene Knoten verteilt. Daten können roh / unformatiert oder auf ein bestimmtes Format standardisiert sein (z. B. in Form einer Transaktion oder eines Datensatzes). Daten können an jeden Knoten (universelle Diffusion) oder nur an eine bestimmte Teilmenge von Knoten (Mehrkanaldiffusion) übertragen werden. Im letzteren Fall ist die Verbreitung von Daten in der Regel auf die Teilnehmer der Transaktion beschränkt. Auf diese Weise können Sie einen "Kanal" für die Datenübertragung erstellen. Dies bedeutet normalerweise Sharding / Lightning Network.

Frühe DLT-Systeme (z. B. Bitcoin, Litecoin) verwenden ein universelles Datenverteilungsmodell, das nach wie vor die beliebteste Datenverteilungsmethode ist.

Um Anonymität und Datenschutz für Unternehmen zu gewährleisten, verfügen spätere Systeme über ein Mehrkanal-Diffusionsmodell (z. B. Hyperledger Fabric, Corda). Andere Systeme wie Cosmos fungieren als Hubs, sodass unabhängige DLT-Systeme über Sharding miteinander verbunden werden können.

Tabelle 6. Datenübermittlungsformular



Ein Beispiel für die Mehrkanaldatenverbreitung ist, dass nicht alle Netzwerkteilnehmer am Konsens über den Status des Kanals teilnehmen müssen: Nur Kanalteilnehmer müssen Konsistenz über die in diesem Kanal gespeicherten Daten erreichen („lokaler“ Konsens). Dies unterscheidet sich erheblich von Systemen mit globaler Datendiffusion, da jeder einzelne Knoten zu einem Konsens über den globalen Zustand des Systems gelangen muss („globaler“ Konsens). Die Unfähigkeit, einen Konsens einiger Knoten zu erzielen, kann zu deren Trennung oder zur Schaffung einer Gabelung führen.

Transaktionserstellung

Der Transaktionserstellungsprozess enthält eine Reihe von Anweisungen, die ausgeführt werden, nachdem eine Transaktion zum Netzwerk hinzugefügt wurde. Das Erstellen von Transaktionen kann unbegrenzt (d. H. Für alle zugänglich) oder auf einige Teilnehmer beschränkt sein. Transaktionen werden von Benutzern erstellt, die die Nachricht mit ihrem privaten Schlüssel signieren. Für Benutzer stehen verschiedene Schnittstellen zum Erstellen und Senden von Transaktionen an das Netzwerk zur Verfügung (z. B. PCs und mobile Geldbörsen).

Transaktionsverarbeitung

Die Transaktionsverarbeitung beschreibt die Aktionen, die erforderlich sind, um eine unbestätigte Transaktion zur Liste der bestätigten Transaktionen hinzuzufügen. Eine Transaktion wird nach dem Hinzufügen ("bestätigt") zur Liste als (vorläufig) gültig angesehen, was zur Ausführung von in die Transaktion eingebetteten Anweisungen führt. Eine Bestätigung allein reicht jedoch nicht aus, um diese Transaktion zur Grundlage für nachfolgende Vorgänge zu machen. bevor Transaktionsausgaben vom System verwendet werden können.

Abbildung 1. Transaktionsverarbeitung in einem DLT-System



Aufzeichnungen folgen einem bestimmten Konsensalgorithmus, der im DLT-System verwendet wird. Dies umfasst das Bestimmen, ob der vorgeschlagene Datensatz gültig ist, das Ablehnen ungültiger Einträge (z. B. fehlerhafte oder inkompatible Einträge) und die Auswahl zwischen verschiedenen, aber gleichermaßen gültigen Einträgen.

Rekordkandidat

Datensätze, die in Zukunft in die Liste der bestätigten Transaktionen verschoben werden können, werden von den Erstellern der Blöcke gesendet, die sie aus der Liste der nicht bestätigten Transaktionen auswählen und zu Kandidaten für das Schreiben in die Liste der bestätigten Datensätze kombinieren. Es gibt zwei Eigenschaften, die das Recht zum Senden eines Datensatzes und dessen zukünftige Aufnahme in die Liste der bestätigten Datensätze bestimmen.

Tabelle 7. Formulare aufzeichnen



Da Datensätze einem Konsens unterliegen, müssen sie den Protokollregeln entsprechen. Erstens müssen sie korrekt formatiert sein und dürfen keine ungültigen oder ungültigen Transaktionen enthalten. Darüber hinaus sollte jeder Eintrag einen Link / Zeiger auf den vorherigen Eintrag enthalten und bei Bedarf PoW oder eine andere Methode verwenden, die es schwierig macht, einen Sibyl-Angriff durchzuführen.

Der Konsensalgorithmus kann nach seiner Komplexität (elektrische / monetäre Kosten) klassifiziert werden. Algorithmen mit unbegrenzter Komplexität werden an den Ressourcen gemessen, die zur Erzielung eines Konsenses erforderlich sind. Bei der Berechnung von PoW Bitcoin steigt beispielsweise die Schwierigkeit, die richtige Lösung zu finden, mit zunehmender Komplexität der Hashing-Daten. Im Gegenteil, andere Algorithmen (z. B. die Aufgabe Byzantinische Generäle / BFT) erfordern keine signifikanten Rechenkosten und sind nur begrenzt komplex.

In offenen Systemen sollte ein Algorithmus bereitgestellt werden, der die Wahrscheinlichkeit eines Sybil-Angriffs verringert. Private (geschlossene) Systeme überprüfen jeden Teilnehmer, bevor sie Zugriff auf die Netzwerkverbindung erhalten, wodurch die Möglichkeit eines Angriffs verhindert wird. In geschlossenen Systemen neigt eine Gruppe von Knoten dazu, einen Knoten auszuwählen, der Blöcke erstellt.

Konfliktlösung

Ein Konflikt kann aus mehreren Gründen verursacht werden:

1. Die Teilnehmer sind sich nicht einig, welche Version des Protokolls relevant ist.
2. Die Teilnehmer sind sich nicht einig über verifizierte Transaktionen.

Im Falle einer Situation des ersten Punkts im Bitcoin-Netzwerk wählt das Netzwerk die längste Blockkette als gültig aus und ignoriert die kürzere. In Tezos wird die Gültigkeit eines Blocks mit einem anderen „Blockgewicht“ bestimmt. Das Gewicht ist hier die Anzahl der „Genehmigungen“ der Validatoren, die er zufällig von den Stakern erhält.

Jeder Konsensalgorithmus bringt eine Reihe von Kompromissen mit sich

Tabelle 7. Motivationsformen für die Transaktionsverarbeitung



Validierung

Die Validierung bezieht sich auf eine Reihe von Prozessen, die erforderlich sind, um sicherzustellen, dass die Probanden in Bezug auf eine genehmigte Reihe von Aufzeichnungen unabhängig voneinander zu demselben Ergebnis kommen. Dies umfasst: Überprüfen gesendeter Transaktionen / Überprüfen aufgezeichneter Daten / Überprüfen des allgemeinen Status des Netzwerks. Dies ist eine wichtige Unterscheidung zu Nicht-DLT-Systemen, da die Teilnehmer die Möglichkeit haben, eine unabhängige Prüfung des Systems durchzuführen.

Transaktionsüberprüfung

Durch Überprüfen einer Transaktion muss sichergestellt werden, dass ein einzelner Datensatz den Protokollregeln entspricht, bevor er an andere Entitäten übertragen wird. Dies beinhaltet: die Richtigkeit des Formats der Transaktion, das Vorhandensein einer geeigneten Signatur und die Erfüllung der Bedingung, dass die Transaktion nicht mit anderen in Konflikt steht. Einige Systeme betreiben möglicherweise ein System, das Transaktionen bis zu einem bestimmten Zeitpunkt oder aus einem anderen Grund verbietet. In der Regel werden solche Bedingungen durch intelligente Verträge erfüllt.

Ein Angriff von 51% ist der Fall, wenn ein Teilnehmer oder mehrere Teilnehmer ihre Rechenleistung (Stimmen) kombinieren und Transaktionen im Netzwerk schneller verarbeiten als der Rest des Protokolls. Mit solchen Angriffen können Sie ungültige Transaktionen durchführen und als gültig aufzeichnen. Besonders anfällig ist ein System, das PoW verwendet

Überprüfen Sie die Aufzeichnungen

Durch Überprüfen des gesendeten Datensatzes können Sie sicherstellen, dass der Datensatz den Protokollregeln entspricht. Wenn der vorgeschlagene Eintrag als gültig erkannt wird, wird er zur Liste der bestätigten Einträge hinzugefügt und an alle verbundenen Knoten im Netzwerk weitergeleitet. Obwohl dieser Prozess in jedem System unterschiedlich ist, ist er in der Regel nach allgemeinen Grundsätzen überall ähnlich, z. B. wenn überprüft wird, ob PoW-Arbeiten an einer Transaktion ausgeführt wurden. Die Kombination aus der Überprüfung gesendeter Transaktionen und ihrer anschließenden Aufzeichnung durch Validatoren bietet eine unabhängige Prüfung des gesamten Systems.

Transaktionsdatensatz

Eine bestätigte Transaktion / Aufzeichnung ist nicht unbedingt irreversibel. Die Irreversibilität des Schreibens kann probabilistisch sein (z. B. ein PoW-basiertes System, bei dem es unpraktisch ist, alle aufgezeichneten Transaktionen neu zu berechnen) oder Systeme, die „Prüfpunkte“ enthalten, die jeder Transaktion zugewiesen werden müssen. Bestätigte Datensätze können als unveränderlich bezeichnet werden, aber diejenigen, die "vorbestätigt" wurden, können storniert werden. Vorbestätigte Datensätze bleiben unverändert, nachdem der Übergangszustand von "vorbestätigt" zu "bestätigt" überwunden wurde.

Abbildung 2. Transaktionsverarbeitung in DLT-Systemen



Abbildung 2 beschreibt eine schematische Beschreibung des Prozesses, der während der Transaktionsverarbeitung abläuft. Zunächst erstellt der Benutzer eine Transaktion und sendet sie an das Netzwerk. Jeder Knoten prüft, ob die Transaktion den Protokollregeln entspricht. Wenn dies als korrekt angesehen wird, fügt der Knoten die Transaktion seiner Liste (mempool) hinzu, in der alle nicht bestätigten Transaktionen gespeichert sind, und wartet darauf, zur Liste der bestätigten Transaktionen hinzugefügt zu werden.

In der Transaktionsverarbeitungsphase wählen die Knoten zufällig nicht bestätigte Transaktionen aus ihrem Mempool aus und kombinieren sie dann zu einer Liste von "vorab genehmigten" Transaktionen. Als nächstes werden Transaktionen gemäß dem Konsensalgorithmus überprüft, um diese Transaktionen allen anderen Netzwerkteilnehmern anzubieten. Die Knoten zeigen die empfangenen Transaktionen und deren Inhalt an. Wenn die Transaktion die Überprüfung besteht, wird die Transaktion zur Liste des Knotens hinzugefügt. Listen mit Transaktionen jedes Knotens werden letztendlich an eine einzelne, wichtigste Liste bestätigter Transaktionen gesendet und gelten als abgeschlossen.

Bestätigte Transaktionen können jedoch aufgrund einer alternativen Transaktion „storniert“ werden. Dies bedeutet, dass Transaktionen in der Abwicklungsphase storniert werden können. In diesem Fall kehren sie als nicht bestätigte Transaktionen zu den Knoten zurück und warten darauf, eine neue Liste von Transaktionen zu erstellen. Die Transaktionsverarbeitungszeit in der Phase „Abrechnung“ hängt von den Einstellungen eines einzelnen Systems ab. Einige Systeme implementieren die sofortige Aufzeichnung von Transaktionen und deren Unwiderruflichkeit, aber einige Protokolle haben einen "probabilistischen" Abschluss in dem Sinne, dass Transaktionen theoretisch abgebrochen werden können. In der Praxis nimmt die Wahrscheinlichkeit dieser Aktion jedoch mit jeder neuen hinzugefügten Transaktion ab, da die Kosten für mit PoW verknüpfte Knoten hoch werden können. Während sich Transaktionen in der Abwicklungsphase befinden, können sie nicht als „abgeschlossen“ betrachtet werden.Der Transaktionsabwicklungsprozess erhöht die Garantie, dass Transaktionen auf allen teilnehmenden Knoten genau aufgelistet und nicht nur auf lokalen Knoten gespeichert werden. Dies hilft, Angriffe mit doppelten Ausgaben zu verhindern.

Einige Systeme implementieren ein "Checkpoint" -System, um die Möglichkeit von Fernangriffen zu begrenzen. Bei diesem Angriff erstellt der Knoten eine alternative Kette mit seinen persönlichen Transaktionen (die nur von ihm gespeichert werden). Diese Transaktionen werden nicht im Netzwerk angezeigt, sondern sofort in der Abwicklungsphase an die Knoten gesendet, um andere Knoten zu zwingen, sie durch ihre lokalen Transaktionen zu ersetzen. "Checkpoints" sind Blöcke, die niemals rückgängig gemacht oder ersetzt werden. Durch Kontrollpunkte wird die „Reichweite“ des Angriffs verringert. Meilensteine ​​erhöhen jedoch das Risiko einer Gabelung.

Tabelle 8. Bestätigte Transaktionseigenschaften

Datenebene

Die Protokollebene bestimmt, wie das System funktioniert und welche Regeln zu befolgen sind. Die Netzwerkschicht implementiert die zugrunde liegenden Prinzipien des Protokolls. Die Protokollschicht und das Netzwerk bilden zusammen die Basis für die Datenschicht, die sich im Laufe der Zeit ansammelt, wenn Transaktionen in die Liste der bestätigten Datensätze geschrieben werden.

Operationen

Die Operations-Komponente umfasst alle Prozesse, mit denen die Teilnehmer mit dem System interagieren.

Datenquellen

Der Eingabeprozess bezieht sich auf eine Quelle oder ein Verfahren zum Erhalten von Daten für ein Protokoll. Datenquellen können intern oder extern sein, was die aktive Interaktion der Benutzer mit dem System, eine Änderung des Protokollstatus, die durch einen internen Systemprozess verursacht oder von außen empfangen wird (z. B. eine von einem anderen Protokoll gesendete Transaktion) oder einen intelligenten Vertrag widerspiegeln kann.

Wir definieren interne Eingabequellen als jeden Datensatz oder jede Transaktion, die vom Benutzer oder aufgrund des Ergebnisses der Benutzerinteraktion mit dem Protokoll erstellt wurde. Externe Eingabequellen sind andererseits das Ergebnis von Eingaben von anderen Systemen, die mit dem Protokoll interagieren, aber im Prinzip von der zugrunde liegenden Plattform getrennt sind (d. H. Sie sind abhängig oder interagieren). Mit hybriden Protokollen können Benutzer Transaktionen jederzeit über die Zahlungskanäle „State Channel“ übertragen. Die Entwicklung dieser Methoden befindet sich jedoch noch im Anfangsstadium.

Tabelle 9. Dateneingabeformulare



Ausführbare Software-Transaktionen

Nicht alle Änderungen der Datenebene sind eine direkte Folge interner oder externer Eingaben. Einige Änderungen im System treten aufgrund der Ausführung von Codeanweisungen auf. Ein markantes Beispiel sind intelligente Verträge. Bei der Ausführung des eingebetteten Programmcodes ändert sich der Netzwerkstatus im Protokoll. Beispielsweise tritt eine Transaktion auf, die in der Liste der bestätigten Transaktionen aufgezeichnet wird. Einige DLT-Systeme unterstützen nur die Skriptsprache (Skript). Bitcoin Script funktioniert beispielsweise in einer einfachen Skriptsprache, mit der Sie Programme mit begrenzten einfachen Einstellungen erstellen können. Solche Systeme heißen - Staatenlos. Ethereum (Solidity), Tezos (Michelson) und EOS (WebAssembly) - diese Systeme unterstützen Turing-vollständige Programmiersprachen für die Entwicklung komplexer intelligenter Verträge, während Bitcoin und Monero eine Skriptsprache verwenden.Dies ermöglicht begrenzte Operationen.

Tabelle 10. Eigenschaften von durch Software ausgeführten Transaktionen Die



tatsächliche Ausführung von Berechnungen Der

Ort, an dem das Programm ausgeführt wird , bestimmt, wo die Berechnungen stattfinden. In der Regel kann sich der Ausführungsort innerhalb des Netzwerks befinden - in der Kette oder außerhalb der Kette (außerhalb des Netzwerks). On-Chain-Berechnungen werden an jedem Knoten durchgeführt. Diese Umgebung kann von einer einfachen virtuellen Maschine als Skriptsprache abweichen oder komplex sein (EVM - Ethereum Virtual Machine), wodurch die Ausführung von Turing-vollständigen Programmen sichergestellt wird. Intelligente Verträge in der On-Chain werden von jedem Knoten im Netzwerk gestartet und daher häufig als "selbstausführend" bezeichnet.

Off-Chain-Computing wird in einer Umgebung außerhalb des Protokolls durchgeführt. Das Ereignis, das den Programmcode ausführt, tritt in der On-Chain auf, und die Berechnungen finden in einem anderen System statt, ohne das Hauptnetzwerk zu laden. Es gibt auch ein Hybridsystem zum Starten von Anwendungen, beispielsweise Plasma in Ethereum. Oder zum Beispiel Cosmos, wo das Hauptnetz als "Zentrum" dient, die Berechnungen jedoch selbst in Nebennetzen erfolgen.

Tabelle 11. Eigenschaften der Softwaretransaktionsausführung

Protokollkomponente

Referenzen

Ab dem Moment, in dem Benutzer mit dem DLT-System interagieren, wird das Protokoll im Laufe der Zeit aktualisiert. Eine Zeitschrift ist jedoch eine Abstraktion. Alle Prozesse, die im DLT-System auftreten, beziehen sich auf ein bestimmtes Protokoll. Beispielsweise sollte ein Protokoll, das sich auf elektronische Zahlungen konzentriert, Informationen über Vermögenswerte enthalten, die bestimmten Benutzern gehören. Andererseits muss ein DLT-System, das intelligente Verträge enthält, über eine eigene virtuelle Maschine verfügen, die die Ausführung von Programmcode implementiert. Daher ist das Konzept einer Zeitschrift eine Abstraktion.

Arten von Links

Es gibt vier verschiedene Arten von Quelldaten: endogene, exogene, hybride und selbstreferenzierende.

Endogene (interne) Links beziehen sich auf Daten, die Informationen zu Variablen verfolgen, die im System „nativ“ sind. In Bitcoin wird beispielsweise eine endogene Referenzvariable verwendet, um die Anzahl der Bitcoins zu verfolgen, über die Benutzer zu einem bestimmten Zeitpunkt verfügen. Diese interne Variable wird aktualisiert, wenn der Benutzer Bitcoins an andere Adressen sendet und empfängt. Ein exogener (externer) Link bezieht sich auf Daten, die Informationen zu Variablen verfolgen, die außerhalb des Systems existieren. Hybridreferenz bezieht sich auf Daten, die sowohl endogene als auch exogene Eigenschaften aufweisen. Es gibt noch einen vierten Typ, der weder endogen noch exogen und nicht hybrid ist: Es ist ein neutraler oder leerer Datentyp - es ist ein selbstreferenzierender Link. Zum Beispiel ist ein intelligenter Vertrag nur ein Teil des Codes.die unter bestimmten Bedingungen durchgeführt werden kann. Obwohl für einen intelligenten Vertrag möglicherweise Informationen zu externen oder internen Systemvariablen erforderlich sind, enthält der Code selbst keinen internen Link zu etwas außerhalb von sich selbst (ein „leerer Link“).

Tabelle 12. Arten von Links und ihre Bedeutung

Fazit

Diese Arbeit zielt darauf ab festzustellen, ob das analysierte Objekt ein DLT-System ist. Die erzielten Ergebnisse eignen sich gut für die vergleichende Analyse verschiedener Projekte, beginnend mit der Managementstruktur bis hin zur Definition von Links, auf die sich Transaktionen beziehen.