Mese: ottobre 2017

Chain Fork: ovvero 2 + 2 = 5

Oppure tre. Quasi mai quattro. Di cosa sto parlando? Delle previsioni quasi sempre sbagliate sui prezzi che i vari fork di bitcoin, ma in passato anche di ethereum, causano nel mercato.

Siamo in pieno fork Bitcoin Gold, abbiamo appena superato la nascita e quasi morte di Bitcoin Cash e le previsioni sui vari prezzi che ho letto in giro sono state più o meno tutte errate.

Un modello semplicistico è quello della legge di Metcalfe che dice che il valore di una rete cresce con il quadrato dei nodi. Quindi una comunity come quella di Bitcoin al crescere di utenti, aziende, miner eccetera dovrebbe aumentare il suo prezzo con il quadrato del numero dei partecipanti. Quindi nel momento in cui avviene uno scisma nella comunità cosa dovrebbe succedere? Posto che a^2 +b^2 < (a + b)^2 o che in altre parole il quadrato dei singoli è minore del quadrato della somma, secondo la legge di Metcalfe ad ogni split la somma dei prezzi dovrebbe essere inferiore al prezzo pre-fork.

Ma wait

  1. La legge di Metcalfe non è una legge, non è mai stata dimostrata e forse non è neanche una congettura valida.
  2. in fondo chi vieta ad un attore/utente/miner che opera nella rete A di operare anche in quella B dopo il fork. Quindi come lo contiamo?
  3. Fattori umani, forse anzi senza forse i più importanti. Infatti, una community gode di un certo prestigio e proietta aspettative anche al suo esterno, esistono un numero di potenziali adopter che non fanno il passo decisivo verso l’adozione a causa di dibattiti e mancanza di una roadmap chiara. Quindi una sorta di bacino latente che rimane bloccato e che si sblocca improvvisamente a favorire uno o l’altro percorso dopo il fork. In genere l’hard fork rappresenta la fine delle discussioni interne, e al massimo l’inizio di una guerra fra le parti dopo lo scisma.

 

Dagli Smart Contract alle ICO

Finalmente è su Kindle.

http://amzn.eu/j95TnCq

Screenshot 2017-10-25 21.22.57

 

Bitcoin ha fatto emergere un nuovo territorio da esplorare in cui la parola chiave è blockchain. Nell’intersezione unica fra finanza, economia, tecnologia, matematica e diritto si sta plasmando un mondo che è ancora praticamente sconosciuto ai più.

Oltre ad abilitare pagamenti senza l’intermediazione delle banche, la blockchain diventa la piattaforma su cui implementare servizi più articolati e complessi come gli smart contract. Se Bitcoin ha introdotto il concetto di criptomoneta, gli smart contract introducono l’idea di denaro programmabile. Non tanto un software che gestisce denaro quindi, ma piuttosto un denaro che contiene il suo software.
Anche la finanza si sta trasformando per accogliere queste innovazioni. Negli ultimi due anni decine di startup hanno ottenuto finanziamenti attraverso una ICO, cioè una “Initial Coin Offering”. In questo modo ogni organizzazione può in pratica battere la sua moneta. Un territorio nuovo e pieno di ramificazioni legali, ma dagli sviluppi interessanti e in qualche modo inevitabili.

ICO Test — Case study su Gladius.io

Testiamo il test. Proviamolo con un progetto attualmente in fase di ICO, Gladius.io, che mi è stato segnalato come promettente e che mi è stato chiesto di analizzare.

Disclaimer: Il risultato del test non costituisce un suggerimento all’investimento. Non garantisco nemmeno che le informazioni che ho raccolto siano complete e veritiere, ho semplicemente dato una lettura al loro white paper e al loro sito web. Potrebbe essermi sfuggita qualche informazione importante, quindi fai la tua ricerca.

