• Aucun résultat trouvé

Blockchain & Bitcoin

N/A
N/A
Protected

Academic year: 2022

Partager "Blockchain & Bitcoin"

Copied!
20
0
0

Texte intégral

(1)

Blockchain & Bitcoin

Notions fondamentales

Lionel Brunie, Omar Hasan

Institut National des Sciences Appliquées de Lyon

Lionel.Brunie@insa-lyon.fr

(2)

Outils de base (1/2)

• Fonction de hachage cryptographique

– Associe à un objet numérique de taille variable, une chaîne de caractères de taille fixe (appelée résidu, empreinte, hash...)

– Sens unique

• Calcul du hash rapide

• Calcul inverse extrêmement difficile

• Probabilité très faible d’obtenir le même hash avec deux données d’entrée différentes (collision)

• Petite modification de la donnée d’entrée => modification aléatoire du hash

• Hashes différents => données d’entrée différentes avec une quasi certitude

– Utilisations

• Intégrité : hash non modifié => donnée non modifiée avec une quasi certitude

• Masquage d’information, propriété et authenticité (log) : stocker le hash d’une donnée permet de masquer le contenu de celle-ci et de minimiser l’espace de stockage ; cependant, le propriétaire de la donnée

d’entrée peut, en dévoilant celle-ci, en restituer le contenu dont l’authenticité est garantie par le hash

(3)

Outils de base (2/2)

• Chiffrement asymétrique

– Deux clefs associées : clef publique / clef privée

– Clef publique... publique (affichée à la vue de tous) !

– Clef secrète... secrète (conservée par devers soi et transmise à personne)

– Quasiment impossible de déduire l’une des clefs à partir de l’autre – Chiffrement avec une clef, déchiffrement avec l’autre clef

– Utilisations

• Confidentialité : chiffrer avec la clef publique du destinataire

• Authentification : chiffrer avec la clef privée de l’émetteur

(4)

Bitcoin Address

• Bitcoin manages transactions i.e., flows of « coins »

• A coin « belongs » to an address

• An address is the 160-bit hash of the public key of a public/private ECDSA keypair

• Bitcoin allows one to create as many addresses as one wants,

and use a new one for every transaction

(5)

Structure of a Block (Bitcoin)

• 3 fields

– Header: 80 Bytes

– Number of transaction (Varint) e.g., n – n concatenated transactions

• Total size <=1MB

(6)

Block Header (Bitcoin)

• 80 Bytes

• Version number (4 Bytes)

• Hash pointer to the previous block (32 Bytes)

• Root of the Merkle tree formed by the n transactions in the block (hash) (32 Bytes)

• Timestamp (uint32) (4 Bytes)

• nBits: Difficulty to solve the block (uint32) (4 Bytes)

• Nonce result of the puzzle (uint32) (4 Bytes)

(7)

Transaction (Bitcoin)

• Header, incl.

– Nb of inputs – List of inputs – Nb of outputs – List of outputs

