Das Orakelproblem – Uneeb Agha

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining


In der Informatik wird eine Operation als Nebeneffekt bezeichnet, wenn sie neben der Rückgabe eines Wertes (des Haupteffekts) an den Aufrufer der Operation einen beobachtbaren Effekt hat. Stellen Sie sich als Beispiel eine einfache Software für einen Taschenrechner vor, die grundlegende arithmetische Operationen unterstützt. Bei einer bestimmten Eingabe wird eine bestimmte Ausgabe zurückgegeben. Das Taschenrechnerprogramm allein ist nutzlos. Es ist jedoch nützlich, wenn Sie damit interagieren können. Das Programm startet, wartet auf Eingabe und zeigt nach Eingabe der Eingabe das Ergebnis an. Die Implementierung fordert den Benutzer möglicherweise auf, Argumente von der Konsole anzugeben, und schreibt die Ausgabe nach der Berechnung zurück in die Konsole. Dies ist eine E / A-Operation. Alle E / A-Vorgänge sind Nebenwirkungen – das heißt, sie sind Teil des Programms (einfacher Taschenrechner), aber nicht die wesentlichen Funktionen. Mit anderen Worten, wenn der Taschenrechner eine Blackbox ist, benötigen wir einen Mechanismus, um eine Verbindung zu ihm herzustellen, der nicht Teil des Taschenrechners selbst ist. Ärgern Sie sich nicht zu sehr, wenn Ihnen dieses Konzept fremd ist. Selbst die besten Programmierer haben Schwierigkeiten, die Nebenwirkungen zu erfassen. Stack Exchange hat einige nette Erklärungen.

Im Allgemeinen geschlossene Systeme, die dies tun nicht Interaktion mit der physischen Welt in irgendeiner Weise möglich sind nutzlos. Es muss eine Brücke gebaut werden, die es den Systemen ermöglicht, sich die Hand zu geben und Informationen zu übertragen. Was nützt ein Server, wenn es keine Schnittstelle dafür gibt? Programmierbare Blockchains (vor allem Ethereum) müssen ähnliche Brücken bauen. Eine solche Brücke ist die offensichtliche Schnittstelle, die vorhanden sein muss, um mit dem Endbenutzer zu interagieren, d. H. Ein Client-Programm, entweder als mobile Anwendung, als Webanwendung oder sogar nur als Befehlszeilentool. Aber es gibt auch eine viel nuanciertere Brücke, mit der die meisten Menschen nicht ganz vertraut sind. Dies ist eine spezielle Art von Brücke, mit der die Blockchain Informationen aus der realen Welt sicherer erfassen kann. Diese Brücke heißt eine Orakel.

Mit intelligenten Verträgen können Sie komplexe Beziehungen erstellen, die vertrauenswürdig validiert und verifiziert werden können. Mit intelligenten Verträgen können Sie nicht nur seltene Token erstellen, denen monetäre Begriffe zugewiesen werden können, sondern auch komplexe mathematische Funktionen und Algorithmen erstellen. Das Hauptproblem ist jedoch, dass ihre Assoziation mit Objekten der realen Welt schwach ist. Mit anderen Worten, es gibt keine einfache Möglichkeit für einen intelligenten Vertrag, den Preis eines Vermögenswerts zu programmieren basierend auf anderen zeitlichen Variablen. Wenn ich beispielsweise den Wert meines Tokens als Funktion der aktuellen Temperatur programmieren möchte, wie würde ich vorgehen? Am einfachsten ist es natürlich, den Wert regelmäßig manuell einzugeben. Aber was nützt das? Die gesamte Voraussetzung für die Verwendung der Blockchain-Technologie besteht darin, die Informationen vertrauenswürdig überprüfen und validieren zu können. Manuelle Eingaben machen den Zweck der Verwendung einer Blockchain zunichte und machen sie außerdem anfällig für Hacks. Das ist das Orakelproblem und obwohl es viele Vorschläge gibt, ist das Urteil immer noch nicht die eleganteste Antwort. Ich persönlich glaube, dass dies eines der größten Hindernisse für eine breitere Akzeptanz ist.

Einstecken in den Smart-Vertrag

Oracle ist ein Datenanbieter. In dient als Brücke zwischen der dezentralen Blockchain und der physischen Welt außerhalb der Kette. Auf der einfachsten Ebene muss ein Informationsstrom bereitgestellt werden. Eine Möglichkeit, einen solchen Datenstrom für Informationen zu erstellen, besteht darin, den Smart-Vertrag mit einem Anbieter zu verbinden, der einen Wert über einen externen Trigger manipuliert. Dieser Wert kann beispielsweise der Preis von Bitcoin in US-Dollar oder das Ergebnis eines bestimmten Ereignisses sein – beispielsweise eine Wahl. Das ist ziemlich einfach:

