{"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\/it\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","title":{"rendered":"Town Crier vs DECO: quale oracolo usare nella blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Oggi solo i pigri non hanno scritto sulla tecnologia blockchain, le criptovalute e quanto sia incredibile. Ma in questo articolo non ci sar\u00e0 alcun elogio per tale tecnologia, si parler\u00e0 proprio dei suoi svantaggi e dei modi per affrontarli. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Durante il lavoro su uno dei progetti dell'azienda Altyrix Systems, \u00e8 emersa la necessit\u00e0 di una conferma sicura e resistente alla censura dei dati da una fonte esterna per la blockchain. Era necessario convalidare le modifiche nei registri di un terzo sistema e, sulla base di queste modifiche, eseguire un ramo logico nel contratto intelligente. A prima vista, questo compito pu\u00f2 sembrare piuttosto banale, ma quando il risultato della sua esecuzione influisce sulla situazione finanziaria di una delle parti coinvolte nel processo, sorgono requisiti aggiuntivi. Prima di tutto, c'\u00e8 bisogno di una fiducia totale in questo tipo di meccanismo di validazione. Ma andiamo con ordine. <\/p>\n

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

Il problema sta nel fatto che la blockchain \u00e8 autonomo e un oggetto chiuso, quindi i contratti intelligenti all'interno della blockchain non sanno nulla del mondo esterno. Allo stesso tempo, le condizioni dei contratti intelligenti sono spesso legate a informazioni su eventi reali (ritardo di volo, tasso di cambio, ecc.). Per un corretto funzionamento dei contratti intelligenti, le informazioni ottenute dall'esterno della blockchain devono essere affidabili e verificate. Questo problema viene risolto attraverso l'uso di oracoli, come Town Crier e DECO. Questi oracoli permettono al contratto intelligente nella rete blockchain di fidarsi delle informazioni provenienti da un server web verificato, si potrebbe dire che sono fornitori di informazioni affidabili. <\/p>\n

<\/p>\n

Oracoli<\/h1>\n

<\/p>\n

Immaginate che un contratto intelligente effettui un trasferimento di 0.001 btc nel vostro portafoglio bitcoin in caso di vittoria della vostra squadra di calcio preferita nella Coppa di Russia. In caso di vittoria effettiva, al contratto intelligente sar\u00e0 necessario fornire informazioni su quale squadra ha vinto, e qui sorgono una serie di problemi: dove ottenere queste informazioni, come trasmetterle in sicurezza al contratto intelligente e come assicurarsi che le informazioni fornite al contratto intelligente corrispondano effettivamente alla realt\u00e0? <\/p>\n

<\/p>\n

Nel caso della fonte di informazione possono esserci 2 scenari: collegare un contratto intelligente a un sito web fidato, dove le informazioni sui risultati delle partite sono conservate in modo centralizzato, e la seconda opzione \u00e8 collegare pi\u00f9 siti e poi selezionare le informazioni dalla maggior parte delle fonti che forniscono dati identici. Per assicurarsi della correttezza delle informazioni, si utilizzano oracle, ad esempio Oraclize, che utilizza TLSNotary (modifica del TLS per la verifica dell'autenticit\u00e0 dei dati). Ma su Oraclize ci sono sufficienti informazioni su Google, e ci sono diversi articoli su Habr, io vi parler\u00f2 oggi degli oracle che utilizzano un approccio leggermente diverso alla trasmissione delle informazioni: Town Crier e DECO. L'articolo descrive i principi di funzionamento di entrambi gli oracle e un confronto dettagliato. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

Town Crier (TC) \u00e8 stato presentato da IC3 (The Initiative for CryptoCurrencies and Contracts) nel 2016 a CCS'16. L'idea principale di TC: trasmettere informazioni dal sito web al contratto intelligente e assicurarsi che le informazioni fornite da TC siano le stesse di quelle sul sito web. TC utilizza TEE (Trusted Execution Environment) per l'autenticit\u00e0 della propriet\u00e0 dei dati. Nella versione originale di TC, \u00e8 descritto il funzionamento con Intel SGX.
\nTown Crier \u00e8 composto da una parte all'interno della blockchain e da una parte all'interno del sistema operativo stesso \u2014 TC Server.
\n\"Town
\nIl contratto TC si trova nella blockchain e funge da front end per TC. Riceve richieste dall'utente CU (contratto intelligente dell'utente) e restituisce risposte dal TC Server. All'interno del TC Server si trova un Relay che stabilisce la connessione tra l'enclave e la rete Internet (traffico bidirezionale) e collega l'enclave alla blockchain. L'Enclave contiene progencl, che \u00e8 il codice che esegue le richieste dalla blockchain e restituisce i messaggi nella blockchain con una firma digitale; progencl contiene una parte del codice del contratto intelligente e, in sostanza, esegue alcune delle sue funzioni. <\/p>\n

<\/p>\n

L'enclave Intel SGX pu\u00f2 essere considerata come una libreria generale con API, che funziona attraverso ecall. L'ecall trasferisce il controllo all'enclave. L'enclave esegue il proprio codice fino al termine o fino a quando non si verifica un'eccezione. Per chiamare le funzioni definite al di fuori dell'enclave, si utilizzano ocall. L'ocall viene eseguito al di fuori dell'enclave e viene gestito come una chiamata non fidata. Dopo l'esecuzione dell'ocall, il controllo ritorna all'enclave.
\n\"Town
\nNella parte Enclave si configura il canale sicuro con il server web, l'enclave stessa esegue il TLS handshake con il server di destinazione e svolge tutte le operazioni crittografiche al suo interno. La libreria TLS (mbedTLS) e il codice HTTP in versione ridotta sono stati esportati nell'ambiente SGX. Inoltre, l'Enclave contiene certificati CA root (collezione di certificati) per verificare i certificati dei server remoti. Il Request Handler riceve una richiesta datagram nel formato fornito da Ethereum, ne decifra il contenuto e lo analizza. Successivamente genera una transazione Ethereum contenente il datagram richiesto, la firma con skTC e la invia al Relay.<\/p>\n

<\/p>\n

La parte Relay comprende l'interfaccia Client, TCP e l'interfaccia Blockchain. L'interfaccia Client \u00e8 necessaria per l'attestazione del codice dell'enclave e la comunicazione con il cliente. Il cliente invia una richiesta di attestazione tramite ecall e riceve un timestamp firmato con skTC insieme all'att (firma di attestazione), poi att viene confermata tramite Intel Attestation Service (IAS) e il timestamp viene verificato da un trusted time service. L'interfaccia Blockchain controlla le richieste in arrivo e inserisce le transazioni nella blockchain per la consegna dei datagram. Geth \u00e8 il client ufficiale di Ethereum e consente a Relay di interagire con la blockchain tramite chiamate RPC. <\/p>\n

<\/p>\n

Lavorando con TEE, TC consente di avviare pi\u00f9 enclave in parallelo, aumentando cos\u00ec la velocit\u00e0 di elaborazione delle informazioni di 3 volte. Se con un'enclave funzionante la velocit\u00e0 era di 15 tx\/sec, con 20 enclave avviate in parallelo la velocit\u00e0 sale a 65 tx\/sec; per confronto, la velocit\u00e0 massima operativa della blockchain di Bitcoin \u00e8 di 26 tx\/sec.<\/p>\n

<\/p>\n

DECO<\/h1>\n

<\/p>\n

DECO (Decentralized Oracles for TLS) \u00e8 stato presentato a CCS'20 e funziona con siti che supportano la connessione TLS. Garantisce la riservatezza e l'integrit\u00e0 dei dati.
\nDECO con TLS utilizza la crittografia simmetrica, in modo che il cliente e il server web condividano le chiavi di crittografia e il cliente, se desidera, pu\u00f2 falsificare i dati della sessione TLS. Per risolvere questo problema, DECO utilizza un protocollo di handshake a tre vie tra prover (smart contract), verifier (oracolo) e web-server (fonte di dati).<\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Il principio di funzionamento di DECO consiste nel fatto che il verificatore (prover) ottiene una parte dei dati D e conferma al verificatore (verifier) che D proviene dal server TLS S. Un'altra problematica \u00e8 che TLS non firma i dati e quindi il cliente TLS ha difficolt\u00e0 a dimostrare che i dati sono stati ricevuti specificamente da quel server (difficolt\u00e0 di provenienza). <\/p>\n

<\/p>\n

Nel protocollo DECO vengono utilizzate le chiavi di crittografia KEnc e KMac. Il cliente invia una richiesta Q a server web<\/a>, la risposta del server R arriva in forma crittografata, ma il cliente e il server possiedono gli stessi KMac e il cliente pu\u00f2 falsificare il messaggio TLS. La soluzione di DECO consiste nel \"nascondere\" KMac dal cliente (prover) fino a quando non risponde alla richiesta. Ora KMac \u00e8 suddiviso tra prover e verifier \u2014 KpMac e KvMac. Il server riceve KMac per crittografare la risposta attraverso l'operazione sulle parti della chiave KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

Impostando un handshake trilaterale, lo scambio di dati tra cliente e server avverr\u00e0 con garanzia di sicurezza.
\n\"Town
\nParlando di un sistema di oracle decentralizzati, non si pu\u00f2 non menzionare Chainlink, che mira a creare una rete decentralizzata di nodi oracle compatibili con Ethereum, Bitcoin e Hyperledger, tenendo conto della modularit\u00e0: ogni parte del sistema pu\u00f2 essere aggiornata. Per garantire la sicurezza, Chainlink propone a ciascun oracle coinvolto nel compito di emettere una combinazione di chiavi (pubblica e privata). La chiave privata viene utilizzata per generare una firma parziale che contiene la loro soluzione alla richiesta di dati. Per ottenere la risposta \u00e8 necessaria la combinazione di tutte le firme parziali degli oracle della rete.<\/p>\n

<\/p>\n

Chainlink prevede di eseguire un PoC iniziale di DECO con focus su applicazioni finanziarie decentralizzate come Mixicles. Al momento della stesura dell'articolo, \u00e8 stata pubblicata una notizia su Forbes riguardo all'acquisizione di DECO da parte di Chainlink dall'Universit\u00e0 di Cornell.<\/p>\n

<\/p>\n

Attacchi agli oracle<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Dal punto di vista della sicurezza informatica, sono stati esaminati i seguenti attacchi a Town Crier:<\/p>\n

<\/p>\n

    \n
  1. \n

    Iniezione di codice di smart contract malevolo sui nodi TEE.
    \nLa natura dell'attacco: invio a TEE di codice di smart contract volutamente errato, in modo che un aggressore che accede al nodo sar\u00e0 in grado di eseguire il proprio smart contract (fraudolento) sui dati decrittografati. Tuttavia, i valori restituiti saranno crittografati con la chiave privata, e l'unica opzione per accedere a tali dati \u00e8 la fuga del testo crittografato durante il ritorno\/uscita.
    \nLa protezione contro questo attacco consiste nella verifica da parte dell'enclave della correttezza del codice presente all'indirizzo attuale. Ci\u00f2 pu\u00f2 essere ottenuto tramite uno schema di indirizzamento, dove l'indirizzo del contratto viene definito tramite l'hashing del codice del contratto. <\/p>\n

    \n<\/li>\n

  2. \n

    Le modifiche al testo crittografato dello stato del contratto rivelano perdite.
    \nLa natura dell'attacco: I proprietari dei nodi su cui vengono eseguiti i contratti intelligenti hanno accesso allo stato del contratto in forma criptata al di fuori dell'enclave. Un malintenzionato che ottiene il controllo di un nodo pu\u00f2 confrontare lo stato del contratto prima e dopo l'esecuzione della transazione e pu\u00f2 determinare quali argomenti sono stati forniti e quale metodo del contratto intelligente \u00e8 stato utilizzato, poich\u00e9 il codice stesso del contratto intelligente e le sue specifiche tecniche sono di pubblico dominio.
    \nProtezione nella garanzia dell'affidabilit\u00e0 del nodo stesso.<\/p>\n

    \n<\/li>\n

  3. \n

    Attacchi side-channel.
    \nUn tipo speciale di attacchi che utilizza il monitoraggio dell'accesso alla memoria e alla cache dell'enclave in diversi scenari. Un esempio di tale attacco \u00e8 Prime and Probe.
    \n\"Town
    \nProcedura dell'attacco:<\/p>\n

    <\/p>\n