Se la blockchain ri-converge in differenti catene con potenziali differenti transazioni, i miners "onesti" posso includere le transazioni della catena invalida nella transaction
A.8. Implicazioni per la sicurezza 137
pool. Tuttavia, possono esistere anche miners "malevoli" nel sistema. Le transazioni
Bitcoin utilizzano il concetto di confirmation [64]: una transazione inclusa nella block-
chain in un blocco con N successori ha una confirmation N+1. Ad esempio, due gruppi di nodi miners dove ogni gruppo ha esattamente il 50% dell’hashing power totale (la
potenza di elaborazione della rete), il gruppo A e il gruppo B. In una prospettiva di
lungo periodo, il 50% dei blocchi dovrebbe venir minato dal gruppo A e il 50% dal
gruppo B; nonostante ciò, se il gruppo A accumula più del 50% dell’hashing power, produrrebbe eventualmente più blocchi del gruppo B.
Majority attack
Si consideri un individuo con intenzioni malevoli che controlla un gruppo di miners
con più del 50% dell’hashing power totale. Si definisca inoltre un blocco X conosciuto
da tutti i nodi del network; il gruppo di miners controllati inizia il processo di minting
("coniare") di una catena segreta dal blocco X - una catena segreta non viene pubblicata agli altri miners. Supponendo che la difficoltà del mining non è cambiata dal blocco X, la catena segreta risulterà quella con la catena più lunga e con un grado di difficoltà accumulato più alto. Finché la catena segreta continua ad avere la difficoltà cumulata più alta, può essere propagata agli altri miners blocco per blocco nello stesso momento.
Tutti i miners setteranno la catena segreta come la nuova main chain, rimpiazzando effettivamente tutti i blocchi dal blocco X. Questo tipo di attacco è conosciuto con il nome di "majority attack", "50% attack" o "51% attack". Questo attacco appartiene alla
categoria dei brute force attacks [65]; con il majority attack, un aggressore può [66]:
• Modificare tutte le transazioni incluse dopo il blocco X; • Modificare le transazioni incluse prima o nel blocco X;
• Convertire le sue stesse transazioni, rimpiazzandole con transazioni già utilizzate nella secret chain, facendo emergere il problema del double-spending;
• Scegliere quali transazioni includere permanentemente nella blockchain Tuttavia, un aggressore non può [66]:
– Inviare bitcoins che non gli appartengono;
– Creare denaro dal nulla;
– Far accettare agli altri nodi le sue consensus rules;
– Convertire le transazioni di altre persone senza la loro cooperazione ;
– Bloccare transazioni non confermate dalla rete.
Considerando un miner con il 10% del hashing power totale, questo ha una probabi-
lità del 20% di eseguire con successo un tentativo di double-spending su una transazione
con una confirmation [65]. Lo stesso miner ha una probabilità di successo del 5.6% con una transazione con due confirmation e lo 0,0059% di probabilità di successo con una
transazione con sei confirmation. Nonostante ciò, il mining di una catena segreta che
non verrà inclusa nella blockchain ha un costo per l’operatore del mining in termini di
elettricità; inoltre, gli fa perdere sia la ricompensa del blocco che le commissioni sulle
transazioni nella catena segreta non inclusa. Infatti, gli operatori di mining hanno un
incentivo economico a non attaccare la rete Bitcoin, in quanto hanno investito nell’hard- ware per effettuare il mining e si aspetta un ritorno da questo investimento o comunque dei futuri profitti. Il mining decentralizzato insieme agli incentivi economici manten-
gono, nella pratica, immutata la blockchain. Dalla prospettiva di chi deve ricevere i bitcoins, essi devono stimare un numero di confirmations C tale che C sia alto abbastan-
za per considerare una transazione ricevuta immutabile. Per esempio, la probabilità di
successo di un doublespending attack che riesca a convertire delle transazioni è minore
se C = 6 piuttosto che C = 1 [65]. Il numero di confirmations sufficiente a rendere una transazione "sicura" può essere deciso da chi deve ricevere i bitcoins in base al
A.8. Implicazioni per la sicurezza 139
centralizzati, richiedono di solito almeno 6 confirmations per permettere agli utenti di
Appendice B
Piattaforma Ethereum e Smart
Contracts
B.1
Contratti
Un contratto è un accordo volontario fra due o più parti, il quale può essere im-
pugnabile in quanto accordo legale vincolante [67]. I contratti vengono solitamente
stabiliti da entrambe le parti e contengono un testo negoziabile che dev’essere com-
prensibile e chiaro. Un intermediario (ad esempio, un notaio) può firmare il contratto
per proteggerne l’autenticità e le autorità hanno la possibilità di mettere forzatamente in atto quanto riportato e definito all’interno del contratto. Considerando invece un
contratto digitalizzato, le parti contraenti possono essere rappresentate da un numero
identificativo e il contenuto del contratto può essere archiviato sotto forma di codice
informatico, utilizzando parametri condizionali, regole e procedure. Per evitare con- fusione nella terminologia dei contratti digitalizzati, verranno analizzate due differenti [68], anche se correlati, concetti di contratto.
B.1.1 Contratto ricardiano
Il ricardian contract è un template per contratti che ha la caratteristica di poter essere
compreso da umani e da computers ed è considerato un pattern da utilizzare nell’archi-
tettura di software che interagiscono con i contratti [69]. Questa tipologia di contratto
è stata inventata da Ian Grigg nel 1995 con lo scopo di portare ed emettere strumenti
finanziari nel Web[70]:
"A Ricardian Contract can be defined as a single document that is a) a contract offered by an issuer to holders, b) for a valuable right held by holders, and managed by the issuer, c) easily readable by people (like a
contract on paper), d) readable by programs (parsable like a database), e)
digitally signed, f) carries the keys and server information, and g) allied with
a unique and secure identifier.[71]"