– Lock time (block height or timestamp when the transaction can

be included into a block

(8)

Input – Output – Coin (1/2)

• A coin is not identified using a fixed id

• A transaction transforms inputs (coins) into output (coins)

• Once used, input coins cannot be anymore used as inputs

• Inputs/Ouputs can represent any amount of satoshis (some miners impose a minimum)

• Inputs (coins) must have been produced as outputs of a previous transaction i.e., an input = reference to an output from a previous transaction

• The total value of the inputs must be >= total value of the outputs

(9)

Input – Output – Coin (2/2)

• Input format

– hash of the previous transaction from which the input was produced – index nb referencing the specific output of this transaction

– script length

– Script (used notably to check the ownership of the inputs)

– sequence nb (allow modifying the transaction when before LockTime expires (may be disabled)

• Output format

– value : nb of satoshis (1 satoshi = 1/10^8 bitcoins) – script length

– Script (includes the Bitcoin address of the recipient of the output (hash of its public key)

(10)

Examples of Transactions

From en.bitcoin.it

(11)

Scripts and Verification

• Stack-based language (Forth-like)

• Pay-to-PubkeyHashTransaction

– script on the inputs (scriptSig): <sig> <pubKey>

– script on the outputs (scriptPubKey): OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

– the “owner” of a transaction input (coin) provides its public key + her signature of the transaction which created this coin (remember a coin is created as output of a transaction)

– the combination of the scripts allows verifying that the hash of the public key matches the address attached to the “coin” (i.e. to the recipient of the output corresponding to the “coin”) and that the signature is correctly decrypted by this public key

• Pay to script hash Transaction

– allows sending coins to a script hash instead of a public key hash

– to spend these coins, the recipient must provide a script that matches the script has and data which makes the script evaluate to true

– Used to implement “(smart) contracts”

(12)

OP-RETURN Script Operator

• OP_RETURN, when placed in an output script (scriptPubKey), makes the script fail => the coin to which the script is attached is unspendable (“ burnt”)

• Data placed after the OP_RETURN operator are not read by the miner (but they are stored in the ledger)

• Usually, one places less than 40 Bytes after OP_RETURN

• Used to create “colored” coins

(13)

Multisignature

• m of n: n addresses are attached to an output coin; at least m of them must sign in order to use this coin

• Often use to introduce an escrow (signature 2 of 3)

• May be use to store information (“fake” address of a 1 of

2 signature)

(14)

Blockchain

• Block = data (transactions in Bitcoin)

• Hash of a block = address (id) of this block. In Bitcoin, one considers the hash of the header. Note: the header contains the root of the Merkle tree formed by the transactions stored in the block

• Blocks are chained (ordered)

(15)

Mining Blocks and Consensus Protocol (1/3)

• Transactions are broadcasted to the Bitcoin P2P network

• Mining = adding transaction records to Bitcoin's public ledger of past transactions

• This ledger is used to log legitimate transactions and prevent double spending

• This ledger = blockchain

• Miners are rewarded for their work

– In each block, a reward transaction (“coinbase transaction”) is included. This transaction creates new coins which are given to the miner. This reward halves every 210000

blocks. It’s now 12,5 bitcoins

– Transactions may (actually should) include “transaction fees” that are given to the miner

• Mining is the only way to create coins

(16)

Mining Blocks and Consensus Protocol (2/3

• Proof of work (PoW)

– deter abuses e.g., DoS, spam, etc.

– PoW = piece of data hard to produce but whose validity can be easily verified

– Bitcoin PoW: find a value (nonce) such that the hash of the concatenation “header of the block + nonce” is lower that a specified threshold (the “target”) (i.e. the hash starts with a certain number of ‘0’)

– as each miner mines a “personalized” block, each miner solves a different puzzle

– Unpredictability of the puzzle => a miner with x% of the total computing power has x%

chance to be the first to solving the puzzle

– The difficulty of the puzzle is set to such a difficulty (target) that a block is mined approx.

every 10 mn

– PoWs are verified by the other miners

(17)

Mining Blocks and Consensus Protocol (3/3)

• Consensus

– The P2P Bitcoin network is an asynchronous network => multiple miners may solve their own puzzle at the same time; each of them then broadcasts its block to the network => the chain is now “forked”

– A consensus protocol is required to fix this issue and make a decision on which block is the new block

– Protocol: choosing the longest chain

If a node receives two blocks (thus facing a chain with 2 branches), it stores both of them and and try to append a new block to one of the 2 branches (typically, the first it receives)

In the meantime, if it receives a new block for one of the branches, it discards the other one (i.e., the shortest one)

Eventually, all miners agree on the same chain (actually, as the chain always grows, they agree on the same prefix)

When a miner receives a longer chain, it needs to “roll back” the blocks (called “orphan blocks”) down to the fork, then to add the newly received blocks

Rewards attached to orphan blocks are nor spendable (actually, not spendable on the longest blockchain)

Transactions logged in an orphan block return back to the memory pool of the miners

It is usually considered that a block is confirmed after 6 other blocks are added to the blockchain

(18)

Some figures (March 7, 2017) (1/2)

• Total bitcoins in circulation: 16,200,950

• Total bitcoins to be ever produced: 21,000,000

• Exchange rate : 1 BTC~ 1280 USD

• Bitcoin capitalization: 20,7 billion USD (19,6 billion €)

• Nb of transactions per hour: 12140 (for 80,121 BTC)

• Total blocks: 456,075

• Nb of blocks generated per day: 144

• Computing power: 3.3 exahashes/s – 42,454,023 PFLOPS (#1 top500

supercomputer: 125 PFLOPS (Rpeak)-93 PFLOPS (Rmax)); sum of top500:

672PFLOPS (Rmax))!!!!! (i7~: a few tens to hundreds of GFLOPS) (use of ASICS)

(19)

Some figures (March 7, 2017) (2/2)

• Total bitcoins in circulation: 16,200,950

• Total bitcoins to be ever produced: 21,000,000

• Exchange rate : 1 BTC~ 1280 USD

• Bitcoin capitalization: 20,7 billion USD (19,6 billion €)

• Nb of transactions per hour: 12140 (for 80,121 BTC). Note: max speed: 7 transactions per seconds; VISA : average 2000 trans./s, peak 56,000 trans./s!

• Total blocks: 456,075

• Size of the Bitcoin blockchain: 105 GB

• Nb of blocks generated per day: 144

• Nb of orphan blocks generated per day: 0-4

• Computing power: 3.3 exahashes/s – 42,454,023 PFLOPS (#1 top500 supercomputer: 125

PFLOPS (Rpeak)-93 PFLOPS (Rmax)); sum of top500: 672PFLOPS (Rmax))!!!!! (i7~: a few tens to hundreds of GFLOPS) (use of ASICS)

• The 5 more powerful mining pools concentrates 55% of the total computing power

• Number of unique addresses: 500,000+

(20)

Conclusion: Why Using Blockchains?

• Some nice properties

– No trusted third party, no single point of failure

– Reliability and immutability (very high replication factor) – (eventual) Consistency

– Non-repudiability

– Existing infrastructure – Open infrastructure – Contracts

• Some issues

– Security (in the ecosystem more than in the Bitcoin protocol itself) – Total transparency; no real anonymity

– Hard consensus

– Low latency, low throughput, poor transactional scalability (cf. huge computing power for only 12140 transactions per day!)

– Waste of resources and energy due to a huge replication factor and the solving of useless puzzles – PoW vs Proof of Stake

Références

Documents relatifs

However, letting the transaction fee be the outcome of a market and make the block size irrelevant or not binding would lead to a too low level of security for Bitcoin. The reason

Indeed, if we make, as already noted, the assumption that all miners include all the transactions in the network in their blocks, then, by Lemma 1, the probability to solve a block

This paper presents an overview of the ImageCLEF 2013 lab. Since its first edition in 2003, ImageCLEF has become one of the key initiative promoting the benchmark evaluation

The goal is to expand on our tools tailored to Bitcoin and offer visual analytics techniques that allow consortium blockchain managers similarly to un- derstand how their

By recording the unique identifier of each legitimate copy of a work on the Bitcoin blockchain, the copy can become forever associated with a particular Bitcoin transaction—even if

We propose a new indicator of problem hardness for tree-based ge- netic programming, called negative slope coefficient, based on the concept of fitness cloud.. The negative

The same sliding mechanism probably allows the nuclear importation of lamins bound to membranes through their farnesyl anchor, either B-type lamins or farnesylated prelamin A

Using a data-driven congestion model that describes the travel time as a function of the number of agents on a road segment, we develop a practical method