Gladius.io è un progetto che vuole fare concorrenza ai servizi di Content Delivery Network e anti-Denial of Service. Un mercato oggi dominato da Akamai, Cloudflare e pochi altri. La sua value proposition è quella di decentralizzare queste funzioni creando e coinvolgendo una comunità peer-to-peer che si sostiene grazie a incentivi in forma di token crittografici su blockchain.

 

IL PROGETTO

Check fondatezza: il progetto affronta un problema reale?

Il problema è reale, impedire o mitigare attacchi come il DDOS o fornire un sistema alternativo alle attuali CDN è sicuramente utile.

 

Check tecnologico: il problema anche se reale è risolvibile in modo pratico?

Su questo punto bisognerebbe analizzare nei dettagli la soluzione tecnica proposta, tuttavia aldilà della specifica implementazione non sembrano esserci rischi tecnologici insormontabili. I nodi della rete dovrebbero ricevere le richieste, verificarne la natura non malevola, fungere da cache locale eccetera.

Check di mercato: la soluzione anche se praticabile ha anche un mercato che possa sostenerla?

Sulla scia di progetti recenti, ma soprattutto sull’esperienza di vecchi progetti di grande successo come SETI@home, dove gli utenti partecipavano senza praticamente nessun incentivo, il mercato sembra promettente.

Check legale: la soluzione anche se economicamente sostenibile, è legalmente praticabile?

Non sembra esserci nessun rischio da un punto di vista legale nell’utilizzare le macchine dell’utente per erogare questo genere di servizi. Posto che i dati personali siano cifrati e non accessibili durante il transito.

IL TOKEN

Intanto analizza se promette dividendi e profitti e somiglia ad un bond o ad un’azione.  In tal caso molto probabilmente è una security e non supererebbe l’Howey test (vedi sezione dedicata).

Check regolatorio: se è “come” una security, è stata chiesta l’autorizzazione per la raccolta di capitali?

Non applicabile.

Check (in)utilità: se non è una security,  garantisce qualche diritto d’utilizzo di un prodotto o servizio che verrà sviluppato?

Il token detto GLA serve per pagare il servizio.

Check Ponzi: se nessun prodotto/servizio è previsto, possiamo scongiurare che non sia uno schema piramidale dove chi entra prima ha dei vantaggi a scapito di chi entra nelle fasi successive?

Check superato

Check (dis)economia: il token ha qualcosa di speciale nella dinamica e nella scarsità e non può essere rimpiazzato direttamente dalla valuta nativa (eth o btc)?

Questo punto non è chiaro dalla lettura del white paper. In teoria è previsto un sistema di fee che vanno ai vari node owner con una commissione distribuita anche a Gladius.io.

IL TEAM

Check anonymous:  il team mostra le identità dei suoi membri?

Assolutamente sì

Check skill: il team ha le competenze per risolvere il problema?

Il core team sembra formato da giovani brillanti accompagnati da un numero di advisor più stagionati.

Check organizzazione: il team ha le capacità organizzative per usare le risorse in modo efficiente?

Le esperienze manageriali del CEO e degli altri membri del core team sono difficili da valutare. La loro carriera sembra più tecnica che gestionale o imprenditoriale.

 

Check liquidità: il team ha la reputazione e la notorietà per riuscire a listare il token sugli exchange?

Il gran numero di advisor, alcuni dei quali con grande esperienza e rete di contatti rende questa evenienza abbastanza probabile.

Check “prendi i soldi e scappa”: la giurisdizione territoriale in cui opera il team offre qualche garanzia a chi investe di vedere rispettati i propri diritti?

Gladius.io è una LLC incorporata negli Stati Uniti

LA TOKEN SALE

Check codice sorgente: il contratto di token sale è open source?

Sì, https://github.com/DecentralizedIT/gladius

 

Check vulnerabilità: è stato fatto un audit sugli smart contract della tokensale da uno o più esperti indipendenti?

Sì, ed è un ottimo esempio di code audit.

https://blog.smartdec.net/gladius-smart-contracts-security-audit-d2b636499e55

