Fonte https://pixabay.com/
Come sicuramente saprai (e se non lo sai ti rimando a questo precedente articolo), la EVM fornisce alla piattaforma Ethereum un ambiente sicuro e protetto dalle possibili insidie esterne grazie ad un processo di virtualizzazione. Questo rende quindi la sua blockchain, che è public e permissionless come quella di Bitcoin, sicura e affidabile insieme al meccanismo di consenso interno della rete. Tutto ciò è chiaramente un vantaggio e una garanzia, ma limita di molto le possibili applicazioni (decentralizzate) e le potenzialità degli smart contracts. Questi contratti possono infatti dialogare tra di loro scambiandosi informazioni, triggerare eventi, creare altri contatti, ma le possibili azioni che possono eseguire sono perlopiù confinate all’interno della blockchain, che rappresenta una sorta di muro invalicabile verso l’esterno. Inoltre gli smart contracts seguono la filosofia “write once run forever”, il che li rende irreversibili e futuri cambiamenti logici sono di difficile realizzazione. Ma allora come possiamo realizzare uno smart contract che attiva una sua procedura interna non appena un certo fenomeno nel “mondo esterno” si verifica, ad esempio quando viene effettuato un pagamento VISA tra due persone o quando il livello della temperatura atmosferica supera i 40°? Di per sé la blockchain non può accedere a dati esterni alla rete: a questo scopo intervengono gli oracoli, agenti di terze parti che si frappongono tra la blockchain (e quindi gli smart contracts) ed il mondo reale, con lo scopo di passare informazioni agli smart contracts non appena una qualche condizione esterna si verifica. Forniscono quindi alla blockchain dati esterni e triggerano l’esecuzione di smart contracts non appena una certa condizione viene soddisfatta, condizione che richiede informazioni non note al momento di scrittura del contratto.
E qua una domanda dovrebbe sorgere spontanea: abbiamo per anni considerato la tecnologia dei distributed ledgers (cui Ethereum fa parte) come un’alternativa (positiva) alla centralizzazione delle informazioni presso enti ed istituzioni che potevano rendere polarizzata la loro verificabilità/veridicità e minare la sicurezza delle stesse. Ora ci stiamo affidando ad una terza parte centralizzata per risolvere un problema (ricevere dati esterni) nella nostra piattaforma decentralizza nata con lo scopo di ridurre l’uso di tale intermediari. Suona strano….
Aggiungiamo un’ulteriore asperità: il dato inviato dall’oracolo, con quale criterio e da chi viene scelto? Ritornando all’esempio dell’oracolo che avvisa lo smart contract non appena la temperatura supera i 40°: supponiamo che siamo una compagnia di benessere che vuole avvisare mediante SMS o mail i propri clienti quando la temperatura supera i 40°. Ogni quanto l’oracolo invia il dato con la misurazione allo smart contract? E il dato che viene inviato è quello istantaneo misurato dalla stazione meteorologica o è una media di altri valori giornalieri? Chiaramente se l’oracolo invia dati istantanei della misurazione avvenuta alle 00.00 difficilmente avrà valori superiori ai 40°. Allo stesso tempo avere valori medi su periodi temporali lunghi non è di molta utilità per la compagnia. E la stazione meteorologica da cui l’oracolo prende i dati è affidabile?
Si intuisce quindi come gioca un ruolo molto importante la fiducia nei confronti dell’oracolo ed una dettagliata rappresentazione del formato dati che ci invierà e le modalità con cui questo è stato estratto dal mondo reale. Una fiducia che l’oracolo si guadagnerà con il tempo. Un programmatore accorto potrebbe allora implementare la decisione tramite un consenso tra oracoli.