Vertrag SomeContract {    Adresse öffentlicher Eigentümer;
uint public someValue;
Funktion SomeContract () public {
owner = msg.sender;
}}
Funktion setValue (uint v) public {
require (msg.sender == owner);
someValue = v;
}}
Funktion getValue () Konstante öffentliche Rückgabe (uint) {
return someValue;
}}
}}

Im obigen Vertrag ist der Code

erfordern (msg.sender == Eigentümer)

Stellt sicher, dass nur der Eigentümer (dessen Wert im Konstruktor festgelegt ist) den Wert ändern kann. Beachten Sie, dass dies nicht unbedingt der msg.sender sein muss. Es kann auch beliebig eingestellt werden. Im Wesentlichen planen wir, dass unser Vertrag von nur einer Person geändert wird.

Es gibt jedoch ein kleines Problem. Stellen wir uns vor, dieser Wert muss regelmäßig festgelegt werden. Vielleicht ist es der Preis von Bitcoin in USD. Wir müssten einen Weg finden, dies zu automatisieren. Eine Möglichkeit besteht darin, den Vertragseigentümer als einen Prozess zuzulassen, der regelmäßig setValue func mit dem angegebenen Wert aufruft. Darüber hinaus können andere Dienste auch einen Vertrag abschließen und aktualisierte Werte anfordern, indem sie das folgende Snippet hinzufügen.

...
Ereignis CallbackGetValue ();
...
Funktion updateValue () public {
CallbackGetValue ();
}}
...

Wie Sie sich vorstellen können, können wir mit dieser Verbindungsbrücke sehr kreativ werden. Wie wäre es, wenn Sie einen separaten Vertrag erstellen, der die Berechtigungen für das Oracle verwaltet, das Werte für diesen Vertrag festlegt. Wie wäre es auch mit einem Orakel für den Erlaubnisvertrag? Wann sollten wir das Ereignis senden: Wenn wir das Orakel bitten, den aktualisierten Wert anzugeben? Oder wenn der Wert aktualisiert wird und um andere zu benachrichtigen? Wie wechseln wir Orakel?

Das Risiko einer Zentralisierung

Lassen Sie uns die größte Lücke im vorherigen Vertrag schließen. Wir bauen dezentrale Smart-Verträge auf und verlassen uns gleichzeitig auf zentralisierte externe Server, um Code auszuführen. An dieser Stelle könnte man sich fragen: Warum überhaupt intelligente Verträge verwenden? Warum nicht einfach den gesamten Code auf einem zentralen Server ausführen? Es gibt einige gute Anwendungsfälle: Der Datenspeicher in der Blockchain ist für einige Zwecke immer noch nützlich. Stellen wir uns vor, wir haben ein Preis-Feed-Orakel für einen intelligenten Vertrag, der den USD-Wert von Ethereum von einer vertrauenswürdigen Behörde (z. B. Coinbase-Server) liefert. Wir können diese Informationen verwenden, um eine Dollar-Bindung (allgemein als Stablecoin bezeichnet) zu erstellen. Das kann dann gegen andere Vermögenswerte eingetauscht werden. Wenn Sie sich jedoch auf eine vertrauenswürdige Partei verlassen, entstehen potenzielle Schwachstellen, die manchmal zu riskant sind. Heute haben wir fast 1 Milliarde US-Dollar in Ethereum gesperrt, die für einen solchen Vertrag verwendet wurden. Selbst ein einfacher Fehler kann viel Geld verlieren.

Schauen wir uns das andere Extrem an. Eine Beispielimplementierung, die vollständig dezentralisiert ist.

Augur

Augur beschreibt sich selbst als Prognosemarkt. Es ist eine Wettplattform, mit der Benutzer das Ergebnis eines Events erstellen und daran teilnehmen können. Für zentralisierte Plattformen muss ein vertrauenswürdiger Dritter funktionieren, mit Geldern umgehen und die Ergebnisse von Ereignissen überprüfen. Als dezentraler, erlaubnisloser Prognosemarkt entfernt Augur Zwischenhändler und ermöglicht eine globale Beteiligung. Smart-Verträge verwalten Benutzergelder und Auszahlungen.

