Digital Davide

Ma cosa sono? Quando si parla di smart contract, ed in particolare di quelli basati sulla blockchain Ethereum ci si imbatte presto in questa affermazione:

Uno smart contract non è né smart né contract.

Ricordiamo che Ethereum è una rete peer to peer che utilizza un protocollo ispirato a quello del Bitcoin per assicurare l’integrità di un registro globale di transazioni. In aggiunta a quanto già svolto benissimo da Bitcoin, Ethereum mette a disposizione uno strumento ed un linguaggio formale per la scrittura di smart contract. La domanda immediata è: perché non esistono gli smart contract su Bitcoin? In realtà esistono, ma diciamo che ci sono delle limitazioni, non tecniche ma volute in fase di progetto, che impediscono di codificare una logica complessa dentro una transazione Bitcoin. La value proposition di Ethereum è proprio questa, fare quello che Bitcoin ha deciso di non fare per timore di inficiare la sicurezza. Ethereum vuole correre il rischio.

Tornando al paradosso che gli smart contract non sono né smart né contract vediamo come spiegarlo. Con smart ci riferiamo a qualcosa di intelligente, ok gli smartphone non sono in effetti così intelligenti, ma lo diciamo per distinguerli dai dumb phone, quelli che servivano solo a fare le telefonate. Così, un po’ per estensione, tutto quello che è innovativo lo vorremmo chiamare smart, ma di fatto sarebbe più corretto dire contratto crittografico o contratto digitale.

Occhio che digitale non significa digitalizzato, non è che prendiamo un contratto cartaceo e lo digitalizziamo questo diventa uno smart contract. Digitale significa che può fare uso delle tecniche digitali (leggi numeriche) per consentire alcune proprietà: ad esempio l’autenticità. Questo si ottiene attraverso la crittografia.

Smart in realtà dovrebbe significare “capace di ragionare con dati incompleti” mimando in qualche modo il ragionamento o l’intuizione umana. Qualcosa più legato all’intelligenza artificiale che alla certezza crittografica. Ma questo è esattamente quello che non vogliamo nei contratti digitali: la discrezionalità dell’interpretazione che porta facilmente alla corruzione e all’ingiustizia.

Vediamo perché non è un contract. Cos’è un contratto? Secondo il codice civile italiano

Il contratto è l’accordo di due o più parti per costituire, regolare o estinguere tra loro un rapporto giuridico patrimoniale.

Insomma, serve definire le parti, che nell’ordinamento italiano saranno persone fisiche o giuridiche mentre nel caso degli smart contract basati su Ethereum queste parti non ci sono, o meglio non sono definite. Ci sono solo account e le loro chiavi private. Potrebbero essere possedute da un minore, da un robot, da uno scimpanzè, etc. da qui la difficoltà di stabilire le parti nel modo in cui si fa per i contratti tradizionali. Il contratto stesso su Ethereum può possedere una dotazione finanziaria (nella sua criptomoneta chiamata ether). Insomma un contratto su Ethereum è più che altro un agente artificiale (non intelligente però) dotato di fondi propri che può interagire con altri attori anch’essi dotati di chiavi crittografiche ed account sulla blockchain. Inoltre sempre secondo il codice civile

L’oggetto del contratto deve essere possibile, lecito, determinato o determinabile

Ammesso di poter identificare un oggetto nel caso degli smart contract, i concetti di possibile, lecito, determinato devono essere traslati nel vocabolario della blockchain e quindi: non esiste il concetto di possibile/impossibile ma quello di valido o non valido. La blockchain è fatta di transazioni, esse sono possibili se la matematica lo  consente ( esempio se hai 1 ether non puoi spenderne 1.5). Le transazioni sono verificate e successivamente inserite nel registro globale.

Lecito significa a norma di legge, ma in questo caso la legge è  il protocollo informatico e non la legge stabilità dalla giurisdizione in cui opera il nodo della rete.

Code is law

Ci piaccia o no, sembra essere così. La natura degli smart contract è quindi più quella di processi o agenti che di contratti intesi come accordi. Tali processi obbediscono ad un codice sorgente che ne stabilisce la logica e le condizioni. Quindi in realtà i contratti sono dei veri e propri programmi in esecuzione. Come tutti i programmi in esecuzioni hanno delle variabili, ad esempio numeri o stringhe, che sono definite e manipolate dal codice stesso.

