{"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 oracle usare nella blockchain?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Oggi solo chi \u00e8 pigro non ha scritto sulla tecnologia blockchain, sulle criptovalute e su quanto sia fantastica. Tuttavia, in questo articolo non loder\u00f2 questa tecnologia, ma parler\u00f2 piuttosto dei suoi difetti e dei modi per affrontarli. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Durante il lavoro su uno dei progetti della societ\u00e0 Altirix Systems, \u00e8 emersa la necessit\u00e0 di confermare in modo sicuro e resistente alla censura i dati provenienti da una fonte esterna per la blockchain. Era necessario confermare le modifiche nei registri di un sistema terzo e, sulla base di queste modifiche, eseguire un ramo nella logica del contratto intelligente. A prima vista, il compito sembrava piuttosto banale, ma quando il risultato della sua esecuzione influisce sulla situazione finanziaria di una delle parti coinvolte, sorgono ulteriori requisiti. Prima di tutto, c'\u00e8 la necessit\u00e0 di una fiducia totale in questo meccanismo di validazione. Ma procediamo con ordine. <\/p>\n

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

Il problema \u00e8 che la blockchain \u00e8 di per s\u00e9 un'entit\u00e0 autonoma e chiusa, 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 (ritardi dei voli, tassi di cambio, ecc.). Per garantire il corretto funzionamento dei contratti intelligenti, le informazioni provenienti 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 consentono ai contratti intelligenti nella rete blockchain di fidarsi delle informazioni da un server web affidabile, potremmo dire che sono fornitori di informazioni sicure. <\/p>\n

<\/p>\n

Oracoli<\/h1>\n

<\/p>\n

Immagina che un contratto intelligente esegua un trasferimento di 0.001 btc al tuo wallet bitcoin in caso di vittoria della tua squadra di calcio preferita nella Coppa di Russia. In caso di vittoria reale, il contratto intelligente deve ricevere informazioni su quale squadra ha vinto, e qui sorgono diverse problematiche: dove reperire queste informazioni, come trasmetterle in sicurezza al contratto intelligente e come assicurarsi che le informazioni ricevute nel contratto intelligente corrispondano realmente alla realt\u00e0? <\/p>\n

<\/p>\n

Per quanto riguarda la fonte delle informazioni, ci possono essere 2 scenari: collegare il contratto intelligente a un sito web di fiducia, dove le informazioni sui risultati delle partite sono archiviate in modo centralizzato, oppure collegare pi\u00f9 siti e successivamente scegliere le informazioni in base a maggioranza di fonti che forniscono dati identici. Per assicurarsi che le informazioni siano corrette, si utilizzano oracoli, come Oraclize, che impiega TLSNotary (una modifica di TLS per dimostrare l'autenticit\u00e0 dei dati). Tuttavia, le informazioni su Oraclize sono facilmente reperibili su Google e ci sono vari articoli su Habr, mentre oggi parler\u00f2 di oracoli che utilizzano un approccio diverso alla trasmissione delle informazioni: Town Crier e DECO. Nell'articolo sono descritte le modalit\u00e0 operative di entrambi gli oracoli, oltre a un confronto dettagliato. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

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

<\/p>\n

L'enclave Intel SGX pu\u00f2 essere vista come una libreria generale con API, funzionante tramite ecall. L'ecall trasferisce il controllo all'enclave. Quest'ultima esegue il proprio codice fino al termine o fino a quando non si verifica un'eccezione. Per invocare funzioni definite al di fuori dell'enclave, si utilizzano ocall. L'ocall viene eseguito al di fuori dell'enclave e trattato come una chiamata non sicura. Dopo l'esecuzione dell'ocall, il controllo torna all'enclave.
\n\"Town
\nNella parte di Enclave, viene configurato un canale sicuro con il server web, l'enclave esegue il handshake TLS con il server di destinazione e gestisce tutte le operazioni crittografiche internamente. La libreria TLS (mbedTLS) e il codice HTTP in una versione ridotta sono stati esportati nell'ambiente SGX. Inoltre, l'Enclave contiene certificati root CA (una raccolta di certificati) per verificare i certificati dei server remoti. Il Request Handler riceve una richiesta datagram nel formato fornito da Ethereum, la decripta e la analizza. Successivamente, genera una transazione Ethereum contenente il datagram richiesto, lo firma con skTC e lo invia al Relay.<\/p>\n

<\/p>\n

La parte Relay include 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 ad att (firma di attestazione); successivamente att viene convalidato tramite Intel Attestation Service (IAS) e il timestamp viene verificato da un trusted time service. L'Interfaccia Blockchain verifica le richieste in entrata e registra le transazioni nella blockchain per la consegna dei datagram. <\/p>\n

<\/p>\n

Lavorando con TEE, TC permette di avviare pi\u00f9 enclave in parallelo, aumentando cos\u00ec la velocit\u00e0 di elaborazione delle informazioni di tre volte. Se con un'enclave funzionante la velocit\u00e0 era di 15 tx\/sec, con 20 enclave avviate in parallelo, la velocit\u00e0 aumenta fino a 65 tx\/sec; a titolo di confronto, la massima velocit\u00e0 nella 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 al CCS\u201920 e funziona con siti che supportano connessioni TLS. Garantisce la riservatezza e l'integrit\u00e0 dei dati.
\nDECO con TLS utilizza la crittografia simmetrica, quindi il cliente e il server web possiedono chiavi di crittografia, e il cliente pu\u00f2, se desidera, 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 dei 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 il client TLS ha difficolt\u00e0 a dimostrare che i dati provengono effettivamente da quel server (difficolt\u00e0 di provenienza). <\/p>\n

<\/p>\n

Nel protocollo DECO vengono utilizzate chiavi di crittografia KEnc e KMac. Il cliente invia una richiesta Q al server web<\/a>, la risposta dal 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 utilizzando l'operazione sulle porzioni della chiave KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

Configurando uno handshake a tre vie, lo scambio di dati tra il cliente e il server avverr\u00e0 con garanzia di sicurezza.
\n\"Town
\nParlando di un sistema di oracoli decentralizzati, non si pu\u00f2 non menzionare Chainlink, che mira a creare una rete decentralizzata di nodi oracolo, compatibile con Ethereum, Bitcoin e Hyperledger, tenendo conto della modularit\u00e0: ogni parte del sistema pu\u00f2 essere aggiornata. Per garantire la sicurezza, Chainlink richiede a ogni oracolo coinvolto in un incarico di rilasciare una combinazione di chiavi (pubblica e privata). La chiave privata \u00e8 utilizzata per generare una firma parziale, che contiene la loro soluzione alla richiesta di dati. Per ottenere una risposta, \u00e8 necessario combinare tutte le firme parziali degli oracoli della rete.<\/p>\n

<\/p>\n

Chainlink prevede di condurre un primo PoC DECO con un focus su applicazioni finanziarie decentralizzate, come i Mixicles. Al momento della scrittura 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 oracoli<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

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

<\/p>\n

    \n
  1. \n

    Iniezione di codice smart contract malevolo sui nodi TEE.
    \nL'essenza dell'attacco: inviare al TEE un codice di smart contract intenzionalmente errato; in questo modo, un aggressore che ha accesso al nodo sar\u00e0 in grado di eseguire il proprio smart contract (fraudolento) sui dati decrittografati. Tuttavia, i valori restituiti verranno crittografati con la chiave privata, e l'unico modo per accedere a tali dati sarebbe la fuga del testo crittografato durante il ritorno\/output.
    \nLa protezione contro questo attacco consiste nel verificare da parte dell'enclave la correttezza del codice all'indirizzo attuale. Questo pu\u00f2 essere realizzato tramite uno schema di indirizzamento, in cui l'indirizzo del contratto \u00e8 definito attraverso l'hashing del codice del contratto. <\/p>\n

    \n<\/li>\n

  2. \n

    Le modifiche al ciphertext dello stato del contratto rivelano la fuga.
    \nEssenza dell'attacco: I proprietari dei nodi sui quali vengono eseguiti smart contract hanno accesso allo stato del contract in forma crittografata al di fuori dell'enclave. Un aggressore, ottenendo il controllo del nodo, pu\u00f2 confrontare lo stato del contract prima e dopo l'esecuzione della transazione e pu\u00f2 determinare quali argomenti sono stati forniti e quale metodo dello smart contract \u00e8 stato utilizzato, poich\u00e9 il codice stesso dello smart contract e le sue specifiche tecniche sono pubblicamente disponibili.
    \nProtezione per garantire l'affidabilit\u00e0 del nodo stesso.<\/p>\n

    \n<\/li>\n

  3. \n

    Attacchi side-channel.
    \nUn tipo particolare 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 per condurre l'attacco:<\/p>\n

    <\/p>\n