Es füllt Kauf- und Verkaufsaufträge für die Gebote aus. Sie können entweder sofort gefüllt werden oder einige Zeit im Auftragsbuch verbleiben. Anteile an einem Ergebnis können verkauft werden, bis das Ergebnis des Ereignisses entschieden ist. Das wahrheitsgemäße Ergebnis wird von den REP-Inhabern festgelegt und gemeldet. Der Benutzer sammelt entweder Gewinne, um auf das richtige Ergebnis zu setzen, oder verliert seinen Einsatz, um das falsche Ergebnis auszuwählen.

Das externe Ereignis erfordert ein Orakel. Im Falle von Augur wird dieses externe Ereignis vollständig in der Kette gelöst – durch dezentrale Abstimmung. Augur Reputation (REP) wird verwendet, um über die Ergebnisse von Ereignissen zu berichten. REP wird von Reportern nach dem Ereignis auf das „wahrheitsgemäße“ Ergebnis gesetzt. Das Ergebnis mit den meisten REP-Einsätzen wird als „wahrheitsgemäßes“ Ergebnis angesehen, um Plattformgewinne und -verluste auf dem Event auszugleichen. In dem Fall, in dem ein Benutzer seine REP-Token auf das falsche Ergebnis setzt (d. H. Ein "unwahres" Ergebnis), werden diese abgesteckten Token unter den Benutzern verteilt, die mit dem Konsens berichtet haben. Durch die Teilnahme an diesem Prozess zur Wahrheitsfindung erhalten Benutzer auch einen Teil der Plattformgebühren. Je mehr REP ein Benutzer für die Berichterstellung einsetzt, desto höher ist der Anteil der Plattformgebühren, die er erhält. Wenn bei der Ermittlung eines „wahren“ Ergebnisses eines Ereignisses etwas schief geht, enthält die Plattform auch eine Streitfunktion, mit der ein solches Problem gelöst werden kann.

Code-exemplarische Vorgehensweise [optional]

Das ist nicht Augurs Code. Aber ich würde erwarten, dass der Code für einen einfachen Absteckvertrag wie folgt aussieht. Sobald alle Optionen hinzugefügt wurden, beginnt die Abstimmung. Anschließend wird ein externer Trigger gegeben, der die Abstimmung stoppt und die Ergebnisse gezählt werden.

Vertrag StakingContract {    Event VotingOptions (Zeichenfolge[] Optionen);
event voteStarted ();
Veranstaltung gewählt (Adresse Wähler, uint BetragStaked);
event voteEnded (uint[] MengenStaked)
Adresse publicAddress; enum State {Erstellt, Abstimmung, Beendet}
Staat öffentlicher Staat;
Modifikator inState (State _state) {
require (state == _state);
_;
}}
nur ModifikatorOfficial () {
require (msg.sender == offiziellAddress);
_;
}}
uint optionsCount; Zeichenfolge[] Optionen;
uint[] MengenStaked;
Konstruktor () public {
offizielleAddress = msg.sender;
state = State.Created;
optionsCount = 0;
}}
Funktion addOption (Stringname)
Öffentlichkeit
inState (State.Created)
nur offiziell
{
MengenStaked[optionsCount] = 0;
Optionen[optionsCount] = Name;
optionsCount ++;
}}
Funktion startVote ()
Öffentlichkeit
inState (State.Created)
nur offiziell
{
state = State.Voting;
Stimmabgabe ausgebenOptions (Optionen);
Stimme abgebenStarted ();
}}
Funktionsabstimmung (uint optionId, uint amountStaked)
Öffentlichkeit
inState (State.Voting)
{
MengenStaked[optionId] + = amountStaked;
emit stimmte (msg.sender, amountStaked);
}}
Funktion endVote ()
Öffentlichkeit
inState (State.Voting)
nur offiziell
{
state = State.Ended;
Stimme abgebenEnded (BeträgeStaked);
}}
}}

Der obige Code erzählt nur die halbe Geschichte. Die andere Hälfte verwendet das Ergebnis dieses Abstimmungsvertrags, um die Umverteilung von Token unter Gewinnern und Verlierern zu bestimmen. Bestrafung von Benutzern, wenn sie auf das falsche Ergebnis gesetzt haben. Wie Sie vielleicht bemerken werden, besteht die Absicht, alles in der Kette zu regeln, darin, den Prozess vollständig dezentral und transparent zu gestalten. Dies ist ein Beispiel für a dezentrales Orakel. Im Wesentlichen die Wahrheit zu bestimmen, indem man den Menschen erlaubt, auf das richtige Ergebnis zu setzen. Mit anderen Worten, Haut im Spiel zu haben. Es ist ausreichend dezentralisiert, geht aber zu Lasten der Langeweile. Nicht geeignet, wenn Sie einen schnellen Konsens benötigen.

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close