Quindi, se non sono contratti a cosa servono e cosa si può fare? Ci sono diverse applicazioni:

• Aziende decentralizzate, attraverso un fondo comune soggetto a regole con cui i partecipanti possono votare per le spese da sostenere e regole per i dividendi
• Testamento, stabilisce che una somma venga spedita al verificarsi della morte di una persona.
• Regalo di compleanno, in cui una somma viene spedita solo al compimento dei 18 anni.
• un contratto di assicurazione che risarcisce automaticamente al verificarsi di un sinistro.
• diventare king of ether

e molti altri ….

Quindi qual è la peculiarità degli smart contract rispetto ai normali programmi del calcolatore? Beh, possiamo dire che la loro forza sta nel fatto che nessuno può spegnerli, una volta avviati, se la terminazione non è prevista nel loro codice, allora saranno per sempre in esecuzione. Si potrebbe suggerire che per spegnere un programma basta staccare la spina al computer che lo esegue, ma qui sta il bello ed il brutto della blockchain: il programma viene eseguito contemporaneamente ed in modo identico da tutti i nodi della blockchain che sono migliaia. Il bello: nessuno può staccare la spina. Il brutto? L’esecuzione più energeticamente inefficiente che possiamo immaginare. Ma ricordiamo come nel caso del Bitcoin. La blockchain è progettata per la sicurezza in un ambiente estremamente ostile dove tutti i partecipanti sono hacker esperti, malintenzionati e anonimi che provano ad imbrogliare mentre indossano la maschera di Guy Fawkes, e nonostante questo la sicurezza e l’onestà delle transazioni è garantita. La blockchain non è pensata per essere energeticamente efficiente.

Se un avversario ostile staccasse la spina al 50% dei nodi (nodi = computer) in poche ore il protocollo si auto-adatterebbe rendendo appetibile a molti nuovi potenziali nodi il loro ingresso. Di fatto i nodi sono sempre in competizione fra loro e se la competizione è più facile questo fa si che immediatamente altri nodi si aggiungano.

Vista la natura descritta fin qui appare chiaro che gli smart contract sono dei processi che automatizzano il trasferimento di valuta in modo automatico e decentralizzato e non sono stati pensati dagli avvocati ma piuttosto dagli ingegneri. Sarebbe interessante capire come e se ai giuristi potrà interessare influenzare questa tecnologia.

Segue esempio di contract, come vedete è assolutamente per programmatori.

pragma solidity ^0.4.0;

contract Purchase {
    uint public value;
    address public seller;
    address public buyer;
    enum State { Created, Locked, Inactive }
    State public state;

    function Purchase() payable {
        seller = msg.sender;
        value = msg.value / 2;
        if (2 * value != msg.value) throw;
    }

    modifier require(bool _condition) {
        if (!_condition) throw;
        _;
    }

    modifier onlyBuyer() {
        if (msg.sender != buyer) throw;
        _;
    }

    modifier onlySeller() {
        if (msg.sender != seller) throw;
        _;
    }

    modifier inState(State _state) {
        if (state != _state) throw;
        _;
    }

    event aborted();
    event purchaseConfirmed();
    event itemReceived();

    /// Abort the purchase and reclaim the ether.
    /// Can only be called by the seller before
    /// the contract is locked.
    function abort()
        onlySeller
        inState(State.Created)
    {
        aborted();
        state = State.Inactive;
        if (!seller.send(this.balance))
            throw;
    }

    /// Confirm the purchase as buyer.
    /// Transaction has to include `2 * value` ether.
    /// The ether will be locked until confirmReceived
    /// is called.
    function confirmPurchase()
        inState(State.Created)
        require(msg.value == 2 * value)
        payable
    {
        purchaseConfirmed();
        buyer = msg.sender;
        state = State.Locked;
    }

    /// Confirm that you (the buyer) received the item.
    /// This will release the locked ether.
    function confirmReceived()
        onlyBuyer
        inState(State.Locked)
    {
        itemReceived();
        // It is important to change the state first because
        // otherwise, the contracts called using `send` below
        // can call in again here.
        state = State.Inactive;
        // This actually allows both the buyer and the seller to
        // block the refund.
        if (!buyer.send(value) || !seller.send(this.balance))
            throw;
    }
}