Check FOMO: Fear of missing out, la token sale garantisce che in caso di transazioni appese, in coda e fuori tempo utile i miei fondi non vadano persi?

Non verificabile in modo immediato mentre la sale prevede bonus decrescenti, dal 20% nelle prime 24h fino all’1% nella terza settimana.

 

Check fallimento: la token sale ha un obiettivo minimo di raccolta noto e prevede la restituzione in caso di mancato raggiungimento?

Dal codice sembrerebbe di sì, e viene richiesta la registrazione per poter acquistare i token. Tale minimo è di $2ml

 

Check superfinanziamento: la token sale ha un massimo di raccolta capitale noto?

Sì. Pari a $12.5ml

Check termini legali: esiste un documento che spiega i termini legali della token sale?

Tale documento non è accessibile dal sito, forse diventa accessibile previa registrazione per la tokensale, ma non abbiamo provato.

Check automazione: la restituzione e altri termini della ICO sono codificati nello smart contract in blockchain o tramite escrow o altri automatismi?

Anche questo aspetto non è stato possibile chiarirlo senza registrarsi alla tokensale

 

Check coerenza: i termini legali sono corrispondenti a quanto decantato nel white paper?

Non verificato per le ragioni viste sopra.

 

Check (in)completamento lavori: esiste uno smart contract o equivalente sblocco dei fondi al raggiungimento dei risultati parziali ottenuti?

Non verificato per le ragioni viste sopra.

 

SPECULAZIONE

Check pump & dump: il team garantisce di non trattenere una percentuale sostanziale dei token?

Solo il 60% dei token viene distribuito, il 40 rimane nelle mani del team, dei founder e per non specificate “operations”. Sembra che una quantità rilevante rimanga sotto il controllo di Gladius.io. I token distribuiti al team sono comunque non spendibili per 18 mesi.

 

Check manipolazione: il team garantisce di non poter bruciare o creare nuovi token a piacimento?

Il white paper afferma che

A fixed supply of tokens will be issued during the Token Creation and no more tokens will ever be created

Tale supply è pari a 96ml di token GLA.

 

Check speculazione occulta: il sistema non prevede di bruciare token con l’utilizzo per aumentarne il valore?

Non sembra prevedere questa opzione. Check positivo.

ICO test. Come valutare una ICO

Liberamente ispirato allo Spolsky test ma applicato alle ICO e trae materiale da diversi interventi ai quali ho assistito e post che ho letto tra cui alcuni di Giacomo Zucco, Ferdinando Ametrano, David Siegel e altri.

Disclaimer: questo test non garantisce nessun risultato, una ICO che superi brillantemente il test non implica un buon investimento e vice versa. Quindi non basarti solo su questo per fare i tuoi investimenti. Questo test è solo un modo per evidenziare alcune caratteristiche di una ICO.  Fai la tua ricerca.

 

IL PROGETTO

Check fondatezza: il progetto affronta un problema reale?

Check tecnologico: il problema anche se reale è risolvibile in modo pratico?

Check di mercato: la soluzione anche se praticabile ha anche un mercato che possa sostenerla?

Check legale: la soluzione anche se economicamente sostenibile, è legalmente praticabile?

IL TOKEN

Intanto analizza se promette dividendi e profitti e somiglia ad un bond o ad un’azione.  In tal caso molto probabilmente è una security e non supererebbe l’Howey test (vedi sezione dedicata).

Check regolatorio: se è “come” una security, è stata chiesta l’autorizzazione per la raccolta di capitali?

Check (in)utilità: se non è una security,  garantisce qualche diritto d’utilizzo di un prodotto o servizio che verrà sviluppato?

Check Ponzi: se nessun prodotto/servizio è previsto, possiamo scongiurare che non sia uno schema piramidale dove chi entra prima ha dei vantaggi a scapito di chi entra nelle fasi successive?

Check (dis)economia: il token ha qualcosa di speciale nella dinamica e nella scarsità e non può essere rimpiazzato direttamente dalla valuta nativa (eth o btc)?

