Titolo originale: 7 Sanity Checks Before Designing a Token

Autore: Guy Wuollet

Compilato da: Katie Gu, Odaily Planet Daily

I token sono una nuova potente primitiva che può essere definita in molti modi. Lo spazio di progettazione dei token è ricco, ma siamo ancora nelle prime fasi di esplorazione.

In realtà, molti team faticano a trovare il design dei token “giusto” per i loro progetti. Tuttavia, il settore non dispone di un quadro di progettazione testato, quindi le generazioni successive affrontano ripetutamente le stesse sfide dei loro predecessori. Fortunatamente, ci sono (alcuni) primi esempi di progettazione di token di successo. I modelli di token più efficaci hanno elementi unici per i loro obiettivi, ma i design di token più imperfetti condividono alcuni bug comuni. Pertanto, questo articolo discuterà del motivo per cui dovremmo considerare la ricerca e la progettazione dei token piuttosto che solo l’“economia dei token” ed elencherà sette suggerimenti per evitare trappole.

#1 Chiarire gli obiettivi della progettazione dei token

Il problema più grande nella progettazione dei token è come costruire un modello di token complesso prima che l'obiettivo sia chiaro. Il primo passo dovrebbe essere quello di identificare l’obiettivo e assicurarsi che tutto il team lo comprenda appieno: cos’è, perché è importante e cosa vuoi veramente realizzare? La mancata definizione rigorosa degli obiettivi spesso comporta una riprogettazione e una perdita di tempo. Avere obiettivi chiari aiuta anche a evitare il problema di “creare un’economia simbolica allo scopo di progettare un’economia simbolica”, che è un fenomeno comune in alcuni progetti economici simbolici.

Inoltre, l’obiettivo dovrebbe riguardare il token stesso, ma questo viene spesso trascurato. Esempi di obiettivi chiari includono:

• Progetta un gioco con un modello token che consenta una scalabilità ottimale e supporti la modellazione.

• Un protocollo DeFi spera di progettare un modello token che distribuisca ragionevolmente il rischio tra i partecipanti.

• Progettare un protocollo di reputazione che garantisca che il denaro non possa sostituire direttamente la reputazione (ad esempio, disaccoppiando la liquidità dai segnali di reputazione).

• Progetta una rete di archiviazione che garantisca che i file siano disponibili con bassa latenza.

• Progetta una rete di staking che offra la massima sicurezza economica.

• Progettare un meccanismo di governance che susciti le vere preferenze degli utenti o massimizzi la partecipazione.

L'elenco potrebbe continuare all'infinito. Lascia che il token supporti qualsiasi caso d'uso e raggiunga qualsiasi obiettivo, piuttosto che il contrario.

Allora come iniziare a definire un obiettivo chiaro? Obiettivi ben definiti di solito derivano dalla "missione del progetto". Mentre la "missione del progetto" tende ad essere di alto livello e astratta, gli obiettivi dovrebbero essere specifici e ridotti alla loro forma più elementare.

Prendiamo come esempio l'EIP-1559. Roughgarden ha dichiarato un obiettivo chiaro per l'EIP-1559: "L'EIP-1559 dovrebbe migliorare l'esperienza dell'utente attraverso una semplice stima dei costi sotto forma di una 'migliore offerta chiara' al di fuori dei periodi di rapida crescita della domanda."

Ha poi proposto un altro obiettivo chiaro: "Possiamo riprogettare il meccanismo delle commissioni di transazione di Ethereum per rendere la fissazione dei prezzi del gas di transazione più 'selica' come fare acquisti su Amazon? L'ideale è un meccanismo di pubblicazione dei prezzi, che significa un meccanismo in cui ogni utente può accettare o rinunciare al prezzo del gas."

Ciò che entrambi gli esempi hanno in comune è che dichiari un obiettivo di alto livello, fornisci un'analogia pertinente per aiutare gli altri a comprendere il tuo obiettivo e poi vai avanti delineando una soluzione progettuale che supporti al meglio quell'obiettivo.

#2 Valutare il lavoro esistente sulla base di principi fondamentali

