Ospite di questa puntata abbiamo Giacomo Zucco il più importante divulgatore di Bitcoin in italia e tra i più acclamati nel mondo, parleremo di RGB un nuova protocollo recentemente finalizzato, scalabile e privacy oriented che permette smartcontract (e quindi anche token) su Bitcoin e Lightning Network.
____
Giulio
Benvenuti al 9º episodio di Bitcoin Detox. Piccolo reminder, cos’è Bitcoin Detox? È una serie di eventi live una volta a settimana, ogni martedì alle ore 18, che parlano di Bitcoin, criptovalute e tecnologie per la libertà dell’individuo. Oggi abbiamo un ospite speciale, Giacomo. Ciao Giacomo.
Giacomo
Ciao a tutti e complimenti per la sigla. Bellissima, molto nostalgica.
Giulio
Grazie! Non voglio presentarti, quindi voglio che sei tu che ti presenti perché in molti ti conoscono. Però vorrei sapere: a una persona che non ti conosce e che magari, anche in maniera un po’ familiare, ti incontra per strada, che fai tu nella vita? Cosa rispondi?
Giacomo
C’è il meme per cui se quello che fai è facile da spiegare, non è interessante. Quindi sarebbe una risposta difficile. Comunque, diciamo, fino al 2009, educazione formale in fisica. Fino al 2013, lavoro ufficiale Fiat come Technology Consultant in Accenture, su pagamenti tradizionali. Fino al 2018 imprenditore in campo Bitcoin seriale, alcune imprese andate molto bene, ho partecipato ai primissimi tempi di cose come Green Address che poi è diventato Blog Stream Green e altre società abbastanza fortunate e altre invece chiaramente finite nel nulla; ed ero imprenditore soprattutto della mia società di consulenza nel laboratorio di ricerca Blockchain Lab, che era il più grande laboratorio di ricerca Bitcoin in Europa e che finanziava il Meetup più importante d’Europa, e alcune conferenze come Scaling Bitcoin Milano. Dopo il 2018 ad oggi ufficialmente sono praticamente uno shitposter su Twitter. In realtà non è proprio così, faccio ancora un po’ di cose. Insegno alcune lezioni Bitcoin in alcune università private e per alcuni clienti privati, faccio consulenza Bitcoin per alcune banche, soprattutto in Svizzera. Partecipo ad alcuni fondi di investimento su Bitcoin, per esempio Lighting Ventures, sono nel board di alcune cosine come per esempio Geiser Fund, ecc., e finanzio un pochettino gli sviluppi di alcuni protocolli open source, tra cui anche il RGB, di cui parleremo oggi. Ma ufficialmente la narrativa è che io passo il tempo a insultare shitcoiners su Twitter.
Giulio
Perfetto, perfetto. (Lorenzo Giudice dice che non si sente l’audio se qualcun altro non sentisse l’audio, per favore lo scrivesse in chat perché a me risulta tutto bene. Io Giacomo lo sento bene, penso che Giacomo mi sente bene.)
Giacomo
Ti sento bene.
Giulio
Perfetto. Allora entriamo in merito della puntata di oggi. L’argomento di oggi è RGB, questo nuovo protocollo per smartcontract. Però prima di entrare a gamba tesa su cos’è RGB, facciamo un attimo un po’ una domanda di prerequisito. RGB introduce un nuovo paradigma, quindi partiamo un po’ dalle basi. Che cos’è questo nuovo paradigma che si chiama client side validation e in cosa differisce da quello che attualmente oggi in Bitcoin potremmo dire essere Network Side Validation?
Giacomo
Sì dunque, il termine è stato creato nel 2016 da Peter Todd, proprio nella conferenza a cui accennavo prima Scaling Bitcoin Milano – la conferenza che abbiamo organizzato al Politecnico. Peter, che è uno sviluppatore Bitcoin, tra i primi e tra i più famosi, è venuto fuori con quest’idea. Il termine è un po’ ambiguo, lo usiamo ancora per motivi storici, ma può essere un po’ confuso. In particolare è chiaro che in Bitcoin la validazione viene fatta dal tuo client. In Bitcoin com’è ora tu installi un nodo che è un client in una rete peer to peer, non c’è nessun server in Bitcoin, c’è la rete e ci sono tanti client e il tuo client fa validazione. Però fa validazione usando dei dati che sono a disposizione anche di tutti gli altri client. Cioè è un sistema a consenso globale. Questo vuol dire che tutti i nodi devono validare tutti i passaggi di stato provocati da tutti gli altri nodi; e i miner ovviamente anche loro devono appoggiarsi a un nodo bitcoin per creare un blocco, perché se creano un blocco e se contiene passaggi di stato non validi deve per forza saperlo, perché altrimenti il suo blocco verrà ignorato e perderà tutta l’energia che ha speso. Ad oggi, se io ti mando dei Bitcoin, metto una firma a questa transazione, magari soddisfo uno script nello smartcontract, quindi qualche condizione particolare di nLockTime, multi-firma, preimage, eccetera. Queste condizioni vengono controllate da tutti gli utenti Bitcoin per sempre. Questo crea chiaramente dei problemi di scalabilità, nel senso che tutti devono scaricare e verificare tutte le transazioni con tutti i dettagli di ogni smart contract per sempre. Ovviamente crea dei problemi anche di sicurezza e di estensibilità, perché creare linguaggi complessi, creare alcuni operatori particolari può essere pericoloso perché appunto questi operatori gireranno sui computer di tutti gli altri. Quindi se io creo per esempio un codice che va in loop, potrei mandare in loop il computer di qualcun altro. Motivo per cui Satoshi aveva deciso di togliere dallo script Bitcoin iniziale, dal linguaggio smartcontract iniziale, un sacco di operatori potenzialmente pericolosi dal punto di vista dell’esecuzione del codice, perché è un sistema completamente ridondato, dove tutti ripetono il calcolo. Poi è un problema anche ovviamente di privacy, perché se io faccio un contratto particolare con te, tutta la rete lo deve venire a sapere, per sempre.
Giacomo
Ora, da un lato ci sono per esempio alcune shitcoin che hanno addirittura esteso questo paradigma nel mettere tutto sul consenso globale. Tutti devono ripetere tutti i calcoli per sempre. Ovviamente questo fa sì che alla fine i nodi smettono di esistere e tutto si centralizza sotto pochi grandi server cloud gestiti da multinazionali. Invece Bitcoin è sempre andato nella direzione opposta. Un esempio è Lighting Network, dove io e te facciamo un canale e gli update di questo canale li teniamo fuori dal consenso globale, ed è solo quando chiudiamo il canale che torniamo nel consenso globale, nella Timechain o Blockchain. Client side validation è un’idea simile a questa, ma ancora più radicale del Lighting network. L’idea di Peter è: Bitcoin non doveva essere necessariamente disegnato così. Per evitare il double spending è necessario che tutti i nodi sappiano che c’è una spesa che viene fatta e che viene registrata in un registro pubblico ridondato da tutti. Questo è necessario per evitare il double spending, ma che il contenuto di questo passaggio di proprietà sia scritto all’interno di questo registro pubblico non era assolutamente necessario. Era la cosa più semplice scrivere tutto nel registro pubblico, ma Peter dice: la cosa che era necessaria era sostanzialmente pubblicare soltanto una spesa, una frase in cui si consuma un certo Coin per esempio, un certo output, viene bruciato in un input, questa cosa deve essere pubblicata onchain e poi si pubblica l’hash di qualcos’altro, questo qualcos’altro possono essere altri dieci output, degli smartcontract, script complessi, non importa, non devono mai essere pubblicati. Come si fa a sapere se una transazione valida? L’idea di Peter era: quando io ti mando dei coin, io sostanzialmente – a livello peer-to-peer per vero e proprio – invio a te come se fosse un messaggio WhatsApp, da me a te, senza coinvolgere gli altri nodi, io ti invio la firma valida, lo script valido e ti invio anche lo script che era stato mandato a me e quello che è stato mandato a chi l’aveva mandato a me e così via, fino alla coinbase iniziale, quindi alla nascita di quel coin. Quindi tutta la prova di possesso viene mandata peer-to-peer. Ovviamente ogni volta che transiamo si allarga un pochettino, ma si allarga nell’ordine di grandezza dei kilobyte, quando noi su WhatsApp ci stiamo mandando dei messaggi audio che sono magari interi megabyte, quindi non è un vero problema quando è peer-to-peer. La dimensione delle transazioni è un problema su consenso globale, perché vuol dire che tutti i nodi Bitcoin dovranno ridondare questa informazione per sempre e quindi diventa un enorme problema scrivere sulla blockchain.
Invece, mandarci dati a peer-to-peer non è un problema e sulla blockchain devo mettere soltanto un commitment a questi dati, quindi devo mettere, per dirla in maniera banale, non è sempre così, non è solo così, ma l’hash di questi dati. Quindi io nella Blockchain, Peter dice, non metto la transazione con tutti gli input e tutti gli output. Metto gli input, ma non metto per esempio il witness che dimostra la firma, metto solo quale tipo di input è stato consumato e poi metto un hash che rappresenta tutto il nuovo stato, e qual è il nuovo stato? Lo mando personalmente alla persona. Questo che vantaggi avrebbe? Avrebbe un vantaggio chiaramente di privacy, nessuno saprebbe quanti Bitcoin vengono mandati o come vengono bloccati, con che tipi di script, di smartcontract, né in ricezione né in spesa. Quindi privacy enorme. I miner farebbero molta fatica a fare blacklisting, anche non sarebbe facilissimo neanche fare whitelisting delle transazioni, quindi la censura diventa più difficile perché i miner non sanno quello che stanno pubblicando. Inoltre sarebbe più sicuro come sistema, perché ad oggi molti portafogli si appoggiano a quello che viene chiamato SPV impropriamente, cioè si appoggiano ai miner. Dicono, se i miner l’hanno messo in un blocco vuol dire che è valido e io non controllo neanche se è valido. In realtà questo è pericoloso, perché vuol dire che la maggior parte dei miner può dirottare la rete con regole nuove. Quindi è importante che ognuno validi personalmente le regole di Bitcoin, non si fidi della maggior parte dei miner. Così anche un 51% attack non può cambiare le regole, ma può solo riscrivere la storia di transazioni valide, ma non può inserire transazioni non valide. In client side validation non esiste.
Giulio
(Giacomo si è impallato, vediamo se è un problema solo mio.)
Giacomo
(Sono andato via per un attimo.)
Giulio
(Si, sei andato via per un secondo. Torna indietro di due-tre frasi.)
Giacomo
Niente, dicevo, i vantaggi sono privacy, scalabilità, perché sulla Blockchain dobbiamo continuare a mettere roba. Ma è soltanto il commitment, non è tutta l’informazione sulla transazione, solo un hash dell’informazione della transazione. Privacy, resistenza alla censura, scalabilità, è un fattore costante ma comunque importante e maggiore anche sicurezza. Quindi sembrerebbe un’idea bellissima. Quali sono gli svantaggi? Sono la complessità. Il sistema in cui funziona Bitcoin, la Network Side Validation, in cui noi assumiamo che tutti gli altri validino tutto per sempre, è un sistema inefficiente, non privato, meno scalabile, più censurabile ma semplice. Si scrive tutto sulla Blockchain, si legge tutto sulla Blockchain, al netto chiaramente dei canali lightining eccetera. Invece un sistema client side validated è più complesso. Basti pensare al concetto delle fee, del mining. Come si fa a pagare il miner con la solita asta delle fee? Non si può, quindi bisogna per esempio avere sistemi complicati in cui si propone a un miner, un pagamento off-chain diventa un po’ più complicato, insomma fare un po’ tutto.
Giulio
Chiaro.
Giacomo
Inoltre il secondo svantaggio è cambiare Bitcoin in maniera così radicale. È chiaro che l’idea è interessante, ma un cambiamento del genere è eccessivo per Bitcoin e ci sono anche due problemi di esperienza utente. Il primo problema è che se tu ricevi Bitcoin puoi farlo anche asincronicamente, cioè io ti do un indirizzo, poi spariscono per un anno. Durante quest’anno tu mi mandi dei Bitcoin su quell’indirizzo, io ritorno, mi risincronizzo e la transazione è stata tenuta via da tutti i nodi per sempre. Quindi la ritrovo perché tutti stanno ottenendo dei dati ridondanti per me a babbo morto diciamo, quindi io torno e me la trovo li. Invece in client side validation, se io ti do un indirizzo, poi me ne vado, tu non sai dove mandare le prove di pagamento, io torno o tu sei ancora lì online a cercare di mandarmi queste prove o se tu sei sparito io non ho ricevuto il mio pagamento perché non posso validarlo. Quindi richiede un po’ di sincronicità e questo è complesso ed è un problema.
Giulio
Un po’ come anche il lightning.
Giacomo
E infatti qui stai spoilerando, perché infatti il passaggio successivo di cui parleremo è unire questa idea a lightning. Ai tempi quando Peter l’aveva presentata lightning era appena appena discusso, ma non era ancora diventato realtà nel 2016. Il secondo problema, anche questo simile a un problema di lightning è il backup. Se io oggi faccio un backup della mia seed Bitcoin col gerarchico deterministico, io mi salvo le mie dodici parole nella mia passphrase, la rimetto su un altro client, rigenero il mio seed da cui rigenera tutti i miei indirizzi con il mio gaplimit deterministico, col mio chaincode e ottengo tutti i miei indirizzi, ma purtroppo tutte le prove offchain che mi vengono passate peer-to-peer me le devo backuppare tutte da solo. Se io ho ancora le mie chiavi, ma perdo tutte le prove dell’asset che mi è stato passato, ho comunque un problema fondamentale. Quindi ricapitoliamo i motivi che rendono questa idea di Peter bella, interessante ma non praticabile, così com’è su Bitcoin 2016.
Uno. Cambiare Bitcoin così tanto? Scordatelo, fuori discussione. Due. Devi essere praticamente online sincronicamente col pagante per poter ricevere. Tre. Il backup diventa complicato perché ti devi fare il backup di un sacco di altra roba. Quindi queste sono le tre cose. Quattro, in realtà, che è importante anche questo, bisogna trovare un modo per fare piccoli pagamenti ai miner senza assumere necessariamente il discorso dell’asta del mining, magari devi riuscire a pagare i miner peer to peer 1 a 1. Quindi sono ostacoli abbastanza forti che nel 2016 fecero considerare questa idea interessante, bella per Bitcoin, ma non necessariamente praticabile.
Giulio
Chiaro. Un’altra cosa che non so se sei d’accordo ad aggiungere è anche magari un eventuale inflation bug, cioè essendo meno trasparente se ci fosse un bug d’inflazione su Bitcoin, essendo tutto molto privato, c’ha l’altro lato della medaglia che non è monitorabile, in un certo senso.
Giacomo
Hai ragione, è lo stesso problema di cose come per esempio Zcash dentro le pull shielded ZKsnarks oppure di liquid dentro confidential transaction di Monero. Un bug di inflazione come ne sono capitati per esempio Zcash non è detectabile in maniera ovvia, perché tutta la rete non lo vede, lo vede solo chi riceve. Ora la versione ovvia della client side validation, tu mi mandi la prova offchain dei fondi che hai ricevuto, i quali vanno indietro nel tempo fino ad una prova di lavoro originale in un blocco. Quindi in realtà io posso calcolare immediatamente la supply, ma in realtà è meno sicura come garanzia rispetto a un consenso pubblico, un consenso globale.
Giulio
Chiaro, è più difficile.
Giacomo
Inoltre è stata aggiunta anche una cosa che Peter non aveva presentato nel 2016, ma su cui si ragionava, infatti esiste in RGB l’idea già che ci mandiamo delle prove offchain, mettiamole anche crittograficamente offuscate, cioè se io ti mando una prova che ti sto pagando e ti mando anche la prova di qualcuno che ha pagato me e di qualcun altro che ha pagato quel qualcuno e così via fino alla Coinbase, magari le prove passate le posso oscurare con crittografia avanzata come per omomorphic, come per esempio le confidential transaction, eccetera. Che infatti è quello che facciamo in RGB. Questo chiaramente crea il problema che tu dici, il problema di possibilità di avere bug inflattivi, assolutamente sì.
Giulio
Chiaro. Prima avevi parlato del client side validation che di fatto è mettere un po’ una struttura logica nella Blockchain, quindi fare un po’ un timestamp, però che differenza c’è tra un timestamp normale e la tecnologia che utilizza RGB, che non è un timestamp normale, che cos’è e come funziona?
Giacomo
Sì, la differenza è tra quella che viene chiamata proof of existence, che usa per esempio la timechain di Bitcoin per dimostrare l’esistenza di un dato e proof of unicity o proof of publication che dimostra la non esistenza di un dato concorrente con una cosa molto diversa. Facciamo un esempio, appunto. Sempre Peter Todd, insieme a Riccardo Casatta e alcuni altri sviluppatori hanno consolidato e diffuso lo standard open time stamps per la notarizzazione su Bitcoin. Potete andare su https://opentimestamps.org/ e potete usare quel sito per notarizzare qualsiasi cosa sulla timechain di Bitcoin. Ora che cosa si può fare con questo? Per esempio, assumiamo che ci sia un medico, questo medico ha una cartella digitale del paziente, la cartella clinica e deve decidere se dare un farmaco A un farmaco B. Ovviamente la sua firma digitale che dimostra la non revocabilità ecc., quindi che è stato lui a prescrivere quel farmaco, quindi ha la sua chiave e firma la cartella. Poi però quando scoppia il macello perché dato il farmaco A che in realtà era sbagliato, chiaramente lui può usare la sua firma digitale anche per pre-datare un’altra cartella in cui dava invece farmaco B e potrebbe magari convincere il gestore del database dell’ospedale a inserire nel database questa seconda cartella invece della prima. Non esiste una prova crittografica del timing senza solo una prova della conoscenza della chiave, ma al tempo non ha dimostrato crittograficamente.
L’idea della proof of existence è che tu prendi la cartella clinica, li file hash di questa cartella clinica, metti questo hash dentro per esempio OP_Return in un blocco di Bitcoin al momento della prescrizione del farmaco, un anno dopo potrai sempre dimostrare che questa tua cartella clinica esisteva in quel momento. Ma attenzione, non abbiamo risolto il problema della cartella clinica, perché tu puoi mostrare questo documento e mostrare che su hash era nel blocco X, quindi che esisteva quel documento, ma non puoi dimostrare in questo modo che non esistesse in un altro hash un documento che diceva il contrario, cioè la prescrizione del farmaco A. Facciamo un altro esempio, anzi questo è un esempio carino perché nel 2016 c’era una start up in Blockchain Lab che diceva di usare la Blockchain per dimostrare la fairness delle proprie previsioni di prezzo con i propri algoritmi evolutivi, genetici, di previsione del prezzo e c’è stato un grande dibattito al riguardo, perché in effetti non dimostrava niente l’uso che facevano della Blockchain. Sostanzialmente, io sono un trader, devo dirti se domani Bitcoin sale o scende in termini di dollari. Io dico che sale, lo firmo con un messaggio e lo hasho. Poi dico che scende, firmo e hasho. In un op-return io metto il commitment, metto praticamente l’hash dentro la op-return del documento che dice che scende e nessuno può leggere cosa c’è scritto dentro. Nell’altro metto quello in cui dice che sale e nessuno può leggere cosa c’è scritto dentro. Quando poi sale, rivelo il secondo e quando scende rivelo il primo. Quindi timestamping è un’ottima cosa per dimostrare che un documento esisteva nel passato e il timestamping può servire, per esempio per i diritti d’autore, per robe tipo la SIAE, i brevetti, cioè io devo dimostrare che esisteva qualcosa. Per esempio io faccio una faccio una scoperta, ne faccio l’hash, metto sulla Blockchain, poi dopo un mese la dichiaro, e qualcuno dice “No, io ho scoperto una settimana prima” e io dico “Ah si? Io l’ho scoperto un mese prima, ecco qui la dichiarazione che avevo timestampato”. Dimostri l’esistenza, ma non puoi dimostrare la non esistenza del claim contrapposto, di un claim rivale rispetto a questo. Per dimostrare l’esistenza del claim rivale devi dire qualcosa in più. Per esempio devi dire “Guardate che tutti gli hash pubblicati in OP_Return da quell’indirizzo Bitcoin riusato saranno le mie previsioni. Così se metto un hash che dice che poi dice che Bitcoin sale ma ne mette anche un altro, tutti mi vedono e mi sgamano che sto mettendo due hash sotto la mia stessa chiave pubblica e quindi mi dicono “Sì, ma rivela anche l’altro adesso” quindi la differenza è che nel timestamping la prova di esistenza la proof of existence, io praticamente posso aggregare infiniti documenti, non solo hash, infatti se voi andate in Open Time Stamps voi potete mettere documenti di due gigabyte, non importa quello che fa il programma è fa un Merkel tre, quindi fa un albero aggregato di hash, prende l’hash padre, lo mette sulla Blockchain, solo quello, ne può aggregare milioni di documenti, e poi tu con il percorso di Merkel puoi dimostrare l’esistenza.
Invece la proof of publication o proof of univocity o uniqueness, ha mille nomi, io volte le chiamo time sealing, quindi single use seal come la chiama Peter Todd, questa è una cosa diversa. Dice che in quel momento li non solo quest’informazione esisteva, ma ti dimostro che non avevo dichiarato che l’unica dichiarazione che ho fatto su quell’ambito è stato pubblicato in questo contesto e non ho pubblicato dichiarazioni alternative rispetto allo stesso oggetto. Quindi, per esempio, la cartella medica viene hashata e l’hash viene messo in una transazione che è l’unica transazione fatta da quella chiave pubblica e qualsiasi altra transazione fatta con la chiave pubblica è evidente, viene vista. E non metto una Merkel root, metto proprio un hash intero. Ho fatto un discorso un po’ nel merito tecnico, ma le cose da portare a casa secondo me sono due. Primo, la proof of existence, la notarizzazione dimostra che un documento esisteva, ma non dimostra che non esisteva un documento che diceva il contrario. Invece la proof of publication o time sealing dimostra che non esisteva un documento contrapposto in un dato ambito.
Ma la proof of existence, quindi il time stamping è infinitamente scalabile e privato. Posso aggregarlo tranquillamente, costa pochissimo con un solo hash nella Blockchain o senza neanche l’hash per esempio con pay to contract con taproot posso dimostrare l’esistenza di milioni di documenti. Invece la proof of publication, proof of uniqueness, quindi la prova che non c’è concorrenza, quindi il time sealing, diciamo così, quello non è scalabile. Per ogni claim mi serve una specifica chiave pubblica spesa onchain sostanzialmente, quindi, questa è la differenza fondamentale.
Bitcoin per funzionare non ha bisogno di time stamping, ha bisogno di time sealing del single-use seal, quindi deve dimostrare la pubblicazione, non deve dimostrare l’esistenza di una transazione, non deve dire “Questa transazione esisteva in questa data”, deve dire “Questa transazione esisteva e la transazione concorrente sullo stesso UTXO non esisteva in questo ambito di pubblicazione”. Questa è la differenza fondamentale e questa seconda cosa non è scalabile. Client side validation la rende un po’ più scalabile, perché, per esempio, in questa seconda cosa non pubblico tutto, gli input, gli output, lo script, lo witness, pubblico solo un pezzettino e il resto lo lascio invece committato, lo lascio semplicemente come dipendenza crittografica.
Giulio
Ottimo ottimo, quindi potremmo dire che di fatto questi single use seal che in italiano “sigilli monouso” – che magari rende un po’ più chiaro il concetto – di fatto prevengono la doppia spesa che è proprio il problema che risolve il protocollo Bitcoin.
Giacomo
Precisamente quello, la doppia spesa nel caso anche dell’esempio che ho fatto sulla doppia spesa della reputazione del medico, sulla cartella clinica o, nel caso di Bitcoin, la doppia spesa di un UTXO Bitcoin.
Giulio
Chiaro.
Giacomo
Il single use seal è il braccialetto che vi mettono quando entrate per esempio in alcuni concerti o in alcune conferenze, emettono questo braccialetto che una volta che viene chiuso non si può più riaprire e chiudere, si può aprire una volta sola. Vi mettono un braccialetto, voi lo potete tagliare o strappare, ma se lo tagliate o strappate è difficile da re-incastrare, si vede, è difficile da incollare. Quindi è una cosa che può essere chiusa una volta sola attorno a un polso e poi per essere riaperto deve essere rotto per sempre. E questo è il single use seal. È una roba che viene chiusa attorno a un dato, ma non può più essere riaperto e richiuso attorno a un altro dato. E questo, nel caso del braccialetto di plastica, è una difficoltà fisica. Devi tagliare, poi devi incollare, è molto difficile, si vede. Nel caso invece della transazione Bitcoin, una difficoltà ovviamente computazionale, crittografica, se tu chiudi un single use seal sopra uno stato che vuol dire pubblichi un UTXO di output di quello stato, poi dopo per spezzare questo sigillo devi spendere questo UTXO e non potrai più spenderlo di nuovo, è stato speso una volta sola.
Giulio
E questo rimane giusto, perfetto, quasi magico, perché Peter Todd non ci aveva pensato prima?! Quindi possiamo un po’ riassumere, cos’è RGB? Abbiamo gettato un po’ le basi, abbiamo spiegato, abbiamo gettato po’ le fondamenta. Però se vogliamo risponde la domanda: che cos’è RGB?
Giacomo
Allora le fondamenta di questa cosa erano interessanti, ma come dicevamo c’erano grossi problemi, il primo dei quali era che non si può cambiare Bitcoin in questo modo, un cambiamento troppo grosso, quindi, era assurdo. Allora, quando un cliente, la società Poseidon in Svizzera mi aveva incaricato come Blockchain Lab a Milano nel 2017, quindi, un anno dopo la presentazione di Peter a Milano, mi aveva incaricato praticamente di descrivere qual era il migliore sistema di asset su Bitcoin. Forse non tutti gli ascoltatori sanno che i famosi NFT che adesso vanno per la maggiore su altre blockchain, sono stati inventati su Bitcoin con cose come counterparty, e anche le cosiddette stablecoin sono state inventate su Bitcoin con protocolli tipo Omni e il lavoro che ci era stato richiesto era di descrivere quali sono questi protocolli e qual era il migliore. Io ho assunto Peter Todd per lavorare con me su questo report e il report che è venuto fuori è stato praticamente che nessuno è decente, fanno tutti abbastanza schifo. Perché? Perché una cosa come counterparty o Omni richiede di mettere dentro la transazione Bitcoin come un dato ulteriore, non validabile dai nodi e dai miner, perché nodi e miner non san niente di counterparty e di Bitcoin e quindi praticamente metto delle informazioni ulteriori, le quali sono utilizzate da un meta protocollo, da un nodo on top per estrarre delle informazioni ulteriori, per esempio sugli NFT o sulle stablecoin, eccetera eccetera.
Facciamo un esempio, noi stiamo giocando a battaglia navale e per giocare a battaglia navale ci mandiamo dei bonifici avanti e indietro e nella causale ci scrivo: “A4” e tu mi rispondi “Colpito e affondato”, nelle causali dei bonifici. Chiaramente stiamo usando una cosa grossa e costosa, nel caso dei bonifici i costi sono burocratici di Sepa, però nel caso di Bitcoin sono i costi tecnici della timechain, per mandarci una cosa di cui tanto il registro fondamentale non sa che farsene, non è utile, è utile solo tra me e te. Molto meglio mandare tra me e te i messaggi direttamente. Allora Peter sostanzialmente dice: “Per i cosiddetti token o i colored coin, come venivano chiamati ai tempi, la client side validation sarebbe il modello migliore, cioè, perché usare Bitcoin mettendoci sopra tutte le informazioni relative a questi smartcontract, a questi token, a questi collectibles, a questi stablecoin? Mettiamoci soltanto l’hash su Bitcoin e basta e la transazione vera e propria di questi token ce la mandiamo offchain io e te, quindi se io ti devo mandare un rare pepes che erano gli NFT del 2015, 2016, 2017 su Bitcoin, io non scrivo, non faccio l’hash dell’immagine e la metto sulla Blockchain di Bitcoin dentro l’OP_return con tutte le altre caselle, cosa che aveva creato anche dei conflitti, perché chiaramente gli sviluppatori di Bitcoin non volevano che si abusasse in questo modo della blockchain. C’era questo dibattito già ai tempi che era un po’ un antesignano del block size work. Praticamente gli sviluppatori di counterparty dicevano: “Allargate l’op return così c’è più spazio, possiamo metterci tutte le nostre cose che ci servono per la nostra meta-Blockchain, per il nostro meta protocollo”, e gli sviluppatori di Bitcoin dicevano: “No, non lo facciamo perché state abusando, se voi fate così tutti i nodi Bitcoin da qui all’eternità dovranno scaricarsi i dati che non riguardano Bitcoin, ma riguardano il vostro protocollo separato e non ci interessa, perché poi diventa un costo ulteriore per i nodi”. E quelli di counterparty rispondevano: “Sì, ma tanto noi paghiamo le fee per metterli onchain” e gli sviluppatori Bitcoin corrispondevano: “No, attenzione voi pagate le fee ai miner, ma in Bitcoin tutti i nodi – non solo i miner – devono scaricarsi, validarsi, devono consumare banda e CPU per scaricare e validare tutto e quindi sostanzialmente se voi sovraccaricate questa cosa tutti pagano per validare, non soltanto i miner.
Voi pagate i miner, ma è il mio nodo che deve comunque validare se tutto ha un problema di banda e un problema di validazione che voi non potete compensare, quindi non vi allarghiamo l’op return”. E allora quali rispondevano: “E allora noi useremo gli output e codificheremo le nostre cose dentro le firme”. C’era tutta questa battaglia, e Todd, giustamente nel report diceva: “Questo è il caso d’uso perfetto per la client side validation. Siccome intanto i miner di Bitcoin non gliene frega niente di cosa c’è dentro l’op return, i miner di Bitcoin non sono nodi counterparty, quindi non vedono, non guardano cosa c’è scritto dentro, è inutile scrivercelo dentro. Usare la timechain di Bitcoin con un sistema di prova di pubblicazione, per fare da storage di roba che serve solo a due persone, è assolutamente inutile. Il colored coin perfetto è client side validated”. Quindi se io ti devo dare un rarepepe, lo strumento intelligente è quello in cui io passo a te tutta la prova di trasferimento dei rarepepe, del NFT o di quello che deve essere, e poi sulla sua transazione Bitcoin mettiamo solo una proof of publication, una single use seal, un sigillo a utilizzo unico, ed è l’unica cosa che facciamo. Così non sporchiamo la Blockchain e addirittura possiamo farlo senza neanche scrivere in op return, possiamo farlo con altri sistemi più raffinati che non consumano anche spazio onchain.
Questa è una bella idea avuta da Peter ed è stata il contenuto di questo report. Il cliente ci ha chiesto: “Ma quindi sarebbe fattibile questa cosa qui?” E noi l’abbiamo chiamata RGB che è lo schema dei colori, perché ai tempi era un’evoluzione del sistema colored coin, quindi dagli output colorati, che voleva dire rappresentativi di un asset, noi abbiamo creato un intero sistema di primitive che scambiavano questi asset al di fuori della Blockchain. Quindi RGB, un nome pensato insieme a Riccardo Casatta, che aveva lavorato anche lui insieme a questa prima idea. C’è però anche un terzo problema. Scusami parentesi – perché ci eravamo interessati dei token? – ne a me, ne a Riccardo, ne a Peter fregava assolutamente nulla dei gattini spostabili sulla Blockchain o delle stablecoin ce ne fregava veramente poco. Il punto vero è che se si riusciva a fare un sistema di token basati sulla client side validation un domani che trovassimo un metodo per fare due peg tra Bitcoin e qualcos’altro, per esempio una sidechain trustless che ancora non siamo riusciti a trovare un modo, ma se riuscissimo a trovarlo, allora si potrebbe creare un token Bitcoin su questo RGB, farlo two-way peg con Bitcoin e avremmo Bitcoin che diventa client-side validated come Peter lo immaginava con i vantaggi di privacy, censorship resistence, scalabilità senza dover cambiare il protocollo Bitcoin sostanzialmente. Quindi introdurre questo design on top come second layer, senza però effettivamente andare a modificare Bitcoin, quindi una cosa ottima.
Il nostro scopo era ed è tutt’oggi immaginare il token RGB come qualcosa che un domani non sappiamo quando, quando troveremo il modo di fare un two-way peg, oppure con un one-way peg, per esempio le space chain, ma poi ne parleremo, potremo avere un Bitcoin client side validated. Allora il secondo problema, il terzo problema rimanevano che erano, ok, avete questa proposta di RGB, ma rimane il problema che devi essere online per ricevere, sincronicamente, che è un’esperienza utente schifosa e devi backupparti tutto, se no perdi tutto che è un’esperienza utente schifosa. Li c’è stata la mia idea che ho aggiunto alla conversazione che è stata: va bene ragazzi, ma queste due limitazioni sembravano terribili nel 2016, ma oggi nel 2018, quando ho cominciato a sviluppare l’idea, sono limitazioni che già esistono e sono già affrontate per lighting network che richiede a tutte le due parti di essere online contemporaneamente sincronicamente per passarsi il pagamento. Tu non mi puoi dare un’invoice e poi sparire. Magari un giorno potrai con sistemi tipo lighting road, ma per ora tu devi essere online per ricevere soldi. Non solo è pure peggio. Con lightning devi anche tornare online frequentemente per non farti fregare dai vecchi stati, quindi deve anche essere online spesso. Invece con RGB devi solo essere online una volta insieme all’inviante e poi puoi riuscire a ricevere. RGB ha meno problemi di lightning. La client side validation ha meno problemi di lightning di sincronicità. Anche il backup su lightning, il tuo seed da solo non conta più niente. Tu non salvi i tuoi soldi se hai il tuo seed, devi anche backupparti il canale, ma pure peggio di RGB e client side validation, perché su lightning se backuppi male il tuo canale e tipo fai un errore di backup e bloccassi uno stato più vecchio ti parte la transazione di punizione che ti frega tutti i soldi del canale.
Quindi le sfide di backup di lightning e le sfide di ricezione sincrona di lightning sono uguali a quelle del RGB, ma peggio. Quindi la mia idea era: attacchiamoci allo sviluppo di lightning, seguiamo quello che fanno loro, gli stessi standard, alle stesse robe. Addirittura su lightning c’è gente che comincia a mandarsi in giro file dentro lightning, messaggi dentro lightning, come per esempio Sphinx Chat o WhatsAtt o robe del genere. Bene, noi dobbiamo mandarci in giro le prove crittografiche? Non stiamo a inventarci un nuovo sistema, attacchiamoci a lightning e i messaggi di lightning conterranno anche le prove offchain di RGB. Quindi l’idea di Peter è stata fondere gli shitoken, diciamo così, i token arbitrari con la sua idea di client side validation come esperimento per un domani farci viaggiare un vero e proprio Bitcoin two way peg e la mia idea è stata fondere questa cosa con lightning, perché lightning ha già gli stessi problemi di UX e quindi siccome dobbiamo risolverli per lightning, ci possiamo appiccicare per risolvere anche quelli del RGB che tanto sono più semplici, sono meno seri di quelli di lightning.
E così è arrivato RGB, il cui acronimo nessuno ha mai capito cosa vuol dire, nel senso che era nato come derivato da colored coin, quindi i colori e ora, diciamo così, abbiamo avuto un po’ di idee di retro continuity per metterci dentro dei significati, ma nessuno sa bene cosa vuol dire. Tutti i nomi del progetto RGB sono un po’ simili, fanno giochi di parole sui colori. Per esempio esiste Bifrost che è il nome di arcobaleno vichingo, esiste Iris, di cui poi magari accenneremo che il Wallet creato da Federico Tenga e il suo team dentro BitFinex che fa questo esperimento di RGB; esiste Kaleidoscope che era un’altra cosa ancora, Spectrum, son tutti nomi sui colori dello spettro visibile, perché è rimasta la tradizione. Però in realtà di fatto si tratta di un esperimento di inserire la client side validation di cui abbiamo parlato usando come pretesto gli asset, i token. Se funziona coi token poi lo faremo anche un domani, su una side coin di Bitcoin e poi aggiungerci una fusione con lightning network perché abbiamo gli stessi problemi, anzi su lightning sono più gravi.
Giulio
Ottimo. Ci siamo quasi. Ho ancora altre domande però te ne rubo due. Una, magari in risposta secca e veloce, giusto per un piccolo chiarimento e un’altra, magari anche un po’ più conclusiva. Poi magari faremo anche un’altra live con RGB parte due. Per quanto riguarda la cosa che era molto interessante quella di applicare le proprietà di un RGB venti, chiamiamolo così a Bitcoin no? Hai detto che attualmente non c’è una tecnologia che permette un peg trustless, quindi un cambio da Bitcoin così com’è, a un Bitcoin con client side validation, ma neanche con un soft fork o con un hard fork, cosa che mi rendo conto che è probabilisticamente nulla no, però neanche con un hard fork del protocollo si riuscirebbe a livello teorico, non dico che sia fattibile poi nella teoria dei giochi portarlo avanti, però a livello semplicemente tecnico.
Giacomo
Allora sì, ma non con un soft fork che saremmo già in grado di scrivere ora. Mi spiego. La prima idea di sidechain che era stata pensata usava un sistema tipo SPV, quindi l’idea era “fidiamoci dei miner”, cioè se i miner dicono che lo stato della sidechain è corretto, allora ci fidiamo. Allora, che cos’è una sidechain? Tu blocchi un Bitcoin sulla timechain di Bitcoin in qualche modo, la blocchi con qualche script di qualche tipo. A questo punto la sidechain che ascolta la rete Bitcoin sa che un coin è stato bloccato, genera un sidecoin. Questo sidecoin si muove dove vuole in giro come vuole, a un certo punto questo sidecoin viene distrutto e la distruzione di questo sidecoin deve sbloccare in qualche modo il maincoin sull’indirizzo diverso però, su un indirizzo arbitrario che è deciso dal possessore del sidecoin. Allora come si fa a fare questo two-way peg? La prima idea era facciamolo SPV cioè facciamolo in modo tale che se sostanzialmente i miner di Bitcoin minano un certo modo, noi usiamo delle prove compatte di presenza dei blocchi per sbloccare. Ma questo voleva dire fidarsi dei miner, e il clima politico, soprattutto del block size wars e la centralizzazione del mining che c’è stata in Cina prima e negli Stati Uniti adesso, l’intervento pesante di BitMain come monopolista dell’hardware che ha cominciato a cercare di influire sul protocollo sono tutte cose successe dopo che hanno reso gli sviluppatori e gli utenti Bitcoin molto guardinghi sull’idea di dare potere politico ai miner. La proposta successiva è stata quella del drivechain, che richiederebbe un soft fork che dice, visto che tanto ci dobbiamo fidare dei miner, fidiamoci in maniera esplicita, cioè creiamo un opcode, non è proprio opcode, ma tipo un opcode che è una hash-rate escrow, cioè creiamo una possibilità nello script di Bitcoin di bloccare dei Bitcoin dicendo, questi bitcoin verranno sbloccati verso qualunque indirizzo in cui la maggioranza del mining approva e l’idea è che la maggioranza del mining avrebbe un incentivo di teoria dei giochi di approvare solo quegli indirizzi che corrispondano allo stato della sidechain. Ma non c’è nessun enforcement di questo, non c’è nessun modo di garantire questa cosa qui. La risposta è facciamo un non uasf, quindi forkiamo via i miner se non rispettano sta cosa, ma questo è del tutto irrealistico perché vuol dire che tutti gli utenti Bitcoin ora devono anche scaricarsi la sidechain per poter sapere se lo sblocco è giusto oppure no.
Quindi, non dico che l’idea di drivechain sia non fattibile su Bitcoin, ma non è una soluzione trustless, è ancora una soluzione trusted. Allora blockstream si è spostato sulla federazione, quindi abbiamo un gruppo e una federazione di utenti con delle macchinette HSM che è un po’ l’idea di Al Finney nel 1998 con reusable proof of work, cioè usare delle macchine che tamper resistant, delle macchinette tipo hardware wallet che è molto difficile manipolare e che firmano insieme in tante giurisdizioni. Però anche questa è una soluzione poco censorship resistant. Se io sono uno Stato e vado da Liquid e metto in galera due federati Liquid gli altri venti federati Liquid spariscono e smettono di firmare i blocchi in cinque minuti, non hanno incentivo di andare avanti. Invece il mining è diverso, se io metto in galera i miner, altri miner arriveranno perché sono incentivati dalle fee e dal subsidy per fare takeover. Quindi per ora la federazione funziona perché funziona, ma è molto fragile per fare il pegging, e invece fidarsi dei miner non è trustless anche quello comunque.
L’idea trustless completamente arriva in realtà dal 2013, Gregory Maxwell l’aveva chiamata coin witness nel 2013 e l’idea era, le Zero Knowledge Proof, queste stesse cose che fanno funzionare confidential assess su liquid con bulletproof che poi è stato copiato con le confidential transactions su Monero o ZCash, che ha usato le ZK Snarks quindi ZK Snarks, ZK Starks, ZK Booze, Bulletproof, tutte queste zero knowledge proof potrebbero evolversi fino ad arrivare ad una zero knowledge proof incredibilmente generale in cui, in maniera compatta, la rete Bitcoin potrebbe dare prova di tutta la storia della sidechain senza scaricarsi da sidechain. Quindi questo sarebbe un soft fork in cui introdurremo in Bitcoin un nuovo sistema di zero knowledge proof che in maniera compatta constant time può provare tutta la storia della sidechain senza saperla. Quindi zero knowledge. Questo è teoricamente possibile con un soft fork di Bitcoin, ma siamo lontanissimi da tecnologie che sono in grado di farlo in maniera efficiente. Ci sono un po’ di esperimenti tipo i vari ZK rollup sulle shitcoin, che sono ancora lontani anni luce da qualcosa di generalmente applicabile in questo senso, quindi è possibile farlo, ma siamo ancora molto lontani.
Inoltre rimangono dei problemi tipo dimostrare l’assenza, rimangono alcuni problemi teorici fondamentali. Non sappiamo se ci saranno soluzioni migliori di questa, un’alternativa proposta anche da me tanti anni fa ma soprattutto più recentemente, da Ruben Somsen, che è stato anche più bravo a dargli un nome, si chiamano spacechain e l’idea è, evitiamo direttamente di fare two-way pegging, facciamo un one-way pegging. Quando tu bruci dei bitcoin, quindi proof of burn perpetua. Quanto tu bruci un Bitcoin generi un sidecoin. E poi questo sidecoin non può più tornare Bitcoin, rimane lì, ma questo è molto meglio di creare un altcoin, perché anche se non è una sidechain, però perlomeno non compete con la supply di Bitcoin, non c’è inflazione infinita, perché un numero massimo di sidecoin sarà 21 milioni, perché ogni volta che ne crei uno devi bruciare un Bitcoin. E ogni volta che tu vai su questa spacechain tu togli domanda a Bitcoin, ma togli anche supply perché bruci dei coin, e quindi non cambia prezzo di Bitcoin, non va a far concorrenza al valore di Bitcoin.
Questo è carino soprattutto se pensiamo che la nostra sidechain sia così superiore a Bitcoin che il mercato migrerà lì. È un modo per fare tipo un upgrade di Bitcoin senza fare un hard fork o un soft fork. Creo un nuovo Bitcoin, fai una proof of burn e chi vuole si sposta lì e poi puoi swappare avanti e indietro e man mano se questa rete è migliore di Bitcoin, l’intero valore di Bitcoin si sposterà di lì e la rete principale rimarrà quasi in disuso, ma rimarrà sempre pronta anche in caso di collasso di questa nuova cosa si torna indietro semplicemente, tutti quelli che sono andati la han perso soldi e quelli che sono rimasti di cui sono rimasti saldi.
Giulio
Una soluzione un po’ malvagia.
Giacomo
Ma se è dichiarata non è malvagia.
Giulio
Chiaro.
Giacomo
Nel senso, se è dichiarata è un rischio che uno si prende. Per esempio, noi potremmo farlo domani un RGB, quando RGB fosse pronto. Noi potremmo fare una spacechain RGB, cioè se tu dimostri di aver bruciato un Bitcoin hai un RGB coin e questo RGB coin non è premine non è una ico, ecc., è la prova di aver distrutto Bitcoin. Non puoi mai trasformarlo in un Bitcoin onchain, ma se dopo anni RGB funziona da dio Bitcoin si è spostato praticamente di là. Se invece non funziona, chi si è spostato di là venderà sotto prezzo, farà uno swap, ma a un prezzo minore che andrà a zero come tutte le altre shitcoin.
Giulio
Chiaro. Ti rubo solo l’ultima domanda, poi ci faremo perdonare. Giusto per riequilibrare un po’ il discorso su RGB per i fan degli smartcontract, quindi, generalizzare il discorso. Con RGB quindi è possibile fare delle automatic market maker tipo UniSwap che scalano meglio, o delle soluzioni come MakerDAO, quindi un criptodollaro decentralizzato, appunto? Questi prodotti che già esistono su rete come Ethereum ad esempio, sono replicabili quindi anche con tutti i vantaggi che porta RGB?
Giacomo
Adesso mi sono ricordato che la domanda precedente dovevo risponderti con un sì e no. Andiamo finchè serve, perché comunque va bene. Se non hai limiti stretti tu, finiamo bene.
Giulio
No, no.
Giacomo
Concludiamo bene queste domande qui. Allora innanzitutto, per esempio, ne accennavamo prima tra di noi, molti sapranno che il design di RGB è stato copiato sostanzialmente da lighting labs con un progetto che si chiamava CMYK quindi RGB sono i colori additivi, CMYK sono i colori ciano, magenta, yellow, black, quindi i colori sottrattivi della stampante e il loro progetto CMYK poi rinominato Taro ed è praticamente RGB. Ma in realtà adesso, dopo il lancio che è stato fatto a Miami in realtà lo scorso aprile, i due progetti hanno cominciato a divergere un pochettino, un po’ perché RGB siamo poveri e invece Taro hanno raccolto 80 milioni, ma un po’ soprattutto perché RGB, Maxim Orlovsky che è uno degli sviluppatori principali, si sta concentrando sul concetto di smartcontact generalizzato. Lui dice tutte quelle supercazzole che abbiamo sentito su i work computer, linguaggi touring complete, tutte ste cose qui non si devono fare onchain, come gli sviluppatori Bitcoin già spiegavano a Buterin e gli altri nel 2015. Anzi è peggio farle onchain, è una cosa assurda, perché ci sono problemi di scalabilità di privacy, di sicurezza. Ma se li facciamo offchain con il sistema client side validated, quindi con RGB è una bella idea invece farli. Questa in realtà segue un trend se ci pensi bene, molto più generale di Bitcoin. Pensa al modo in cui vengono fatti gli smartcontract su Bitcoin oggi e nel 2009. Nel 2009 facciamo che io ti devo mandare un coin che puoi spendere tu oggi o tua mamma tra un mese o tuo zio tra un anno. Come facevamo nel 2009? Tu mi dai la tua chiave pubblica, mi dai la chiave pubblica di tua madre, la chiave pubblica di tuo zio, e creiamo un output che dice, la tua chiave pubblica oggi o quella di tua mamma tra un mese o quella di tuo zio tra un anno, e scriviamo tutto lo smartcontract nell’output. Questo è male, perché prima di tutto tutti, a livello di privacy, tutti sapranno dove sono andati questi coin come contratto, in un contratto pubblico che tutti sanno i fatti tuoi e dei tuoi eredi che non va bene, è un problema di privacy, anche di censorship resistant.
Poi problemi di scalabilità perché questa roba qui entra nella Blockchain subito, adesso, appena avere minata la transazione, in più rimane nell’ UTXO set, cioè nel set degli ultimi stati validi per sempre, finché non verrà spesa con tutto il mappazzo. Quindi tu nel tuo database dei UTXO set devi tenerti tutto il contratto gigantesco. Io ora te l’ho fatto con tre opzioni, ma se erano 100 per esempio diventava molto impegnativo come scalabilità. Poi magari voi sparite tutte e tre, perdete le chiavi e non verrà mai speso e quell’UTXO rimarrà per sempre, con tutto il contratto sull’output della blockchain. Da lì si è passati a pay to script output p2sh – gli indirizzi Bitcoin comincia col tre – che sono più smart perché dicono, tu crea il contratto io o mia mamma dopo un mese o mio zio dopo un anno, fai l’hash di questo contratto, di questo script, e io non pago verso il contratto nell’output. Io pago l’hash, io nell’output metto solo “chiunque mi porti lo script che ha questo hash e poi mi risolve lo script può spendere”, e solo nell’input quando tu andrai a spendere riveli l’intero contratto e quindi praticamente nell’UTXO set entra solo l’hash. Nella Blockchain entra solo l’hash e quando andrai a spendere metterai nella Blockchain invece le condizioni complete di spesa che peraltro andranno nel witness program che può essere più facilmente clonato.
Quindi un passo avanti che toglie i contratti dalla Blockchain. MAST – quindi Merkelized Abstract Syntax Tree – è un altro passaggio avanti che dice, ma perché quando spendo questo contratto devo rivelare tutti e tre i casi, il mio, quello di mia mamma e quello di mio zio? Perché non faccio un Merkel tree invece di un hash? E quando spendo rivelo soltanto il branch, la foglia che ho usato e l’hash del resto senza rivelare tutto quanto. Quindi questo è un altro passaggio per tirare via dalla Blockchain lo smartcontract. Taproot è un passaggio ulteriore avanti perché dice, facciamo un MAST, quindi facciamo un Merkel tree degli script e un Merkel root invece dell’hash, ma oltre a quello mettiamo una chiave pubblica, che può essere la somma della chiave pubblica di tutti i partecipanti. Così, nel caso d’uso tipico in cui siamo tutti d’accordo, tu, tuo zio e tua mamma firmate insieme, sommate le firme e sulla blockchain si vede solo una firma di una chiave pubblica e solo in caso di disaccordo tirate fuori una delle varianti. Quindi, se vedi c’è una progressione che va da, metti tutto onchain a metti onchain solo i commitment che servono, solo quando servono, metti sempre meno e sempre meno, sempre meno. RGB è l’estremo di questo. Quando spendi non mettere onchain niente, neanche una branch di taproot, tu metti un chain soltanto, il commitment di qualcosa che ti passi peer to peer e il contratto te lo tieni completamente off chain e usi la Blockchain solo per evitare il double spending e non per storare nessuna parte del contratto, non per guardare la validità. In questo senso l’idea di Maxim Orlovsky è che, se vai completamente off chain in questo modo qui non hai problemi di scalabilità perché appunto peer to peer ci possiamo mandare un contratto di sei gigabyte, non importa. Non hai problemi di latenza per esempio, perché dobbiamo aspettare il mining, possiamo passarcelo in uno state channel tra noi due, immediato come lightning, non hai problemi di privacy, possiamo fare contratti che nessuno andrà a vedere, non hai problemi di censura, di front running i miner che fanno front running sui contratti, come succede per esempio in Ethereum.
Tutti questi problemi non ce li hai e inoltre hai meno problemi di sicurezza, perché se facciamo un opcode sbagliato perché viene fuori un baco, un’imprecisione, un problema di sicurezza, semplicemente non va a impattare la Blockchain, non è scritto sulla Blockchain. È scritto in un contratto privato che può essere più facilmente aggiornato pezzo per pezzo, è un consenso locale non globale. Quindi l’idea di Maxim Orlovsky è una roba tipo Turing Complete stile Solidity EVM sulla Blockchain è una brutta idea e su questo tutti i developer Bitcoin principali sono d’accordo. Ma la stesso livello di complessità fatto su RGB non è più una brutta idea, perché lì effettivamente è tutto locale. La domanda quindi per concluderla è: si può fare un contratto complesso come UniSwap su RGB? Risposta: sì, è banale in realtà perché UniSwap non è complesso. Io posso fare una transazione Bitcoin che swappa un UTXO Bitcoin che contiene un commitment RGB con un altro UTXO Bitcoin, quindi posso darti un rare pepe al RGB e tu in cambio mi dai dei Bitcoin. Oppure posso darti dei Bitcoin su RGB e tu in cambio mi dai una rare pepe. Quindi da questo punto di vista non c’è un problema di creare uno swap, creare maker DAO è un po’ più complicato perché ci sono cose più statefull, cioè c’è uno stato attuale del contratto. In Ethereum e in altre shitcoin che copiano Ethereum lo stato viene replicato su tutti i nodi della rete, e questo lo rende non scalabile, non privato e non sicuro. Invece in RGB, lo stato globale è condiviso soltanto tra i partecipanti di questo network. Per esempio, uno dei modi con cui Maxim intende replicare questi contratti complessi è, tutti i partecipanti dei contratti, creando una sorta di canale multi party su RGB tra di loro e crea questa sorta di canale gerarchico simile a lightning. Quindi un concetto opposto se vogliamo. Puoi creare robe del genere, molto più complesse, quindi possibilità maggiori di errori, bacchi di complessità, anche più difficoltà nel lanciarle, ma se funzionano, funzionano a scala, con buona privacy e molto tolleranti anche ai bachi, perché tutto il consenso locale puoi fixarlo localmente. Invece non puoi fixare un contratto che tutti i nodi dovranno replicare per sempre, quindi molto meno rischio, per esempio se crei un loop infinito su EVM hai completamente distrutto tutti e sette i nodi Ethereum per sempre. Invece se crei un baco di loop su RGB è un problema locale tra te e la controparte. Potete anche negoziare di rimandare un nuovo cambiamento di stato. Quindi la risposta è sì, può riprodurre praticamente tutti i casi d’uso di un contratto generico con molta più complessità, con alcuni trucchi, non è così pulito, ma con molta più privacy, scalabilità e sicurezza in generale.
Giulio
Ottimo, ottimo. Sono molto soddisfatto della live di oggi perché abbiamo spiegato veramente bene RGB e magari faremo anche una parte parte due, ancora più deep, perchè no? Io ricordo a tutti prima di salutare Giacomo, questo qui è il canale Telegram, se vuole entrare, fare domande, siete i benvenuti. Anche Giacomo se può risponde.
Giacomo
Pensa che appunto potrei non poter rispondere, perché se è un canale pubblico io non posso.
Giulio
Vero, vero. Potete entrare anche nella chat Telegram Bitcoin Italia di Giacomo.
Giacomo
Dove posso rispondere, perché l’ho creata io, quindi Telegram non mi ha bannato dalla mia chat, quindi posso ancora rispondere.
Giulio
Comunque se entrerete in chat, vi giriamo anche il link di Bitcoin Italia, siete i benvenuti. Grazie ancora Giacomo, chiudiamo qui questo episodio di Bitcoin Detox e ci vedremo sicuramente in una delle prossime live. Ciao a tutti.
Giacomo
Perfetto, a presto! Ciao a tutti! Grazie ciao!