IL TEAM

Check anonymous:  il team mostra le identità dei suoi membri?

Check skill: il team ha le competenze per risolvere il problema?

Check organizzazione: il team ha le capacità organizzative per usare le risorse in modo efficiente?

Check liquidità: il team ha la reputazione e la notorietà per riuscire a listare il token sugli exchange?

Check “prendi i soldi e scappa”: la giurisdizione territoriale in cui opera il team offre qualche garanzia a chi investe di vedere rispettati i propri diritti?

LA TOKEN SALE

Check codice sorgente: il contratto di token sale è open source?

Check vulnerabilità: è stato fatto un audit sugli smart contract della tokensale da uno o più esperti indipendenti?

Check FOMO: Fear of missing out, la token sale garantisce che in caso di transazioni appese, in coda e fuori tempo utile i miei fondi non vadano persi?

Check fallimento: la token sale ha un obiettivo minimo di raccolta noto e prevede la restituzione in caso di mancato raggiungimento?

Check superfinanziamento: la token sale ha un massimo di raccolta capitale noto?

Check termini legali: esiste un documento che spiega i termini legali della token sale?

Check automazione: la restituzione e altri termini della ICO sono codificati nello smart contract in blockchain o tramite escrow o altri automatismi?

Check coerenza: i termini legali sono corrispondenti a quanto decantato nel white paper?

Check (in)completamento lavori: esiste uno smart contract o equivalente sblocco dei fondi al raggiungimento dei risultati parziali ottenuti?

SPECULAZIONE

Check pump & dump: il team garantisce di non trattenere una percentuale sostanziale dei token?

Check manipolazione: il team garantisce di non poter bruciare o creare nuovi token a piacimento?

Check speculazione occulta: il sistema non prevede di bruciare token con l’utilizzo per aumentarne il valore?

—

Se ti è piaciuto l’articolo potresti scaricare il mio Kindle ebook Dagli Smart Contract alle ICO.Screenshot 2017-10-25 21.22.57

Oppure in alternativa mettere un mi piace alla Facebook page

Ultima raccomandazione: niente di quello che scrivo è un invito ad investire i tuoi soldi, è al massimo un invito a conoscere la tecnologia sottostante. Se investi non investire più di quello che sei disposto a perdere e soprattutto non investire in cose che non capisci, siano queste i bitcoin, Ripple o bipcucù (cit.)

 

Si fa presto a dire smart: caveats per smart contract sicuri – parte 1

Sempre più persone sentono parlare di ICO e quindi si immaginano di ottenere soldi facili con un wallet online aperto come un cesto di basketball dove gli investitori non vedono l’ora di schiacciar dentro palloni foderati di ether, bitcoin, litecoin e tutti gli altri coin della famiglia.

Il tutto perché si tratta di smart contract, sono lì apposta. Ora a parte la difficoltà di metter su una vera ICO, difficoltà che aumenta ogni giorno perché ogni giorno l’asticella si sposta verso l’alto e la competizione è in crescita esponenziale, ci sono anche aspetti meramente tecnici su cui riflettere.

ICO a parte ogni smart contract è sempre un pezzo di “programmable money”. Anzi, nel momento in cui viene messo in moto sulla blockchain è un pezzo di “programmed money” e come ben sanno tutti quelli che hanno scritto un hello world non è possibile scrivere un software senza metterci dentro, involontariamente si spera, un bug.

“In accordance with Unix philosophy, Perl gives you enough rope to hang yourself” –Larry Wall

Un bug che colpisce un programma già è una cosa seccante, se colpisce il nostro denaro diventa un disastro. A differenza di un normale sistema in produzione che una volta individuato il bug si può fixare e riavviare – e pazienza per il downtime – quando succede ad uno smart contract in realtà ripristinare lo stato corretto di esecuzione non è scontato. Si può sostituire un contract con uno corretto, ma non è detto che si possano recuperare gli ether. Infatti non si tratta di recuperare dati, si tratta di recuperare gli effetti di transazioni irrevocabili. Per questa ragione Ethereum sembra un progetto pazzesco. Tanto pazzesco che però piace a molti e sta diventando la piattaforma di riferimento per mettere bug nei soldi, ops … per creare smart contract.