Quando si crea qualcosa di nuovo, è una buona idea iniziare con qualcosa che già esiste. Quando si valutano i protocolli esistenti e la letteratura esistente, questi dovrebbero essere valutati oggettivamente in base ai loro meriti tecnici.

I modelli di token vengono spesso valutati in base al prezzo del token o alla popolarità del progetto associato. Questi fattori potrebbero non essere correlati alla capacità del Token Model di raggiungere gli obiettivi dichiarati. La valutazione, la popolarità o altri modi semplicistici di valutare un modello di token possono portare i costruttori a prendere “deviazioni”. Se si presuppone che altri modelli di token funzionino correttamente quando in realtà non lo sono, è possibile creare un modello di token "intrinsecamente difettoso".

# 3 Chiarisci le tue ipotesi

Rendi chiare le tue supposizioni. Quando ti concentri sulla costruzione di una moneta, è facile dare per scontati i presupposti di base. È anche facile esprimere in modo errato le ipotesi che stai effettivamente facendo.

Prendiamo, ad esempio, un nuovo protocollo che presuppone che il collo di bottiglia hardware sia la velocità di elaborazione. Rendere questo presupposto parte del modello token (ad esempio, limitando il costo dell'hardware necessario per partecipare al protocollo) può aiutare ad allineare la progettazione al comportamento desiderato.

Tuttavia, se i progettisti di protocolli e token non esprimono chiaramente i loro presupposti, oppure i presupposti che esprimono sono errati. I partecipanti che sono consapevoli di questa discrepanza hanno quindi il potenziale per estrarre valore dal protocollo. Gli hacker sono solitamente persone che comprendono un sistema meglio di coloro che lo hanno originariamente costruito.

Chiarire i presupposti rende più semplice per le persone comprendere la progettazione del token e garantire che funzioni correttamente. Se non chiarisci la tua ipotesi, non sarai in grado di testarla.

# 4 Metti alla prova le tue ipotesi

C’è un detto: “Non è ciò che non sai che ti mette nei guai, è ciò che sei convinto che non lo faccia”.

I modelli token spesso fanno una serie di ipotesi. Questo approccio deriva in parte dalla progettazione del sistema bizantino, che ha ispirato la blockchain. Il sistema fa un'ipotesi e costruisce una funzione che, se l'ipotesi è vera, garantisce un determinato risultato. Ad esempio, Bitcoin garantisce l’attività in un modello di rete sincrona, garantendo coerenza se il 51% dell’hash power nella rete è onesto. Diverse blockchain più piccole hanno subito attacchi del 51%, violando il numero di presupposti di onestà richiesti dal consenso di Satoshi affinché le blockchain funzionino correttamente.

I progettisti di token possono verificare le loro ipotesi in vari modi. Una modellizzazione statistica rigorosa, spesso sotto forma di modelli basati su agenti, può aiutare a verificare queste ipotesi. Le ipotesi sul comportamento degli utenti possono spesso essere verificate anche parlando con gli utenti, e meglio ancora osservando ciò che le persone effettivamente fanno (piuttosto che dire ciò che fanno). La probabilità di successo della convalida è maggiore, soprattutto con reti di test incentivate che producono risultati empirici in un ambiente sandbox. Anche la convalida formale o il controllo intensivo contribuiranno a garantire che la base di codice funzioni come previsto.

#5 Identificare le “barriere astratte”

Una "barriera di astrazione" è l'interfaccia tra diversi livelli di un sistema o protocollo. Viene utilizzato per separare i diversi componenti di un sistema, consentendo a ciascun componente di essere progettato, implementato e modificato in modo indipendente. Le chiare barriere di astrazione sono utili in tutte le aree dell’ingegneria, in particolare nella progettazione del software, ma sono ancora più necessarie per lo sviluppo decentralizzato e per i grandi team che costruiscono sistemi complessi che nessun individuo può comprendere.

Nella progettazione dei token, l’obiettivo di eliminare le barriere di astrazione è ridurre al minimo la complessità. Ridurre le dipendenze (interne) tra i diversi componenti di un modello di token può portare a un codice più pulito, a meno bug e a una migliore progettazione dei token.

Ad esempio, molte blockchain sono costruite da grandi team di ingegneri. Un team potrebbe fare ipotesi sui costi dell’hardware nel tempo e utilizzarli per determinare quanti minatori contribuiscono con l’hardware alla blockchain a un determinato prezzo simbolico. Se un altro team fa affidamento sul prezzo simbolico come parametro ma non conosce le ipotesi del primo team sui costi dell'hardware, può facilmente formulare ipotesi contrastanti.

A livello applicativo, chiare barriere di astrazione sono fondamentali per ottenere la componibilità. Man mano che sempre più protocolli vengono combinati tra loro, la capacità di adattare, costruire, estendere e remixare diventerà sempre più importante. Composizioni più grandi portano maggiori possibilità, ma anche maggiore complessità. Quando le applicazioni desiderano comporre, devono comprendere i dettagli del protocollo di composizione che utilizzano.

Presupposti e interfacce opachi possono occasionalmente portare a bug oscuri, soprattutto nei primi protocolli DeFi. Le barriere di astrazione fuzzy aumentano anche l’efficienza della comunicazione richiesta tra i team che lavorano su diversi componenti del protocollo, allungando così i tempi di sviluppo. Vaghe barriere di astrazione aumentano anche la complessità del protocollo, rendendo difficile comprenderne appieno i meccanismi.

Creando chiare barriere astratte, i progettisti di token possono prevedere più facilmente come modifiche specifiche influenzeranno ciascuna parte della progettazione del token. Le chiare barriere di astrazione semplificano inoltre l'estensione di un token o di un protocollo e la creazione di una comunità Builder più inclusiva e scalabile.

#6 Riduci la dipendenza dai parametri esterni

I parametri esterni non sono inerenti al sistema ma possono influenzare le prestazioni complessive e il successo, come il costo delle risorse di elaborazione, il volume delle transazioni o la latenza nelle prime fasi della creazione del modello token.

Ma quando un modello token funziona solo quando i parametri vengono mantenuti entro un intervallo limitato, può verificarsi un comportamento imprevisto. Ad esempio, un protocollo che vende servizi e fornisce sconti sotto forma di ricompensa fissa in token potrebbe valere più del costo del servizio se il prezzo del token è inaspettatamente alto. In questo caso, è abbastanza conveniente acquistare servizi illimitati dal protocollo, che trarrà pieno vantaggio dai premi e dai servizi token.

Oppure, per fare un altro esempio, le reti decentralizzate spesso si basano su algoritmi crittografici o enigmi computazionali difficili ma non impossibili da risolvere. La difficoltà di solito dipende da una variabile esogena, come la velocità con cui un computer può calcolare una funzione hash o una dimostrazione a conoscenza zero. Ad esempio, esiste un protocollo che presuppone la velocità con cui può essere calcolata una determinata funzione hash e paga di conseguenza i premi in token. Se qualcuno inventa un nuovo modo per calcolare una funzione hash più velocemente, o semplicemente dispone di risorse eccessive per risolvere il problema, sproporzionate rispetto al lavoro effettivo svolto nel sistema, può essere ricompensato con token inaspettatamente enormi.

# 7 Riconvalida le ipotesi

Progettare un token dovrebbe essere come progettare un sistema contraddittorio. Il comportamento dell'utente cambierà man mano che cambia il modo in cui funziona il token.

Un errore comune è quello di modificare il modello del token senza garantire che il comportamento arbitrario dell’utente produca comunque risultati accettabili. Non dare per scontato che il comportamento degli utenti rimarrà lo stesso a causa dei cambiamenti nel modello di token. In genere questo tipo di errore si verifica nelle fasi avanzate del processo di progettazione, quando qualcuno ha dedicato molto tempo a definire l'obiettivo del token, a definirne la funzionalità e a convalidarlo per garantire che funzioni come previsto. Hanno quindi identificato un caso speciale e hanno modificato il design del token per adattarlo, ma si sono dimenticati di riconvalidare l'intero modello del token. Risolvendo un caso speciale, ne creano un altro (o molte altre) conseguenze indesiderate.

Ricorda di non lasciare che il tuo duro lavoro vada sprecato, ogni volta che un progetto cambia il suo modello di token, verifica nuovamente che funzioni come previsto.