Home
» Conoscenza
»
Come leggere un white paper sulle criptovalute: una guida pratica in 8 passaggi
Come leggere un white paper sulle criptovalute: una guida pratica in 8 passaggi
La regola più importante per leggere un white paper su una criptovaluta è semplice: consideralo come un insieme di affermazioni da verificare, non come la prova che il progetto funziona . Un buon white paper dovrebbe spiegare quale problema il progetto intende risolvere, come dovrebbe funzionare il suo sistema, perché è necessario un token, su quali presupposti si basa il progetto e quali rischi o compromessi rimangono. Il tuo compito è trasformare queste affermazioni in domande che puoi verificare confrontandole con la documentazione attuale, il codice sorgente, i dati on-chain, i registri di governance e le prove di sicurezza indipendenti.
Questo è importante perché i white paper possono invecchiare rapidamente. Il sito web di Ethereum avverte esplicitamente che il white paper del 2014 non riflette più Ethereum come esiste dopo oltre un decennio di sviluppo, sebbene il documento rimanga utile per comprendere la visione originale. Questo è un forte promemoria del fatto che un white paper è spesso un documento di progettazione storico, non una specifica continuamente aggiornata. Consultate la pagina del white paper di Ethereum per questo avviso e per il testo originale.
Cosa è necessario sapere prima di terminare la lettura?
Al termine della tua analisi, dovresti essere in grado di spiegare il progetto in un linguaggio semplice e comprensibile, senza ripetere il linguaggio di marketing. Dovresti sapere chi ha bisogno del sistema, cosa cambia quando viene utilizzato, quale componente crea il vantaggio dichiarato, cosa può non funzionare, dove si colloca il token, chi controlla gli aggiornamenti o i fondi di tesoreria e quali affermazioni hai verificato in modo indipendente.
Se dopo aver letto il documento non riuscite a rispondere a queste domande, non cercate di compensare presumendo che i dettagli mancanti siano favorevoli. Consideratele irrisolte e cercate prove più convincenti.
Passaggio 1: Inizia con l'abstract, il contenuto, la data e la versione.
Non iniziare leggendo ogni pagina in modo lineare. Per prima cosa, individua il titolo, la data di pubblicazione, il numero di versione, l'abstract, l'indice e qualsiasi nota legale o tecnica. Questo ti fornirà una mappa del documento e ti permetterà di capire se stai leggendo una proposta originale, una revisione successiva o una versione obsoleta.
Prima di valutare le singole affermazioni, iniziate identificando la versione, la data, l'abstract e la struttura delle sezioni del white paper.
Una data è particolarmente importante quando un progetto è già stato avviato. Confrontatela con la documentazione di protocollo vigente. Il white paper pubblicato da Solana, ad esempio, è una proposta tecnica che include una clausola di esclusione di responsabilità legale in cui si afferma che i piani possono cambiare e che i risultati futuri non sono garantiti. È possibile consultare il documento originale al seguente link: white paper ufficiale di Solana (PDF) .
Domande rapide
Quando è stato pubblicato o revisionato per l'ultima volta l'articolo?
Il progetto è già attivo?
Il progetto fornisce una documentazione tecnica più recente?
Le sezioni relative ai token, alla governance o alla roadmap sono ancora aggiornate?
Passaggio 2: Riscrivi il problema e la soluzione con parole tue.
Individua la descrizione del problema e la soluzione proposta. Quindi riscrivi ciascuna in una o due frasi. Evita gli aggettivi preferiti dal progetto, come "rivoluzionario", "senza attriti", "di nuova generazione" o "infinitamente scalabile". Sostituiscili con sostantivi concreti, azioni e risultati misurabili.
È importante separare il problema dichiarato, la soluzione proposta, le ipotesi e i compromessi, anziché considerarli come un'unica narrazione di marketing.
Ad esempio, il documento originale di Bitcoin non si limitava ad affermare che i pagamenti digitali dovessero essere decentralizzati. Proponeva un sistema di denaro elettronico peer-to-peer progettato per consentire ai pagamenti online di spostarsi direttamente tra le parti senza dipendere da un istituto finanziario, e descriveva poi un meccanismo basato sulla prova di lavoro per ordinare le transazioni. Il documento originale è disponibile su Bitcoin.org .
Dopo aver riassunto il problema e la soluzione, chiedetevi se il problema sia effettivamente sufficientemente reale da richiedere una blockchain o un token. Un progetto che potrebbe funzionare altrettanto bene con un database convenzionale potrebbe comunque essere utile, ma il white paper dovrebbe spiegare quali vantaggi offre la decentralizzazione e quali costi comporta.
Fase 3: Identificare il meccanismo che rende il progetto diverso
Passiamo ora al nucleo tecnico: consenso, modello di esecuzione, disponibilità dei dati, meccanismo di privacy, progettazione dell'oracolo, modello di liquidità, architettura di bridging, modello di archiviazione, o qualsiasi altra cosa che effettivamente crei il vantaggio dichiarato del progetto. Non è necessario comprendere immediatamente ogni equazione. È necessario però comprendere la catena di causa ed effetto.
Traduci le sezioni relative all'architettura e al consenso in una lista di controllo di componenti, dipendenze, presupposti di sicurezza e vantaggi prestazionali dichiarati.
Un test utile consiste nel completare questa frase: "Il progetto afferma di raggiungere X perché utilizza Y , il che funziona solo se Z rimane vera". La parte "Z" spesso rivela l'assunto più importante.
Quando compaiono dati sulle prestazioni, verificate le condizioni. Un calcolo teorico della velocità di trasmissione in base a una determinata larghezza di banda di rete, configurazione hardware o carico di lavoro idealizzato non equivale a una prestazione di produzione sostenuta in condizioni di congestione. Considerate ogni dato relativo a velocità, costi, finalità e scalabilità come incompleto finché non sapete come è stato misurato.
Fase 4: Analizzare la tokenomics come sistema di incentivi
Una sezione sulla tokenomics dovrebbe rispondere a domande che vanno oltre il semplice "Qual è l'offerta massima?". È necessario comprendere l'allocazione, l'emissione, la maturazione, lo sblocco, i flussi di commissioni, lo staking o gli incentivi legati ai titoli, i diritti di governance, il controllo della tesoreria e la fonte di qualsiasi rendimento.
Verificate se le percentuali di allocazione corrispondono, quando i token entrano in circolazione, chi li riceve e quale funzione concreta svolge il token.
Analizza attentamente i numeri. Se insider, investitori, fondazioni o fondi dell'ecosistema controllano una quota consistente, chiedi quando questi token verranno sbloccati e chi potrà trasferirli. Se vengono pubblicizzati premi per lo staking, chiedi se questi provengono dai ricavi del protocollo, dall'emissione di nuovi token, dalle commissioni pagate dagli utenti o da altre fonti. Un rendimento nominale elevato, finanziato principalmente dalla diluizione, è economicamente diverso da un rendimento sostenuto dalla domanda esterna.
È inoltre importante distinguere l'utilità di un token dalla sua acquisizione di valore . Un token può essere richiesto per il pagamento di commissioni o per la governance senza per questo acquisire automaticamente valore con l'aumentare del suo utilizzo. Il white paper non dovrebbe passare bruscamente da "la rete utilizza questo token" a "pertanto il token dovrebbe apprezzarsi".
Passaggio 5: Confrontare il white paper con il codice e la documentazione attuali
Una volta compreso il documento, smettete di considerarlo la fonte primaria di verità. Confrontatelo con la documentazione tecnica attuale del progetto, i repository pubblici, le note di rilascio, i contratti implementati e le specifiche del protocollo. Cercate funzionalità che sono state rimosse, rinominate, posticipate o sostanzialmente riprogettate.
Confronta il documento con il codice, le versioni e la documentazione attuali per verificare se l'implementazione corrisponde ancora al progetto originale.
È in questa fase che i white paper obsoleti diventano evidenti. Ethereum ne è un altro esempio calzante: la pagina del white paper del progetto stesso informa i lettori che il documento originale è precedente al lancio e ai principali aggiornamenti. La conclusione corretta non è che il vecchio documento sia inutile, bensì che l'intento progettuale storico e l'implementazione attuale devono essere valutati separatamente.
Per quanto riguarda i meccanismi del protocollo, è preferibile consultare fonti tecniche primarie. Uniswap, ad esempio, pubblica il proprio materiale tecnico attraverso la documentazione ufficiale, incluso il white paper di Uniswap v2 , che descrive le scelte di progettazione fondamentali come le coppie ERC-20, il comportamento dell'oracolo dei prezzi, gli scambi flash e i meccanismi delle commissioni di protocollo.
Passaggio 6: Verificare, ove possibile, le dichiarazioni relative al token e al protocollo sulla blockchain.
Se il progetto è attivo, molti aspetti importanti non sono più teorici. Conferma l'indirizzo del contratto implementato da una fonte ufficiale, quindi esamina il codice del contratto verificato, l'offerta, i detentori, i permessi di conio, la possibilità di aggiornamento, i portafogli del tesoro e l'attività delle transazioni utilizzando l'explorer della blockchain di riferimento.
Utilizza gli indirizzi contrattuali ufficiali e i registri on-chain per verificare che le dichiarazioni relative a fornitura, standard dei token e utilità corrispondano al sistema attivo.
Non fidarti di un indirizzo di contratto copiato da un post casuale sui social media o da un risultato di ricerca. Parti dalla documentazione ufficiale del progetto e segui l'indirizzo fino a un block explorer affidabile. Se il white paper afferma che l'offerta è limitata, cerca funzioni di conio o ruoli privilegiati che potrebbero modificarla. Se la governance è descritta come decentralizzata, identifica chi può aggiornare i contratti o modificare i parametri critici.
Passaggio 7: Mappare la governance, le chiavi di amministrazione e il controllo effettivo
Il termine "governance decentralizzata" può avere significati molto diversi. Ad esempio, stabilire chi può proporre modifiche, chi può votare, cosa determina il potere di voto, se i voti sono vincolanti, se una firma multipla può annullare i risultati, come avvengono gli aggiornamenti e chi controlla il tesoro.
Tracciare il processo che porta le proposte a diventare modifiche eseguibili e identificare eventuali chiavi di amministratore, privilegi di aggiornamento, firme multiple o controlli di tesoreria.
Presta particolare attenzione ai poteri di emergenza. Una funzione di pausa o un tasto di aggiornamento possono essere utili per un protocollo giovane, ma modificano il modello di sicurezza. La questione importante non è se esistano controlli centralizzati, ma se siano chiaramente divulgati, opportunamente limitati e coerenti con le dichiarazioni del progetto.
Passaggio 8: Concludere con un controllo delle segnalazioni di allarme e delle prove.
Prima di decidere che un progetto merita più tempo, dividi i tuoi appunti in tre colonne: verificato , plausibile ma non verificato e contraddetto o poco chiaro . Questo eviterà che una scrittura curata si trasformi in fatti dati per scontati.
Concludi la revisione verificando le prove di sicurezza, le dipendenze architetturali, la concentrazione, la trasparenza della governance e le promesse non supportate da prove.
Segnali d'allarme che meritano un'analisi più approfondita
Promesse di rendimenti garantiti o insolitamente elevati, prive di una chiara giustificazione economica.
Dati sulle prestazioni forniti senza condizioni di prova, metodologia o prove riproducibili.
Un'allocazione di token che concentra il controllo senza meccanismi di garanzia trasparenti né di governance.
I contributori anonimi o non verificabili vengono presentati come sostituto delle prove tecniche.
Una tabella di marcia ricca di risultati attesi, ma con poche spiegazioni sulle dipendenze o sulle tappe fondamentali del progetto.
Affermazioni sulla sicurezza che si basano sulla parola "verificato" senza fornire un collegamento al rapporto di verifica effettivo e al suo ambito di applicazione.
Linguaggio di governance che ignora le chiavi di amministratore, le firme multiple, la possibilità di aggiornamento o i poteri di emergenza.
Un white paper che è in conflitto con il codice corrente, la documentazione o i contratti in essere.
Le autorità di regolamentazione avvertono inoltre gli investitori di non considerare le informazioni sulle criptovalute come un sostituto della comprensione del rischio. Il sito Investor.gov della SEC statunitense sottolinea che gli investimenti in criptovalute possono essere altamente speculativi e comportare volatilità, illiquidità, proprietà o controllo opachi, guasti tecnici e limitate tutele per gli investitori. Si consiglia di consultare l' avviso sui titoli in criptovalute pubblicato su Investor.gov per un'analisi dei rischi rivolta agli investitori.
Un semplice schema di valutazione per i white paper
Zona
Che aspetto ha una buona prova
Cosa dovrebbe preoccuparti?
Problema
Utenti specifici, punto critico misurabile, motivo chiaro per cui la decentralizzazione è d'aiuto
Affermazioni vaghe sulle dimensioni del mercato o un problema che non richiede il sistema proposto
Tecnologia
Meccanismo, presupposti, compromessi, modello di minaccia, riferimenti per l'implementazione
Parole d'ordine prive di spiegazione causale o affermazioni irrealistiche sulle prestazioni
Token
Assegnazione, emissione, maturazione, utilità, flusso di commissioni, diritti di governance
Sblocchi poco chiari, controllo concentrato o utilità che esiste solo per giustificare un token
Il white paper e il prodotto finale presentano differenze sostanziali, senza alcuna spiegazione.
Governance
Processi documentati relativi a proposta, votazione, esecuzione, amministrazione, aggiornamento e tesoreria.
controllo privilegiato nascosto o scarsamente divulgato
Sicurezza
Ambito di verifica pubblicato, correzioni, programma di ricompensa per la segnalazione di bug, limitazioni note
La dicitura "Sottoposto a verifica" viene usata come etichetta di marketing, senza un rapporto accessibile né risultati irrisolti.
Fino a che profondità bisogna andare?
Il livello di analisi da effettuare dovrebbe essere commisurato all'esposizione che si intende investire. Se si desidera solo comprendere un concetto del protocollo, il white paper e la documentazione attuale potrebbero essere sufficienti. Se si prevede di utilizzare un protocollo con fondi significativi, è necessario aggiungere la verifica dei contratti, gli audit di sicurezza, l'analisi della governance e la valutazione del rischio operativo. Se si sta valutando un token come investimento, è opportuno considerare anche le dinamiche dell'offerta, i piani di sblocco, il comportamento del tesoriere, le informative legali, la struttura del mercato, il rischio di custodia e la possibilità di perdita totale.
Non serve diventare un crittografo per leggere bene un white paper. Bisogna però notare dove il documento passa dalle prove alle ipotesi. Il risultato migliore non è "Ho capito ogni formula", ma piuttosto "So cosa afferma il progetto, cosa rende possibili tali affermazioni, quali parti sono attive oggi, quali ho verificato e quali rischi restano irrisolti".
Conclusioni
Leggere un white paper sulle criptovalute è solo l'inizio della due diligence, non la fine. Innanzitutto, bisogna comprendere il problema e il meccanismo. Poi, bisogna testare gli incentivi basati sui token, confrontare il documento con l'implementazione attuale, verificare le affermazioni in tempo reale sulla blockchain, identificare chi controlla realmente gli aggiornamenti e i fondi e concludere con una checklist esplicita di prove e rischi. Un documento tecnicamente impeccabile può comunque descrivere un cattivo investimento e un'idea promettente può comunque fallire nella fase di implementazione. Il white paper è utile proprio perché fornisce affermazioni che è possibile contestare.