Se nel caso del software normale l’audit del codice sembra quasi una pratica da sbrigare per compiacenza generale di clienti e colleghi, nel caso degli smart contract diventa una pratica alla quale non vorremo mai rinunciare.

Screenshot 2017-10-14 15.43.21

Auditor dove siete?

Sempre più progetti pubblicano i risultati dei loro audit su codice solidity e la cosa è molto apprezzabile, ci consente di imparare molto dagli audit degli altri e di capire meglio lo stato dell’arte su cos’è considerato un codice “relativamente” sicuro, o per lo meno un codice audited.

Uno dei framework più affermati per iniziare, almeno iniziare, con codice sicuro (per quanto si possa essere sicuri di qualcosa) è sicuramente Open Zeppelin. Tra le librerie fornite da Open Zeppelin c’è Safe Math

 

SafeMath

Il problema con solidity è che non fornisce un controllo sull’overflow della somma fra due numeri, o in generale sul risultato di un’operazione aritmetica. Ad esempio nel caso della somma se questa supera il max integer value di (2^256-1). Safe Math aggiunge un controllo sul risultato. Allo stesso modo per molte altre operazioni aritmetiche.

function safeAdd(uint256 x, uint256 y) internal returns(uint256) {

 uint256 z = x + y;
 assert((z >= x) && (z >= y));
 return z;
}

Naturalmente usare SafeMath per ogni operazione consuma più gas, quindi se siamo sicuri di non “sforare” con le operazioni aritmetiche non bisognerebbe usarlo.

 

Reentrancy

Un altro tipico problema è la reentrancy. Quando una funzione spedisce ether ad un account esterno in generale questo potrebbe essere un altro contratto. Un contratto può essere programmato per eseguire codice nel momento in cui riceve ether e in modo malevolo potrebbe re-invocare la funzione che lo sta “beneficiando” con lo scopo di sifonarla. L’errore tipico è spedire una quota di ether ad un indirizzo e solo dopo mettere a zero il suo balance in una tabella, come nell’esempio sotto.

 

// THIS CONTRACT CONTAINS A BUG - DO NOT USE
contract Fund {
  /// Mapping of ether shares of the contract.
  mapping(address => uint) shares;
  /// Withdraw your share.
  function withdraw() {
  if (msg.sender.send(shares[msg.sender]))
    shares[msg.sender] = 0;
  }
}

 

msg.sender potrebbe a sua volta invocare ancora withdraw( … ) prima che l’istruzione shares[msg.sender] = 0 venga eseguita. Un esempio di questo exploit è riportato qui

Un errore simile a questo è stato alla base del DAOsaster. Una versione corretta del “prelievo” prima di tutto mette a zero il balance del prelevante e solo dopo gli spedisce i suoi ether.

contract Fund {
 /// Mapping of ether shares of the contract.
 mapping(address => uint) shares;
 /// Withdraw your share.
 function withdraw() {
   var share = shares[msg.sender];
   shares[msg.sender] = 0;
   msg.sender.transfer(share);
 }
}

Ultimo caso analizzato in questa parte del post è un caso in realtà non legato a Ethereum ma valido in generale per tutti i linguaggi con blocchi di codice separati da parentesi (python è immune), non fate if su più linee senza parentesi.

 

Multi line if without brackets

function destroyDeed() {
 if (active) throw;
 if(owner.send(this.balance))
 selfdestruct(burn);
}

Questo stile di programmazione porta molto probabilmente un refactoring o un futuro sviluppo del codice ad aggiungere qualche istruzione in modo errato, come sotto.

function destroyDeed() {
 if (active) throw;
 if(owner.send(this.balance))
 runPreDestroy();
 selfdestruct(burn);
}