- Torna al menu
- Torna al menuPrezzi
- Torna al menuRicerca
- Torna al menuConsenso
- Torna al menu
- Torna al menu
- Torna al menu
- Torna al menuWebinar ed Eventi
Il codice è legge? Non ancora del tutto
Il codice dovrebbe essere legge? In questo articolo Opinioni , Lukas Abegg sostiene che ci sono molti ostacoli scientifici da superare prima che ciò sia verosimilmente possibile.
Dopo il fallimento dell'esperimento DAO, è scoppiato un acceso dibattito Politiche su come procedere con lo sviluppo della blockchain di Ethereum.
Le posizioni spaziavano dal mantenimento del paradigma dell'immutabilità, con "il codice è legge" come regola più importante da Seguici, a un approccio più Human , che chiedeva ai minatori e agli sviluppatori di Ethereum quali misure avrebbero dovuto essere adottate.
Tuttavia, è stato dedicato poco tempo alla questione di cosa sia uncontratto intelligenteè effettivamente in grado di eseguire.
Ma credo che proprio questa domanda debba essere al CORE del dibattito e che la risposta sia l'unica base sensata su cui costruire una Politiche solida per lo sviluppo di blockchain e contratti intelligenti.
Diamo quindi un'occhiata più da vicino alle capacità degli smart contract.
Natura delle informazioni
La caratteristica di uno smart contract è, nella sua essenza, l'elaborazione delle informazioni.
Sebbene la nozione di informazione vari e non esista una definizione universale, è utile iniziare con il modo in cuiteoria dell'informazionesi occupa di informazioni poiché la teoria dell'informazione fa parte del DNA dell'informatica odierna.
È quindi necessario suddividere le informazioni ininformazioni sintattiche E informazioni semantiche. Le prime sono le regole sulla relazione tra simboli e le seconde sono il significato attribuito a tali simboli (ad esempio: "intento"). La linea tra le due è un po' sfocata e a volte è difficile distinguerle (il che, come vedremo più avanti, ha portato al problema DAO in primo luogo), ma una differenza tra loro esiste chiaramente.
Un pezzo interessante sulla difficoltà di catturare "l'intento" erascritto di recentedi Vitalik Buterin.
Le informazioni sintattiche possono essere analizzate e misurate (comeShannon E Tessitore fatto in "A Mathematical Theory of Communication") ed è aperto alla dimostrazione matematica. L'informazione semantica, tuttavia, è ciò che un essere Human attribuisce a un simbolo. Può rappresentare qualsiasi cosa un cervello Human sia in grado di pensare.
Normalizzare le informazioni semantiche e renderle elaborabili è un compito piuttosto difficile, per usare un eufemismo. Informatica (in particolare ricercatori di intelligenza artificiale)lotta moltonel tentativo di catturare informazioni semantiche, come il linguaggio naturale, e rappresentarne il significato nel software. A peggiorare le cose, le informazioni semantiche possono essere qualsiasi cosa, da molto semplici a molto complesse.
Informazioni semantiche piuttosto semplici e formali, come un brevetto ad esempio, possono già essere elaborate dal linguaggio informatico. Pensate a un file CAD di un widget brevettato su un computer che consente a una stampante 3D di stampare esattamente la cosa che il suddetto file CAD contiene.
Informazioni semantiche più complesse, come la nozione legale di "buona fede", ad esempio, non possono ancora essere gestite dall'informatica. Per farlo, è ancora necessario un grande balzo in avanti nella ricerca sull'intelligenza artificiale.
Mancanza di governance
Un altro modo per fare una distinzione tra questi due tipi di informazioni sarebbe quello di riferirsi ad essi come"codice secco" e "codice umido", un concetto coniato dal crittografo Nick Szabo.
Per chiarire perché è fondamentale rispettare questa natura bilaterale delle informazioni, potremmo guardare The DAO. L'imperativo di "non arrecare danno" (vale a dire: informazioni semantiche) è stato scritto solo sulla home page di The DAO e non nel suo codice (che, per la maggior parte, elaborava solo informazioni sintattiche).
I seguaci di una rigida dottrina del "codice è legge" hanno sostenuto che l'hacker di DAO potrebbe quindi KEEP l'etere prosciugato poiché l'imperativo "non nuocere" era solo nelle specifiche della home page ma non nel codice stesso e quindi non era vincolante. Hanno portato la loro causa ancora più avanti mantenendo la blockchain Ethereum non biforcata e hanno creato un ambiente Ethereum parallelo, Ethereum Classic, che crea alcuni problemi piuttosto complicati per utenti e sviluppatori.
Se ci fosse stato uno strumento di governo adeguato che si fosse occupato delle informazioni semantiche (ad esempio: assicurando che tutti rispettassero la regola del "non nuocere" e fornendo i mezzi per affrontare i trasgressori), tale divisione probabilmente non si sarebbe verificata.
Dimostrazione matematica e immutabilità
Quando Shannon lavorava sulla teoria della comunicazione, si preoccupava molto che la sua ricerca fosse confinata nel regno delle informazioni sintattiche. Ciò gli consentiva di dimostrare matematicamente le sue scoperte.
Ciò non sarebbe stato possibile se fossero state coinvolte informazioni semantiche. Per Shannon, la dimostrazione matematica era importante per far progredire la scienza.
La codifica di uno smart contract non fa realmente progredire la scienza e quindi la dimostrazione matematica non è importante, ONE potrebbe pensare. Tuttavia, non appena aggiungi l'immutabilità tramite un'implementazione blockchain al tuo codice, stai alzando l'asticella per la correttezza del tuo codice a un livello incredibilmente alto, se non completamente fuori portata (cfr:analisi più dettagliata).
Poiché il codice è immutabile e non può essere modificato, devi essere assolutamente certo che non abbia difetti.
La dimostrazione matematica del tuo codice, quindi, sembra improvvisamente una caratteristica molto importante da avere.
Eppure, Solidity, così come viene utilizzato su Ethereum per l'implementazione di contratti intelligenti, non è un linguaggio che consente la dimostrazione matematica (ad esempio: non è referenzialmente trasparente). Ha consentito l'implementazione di informazioni semantiche o, per dirla in modo esplicito, l'intento degli sviluppatori. La chiamata ricorsiva che ha portato all'hack di The DAO avrebbe dovuto essere utilizzata in un modo specifico, come previsto dagli sviluppatori.
Ovviamente, tale intento non è stato catturato dal codice e quindi T ha impedito all'hacker di The DAO di prosciugare The DAO.
In conclusione: l'immutabilità e la correttezza del codice sono come i due piatti di una bilancia. Più "peso" dai all'immutabilità, più attenzione devi prestare alla correttezza del tuo codice.
Necessità di codice verificabile
Se quasi l'intero contratto intelligente viene eseguito in modo immutabile sulla blockchain (come alcuni sostenitori del principio "il codice è legge" immaginano sia l'unica strada da seguire), molto probabilmente non sarai in grado di dare un "contrappeso" sufficiente alla correttezza del tuo codice.
Tutte queste scoperte sono ben lungi dall'essere una novità.
Già nel 2002, Nick Szabo scrisse un articolo su unlinguaggio formale per i contratti, in cui ha sottolineato esplicitamente che l'uso del linguaggio informatico procedurale può essere allettante ma causare più danni che benefici. Questo T nemmeno menzionare tutti i linguaggi di programmazione esistentiche vengono utilizzati nel settore finanziario o nuovi modi di creare linguaggi di programmazione, che consentono la dimostrazione formale (campioniQuie qui https://legalese.com/docs).
Anche lo sviluppatore di Solidity stesso, il dottor Gavin Wood,immaginatoin una fase iniziale della concezione di Solidity un linguaggio che consente la dimostrazione matematica e le ricerche più recenti suggeriscono chetraduzione di Solidità in F*per raggiungere un codice verificabile sarebbe necessario.
Tuttavia, ormai sembra chiaro che lo stato desiderato di legalità, in cui non è necessario alcun impegno esterno a uno smart contract, non è ancora stato raggiunto. E probabilmente ci vorrà ancora un bel po' di tempo per arrivarci, se mai potrà essere raggiunto.
Colmare il vuoto tecnico
Ciò non significa, tuttavia, che il concetto di smart contract sia fallito o che sarebbe inutile. Ha solo bisogno di un'architettura che rispetti i limiti della Tecnologie attuale. E di un'ingegnosa soluzione alternativa per le lacune nel linguaggio di programmazione e nell'intelligenza artificiale che devono ancora essere colmate.
Una tale soluzione alternativa potrebbe risiedere nel sistema legale del classico meatspace, in particolare in un'area specifica chiamataRisoluzione alternativa delle controversie(ADR).
Il suo scopo è quello di dare a due o più parti in causa i mezzi formali per risolvere le loro controversie in privato senza dover ricorrere a tribunali pubblici statali. Fornisce strumenti che consentono di stabilire le proprie regole, definire i processi di gestione dei conflitti e/o selezionare i giudici di propria scelta.
Ha anche il piacevole effetto collaterale di essere effettivamente un classico-meatspace-legalmente vincolante. È un campo di gioco formidabile da esplorare, ad esempio:idee di futarchia come i Mercati di previsioneo nuovi concetti di attribuzione del valore comeAlimentazione posterioreper la scelta di un arbitro. E non è nemmeno molto difficile implementare tali regole di arbitrato in uno smart contract.
Assicurati solo che ogni utente di un servizio di contratto intelligente accetti di essere soggetto a tali regole di arbitrato, proprio come sei soggetto a regole di arbitrato costituite privatamente (ad esempio: ICANNUDRP) quando si registra un nome di dominio.
Come potrebbe apparire un LINK tra contratti intelligenti e regole legali dello spazio reale può essere scopertoQui(Queste non sono regole ADR ma regole di diritto contrattuale. L'implementazione, tuttavia, sarebbe molto simile).
Verso l'illegalità
A prima vista potrebbe sembrare strano utilizzare vecchi concetti per progredire in un nuovo ambito.
Tuttavia, se lo si considera come una struttura di supporto, molto simile a un oggetto appena stampato in 3D e che può essere gradualmente spostato quando il nuovo oggetto è in piedi da solo, la stranezza svanisce. Ancora di più, un tale modo di procedere potrebbe persino avere un elemento euristico nel senso che aiuta a Imparare di più su nuovi concetti e strumenti di governance che potrebbero sostituire completamente gli strumenti legali del meatspace in futuro.
Per chiudere il cerchio con l'inizio, dovremmo rispettare la natura bilaterale delle informazioni e lasciare che il codice elabori le informazioni sintattiche e implementare strumenti di governance affinché gli esseri Human elaborino le informazioni semantiche.
L'utilizzo di uno strumento di governo come le regole di arbitrato specifiche per i contratti intelligenti, insieme al riconoscimento che i contratti intelligenti non sono né intelligenti né contratti, ma solo codice eseguito in modo verificabile (VEC), potrebbe fornire un modo per testare le nuove Tecnologie in modo meno disastroso rispetto a quanto fatto con The DAO e potrebbe anche fornire la certezza necessaria per rendere i contratti intelligenti interessanti per le aziende.
Almeno finché la scienza non raggiungerà la visione del “codice come legge” e un vero stato dilegalitàpuò essere raggiunto.
Immagine del golftramite Shutterstock
Nota: Le opinioni espresse in questa rubrica sono quelle dell'autore e non riflettono necessariamente quelle di CoinDesk, Inc. o dei suoi proprietari e affiliati.