La frontiera dell’assurance: l’audit agli Oracoli
Si fa un gran parlare, beh proprio grande magari no, diciamo che nella sempre meno ristretta community blockchain un tema che va per la maggiore è quello degli smart contracts. Per chi fosse nuovo della tematica, gli smart contracts sono programmi software che girano sulle macchine virtuali delle blockchain, Ethereum fra tutte e che costituiscono il motore del Metaverso Web3
Uno dei refrain è quanto sono fantastici gli smart contracts, quante cose belle si possono automatizzare senza bisogno di piattaforme di intermediari (banche, assicurazioni etc.). Lo smart contract entra in funzione automaticamente, e in linea di principio senza possibilità di essere bloccato (con dovute eccezioni – il post specifico di qualche tempo fa) al verificarsi di determinate condizioni cablate nello smart contract stesso.
Ad esempio, allo scattare di una determinata data-ora un affitto viene pagato o una rata di un mutuo saldata. Oppure, al verificarsi di un sinistro automaticamente scatta il rimborso assicurativo senza necessità di attivare procedure burocratiche con la compagnia di assicurazione. Tutto automatico, efficace e splendido.
Ma questi dati che fanno scattare le condizioni (trigger) da dove vengono presi? Per alcuni è facile, ossia per quelli interni alla blockchain stessa. Ad esempio, le blockchain da qualche parte gestiscono sicuramente data ed ora. Ma il verificarsi un evento esterno alla blockchain, ad esempio un sinistro, una calamità naturale, un soglia di temperatura, il prezzo di un titolo azionario, il decesso o infermità di una persona dove vengono presi? Chi lo dice alla blockchain? E visto che in ballo ci sono dei soldi, potenzialmente tanti, come si fa ad essere sicuri della bontà del dato? Insomma, di una noiosità assoluta, ma, dopo tanta innovazione, si ricade nel tradizionale alveo dell’Information Technology più classica: correttezza, tempestività, disponibilità, affidabilità, etc., dei dati, con ovviamente in più tutto l’impianto legale a tutela e garanzia delle parti coinvolte.
Abbiamo quindi capito che la blockchain non ce la fa da sola. Serve un componente esterno, un ponte (bridge), che la metta in comunicazione con il mondo reale. Questi componenti sono detti Oracoli.
Semplificando, ci sono sostanzialmente tre tipi di Oracoli in chiave blockchain:
- Oracoli software: moduli software che interagiscono con fonti di dati esterne tramite interfacce applicative (API) e li rendono disponibili agli smart contract sulla blockchain.
- Oracoli hardware: tipicamente dei sensori (temperatura, velocità, umidità etc) del mondo reale
- Oracoli decentrati: fatto si tratta di aggregatori di informazioni, di fatto un layer aggiuntivo fra blockchain e mondo reale che dovrebbe farsi carico di alcuni aspetti inerenti la qualità del dato. Il concetto è espresso molto bene sulla sezione education del sito di uno dei principali Oracoli decentrati, Chainlink. Ovviamente, per alcune considerazioni espresse da tenere sempre presente che Chainlink il sito è di parte.
Ma tutto questo cosa c’entra col titolo del post? L’audit agli Oracoli. C’entra eccome perché come dicevamo prima il ruolo degli Oracoli è quello di rendere disponibile dati che costituiscono dei trigger per l’attivazione di determinati eventi, anche o perlopiù, di natura economica. E quindi riemerge con prepotenza il tema tradizionale dell’assurance sul processo di produzione dei dati con riguardo sia ai processi tecnologici, sia su quelli di scelta e di acquisizione. Anche perché è da considerare come gli Oracoli introducano un potenziale point of failure, un punto di vulnerabilità, nell’altrimenti sicuro mondo della blockchain. Alcuni esempi:
- Come è stato scelto l’Oracolo: make or buy?
- Processo di scelta dell’Oracolo
- metodologie di sviluppo sicuro del software
- Audit right sul fornitore dell’Oracolo
- Compliance alle norme applicabili
- Tutele legali in caso di errori nei dati
Il tema è stato affrontato da qualche tempo a livello di associazioni professionali e di istituti universitari. Interessante Preparing Auditors for the Blockchain Oracle Problem di cui è liberamente disponibile un esteso summary che riprende anche quanto determinato fin dal 2021 da AICPA e PCAOB trattando in termini di Service Organization:
“ ….. if a smart contract acts as an internal control to ensure that transactions are processed appropriately, then the information provided by the oracle is relevant to these users’ internal control over financial reporting, thus making the oracle act as a service organization “ con le conseguenti implicazioni in termini di responsabilità standard di revisione
La connessa domanda alla IA generativa (ChatGPT) è postata nella gallery dedicata: Are blockchain Oracles auditable objects?