Questa è la terza parte di una serie in tre parti in cui Andrew Levine delinea i problemi che devono affrontare le catene di blocco ereditate e propone soluzioni a questi problemi. Leggete qui la Parte 1 sulla crisi dell’aggiornabilità e qui la Parte 2 sulla crisi della scalabilità verticale.
Aggiornabilità, scalabilità verticale e governance: Ciò che tutti e tre questi problemi hanno in comune è che la gente sta cercando di iterare su un’architettura imperfetta. Bitcoin ed Ethereum sono stati talmente trasformativi che hanno totalmente inquadrato il nostro modo di guardare a questi problemi.
Dobbiamo ricordare che sono stati sviluppati in un momento specifico del tempo, e che il tempo è ora in un passato un po‘ lontano, quando la tecnologia a catena di blocchi era ancora agli albori. Uno dei settori in cui quest’epoca si manifesta è quello della governance.
Bitcoin ha lanciato con la prova del lavoro per stabilire la tolleranza ai guasti bizantina e fornire il decentramento necessario per creare un libro mastro senza fiducia che possa essere usato per ospitare il denaro digitale.
Con Ethereum, Vitalik Buterin cercava di generalizzare la tecnologia di base in modo che potesse essere utilizzata non solo per ospitare il denaro digitale ma anche per consentire agli sviluppatori di programmare quel denaro. Con questo obiettivo in mente, aveva perfettamente senso adottare l’algoritmo di consenso dietro la catena di blocco più affidabile: la prova del lavoro.
La prova del lavoro è un meccanismo per ridurre al minimo l’intolleranza alle faglie bizantine – dimostrare la BFT non è così facile come la gente ama fingere. Non è un sistema di governance. Bitcoin non ha bisogno di un sistema di governance perché non è un computer generico. La ragione per cui i computer generici hanno bisogno di un sistema di governance è che i computer devono essere aggiornati.
Non c’è bisogno di una prova più chiara della portata dei cambiamenti previsti per l’Ethereum 2.0 e della difesa aggressiva per l’adozione delle necessarie forchette rigide. Non siamo i primi a segnalare questo problema. I fondatori di Tezos hanno previsto accuratamente questo problema, ma alla fine non sono riusciti a fornire un protocollo che soddisfi le esigenze della maggior parte degli sviluppatori per le seguenti ragioni:
La blockchain è scritta in un linguaggio diverso rispetto ai contratti intelligenti.
Hanno introdotto un processo politico in cui il processo decisionale avviene fuori dalla catena.
Non sono riusciti a fornire un percorso di aggiornamento esplicito on-catena.
Non sono riusciti a stabilire classi distinte che possano fungere da controlli ed equilibri.
L’intelligenza dei contratti intelligenti
Gli sviluppatori devono essere in grado di codificare i comportamenti che vorrebbero vedere nella blockchain come contratti intelligenti, e ci deve essere un processo on-chain per aggiungere questo comportamento al sistema attraverso un percorso di aggiornamento esplicito. In breve, dovremmo essere in grado di vedere la storia di un aggiornamento così come possiamo vedere la storia di un determinato token.
Il luogo appropriato per la governance è quello di determinare quali contratti intelligenti vengono trasformati in contratti „di sistema“ in base al fatto che aumenteranno il valore del protocollo. La sfida è, naturalmente, giungere a un consenso su tale valore.
Il punto più controverso che farò è la necessità critica di classi algoritmicamente distinte che agiscano come controlli e contrappesi l’una sull’altra. Mentre l’intuizione potrebbe suggerire che più classi rendono più difficile il consenso, questo non è il caso.
In primo luogo, se i candidati all’upgrade sono già in esecuzione come contratti intelligenti sulla rete principale, si possono utilizzare metriche oggettive per determinare se l’ecosistema trarrebbe beneficio dal trasformare il contratto „utente“ in un contratto „sistema“. In secondo luogo, se non cercassimo di raggruppare gli upgrade in forchette dure, potrebbero essere frammentari e mirati. Cercheremmo semplicemente di valutare, in modo decentralizzato, se il sistema sarebbe migliorato da un singolo cambiamento.
Controlli e bilanci
È comunemente inteso che in qualsiasi economia, ci sono essenzialmente tre fattori di produzione: la terra (infrastrutture), il lavoro e il capitale. Ogni grande catena di blocco riconosce una sola classe: il capitale. Nelle catene di PoW, coloro che hanno più capitale acquistano il maggior numero di ASIC e determinano quali potenziamenti possono passare. Nelle catene di proof-of-stake e di proof-of-stake delegati, il controllo da parte del capitale è più diretto.
Oltre ad essere problematica in apparenza, l’assenza di altre classi che fungano da controllo sul capitale ha un effetto paradossale che porta alla paralisi politica. Nessun gruppo è omogeneo. Le classi, opportunamente misurate, creano efficienza – non inefficienza – costringendo i membri di una classe a raggiungere un consenso attorno al loro interesse comune.
Senza tale pressione, le sottoclassi (gruppi all’interno di una classe) combatteranno tra loro, portando ad un ingorgo. Classi adeguatamente progettate motivano i loro membri a raggiungere un consenso interno in modo da poter massimizzare la loro influenza sul sistema rispetto alle altre classi.
Se possiamo codificare le singole classi che rappresentano le infrastrutture, lo sviluppo e il capitale, allora gli aggiornamenti che ricevono l’approvazione di tutte e tre le classi devono, per definizione, aggiungere valore al protocollo, poiché queste tre classi comprendono la totalità degli stakeholder all’interno di qualsiasi economia.
Un sistema di governance di questo tipo, se combinato con una piattaforma altamente aggiornabile, sarebbe in grado di adattarsi rapidamente alle esigenze degli sviluppatori e degli utenti finali, e di evolvere in una piattaforma in grado di soddisfare le esigenze di tutti.
I punti di vista, i pensieri e le opinioni qui espressi sono solo dell’autore e non riflettono o rappresentano necessariamente i punti di vista e le opinioni del Cointelegraph.