{"id":93794,"date":"2020-09-10T07:42:27","date_gmt":"2020-09-10T05:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne"},"modified":"2020-09-10T07:42:27","modified_gmt":"2020-09-10T05:42:27","slug":"town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","title":{"rendered":"Town Crier vs DECO: welcher Orakel soll im Blockchain verwendet werden?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Heutzutage hat nur derjenige, der faul ist, nicht \u00fcber die Blockchain-Technologie, Kryptow\u00e4hrungen und wie cool das ist, geschrieben. In diesem Artikel wird es jedoch nicht um das Lob dieser Technologie gehen, sondern wir werden uns vielmehr mit ihren Nachteilen und m\u00f6glichen L\u00f6sungen befassen. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

W\u00e4hrend der Arbeit an einem der Projekte bei Altirics Systems stellte sich die Aufgabe der sicheren, zensurresistenten Best\u00e4tigung von Daten aus einer externen Quelle f\u00fcr die Blockchain. Es war notwendig, \u00c4nderungen in den Datens\u00e4tzen eines dritten Systems zu best\u00e4tigen und auf Grundlage dieser \u00c4nderungen in der Logik des Smart Contracts entweder diesen oder jenen Pfad auszuf\u00fchren. Die Aufgabe erschien zun\u00e4chst recht trivial, aber wenn das Ergebnis ihrer Ausf\u00fchrung vom finanziellen Zustand einer der am Prozess beteiligten Parteien abh\u00e4ngt, kommen zus\u00e4tzliche Anforderungen hinzu. Dabei handelt es sich vor allem um das umfassende Vertrauen in einen solchen Validierungsmechanismus. Aber lassen Sie uns der Reihe nach vorgehen. <\/p>\n

<\/a><\/noindex><\/p>\n

Das Problem besteht darin, dass die Blockchain an sich ein autonomes, geschlossenes Objekt darstellt, weshalb Smart Contracts innerhalb der Blockchain nichts \u00fcber die Au\u00dfenwelt wissen. Gleichzeitig sind die Bedingungen von Smart Contracts h\u00e4ufig mit Informationen \u00fcber reale Dinge (Flugversp\u00e4tungen, Wechselkurse usw.) verkn\u00fcpft. Damit Smart Contracts ordnungsgem\u00e4\u00df funktionieren, muss die von au\u00dferhalb der Blockchain erhaltene Information zuverl\u00e4ssig und \u00fcberpr\u00fcft sein. Dieses Problem wird durch die Verwendung von Orakeln wie Town Crier und DECO gel\u00f6st. Diese Orakel erm\u00f6glichen es dem Smart Contract in einem Blockchain-Netzwerk, den Informationen von einem \u00fcberpr\u00fcften Webserver zu vertrauen, man kann sagen, dass es sich um Lieferanten zuverl\u00e4ssiger Informationen handelt. <\/p>\n

<\/p>\n

Orakel<\/h1>\n

<\/p>\n

Stellen Sie sich vor, ein Smart Contract \u00fcberweist 0,001 BTC auf Ihre Bitcoin-Brieftasche im Falle des Sieges Ihres Lieblingsfu\u00dfballvereins im russischen Pokal. Im Falle eines tats\u00e4chlichen Sieges muss dem Smart Contract mitgeteilt werden, welcher Verein gewonnen hat, und hier treten einige Probleme auf: Woher bekommen wir diese Informationen, wie \u00fcbermitteln wir sie sicher an den Smart Contract und wie stellen wir sicher, dass die Informationen, die in den Smart Contract gelangen, tats\u00e4chlich mit der Realit\u00e4t \u00fcbereinstimmen? <\/p>\n

<\/p>\n

Es gibt zwei Szenarien hinsichtlich der Informationsquelle: die Verbindung eines Smart Contracts mit einer vertrauensw\u00fcrdigen Website, auf der die Informationen \u00fcber die Spielergebnisse zentral gespeichert sind, und die zweite M\u00f6glichkeit - die Anbindung mehrerer Websites, um die Informationen aus den meisten Quellen auszuw\u00e4hlen, die die gleichen Daten liefern. Um die Richtigkeit der Informationen zu \u00fcberpr\u00fcfen, werden Orakel verwendet, beispielsweise Oraclize, das TLSNotary nutzt (eine Modifikation von TLS zur Nachweisf\u00fchrung der Datenauthentizit\u00e4t). Zu Oraclize gibt es gen\u00fcgend Informationen bei Google, und auf Habr gibt es mehrere Artikel. Ich werde heute \u00fcber Orakel sprechen, die einen etwas anderen Ansatz zur \u00dcbertragung von Informationen verwenden: Town Crier und DECO. Der Artikel beschreibt die Funktionsweise beider Orakel sowie einen detaillierten Vergleich. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

Town Crier (TC) wurde 2016 auf der CCS'16 von IC3 (The Initiative for CryptoCurrencies and Contracts) vorgestellt. Die Hauptidee von TC besteht darin, Informationen von einer Website an einen Smart Contract zu \u00fcbertragen und sicherzustellen, dass die \u00fcber TC bereitgestellten Informationen mit denen auf der Website \u00fcbereinstimmen. TC verwendet TEE (Trusted Execution Environment) zur Gew\u00e4hrleistung der Datenauthentizit\u00e4t. Im Original wird die Arbeit mit Intel SGX beschrieben.
\nTown Crier besteht aus einem Teil innerhalb der Blockchain und einem Teil innerhalb des Betriebssystems selbst \u2013 dem TC Server.
\n\"Town
\nDer TC Contract befindet sich in der Blockchain und fungiert als Frontend f\u00fcr TC. Er empf\u00e4ngt Anfragen vom CU (Smart Contract des Benutzers) und gibt Antworten vom TC Server zur\u00fcck. Innerhalb des TC Servers befindet sich ein Relay, das die Verbindung zwischen dem Enklave und dem Internet (bidirektionaler Datenverkehr) herstellt und die Enklave mit der Blockchain verbindet. Die Enklave enth\u00e4lt progencl, der den Code darstellt, der Anfragen aus der Blockchain ausf\u00fchrt und Nachrichten mit digitaler Signatur zur\u00fcck in die Blockchain sendet. Progencl enth\u00e4lt Teile des Smart Contract-Codes und f\u00fchrt im Wesentlichen einige seiner Funktionen aus. <\/p>\n

<\/p>\n

Die Intel SGX-Enklave kann als eine allgemeine Bibliothek mit API betrachtet werden, die \u00fcber ecall funktioniert. Ecall \u00fcbertr\u00e4gt die Kontrolle an die Enklave. Die Enklave f\u00fchrt ihren Code aus, bis er abgeschlossen ist oder eine Ausnahme auftritt. F\u00fcr den Aufruf von Funktionen, die au\u00dferhalb der Enklave definiert sind, werden ocall verwendet. Ocall wird au\u00dferhalb der Enklave ausgef\u00fchrt und vom System als unsicherer Aufruf behandelt. Nach der Ausf\u00fchrung von ocall wird die Kontrolle an die Enklave zur\u00fcckgegeben.
\n\"Town
\nIm Enclave wird ein sicherer Kanal mit dem Webserver eingerichtet, das Enclave f\u00fchrt das TLS-Handschlag mit dem Zieldatenserver durch und f\u00fchrt alle kryptografischen Operationen intern aus. Die TLS-Bibliothek (mbedTLS) und der HTTP-Code in verkleinerter Form wurden in die SGX-Umgebung exportiert. Au\u00dferdem enth\u00e4lt das Enclave Root-CA-Zertifikate (eine Sammlung von Zertifikaten), um die Zertifikate von entfernten Servern zu \u00fcberpr\u00fcfen. Der Request Handler nimmt das Datagramm im Format entgegen, das von Ethereum bereitgestellt wird, entschl\u00fcsselt es und analysiert es. Anschlie\u00dfend generiert er eine Ethereum-Transaktion, die das angeforderte Datagramm enth\u00e4lt, signiert es mit skTC und \u00fcbergibt es an den Relay.<\/p>\n

<\/p>\n

Der Relay-Bereich umfasst die Client-Schnittstelle, TCP und die Blockchain-Schnittstelle. Die Client-Schnittstelle ist notwendig f\u00fcr die Attestation des Enclave-Codes und die Verbindung zum Client. Der Client sendet eine Anfrage zur Attestation \u00fcber ecall und erh\u00e4lt einen Zeitstempel, der mit skTC signiert ist, zusammen mit att (dem Attestierungszeichen), danach wird att \u00fcber den Intel Attestation Service (IAS) best\u00e4tigt, und der Zeitstempel wird durch einen vertrauensw\u00fcrdigen Zeitdienst \u00fcberpr\u00fcft. Die Blockchain-Schnittstelle \u00fcberpr\u00fcft die eingehenden Anfragen und platziert die Transaktionen in der Blockchain zur Lieferung der Datagrams. Geth ist der offizielle Ethereum-Client und erm\u00f6glicht es dem Relay, \u00fcber RPC-Calls mit der Blockchain zu interagieren. <\/p>\n

<\/p>\n

Durch die Arbeit mit TEE erm\u00f6glicht TC das gleichzeitige Starten mehrerer Enclaves, wodurch die Informationsverarbeitungsgeschwindigkeit um das Dreifache erh\u00f6ht wird. Wenn bei einem laufenden Enclave die Geschwindigkeit 15 tx\/sec betrug, steigt sie bei 20 parallel gestarteten Enclaves auf 65 tx\/sec, zum Vergleich: die maximale Geschwindigkeit im Bitcoin-Blockchain betr\u00e4gt 26 tx\/sec.<\/p>\n

<\/p>\n

DECO<\/h1>\n

<\/p>\n

DECO (Dezentrale Orakel f\u00fcr TLS) wurde auf CCS\u201920 vorgestellt und funktioniert mit Websites, die TLS-Verbindungen unterst\u00fctzen. Es gew\u00e4hrleistet die Vertraulichkeit und Integrit\u00e4t der Daten.
\nDECO mit TLS verwendet symmetrische Verschl\u00fcsselung, sodass der Client und der Webserver Verschl\u00fcsselungsschl\u00fcssel haben, und der Client kann, wenn er m\u00f6chte, die TLS-Sitzungsdaten f\u00e4lschen. Um dieses Problem zu l\u00f6sen, verwendet DECO ein dreiseitiges Handshake-Protokoll zwischen prover (Smart Contract), verifier (Oracle) und web-server (Datenquelle).<\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Der Arbeitsprinzip von DECO besteht darin, dass der pr\u00fcfende (prover) einen Teil der Daten D erh\u00e4lt und dem verifizierer (verifier) best\u00e4tigt, dass D vom TLS-Server S stammt. Ein weiteres Problem besteht darin, dass TLS die Daten nicht signiert und es dem TLS-Client schwerf\u00e4llt zu beweisen, dass die Daten von genau diesem Server stammen (Provenance-Schwierigkeit). <\/p>\n

<\/p>\n

Im DECO-Protokoll werden die Verschl\u00fcsselungsschl\u00fcssel KEnc und KMac verwendet. Der Client sendet eine Anfrage Q an einen Webserver<\/a>, die Antwort des Servers R kommt in verschl\u00fcsselter Form, aber der Client und der Server besitzen die gleichen KMacs, sodass der Client die TLS-Nachricht f\u00e4lschen kann. Die L\u00f6sung von DECO besteht darin, KMac vor dem Client (prover) zu \"verstecken\", bis dieser auf die Anfrage antwortet. Nun ist KMac zwischen prover und verifier aufgeteilt \u2013 KpMac und KvMac. Der Server erh\u00e4lt KMac zur Verschl\u00fcsselung der Antwort mittels der Operation der Schl\u00fcsselteile KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

Durch die Einrichtung eines dreiseitigen Handshakes wird der Austausch von Daten zwischen Client und Server mit einer Sicherheitsgarantie durchgef\u00fchrt.
\n\"Town
\nWenn es um das System der dezentralisierten Orakel geht, muss Chainlink erw\u00e4hnt werden, das eine dezentrale Netzwerkarchitektur von Orakel-Knoten anstrebt, die mit Ethereum, Bitcoin und Hyperledger kompatibel ist, unter Ber\u00fccksichtigung der Modularit\u00e4t: Jeder Teil des Systems kann aktualisiert werden. Um die Sicherheit zu gew\u00e4hrleisten, bietet Chainlink jedem Orakel, das an einer Aufgabe beteiligt ist, eine Kombination von Schl\u00fcsseln (\u00f6ffentlich und privat) an. Der private Schl\u00fcssel wird verwendet, um eine partielle Unterschrift zu generieren, die ihre L\u00f6sung f\u00fcr die Datenanforderung enth\u00e4lt. Um die Antwort zu erhalten, ist die Kombination aller partiellen Unterschriften der Netzwerkorakel erforderlich.<\/p>\n

<\/p>\n

Chainlink plant die Durchf\u00fchrung eines ersten PoC DECO mit dem Fokus auf dezentralisierte Finanzanwendungen wie Mixicles. Zum Zeitpunkt des Schreibens wurde in den Nachrichten von Forbes berichtet, dass Chainlink DECO von der Cornell University erworben hat.<\/p>\n

<\/p>\n

Angriffe auf Orakel<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Aus der Perspektive der Informationssicherheit wurden die folgenden Angriffe auf Town Crier betrachtet:<\/p>\n

<\/p>\n

    \n
  1. \n

    Rogue-Smart-Contract-Code-Injektion auf TEE-Knoten.
    \nDas Wesen des Angriffs besteht darin, einen absichtlich falschen Smart-Contract-Code in die TEE zu \u00fcbertragen, sodass ein Angreifer, der Zugang zum Knoten hat, seinen eigenen (betr\u00fcgerischen) Smart-Contract auf entschl\u00fcsselte Daten ausf\u00fchren kann. Die zur\u00fcckgegebenen Werte werden jedoch mit dem privaten Schl\u00fcssel verschl\u00fcsselt, und die einzige M\u00f6glichkeit, auf solche Daten zuzugreifen, besteht darin, dass der verschl\u00fcsselte Text bei der R\u00fcckgabe\/\u00dcbertragung ausl\u00e4uft.
    \nDer Schutz vor diesem Angriff besteht darin, dass der Enklave die Richtigkeit des Codes an der aktuellen Adresse \u00fcberpr\u00fcft. Dies kann durch ein Addressing-Schema erreicht werden, bei dem die Adresse des Vertrags durch das Hashing des Codes des Vertrags bestimmt wird. <\/p>\n

    \n<\/li>\n

  2. \n

    \u00c4nderungen des Verschl\u00fcsselungszustands des Vertrags f\u00fchren zu Leaks.
    \nDie Essenz des Angriffs: Die Betreiber von Knoten, auf denen Smart Contracts ausgef\u00fchrt werden, haben Zugriff auf den Contract-State in verschl\u00fcsselter Form au\u00dferhalb des Enklave. Ein Angreifer, der die Kontrolle \u00fcber den Knoten erlangt, kann den Contract-State vor und nach der Ausf\u00fchrung der Transaktion vergleichen und ermitteln, welche Argumente \u00fcbergeben wurden und welche Methode des Smart Contracts verwendet wurde, da der Code des Smart Contracts und seine technischen Spezifikationen \u00f6ffentlich zug\u00e4nglich sind.
    \nSchutz zur Gew\u00e4hrleistung der Zuverl\u00e4ssigkeit des Knotens selbst.<\/p>\n

    \n<\/li>\n

  3. \n

    Seitenkanalangriffe.
    \nEine spezielle Art von Angriffen, die das Monitoring des Zugriffs auf den Speicher und den Cache der Enklave in verschiedenen Szenarien nutzt. Ein Beispiel f\u00fcr einen solchen Angriff ist Prime and Probe.
    \n\"Town
    \nAblauf des Angriffs:<\/p>\n

    <\/p>\n