2020 Perard Doriane

5)µ4&
&OWVFEFMPCUFOUJPOEV
%0$503"5%&-6/*7&34*5²%&506-064&
%ÏMJWSÏQBS
Institut Supérieur de l’Aéronautique et de l’Espace
1SÏTFOUÏFFUTPVUFOVFQBS
Doriane PERARD
le mercredi 16 décembre 2020
5JUSF

Blockchain et stockage efficace
²DPMF EPDUPSBMF et discipline ou spécialité

ED MITT : Informatique et Télécommunications
6OJUÏEFSFDIFSDIF
Équipe d'accueil ISAE-ONERA MOIS
%JSFDUFVS T
EFʾÒTF
M. Jérôme LACAN (directeur de thèse)
Jury :
M. Carlos AGUILAR-MELCHOR Professeur ISAE-SUPAERO - Président
M. Daniel AUGOT Directeur de recherche INRIA SACLAY - Rapporteur
M. Jean-Christophe DENEUVILLE Professeur associé ENAC
M. Jérôme LACAN Professeur ISAE-SUPAERO - Directeur de thèse
M. Sylvain KUBLER Professeur associé Université de Lorraine
Mme Thi-Mai-Trang NGUYEN Maître de conférences Sorbonne Université
M. Stefano SECCI Professeur CNAM Paris - Rapporteur
"L’essentiel est invisible pour les yeux. C’est le temps que tu as perdu pour ta rose
qui fait ta rose si importante."
Antoine de Saint-Exupéry
Remerciements
Je profite de cet espace pour remercier toutes les personnes m’ayant soutenue
pendant ces trois dernières années (et plus).
Je tiens tout d’abord à remercier mes directeurs de thèse, Jérôme Lacan pour
m’avoir guidée et encouragée jusqu’au Canada, ainsi que Yann Bachy, sans qui cette
thèse n’aurait pas eu lieu, et qui a également répondu présent chaque fois que je
le demandais. Tout ce travail a pu aboutir grâce à eux. Un grand remerciement
aussi à l’ISAE-SUPAERO et plus particulièrement à tout le personnel du DISC (le
meilleur département) et surtout Odile, pour m’avoir si bien accueillie durant 3 ans
et demi. Laisser mon bureau vide, à la fin, aura été un moment intense en émotions.
Merci également aux membres du jury de ma thèse, pour la relecture et les
commentaires sur mon manuscrit ainsi que leurs participations actives lors de ma
soutenance, malgré les conditions sanitaires.
Merci à mes amis et à ma famille.
Dans un premier temps les nouveaux arrivants : cette période de ma vie m’aura
permis de rencontrer beaucoup de personnes géniales. Gabrielle-Kiki, on aura essayé
de faire du sport, de bien manger, et toutes les méthodes d’organisations possibles
et inimaginables, ça n’aura pas forcément abouti, mais au moins on aura bien ri !
Merci pour ces soirées danse et karaoké.
A toute la team pause café du DISC, tout d’abord désolée de vous avoir fait
perdre de l’argent avec le Stellar Lumen, mais ça y est, il a enfin décollé. Je vous
remercie tous, nos pauses infinissables vont me manquer. John, tu as troqué les
cernes du gamer nocturne contre une nouvelle fatigue due à Pavard-second-poteau,
heureusement que les litres de café étaient là chaque matin. Antoine, le seul a
partager ma passion de Pumpkin le raccoon, je n’ai jamais compris comment tu
pouvais prétendre ne pas aimer le fromage tout en faisant fondre du Roquefort.
Eyal, le plus chill de la bande, qui a finalement cédé à la pression en troquant
son téléphone frigo contre un smartphone. Fred, tu as fui pour l’Australie quand
je suis arrivée, mais j’ai ensuite pu découvrir une super personne ouverte d’esprit,
passionné du bon café, et un champion de Pole.
A Xavier, le meilleur stagiaire de France, qui m’a arraché le bras à moult reprises
à l’escrime. Conserve bien ta passion et ton énergie, tu feras de grandes choses avec.
Une grande pensée à Thibault, le seul dans cette liste qui n’est pas (encore)
ii Remerciements
membre du DISC. Merci de m’avoir écoutée râler de longues minutes pendant que
nous faisions des tours de voiturette.
Enfin, une immense merci au Beau Bureau. A toi Henrick, le créateur de cette
expression, qui m’a appris tellement de choses utiles et moins utiles, comme les
particularités d’un Tanuki, comment couper un saucisson avec un couteau dans
un seau sans rien toucher grâce à l’Haskell (j’ai bien compris ?), et qui me faisait
rêver tous les midis avec ses supers bentos. Je t’ai vu réussir tout ce que tu
entreprenais grâce à ton intelligence et ta persévérance, de la thèse au sport, et
j’ai tenté tant bien que mal de suivre tes pas. Big up à Eun-Bee, l’influenceuse
Kimchi, aussi gentille que drôle. A Bastien, le socle de la cohésion entre doctorants,
le seigneur du BDM, l’organisateur des meilleures raclettes et fondues de toute
l’Occitanie (sa patrie), qui réussit l’exploit de me faire venir à Ramonville tous les
samedis matins. Top5 mondial sur un niveau d’Hitman, tu as rendu mes années
toulousaines inoubliables. A tous ceux qui lisent ce texte, abonnez vous à la chaine
"Les Aventures du Ratafia" ! Merci à Guillaume de n’avoir jamais existé mais
d’avoir animé la vie du Disc par sa présence virtuelle pendant une bonne semaine.
Et enfin le dernier membre mais pas des moindres, Lucas, mon frr, mon garde du
corps du Brésil. Qui aurait cru que le grand gaillard sérieux et timide à chemise
arrivant dans le Beau Bureau deviendrait si important dans ma vie ? Courage pour
la fin de ta thèse, et vivement qu’on ouvre notre bar à bières, rhums arrangés et
jeux de société ! Justine, bienvenue à Toulouse, j’espère que tu t’y plairas et que
ton coloc n’est pas trop pénible !
Et pour finir merci à ceux qui étaient déjà là, aux éternels ; vous avez tous
répondu présents, et fait l’effort de vous intéresser quelques heures aux blockchains,
ce qui m’a donné force et courage. Je vous remercie tous. Merci à Mathilde (et
Svarti) pour m’avoir supportée au quotidien et 24h/24 pendant les confinements.
Tu es la meilleure Zouzik et tellement plus. Je l’avoue haut et fort de façon
indélébile ici : "ok, Toulouse est une super ville*". A mes parents, vous qui avez
toujours cru en moi et qui m’avez poussée à donner le meilleur (ou presque).
Après 7 déménagements en presque autant d’années, je suis fière de pouvoir vous
montrer aujourd’hui l’aboutissement de tout cela. Je ne serais jamais arrivée si loin
sans votre amour et votre présence, vous êtes mes modèles de réussite. Rébecca,
ma grande petite sister, tellement intelligente, douée, drôle et gentille derrière ta
petite carapace. Merci pour tous les "TRAVAILLE !" pendant mon sprint final
d’écriture. Térence, le plus gentil de la famille (mouais...), le futur prix Nobel,
Remerciements iii
merci d’être venue si souvent me voir à chocolatine-land, pour encourager le Stade

Toulousain et danser devant des enceintes. Je crois que tu es le seul de cette grande
liste à m’avoir posé des vraies questions sur ma thèse, ta curiosité et ta vivacité
d’esprit m’impressionneront toujours. Marion, tu es la plus mimi, merci d’avoir
relu des dizaines de pages de cette thèse, et d’avoir rejoint le gang des Perard.
Merci à mes 4 grands parents pour tout ce que vous avez fait pour moi ces 27
années, et pour avoir continué à bien me nourrir même si loin de vous. Pauline et
Aurélie, mes amies depuis bientôt 20 ans, vous qui avez parcouru 900 km en 24h
seulement pour venir m’apporter votre soutien et m’encourager. Merci mille fois.
Vous savez combien vous comptez pour moi, mais voici une occasion de plus pour
vous le rappeler. Et merci également à Victoria pour sa petite présence ! Dorine
et Jade, la date de soutenance et le contexte n’ont pas permis que vous soyez là
physiquement, mais vous savoir avec moi même à distance était le plus important,
alors un immense merci.
Enfin, merci aux éventuels lecteurs de cette thèse. Lisez bien le graphique 2.5,
et si cette thèse et son contexte vous intéressent toujours, alors soyez les bienvenus !
Table des matières
1 Introduction 5
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Plan du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 État de l’art 7
2.1 Cryptographie et sécurité informatique . . . . . . . . . . . . . . . . . 8
2.1.1 Propriétés de la sécurité informatique . . . . . . . . . . . . . 8
2.1.2 Fonctions de hachage classiques . . . . . . . . . . . . . . . . . 9
2.1.3 Fonctions de hachage homomorphes . . . . . . . . . . . . . . 10
2.1.4 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Arbre de Merkle . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Généralité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Blockchain publique, blockchain privée . . . . . . . . . . . . . 21
2.2.3 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.4 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Théorie des codes correcteurs . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Théorie de l’information . . . . . . . . . . . . . . . . . . . . . 31
2.3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.3 Construction de codes à effacement . . . . . . . . . . . . . . . 33
2.4 Preuve de récupérabilité . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.2 Principaux travaux . . . . . . . . . . . . . . . . . . . . . . . . 37
3 Client blockchain basé sur les codes à effacement 41

3.1 Introduction et contexte . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.3 Différents types de clients . . . . . . . . . . . . . . . . . . . . 45
3.1.4 Nouvelles solutions émergeantes . . . . . . . . . . . . . . . . . 46
3.2 Description globale du système . . . . . . . . . . . . . . . . . . . . . 47
3.2.1 Noeud LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.2 Accès aux soldes des comptes . . . . . . . . . . . . . . . . . . 48
3.2.3 Interaction avec la blockchain . . . . . . . . . . . . . . . . . . 48
3.3 Protocole des noeuds LS . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1 Fragmentation des blocs . . . . . . . . . . . . . . . . . . . . . 50
3.3.2 Coder les blocs . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.3 Décoder les blocs . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Analyse des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . 54
vi Table des matières
3.4.1 Taille du corps fini . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.2 Complexité de codage . . . . . . . . . . . . . . . . . . . . . . 54
3.4.3 Complexité du décodage . . . . . . . . . . . . . . . . . . . . . 58
3.4.4 Paramètre de fragmentation k . . . . . . . . . . . . . . . . . . 59
3.4.5 Facteur de compression . . . . . . . . . . . . . . . . . . . . . 59
3.5 Décodage en cas de fragments codés erronés malveillants . . . . . . 61
3.5.1 Code correcteur d’erreurs . . . . . . . . . . . . . . . . . . . . 61
3.6 Avantage des noeuds LS . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.6.1 Effort de stockage réduit . . . . . . . . . . . . . . . . . . . . . 72
3.6.2 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.3 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.6.4 Équilibrage de la charge réseau . . . . . . . . . . . . . . . . . 77
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4 BlockHouse : Blockchain-based Distributed Storehouse System 81

4.1 Introduction et contexte . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.3 Clouds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.1.4 Blockchains et systèmes de stockage existants . . . . . . . . . 85
4.2 BlockHouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.1 Général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2 Type de blockchain nécessaire . . . . . . . . . . . . . . . . . . 89
4.2.3 Acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.4 Disponibilité et confidentialité . . . . . . . . . . . . . . . . . . 90
4.2.5 Réputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.6 Intervalle de temps . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Description détaillée du système . . . . . . . . . . . . . . . . . . . . 92
4.3.1 Phase d’initialisation . . . . . . . . . . . . . . . . . . . . . . . 92
4.3.2 Phase de stockage et d’audit . . . . . . . . . . . . . . . . . . 95
4.3.3 Fin du contrat . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.4 Auditeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.4.1 Fonctionnement général . . . . . . . . . . . . . . . . . . . . . 98
4.4.2 Probabilité d’avoir une majorité d’auditeurs honnêtes . . . . 99
4.5 Preuve de récupérabilité . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5.2 Critères de sélection d’une PoR dans notre cas . . . . . . . . 103
4.6 L’aléatoire dans les blockchains . . . . . . . . . . . . . . . . . . . . . 104
4.6.1 Besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6.2 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.3 Intégration dans BlockHouse . . . . . . . . . . . . . . . . . . 106
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table des matières vii
5 Conclusion et perspectives 109

5.1 Résumé du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2 Perspectives futures . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A Liste des publications 113
Bibliographie 115
Table des figures
2.1 Exemple d’un arbre de Merkle . . . . . . . . . . . . . . . . . . . . . 13

2.2 Exemple d’un bloc simple . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Exemple d’une blockchain . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Tentative de modification d’un ancien bloc . . . . . . . . . . . . . . . 20
2.5 Ai-je besoin d’une blockchain ? Traduction du diagramme de l’ar-
ticle [1] par lesechos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Exemple d’ajout d’un nouveau bloc qui aura un parent et un oncle . 28
2.7 Exemple d’un canal binaire symétrique . . . . . . . . . . . . . . . . . 32
2.8 Exemple d’un canal binaire symétrique à effacement . . . . . . . . . 32
2.9 Exemple d’un canal symétrique binaire à erreur et à effacement . . . 33
2.10 Exemple d’un décodage avec un code LT . . . . . . . . . . . . . . . . 35
2.11 Exemple d’un codage avec une opération de précodage . . . . . . . . 36
3.1 Evolution de la taille de la blockchain Bitcoin . . . . . . . . . . . . . 43

3.2 Evolution de la taille de la blockchain Ethereum pour un noeud archive 43
3.3 Fragmentation d’un bloc . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Exemple de codage d’un bloc . . . . . . . . . . . . . . . . . . . . . . 51
3.5 Exemple de décodage d’un bloc . . . . . . . . . . . . . . . . . . . . . 53
3.6 Vitesse de codage et de décodage, sur un PC, avec des blocs de
taille = 1MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7 Vitesse de codage et de décodage, sur un PC, avec des blocs de
taille = 25kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.8 Vitesse de codage et de décodage, sur un raspberry 4, avec des blocs
de taille = 1MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9 Vitesse de codage et de décodage, sur un raspberry 4, avec des blocs
de taille = 25kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.10 Regroupement de plusieurs blocs avant la fragmentation . . . . . . . 60
3.11 Codage d’un bloc avec un code fontaine . . . . . . . . . . . . . . . . 62
3.12 Décomposition d’un bloc . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.13 Paramètres du système . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.14 Système avec empreintes homomorphes . . . . . . . . . . . . . . . . 68
3.15 Temps de génération d’un fragment codé, pour des fichiers de tailles
différentes, et différentes valeurs de k. . . . . . . . . . . . . . . . . . 68
3.16 Temps de calcul d’une empreinte homomorphe pour un fragment . . 70
3.17 Temps de calcul d’une empreinte homomorphe d’un fragment codé à
partir des empreintes homomorphes des fragments originaux . . . . . 70
3.18 Probabilité pour un noeud de stocker r fragments codés, avec une
distribution géométrique de paramètre p = 0.2 . . . . . . . . . . . . 75
3.19 Probabilité qu’un bloc choisi soit irrécupérable, en fonction de n,
avec k = 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
x Table des figures
4.1 EMEA, répartition par origine . . . . . . . . . . . . . . . . . . . . . 82

4.2 APJxC, répartition par origine . . . . . . . . . . . . . . . . . . . . . 82
4.3 EMEA, répartition par type de stockage . . . . . . . . . . . . . . . . 83
4.4 APJxC, répartition par type de stockage . . . . . . . . . . . . . . . . 83
4.5 Protocole de BlockHouse . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.6 Phase d’initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.7 Phase d’audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.8 Phase finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.9 Appel des auditeurs quand le serveur est honnête . . . . . . . . . . . 100
4.10 Appel des auditeurs quand le client est honnête . . . . . . . . . . . . 101
4.11 Probabilité d’avoir une majorité d’auditeurs malhonnêtes, en fonc-
tion de n, avec p = 4/5, p = 5/7 and p = 2/3. . . . . . . . . . . . . . 101
4.12 Propriétés de la PoR . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.13 Paramétrage de la PoR . . . . . . . . . . . . . . . . . . . . . . . . . 104
Liste des tableaux
3.1 Choix de k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2 Choix de r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3 Valeurs de c pour différents k et r, avec sB = 1M B . . . . . . . . . . 71
3.4 Analyse de paramètres pour un bloc de taille 1MB (avec tailles en
octets et temps en secondes) . . . . . . . . . . . . . . . . . . . . . . . 72
Résumé en français
La blockchain est un registre distribué et décentralisé, permettant de stocker et
d’échanger des informations de façon sécurisée, sans tiers de confiance. Pour cela,
les informations, appelées transactions, sont regroupées au sein de blocs, qui sont
ensuite liés entre eux de façon immuable grâce à des procédés cryptographiques. Le
registre sert d’historique de toutes les actions menées par les participants du réseau
depuis sa création.
C’est une technologie en plein essor, de plus en plus utilisée au quotidien. Cet
engouement croissant entraîne une explosion du nombre de transactions, ayant pour
conséquence directe une forte augmentation de la taille des principales blockchains.
Celles-ci deviennent donc plus compliquées à stocker dans leur intégralité, ce qui
peut décourager certains noeuds de stocker toute la blockchain et ainsi réduire le
niveau de décentralisation.
Dans cette thèse, nous proposons un nouveau type de noeud, appelé low storage
(LS) node, qui ne stocke plus les blocs en entier, mais des fragments de ceux-ci codés
avec un code à effacement. Pour retrouver le bloc initial, un noeud LS commence par
télécharger suffisamment de fragments codés depuis d’autres noeuds LS du réseau,
puis procède au décodage.
L’intérêt de cette approche est qu’elle permet à certains noeuds de stocker une
version codée moins volumineuse de la blockchain tout en contribuant à la décen-
tralisation de la blockchain. Elle facilite ainsi le passage à l’échelle des blockchains
qui pose actuellement problème.
Ce manuscrit présente également BlockHouse, un système complet permettant
la location d’espace de stockage libre entre particuliers. La principale innovation
est l’utilisation de contrats intelligents (smart contracts) déployés sur la blockchain
qui permettent des paiements automatiques et sécurisés basés sur des preuves de
récupérabilité des données régulièrement fournies par les serveurs de stockage.
Mots clés : Blockchain, passage à l’échelle, stockage, code à effacement, preuve
de récupérabilité
English summary
A blockchain is a distributed and decentralized registry, allowing to store and
exchange information in a secure way, without trusted third party. To do this,
the information, called transactions, is grouped into blocks, which are then linked
together in an immutable way thanks to cryptographic mechanisms. The registry
serves as an history of all the actions carried out by the network participants since
its creation.
It is a fast-growing technology, more and more used every day. This growing
popularity is leading to an explosion in the number of transactions, and the direct
consequence is an important increase of the size of the main blockchains. They
become more difficult to store in their entirety, which may discourage some nodes
from storing the entire blockchain and thus reduce their decentralization.
In this thesis, we propose a new type of node, called low storage (LS) node, which
no longer stores entire blocks, but fragments of them, coded with an erasure code.
To retrieve the initial block, a LS node first downloads enough coded fragments
from other LS nodes in the network and then decodes them.
The interest of this approach is that it allows some nodes to store a smaller
coded version of the blockchain while contributing to the decentralization of the
blockchain. It thus facilitates the scaling of blockchains, which is one of the major
issue of this technology.
This manuscript also presents BlockHouse, a complete system allowing
nodes to rent their free storage spaces to others. The main innovation is the
use of smart contracts deployed on the blockchain that allow regular, automatic
and secure payments based on proof of retrievability provided by the storage servers.
Key words : Blockchain, scalability, storagee, erasure code, proof of retrieva-

bility
Chapitre 1
Introduction
1.1 Contexte
Une blockchain est un registre distribué et décentralisé, qui permet de stocker et
de transmettre des informations de façon sécurisée, sans utiliser d’autorité centrale.
Pour cela, le registre servant d’historique de toutes les actions menées au sein du
réseau est stocké indépendamment par chaque participant.
Une de ses propriétés principales est donc la décentralisation. Ces multiples
points de stockage empêchent en effet les noeuds malveillants de modifier les données
pour changer l’historique de la blockchain. Cependant, depuis quelques années, les
blockchains deviennent de plus en plus populaires. Les nombres d’utilisateurs et de
transactions augmentent fortement, et il devient difficile de participer activement
au système pour un utilisateur quelconque avec des capacités limitées.
Nous proposons dans un premier temps un nouveau type de client appelé low sto-
rage. Le principe est de ne plus stocker la chaîne dans sa totalité, mais uniquement
des fragments codés. Pour cela, les blocs originaux sont découpés en fragments de
taille fixe, et sont ensuite codés en réalisant des combinaisons linéaires de fragments.
Ce procédé permet de résoudre partiellement deux points sur les trois problèmes
actuels du passage à l’échelle, à savoir la trop grandes place requise pour stocker la
blockchain entière, et l’engorgement du réseau lié au nombre insuffisant de noeuds.
Suite à ces premiers travaux, nous nous sommes intéressés aux blockchains de
stockage existantes. Après une étude approfondie de leurs caractéristiques et dif-
férences, nous avons noté plusieurs points pouvant être améliorés, et avons donc
décidé de proposer notre propre système.
Dans un second temps, nous présentons BlockHouse, une solution de location
d’espace de stockage entre noeuds de la blockchain utilisant des contrats intelligents.
La particularité est que toutes les actions sont enregistrées dans la chaîne, et des
audits réguliers et automatiques sont menés par l’ensemble du réseau, grâce à des
preuves de récupérabilité.
Le contexte précis de chaque partie est expliqué plus en détails au début du
chapitre associé.
6 Chapitre 1. Introduction
1.2 Plan du manuscrit

Ce manuscrit de thèse s’articule en quatre parties.
Dans le chapitre 2, nous présentons un état de l’art des différents concepts et
outils scientifiques ayant été utilisés au cours de cette thèse. Celui-ci commence
par rappeler certaines notions de cryptographie essentielles à la compréhension du
manuscrit. Puis nous présentons les caractéristiques générales des blockchains, en
nous concentrant sur Bitcoin et Ethereum. La troisième section est consacrée à la
théorie de l’information, et plus particulièrement aux codes à effacement. Puis nous
terminons avec les preuves de stockage.
Le Chapitre 3 présente un nouveau type de noeud pour blockchain, appelé "low
storage node", à mi chemin entre le noeud dit "complet" et le noeud dit "léger". Le
principe de ce noeud est de stocker des fragments codés de blocs, et non plus les blocs
dans leur totalité. Des utilisateurs avec une capacité de stockage limité pourraient
ainsi se joindre au réseau, et contribuer à la décentralisation de la blockchain, en
fournissant un effort limité.
Le Chapitre 4 regroupe les travaux portant sur la première thématique cette
thèse, sous le nom de BlockHouse. Cette proposition définit un nouveau système
au sein d’une blockchain, permettant la vérification par l’ensemble du réseau qu’un
noeud stocke bien certaines données. Les noeuds "clients" peuvent ainsi entreposer
leurs données sur des noeuds "serveurs", en profitant des propriétés de décentrali-
sation et de fiabilité de la blockchain.
Pour finir ce manuscrit, le Chapitre 5 donnera les conclusions de ces travaux
ainsi que les perspectives futures.
Chapitre 2
État de l’art
Sommaire
2.1 Cryptographie et sécurité informatique . . . . . . . . . . . . 8
2.1.1 Propriétés de la sécurité informatique . . . . . . . . . . . . . 8
2.1.2 Fonctions de hachage classiques . . . . . . . . . . . . . . . . . 9
2.1.4 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Arbre de Merkle . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Généralité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Blockchain publique, blockchain privée . . . . . . . . . . . . . 21
2.2.3 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.4 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Théorie des codes correcteurs . . . . . . . . . . . . . . . . . . 30
2.3.1 Théorie de l’information . . . . . . . . . . . . . . . . . . . . . 31
2.3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.3 Construction de codes à effacement . . . . . . . . . . . . . . . 33
2.4 Preuve de récupérabilité . . . . . . . . . . . . . . . . . . . . . 36
2.4.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.2 Principaux travaux . . . . . . . . . . . . . . . . . . . . . . . . 37
8 Chapitre 2. État de l’art
Dans cette thèse, nous proposons des contributions prenant place sur les blo-
ckchains. Le fonctionnement de celles-ci repose sur des procédés cryptographiques,
c’est pourquoi cet état de l’art commencera en 2.1 par rappeler certaines notions
de ce domaine, essentielles pour la compréhension de la suite.
Une fois ces notions abordées, nous présenterons les caractéristiques et le fonc-
tionnement des blockchains dans la partie 2.2.
Le chapitre 3 présente un nouveau type de noeud de blockchain, dont le principe
est de stocker des fragments codés à la place des blocs entiers. Pour la compréhension
de cette partie, nous introduisons en 2.3 les concepts de base de la théorie de
l’information et plus particulièrement les codes correcteurs d’erreur.
Le chapitre 4 propose un nouveau système se plaçant au sein de la blockchain,
et permettant de déporter le stockage de données sur un serveur externe, avec
vérifications et paiements automatiques. Ce système repose entre autres sur un
outil appelé preuve de récupérabilité, qui sera abordé en détail dans la partie 2.4.
2.1 Cryptographie et sécurité informatique
2.1.1 Propriétés de la sécurité informatique
La sécurité informatique est la discipline ayant pour but de protéger les sys-
tèmes d’information contre la malveillance. Pour cela, des protections sont mises en
place à différents niveaux : techniques, organisationnels, humains, etc. Une des ma-
nières d’évaluer la sécurité, comme spécifié dans la norme ISO 27001, est de définir
plusieurs propriétés que le système d’information doit respecter :
— Confidentialité : seules les personnes autorisées ont accès à l’information.
Celle-ci peut éventuellement être lue par une personne non autorisée, mais
doit rester inintelligible.
— Intégrité : les données n’ont pas été altérées, elles sont exactes et complètes.
Un adversaire ne doit pas pouvoir les modifier ou les forger.
— Authenticité : l’émetteur est bien celui qu’il prétend être.
— Disponibilité : les données sont accessibles lorsqu’un utilisateur en a besoin.
— Non répudiation : garantir qu’un message a bien été envoyé par son émetteur,
et/ou que le destinataire l’a bien reçu.
Selon les référentiels ou les domaines d’application, ces propriétés peuvent être
plus ou moins nombreuses. Dans le cadre de ce manuscrit, seules celles-ci seront
utilisées.
2.1. Cryptographie et sécurité informatique 9
2.1.2 Fonctions de hachage classiques
Une fonction de hachage est une fonction à sens unique qui, à partir d’un en-
semble de taille variable et diversifié, va retourner une empreinte unique. Cette
empreinte est un ensemble de taille fixe, dont la valeur dépendra de la fonction
utilisée.
La plus récente est SHA-3 [2], validée en 2012 par le National Institute of Stan-
dards and Technology. Elle propose une alternative à la famille des fonctions SHA-2,
qui ne sont toujours pas compromises pour le moment.
Chaque fonction de hachage possède ses propres algorithmes, nous expliquerons
donc le principe générale, et non pas un exemple précis.
Plus formellement, notons notre fonction de hachage h, notre texte initial t
(d’une taille quelconque), sur l’ensemble binaire {0, 1}, et l’empreinte obtenue h(t),
d’une taille m sur l’ensemble binaire {0, 1}. On a alors :
h : {0, 1}∗ →
− {0, 1}m
(2.1)
t→
− h(t)
Sens unique signifie ici que la fonction est facilement réalisable, mais que son in-
verse est très complexe à calculer. Ainsi, on ne peut pas retrouver la donnée d’origine
à partir de son empreinte. Pour cela, la fonction de hachage doit vérifier certaines
propriétés (nous reviendrons plus tard sur la notion d’impossibilité présente dans
ces propriétés) :
— Résistance au calcul d’une préimage : il est impossible calculatoirement de
retrouver un texte x, en connaissant seulement son empreinte. L’équation 2.2
donne une explication plus formelle :
∀X ∈ h ({0, 1}∗ ) il doit être impossible calculatoirement de trouver

(2.2)
y ∈ {0, 1}∗ tel que h (y) = X
— Résistance au calcul d’une deuxième préimage : Pour un texte donné et son

empreinte, il est impossible calculatoirement de trouver un deuxième texte
différent, dont l’empreinte est la même que celle du premier. L’équation 2.2
donne une explication plus formelle :
∀x ∈ {0, 1}∗ il doit être impossible calculatoirement de trouver

(2.3)
y ∈ {0, 1}∗ | y 6= x tel que h (y) = h (x)
— Résistance aux collisions : il est impossible calculatoirement de construire 2

textes tels que leurs empreintes soient identiques. L’équation 2.4 donne une
explication plus formelle :
il doit être impossible calculatoirement de trouver

(2.4)
x, y ∈ {0, 1}∗ | y 6= x tel que h (y) = h (x)
Malheureusement en pratique il n’existe pas de fonction de hachage parfaite,
répondant à ces critères. La fonction de hachage produit une élément de taille fixe,
à partir d’un élément de taille variable, elle n’est donc pas injective : les propriétés
2 et 3 ne peuvent pas être garanties. La notion d’impossibilité est donc remplacée
par une notion de grande complexité de calculs.
Le paradoxe des anniversaires, qui permet d’estimer la probabilité dans un
groupe d’avoir au moins deux personnes nées le même jour, peut nous servir à dé-
terminer la taille que doit avoir l’empreinte de notre fonction de hachage. Grâce à
ce paradoxe, on peut déduire la probabilité d’avoir une collision parmi n empreintes
aléatoires de taille m (éq. 2.5), et donc choisir une taille suffisamment grande pour
que le nombre de calculs soit trop important pour être réalisable dans un temps
raisonnable.
−n(n−1)
p(collision) = 1 − e 2m (2.5)
2.1.3 Fonctions de hachage homomorphes
Une fonction de hachage homomorphe possède les mêmes propriétés qu’une fonc-
tion classique, avec la propriété supplémentaire que l’empreinte d’une combinaison
linéaire de certains blocs d’entrée peut être construite efficacement par une combi-
naison des empreintes des blocs d’entrée. Le but est d’avoir deux opérations, notées
et ◦, telles que h(ca .acb .b) = hca (a) ◦ hcb (b), avec a et b des vecteurs, et ca et cb
des scalaires.
Dans cette thèse, nous avons utilisé les résultats de l’article "On-the-fly verifi-
cation of rateless erasure codes for efficient content distribution" [3], ainsi que ceux
de "Cooperative Security for Network Coding File Distribution" [4], permettant
l’homomorphie avec l’addition sur Zq et ◦ la multiplication sur Zp .
Soit F le fichier dont on souhaite l’empreinte. Ce fichier est séparé en n blocs,
notés bi avec i ∈ {1, n}, et chaque bloc est lui-même séparé en m sous-blocs notés
bi,j avec i ∈ {1, n} et j ∈ {1, m}. Le fichier peut donc être représenté par une
matrice :  
b1,1 b1,2 ... b1,n
 
b b2,2 ... b2,n 
 2,1
(2.6)

 
 ... 
 
bm,1 bm,2 ... bm,n
Les paramètres du système à générer sont p et q, deux grands nombres premiers

tel que q|(p − 1), et un vecteur ligne de taille 1 × m, noté g, composé d’éléments
aléatoires de Zq . Les additions seront effectuées sur Zq , tandis que les multiplications
et exponentiations seront sur Zp . La taille de ces nombres est à définir en fonction
du système, car influe directement sur sa sécurité mais également sur la complexité
des calculs.
Qm bi,j
L’empreinte d’un bloc de ce ficher est définie par h(bj ) = i=1 gi mod p et
ainsi l’empreinte globale du fichier est définie par h(F ) = h(b1 + b2 + ... + bn ) =
h(b1 ) × h(b2 ) × ... × h(bn ).
Il est également possible de coder les blocs, en réalisant des combinaisons li-
Pn
néaires de blocs : cb = i=1 ci .bi mod q, avec (c1 , . . . , cn ) ∈ Znq . Dans ce cas,
Pn Qn ci
l’empreinte du bloc est égale à h(cb) = h( i=1 ci .bi ) mod p = i=1 h(bi ) mod p.
Cette fonction de hachage se base sur le problème du logarithme discret (pour
un groupe cyclique G fini engendré par α, le logarithme discret est l’application qui
associe à un élément β de G le plus petit entier naturel k tel que αk = β), et est
résistante aux collisions.
2.1.4 Signatures
La signature numérique a pour but de garantir les propriétés d’authenticité de

l’émetteur d’un message, l’intégrité des données et la non répudiation.
C’est une composante de la cryptographie à clé publique / clé privée, également
appelée cryptographie asymétrique. Chaque utilisateur possède un couple de clés,
constitué d’une clé publique (connue par l’ensemble du réseau), notée e et d’une clé
privée (connue uniquement par son possesseur), notée d. Pour les fonctionnalités
de chiffrement, la clé publique sert à chiffrer et la clé privée à déchiffrer. Pour la
signature, ce sera l’inverse.
Pour signer un message m, on calcule tout d’abord son empreinte avec une
fonction de hachage h(m). Une fonction de signature S publique associe une clé
privée d et un texte en clair m. On calcule la signature sm = S(d, h(m)). On envoie
le message original m et la signature associée sm .
Une fonction de vérification V associe une clé publique e et une signature sm . Le
destinataire du message reçoit un texte en clair, que l’on notera m0 et une signature
sm . En appliquant la fonction de vérification de la signature avec la clé publique
du destinataire e, V (e, sm , m0 ), on vérifie à la fois que l’empreinte du message reçu
correspond à celle de la signature (intégrité), et que la signature a bien été faite
par la bonne personne (authenticité). Tout le monde connaît e, donc peut s’assurer
que c’est le bon émetteur, car lui seul connaît le d associé. Combiné au fait que
l’on respecte les propriétés d’intégrité et d’authenticité, on obtient également la
propriété de non répudiation.
Voici quelques exemples d’algorithmes asymétriques pouvant être utilisés pour
la signature :
— RSA [5] : Repose sur le petit théorème de Fermat et l’exponentiation mo-
dulaire. Les calculs se font modulo n, le produit des deux nombres premiers
distincts. Pour chiffrer et déchiffrer, le message est élevé à la puissance d’un
nombre, qui est la clé publique ou la clé privée selon la situation. A sa
conception, RSA était sous brevet MIT.
— ElGamal [6] : Se base sur l’exponentiation modulaire ainsi que sur le pro-
blème du logarithme discret. Les calculs se font modulo p, un nombre pre-
mier. La clé publique est un nombre élevé à la puissance de la clé privée
kp = αks mod p. La clé privée permet donc de déchiffrer, en mettant le
message chiffré à la puissance de son opposé m = m−k
c
s mod p. L’utilisation
d’un nombre aléatoire pour chaque nouvelle signature rend la fonction non
deterministe.
— DSA : Se base sur le problème du logarithme discret. C’est une amélioration
de l’algorithme de ElGamal, qui permet d’avoir une signature de taille infé-
rieure, en prenant des élément d’un sous groupe, tout en assurant la même
sécurité.
— ECDSA ("Elliptic Curve Digital Signature Algorithm") [7] : utilisée par
exemple sur les blockchains Bitcoin et Ethereum, le principe est similaire
à DSA, mais le groupe est une groupe de points sur une courbe elliptique
sur un corps fini. La sécurité est renforcé sur un tel groupe, car il n’existe
pour le moment pas d’algorithme permettant de réduire la complexité de la
résolution du problème du logarithme discret.
— Schnorr [8] est une preuve à divulgation nulle de connaissance, reposant
encore sur le problème du logarithme discret. Le protocole est intéractif entre
plusieurs entités et se déroule en trois étapes : engagement, défi, réponse.
Il n’est possible de répondre correctement au défi qu’en connaissant la clé
privée. Son utilisation est fortement envisagé pour une évolution future de
Figure 2.1 – Exemple d’un arbre de Merkle
Bitcoin.
2.1.5 Arbre de Merkle
Un arbre de Merkle est une structure informatique particulière, présenté en 1987

par R. Merkle [9]. L’objectif de cet article est de proposer une solution permettant de
vérifier l’intégrité d’un ensemble de données, sans avoir ni à les stocker entièrement,
ni à stocker l’empreinte de chaque donnée.
Pour le construire on commence par découper le fichier en plusieurs blocs, ici

d1, d2, d3 et d4 dans le schéma 2.1. On obtient ainsi h(d1), h(d2), h(d3) et h(d4).
On concatène ensuite ces empreintes deux à deux (par exemple h(h(d1) + h(d2))),
et on re-hache l’ensemble obtenu. Ces opérations sont réitérées jusqu’à obtenir une
unique empreinte, la racine de notre arbre. Cette racine dépend de toutes les opéra-
tions faites précédemment, et donc directement des données initiales. Les propriétés
des fonctions de hachage, telles qu’expliquées dans la section 2.1.2, garantissent de
pouvoir vérifier que des données correspondent bien à une racine de Merkle, car
modifier une donnée revient à modifier son empreinte. On obtient un temps de
vérification logarithmique dans la plupart des implémentations.
Dans notre exemple, pour vérifier l’intégrité de d3, nous avons besoin de h(d4),
h(h(d1) + h(d2)) et de la racine. Il n’est donc pas nécessaire de télécharger toutes
les données.
2.2 Blockchain
2.2.1 Généralité
2.2.1.1 Historique
En 1988, D. Chaum, propose un nouveau système de paiement, anonyme, afin

de permettre aux utilisateurs d’effectuer des transferts d’argent sur internet sans
être traçables par le gouvernement [10]. Pour permettre cela, il utilise les signatures
aveugles, qu’il a développé dans ses précédents travaux [11]. L’année suivante sort
l’implémentation, sous le nom de DigiCash. Cependant le projet est un échec, en
partie car le commerce en ligne n’en est encore qu’à ses prémices, et le projet est
abandonné faute de moyens suffisants.
En 1991, S. Haber et W.S. Stornetta écrivent un article sur un nouveau moyen
de certifier qu’un document n’a pas été falsifié [12]. Pour cela, ils proposent de
stocker l’empreinte du document dans une chaîne linéaire, en considérant que la
fonction de hachage est résistante aux collisions. Afin d’en améliorer l’efficacité, en
1992, ce concept est repris et amélioré par D. Bayer, S. Haber et W.S. Stornetta
qui ajoutent des arbres de Merkle [13], afin de permettre le stockage d’informations
de plusieurs documents dans un seul bloc de la chaîne.
En 1993, deux nouveaux articles présentant des monnaies électroniques sont
proposés : Single Term Off-Line Coins de N. Ferguson [14] et Untraceable Off-Line
Cash in Wallets with Observers de S.Brands [15].
En 1996 la NSA publie un rapport "How to make a mint : the cryptography
of anonymous electronic cash" [16], pour exprimer leurs inquiétudes vis à vis des
monnaies électroniques. Ce document soulève plusieurs problèmes potentiels, qui
sont encore d’actualité de nos jours :
— Le problème de la double dépense : dans le cas de paiement hors ligne (ou
d’un réseau asynchrone), il n’est pas possible de garantir qu’une pièce de
monnaie ne soit dépensée qu’une fois.
— Pour effectuer un transfert d’argent, l’utilisateur doit utiliser un portefeuille
électronique, développé par une entreprise. Celui-ci peut être vu comme un
tiers de confiance pouvant potentiellement agir à l’encontre de la volonté de
son propriétaire (tracer les transactions par exemple). Celui-ci peut égale-
ment être en charge de vérifier qu’il n’y a pas de double dépense.
— Toute la sécurité du protocole réside sur les fonctions de cryptographie choi-
sies, qui ne sont pas réellement sûres comme nous l’avons vu dans la section
2.1.2.
2.2. Blockchain 15
— Les lois ne peuvent pas directement être adaptées à la monnaie électronique.

L’aspect anonyme est susceptible de poser problème dans le cas d’une en-
quête, et peut permettre de frauder plus facilement.
En 1997, A. Back propose une méthode de preuve de travail, sous le nom de

hashcash [17]. Le principe est d’effectuer une certaine quantité de travail, nécessi-
tant des ressources du CPU, pour accéder à un service. Dans le cas d’un utilisateur
légitime, ce travail est négligeable, alors que dans le cas d’une personne malveillante
voulant accéder au service de façon répétée, cette quantité de travail devient consi-
dérable. Cette technique est utilisée par exemple pour lutter contre le spam ou bien
le déni de service.
Mais le hashcash permet également de venir à bout du problème du consensus,

qui sera expliqué en détail dans la partie 2.2.3. En 1998, W. Dai utilise donc cette
preuve de travail pour synchroniser sur un réseau une base de données, appelée b-
money [18], dans laquelle est inscrite la valeur possédée par chacun des participants.
La même année, N. Szabo propose de son coté le BitGold [19], avec un principe
similaire.
En 2008, Satoshi Nakamoto écrit l’article fondateur du Bitcoin, la première vraie

chaîne de blocs [20]. Ce nom semble être un pseudonyme, et la réelle identité de
cette personne, ou de ce groupe de personnes, reste à ce jour un mystère. Cet article
décrit la structure et le fonctionnement du protocole Bitcoin, de façon théorique. La
première implémentation du Bitcoin arrive l’année suivante, en 2009, sous le nom
de Bitcoin-QT. C’est également la première fois que le mot blockchain est employé.
En 2013, V. Buterin décide de reprendre le concept de la blockchain, en y ajou-

tant la possibilité d’exécuter des applications décentralisées. Le but de cette nouvelle
blockchain, appellée Ethereum [21], est de construire une sorte d’ordinateur géant
décentralisé. Ces applications sont possibles grâce aux contrats intelligents.
Ce concept avait été publié pour la première fois en 1994 par N. Szabo [22],
qui présentait le contrat intelligent comme "un protocole de transaction informatisé
qui exécute automatiquement les termes d’un contrat." Un accord entre plusieurs
entités, écrit sous la forme d’un code informatique, et décentralisé. La décentralisa-
tion est possible car le contrat est stocké dans la blockchain, donc distribué sur le
réseau, et s’exécute automatiquement sous certaines conditions, sans avoir besoin
d’une tierce personne.
La technologie blockchain est peu à peu devenue connue du grand public, et de

nombreuses nouvelles ont vu le jour.
2.2.1.2 Principe général d’une blockchain
Afin d’expliquer le plus simplement possible le fonctionnement général d’une

blockchain, nous prendrons dans un premier temps l’exemple de la blockchain
Bitcoin, précurseure du domaine, dont les principes de base se retrouvent dans la
majorité des autres.
Dans sa définition formelle, la blockchain est un registre distribué et décentralisé

qui permet de stocker et d’échanger des informations sans tiers de confiance. Ce
registre sert d’historique de toutes les actions menées par les participants (appelés
noeuds) depuis sa création.
Cette technologie tire son nom de ses deux points clés principaux. Les utili-
sateurs possèdent des jetons, servant de monnaie au sein de la blockchain, qu’ils
peuvent s’échanger. Les actions au sein du réseau, appelées transactions, sont
regroupées dans des blocs. L’intégralité des actions de tous les utilisateurs est
ainsi stockée au sein de la chaîne.
Afin de sécuriser la blockchain en la rendant infalsifiable, on ajoute en plus dans
chaque nouveau bloc l’empreinte cryptographique du bloc précédent (voir figure
2.3). On chaîne donc les blocs entre eux, d’où le nom de blockchain.
Le but principal de ce système est d’éviter les intermédiaires. Pour cela, chaque
machine participant au réseau stocke sa propre chaîne, sur sa propre mémoire.
Toutes ont en commun le même bloc initial, appelé bloc genèse. Lorsqu’un nouveau
bloc est ajouté, le noeud vérifiera sa validité grâce à ses informations, et le validera
(ou non) en l’ajoutant à la suite de sa chaîne. Il peut ainsi avoir une entière
confiance dans les informations qu’il stocke, puisqu’il a vérifié chacune d’elles.
Chaque nouveau bloc est créé à intervalle régulier par un noeud choisi par le
réseau, selon la méthode de consensus propre au système (voir section 2.2.3). Il est
ensuite envoyé à tous les noeuds du réseau, qui en vérifient indépendamment la
validité. Dans la pratique, le réseau est loin d’être totalement temps réel, il peut
donc arriver que des machines n’aient pas exactement la même version de la chaîne
à un moment donné. Dans ce cas, la règle est de choisir la chaîne valide la plus
longue.
Une blockchain est considérée comme valide lorsqu’il est possible de la recons-
truire entièrement en partant du bloc genèse.
2.2. Blockchain 17
2.2.1.3 Structure du réseau
Chaque participant du réseau, appelé noeud, est en réalité un ordinateur sur

lequel tourne un logiciel spécial appelé client. Pour une blockchain il peut exister
différents clients, développés par plusieurs communautés ou entreprises, dans des
langages variés. Le but étant qu’au final tous ces clients s’interfacent sans difficultés,
car tous respectent les conventions et structure de la blockchain.
Le réseau est organisé en système pair-à-pair, c’est à dire que chaque machine
est à la fois client et serveur, et s’organise sans avoir besoin d’une autorité centrale.
Les échanges se font directement d’un ordinateur à un autre.
Lorsqu’un nouveau noeud souhaite rejoindre le réseau, il se connecte à un ou
plusieurs noeuds, dont les adresses sont connues via par exemple un site internet ou
encore écrites directement dans le code source du client. Puis grâce à ces noeuds,
il peut obtenir l’adresse d’autres noeuds, eux-mêmes connectés à d’autres noeuds,
etc. La topologie du réseau est donc complexe et en mouvement, et il est assez
compliqué d’obtenir des informations précises en temps réel dessus.
Les réseaux pair-à-pair sont principalement connus du grand public pour le par-
tage de fichiers, illégal dans de nombreux cas, mais leurs usages sont nettement plus
larges. Le pair-à-pair permet, entre autres, de faire du calcul distribué, d’échanger
des paquetages de logiciels et des images ISO pour certaines distributions de Linux,
de résoudre des requêtes DNS, et beaucoup plus encore.
2.2.1.4 Structure d’un bloc et de la blockchain
Comme nous venons de le voir, une blockchain est une séquence de blocs. La
structure exacte d’un bloc dépend de la blockchain en question et est spécifiée
dans son protocole, mais un certain nombre d’informations restent obligatoires et
communes :
— Le numéro du bloc, permettant de vérifier l’ordre de la chaîne.
— L’horodatage, indiquant la date et l’heure à laquelle le bloc a été créé. Les
blocs se suivent de façon chronologique.
— La donnée du bloc, contenant par exemple les transactions. La section 2.2.1.5
rentrera dans les détails.
— Le NONCE (number used once) est un nombre aléatoire. Il permet de réaliser
la preuve de travail, comme nous l’expliquerons dans la section 2.2.3.
— L’empreinte du bloc précédent, qui permet de lier les blocs entre eux. En
effet connaissant l’empreinte du bloc précédent, il est possible de s’assurer
de son intégrité, et donc de repérer des éventuelles modifications.
Figure 2.2 – Exemple d’un bloc simple
Figure 2.3 – Exemple d’une blockchain
— L’empreinte du bloc courant.

La figure 2.2 représente un schéma d’un bloc quelconque. Les informations sont
séparées en deux parties, l’en-tête, qui contient les informations caractérisant le
bloc, et les données, qui contiennent les informations relatives aux transactions.
2.2.1.5 Données et transactions
Un compte utilisateur d’une blockchain est une adresse à laquelle est associé un
couple de clés privée/publique. Transférer des jetons vers un autre compte revient
à émettre un message signé avec sa clé privée vers l’adresse du destinataire, en
précisant le nombre de jetons concernés. Comme nous l’avons vu dans la partie 2.1,
2.2. Blockchain 19
la signature permet de garantir l’authenticité et l’intégrité des données, ainsi que

la non répudiation. Cette signature garantit donc à elle seule que l’émetteur a bien
donné son accord pour transférer cet argent, et une fois validée, ne peut plus être
modifiée ou contestée.
Bitcoin utilise un système de script pour s’assurer que le compte possède bien
les jetons qu’il souhaite dépenser. Mais ce langage n’est pas Turing complet, et est
donc limité. Ces scripts permettent de lier les jetons qui vont être dépensés par le
compte dans une transaction avec des jetons qui ont été versés antérieurement à ce
même compte, et pas encore dépensés.
La partie données d’un bloc est valide si toutes les transactions qu’il contient sont
légitimes et authentiques, ce qui est vérifiable grâce à l’historique des transactions
que chaque noeud possède.
2.2.1.6 Propriété d’immuabilité de la blockchain
Une des particularités de la blockchain, est de chaîner les blocs entre eux, grâce
à la cryptographie. Pour cela, on ajoute dans chaque nouveau bloc l’empreinte du
bloc précédent, qui lui même contiendra l’empreinte du bloc le précédant. Ainsi, les
blocs vont être liés entre eux de façon immuable, permettant de garantir l’intégrité
des données. Si une personne malveillante tente d’altérer un bloc au milieu de la
chaîne, cette modification aura une impact directe sur son empreinte, et le bloc
suivant ne le reconnaîtrait plus.
Pour illustrer cela, dans la figure 2.4, on tente de modifier le contenu du bloc
94.
Dans ce schéma, la blockchain originale est représentée en noir. Pour des
raisons de lisibilité, seules les empreintes des blocs précédents sont représentés.
Un attaquant décide de modifier le bloc 51, afin d’y insérer une transaction en sa
faveur (par exemple un transfert de fond important vers son compte). Le nouveau
bloc, que nous appellerons 94’, est représenté en rouge. Comme son contenu est
différent du bloc 51, son empreinte sera également différent. Ainsi, le bloc 95 ne
reconnaîtra pas le bloc 94’ comme son bloc précédent. Comme il est d’usage de
choisir la chaîne la plus longue, les autres noeuds du réseau continueront avec la
blockchain d’origine, en noir. Il faudrait reconstruire toute la suite de la chaîne
pour obtenir une chaîne valide.
Il faudrait ainsi changer le bloc suivant, et ainsi de suite. Le tout suffisamment

Figure 2.4 – Tentative de modification d’un ancien bloc

2.2. Blockchain 21
rapidement pour rattraper et dépasser la chaîne courante légitime, puisque, comme

dit précédemment, la chaîne la plus longue est choisie en cas de double chaîne. Cette
prouesse nécessiterait d’accomplir le processus de consensus très rapidement (pour
pouvoir être choisi pour créer le nouveau bloc, voir section 2.2.3), ce qui pourrait
avoir deux impacts négatifs :
1. Tout d’abord la méthode de consensus est justement choisie pour être suf-
fisamment compliquée à réaliser pour ne pas pouvoir rattraper la chaîne
courante. Cela impliquerait des coûts très élevés. Or le noeud accomplissant
le consensus et créant le nouveau bloc reçoit une récompense. Il est donc
plus rentable pour le noeud de jouer le jeu de façon honnête.
2. Considérons maintenant le cas où le noeud malveillant réussirait à modifier

un bloc, puis à reconstruire la chaîne plus rapidement que la chaîne légitime.
Cette action aura sans doute pour but d’annuler certaines de ses dépenses,
pour récupérer des jetons. Cependant la blockchain fonctionne car les utili-
sateurs ont confiance dans le système. Cette action malveillante risquerait de
briser cette confiance, et de totalement déstabiliser l’équilibre du système,
entraînant une méfiance et potentiellement une chute de la valeur des jetons.
2.2.2 Blockchain publique, blockchain privée
Comme nous l’avons vu précédemment, la blockchain est par définition un réseau

pair-à-pair décentralisé, où chaque participant détient un exemplaire du registre
distribué contenant des transactions signées numériquement. La synchronisation se
fait grâce au consensus, que nous aborderons plus en détail dans la section 2.2.3.
Sur les blockchains traditionnelles comme Bitcoin et Ethereum, n’importe quelle
machine peut se joindre au réseau sous forme de noeud, et tous les noeuds sont en
droit de participer au consensus, pour concourir à la création d’un nouveau bloc.
Depuis quelques années, un nouveau type de blockchain avec plus de restrictions a
fait son apparition, avec notamment le client HyperLedger Fabric, développé en 2015
par la Fondation Linux. Le premier cas regroupe les blockchains dites publiques,
en opposition au deuxième cas, les blockchains privées.
Les deux permettent de garantir l’intégrité des données, même en présence de
malveillance. La principale différence repose sur le droit des noeuds à pouvoir par-
ticiper au système, écrire ou même lire les données.
2.2.2.1 Blockchain publique
La première blockchain, Bitcoin, est une blockchain publique, même si la préci-

sion n’était pas de rigueur à l’époque puisque seule existait ce type de blockchain.
Dans un projet où le but est de s’affranchir d’intermédiaire de confiance, il semble
assez naturel de ne pas mettre en place un contrôle d’accès, et que n’importe quelle
machine disposant du logiciel client puisse rejoindre la blockchain et se synchroniser.
Chaque participant peut ainsi participer au consensus pour créer le nouveau
bloc, et il y a généralement une incitation financière à participer, car le consensus
nécessite de mobiliser des moyens importants (voir section 2.2.3 pour plus de dé-
tails). Il n’y a donc pas besoin de confiance envers les autres participants, qui sont
d’ailleurs inconnus, ni besoin d’une autorité centrale. Cette incitation financière
peut être des jetons créés en même temps que le nouveau bloc et qui seront versés à
son créateur, ou des frais de transaction que paye chaque personne voulant émettre
une transaction (obligatoire ou facultatif, selon le modèle choisi).
Dans ce contexte, il est compliqué d’avoir des informations précises sur le réseau,
comme par exemple le nombre de participants en temps réel, à cause de la topologie
du réseau pair-à-pair et le fait qu’il n’y ait pas besoin d’acceptation pour rejoindre
le réseau.
Les blockchains principales sont des blockchains publiques, comme Bitcoin,
Ethereum, Monero, Litecoin, Dash.
2.2.2.2 Blockchain privée
Les blockchains privées possèdent une principe similaire aux blockchains pu-
bliques, mais l’accès est restreint, et les noeuds ne possèdent pas tous des droits
identiques. Le nombre de noeuds étant plus restreint, elles sont moins décentra-
lisées, mais l’information circule plus rapidement. Le choix de consensus est plus
varié, et il peut même d’ailleurs être inexistant dans le cas d’une blockchain privée
avec autorité centrale. De plus, certains méthodes de consensus ne demandent pas
d’effort, les frais de transaction n’ont donc plus de raisons d’être. Ces blockchains
peuvent être regroupées en deux catégories : consortium et privée. Hyperledger Fa-
bric, R3 Corda et Quorum sont trois exemples de blockchains pouvant tourner en
privée ou en consortium, selon le contexte où elles sont déployées.
Les blockchains de consortium sont généralement utilisées dans les cas où

les membres du réseaux veulent avoir un regard sur qui peut les rejoindre, mais
sans utiliser un tiers de confiance ou une autorité centrale. Ils peuvent par exemple
2.2. Blockchain 23
procéder à un vote pour se mettre d’accord sur l’acceptation ou le refus d’accueillir

un nouveau participant.
Ce système peut être utile dans le cas d’entreprises avec des intérêts divergents,
mais un minimum de confiance et de connaissance les unes avec les autres. Chaque
entité stocke donc son propre jeu de données et limite ainsi la confiance qu’elle porte
aux autres. Les données sont accessibles uniquement aux noeuds validés.
Les blockchains privées avec autorité centrale fonctionnent grâce à un tiers

de confiance, qui valide l’entrée des autres noeuds dans le réseau, et créée et partage
les nouveaux blocs. Les autres noeuds peuvent lui envoyer les transactions qu’ils
souhaitent voir apparaitre dans la blockchain, et continue de valider et stocker la
chaîne.
2.2.2.3 Choix
Le choix d’utilisation d’une blockchain, publique ou privée (de consortium ou

non), est loin d’être trivial, et doit être mûrement réfléchi. La tendance actuelle à
vouloir utiliser des blockchains à tort dans chaque nouveau projet est loin d’être
une bonne chose, et décrédibilise la technologie. L’article [1] s’intéresse justement à
cette problématique, et fait le point sur les critères à prendre en compte en compte
pour faire son choix. Le schéma de la figure 2.5 est une traduction du diagramme de
décision présent dans cet article, qui récapitule les questions à se poser pour décider
du choix de la technologie à utiliser.
Figure 2.5 – Ai-je besoin d’une blockchain ? Traduction du diagramme de l’ar-

ticle [1] par lesechos.
2.2.3 Consensus
Un consensus est par définition un accord entre plusieurs parties amenant au

consentement de la majorité. Dans le cas des blockchains, il convient de trouver un
moyen pour que l’ensemble du réseau se mette d’accord sur le nouveau bloc et son
contenu à ajouter à la chaîne. Un algorithme de consensus valide doit répondre à
trois critères :
— Terminaison : chaque participant du réseau doit à la fin avoir choisi un bloc.
— Intégrité : ce bloc doit avoir a été proposé par un des noeuds du réseau.
— Accord : tous les participants décident du même bloc.
De plus, étant dans un réseau pair-à-pair asynchrone avec potentiellement des
défaillances, l’algorithme doit être résistant aux pannes dans une certaine mesure.
En 1985, trois chercheurs [23] ont démontré qu’il était impossible de construire
un algorithme capable de valider les trois critères présentés précédemment, en pré-
sence de fautes. Il convient donc de trouver l’algorithme permettant de valider le
plus de critères, tout en spécifiant les limites de son utilisation.
De nombreux travaux ont été réalisés depuis l’introduction par L. Lamport de
Paxos [24], qui garantit un consensus dans un réseau asynchrone tant que le nombre
de machines en fonctionnement est supérieur au nombre de machines défaillantes.
Certaines machines du réseau vont faire des propositions, et les autres machines
vont valider et enregistrer la dernière proposition reçue, en la renvoyant aux autres
participants, jusqu’à ce que la majorité ait validé la même valeur. Comme chaque
membre est censé être honnête, et donc accepté la valeur sans réticence, l’algorithme
converge au bout d’un certain temps.
Dans le cas des blockchains, il faut également prendre en compte le fait qu’il
n’y a pas de confiance dans le réseau, et que les autres noeuds peuvent se comporter
de façon malhonnête.
Ce problème concernant l’intégrité des différents protagonistes lors d’une trans-
mission d’information, est un problème important en informatique. Il est appelé
"problème des généraux byzantins" [25].
PBFT [26] est un algorithme permettant d’arriver à un consensus en présence
d’au plus f noeuds malveillants, si le réseau est composé d’au moins 3f + 1 ma-
chines. Pour rendre cela possible, le réseau se sépare en deux groupes, les noeuds
primaires, proposant des valeurs, et les noeuds secondaires, validant et relayant les
propositions, jusqu’à arriver à une majorité d’accords, similairement à Paxos. L.
Lamport a d’ailleurs ensuite également adapté Paxos, afin de le rendre tolérant aux
2.2. Blockchain 25
attaques byzantine [25]. Ce type d’algorithme peut être utilisé pour les blockchains
privées.
Cependant les blockchains publiques ont besoin d’arriver à un consensus à des
périodes régulières, et peuvent être constituées d’un très grand nombre de noeuds
(ce nombre étant d’ailleurs généralement inconnu). De plus, n’importe qui peut
rejoindre le réseau sans vérification, et il est donc possible de créer plusieurs comptes
pour une seule et même personne. Le mécanisme de consensus doit être résistant
aux attaques Sybil (basées sur la création de fausses identités). Pour ces raisons,
d’autres méthodes de consensus ont été choisies.
La preuve de travail (proof of work) a été utilisée dès la spécification de

Bitcoin, en 2009 [20]. Le principe est de résoudre un problème cryptographique
difficile. Ainsi, en échange d’une quantité de travail effectuée, le noeud compétiteur,
appelé mineur, gagne le droit de créer le nouveau bloc de la chaîne, et l’éventuelle
récompense qui va avec (la récompense du bloc et les éventuels frais de transactions).
La preuve de travail utilisée par Bitcoin est le Hashcash, créé par A. Back en
1997 [17]. Le but est de trouver une valeur de NONCE, telle que l’empreinte de
l’en-tête du bloc soit inférieure à un certain seuil fixé. Ce seuil permet d’adapter
la difficulté de résolution du challenge, pour avoir une création de bloc à intervalle
quasiment fixe, même lorsque la puissance de calcul du réseau varie. Il n’y a pas de
réelle stratégie pour résoudre le challenge, le but étant de tester un grand nombre
de NONCE jusqu’à en trouver un qui fonctionne. Si cette résolution est coûteuse
en temps et en ressource, sa vérification est triviale et rapide, permettant à chaque
participant du réseau de s’assurer que le nouveau bloc créé est légitime.
Cet algorithme permet de lutter facilement contre les attaques Sybil, puisque
seule la puissance de calcul possédée par un participant lui permet de résoudre
le challenge. Cependant, un participant possédant plus de 51% de la puissance de
calcul totale du réseau aurait une très forte probabilité de sortir gagnant de chaque
challenge, et donc de forger à lui tout seul la chaîne.
La preuve d’enjeu (proof of stake) est une autre proposition de résolution du

consensus, soutenue entre autre par les développeurs d’Ethereum (voir partie 2.2.4).
Pour élire le noeud qui créera le nouveau bloc, le système se base sur sa participation
au système. Plusieurs critères peuvent entrer en compte, comme la quantité de
jetons qu’il possède, ou bien encore la durée de possession. Si la sécurité de la preuve
de travail repose sur les fonctions de hachage, celle de la preuve d’enjeu repose sur
les signatures cryptographiques, permettent de s’assurer qu’un tel possède bien les
jetons qu’ils prétend avoir.
D’autres preuves ont vu le jour, ou sont en développement. Cet engouement

pour des nouvelles preuves est en partie dû à l’énorme gaspillage d’énergie induit
par la preuve de travail, qui parait peu compatible dans notre société actuelle où
le changement climatique devient un enjeu majeur. Une autre raison est l’appari-
tion des blockchains privées, qui sont plus controlées et permettent donc d’utiliser
d’autres mécanismes de consensus jusqu’alors incompatible (comme expliqué pour
Paxos, qui demande une connaissance du nombre de participants). Parmi ces nou-
veaux consensus, on peut citer :
— Raft est un consensus développé dans le cadre d’une thèse en 2014 [27], dont
le but est de rendre Paxos plus compréhensible et facile à implémenter, en
le décomposant en sous problèmes.
— La preuve de temps écoulée (proof of elapsed time), soutenue par Hyperled-
ger Sawtooth (Intel et Linux Fondation), consiste à ce que tous les noeuds
du réseau attendent une durée aléatoire qui lui est imposée, et le premier
à avoir fini d’attendre remporte le droit de créer le nouveau bloc. La dif-
ficulté de cette méthode est de s’assurer que le temps d’attente a bien été
attribué aléatoirement. Pour cela, le code doit s’exécuter dans un environ-
nement sécurisé et précis (développé par Intel), avec un jeu d’instructions
particulières.
— La preuve d’autorité (proof of authority) donne le droit de création de blocs
à un nombre limité de noeuds de confiance, appelés Authorities. Une sorte
de PBFT se joue alors entre seulement ces noeuds, ce qui le rend beaucoup
plus rapide à accomplir.
— La preuve de réputation (proof of reputation) a un principe assez similaire
à celui de la preuve d’autorité, car seuls certains noeuds sont autorisés à
créer des blocs. La différence réside dans le fait que ces noeuds sont choisis
en fonction de leur réputation. Cette réputation est calculée selon différents
algorithmes, et peut prendre en compte la réputation au sein de la blockchain
(le noeud agit honnêtement), comme la réputation réelle (une entreprise, avec
des intérêts non contradictoires par exemple).
— La preuve de destruction (proof of burn) peut être vue comme une alternative
à la preuve de travail, le gaspillage énergétique en moins. Le principe est le
même, mais le minage se fait de façon virtuelle. Pour cela, les utilisateurs
vont "brûler" certains de leurs jetons, pour simuler une dépense financière
qui servirait à miner pour résoudre la preuve de travail dans la vie réelle
2.2. Blockchain 27
(achat du matériel, éléctricité). Plus l’utilisateur va brûler des jetons, plus

sa puissance de calcul virtuelle sera importante, et plus il aura de chance
d’être choisi pour créer le prochain bloc.
— La preuve de stockage [28] (proof of storage) demande aux noeuds du réseau
de stocker d’importante quantité d’information, pour espérer être élu pour
créer le prochain bloc. S’ensuit des étapes de questions - réponses sous forme
de challenge, pour vérifier que le noeud stocke réellement ce qu’il prétend
stocker. Ce consensus est utilisé entre autre dans la blockchain Spacemint,
ainsi que dans Storj [29].
2.2.4 Ethereum
Ethereum est une blockchain présentée en 2013 par V. Buterin. La principale

nouveauté qu’elle apporte est le fait de permettre d’utiliser des applications de façon
décentralisée. Ces applications sont appelées contrats intelligents, et sont stockées
directement dans la blockchain, donc répliquées sur tous les noeuds du réseau.
Plusieurs papiers (aux couleurs différentes) expliquent les principales caracté-
ristiques de la technologie Ethereum :
— White paper [30] : le premier papier, à vocation plutôt marketing, présente
le travail en amont, en expliquant le contexte et l’intérêt de cette nouvelle
technologie, ainsi que la manière globale dont elle fonctionne.
— Yellow paper [31] : sorti un an plus tard, ce papier est plus précis et complète
le précédent en développant de façon plus technique. Sa lecture est assez
complexe car il utilise beaucoup de notations scientifiques et mathématiques.
— Beige paper [32] : ce papier a pour but de remplacer le précédent, en repre-
nant les mêmes concepts avec une écriture plus littérale, et une organisation
différente, rendant sa lecture plus accessible.
— Mauve paper [33] : sorti en 2016, ce papier présente certaines problématiques
des blockchains, et l’idée de la preuve d’enjeu et de la fragmentation, pour
permettre le passage à l’échelle d’Ethereum.
En plus des applications décentralisées, Ethereum instaure un nouveau concept,
les oncles. Un oncle est un bloc valide, mais non inséré dans la chaîne la plus longue.
Ses transactions ne seront pas prises en compte, cependant il sera stocké au même
titre qu’un bloc de la chaîne principale. Il est appelé oncle tout simplement car il est
au même niveau que le bloc parent du bloc courant. Dans l’exemple à la figure 2.6,
le bloc #103’ sera l’oncle du nouveau bloc #104, dont le parent est le bloc #103.
En incluant les oncles dans les nouveaux blocs ajoutés, la sécurité de la chaîne
Figure 2.6 – Exemple d’ajout d’un nouveau bloc qui aura un parent et un oncle
est renforcée. Chaque bloc valide peut ainsi être ajouté dans la chaîne, et la somme
totale de la preuve effectuée pour la blockchain augmente, puisque le nombre de
blocs augmente. De plus, réaliser le consensus même dans le cas où le bloc n’est pas
ajouté dans la chaîne principale, donne quand même le droit à une rémunération, et
permet donc à des mineurs avec une capacité de minage modeste de quand même
continuer leur travail, contribuant à la décentralisation.
Grâce à cela, sur Ethereum la fréquence entre deux blocs est de 15 secondes
environ, tandis que sur Bitcoin un bloc est créé en moyenne toutes les 10 minutes.
Les transactions sont ainsi plus rapidement validées sur Ethereum.
2.2.4.1 Applications décentralisées
Dans sa publication de 1996 [34], N. Szabo définit les contrats intelligents

comme "[...] un protocole de transaction informatisé qui exécute automatiquement
les termes d’un contrat. Les objectifs généraux de la conception de contrats in-
telligents sont de satisfaire aux conditions contractuelles courantes (telles que les
modalités de paiement, les privilèges, la confidentialité et même l’exécution), de
minimiser les erreurs tant malveillantes qu’accidentelles et de minimiser le besoin
d’intermédiaires fiables.".
Un contrat est donc un accord entre différents protagonistes, écrit sous la forme
de code, et s’exécutant de façon automatique selon des critères précis. Grâce aux
multisignatures, le contrat peut être fait avec un nombre illimité de participants. Il
est stocké directement dans la blockchain, et bénéficie de ses propriétés d’immua-
bilité. Il sera également exécuté par tous les noeuds du réseau. Le contrat peut se
déclencher sous des conditions internes à la blockchain (solde d’un compte, vote,
durée de temps écoulé,...) ou bien externes. Dans ce dernier cas, pour faire la liaison
avec un évènement du monde réel, il est nécessaire de faire appel à un oracle, qui
peut-être vu comme une sorte de tiers de confiance.
2.2. Blockchain 29
Pour écrire ces contrats, plusieurs langages de programmation haut niveau ont
été développés. Ces langages sont Turing complet, comme la plupart des langages de
programmation usuels, ce qui amène un problème important, le problème de l’arrêt.
En effet, dans le cas d’un tel langage, en ayant uniquement le code source et l’entrée
du programme, il est impossible de s’assurer qu’un programme s’arrêtera. Or les
contrats s’exécutant sur toutes les machines du réseau, qui n’ont par définition pas
forcément confiance dans le réseau, il est nécessaire de s’assurer que le programme
s’arrêtera. De plus, il semble assez logique de limiter le nombre de calculs à effectuer
dans les contrats, pour éviter de saturer tous les noeuds avec des calculs trop lourds.
Pour cela, dès le white paper, il a été convenu d’ajouter le concept de gaz,
une somme de jeton à dépenser pour déployer son contrat dans la blockchain, qui
correspond à l’effort nécessaire pour exécuter le code. L’environnement d’exécution
de ces contrat s’appelle l’Ethereum Virtual Machine et est présent dans tous les
clients Ethereum, pour permettre à chaque noeud de faire tourner les contrats et
de les vérifier par eux-mêmes.
2.2.5 Applications
La blockchain est une technologie assez récente, et de nouvelles applications

apparaissent très régulièrement. Celles-ci peuvent être classées en deux grandes ca-
tégories : les applications purement virtuelles, n’impliquant que des données propres
à la blockchain, et celles impliquant des données de la blockchain et des données
externes.
L’application virtuelle historique est financière. Bitcoin a justement été créé

dans ce but, pouvoir effectuer des paiements sans autorité centrale, grâce aux
crypto-monnaies. Il est également techniquement possible d’utiliser la blockchain
pour transférer des actifs, comme des actions ou obligations, qui seraient alors di-
rectement inscrits dans la blockchain. Mais pour que ceci soit valable, le cadre
juridique doit s’adapter.
La blockchain Gnosis permet, quant à elle, de réaliser des sortes de sondage
auprès de la communauté. Il est possible de créer des paris sur des évènements, et
chaque noeud peut répondre. A la fin du temps imparti, les noeuds ayant répondu
comme la majorité reçoivent une récompense financière. Ce système permet ainsi
d’obtenir une opinion assez réaliste sur une question précise, car les utilisateurs ont
tout intérêt à répondre correctement pour espérer obtenir des gains.
Une autre application possible serait le vote en ligne. Chaque électeur pourrait
inscrire dans la blockchain son vote, chiffré ou non, selon la confidentialité voulue,
et un contrat intelligent comptabiliserait les votes pour annoncer automatiquement
les résultats. Plusieurs essais concluants ont été réalisés ces dernières années, comme
par exemple lors d’un vote interne pour le parti "Nous citoyens", sur la blockchain
Ethereum.
Les applications utilisant des données du monde réel sont de plus en

plus nombreuses, notamment pour résoudre les problème de traçabilité. Parmi les
exemples, on peut citer le projet "Act for food" de Carrefour, consistant à propo-
ser la traçabilité de leurs produits. Chaque emballage concerné est muni d’un QR
code, menant à des informations sur le produit, stockées dans une blockchain privée.
Le même principe est appliqué dans certains projets pour la traçabilité des objets
de luxe (oeuvres d’art, vins grands crus,...), des médicaments ou pour les pièces
détachées.
Plusieurs institutions et écoles réfléchissent à utiliser une blockchain pour certi-
fier différents documents, comme les certificats de naissance, les papiers d’identité,
ou encore les diplômes.
La blockchain Solacoin propose l’achat automatique d’énergie solaire entre par-
ticulier, le tout sans éviter de passer par les traditionnels fournisseur d’énergie.
Toutes ces applications sont prometteuses, mais possèdent le même gros pro-
blème : comment garantir et vérifier ce qui se passe hors chaîne, sans utiliser d’in-
termédiaire de confiance ? Bien que des recherches soient menées pour résoudre ce
point, pour le moment aucune solution valable n’a été trouvée.
2.3 Théorie des codes correcteurs
Un code correcteur permet de rajouter de la redondance à un message, afin

de corriger les erreurs qui pourraient apparaître lors de sa transmission. Dans le
chapitre 3 de ce manuscrit, les codes correcteurs sont utilisés dans un contexte de
stockage distribué, où des noeuds de stockage peuvent disparaître. Ils sont égale-
ment employés dans les mécanismes de preuves de récupérabilité, présentés dans la
partie 2.4, et utilisés dans le chapitre 4.
Cette thèse n’a pas pour vocation de définir de nouveau code, mais simplement
d’en utiliser certains déjà existants. C’est pourquoi cette partie ne rentrera pas dans
les détails mathématiques, et se contentera d’expliquer certains types de codes à
haut niveau.
2.3. Théorie des codes correcteurs 31
2.3.1 Théorie de l’information
La théorie des communications spécifie comment transmettre une information

depuis une source d’information jusqu’à un utilisateur, via un canal. Cette informa-
tion peut être diverse, tant qu’elle est représentable numériquement par un alpha-
bet. La transmission d’information est un problème majeur dans toutes les techno-
logies actuelles et notamment les télécommunications. La théorie de l’information
a été formulée pour la première fois par Claude Shannon, en 1948 [35], qui dé-
termina le principe de quantité d’information dans un message, ce qui équivaut à
déterminer son taux de redondance. En réduisant cette redondance, on réduit la
taille que prend le message, et on réduit le temps nécessaire pour le transmettre.
Shannon s’intéressa également à la sécurité des messages, en apportant notamment
des preuves mathématiques de confidentialité. Dans le cas d’un canal soumis à des
perturbations, le message qui transite peut être altéré. Shannon prouva en 1948
que pour chaque canal, on peut déterminer la quantité de redondance minimale
nécessaire pour une transmission sans erreur.
Shannon décompose la transmission d’un message selon trois entités différentes,
qui seront détaillées dans les sous-sections suivantes :
1. l’émetteur
2. le canal
3. le destinataire
2.3.1.1 L’émetteur, ou source
Un émetteur, appelé également source, produit des symboles appartenant à

un alphabet fini, noté S = (s0 , s1 , ..., sn ). Il peut être représenté par une variable
aléatoire X avec un distribution de probabilité P = (p0 , p1 , ..., pn ), où pi représente
la probabilité d’apparition du symbole si .
2.3.1.2 Canal
Le canal est le support permettant de faire transiter l’information de l’émetteur

jusqu’au destinataire. Cette information est représentée par un bloc de k symboles
appartenant à S qui est transformé en un mot de taille n par le code correcteur
d’erreurs. Il est caractérisé par le nombre de possibilités en entrée, soit le nombre
d’éléments dans l’alphabet X = (x0 , x1 , ..., xn ), et le nombre de possibilités en sortie,
soit le nombre d’éléments dans l’alphabet Y, et également par sa loi de transition qui
permet de calculer sa capacite. La capacité du canal est la quantité d’information
Figure 2.7 – Exemple d’un canal binaire symétrique
Figure 2.8 – Exemple d’un canal binaire symétrique à effacement
maximale pouvant transiter sans erreur sur celui-ci dans un temps donné. La loi de
transition, notée P (Y |X), est la probabilité d’obtenir un certain symbole en sortie
de canal, connaissant le symbole d’entrée. Le taux d’erreur est la probabilité qu’un
symbole décodé, en sortie du canal, soit différent du symbole initial, en entrée du
canal.
Plusieurs modélisations de canal existent, selon les caractéristiques qu’il pré-
sente. Un des modèles les plus simples est le canal binaire symétrique, présenté
sur la figure 2.7, dans lequel un bit peut soit être transformé, soit être transmis
correctement.
Un autre modèle courant est le canal binaire symétrique à effacement, présenté à
la figure 2.8, dans lequel un bit peut soit être perdu, soit être transmis correctement.
Dans le contexte de cette thèse, il peut y avoir des effacements, mais également
des erreurs (dues entre autres à de la malveillance). Le canal pourra donc être
représenté par un canal binaire symétrique à erreur et à effacement. Sur le schéma
de la figure 2.9, la probabilité de transmettre correctement l’information est 1−p−q,
la probabilité d’avoir une erreur est p, et la probabilité d’avoir une perte est q.
Dans certains systèmes, les symboles des mots de code sont souvent des octets
et non pas simplement des bits. Dans le cas d’un codage par blocs de taille k, on
découpe le message m en blocs contenant k symboles et on traite les blocs les uns à
la suite des autres. Le schéma du canal reste le même, avec 256 possibilités à gauche
(de 00000000 à 11111111), et 257 à droite (les mêmes octets et en plus la possibilité
Figure 2.9 – Exemple d’un canal symétrique binaire à erreur et à effacement
d’avoir perdu l’information, ε).
2.3.1.3 Le destinataire, ou récepteur
Le destinataire du message récupère la sortie du canal, Y . Son but est de le

décoder, si cela est possible, pour obtenir le message original.
2.3.2 Applications
Dans un contexte de canal avec perturbations, les codes correcteurs servent à

faire de la détection et de la correction d’erreurs.
Dans le cadre du stockage de données, il arrive couramment que certains sup-
ports de stockage puissent être abîmés, comme les CD ou les DVD. En codant
l’information, il est possible de détecter et corriger un certain nombre d’erreurs,
continuant ainsi à rendre possible la lecture du média. Dans le stockage sur disque
dur, le procédé RAID utilise les codes pour créer, à partir des informations stockées
sur plusieurs disques, de la redondance sur un disque supplémentaire (par exemple
un bloc de parité). En cas de perte d’un disque, il est alors possible de reconstruire
l’information.
Dans le domaine des télécommunications, tous les systèmes modernes utilisent
des codes correcteurs d’erreurs. Par exemple, tous les types de transmissions spa-
tiales (satellites, sondes, etc) nécessitent l’utilisation de codes pour résoudre les
problèmes d’altération de données.
2.3.3 Construction de codes à effacement
Le message m est découpé en blocs constitués de k symboles. Le codage consiste

à rajouter de la redondance, en transformant le bloc en un nouveau bloc de taille
n = k + r. La fonction code(n, k) doit être injective, pour pouvoir récupérer le

k
message original. Le rendement R = n représente le taux de symboles source dans
un bloc codé. Le taux de redondance est égal à 1 − R.
Pour avoir une fonction de codage efficace, il faut avir :
— un taux de redondance supérieur à la probabilité d’erreur
— un rendement le plus grand possible
— une complexité de calcul la plus petite possible (codage + décodage)
Nous allons ici présenter trois types de code différents utilisés dans cette thèse,
permettant de réaliser de la correction sur le canal symétrique à effacement.
2.3.3.1 Codes Reed-Solomon
Ce code a été proposé par I. S. Reed et G. Solomon en 1960 [36, 37]. C’est un
code linéaire, noté RS(n, k), avec k symboles originaux et n symboles en sortie,
soit n − k symboles de redondance. Il corrige jusqu’à t symboles et e erreurs avec
2t + e = n − k. Le code est optimal sur le canal à effacement car il décode jusqu’à
la capacité du canal.
Pour construire un code RS(n, k) sur le corps fini Fq , on prend tout d’abord
Qq−1
n = q − 1. Soit α une racine primitive. On a X n − 1 = i=1 (X − αi )
Pour construire un code Reed-Solomon(n,k) avec r = n − k symboles de redon-
dance, on choisit un polynôme générateur de degré r avec des racines consécutives :
Qs+r−1
g(X) = i=s (X − αi )
On peut aussi le caractériser par sa matrice génératrice k × n :

G = αi.j (2.7)
i=0,...,k−1; j=0,...,n−1
2.3.3.2 Codes Fontaines
Les codes fontaines sont une catégorie de codes quasi optimaux, c’est-à-dire
qu’ils nécessitent au moins (1 + ε)k blocs codés pour restaurer un message initial
composé de k blocs (avec ε > 0). L’avantage est que les temps de codage et décodage
sont quasi-linéaires (de l’ordre de k.ln( 1ε ) avec k(1 + ε) blocs codés).
Nous détaillons ici le cas des LT codes et des online codes. Ils permettent d’ex-
pliquer comment fonctionnent des codes fontaines avec et sans précodage, et seront
utilisés plus tard dans le manuscrit.
Codes LT Présenté par M. Luby en 1998 [38, 39], les codes LT sont des codes
fontaines sans précodage.On décrira ces codes dans le contexte pour lequel ils ont
Figure 2.10 – Exemple d’un décodage avec un code LT
été créés, c’est à dire le transfert de fichiers sur un canal à effacement.

Le fichier initial est divisé en n blocs de même taille. Pour créer un bloc de re-
dondance, on choisit un degré d tel que 0 ≤ d ≤ n. A l’aide d’un générateur pseudo-
aléatoire, on sélectionne d symboles source à combiner (XOR sur F2 ) pour créer le
symbole de redondance. L’indice des symboles sources utilisé dans sa construction
sera ajouté au bloc de redondance.
Pour décoder, il convient tout d’abord d’isoler les blocs dont l’indice d = 1. Cela
signifie que ce bloc ne nécessite pas de décodage, puisque qu’il n’est composé que
d’un unique bloc. Puis, les blocs de redondance de degrés d = 2 composés entre
autre d’un de ces blocs décodés sont également isolés, et vont pouvoir être décodés
à leur tour grâce à un XOR. Cette opération va permettre de décoder de nouveaux
blocs sources, et ainsi de suite. Un exemple est présenté dans la figure 2.10.
Codes Raptor et Online Les codes Raptor [40] et les codes Online [41], présen-
tés respectivement par A. Shokrollahi et P. Maymounkov quelques années plus tard,
sont une famille de codes dérivée des codes LT, avec une opération supplémentaire
de précodage.
Figure 2.11 – Exemple d’un codage avec une opération de précodage
La figure 2.11 présente un exemple de codage avec une opération de précodage.

La première étape, le précodage, consiste à créer des blocs auxiliaires en appliquant
une première fonction de codage.
Lors de l’étape de codage, on applique un code LT sur la donnée initiale et les
blocs auxiliaires précédemment générés.
Le principal intérêt est qu’ils possèdent une capacité de correction bien meilleure
que celle des codes LT, en contrepartie d’une très légère augmentation de la com-
plexité.
2.4 Preuve de récupérabilité

Dans cette partie nous abordons le problème de la récupérabilité d’un fichier. Ce
problème peut s’énoncer de la manière suivante : lorsqu’un client stocke un fichier
sur un serveur externe, comment peut-il s’assurer que le fichier est bien stocké dans
son intégralité ?
2.4.1 Contexte
Une solution naïve à ce problème serait de télécharger le fichier dans son inté-
gralité, afin d’en vérifier l’intégrité. Cependant ce processus est long, et doit en plus
être réalisé régulièrement.
Une deuxième solution pourrait être de demander fréquemment au serveur des
morceaux plus ou moins longs de fichier. Le problème dans ce cas est double : tout
d’abord, pour pouvoir vérifier que le morceau de fichier est correct, le système doit
2.4. Preuve de récupérabilité 37
en posséder une copie, et donc en réalité continuer à stocker lui même le fichier en
entier ; de plus, la probabilité de détecter une erreur est directement proportionnelle
à la taille du morceau téléchargé.
Les preuves de récupérabilité (POR) sont des protocoles permettant au client de
s’assurer que le serveur externe stocke bien son fichier, et que celui ci est récupérable.
En d’autres termes, le fichier doit non seulement être toujours stocké par le serveur,
mais ne pas avoir été altéré (pas de modification ni de suppression). Pour cela,
le client va régulièrement envoyer des challenges au serveur, qui aura besoin du
fichier pour les résoudre. La réponse à ces challenges doit induire un coût en bande
passante et en calcul inférieur à celui du téléchargement du fichier entier, et doit
permettre de s’assurer avec une très grande probabilité que le serveur possède bien
le fichier.
Les travaux réalisés sur ces preuves sont assez récents et concentrés, car cette
problématique est devenue importante avec l’avènement du cloud computing et du
stockage à distance, vers les années 2007.
2.4.2 Principaux travaux
2.4.2.1 Shah
L’article [42], présente un système permettant de déléguer la tache d’audit d’un

serveur externe à un tiers, que l’on appellera auditeur. Il est possible de transmettre,
de récupérer et d’auditer la donnée et la clé, en passant par l’auditeur, sans atteinte
à la confidentialité.
Le fichier F est chiffré avec une clé K, puis ce chiffré EK (F ) et la clé correspon-
dante sont envoyés au serveur. A partir de la clé, le serveur va générer une sous-clé,
K 0 . Il rendra public K 0 , ainsi que l’empreinte du fichier chiffré, H(EK (F )). Ces
fonctions sont à sens unique et résistantes aux collisions, on peut donc vérifier ces
valeurs en n’apprenant aucune information sur la donnée initiale.
L’auditeur, quant à lui, télécharge la sous-clé et l’empreinte, puis va précalcu-
ler un certain nombre de challenge à partir de nombres aléatoires notés Ri . Pour
répondre au ième challenge, le serveur a besoin d’être en possession de Ri , de la
clé secrète ainsi que du fichier dans sa totalité. L’auditeur peut ainsi vérifier que le
serveur stocke toujours la donnée entière.
Lorsque l’auditeur a utilisé tous ses challenges pré-calculés, il re-télécharge
EK (F ), et en re-calcule des nouveaux.
2.4.2.2 Ateniese
L’article reprend l’idée de base de [42]. Ses auteurs sont les premiers à proposer
une POR publique grâce à des authentificateurs, des tags homomorphes et à RSA.
Deux schémas différents sont présentés, un privé et un public.
Le fichier F est séparé en blocs auxquels on associe des tags homomorphe, qui
seront stockés sur le serveur. Ils sont générés à partir du message, de la clé privée
et de la clé publique. Ils permettent de vérifier les blocs, même sans les posséder
entièrement, car ils les caractérisent et sont inforgeables.
Le client émet un challenge, en choisissant un nombre unique et différent à
chaque fois. Le serveur envoie une réponse à partir de la clé publique, le fichier, le
challenge, et les tags, que le client peut vérifier avec la clé privée, la clé publique,
le challenge et la réponse.
Les tags de chaque bloc permettent de s’assurer qu’une combinaison linéaire
de blocs est correctement réalisée. Avec ce procédé, la réponse au challenge est
rendue plus légère, mais le temps d’exécution est allongé à cause de la complexité
de l’exponentiation modulaire. A noter que le nombre d’exponentielles modulaires
est constant, donc la complexité des entrées/sorties l’est également : cette méthode
est ainsi applicable pour des gros fichiers.
2.4.2.3 Juels et Kaliski
L’article [43] est l’un des plus anciens à proposer une réelle solution à la preuve
de récupérabilité, en introduisant le vocabulaire correspondant et en définissant
clairement le concept. Leur solution apporte entre autre le fait de s’assurer non
seulement que le fichier est toujours stocké, mais également qu’il sera récupérable
par l’utilisateur.
Le client ajoute des données supplémentaires, appelées sentinelles, dans le fichier
préalablement chiffré qu’il souhaite faire stocker. Les sentinelles sont placées à des
positions stratégiques dans le fichier. De cette façon, modifier une partie du fichier
entraîne une modification d’une sentinelle avec une probabilité très élevée. Comme
le fichier est illisible car chiffré, les sentinelles seront indétectables pour le serveur.
Le client envoie ce fichier modifié et stocke uniquement la clé de déchiffrement
du fichier, ainsi que les fameuses sentinelles. Lorsqu’il souhaite une preuve de récu-
pérabilité, il envoie une demande de donnée à une position précise, correspondant
à une sentinel. Il est possible pour le client de vérifier si la sentinelle demandée est
correcte, puisqu’il les a gardées dans sa mémoire.
Le nombre de sentinelles étant fixe, le nombre de demandes de preuves est limité.
De plus, la donnée est statique, c’est-à-dire que si l’on souhaite la modifier, il faudra
recommencer tout le processus.
Dans leur article "Proofs of retrievability : Theory and implementation" [44], ils
reprennent les travaux "Compact Proofs of Retrievability" [45] de Shacham, expliqué
dans la prochaîne sous-section. Leur proposition permet de réduire les besoins en
stockage tout en augmentant le niveau de sécurité, au détriment d’une légère hausse
en terme de calculs.
2.4.2.4 Shacham et Waters
En 2008, H. Shacham et B. Waters étendent la solution [43], pour la rendre

optimisée quand le serveur répond faux la majorité du temps. Cet article, [45] a
l’avantage d’être complet et détaillé, et de présenter des preuves formelles. Un autre
point important est que ce protocole permet un nombre de challenges illimités, grâce
à l’ajout d’une valeur aléatoire dans chaque nouveau challenge.
La grosse nouveauté est la définition de nouveaux types d’authentificateurs ho-
momorphiques, permettant d’aggréger les preuves pour gagner en efficacité et en
espace mémoire.
L’article est composé de deux propositions :
1. Une version dite privée utilisant des fonctions de chiffrement symétriques
(HMAC), avec un challenge de taille réduite, se positionnant comme la suite
logique de "PORs : Proofs of Retrievability for Large Files" [43].
2. Une version dite publique, utilisant des signatures sur les courbes elliptiques
(BLS - Diffie-Hellman), avec un challenge et une réponse de tailles réduites.
Chapitre 3
Client blockchain basé sur les

codes à effacement
Sommaire
3.1 Introduction et contexte . . . . . . . . . . . . . . . . . . . . . 42
3.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.3 Différents types de clients . . . . . . . . . . . . . . . . . . . . 45
3.1.4 Nouvelles solutions émergeantes . . . . . . . . . . . . . . . . . 46
3.2 Description globale du système . . . . . . . . . . . . . . . . . 47
3.2.1 Noeud LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.2 Accès aux soldes des comptes . . . . . . . . . . . . . . . . . . 48
3.2.3 Interaction avec la blockchain . . . . . . . . . . . . . . . . . . 48
3.3 Protocole des noeuds LS . . . . . . . . . . . . . . . . . . . . . 49
3.3.1 Fragmentation des blocs . . . . . . . . . . . . . . . . . . . . . 50
3.3.2 Coder les blocs . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.3 Décoder les blocs . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Analyse des paramètres . . . . . . . . . . . . . . . . . . . . . . 54
3.4.1 Taille du corps fini . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.2 Complexité de codage . . . . . . . . . . . . . . . . . . . . . . 54
3.4.3 Complexité du décodage . . . . . . . . . . . . . . . . . . . . . 58
3.4.4 Paramètre de fragmentation k . . . . . . . . . . . . . . . . . . 59
3.4.5 Facteur de compression . . . . . . . . . . . . . . . . . . . . . 59
3.5 Décodage en cas de fragments codés erronés malveillants . 61
3.5.1 Code correcteur d’erreurs . . . . . . . . . . . . . . . . . . . . 61
3.6 Avantage des noeuds LS . . . . . . . . . . . . . . . . . . . . . 72
3.6.1 Effort de stockage réduit . . . . . . . . . . . . . . . . . . . . . 72
3.6.2 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.3 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.6.4 Équilibrage de la charge réseau . . . . . . . . . . . . . . . . . 77
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
42 Chapitre 3. Client blockchain basé sur les codes à effacement
3.1 Introduction et contexte

3.1.1 Introduction
La propriété la plus importante des blockchains est probablement la décentrali-

sation, qui évite le recours à une autorité centrale. Dans une blockchain classique,
les noeuds participent au réseau en validant les nouveaux blocs et en stockant la
blockchain entièrement. Ces multiples points de stockage empêchent des noeuds
malveillants de modifier les données pour changer l’historique de la blockchain.
Cependant, depuis quelques années, la popularisation des blockchains entraîne
une importante difficulté à participer activement au système pour un utilisateur
quelconque avec des capacités limitées. Les points bloquants qui sont apparus
peuvent être résumés en trois points :
1. CPU : chaque nouvelle transaction doit être validée et exécutée (dans le cas
d’un contrat intelligent) par le noeud.
2. Capacité de stockage : la taille des blockchains augmente et l’effort de sto-
ckage à effectuer devient conséquent.
3. Charge réseau : la blockchain fonctionnant sur un réseau pair-à-pair, les
noeuds sont sollicités en permanence par d’autres noeuds pour obtenir des
informations. Plus la blockchain est distribuée, plus la charge réseau sera
également distribuée. Cependant, les points 1) et 2) entraînent une diminu-
tion des noeuds possédant la blockchain dans sa totalité, ce qui augmente la
charge réseau des noeuds qui la stockent entièrement.
Dans ces travaux, nous proposons une solution permettant de résoudre en par-
tie les problèmes 2. et 3. En effet, notre solution utilise les codes correcteurs pour
représenter et stocker la blockchain sous une forme codée moins volumineuse. L’ef-
fort de stockage est ainsi moins important, et il est possible de solliciter plus de
noeuds pour se synchroniser au réseau, ce qui diminue la charge réseau supportée
par chacun des noeuds. Cependant, coder et décoder la blockchain entraînent des
opérations supplémentaires, qui ont un coût en terme de CPU. Dans la partie 3.4,
nous montrerons que ces coûts sont acceptables.
3.1.2 Contexte
L’utilisation des blockchains a explosé en 2016, lorsque le grand public a com-

mencé à s’y intéresser. Dès lors, le nombre de transactions quotidiennes a fortement
augmenté, conduisant directement à une augmentation de la taille des principales
blockchains. La figure 3.1 montre l’évolution de la taille de la blockchain Bitcoin,
3.1. Introduction et contexte 43
300
Taille (Go)
200
100
0
2009-01
2015-09
2020-01
Figure 3.1 – Evolution de la taille de la blockchain Bitcoin
Client Geth complet

Client Parity complet
4,000
Client Geth archive
Client Parity archive
Taille (Go)
3,000
2,000
1,000
500
2019-01
2019-06
2020-01
2020-06
Figure 3.2 – Evolution de la taille de la blockchain Ethereum pour un noeud

archive
dont l’augmentation était de l’ordre de la dizaine de Go pour l’année 2014 pour

maintenant osciller autour des 50 Go annuels depuis 2017. Elle a franchi le seuil des
300 Go de stockage nécessaires en septembre 2020.
La blockchain Ethereum subit elle aussi cette augmentation rapide de sa taille,
mais de façon encore plus importante puisque l’espace de stockage actuellement
nécessaire à un noeud complet varie entre 300 et 500 Go selon le client choisi, comme
indiqué sur la figure 3.2. Concernant les noeuds archives (voir sous-section 3.1.3 pour
plus de détails), l’espace de stockage nécessaire est de l’ordre des 5 To.
Ces chiffres permettent de se rendre compte rapidement que le fait de stocker la
blockchain dans sa totalité nécessite un investissement pour l’utilisateur en terme
d’espace de stockage. Il est donc intéressant d’étudier en parallèle l’évolution du
nombre de noeuds dans les blockchains, afin de déterminer si cette taille est un
frein à la distribution massive de la blockchain, ce qui aurait pour conséquence les
problèmes associés présentés dans l’introduction.
L’article [46], publié en 2019, étudie le réseau Bitcoin et notamment le nombre

d’acteurs au sein du réseau, selon différents critères. Dans cet article, un graphique
présente l’évolution du nombre d’adresses IP associées à des noeuds Bitcoin depuis
2016, tout type de clients confondus, ainsi que l’évolution du nombre de noeuds
complets quotidiens. Il est intéressant de noter que la courbe représentant cette
dernière valeur est quasiment constante. Ses auteurs utilisent également le travail
de différents autres articles pour construire un tableau plus précis, présentant leur
évolution sur la période de 2013 à 2018. D’après la figure 3.1, entre 2013 et 2018 la
taille de la chaîne Bitcoin a augmenté d’un ratio de 31.8. En 2013, il y avait 3500
noeuds complets Bitcoin connectés quotidiennement et 8527 en 2018. Le nombre
de noeuds complets a donc quant à lui été multiplié par 2.4 seulement, ce qui reste
peu en comparaison de l’augmentation de la taille de la chaîne.
La conclusion de cet article concorde avec nos observations, en analysant la
différence entre l’évolution de tous les noeuds et celle des noeuds complets : "Nous
observons que le nombre de noeuds Bitcoin (dans le sens d’adresse IP unique) a
augmenté significativement (31.5 x) ces 5 dernières années. Toutefois, le nombre
de noeuds complets a lui augmenté avec un ratio plus faible (2.4 x) que le nombre
total de noeuds. Cela implique que, bien que le nombre d’"utilisateurs" de Bitcoin
ait augmenté de manière significative, la majorité d’entre eux sont des utilisateurs
passifs qui utilisent uniquement des clients légers, probablement un public général
qui s’intéresse à l’aspect financier de Bitcoin.
L’article [47] propose un outil d’analyse du réseau Ethereum, nommé Node-
Finder. Leurs résultats indiquent que le nombre de noeuds complets sur le réseau
Ethereum est de 15454 en avril 2018, soit quasiment le double de Bitcoin. Mais l’ar-
ticle soulève d’autres problèmes propres à ce réseau, comme le fait que les noeuds
soient en majorité très récents (50% et 75% des noeuds Parity et Geth ont moins de
100 jours), et que l’information est surtout concentrée dans quelques pays, puisqu’à
eux seuls les USA et la Chine comportent 56.1% des noeuds complets.
3.1.3 Différents types de clients
Nous présentons dans cette partie les deux types de clients classiques, ainsi que
leurs points positifs et négatifs.
3.1.3.1 Client complet
Un client complet est le type de client que nous avons vu dans la partie état de
l’art, sans le citer explicitement. En effet, c’est le client classique des blockchains, qui
se synchronise au réseau en téléchargeant chaque bloc depuis le bloc genèse, et en
vérifiant toutes les transactions qu’ils contiennent. Ce type de noeud est primordial
car il permet une vraie décentralisation de la blockchain, qui sera donc distribuée
sur plusieurs noeuds. Il permet aussi d’assurer sa disponibilité et sa sécurité.
Dans le cas d’Ethereum, le noeud doit en plus stocker, exécuter et vérifier les
contrats intelligents. Cette blockchain stocke l’état des comptes ainsi que des struc-
tures particulières mises à jour à chaque nouveau bloc traité (par exemple les reçus
de transactions donnant le résumé et le résultat d’exécution d’un contrat). Il existe
à ce jour plusieurs types de noeuds complets [48] :
1. Noeud archive Ethereum : il garde tous les blocs et tous leurs états, c’est
à dire qu’il est possible à tout moment de revenir à un point donné de la
blockchain, sans rien avoir à calculer.
2. Noeud élagué : il stocke tous les blocs mais ne garde que les états les plus
récents.
3. Noeud à synchronisation rapide : en partant du bloc genèse, il télécharge
les blocs, les en-têtes, et vérifie les preuves. Mais concernant les contrats, il
ne les exécute pas mais télécharge simplement les reçus de transactions et
l’état courant le plus récent. Lorsqu’il arrive à un point pivot (bloc courant -
1024 par défaut), il traite les derniers blocs "normalement" (c’est à dire qu’il
repasse en mode noeud complet).
Ces trois types de noeuds complets sont les plus utilisés, mais d’autres similaires
peuvent exister, reprenant en partie ces concepts.
3.1.3.2 Client léger
Comme son nom l’indique, un noeud faisant tourner un client léger aura une
version allégée de la blockchain. Ce noeud ne participera donc pas réellement à la
décentralisation, la distribution et la sécurité de la blockchain. Cependant, il pourra
quand même vérifier certaines transactions, en émettre, ou bien encore consulter les
états des comptes.
Dans le papier initial présentant Bitcoin [20], une description d’un client léger
était déjà présente. Appelé SPV pour Simplified Payment Verification, il prévoyait
de ne stocker que les en-têtes des blocs. Pour vérifier une transaction, le noeud
demande le contenu des blocs correspondants au réseau, et vérifie leur intégrité
grâce aux arbres de Merkle contenus dans l’en-tête. Il ne vérifie donc en général
que les transactions qui le concerne directement. Ce système permet de résoudre
partiellement les problèmes 1) et 2) abordés dans la section 3.1.1.
Sur Ethereum, il existe différents clients légers reprenant le principe consistant
à ne stocker que les en-têtes. Certaines options permettent de ne télécharger que
les dernières en-têtes depuis un point de contrôle (donc un point de confiance),
ou depuis le bloc genèse. Là encore, les données sont vérifiées grâce aux arbres
de Merkle. Il est également possible de garder en plus les derniers blocs dans leur
totalité.
Les noeuds légers sont plus accessibles et plus faciles à mettre en place sur une
machine, car ils sont beaucoup moins coûteux en termes de stockage, de traitement
et de connexion. Cependant, nous y voyons deux gros problèmes :
— Comme ils ne stockent pas les blocs, la disponibilité des blocs diminue. Ils
n’apportent pas d’amélioration de la distribution de la blockchain, ce qui
entraîne un danger pour la blockchain qui repose sur la disponibilité de tous
les blocs (en effet il est primordial de pouvoir remonter jusqu’au bloc de
genèse pour considérer la chaine comme valide).
— Ils ne reconstruisent pas la blockchain entièrement, et demandent ainsi une
certaine confiance dans le réseau et les noeuds complets.
3.1.4 Nouvelles solutions émergeantes
Plusieurs solutions sont actuellement étudiées pour résoudre totalement ou par-

tiellement le problème du passage à l’échelle. Nous présentons ici les deux princi-
pales.
3.2. Description globale du système 47
Le lightning network : est un ensemble de noeuds formant un réseau parallèle

à Bitcoin, dont le but est de réaliser des transferts de jetons plus rapidement, en
évitant d’avoir à inscrire chaque transaction sur la blockchain. Pour cela, un système
de verrou temporaire interdit à un participant de réaliser une double dépense, et
seule la transaction finale (souvent constituée de plusieurs micro-transactions) sera
réellement inscrite sur la chaîne principale.
Le sharding : est une technique directement tirée du big data, où les bases
de données sont divisées en éclats (shards) répartis sur différents serveurs, afin
de distribuer les charges de stockage, de traitement et de réseau. Dans le cas des
blockchains, les noeuds ne traiteront donc plus la chaîne entière, mais uniquement
des portions de celle-ci.
3.2 Description globale du système
Nous proposons dans cette thèse un nouveau type de client de blockchain, appelé
low storage et abrégé en "noeud LS" dans ce manuscrit. Nous présentons ici une vue
haut niveau ainsi que la manière dont ils s’intègrent dans le système actuel.
3.2.1 Noeud LS
Le noeud low storage, est un nouveau type de noeud. Son but est de se placer
entre le noeud complet et le noeud léger, en proposant une alternative pour les
personnes souhaitant participer activement à la décentralisation de la blockchain,
mais sans forcément la stocker dans son intégralité et sans accorder sa confiance à
des tiers.
Les noeuds LS n’ont pas pour ambition de remplacer les noeuds existants. Ils
peuvent au contraire co-exister avec.
Le principe de base est de proposer le stockage de fragments codés uniquement,
au lieu de stocker les blocs dans leur totalité. Pour cela, les blocs initiaux sont
découpés en fragments de taille fixe, qui sont ensuite codés en réalisant des com-
binaisons linéaires de fragments. Ces combinaisons linéaires dépendent du type de
code utilisé, et il est possible d’utiliser au choix l’un des codes présentés dans la
section 2.3.
3.2.2 Accès aux soldes des comptes
Les fragments codés stockés ne sont pas directement exploitables, mais peuvent
être décodés si besoin grâce aux autres noeuds LS, possédant eux-mêmes d’autres
fragments codés. L’économie en terme de stockage se fait ainsi au détriment de
l’accès immédiat à l’information. Il est donc nécessaire de pouvoir consulter les
montants associés à chaque compte d’une autre façon qu’en parcourant les anciens
blocs, pour éviter d’avoir à décoder trop fréquemment.
Dans le cas d’Ethereum, les soldes des comptes sont stockés dans une base de
données mise à jour à chaque nouveau bloc traité. En construisant soi-même cette
base de données depuis le bloc genèse, le noeud n’a pas de confiance particulière à
fournir au réseau. Lorsque le noeud veut valider une nouvelle transaction, il lui suffit
de vérifier que l’émetteur est bien en possession des jetons qu’il souhaite dépenser,
puis de les soustraire au montant du compte et de les ajouter à celui du destinataire
de cette transaction, dans la base de données.
Dans le cas de Bitcoin, le système actuel ne permet pas d’accéder directement
aux soldes des comptes. Cependant il nous semble facile de mettre en places une
base de données des comptes comme dans Ethereum, en traitant chaque nouvelle
transaction afin d’ajouter ou soustraire des jetons aux soldes des comptes concernés.
3.2.3 Interaction avec la blockchain
Ce nouveau type de noeud n’a pas pour ambition de remplacer les noeuds exis-
tants, mais plutôt de les compléter, en proposant une nouvelle alternative. Ce noeud
peut s’implémenter aussi bien dans une blockchain publique qu’une blockchain pri-
vée.
3.2.3.1 Ajout d’un nouveau noeud
Lorsqu’un noeud LS souhaite rejoindre le réseau, il a besoin de télécharger la

blockchain dans son intégralité. Pour cela, il peut le faire à partir d’un ou plu-
sieurs noeuds complets, comme dans le système existant, mais également à partir
d’autres noeuds LS. Pour chaque bloc téléchargé, le client LS va bien entendu vé-
rifier sa validité, exécuter les éventuels contrats, et mettre les états à jour, mais va
en plus générer des fragments codés. Il ne stockera que ces fragments codés, ainsi
que l’empreinte cryptographique du bloc contenu dans l’en-tête, et supprimera le
bloc original.
Comme cette opération ne dépend que d’un seul bloc, elle peut-être réalisée au
fur et à mesure, en parallèle du téléchargement de la blockchain. L’avantage est qu’il
3.3. Protocole des noeuds LS 49
n’y a jamais besoin de stocker la blockchain dans sa totalité, et donc de posséder

l’espace mémoire nécessaire. De plus, il n’y a aucunement besoin d’une quelconque
confiance dans le réseau, puisque le noeud aura vérifié par lui même la totalité de
la chaine.
3.2.3.2 Décodage d’un bloc
Bien que nous considérions que cet évènement reste relativement rare, il peut
arriver qu’un noeud LS ait besoin de restaurer un bloc, par exemple pour vérifier
son contenu. Mais ce décodage peut également avoir lieu lors du téléchargement
initial de la blockchain, quand le noeud se synchronise au réseau pour la première
fois. En effet il peut tout simplement utiliser des noeuds complets, sans besoin de
décoder, ou bien s’appuyer sur des noeuds LS, ou encore associer les deux.
Dans le cas de l’utilisation de noeuds LS, le noeud doit télécharger suffisamment
de fragments codés. Lorsque le nombre de fragments nécessaire est atteint, il procède
à l’opération de décodage. Il se retrouve alors en possession des fragments initiaux,
et n’a plus qu’à les assembler pour obtenir le bloc dans sa totalité.
Le nombre de fragments nécessaires dépend du type de code choisi, ainsi que du
nombre de fragments initiaux.
3.2.3.3 Ajout d’un nouveau bloc dans la blockchain
Lorsqu’un nouveau bloc est créé, le noeud l’ayant produit le transfère à tous ses
voisins, qui vont ensuite eux aussi le transférer, jusqu’à ce que le bloc soit accepté
par tous les membres du réseau, qui vont le vérifier, et l’ajouter à leur copie de la
blockchain.
Pour un noeud LS, ce protocole ne change pas. Le noeud va recevoir le bloc,
rejouer son contenu et le vérifier, puis éventuellement le coder selon sa politique
mise en place.
La seule différence est le fait que le noeud peut télécharger le nouveau bloc
entier, dans le cas où il est directement connecté à un noeud complet, ou bien
de télécharger des fragments codés qui seront ensuite décodés, si il est connecté à
suffisamment de noeuds LS.
3.3 Protocole des noeuds LS

Dans cette section nous présentons les aspects techniques de la solution, no-
tamment le codage des blocs, pour obtenir les fragments codés, et le décodage
permettant de récupérer la donnée initiale.

Pour une meilleure compréhension du système, nous posons dans cette section
l’hypothèse que les fragments codés reçus sont sans erreur. Les erreurs et modifica-
tions malveillantes seront abordées dans la section 3.5.
Afin de simplifier les explications, nous utiliserons des notations propres à ce
manuscrit. Ces notations sont rappelées en début de manuscrit. Nous noterons i, un
identifiant unique permettant de reconnaître un noeud du réseau, et N (i) le noeud
en question. Nous noterons B (j) le j ieme bloc de la blockchain, qui commence au
bloc B (1) .
La taille maximale d’un bloc est notée SB . Enfin, nous définissons deux en-
tiers, k et r, qui correspondent respectivement au nombre de fragments obtenus
en découpant un bloc, et au nombre de fragments codés générés et stockés par un
noeud.
3.3.1 Fragmentation des blocs
(j)
F1
(j)
F2
.. k fragments
..
(j)
Fk
B (j)
Figure 3.3 – Fragmentation d’un bloc
La première étape consiste à fragmenter les blocs. Chaque bloc va être traité
indépendamment des autres. Nous posons l’hypothèse que la taille maximale d’un
bloc est connue, et vaut SB . Le bloc sera découpé en k fragments de même taille,
avec k un paramètre commun à tous les noeuds du réseau. Le uieme fragment du
(j)
bloc B (j) sera noté Fu .
Si le bloc est de taille inférieure à SB , celui-ci va être complété par des 0, afin
d’atteindre la taille SB . Ce procédé permet à la fin d’obtenir k fragments de taille
identique et fixe : SF = SB /k.
La figure 3.3 montre la découpe d’un bloc B (j) en k fragments de même taille.
3.3.2 Coder les blocs
Le principe du codage d’un bloc repose sur le fait d’effectuer des combinaisons
linéaires de ses fragments. Pour cela, le noeud dispose d’une suite de k.r coefficients
(i,j) (i,j)
appartenant au corps fini F2m , notée {α1 , . . . , αk.r }. Le choix de ce corps fini
sera expliqué dans la partie 3.4.1.
(i,j)
Pour construire le fragment codé Fu avec u ∈ [1, r], le noeud va prendre les k
(i,j) (i,j)
coefficients {α(k+1).u , . . . , α(k+1).u } et effectuer la combinaison linéaire suivante :
(i,j) (j) (i,j) (j)

F(i,j)
u = α(k+1).u .F1 + . . . , α(k+1).u .Fk
En réitérant cette opération r fois, le noeud obtiendra ses r fragments codés.

Cette opération dans sa globalité peut-être schématisée comme une multiplication
d’une matrice par un vecteur colonne, comme représenté sur la figure 3.4.
En pratique, comme les éléments de F2m peuvent être associés à des vecteurs de
(j) (j)
m bits, on découpe chaque fragment Fl en vecteurs de m bits. Soit fl,v l’élément
(j)
du corps fini associé au v ième vecteur de longueur m du fragment Fl , alors le v ième
(i,j)
vecteur de longueur m du fragment codé Fu est défini par l’élément du corps fini
(i,j)
fu,v calculé comme cela :
(i,j) (j) (i,j) (j)

f(i,j)
u,v = α(k+1).u .f1,v + . . . , +α(k+1).u .fk,v
L’article [49] présente de façon plus précise comment sont réalisées les combi-
naisons linéaires de paquets de données.
(j)
F1
 (i,j) (i,j) (i,j)

α α2 .. .. αk
 1(i,j) (i,j) (i,j)  (j) (i,j)
α
 k+1 αk+2 .. .. α2k   × F2 F1
 .. .. .. .. ..  .. ..
  = r fragments codés
(i,j)
.. .. .. .. αr.k .. (i,j)
Fr
(j)
Fk
B (j)
Figure 3.4 – Exemple de codage d’un bloc
La façon dont sont déterminés les coefficients dépend du type de code choisi.
Dans notre proposition initiale, nous utilisons des coefficients aléatoires : le noeud
N (i) initialise un générateur pseudo-aléatoire avec une graine, qui est composée de
la concaténation de son identifiant unique i et du numéro du bloc j. Le générateur
(i,j) (i,j)
lui donne la séquence des k.r coefficients {α1 , . . . , αk.r }. L’avantage de cette
solution est qu’il n’est pas nécessaire de stocker les coefficients, puisqu’ils peuvent
être recalculés à tout moment. De plus, le noeud est obligé de re-coder lui même la
blockchain, avec ses propres coefficients, et donc de la vérifier. Cependant, comme
nous le verrons dans la section 3.5, cette solution rencontre des problèmes dans le cas
où des fragments codés erronés circulent sur le réseau. Il est alors possible d’utiliser
des codes correcteurs pour résoudre ce problème. La section 2.3 de l’état de l’art de
la thèse reprend les concepts de base de différents codes pouvant s’appliquer à ce
système. Voici quelques unes des solutions envisageables :
— Code de Reed Solomon : les fragments codés sont des combinaisons linéaires
des fragments originaux, avec des coefficients spécifiques permettant de re-
construire le bloc en présence d’un nombre limité d’erreurs.
— Code LT : chaque fragment codé généré sera une addition de d ≤ k fragments
d’origine sélectionnés aléatoirement. Ce nombre d est appelé degré du bloc
et est choisi selon une fonction de distribution particulière [39], choisie au
niveau du système.
— Code online : le principe est similaire à celui du code Luby transformation,
avec une étape de précodage en plus.
3.3.3 Décoder les blocs
Afin de décoder le bloc B (j) , le noeud N (i) commence par télécharger u fragments
(i ,j) (i ,j)
codés F1 1 , . . . , Fu u depuis différents noeuds du réseau N (i1 ) , . . . , N (iu ) . Il est
possible de télécharger plusieurs fragments codés depuis le même noeud.
Le nombre u de fragments codés à télécharger dépend tout d’abord de r, le
nombre de fragments codés que possède déjà N (i) . Il dépend également du type de
code choisi, selon si il est optimal ou non. En effet, si les fragments codés sont sans
erreurs, avec un code de Reed Solomon, le bloc pourra être décodé dès lors que le
noeud sera en possession de k fragments codés. Dans le cas d’utilisation d’un code
aléatoire ou en utilisant un code fontaine (LT ou online), k + ε fragments codés
seront nécessaires.
Une fois le nombre de fragments codés nécessaires atteint, le noeud doit
connaître les coefficients associés. Avec la solution du générateur pseudo-aléatoire,
le noeud N (i) va lui-même les recalculer. En effet, il connaît les identifiants uniques
de chacun des noeuds, i1 , . . . , iu , ainsi que le numéro du bloc j. Il peut donc initia-
liser correctement le générateur pseudo-aléatoire avec les couples i1 , . . . , iu et j et
ainsi régénérer tous les coefficients α utilisés par les noeuds N (i1 ) , . . . , N (iu ) pour
construire leurs fragments codés.
Avec les autres solutions, des informations supplémentaires doivent être trans-
mises, comme la matrice génératrice ou encore les degrés et la manière dont les
blocs ont été créés.
Le noeud N (i) connaît maintenant les r + u coefficients linéaires utilisés pour

construire les r + u fragments codés à partir du bloc B (j) . Il peut procéder à l’opé-
ration de décodage. Globalement, cette opération consiste à calculer l’inverse de la
matrice de coefficients ayant servis à générer les fragments codés reçus, puis à mul-
tiplier cette matrice par ces mêmes fragments. Une fois cette opération terminée, il
est en possession des k fragments initiaux, et donc du bloc B (j) .
La figure 3.5 présente un exemple de décodage, où le noeud N (4) souhaite re-

trouver le bloc B (j) . Il est en possession d’un fragments codés sur les 5 nécessaires
au décodage. Il en télécharge 1 auprès des noeuds N (1) et N (3) , et 2 auprès du noeud
N (2) . Il récupère ensuite les coefficients linéaires associés, puis procède à l’opération
de décodage pour retrouver le bloc initial.
N (1)
(1,j)
F1
(1,j)
F2
(1,j)
F3
(1,j)
F4
N (2) (1,j)
(2,j) F5
F1
(2,j)
F2
(2,j) N (4)
F3
(4,j)
(4,j)
α1
(4,j)
α2
(4,j)
α3
(4,j)
α4
(4,j)
α5 −1 F1
(2,j) (2,j) (2,j) (2,j) (2,j) (2,j)
α1 α2 α3 α4 α5 F1
× (1,j) = B (j)
(1,j) (1,j) (1,j) (1,j) (1,j)
α1 α2 α3 α4 α5 F1
N (3) (2,j) (2,j) (2,j) (2,j) (2,j) (2,j)
(3,j)
F1
α6 α7 α8 α9 α10 F2
(3,j)
α1
(3,j)
α2
(3,j)
α3
(3,j)
α4
(3,j)
α5 (3,j)
(3,j)
F2 F1
Figure 3.5 – Exemple de décodage d’un bloc

3.4 Analyse des paramètres
3.4.1 Taille du corps fini
Dans la partie 2.3, nous avons expliqué qu’il était nécessaire d’avoir recours à
des structures algébriques particulières lors de l’utilisation de code, afin de s’assurer
entre autre que le décodage est possible. La taille du corps fini utilisé pour effectuer
les combinaisons linéaires doit aussi être attentivement étudiée. Lorsque sa taille est
grande, la probabilité de pouvoir inverser la matrice de codage et donc de pouvoir
décoder augmente, au détriment des complexités de codage et décodage.
L’article [50] nous montre qu’en choisissant des coefficients aléatoires pour la
combinaison linéaire dans F2m , la probabilité de pouvoir récupérer le bloc initial
avec k + ε fragments codés téléchargés est d’environ 1 − 2−m.(ε+1) .
Comme les données sont représentées sous forme binaire, il est classique de
i
prendre des tailles de corps fini q tel que q = 22 , c’est à dire 2, 4, 16, 256, 65536,...
En effet, il est plus évident de représenter les données sur un demi-octet, un octet,
ou deux octets,... Une implémentation efficace et rapide [51] a été développée avec
2m = 256, nous proposons donc de choisir cette valeur par défaut pour l’évaluation
de la complexité et l’implémentation de test.
3.4.2 Complexité de codage
Selon le type de code choisi, il n’est pas nécessaire d’impliquer tous les fragments
originaux dans la construction d’un fragment codé. Nous notons d le degré d’un
fragment codé, c’est à dire le nombre de fragments ayant servis à le créer parmi les
k initiaux. r représente le nombre de fragments codés créés et stockés par un noeud.
Le codage consiste à multiplier une matrice décrivant la composition du fragment
codé (de taille d × r, avec d le degré du bloc, c’est à dire le nombre de fragments le
composant) par les fragments de taille sB /k. Cela fait donc d × r × sB /k opérations.
Dans le cas où les fragments codés sont de degrés k, c’est à dire la combinaison
linéaire de tous les fragments d’origine, la complexité vaut donc r × sB et ne dépend
donc pas de k, mais uniquement de r.
Les figure 3.6 et 3.7 présentent les vitesses de codage et de décodage, pour des
blocs respectivement de taille 1MB et 25kB, pour différentes valeurs de k et de r.
Ces vitesses sont données en bloc par seconde. Pour réaliser ces tests, nous avons
utilisé l’implémentation des codes à effacement ISA-L [51] avec un jeu d’instructions
avx2 sur un processeur Intel i5-6500@3.20GHz, dans le corps fini F28 .
ISA-L propose des fonctions bas niveau (en assembleur) optimisées pour les
3.4. Analyse des paramètres 55
applications de stockage, développées par Intel. À l’origine, cette bibliothèque était

utilisable uniquement sur les processeurs Intel, mais elle a été portée depuis peu sur
ARM. Nous avons choisi de réaliser nos tests avec cette implémentation, car c’est
une des plus efficaces pour le moment. Le codec Reed Solomon utilise le corps F28 .
Les tests ont été réalisés avec les différents programmes accessibles sur ce dépôt
Github [52]. Pour chacune des combinaisons de valeurs, nous procédons à L itéra-
tions pour lisser les résultats. Cependant, cela a pour effet de donner des résultats
avec des vitesses légèrement plus élevées, dûes à la mise en cache.
Les figures 3.8 et 3.9 présentent quant à elles des tests réalisés sur un raspberry
pi 4 modèle 8Go de mémoire RAM, avec un processeur quad-core Cortex-A72 (ARM
v8) 64-bits à 1.5GHz. Ces tests ont également été réalisés avec le codec Reed Solo-
mon d’ISA-L.
Dans le réseau Bitcoin, un nouveau bloc est ajouté toutes les 10 minutes environ.
Comme expliqué au début de cette sous-section, la vitesse de codage ne dépend ici
que de r, puisque nous sommes dans le cas d’un code optimal avec d = k. Les
courbes sont ainsi constantes, avec quelques variations dues entre autres aux temps
d’accès à la mémoire. La figure 3.6 nous apprend qu’elle se situe autour de 10000
blocs par seconde pour générer r = 1 fragments codés et de 450 blocs par seconde
pour r = 50. L’opération de codage des nouveaux blocs n’est donc pas limitant
pour un ordinateur personnel.
Un Raspberry étant moins performant, les vitesses sont plus basses. D’après la
figure 3.8 la vitesse de codage d’un bloc de taille 1Mo est d’environ 1500 blocs par
seconde pour r = 1, et de 330 blocs par seconde pour r = 10. Là encore, bien que
les vitesses soient considérablement réduites, elles restent largement acceptables.
Au moment d’écrire ce chapitre, le 28 juillet 2020, le dernier bloc de Bitcoin
comporte le numéro 641147. Pour coder entièrement la blockchain avec par exemple
un facteur de compression c = k/r = 30/1 = 30, pour un ordinateur il faudrait donc
environ nb_bloc/vitesse_de_codage = 641147/2500 = 64 secondes. Pour garder le
même facteur de compression mais avoir plus de redondance, il est possible de fixer
un k plus élevé, par exemple k = 150, et stocker r = 5 fragments codés. Le temps
nécessaire sera alors de 641147/3050 = 210 secondes.
Pour un Raspberry il faudrait environ nb_bloc/vitesse_de_codage =
641147/1500 = 427 secondes. Avec r = 5, le temps nécessaire sera plus élevé,
641147/650 = 986 secondes, soit environs 16 minutes.
Se synchroniser au réseau Bitcoin, c’est à dire télécharger et vérifier l’intégralité
de la blockchain, nécessite actuellement plusieurs jours. Ces temps additionnels de
codage sont donc très largement acceptables.
Vitesse (Blocs par seconde)
Codage (r = 1) Codage (r = 10) Codage (r = 50) Décodage
104
102
100
20 40 60 80 100 120 140 160 180 200
k
Figure 3.6 – Vitesse de codage et de décodage, sur un PC, avec des blocs de
taille = 1MB
Dans le réseau Ethereum, un nouveau bloc est ajouté toutes les 15 secondes
environ. La figure 3.7 nous apprend que la vitesse de codage est d’environ 240000
blocs par seconde pour générer r = 1 fragments codés et de 8000 blocs par seconde
pour r = 50.
Pour le Raspberry, d’après la figure 3.9 la vitesse de codage est d’environ 110000
blocs par seconde pour r = 1, et de 14000 blocs par seconde pour r = 10.
Là encore les vitesses ne sont pas limitantes.
Le dernier bloc comporte le numéro 10546750 (le 28 juillet 2020) sans compter
les blocs "oncles". Pour coder entièrement la blockchain avec par exemple un facteur
de compression c = k/r = 30/1 = 30, pour un ordinateur il faudrait donc environ
nb_bloc/vitesse_de_codage = 10546750/240000 = 44 secondes. Pour garder le
même facteur de compression mais avoir plus de redondance, il est possible de fixer
un k plus élevé, par exemple k = 150, et stocker r = 5 fragments codés. Le temps
nécessaire sera alors de 10546750/75000 = 140 secondes.
Pour un Raspberry, avec r = 1 il faudrait environ

nb_bloc/vitesse_de_codage = 10546750/110000 = 96 secondes. Avec r = 20, le
temps nécessaire sera plus élevé, 10546750/28000 = 377 secondes.
Comme expliqué pour Bitcoin, la synchronisation totale est une opération

longue. C’est d’autant plus le cas pour Ethereum, car il est nécessaire d’exécu-
ter les contrats intelligents pour vérifier les blocs. Ces temps additionnels de codage
sont donc largement acceptables.

105
103
101
20 40 60 80 100 120 140 160 180 200

k
Figure 3.7 – Vitesse de codage et de décodage, sur un PC, avec des blocs de
taille = 25kB
103
102
101
10 20 30 40 50 60 70 80 90 100
k
Figure 3.8 – Vitesse de codage et de décodage, sur un raspberry 4, avec des blocs
de taille = 1MB
104
102
10 20 30 40 50 60 70 80 90 100
k
Figure 3.9 – Vitesse de codage et de décodage, sur un raspberry 4, avec des blocs
de taille = 25kB
3.4.3 Complexité du décodage
L’opération de décodage consiste tout d’abord à inverser une matrice d × k ×

(1 + ε), puis à la multiplier par les fragments codés de taille sB /k. Dans le cas de
l’utilisation d’un code optimal, le degré des fragments codés est égal à k et seulement
k fragments codés sont nécessaires. La matrice est de taille k × k. L’inversion d’une
telle matrice pseudo-aléatoire a une complexité de l’ordre de O(k 3 ). Le nombre
d’opérations nécessaires est de O(k 3 ) + k 2 × sB /k= O(k 3 ) + k × sB et ne dépend
donc que de k, indépendamment de r. Si la taille des blocs est grande par rapport
à k, alors la multiplication de la matrice par le bloc (k × sB ) est l’opération la plus
coûteuse.
Les courbes représentant les vitesses de décodage (représentées en bleu) sur les
figures 3.6, 3.7, 3.8 et 3.9 sont donc décroissantes, et la vitesse diminue également
quand la taille du bloc est plus élevée.
Pour la blockchain Bitcoin, avec des blocs de 1MB, les tests réalisés sur un le
processeur i5 montrent que pour k = 10, il est possible de décoder 9474 blocs par
seconde, ce qui est du même ordre de grandeur que le codage pour r = 1. A k = 100,
la vitesse a bien diminué, et il est possible de décoder 200 blocs par seconde, une
vitesse proche du codage avec r = 50. Pour décoder entièrement la blockchain,
il faudrait 641147/200 = 3205 secondes soit environ 53 minutes. Pour le cas de
k = 200, cette fois le temps nécessaire sera de 641147/27 = 23746 secondes, soit 6.6
heures.
En utilisant le raspberry, les vitesses seront plus basses. Pour k = 11, la vitesse
de décodage des blocs de taille 1MB atteint 9474 blocs par seconde. Avec k = 50, la
vitesse est de 338 blocs par seconde, soit un temps de décodage total de la blockchain
de 641147/338 = 1897 secondes = 32 minutes. Dans notre dernier test, à k = 99, il
faut 641147/53 = 12097 secondes pour le décodage, soit 3.3 heures.
Dans le cas de la blockchain Ethereum, les tests réalisés sur le processeur i5
indiquent que la vitesse de décodage est de 68027 blocs par seconde pour k = 10, et
de 194 pour k = 100, ce qui donne un temps de décodage de la blockchain entière
d’environ 10546750/194 = 54365 secondes = 15 heures. Pour le cas k = 200, ce
temps augmente pour atteindre 10546750/27 = 390620 secondes = 108 heures.
Les tests ont également été réalisés sur le raspberry, où la vitesse de décodage est
de 27816 blocs par seconde pour k = 11. Avec k = 50, la vitesse est de 601 blocs par
seconde, soit un temps de décodage total de la blockchain de 10546750/601 = 17549
secondes = 4.8 heures. Pour le cas de k = 99, cette fois le temps nécessaire sera de
10546750/56 = 188335 secondes soit environ 52 heures.
Ces temps additionnels sont plus élevés que ceux de codage, et doivent être
pris en compte, car peuvent ne pas être négligeables. En comparaison du temps
total nécessaire pour se synchroniser à la blockchain Bitcoin, mais surtout à celle
d’Ethereum, qui se comptent en jours, ces temps peuvent tout à fait être acceptés.
3.4.4 Paramètre de fragmentation k
Dans la partie 3.3.1, nous avons vu en détails la façon dont la blockchain est co-
dée. Chacun de ses blocs est initialement divisé en k fragments, puis ces fragments
sont ensuite codés de façon à obtenir r fragments codés. Le choix du nombre k est
très important, car fixé au niveau du système et donc commun à tous les noeud du
réseau. Comme présenté dans le tableau 3.1, le choix est à faire selon un compromis.
En augmentant la taille de k, le facteur de compression maximal augmente, et per-
met donc d’être plus paramétrable et personnalisable pour chacun des noeuds. Mais
cet avantage se fait au détriment d’une complexité de décodage qui augmente alors,
ce qui entraîne une difficulté à récupérer un bloc et donc également à télécharger
la blockchain dans sa totalité lorsqu’un nouveau noeud rejoint le réseau pour la
première fois.
Tableau 3.1 – Choix de k
Paramètres k
Complexité de décodage Décroissante
Flexibilité du facteur de compression Croissante
Compression maximale Croissante
Il n’y a donc pas de meilleure valeur universelle pour k.

De plus, si la taille maximale d’un bloc, SB est trop petite et ne permet pas
d’avoir un k élevé, il est envisageable de regrouper les blocs en un paquet de bloc,
avant d’appliquer le processus habituel, à savoir découper ce paquet de blocs en
fragments, qui seront ensuite codés, comme expliqué à la figure 3.10.
3.4.5 Facteur de compression
Le facteur de compression c = k/r indique à quel point la chaîne est compressée

et donc l’effort du stockage du noeud diminué. Ce facteur est propre à chaque noeud.
Dans la partie précédente nous avons donné quelques indications pour choisir k, qui
sera fixé au niveau du système. Pour r, chaque noeud fait son propre choix. Dans
x blocs
..
(j,..,j+x)
f1
(j,..,j+x)
f2
.. k fragments
..
(j,..,j+x)
fk
B (j) B (j+x)
Figure 3.10 – Regroupement de plusieurs blocs avant la fragmentation
le tableau 3.2, nous proposons un récapitulatif des différents impacts de r, et dans

quel sens choisir r pour chacun.
Tableau 3.2 – Choix de r
Paramètres r
Disponibilité de la blockchain %
Probabilité de récupérer le bloc %
Complexité de codage &
Meilleure compression &
Équilibre de la charge réseau %
D’après la définition de c, on remarque directement qu’un grand r entraînera

un petit facteur de compression, et inversement. Si tous les noeuds choisissent un r
élevé, ils stockeront plus de fragments codés. La blockchain sera donc plus facilement
récupérable, et la charge réseau diminuera car il y aura une plus grande possibilité de
choisir k fragments codés dans le réseau. Pour ces mêmes raisons, la blockchain sera
mieux distribuée au niveau du réseau (voir la partie 3.6.2 pour plus d’explications
avec un exemple). En revanche, en choisissant un r bas, le facteur de compression
augmente, puisque l’effort de stockage diminue, et la complexité de codage des
fragments codés diminue également.
Là encore on peut conclure qu’il n’y a pas de valeur parfaite de r, chaque
noeud doit la fixer en fonction de ses caractéristiques. À noter que, comme expliqué
précédemment, la valeur r peut-être fixée indépendamment pour chaque bloc, afin
de paramétrer son effort de stockage plus finement.
Il peut être intéressant par exemple de garder un nombre de fragments codés en
3.5. Décodage en cas de fragments codés erronés malveillants 61
relation avec l’âge du bloc. En effet, un bloc ancien aura plus de chances de contenir
des transactions dont les montants auront déjà été re-dépensées, ou des contrats
intelligents dépréciés. Dans ce cas, le bloc aura certainement moins de raisons d’être
accédés dans sa totalité pour des raisons autres que la synchronisation au système.
Un tel bloc est appelé froid, en opposition à un bloc récent avec un contenu plus
d’actualité et plus demandé, qui sera lui appelé bloc chaud. Ces notions de chaud
et froid sont déterminées en fonction de l’utilisateur et/ou du système.
Un noeud pour également décider de ne garder que des fragments codés de blocs
froids, et les blocs chauds dans leur totalité, pour y accéder plus rapidement.
3.5 Décodage en cas de fragments codés erronés mal-

veillants
Dans cette partie nous nous intéressons à la situation où un acteur malveillant
peut contrôler un ou plusieurs noeuds du réseau, afin de fournir des fragments codés
volontairement erronés.
Pour palier à ce problème, nous proposons deux solutions permettant d’appor-
ter la possibilité de récupérer le bloc voulu même dans le cas où un ou plusieurs
fragments sont incorrects, malveillants ou juste en erreur. Les fragments en ques-
tion pourront être identifiés, tout comme les noeuds associés. Ce besoin de gérer les
fragments malveillants a été formulé à deux reprises, dans les articles [53] et [54].
Pour cela, nous proposons deux solutions :
— La première utilisant les codes correcteurs d’erreurs, rapide à mettre en place
mais plus lente à utiliser.
— La deuxième utilisant des fonctions de hachage homomorphes, plus lente à
mettre en place mais plus rapide à utiliser.
Le choix entre ces deux propositions dépend du système (beaucoup de mal-
veillance, beaucoup de décodage, etc).
3.5.1 Code correcteur d’erreurs
Dans sa première version présentée dans [55], le noeud LS ne fonctionnait qu’avec

des simples combinaisons linéaires. Ce choix permettait un codage rapide de la
donnée, mais ne profitaient pas de toutes les propriétés de détection et correction
d’erreurs.
Dans cette partie nous étudions l’avantage de mettre en place un vrai codage de
la donnée, afin d’en améliorer l’intégrité. Le but des codes correcteurs est en effet de
detecter et corriger les éventuelles erreurs présentes. Nous considérons tout d’abord
le cas d’un code Reed Solomon, puis celui d’un code LT.
3.5.1.1 Reed Solomon
Le code Reed Solomon est un code optimal pour les canaux que nous considé-
rons (effacements et erreurs), ce qui signifie qu’il n’a besoin que d’une redondance
minimal pour une capacité de correction choisie.
En utilisant un tel code, le protocole des noeuds LS ne change pas : le bloc initial
est découpé en k fragments, qui vont être combinés pour obtenir r fragments codés.
Pour décoder il faut toujours être en possession d’au moins k fragments codés.
Soit λ le nombre de fragments codés supplémentaires possédés par le noeud (il
a donc k + λ fragments codés). D’une manière générale, un code Reed Solomon
RS(n,k) peut corriger jusqu’à t erreurs et e effacements si 2t + e ≤ n − k. Dans
k+λ
notre cas, il est ainsi possible de corriger au maximum t erreurs avec t = 2 . Dans
le cas où le décodage n’est pas possible car il y a trop de fragments codés erronés en
comparaison des fragments codés corrects, le noeud contacte d’autres noeuds LS,
pour télécharger plus de fragments codés.
3.5.1.2 Code LT
(j) (i,j)
F1 F1
(j)
F2
.. .. ..
r fragments codés
..
(j) (i,j)
Fk Fr
B (j)
Figure 3.11 – Codage d’un bloc avec un code fontaine
Une autre solution est d’utiliser un code fontaine (LT ou online), qui a l’avan-
tage d’être plus rapide que les codes Reed Solomon. En contrepartie, le nombre
de fragments codés nécessaires pour décoder sera supérieur. Nous expliquons ici le
protocole général avec un code fontaine sans précodage. Le type de code choisi aura
une influence sur le choix du degré d et la façon dont sont sélectionnés les fragments,
et pourra donner place à un précodage dans le cas dun code Raptor.
Fragmentation : Le bloc est encore une fois découpé en k fragments de même

taille.
Codage : Le schéma de codage des codes Fontaine respecte le schéma général

présenté sur la figure 3.4, mais utilise le corps fini binaire et définit les combinaisons
linéaires d’une manière particulière. Pour chaque fragment codé à créer, le noeud
effectue un tirage aléatoire pour choisir une valeur de degré pour le bloc codé à créer,
de façon à ce que 1 ≤ d ≤ k. Puis il sélectionne aléatoirement d fragments parmi k
et effectue un XOR bits à bits de ces d fragments, pour obtenir un fragment codé.
Le processus est répété pour obtenir r fragments codés. Le noeud garde en mémoire
seulement ces fragments codés et l’en-tête, et peut supprimer le bloc associé. Dans la
(i,j) (i,j) (j) (j) (j)
figure 3.11, le premier fragment codé F1 est de degré 3 : F1 = F1 + Fl + Fk
(i,j) (j) (j)
et le dernier fragment codé est de degré 2 : Fr = F2 + Fk
Décodage : Comme nous utilisons ici des codes Fontaine, il est possible de retrou-
ver les fragments initiaux avec une forte probabilité lorsque l’on est en possession de
k + ε fragments codés. Le noeud N (i) contacte d’autres noeuds LS jusqu’à obtenir
suffisamment de fragments codés, puis va procéder à l’opération de décodage. Une
description des algorithmes de décodage de certains codes en présence d’erreurs et
d’effacements est présentée dans la section 2.3.3.2.
Si il n’est pas possible de décoder car le nombre de fragments codés erronés est
trop élevé par rapport aux fragments codés corrects, il convient alors de contacter
plus de noeuds, pour augmenter le ratio précédent et pouvoir décoder.
Dans l’article [54], les auteurs proposent de reprendre le principe des noeuds LS,
présentés dans notre article [55], en utilisant des codes Luby Transform à la place
de combinaisons linéaires aléatoires. La principale différence est qu’ils suggèrent de
travailler sur des groupements de k blocs, plutôt que sur des blocs séparés, et fixent
un r pour l’ensemble du réseau.
3.5.2 Fonctions de hachage homomorphes
3.5.2.1 Principe
Comme expliqué dans la section 2.1.3, les fonctions de hachage homomorphes

vérifient la propriété suivante : h(ca .a + cb .b) = hca (a) × hcb (b), avec a et b des blocs
d’informations, et ca et cb des coefficients quelconques. Cette propriété particulière
permet de pouvoir facilement vérifier des données codées à partir de combinaisons
linéaires. Les utilisateurs peuvent ainsi tout d’abord vérifier que les empreintes de
ces données sont correctes, avant de télécharger les données entières pour pouvoir
les décoder. Ce système est présenté dans notre article [56].
Le bloc B est divisé en k fragments. Chacun de ces fragments est un vecteur
Vi = t × 1 avec i ∈ {1; k}). Les fragments sont eux-même composés de t sous-
fragments, que l’on note fi,j (avec i ∈ {1; t} et j ∈ {1; k}). Il est possible de
le représenter comme dans la figure 3.12. Chaque fragment stocke exactement β
octets d’information du bloc initial B. Le dernier fragment peut-être complété si
besoin, dans le cas où il serait de taille inférieur. Les sous-fragments sont de taille
β/t octets. Chaque sous-fragment correspond à un élément du corps fini. Il faut
noter que l’utilisation de fonctions de hachage homomorphes implique le choix d’un
corps fini de type Zp et non plus polynomial comme dans les sections précédentes.
De façon mathématique, le bloc B est représenté par une matrice t × k.
 
f1,1 f1,2 ... f1,k
 
f f2,2 ... f2,k 
 2,1
(3.1)

 
 ... 
 
ft,1 ft,2 ... ft,k
..
f(1,1) f(1,k)
.. .. ..
.. .. ..
.. .. ..
..
f(m,1) f(m,k)
Figure 3.12 – Décomposition d’un bloc
3.5.2.2 Paramètres du système
Dans l’article [3], la fonction de hachage repose sur l’exponentiation modulaire

avec des grands nombres premiers et demande de fixer certains paramètres de sécu-
rité. Ces paramètres sont rassemblés dans un vecteur G, composé de deux grands
nombres premiers p et q, ainsi qu’un vecteur g = (g1 , ..., gm ) ∈ Zm
q . Le premier
critère est que q doit diviser p − 1. Des tailles typiques pour ces paramètres sont
|p| = 1024 bits et |q| = 257 bits. Le deuxième est que g est un vecteur 1 × t composé
de t nombres aléatoires appartenant à Zp (t étant le nombre de sous-fragments).
Les additions seront effectuées sur Zq , et les multiplications et exponentiations
seront sur Zp .
Les paramètres sont à définir au niveau du système donc communs à tous
les noeuds. Ce choix est très important, car il aura une influence direct sur le
niveau de sécurité mais également sur la complexité à effectuer les opérations. Le
tableau 3.13 récapitule ces différents paramètres.
Nom Description Valeur dans nos tests

p Grand nombre premier |p| = 1024
q Grand nombre premier tel que q|(p − 1) |q| = 257
λp Paramètre de sécurité tel que λp = |p| λp = 1024
λq Paramètre de sécurité tel que λq = |q| λq = 257
k Nombre de fragments pour un bloc Variable
t Nombre de sous-fragments par fragment Variable
β Taille d’un fragment en bit β = taille_f ichier/k
g Vecteur ligne 1 × t d’ordre q dans Zq -
G Paramètres de la fonction de hachage G = (p, q, g)
Figure 3.13 – Paramètres du système
3.5.2.3 Codage
Comme présenté dans les parties précédentes, le codage des blocs peut se faire
de différentes façons : en utilisant des combinaisons linéaires générées pseudo-
aléatoirement, ou en utilisant des codes correcteurs. L’unique différence dans notre
protocole sera le degré des blocs codés, et la nécessité de télécharger ε fragments
codés en plus lors du décodage.
Voici ici le processus détaillé du codage d’un bloc B (j) par un noeud N i , dans
le cas de l’utilisation des fonctions de hachage homomorphes :
1) Découpage du bloc : Le bloc B (j) est découpé en k fragments de taille

(j)
identique, notés Fu avec u = 1, ..., k. Ces fragments sont eux aussi découpés en t
sous-fragments correspondant aux éléments du corps fini, notés fu,v avec u ∈ {1, k}
et v ∈ {1, t}. Si besoin, le dernier fragment peut-être complété pour atteindre la
taille fixée.
2) Empreinte homomorphe du bloc : Pour pouvoir vérifier par la suite

les empreintes homomorphes des fragments codés, il est nécessaire de conser-
ver l’empreinte homomorphe du bloc B (j) . Celle-ci est en réalité l’ensemble
des empreintes homomorphes des fragments qui composent le bloc : h(B (j) ) =
(j) (j) (j)
(h(F1 ), h(F2 ), ..., h(Fk )) avec :
t (j)
Y fu,v
h(Fu(j) ) = gv mod p (3.2)
v=1
3) Génération des fragments codés : Dans cette étape, il s’agit de construire

(i,j)
les r fragments codés Fu , de la même façon que présenté dans la partie 3.3.2,
c’est-à-dire en réalisant des combinaisons linéaires :
(i,j) (j) (i,j) (j)

F(i,j)
u = αk.u .F1 + . . . , α(k+1).u−1 .Fk
Les coefficients α ∈ Zp dépendent du code choisi.
4) Empreintes homomorphes des fragments codés : Une fois en possession

de r fragments codés, il convient de réaliser leurs empreintes homomorphes. Celles-
ci seront transmises aux autres noeuds demandant des fragments codés pour leur
permettre de vérifier l’intégrité du fragment codé. L’empreinte du fragment codé
(i,j) (i,j)
u est notée hu = h(Fu ). Grâce à la propriété d’homomorphie, on a l’équation
suivante, qui nous permettra de les vérifier :
k (i,j)
h(Fv(j) )αk.u+v−1
Y
h(F(i,j)
u )= (3.3)
v=1
5) Stockage : Les différentes opérations pour le codage sont terminées. Le noeud

peut maintenant supprimer le bloc B (j) , et ne conserver que ses r fragments codés
(i,j) (i,j)
F1 , . . . , Fr , et les k + r empreintes homomorphes calculées dans les phases 2)
et 4), correspondant aux fragments initiaux et fragments codés.
3.5.2.4 Décodage
Nous allons maintenant détailler le processus à appliquer lorsqu’un noeud sou-

haite récupérer un bloc à partir de fragments codés stockés par différents noeuds
LS. La figure 3.14 illustre le cas où le noeud N (4) souhaite reconstruire le bloc B (j) .
Pour cela, il a accès à trois autres noeuds LS, N (1) , N (2) et N (3) , pouvant lui fournir
les quatre fragments codés nécessaires au décodage.
1) Téléchargement des empreintes des fragments codés : Comme repré-

senté dans la figure 3.14, le noeud N (4) commence par télécharger k(1+ε) empreintes
(i,j)
homomorphes, notées hz , qui correspondent aux k(1 + ε) fragments codés identi-
fiés sur les autres noeuds LS.
2) Vérification des empreintes homomorphes : Le noeud vérifie que les

empreintes téléchargées sont correctes par rapport au bloc d’origine. Pour cela et
pour chaque fragment codé, il utilise les propriétés homomorphes présentées dans
(i,j)
l’équation 3.3, et recalcule l’empreinte homomorphe du fragment codé avec les αk.u
annoncés ainsi que les empreintes des fragments initiaux. Puis il compare les deux
empreintes, pour vérifier qu’elles sont identiques et donc que l’empreinte est cor-
recte.
3) Téléchargement des fragments codés : Si les empreintes sont valides, alors

(i ,j) (i ,j)
le noeud N (i) r−1
peut télécharger les fragments codés F0 0 , . . . , Fr−1 associés à ces
empreintes.
4) Vérification des fragments codés : Afin de vérifier que les fragments codés
reçus correspondent bien aux empreintes préalablement vérifiées, le noeud va réaliser
leurs empreintes homomorphes, soit le calcul présenté dans l’équation 3.2. Comme
présenté dans [3], cette vérification se fait à la volée, c’est à dire au fur et à mesure
du téléchargement, afin de rendre le processus plus rapide.
5) Décodage du bloc : Une fois les étapes précédentes réalisées, il est possible
de retrouver le bloc initial en décodant les fragments codés. Avec k(1 + ε) fragments
codés corrects, le noeud est en possession de suffisamment d’équations pour pouvoir
procéder à l’opération de décodage, et obtenir les k fragments initiaux composant le
bloc B (j) . Le bloc sera vérifié une dernière fois en utilisant son empreinte d’origine,
conservée lors du codage.
3.5.2.5 Analyses des paramètres
La complexité des opérations utilisées dans cette fonction de vérification du

hachage homomorphe peut être un problème. [3] et [4] ont proposé d’effectuer des
contrôles probabilistes pour réduire le nombre de calculs d’empreintes. Malgré cela,
la complexité effective de cette fonction doit être soigneusement estimée afin de
déterminer clairement les contextes dans lesquels cette solution peut être utilisée.
Les tests suivants on été réalisés sur un ordinateur disposant d’un processeur
Intel Core i5-7300HQ @2.50GHz avec 8GB de RAM. Le paramètre p possède une
N (1) N (2)
(1,j) (1,j) (2,j) (2,j)
F1 h1 F1 h1
N (3) N (4)
(3,j) (3,j) (4,j) (4,j)
F1 h1 F1 h1
(3,j) (3,j)
F2 h2
Figure 3.14 – Système avec empreintes homomorphes
taille de 1024 bits et q de 257. Les tests ont été réalisés 10 fois, et une moyenne a
été ensuite effectuée pour chacun d’entre eux, afin de limiter les aléas.
·10−3
Fichier de taille 1MB, degré k
3 Fichier de taille 32KB, degré k
Fichier de taille 1MB, degré 4
Temps (s)
Fichier de taille 32KB, degré 4

2
0
0 20 40 60 80 100 120 140 160 180 200 220 240 260
k
Figure 3.15 – Temps de génération d’un fragment codé, pour des fichiers de tailles
différentes, et différentes valeurs de k.
Taille du corps fini Les opérations servant à calculer les empreintes homo-
morphes sont réalisées dans un corps fini. Avec les fonctions de hachage que nous
avons choisies, le corps fini est de type Zp avec p un grand nombre premier.
Les conséquences du choix de ce corps sont importantes, tout d’abord d’un
point de vue sécurité. Comme les calculs sont fait modulo p, la taille de l’empreinte
dépend directement de p. Comme nous l’avons vu dans la sous-section 2.1.2, la
probabilité de trouver une collision est liée entre autre de la taille de l’empreinte.
Un p élevé permet donc de réduire la probabilité de collision, et ainsi d’augmenter la
sécurité du système. De plus, les combinaisons linéaires réalisées pour coder les blocs
seront également faites dans le même corps fini. Un grand corps permet d’avoir une
probabilité plus élevée de récupérer le bloc d’origine à partir de fragments codés.
Cependant, un grand corps fini implique automatiquement des calculs plus com-
plexes. La complexité de codage et décodage augmente dans ce cas. La figure 3.15
présente les temps de codage et de décodage de bloc de différentes tailles, pour des
k différents, avec un p de taille 1024 bits, comme suggéré dans [3]. Contrairement à
l’implémentation dans Fm
2 , celle-ci n’est pas optimisée. A titre d’exemple, la vitesse
de codage d’un bloc de taille 1Mb, avec k = 64 pour un degré k est de l’ordre de
527 blocs par secondes pour cette implémentation, contre 9833 blocs par seconde
dans la figures 3.6.
Il s’agit là surtout de montrer que bien que les temps augmentent fortement par
rapport aux courbes présentées dans la section 3.4, ils restent cependant acceptables.
Complexité des fonctions de hachage Comme indiqué dans les articles [3]
et [4], la complexité d’une fonction de hachage (équation 3.2) d’un fragment à t
éléments est de l’ordre de O(t). La figure 3.16 présente le temps de calcul pour
effectuer l’empreinte homomorphe d’un fichier de 1MB et d’un fichier de 32KB,
selon différentes valeurs de k. Elle nous confirme la complexité précédente, car pour
une taille de fichier donnée, quand la valeur de k augmente, le nombre t d’éléments
par fragment diminue, et donc le temps diminue également.
Nous avons vu précédemment que calculer l’empreinte homomorphe du bloc
entier revenait à calculer l’empreinte homomorphe de ses k fragments. La complexité
est de l’ordre de O(k.t) opérations. Il est donc linéaire en fonction de k × t qui est le
nombre d’éléments du corps finis qui le composent. Le temps de calcul de l’empreinte
homomorphe est donc indépendant de k. Il peut être obtenue grâce à la figure 3.16,
en multipliant un temps par la valeur k associée.
Pour vérifier la validité de l’empreinte d’un fragment codé à partir des d em-
preintes de fragments ayant servis à le construire (équation 3.3), la complexité est de
O(t) + O(d). La figure 3.17 présente le temps de calcul de l’empreinte homomorphe
d’un fragment codé, à partir des empreintes homomorphes des fragments initiaux,
pour différentes tailles de fichiers (1 MB et 32 KB), ainsi que pour différents degrés
(d = 4 et d = k). La figure indique que le paramètre t, dépendant directement de la
taille du fichier, n’a pas un gros impact en comparaison du degré du bloc d. En effet,
lorsque le degré est égal à 4, les fragments codés étant composés par 4 combinaisons
linéaires de fragments, le temps de vérification est constant aux alentours de 0.0004
secondes pour les deux tailles de fichiers. Lorsque le degré vaut d = k, c’est-à-dire
que les fragments codés sont des combinaisons linéaires de tous les fragments ini-
tiaux, le temps nécessaire augmente en fonction de k, car le degré augmente. Mais
pour deux tailles de fichiers différentes, il reste du même ordre de grandeur pour un
k donné (pour k = 128 la vérification pour un fragment codé d’un fichier de 1MB
se fait en 0.0145386 seconde, et elle se fait en 0.0143762 seconde pour un fichier de
32KB).
Fichier de taille 1MB

10−1 Fichier de taille 32KB
Temps (s)
10−2
10−3
0 20 40 60 80 100 120 140 160 180 200 220 240 260

k
Figure 3.16 – Temps de calcul d’une empreinte homomorphe pour un fragment
·10−2
3 Fichier de taille 1MB, degré k
Fichier de taille 32kB, degré k
Fichier de taille 1MB, degré 4
Temps (s)
2 Fichier de taille 32kB, degré 4
0
0 20 40 60 80 100 120 140 160 180 200 220 240 260
k
Figure 3.17 – Temps de calcul d’une empreinte homomorphe d’un fragment codé
à partir des empreintes homomorphes des fragments originaux
Facteur de compression Le facteur de compression présenté dans la sous-

section 3.4.5 est modifié par l’ajout du stockage de données supplémentaires né-
cessaires à la vérification. Auparavant, seul les fragments codés, ainsi que quelques
paramètres du système, étaient à conserver. En ajoutant les fonctions de hachage
homomorphe, le noeud stocke toujours les r fragments codés, mais également les k
empreintes homomorphes des fragments d’origine, et les r empreintes homomorphes
des fragments codés. Le nouveau facteur de compression (avec SH la taille de l’em-
preinte homomorphe et SB la taille du bloc) est :
k 4 32 64 128 256
r=1 0.251 0.0355 0.0239 0.0243 0.0369
r=5 - 0.161 0.0870 0.0561 0.0529
Tableau 3.3 – Valeurs de c pour différents k et r, avec sB = 1M B
(k + r) × SH r
c= + (3.4)
SB k
Afin de trouver l’optimum de cette équation, nous pouvons calculer le k per-
mettant d’avoir le meilleur facteur de compression :
s
r × SB
kopt = (3.5)
SH
Le tableau 3.3 présente différentes valeurs de facteur de compression en fonction

de k et r, pour un fichier de 1MB.
Pour un bloc de taille 32KB, le facteur de compression optimal est c = 0.1305
avec k = 16, ce qui ne permet pas d’importantes réductions de l’espace de stockage
nécessaire. Pour espérer l’augmenter, il peut-être intéressant de grouper des blocs
afin d’agir sur des données plus grandes, rendant plus acceptable les empreintes
homomorphes à stocker.
3.5.2.6 Choix des paramètres k et r
Le paramètre k, ainsi que les différents paramètres présentés dans le tableau 3.13
sont à définir au niveau du système, pour tous les utilisateurs, et doivent donc
être mûrement réfléchis. Ils ont une influence directe sur la sécurité du système, la
compression maximale, mais également sur la complexité des opérations. Il s’agit
donc de trouver un compromis au cas par cas, en fonction de la blockchain et de
son utilisation.
Le tableau 3.4 présente le temps nécessaire pour mettre en place le système
homomorphe et l’utiliser pour la vérification, ainsi que les stockages associés, pour
différentes valeurs de k et r. On remarque que le temps de mise en place diminue
quand k augmente, mais augmente quand r augmente. Le temps de vérification
augmente quand k augmente, mais diminue avec r car il y a moins de fragments à
vérifier (puisque l’on considère les r fragments stockés comme valides).
Concernant le facteur de compression, il oscille autour d’un facteur optimal
calculé grâce aux équations 3.4 et 3.5. Mais pour un k fixé, il diminue lorsque r
augmente. Trouver quel k fixer pour le système demande donc une réflexion, et une
Paramètres k=4, r=1 k=64, r=1 k=64, r=5

Génération k empreintes homomorphes 0.914 0.871 0.871
Génération r fragments codés 0.003 0.002 0.009
Génération r empreintes homomorphes 0.229 0.014 0.068
Temps de mise en place 1.146 0.887 0.949
Vérification k − r empreintes homomorphes 0.002 0.427 0.400
Génération k − r empreintes homomorphes 0.686 0.858 0.803
Temps de vérification 0.687 1.285 1.203
Stockage k empreintes homomorphes 512 8192 8192
Stockage r fragments codés 250000 15625 78125
Stockage r empreintes homomorphes 128 128 640
Facteur de compression 0.251 0.024 0.0870
Tableau 3.4 – Analyse de paramètres pour un bloc de taille 1MB (avec tailles en
octets et temps en secondes)
bonne analyse. Il est possible de le choisir pour obtenir un bon équilibre entre temps
de mise en place et temps de vérification, ou bien privilégier l’une des deux étapes
(par exemple si on a une idée du taux moyen de malveillance du système, ou de la
fréquence de décodage de bloc).
3.6 Avantage des noeuds LS
3.6.1 Effort de stockage réduit
Rappelons que c, le facteur de compression des données, est défini par c = k/r.
On rappelle aussi qu’un noeud stockant r fragments codés et souhaitant décoder un
bloc doit télécharger au moins k −r fragments codés supplémentaires. Ainsi, lorsque
le facteur de compression augmente, le nombre de fragments codés à télécharger
pour décoder le bloc concerné augmente également de façon proportionnelle. Le
choix de ces paramètres et les conséquences associées seront discutés plus en détails
dans la partie 3.4.
Lorsque r = k, le facteur de compression vaut c = 1, ce qui signifie que l’effort de
stockage n’est pas réduit, et que la blockchain nécessite toujours autant de place en
mémoire. Dans ce cas, les données peuvent être reconstruites sans téléchargement
supplémentaire, puisque le nombre de fragments codés à télécharger vaut k − r = 0.
Au contraire, lorsque r = 1, le facteur de compression atteint sa valeur maximale c =
k, car notre solution implique que chaque noeud stocke au minimum un fragment
codé.
Un avantage de cette solution est sa flexibilité, permettant à chaque noeud
3.6. Avantage des noeuds LS 73
d’adapter son nombre de fragments codés stockés r, selon sa capacité ou son besoin.
Seul le nombre k est fixé par le réseau. Chaque noeud choisit son r, pour ajuster
son facteur de compression à ses moyens disponibles, et cela indépendamment des
autres noeuds.
Le r peut-être fixé par le noeud de manière globale, pour tous les blocs, mais
peut également être paramétrable plus finement. Une possibilité est d’adapter le
r de chaque bloc en fonction de son importance, en supprimant des fragments
codés lorsque l’importance diminue. Cette notion d’importance est définie par le
noeud, et peut par exemple être liée à l’âge du bloc (un bloc ancien sera considéré
comme moins souvent demandé et consulté), ou selon son lien avec le noeud (un
bloc contenant des transactions liées au noeud sera plus important pour ce dernier).
Le fait de n’avoir qu’à supprimer des fragments codés ne nécessite aucun calcul
supplémentaire.
3.6.2 Disponibilité
Comme présenté dans la partie 3.1.1, un des objectifs de ces travaux est d’amé-
liorer la disponibilité de la blockchain. Pour cela, nous misons sur la plus grande
réplication possible, qu’elle soit totale ou partielle. En proposant de réduire l’effort
de stockage nécessaire à un noeud pour maintenir la blockchain en codant celle-ci,
nous espérons une augmentation importante du nombre de noeuds dans le réseau.
En effet, il nous parait acceptable de partir du principe que n’importe quel noeud
est en capacité de stocker au moins un fragment codé de chaque bloc, pour un
paramètre k bien choisi.
La donnée est stockée de façon codée et partielle, puisque elle est tout d’abord
divisée en plusieurs fragments qui vont ensuite être codés, et que le noeud n’en
gardera que certains. A l’échelle du noeud, notre solution n’apporte donc aucune
amélioration de la disponibilité, au contraire. Cependant à l’échelle du système glo-
bal, tous les blocs sont stockés et répliqués de nombreuses fois. N’importe quel bloc
peut-être reconstruit en combinant n’importe quels k fragments codés. L’impact
d’un noeud injoignable ou quittant le réseau est réduit, car il peut facilement être
compensé en téléchargeant depuis un autre noeud.
De plus, privilégier le nombre total de noeuds plutôt que la capacité de stockage
de chacun de ces noeuds favorise la décentralisation, ce qui va dans le sens de la
philosophie première de la blockchain. L’information étant plus largement répartie,
le risque de prise de contrôle du réseau par une même entité devient moins élevé.
Pour évaluer la disponibilité, nous proposons l’exemple simplifié suivant, en
posant l’hypothèse qu’il n’y a pas d’erreur ou de malveillance dans les données :
Soit n le nombre de noeuds dans le réseau. Chaque noeud peut stocker un nombre
variable de fragments codés pour un bloc donné, nous noterons ri ce nombre pour le
ième noeud. Nous prenons l’hypothèse que ce ri peut être modélisé comme une réali-
sation de variables discrètes indépendantes, suivant une probabilité de distribution
f . Un bloc peut être décodé donc récupéré quand au moins k différents fragments
codés de ce bloc sont disponibles. Nous pouvons définir la probabilité Pc que le bloc
ne soit pas récupérable par :
n−1
! k−1 n−1
! k−1
X X X X n
Pc = p ri < k = p ri = u = f ∗ (u) (3.6)
i=0 u=0 i=0 u=0
n fois
n
z }| {
où f∗ = f ∗ f ∗ · · · ∗ f et ∗ la convolution entre deux distributions de probabi-
lité.
On souhaite comparer avec le système actuel où, de façon simplifiée, il n’existe
que deux types de noeuds : les noeuds complets, stockant la donnée telle quelle
dans sa totalité, et les noeuds légers, ne stockant pas la donnée. Pour comparer
facilement ces deux systèmes, nous supposons qu’ils possèdent la même capacité
totale de stockage global. On suppose donc dans ce cas là que chaque noeud stocke
la blockchain avec une probabilité de 1/c. La probabilité qu’un bloc choisi ne soit
pas stocké par un noeud est donc de 1 − 1/c. Nous sommes dans le cas de variables
indépendantes, car chaque noeud choisi indépendemment des autres si il stocke ou
non le bloc. La probabilité Pr qu’un bloc ne soit stocké par aucun noeud du réseau
est de :
1
Pr = (1 − )n (3.7)
c
Comparons maintenant nos deux systèmes avec un exemple numérique. Prenons
l’hypothèse que dans le cas du système avec fragments codés, le nombre de fragments
codés stockés par chaque noeud suit une distribution géométrique fp (r) = p.(1 −
p)r−1 . Nous avons donc :
n (u − 1)!
fp∗ (u) = .pn .(1 − p)u−n (3.8)
(n − 1)!(u − n)!
Dans notre exemple, nous supposons que k = 100 et que le facteur de compres-
sion moyen du bloc dont nous allons étudier la disponibilité est c = 20, ce qui donne
un stockage moyen de r = 5 fragments codés par noeud. Comme la moyenne d’une
Distribution géométrique
0.2
Probability
0.1
0
0 5 10 15 20 25
Nombre de fragments stockés r
Figure 3.18 – Probabilité pour un noeud de stocker r fragments codés, avec une
distribution géométrique de paramètre p = 0.2
Système avec réplication Système codé

100
Probabilité de perte du bloc
10−1
10−2
10−3
10−4
10−5
0 10 20 30 40 50 60 70 80 90 100
Nombre de noeuds n
Figure 3.19 – Probabilité qu’un bloc choisi soit irrécupérable, en fonction de n,

avec k = 100
distribution géométrique de paramètre p est 1/p, nous avons p = 0.2 comme illustré
à la figure 3.18.
En prenant tous ces paramètres, la figure 3.19 représente la probabilité de ne pas
pouvoir récupérer le bloc car il n’y a pas suffisamment de fragments codés dans le
réseau. Pour le système actuel avec réplication, la courbe est construite à partir de
l’équation 3.7, et pour le système codé avec les équations 3.6 et 3.8. Avec le système
où la blockchain est codée (courbe bleue), la probabilité de pouvoir récupérer le bloc
vaut 1 (avec une précision à 5 chiffres) du moment où il y a au moins 37 noeuds
dans le réseau. Avec le système de réplication, il faut atteindre les 238 noeuds dans
le réseau pour avoir une probabilité équivalente de récupérer le bloc.
3.6.3 Intégrité
Dans cette partie nous allons présenter les arguments montrant que non seule-
ment il n’y a pas de perte d’intégrité avec notre système, mais qu’au contraire
l’intégrité peut être augmentée.
Vérification de la blockchain Comme nous l’avons expliqué précédemment

dans la partie 3.3, chaque noeud doit obligatoirement télécharger la blockchain
dans son intégralité pour ensuite la recoder lui même. A partir de i, son identifiant
unique sur le réseau, il va en déduire une graine pour le générateur aléatoire. La
graine dépend à la fois des identifiants du noeud, mais également de paramètres
propres au bloc. Ce procédé permet d’obtenir des coefficients servant à réaliser les
combinaisons linéaires pour coder les blocs. Lorsque qu’un autre utilisateur sou-
haite récupérer un bloc, il va commencer par télécharger des fragments codés sur
le réseau. Pour les décoder, il a besoin des coefficients propres à chaque fragments
codés. Pour les obtenir, il va utiliser la graine, et donc l’identifiant du noeud i.
Si le noeud n’a pas recodé lui même la blockchain, le décodage ne fonctionne
pas car les combinaisons linéaires ne seront pas bonnes. Chaque noeud est obligé de
recoder la blockchain, et donc de la télécharger et de la vérifier dans son intégralité.
Cela permet de s’assurer que les utilisateurs n’accordent pas leur confiance au réseau
sans eux-mêmes vérifier chaque information, contenue dans chaque bloc. Il y a donc
moins de risques de propagation d’informations erronées involontaires.
Collision d’empreintes L’intégrité de la blockchain est garantie par le fait que

chaque bloc contient l’empreinte du bloc précédent. Si la moindre modification sur-
vient au sein d’un bloc, son empreinte change et ne correspond plus à celle contenue
dans le bloc suivant. Ce principe est un des fondements principaux de la blockchain
et est expliqué plus en détail dans le paragraphe 2.2.1.2. Pour espérer modifier
le contenu d’un bloc, les deux seules solutions sont donc de reconstruire intégrale-
ment la suite de la blockchain, suffisamment vite pour rattraper la chaine principale
et la dépasser (expliqué dans la section 2.2.1.6), ou bien de trouver une collision
dans les empreintes (voir partie 2.1.2 pour plus de détails), afin de faire concorder
l’empreinte dans le bloc suivant avec celle du bloc modifié. Le fait de ne pas pou-
voir reconstruire la blockchain assez rapidement pour écraser la chaine principale
est sécurisé grâce au choix du consensus 2.2.3. Nous allons ici nous intéresser à la
possibilité de trouver une collision.
Un noeud malveillant ne peut altérer qu’un nombre limité de fragments codés
utilisés pour le processus de décodage. Pour espérer modifier un bloc furtivement,
il doit tout d’abord déterminer quels sont les autres fragments codés qui seront
utilisés pour le processus de décodage. Ceci est d’autant plus dur qu’il y a des
noeuds différents proposant des fragments codés sur le réseau.
Ensuite, il doit rechercher une collision telle que le résultat du processus de

décodage des fragments corrects et altérés ait la même empreinte que le bloc initial.
Ce problème est au minimum aussi difficile que le problème classique de collision
de hachage. L’utilisation de codes correcteurs ne réduit donc pas seulement, mais
augmente plutôt l’intégrité du système.
Identification de noeuds malveillants Les codes correcteurs fournissent éga-

lement des solutions pour identifier les noeuds malveillants qui modifient les blocs
et les fragments codés. Les fragments codés altérés ne seront pas compatibles et co-
hérents avec tout ensemble de fragments codés valides de k. Cette propriété permet
à chaque noeud de vérifier la validité des autres noeuds et améliore ainsi la sécurité
globale du système. La section 3.5 de ce chapitre traite en détails les différentes
façon de détecter la malveillance.
En outre, cela permettrait de mettre en place un système de preuves de fraude,
afin de signaler les noeuds malveillants. Il serait alors possible d’éventuellement
mettre en place des sanctions, comme une perte financière ou une liste noire de
noeuds à éviter. Cette possibilité est d’ailleurs étudiée depuis 2017 par le fondateur
d’Ethereum, dans l’article [57].
3.6.4 Équilibrage de la charge réseau
Comme nous espérons que les noeuds LS contribuent à l’augmentation du

nombre de noeuds dans le réseau, nous pensons qu’ils peuvent en conséquence per-
mettre d’améliorer la distribution de la chaine, et donc équilibrer la charge réseau.
Pour illustrer nos propos, nous allons considérer un exemple se basant sur l’état
du réseau de la blockchain Bitcoin en 2018, présenté dans la sous-section 3.1.2
Considérons N bN L = 500000 noeuds légers et N bN C = 8500 noeuds complets.
On pose l’hypothèse que les noeuds légers ont une connexion internet dépassant
légèrement le seuil du "haut débit" pour la France, soit débitN L = 10 Mbps. Dans
cette situation, pour permettre de distribuer efficacement la blockchain en temps
réel aux noeuds légers, les noeuds complets doivent avoir un débit d’au moins :
débitN L × N bN L 10M bps × 500000

débitN C = = = 588M bps
N bN C 8500
.
Maintenant considérons un réseau comportant la même capacité de stockage
dans le réseau, mais en utilisant des noeuds LS. Nous considérons les paramètres
(k = 100, c = 20), c’est à dire que chaque noeud LS va stocker 5 fragments codés.
Pour un même effort de stockage global, le réseau sera composé de N bLS = N bN C ×

c = 8500 × 20 = 170000 noeuds LS.
Dans cette situation, chaque noeud léger pourra initier c = 20 connexions à
débitN L /c = 10M bps/20 = 0.5M bps pour un total de 10000000 connexions sur
l’ensemble du réseau. Toujours dans le but de distribuer en temps réel l’information
à la totalité des noeuds légers, chaque noeud LS devra alors avoir une connexion
d’au moins :
débitN L 10M bps
c × 10000000 20 × 10000000
débitLS = = = 29M bps
N bLS 170000
Cet exemple simple illustre clairement comment les noeuds LS, avec pourtant
une capacité de stockage relativement faible (20 fois moins), peuvent décongestion-
ner le réseau, en ne nécessitant qu’un débit là encore relativement faible. Naturel-
lement, le temps d’établissement de la connexion et d’autres paramètres devraient
être pris en compte pour obtenir une estimation de charge du réseau complète et
plus précise.
3.7 Conclusion
Dans ce chapitre, nous avons présenté les noeuds LS, un nouveau type de noeud
permettant de participer activement à la blockchain et sa décentralisation, en ré-
duisant l’espace nécessaire à son stockage. Pour cela, nous proposons de stocker la
blockchain sous forme codée. Ce procédé permet d’améliorer deux points sur les
trois problèmes actuels du passage à l’échelle, à savoir la trop grande place requise
pour stocker la chaine dans sa totalité, et l’engorgement du réseau dû au nombre
insuffisant de noeuds.
Un avantage de cette solution est qu’il ne nécessite pas de réels changements
sur les blockchains existantes, puisque que le client LS n’a pas pour vocation de
remplacer les clients existants (les clients légers et les clients complets), mais à
simplement les compléter en proposant une alternative.
Nous avons également présenté deux moyens différents de mettre en place un
système pour rendre possible (ou améliorer) le décodage dans le cas où des frag-
ments codés sont erronés ou malveillants. Le premier, utilisant des codes correcteurs,
permet de quand même pouvoir décoder en téléchargeant plus de fragments codés.
Le deuxième utilise des empreintes homomorphes, afin de vérifier la cohérences des
fragments codés avant de les télécharger et de lancer l’opération de décodage.
Notre idée de noeuds LS stockant des fragments codés de blocs semble avoir été
3.7. Conclusion 79
bien reçue par la communauté, puisque plusieurs articles ont cité et repris le travail
réalisé dans cette thèse. Nous présentons ici les principaux :
— SeF : A Secure Fountain Architecture for Slashing Storage Costs in Block-
chains [54] : dans cet article, les auteurs proposent de reprendre le principe
des noeuds LS, en utilisant des codes LT à la place de combinaisons linéaires
aléatoires. Ils suggèrent également de travailler sur des groupements de k
blocs, plutôt que sur des blocs séparés, et fixent un r pour l’ensemble du
réseau.
— Bitcoin Blockchain Compression Algorithm for Blank Node Synchroniza-
tion [58] : les auteurs proposent de remplacer le système permettant de suivre
les transactions d’un bloc à l’autre par une autre structure plus légère, ce
qui entraine une réduction de l’espace de stockage nécessaire pour Bitcoin
de 12.71%.
— Transparent Coded Blockchain [59] : cette proposition consiste à distribuer
l’historique de la blockchain en utilisant une distribution soliton, entraînant
une réduction de l’effort de stockage. Comme les blocs ne sont pas codés,
l’information contenu est directement accessible.
— Patterned Erasure Correcting Codes for Low Storage-Overhead Blockchain
Systems [60] : cet article part du postulat qu’un noeud peut se retrouver
en erreur régulièrement. Ces auteurs présentent un système de codage pre-
nant en compte certains modèles précis d’erreurs, ce qui permet un gain de
stockage plus efficace qu’avec les codes.
— Superlight – A Permissionless, Light-client Only Blockchain with Self-
Contained Proofs and BLS Signatures [61] : les auteurs de ce papier pré-
sentent un nouveau type de noeud, appelé Superlight. Un des systèmes ac-
tuels pour valider une dépense consiste à aller vérifier dans les anciens blocs
qu’il y a bien eu des transactions vers le compte que l’on souhaite débiter,
pour s’assurer que le noeud possède suffisamment de jetons. Afin d’alléger ce
mécanisme, et la proposition est d’utiliser des signatures multiples BLS afin
d’inclure les transactions entrantes dans les transactions sortantes, prouvant
ainsi que les jetons sont réellement possédés.
Chapitre 4
BlockHouse : Blockchain-based
Distributed Storehouse System
Sommaire
4.1 Introduction et contexte . . . . . . . . . . . . . . . . . . . . . 82
4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.3 Clouds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.1.4 Blockchains et systèmes de stockage existants . . . . . . . . . 85
4.2 BlockHouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.1 Général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2 Type de blockchain nécessaire . . . . . . . . . . . . . . . . . . 89
4.2.3 Acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.4 Disponibilité et confidentialité . . . . . . . . . . . . . . . . . . 90
4.2.5 Réputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.6 Intervalle de temps . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Description détaillée du système . . . . . . . . . . . . . . . . 92
4.3.1 Phase d’initialisation . . . . . . . . . . . . . . . . . . . . . . . 92
4.3.2 Phase de stockage et d’audit . . . . . . . . . . . . . . . . . . 95
4.3.3 Fin du contrat . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.4 Auditeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.4.1 Fonctionnement général . . . . . . . . . . . . . . . . . . . . . 98
4.4.2 Probabilité d’avoir une majorité d’auditeurs honnêtes . . . . 99
4.5 Preuve de récupérabilité . . . . . . . . . . . . . . . . . . . . . 102
4.5.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5.2 Critères de sélection d’une PoR dans notre cas . . . . . . . . 103
4.6 L’aléatoire dans les blockchains . . . . . . . . . . . . . . . . . 104
4.6.1 Besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6.2 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.3 Intégration dans BlockHouse . . . . . . . . . . . . . . . . . . 106
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Chapitre 4. BlockHouse : Blockchain-based Distributed Storehouse
82 System
4.1 Introduction et contexte

4.1.1 Introduction
Lors de la première partie de cette thèse, à la suite du travail présenté dans le

chapitre 3, nous avons commencé à réfléchir au problème du consensus. Le consensus
est primordial dans les blockchains puisqu’il permet de désigner la personne en
charge de créer le prochain bloc, et donc de s’assurer que (quasiment) la totalité du
réseau possède la même copie de la chaîne. Actuellement, la plupart des blockchains
utilisent un consensus basé sur la preuve de travail, qui a le désavantage de demander
une importante quantité d’énergie, pour résoudre des challenges vides de sens. Cette
dépense énergétique peut ainsi être considérée comme du gaspillage.
Nous avons considéré différentes méthodes de consensus existantes, afin de voir
si il était possible d’en créer un nouveau, qui se baserait sur le fait de participer
ou non à l’effort de stockage de la blockchain, en lien avec les travaux du chapitre
précédent.
Au fur et à mesure de nos recherches, nous avons étudié les preuves de récu-
pérabilité. En parallèle, nous nous sommes rendus compte que les utilisateurs des
systèmes d’information, particuliers ou professionnels, avaient de plus en plus de
données à stocker, et se tournaient massivement vers le stockage distribué. En re-
gardant en détails les blockchains de stockage existantes, nous avons noté plusieurs
points qui pourraient être améliorés, et avons donc décidé de proposer notre propre
système.
4.1.2 Contexte
Figure 4.1 – EMEA, répartition par Figure 4.2 – APJxC, répartition par
origine origine
Figure 4.3 – EMEA, répartition par Figure 4.4 – APJxC, répartition par
type de stockage type de stockage
Une étude réalisée en janvier 2019 par la International Data Corporation et

Seagate dresse un portrait de l’état du stockage de données dans deux grandes
régions du monde, que sont la zone EMEA (les pays d’Europe, du Moyen-Orient
et de l’Afrique) et la zone APJxC (les pays de l’Asie Pacifique incluant le Japon et
excluant la Chine, de l’Extrême-Orient et du sous-continent indien et de l’Océanie).
Les figures 4.1 et 4.2 nous permettent d’analyser la répartition du nombre de
données relatives aux entreprises et aux particuliers dans ces deux régions. Il est
intéressant de noter que la quantité totale de données suit une augmentation expo-
nentielle. Entre 2018 et 2025, la quantité de données créée par an à l’échelle de la
planète devrait être multipliée par 5.
L’étude nous indique quelques raisons de l’augmentation des données. Concer-
nant les entreprises, celles-ci ont tendance à archiver toutes les données sans for-
cément les trier, ce qui entraîne un stockage important de données obsolètes. De
plus, l’utilisation d’applications et de logiciels métiers devient courant, et permet de
numériser toutes les données des entreprises, qu’il faut là encore stocker. Disposer
d’un grand volume de données sur ses utilisateurs n’est d’ailleurs pas une mauvaise
chose puisqu’avec l’avènement du big data, celles-ci peuvent être très rentables à
analyser, afin de mieux comprendre et cibler ses clients par exemple.
Pour les particuliers, de nouveaux usages et technologies voient le jour, entraî-
nant des données provenant de nouvelles origines. De plus en plus de personnes
mettent en place leur propre système de surveillance, avec des réseaux de caméras
filmant en continu, dont il faut héberger leurs vidéos. L’internet des objets prend
également place dans le quotidien, et bien que les données émises soient souvent
84 System
de petites tailles, le nombre total d’objets connectés est si important qu’il entraîne
une quantité de données générées finalement significative. Enfin, l’usage de la vidéo
en ligne pour les particuliers est l’un des 5 segments de données qui augmentent
le plus, avec notamment la création de vidéos de divertissement, hébergées sur des
plate-formes telles que YouTube ou Twitch.
4.1.3 Clouds
Comme nous venons de le constater, un nombre très important et croissant de

données sont produites chaque année dans le monde. Pour stocker toutes ces don-
nées, les utilisateurs, qu’ils soient particuliers ou professionnels, ont deux solutions
majeures : stocker eux-mêmes en local sur leurs propres machines, ou bien les faire
stocker ailleurs, sur un cloud.
Les figures 4.3 et 4.4 nous indiquent que les clouds publics étaient au départ
plutôt à destination des entreprises et très peu utilisés par les particuliers, mais que
ces derniers se tournent maintenant massivement vers eux. D’après les estimations,
environ 8% des données de la zone EMEA devraient être stockées sur clouds pu-
blics d’ici 2025, contre 10% pour la zone APJxC. L’intérêt pour les entreprises est
d’avoir des solutions tout-en-un, plus facile à mettre en place et ne demandant pas
de maintenance directe. Pour les particuliers, un des attraits est la possibilité de
pouvoir accéder à leurs données à tout moment, depuis n’importe quel appareil.
La majorité des données accessibles sur Internet est stockée par seulement
quelques acteurs qui disposaient de suffisamment de fond pour saisir l’opportu-
nité de construire des centres de stockage au moment de l’émergence des clouds.
Le problème de la centralisation se pose donc, et peut avoir un impact direct sur la
sécurité et la confidentialité des données.
En cas d’attaque réussie sur une de ces entreprises, une quantité non négligeable
de données se retrouverait perdue. De plus, ces entreprises intègrent souvent dans
leur modèle économique le traitement et l’analyse des données à des fins commer-
ciales et marketing. Il est en effet très rare que les données soient automatiquement
chiffrées avant d’être envoyées sur les clouds, et l’utilisateur moyen ne s’en préoccupe
pas forcément.
Au niveau financier, le coût de stockage est décidé par cette majorité d’entre-
prise, et est rarement personnalisable, ce qui signifie que l’utilisateur doit payer un
abonnement même si il n’utilise qu’une petite fraction du stockage disponible.
Pour finir, en cas de désaccord avec un fournisseur de stockage du cloud, le
recours est fastidieux : par exemple, l’obtention d’une compensation en cas de perte
de données est compliquée en raison de la pluralité des canaux juridiques des pays.
En effet, il est nécessaire de contacter le service clientèle pour espérer obtenir une
compensation, ou de se tourner vers la justice. Là encore, en fonction du pays où
les données sont hébergées et du type de contrat, cette voie peut être compliquée.
Certains systèmes de stockage dans le cloud utilisent une preuve de récupérabi-
lité, expliquée dans l’état de l’art à la section 2.4, pour permettre de vérifier que le
cloud stocke réellement l’ensemble des données à tout moment.
Une solution pour améliorer le stockage et la fiabilité des données consiste à
utiliser un code d’effacement, comme dans un contexte multi-cloud. L’idée principale
est d’encoder les données en morceaux codés qui sont répartis sur plusieurs clouds
de stockage [62], afin de permettre la reconstruction du message original même en
cas de perte du serveur.
4.1.4 Blockchains et systèmes de stockage existants
Plutôt que de compter uniquement sur quelques gros acteurs centraux, une idée
est d’ouvrir le marché, et de diversifier les offres. Afin de résoudre le problème
de confiance dans l’entité possédant le cloud, et d’avoir un véritable système de
recours en cas de désaccord, plusieurs groupes de travail ont eu l’idée de proposer
des solutions se basant sur la blockchain. Nous présentons ici les projets les plus
aboutis.
4.1.4.1 Sia coin
Sia coin est une crypto-monnaie et un ensemble d’outils, basés sur la blockchain
Bitcoin et présentés en 2014 dans l’article [63]. Son but est de permettre à des
particuliers de stocker ou faire stocker des données, en échange de jetons. Seul le
contrat de location est stocké sur la blockchain, le reste est en dehors de la chaîne
(offchain). Il n’y a donc pas de réel procédé de vérification de l’honnêteté des ser-
veurs, et le système se base principalement sur un système de réputation, reposant
entre autres sur une somme d’argent bloquée par chaque noeud pour témoigner
de son engagement dans le bon fonctionnement du système. Les données sont sto-
ckées sur différents serveurs, en utilisant les codes à effacement, pour augmenter la
probabilité de pouvoir les récupérer entièrement et correctement à la fin du contrat.
4.1.4.2 Storj
Storj [29] est un système de cloud décentralisé présenté en 2014 qui repose
sur la blockchain Ethereum. Le fichier à stocker est séparé en 20 fragments qui sont
86 System
chiffrés, puis codés avant d’être envoyés sur 40 serveurs différents (choix par défaut).
Des noeuds de confiance, appelés satellites, vont stocker les méta-données associées,
assigner les données à des serveurs, et vérifier que les serveurs stockent toujours les
données en réalisant des audits réguliers. Si certains serveurs ne le font plus, alors
la donnée est répliquée ailleurs pour assurer toujours la même redondance.
4.1.4.3 BlockStore
BlockStore [64] est l’un des premiers à détailler le schéma global du processus
de stockage des fichiers. Il utilise des Space Wallet, une structure spéciale qui suit
l’espace de stockage disponible sur tous les noeuds. Leur choix technique est de
réduire l’impact sur la taille de la chaîne en ne stockant dessus que les échecs de
preuves. Les autres fonctionnalités (audits, transfert, ...) sont effectuées hors de la
chaîne. Cependant, ce système ne résout pas automatiquement les éventuels litiges
lors de la récupération des fichiers à la fin du stockage.
4.1.4.4 FileCoin
FileCoin [65] est un système de fichiers décentralisé pour stocker des fichiers
considérés comme importants sur une blockchain dédiée. Le stockage est divisé en
secteurs de taille fixe et chaque secteur contient une donnée qui sera répliquée sur le
réseau. Les données sont codées d’une façon particulière, permettant de réaliser des
preuves de réplication. Le consensus est fait sur ce stockage. Les mineurs doivent
donc régulièrement envoyer des preuves, appelées "proof of spacetime", certifiant
qu’ils stockent bien leur donnée. La racine de l’arbre de Merkle de la donnée répli-
quée est stockée sur la blockchain. Le mineur doit envoyer une preuve correcte pour
un emplacement aléatoire, le challenge, qui pourra être vérifiée grâce à l’arbre.
Lorsque le client veut récupérer sa donnée, stockée par plusieurs autres noeuds, il
sélectionne un serveur la possédant, le paye, et récupère le fichier. Plus un fichier est
demandé, plus d’autres serveurs le stockeront et plus il sera distribué et décentralisé.
Ce projet sert entre autre à stocker certaines pages de Wikipedia, openstreet-
map, ainsi que le projet Gutenberg (60 000 livres électroniques classiques).
4.1.4.5 Spacemint
Spacemint [66] est un système de blockchain où le minage consiste à réaliser des

preuves de stockage à partir d’un espace de stockage de grande taille, spécifiquement
alloué. Il se base sur le même principe que la preuve de stockage expliquée dans la
4.2. BlockHouse 87
section 2.2.3. Le défaut est que la donnée utilisée pour faire la preuve est statique,
donc la mémoire qui lui est attribuée peut être considérée comme gaspillée.
4.1.4.6 IPFS
L’idée principale de l’InterPlanetary File System est de décentraliser internet,

en stockant du contenu sur de l’espace de stockage appartenant à des particuliers.
Pour cela, les fichiers, et tous les blocs qu’ils contiennent, sont associés à une em-
preinte. IPFS utilise IPNS, un système de dénomination décentralisé permettant de
faire le lien entre les empreintes et les noms (lisibles par un humain) des différents
fichiers présents sur le réseau. Lorsque un fichier est recherché pour être visualisé
ou téléchargé, une requête est envoyée au réseau afin de trouver les noeuds qui le
stockent, grâce à cette empreinte. Chaque noeud du réseau ne stocke que le contenu
qui l’intéresse, plus quelques informations d’indexation qui aident à déterminer où
les fichiers sont stockés. Ce projet ne présente pas directement une blockchain, mais
est un lien direct avec plusieurs blockchains.
4.2 BlockHouse
4.2.1 Général
Comme nous venons de le voir, les utilisateurs ont de plus en plus tendance
à déporter leurs données sur des serveurs externes, comme des clouds. Cependant
le choix est assez limité, et le système repose essentiellement sur la confiance que
l’on porte aux grandes entreprises qui les gèrent. Depuis quelques années, plusieurs
groupes de recherche et entreprises ont commencé à imaginer des blockchains per-
mettant la location d’espaces de stockage libres entre particuliers. Après analyses
de ces dernières, nous avons remarqué plusieurs points problématiques récurrents,
notamment dus aux actions se passant en dehors de la chaîne (et donc non véri-
fiables par tous les noeuds). Nous proposons donc BlockHouse [67], notre solution,
dont la particularité est d’intégrer le maximum d’opérations de gestion du système
dans la chaîne.
BlockHouse est un système basé sur la blockchain, permettant de stocker ou faire
stocker sa donnée de façon sécurisée. La sécurité repose sur le fait que le serveur en
charge du stockage doit régulièrement envoyer une preuve qu’il stocke en effet tou-
jours la donnée, afin d’être payé pour ce service. Cette preuve est effectuée à partir
d’un challenge automatiquement généré, permettant de s’assurer avec une haute
probabilité que la donnée est stockée entièrement sans altération. Ainsi le paiement
88 System
Figure 4.5 – Protocole de BlockHouse

4.2. BlockHouse 89
est automatique, sous réserve que le serveur stocke bien toujours la donnée. Pour
cela, nous utilisons les preuves de récupérabilité, présentées dans la section 2.4. Pour
que celles-ci fonctionnent correctement, le système a besoin de pouvoir générer des
nombres aléatoires. L’aléatoire est un problème loin d’être trivial dans un contexte
décentralisé comme les blockchains, c’est pourquoi nous étudierons les possibilités
dans la partie 4.6.
Comme sur n’importe quelle blockchain, tous les noeuds du réseau vérifient tous
les contrats et transactions, donc toutes les preuves. En cas de litige, la blockchain
sert de juge, afin de déterminer si le client a subit un préjudice, et si il doit être
dédommagé ou non.
Le protocole détaillé de BlockHouse est présenté dans la figure 4.5.
4.2.2 Type de blockchain nécessaire
Notre solution s’adapte à n’importe quelle blockchain sur laquelle peuvent fonc-
tionner des contrats intelligents. Dans cette première version de BlockHouse, avec
l’utilisation d’auditeurs, la blockchain privée est privilégiée car elle permet d’avoir
un certain contrôle sur les acteurs du réseau. La vérification avec les auditeurs est
coûteuse en temps, et il peut être intéressant de l’éviter au maximum. Pour cela,
un moyen rapide est de bannir les utilisateurs fréquemment sources de problèmes.
Dans la blockchain publique ce ban est compliqué, puisque par définition toute per-
sonne disposant d’un ordinateur peut y participer et se créer un nombre illimité
de comptes. Cependant l’utilisation d’un outil de réputation peut palier à ce pro-
blème, car un utilisateur malhonnête aura soit une mauvaise réputation, soit une
réputation nulle due à la création d’un nouveau compte, et sera dans ces deux cas
non prioritaire par rapport à d’autres noeuds avec un meilleur score.
4.2.3 Acteurs du système
Chaque noeud participant activement à la blockchain peut endosser un ou plu-

sieurs des rôles suivants :
Le noeud client : C’est un noeud qui souhaite stocker des données sur un serveur
ayant de la place, contre une somme d’argent.
Le noeud serveur : Son rôle est de stocker la donnée et envoyer des preuves pour
le prouver, puis retourner la donnée à la fin du contrat. C’est un noeud participant
90 System
au système, avec de l’espace de stockage disponible, et étant connecté en permanence

au réseau.
Le noeud auditeur : Les noeuds auditeurs seront abordés en détails dans la

partie 4.4. Ce sont des volontaires, chargés de régler les litiges potentiels en fin de
contrat entre un client et un serveur. Ils sont choisis aléatoirement parmi une liste,
et rémunérés en conséquence.
4.2.4 Disponibilité et confidentialité
Afin d’assurer un certain niveau de disponibilité et de confidentialité des don-

nées, il peut être intéressant de suggérer ou de rendre obligatoire certaines pratiques.
Il est important de ne pas oublier qu’un serveur peut se retrouver hors ligne
à n’importe quel moment, malgré le fait que cela ne soit pas dans son intérêt.
Pour éviter de perdre ainsi sa donnée, le noeud client peut choisir de la stocker sur
plusieurs serveurs, et ainsi augmenter la disponibilité. Pour accéder à sa donnée, il
n’aura qu’à trouver un serveur en ligne et à la télécharger. Cependant il multiplie
également le prix de stockage.
Une autre solution consiste à séparer la donnée en k fragments, puis à les coder
pour générer r > k fragments codés, pour enfin envoyer les r fragments codés sur
différents serveurs. Les codes à effacement étant la base des noeuds LS présentés
dans le chapitre 3 de ce manuscrit, nous ne rentrerons pas plus dans les détails.
Notons toutefois que cette solution offre le meilleur compromis entre la fiabilité et
la quantité de stockage, et donc le coût de stockage.
Concernant la confidentialité des fichiers, il est fortement recommandé à l’utilisa-
teur d’utiliser une fonction de chiffrement pour les rendre illisibles à toute personne
ne disposant pas de la clé.
Que la donnée soit chiffrée, codée, ou non, le protocole même du système ne
change pas. Ces techniques peuvent donc être imposées et automatisées, ou bien
laissées à la préférence de chaque noeud client.
4.2.5 Réputation
Un système de réputation permet aux utilisateurs, qu’ils soient clients ou ser-

veurs, d’avoir un avis sur la fiabilité des autres noeuds. Cette réputation a pour effet
d’inciter les acteurs du réseau à agir de façon honnête, pour avoir une bonne note et
se démarquer des autres, afin d’être choisis. De plus, une bonne réputation permet
4.2. BlockHouse 91
de justifier d’un tarif plus élevé, puisque cela signifie que le noeud est honnête et
qualifié.
La réputation d’un noeud augmentera lorsque ses contrats se termineront sans
problème de sa part, et diminuera dans la situation inverse. Un serveur avec une
mauvaise réputation peut donc signifier qu’il a envoyé un nombre important de
réponses invalides à des challenges, ou encore qu’il lui est arrivé de ne pas retourner
le fichier correctement. Un client avec une mauvaise réputation a quant à lui indiqué
qu’il n’avait pas pu télécharger sa donnée correctement à la fin d’un contrat, alors
que les auditeurs ont en majorité indiqué qu’elle était disponible et intègre. Notons
que toutes ces actions sont stockées sur la blockchain, et donc facilement vérifiables.
Dans le cas où le client souhaite faire stocker sa donnée sur plusieurs serveurs,
il peut être intéressant pour lui de choisir des serveurs avec une bonne réputation
et d’autres avec une réputation plus faible, afin d’obtenir un bon équilibre entre
disponibilité et prix.
Cette réputation peut se faire sur la base d’avis, où le participant d’un contrat
de location d’espace de stockage note le second acteur à l’issue du contrat. Dans ce
cas, le noeud serveur émet un avis sur le noeud client et inversement, en fonction
de si tout s’est bien déroulé ou non.
Il est également possible de mettre en place un système de réputation automa-
tique, utilisant toutes les actions stockées dans la blockchain, et donc consultables
et vérifiables par tous, pour attribuer une note à chaque noeud.
4.2.6 Intervalle de temps
Pour que BlockHouse fonctionne correctement, il est nécessaire de pouvoir me-

surer une durée relativement précise entre plusieurs actions. En effet, pour s’assurer
que le noeud serveur stocke toujours les données, il faut vérifier que la preuve est
bien générée régulièrement, toutes les x secondes, ou tous les x blocs. Le protocole
s’appuie de plus sur des temps d’expiration, pour décider si une requête n’a pas
aboutie, ou pour déclencher l’appel aux auditeurs dans le cas d’un non acquitte-
ment de la part du noeud client.
Le problème ici est que les blockchains sont des systèmes asynchrones et décen-
tralisées, qui ne fonctionnent donc pas en temps réel, et où il n’y a pas d’horloge
commune.
Dans la section de l’algorithme décrivant la validation du bloc du protocole
d’Ethereum [68], il est expliqué qu’un bloc n’est considéré comme valide par un
noeud que si il y a une différence maximale de 900 secondes (15 minutes) entre
92 System
Figure 4.6 – Phase d’initialisation
l’horloge de son système et le timestamp du bloc. Une solution pourrait donc être
d’utiliser l’horloge de chaque noeud, si on demande une précision inférieure à 15
minutes, donc une preuve dont la fréquence est supérieure à 15 minutes.
4.3 Description détaillée du système
Dans cette section nous présentons notre solution, appelée BlockHouse, pour
blockchain-based distributed storehouse system. Elle peut être décomposée en trois
phases : la phase d’initialisation qui met en place le contrat entre un noeud client et
un noeud serveur de stockage, la phase d’audit et de stockage où des vérifications
régulières vont avoir lieu pour s’assurer que tout se déroule comme prévu, puis la
phase de fin de contrat, pendant laquelle aura lieu le paiement final et la remise du
fichier au client.
4.3.1 Phase d’initialisation
La Fig. 4.6 présente un résumé schématique de la phase d’initialisation.

4.3. Description détaillée du système 93
4.3.1.1 Création du contrat
Le noeud client souhaite faire stocker son fichier par un ou plusieurs noeuds
serveurs de stockage. N’importe quel noeud du système peut être client, ou serveur
de stockage, ou bien encore les deux.
Le noeud client créé une transaction spéciale avec un certain nombre d’infor-
mations à propos du stockage qu’il souhaite. Cette transaction est représentée à
l’étape À de la figure 4.6, et comporte entre autre la taille de la donnée à stocker,
la durée de location souhaitée, la fréquence des preuves de récupérabilité, le prix de
la location, ainsi que le séquestre du fichier et le séquestre auditeurs requis. Cette
transaction est envoyée sur le réseau, inclue dans un bloc, et tous les participants
de la blockchain peuvent la consulter et éventuellement y répondre.
Comme indiqué dans la section 4.2.5, nous considérons qu’un système de ré-
putation est mis en place, où chaque noeud est noté selon différents critères. Le
noeud peut avoir une note en tant que client, qui dépendra par exemple du nombre
de contrats s’étant déroulés correctement et au contraire de ceux où il y a eu des
litiges, et une note en tant que serveur, qui pourra dépendre de la proportion de
preuves de récupérabilité correctes par rapport aux incorrectes. On peut imaginer
qu’un serveur avec une bonne réputation aura tendance à demander des prix plus
élevés qu’un serveur avec une réputation plus faible. Le client peut avoir un moyen
efficace de choisir un serveur, en fonction de l’importance de sa donnée et de son
budget.
Quand un ou plusieurs noeuds sont intéressés par la demande du client, et
possèdent tous les critères demandés, ils peuvent faire une transaction en retour
pour solliciter un accord. Lorsque cette requête est envoyée, dans l’étape Á de la
figure 4.6, le serveur bloque une somme de monnaie correspondant aux séquestres
demandés dans À. La nature et le but de ces séquestres seront expliqués en dé-
tails dans la partie 4.3.1.2. Ce blocage de fond permet entre autre d’éviter que les
serveurs ne répondent à toutes les demandes qui transitent sur le réseau, et soient
éventuellement acceptés par plusieurs clients sans qu’ils ne possèdent suffisamment
de monnaie et d’espace de stockage pour réaliser les différents contrats.
Dans l’étape suivante Â, le client choisit un ou plusieurs serveurs, selon ses
propres critères comme par exemple leur réputation. Pour chaque serveur choisi,
le client effectue une transaction indiquant l’identifiant du serveur, et bloquant sur
un contrat intelligent la somme correspondant au paiement total de la location et
au séquestre auditeur. Les serveurs candidats pourront ainsi découvrir si ils ont été
choisis ou non en consultant ces transactions.
94 System
Enfin, dans l’étape Ã, le client transfère aux serveurs le fichier à stocker en

dehors de la chaîne, puis génère et stocke sur la chaîne en Ä des méta-données qui
seront utilisées pour les preuves de récupérabilité (voir section 4.5 pour plus de
détails). Dans ces méta-données figure entre autres l’empreinte du fichier envoyé.
Les noeuds serveurs génèrent et stockent sur la blockchain leurs premières
preuves de récupérabilité lors de la dernière étape, la Å. En cas de succès de la
preuve, la phase d’initialisation est correctement terminée, et chaque couple client/
serveur passe ensuite à la phase de stockage et d’audit. En cas d’échec, il est possible
de paramétrer le système pour que le serveur ait le droit à une ou plusieurs autres
tentatives. Une fois le nombre maximal d’échecs atteint, la phase d’initialisation se
termine de façon incorrecte, et chaque partie récupère intégralement ses fonds. En
effet, à ce moment précis, il est impossible de déterminer si le serveur n’a pas réussi
à effectuer une preuve correcte par sa faute ou par celle du client (qui aurait par
exemple fourni des méta-données erronées).
4.3.1.2 Séquestre
Nous venons de voir que les deux parties devaient mettre en caution un cer-
tain nombre de jetons dans des contrats intelligents, lors des étapes Á et Â. Ces
séquestres ont pour but de s’assurer que les deux protagonistes vont être honnêtes
durant toute la durée du contrat qui les lie. Il y a deux types de séquestre, avec
chacun un intérêt propre. Le noeud serveur doit bloquer les deux séquestres, tandis
que le noeud client ne bloque que le second.
1. Le premier séquestre est celui du fichier. Il est versé au noeud client en

compensation si le noeud serveur n’est pas capable de lui rendre le fichier
stocké, par exemple dans le cas d’une perte.
2. Le deuxième séquestre est le séquestre auditeur. Il est utilisé dans le cas
d’un conflit à la fin du contrat. En effet, si à la fin du contrat le client
déclare ne pas pouvoir récupérer son fichier, il n’est alors pas possible dans
l’état des choses de s’assurer que tel est bien le cas, car le fichier est stocké
en dehors de la blockchain. Dans cette situation, le système va faire appel
à d’autres noeuds, appelés auditeurs, qui iront eux-mêmes télécharger le
fichier et vérifier son intégrité grâce à son empreinte stockée lors de l’étape
Ä. Comme les auditeurs fournissent un effort supplémentaire (le fichier peut
être lourd et nécessiter du temps de téléchargement, un fort débit et de
l’espace de stockage), ils seront rémunérés en conséquence. La section 4.4
présentera en détails le fonctionnement des auditeurs.
4.3.2 Phase de stockage et d’audit
La figure 4.7 présente la seconde étape, celle du stockage et de l’audit. Cette

étape intervient une fois que la première preuve de récupérabilité a été envoyée et
validée. A partir de ce moment, on considère que le noeud serveur de stockage est
bien en possession du fichier, et donc que le noeud client peut éventuellement le
supprimer de son propre disque.
Le principe est de vérifier régulièrement que le fichier est toujours stocké, et
d’effectuer les paiements en conséquence. L’étape de stockage et d’audit est ainsi
répétée fréquemment.
Cette phase, réitérée de nombreuses fois, peut se décomposer en deux étapes
distinctes. La première, À sur la figure 4.7, est la construction et l’envoi de la
preuve par le serveur. Pour cela, nous allons utiliser les preuves de récupérabilité,
présentées en détails dans la section 2.4. Le principe est d’envoyer au serveur un
challenge généré aléatoirement, qui aura besoin de posséder le fichier initial dans sa
globalité pour pouvoir y répondre correctement. On peut ainsi être assuré avec une
probabilité importante que le serveur stocke toujours la donnée, et qu’elle n’a pas été
altérée. Nous proposons d’adapter légèrement le protocole, pour que le challenge soit
déduit automatiquement de la blockchain, et non pas généré et envoyé par un noeud.
L’avantage est tout d’abord de limiter le stockage d’éléments supplémentaires sur
la blockchain, puisqu’elle sera ensuite répliquée sur tous les noeuds du réseau. Ce
léger gain de place pour une preuve permet une réelle économie à l’échelle de tous
les noeuds et de toutes les preuves. De plus, générer automatiquement le challenge
permet de s’affranchir de la nécessité d’une action de la part du client, qui peut
parfois être hors ligne.
La génération d’aléatoire dans les blockchains est loin d’être un problème trivial
dans le contexte des blockchains, et sera abordée dans la section 4.6.
On pose donc l’hypothèse que le noeud serveur récupère un nombre aléatoire à
partir de la blockchain à un instant t prédéfini et en déduit un challenge. Il construit
sa preuve, puis l’envoie dans une transaction qui sera ensuite incluse dans un bloc,
et ainsi distribuée à tous les noeuds du réseau.
Dans la phase Á, les noeuds de la blockchain vérifient tous indépendamment
la preuve contenue dans le nouveau bloc. A l’instant t, ils prennent connaissance
du challenge aléatoire, puis vérifient que la preuve envoyée est correcte, grâce aux
méta-données de la phase Ä de l’étape d’initialisation, figure 4.6. Cette validation
débloque un paiement du noeud client à destination du noeud serveur. Toute cette
étape est faite automatiquement grâce à des contrats intelligents, vérifiant à la fois
96 System
Figure 4.7 – Phase d’audit
que la preuve est correcte, mais également qu’elle a bien été demandée, en calculant
le temps écoulé depuis la dernière preuve et en le comparant à la fréquence des
preuves définie dans le contrat.
En cas de preuve incorrecte, le contrat se termine de façon anticipée, par la
faute du serveur. Les conséquences sont expliquées dans la partie suivante 4.3.3.
Lorsque le contrat se termine, avec la validation des dernières preuves, le système
passe à l’étape 3.
4.3.3 Fin du contrat
La figure 4.8 présente la dernière étape de BlockHouse, l’étape de fin de contrat,

dans le cas où aucun problème n’est rencontré.
Arrivant à la fin du contrat, le client doit tout d’abord télécharger son fichier
si besoin (À). Pendant ce temps, les dernières preuves et vérifications continuent,
jusqu’à arriver à la dernière Á. Lorsque le fichier est téléchargé entièrement, et
qu’il est correct, le client envoie une transaction spéciale sur la blockchain, pour
l’indiquer aux autres noeuds, en Â.
Tout s’étant déroulé correctement, les séquestres auditeur sont rendus dans leur
totalité aux deux parties, et le séquestre fichier est rendu au noeud serveur, comme
indiqué en Ã. Pour finir, le serveur peut supprimer le fichier à la phase finale Ä,
puisque le client lui a confirmé qu’il l’avait bien récupéré en Â. Le contrat se termine
Figure 4.8 – Phase finale
ici.
Nous venons ici d’expliquer le cas le plus simple, où aucun problème n’a été
rencontré. Nous allons maintenant développer différents autres cas de terminaison :
Interruption anticipée par le client : Dans le cas où le client souhaite ter-

miner le contrat plus tôt, quelqu’en soit la raison, chaque partie récupère son/ses
séquestre(s). Cependant, la totalité des fonds bloqués par le contrat intelligent pour
le paiement des preuves est transféré au serveur.
Interruption anticipée par le serveur : Dans le cas où le serveur décide de

terminer le contrat plus tôt, le client récupère son séquestre, le restant de ses jetons
pour le paiement des preuves, et le séquestre du fichier du serveur, en dédomma-
gement pour l’éventuelle perte de ses données. Le serveur quand à lui ne récupère
donc que son séquestre auditeur.
Preuve incorrecte : Si le noeud serveur génère "trop" de preuves incorrectes,

le contrat se termine de manière anticipée. Le terme "trop" ici dépend de la façon
dont est paramétré le système, qui peut avoir une tolérance nulle, et donc punir dès
la première preuve incorrecte, ou bien autoriser un nombre supérieur de preuves
incorrectes. Comme pour une interruption anticipée de la part du serveur, celui-ci
récupère uniquement son séquestre auditeur. Son séquestre fichier est versé au client
pour le dédommager, et celui-ci récupère également son propre séquestre auditeur,
ainsi que les jetons restants pour le paiement des preuves.
98 System
Problème de téléchargement du fichier : Lorsqu’il y a un problème durant

la phase À de téléchargement de la donnée, savoir qui est en tort est relativement
complexe. En effet, rien n’empêche le client de ne pas envoyer la transaction Â de
téléchargement de fichier correct, bien qu’il l’ait réellement téléchargé avec succès.
Dans ce cas, en l’état actuel des choses, il est impossible pour le reste du réseau
de savoir si le fichier a bel et bien été téléchargé ou non, puisque cette action est
effectuée en dehors de la chaîne.
D’un coté, le client peut mentir pour récupérer à la fois le fichier et le séquestre
fichier du serveur. Mais le serveur peut aussi mentir, soit parce qu’il a effectivement
perdu le fichier depuis la dernière preuve, ou bien pour diverses raisons, comme par
exemple pour faire ensuite du chantage au client. Pour résoudre ce dilemme, une
solution est de faire appel à plusieurs autres noeuds du réseau, qui sont chargés de
vérifier qui du serveur et du client est honnête. Le rôle des auditeurs sera développé
dans la section 4.4.
4.4 Auditeurs
Comme le téléchargement du fichier stocké se fait en dehors de la blockchain, en

cas de désaccord sur la fin du contrat il n’est pas possible pour les autres membres
du réseau de savoir qui est en tort, et à qui il faut verser les différents séquestres.
Nous présentons dans cette section le rôle des auditeurs, chargés de résoudre ce
conflit.
4.4.1 Fonctionnement général
Dans le cas d’un désaccord, un des deux protagonistes est forcément malhonnête.
Afin de déterminer si c’est le client qui ment (et donc que le fichier est disponible et
correct) ou si c’est le serveur (et donc que le fichier est indisponible ou incorrect),
un certain nombre de noeuds vont être choisis pour jouer le rôle d’auditeur.
L’auditeur est chargé de télécharger la donnée, et de vérifier son intégrité, en
utilisant pour cela l’empreinte initialement stockée dans la blockchain lors de la
phase Ä de l’étape d’initialisation. Il doit ensuite rendre une réponse sous la forme
d’une transaction, pour annoncer qui est en tort. Cette transaction indique soit que
le fichier n’est pas disponible, soit au contraire qu’il l’est. Dans ce cas, l’auditeur
réalise une preuve de récupérabilité pour le prouver.
Lorsque suffisamment d’auditeurs ont rendu leurs réponses, un contrat intelli-
gent analyse les réponses et détermine la marche à suivre en fonction de la majorité
4.4. Auditeurs 99
des réponses.
Le travail d’auditeur demande de mettre à disposition du système des ressources,
puisqu’il faudra potentiellement télécharger un volume de données important, et
ainsi avoir l’espace libre disponible et une connexion internet suffisants. De plus,
cela peut prendre un certain temps. Les auditeurs sont donc des noeuds volontaires,
s’inscrivant sur une liste. Il peuvent être choisis de façon totalement aléatoire, ou
alors choisi avec un aléa pondéré par la réputation de l’auditeur à répondre correc-
tement ou non.
Pour encourager des noeuds à faire parti des auditeurs, et à agir de façon hon-
nête, un système de rémunération est mis en place pour les auditeurs répondant
correctement. Répondre correctement signifie ici que la réponse choisie est la même
que la majorité des noeuds. Cette récompense est une partie du séquestre auditeur
de l’entité en tort.
Les figures 4.9 et 4.10 présentent les deux situations possibles en cas de désac-
cord. Dans la première étape À, le serveur fournit sa dernière preuve, mais le client
n’envoie pas l’acquittement du bon téléchargement du fichier. Après un certain
temps, en Á, le réseau élit plusieurs auditeurs, qui tentent de télécharger le fichier
afin de le vérifier, dans l’étape suivante Â. Ils rendent ensuite une réponse, qui varie
en fonction de la situation.
La figure 4.9 présente le cas où le serveur est honnête, et dispose du fichier dans
sa totalité. Lorsque tous les auditeurs ont été choisis et ont vérifié si le fichier était
disponible ou non, ils vont rendre leur réponse dans une transaction. Dans ce cas
là, dans l’étape Ã la majorité des auditeurs, les 1 et 3, répondent que le fichier est
toujours accessible et correct. Le serveur est donc honnête, et le client malhonnête.
Le serveur récupère ses deux séquestres en Ä, et les auditeurs 1 et 3 ayant répondu
de façon valide vont être récompensés avec le séquestre auditeur du client.
La figure 4.10 présente la deuxième situation, quand le client est honnête et
que le fichier n’est plus disponible, ou bien est incorrect. Cette fois, la majorité des
auditeurs répondent en Ã que le fichier n’est plus disponible ou qu’il a été altéré.
Le serveur est ainsi en tort, et son séquestre fichier est donné au client, qui récupère
également son séquestre auditeur, dans l’étape Ä. Les auditeurs sont payés avec le
séquestre auditeur du serveur.
4.4.2 Probabilité d’avoir une majorité d’auditeurs honnêtes
Afin d’évaluer la probabilité d’avoir une majorité de noeuds auditeurs honnêtes,

et donc pour savoir quel noeud ment, nous notons n le nombre de noeuds choisis pour
100 System
Figure 4.9 – Appel des auditeurs quand le serveur est honnête

4.4. Auditeurs 101
Figure 4.10 – Appel des auditeurs quand le client est honnête

Probabilité d’une majorité malhonnête
p = 4/5 p = 5/7 p = 2/3

100
10−1
10−2
10−3
10−4
10−5
10−6
10−7
10−8
10−9
40 60 80 100 120 140 160 180 200 220 240 260 280 300
Nombre de noeuds auditeurs n
Figure 4.11 – Probabilité d’avoir une majorité d’auditeurs malhonnêtes, en fonc-

tion de n, avec p = 4/5, p = 5/7 and p = 2/3.
102 System
être auditeurs. Nous notons p la probabilité que le noeud réponde correctement, c’est
à dire qu’il soit honnête, et Xn le nombre total de bonnes réponses.
Nous supposons que les Xn peuvent être modélisés comme des réalisations de
variables aléatoires discrètes indépendantes suivant une distribution de probabilité
binomiale avec une probabilité p.
La blockchain a besoin d’un nombre minimum de noeuds dans le réseau pour
fonctionner correctement et pour que le consensus soit valable. Nous supposons
donc que ce nombre est suffisant pour pouvoir approximer la distribution binomiale
par une distribution normale (n ≥ 30, np ≥ 5 et n(1 − p) ≥ 5) :
1 x−µ 2 − 1 ( √ x−np )2
e− 2 ( σ ) e 2 np(1−p)
f (x) = √ =p √ (4.1)
σ 2π np(1 − p) 2π
La probabilité d’avoir une majorité malhonnête est ainsi :
1 x−np 2
Z n2 Z n2 − 2 ( √np(1−p) )
n e
Pm = p 0 ≤ Xn ≤ = f (x)dx = p √ (4.2)
2 0 0 np(1 − p) 2π
Dans la figure 4.11, nous représentons la probabilité d’avoir une majorité d’au-
diteurs malhonnêtes en fonction du nombre de noeuds d’auditeurs. Nous partons du
principe qu’au moins la moitié des noeuds sont honnêtes, hypothèse de base pour
le bon fonctionnement d’une blockchain.
Avec p = 4/5, la probabilité est inférieure à 10−6 à partir du moment où il y
a un minimum de 41 noeuds dans le réseau. Pour p = 5/7, il faut au moins 101
noeuds, et 181 avec p = 2/3.
Nous avons vu dans la sous-section 3.1.2 que les nombres de noeuds complets
dépassaient les 8000 et 15000 pour les blockchains Bitcoin et Ethereum. Ces nombres
d’auditeurs requis semblent donc tout à fait acceptables.
4.5 Preuve de récupérabilité
4.5.1 Généralités
Comme expliqué dans la section 2.4, les preuves de récupérabilité (PoR) per-
mettent à un client de s’assurer qu’un serveur stocke bien une donnée comme il
le prétend, et que celle-ci est récupérable. Le fonctionnement se base sur des chal-
lenges, posés régulièrement par la blockchain, auxquels le serveur doit répondre
correctement. Tous les noeuds du réseau vont ensuite vérifier chacune des preuves,
Figure 4.12 – Propriétés de la PoR
Propriétés Caractéristiques
Audit Public
Nombre de challenges Illimité
Type de données Statique ou dynamique
Confidentialité de la donnée Oui, chiffrée
et effectuer les actions adéquates en fonction de leurs validités. La probabilité de

répondre correctement sans disposer du fichier originel dans sa totalité doit se rap-
procher au maximum de zéro afin que la preuve de récupérabilité soit utilisable.
4.5.2 Critères de sélection d’une PoR dans notre cas
Comme nous l’avons vu dans la section 2.4, de nombreux systèmes de preuves de

récupérabilité existent, avec des caractéristiques différentes. Pour fonctionner avec
notre système, la preuve choisie doit satisfaire certaines propriétés. Dans Block-
House, il est nécessaire qu’un contrat intelligent, c’est-à-dire tous les noeuds, vérifie
que la preuve ait bien été réalisée, et qu’elle soit correcte. Ces noeuds ne font pas
réellement partie du contrat liant le serveur et le client, ils n’ont jamais accès au
fichier à stocker, il est donc nécessaire que l’audit de la preuve soit public. La durée
de location de l’espace de stockage peut être longue et la fréquence des preuves
rapide, et ces paramètres sont différents pour chaque contrat. Une preuve avec un
nombre illimité de challenges est à privilégier afin d’éviter de se retrouver à court
de challenges, et que le client ait besoin de télécharger sa donnée pour en générer
des nouvelles (ce qui implique également de stocker de nouvelles méta-données sur
la blockchain). Certaines preuves autorisent des données dynamiques tandis que
d’autres sont limitées aux données statiques. Dans un premier temps nous partons
du principe que la donnée est statique, afin de simplifier le processus. Cependant
l’idée de pouvoir modifier la donnée est sans aucun doute une réflexion intéressante
à aborder dans un futur travail. Pour finir, les données doivent pouvoir être chif-
frées par le client, afin de garantir la confidentialité de ses fichiers en rendant leurs
contenus illisibles par le serveur les stockant.
Ces propriétés sont récapitulées dans le tableau 4.12.
De plus, dans le cadre d’une blockchain, la puissance de calcul et le stockage dis-
ponible sont limités. Afin de passer à l’échelle, la preuve devra aussi être paramétrée
d’une façon précise, résumée dans le tableau 4.13. La génération des méta-données
réalisées par le client dans l’étape Ä doit être faisable en quelques minutes par un
ordinateur avec une capacité moyenne, tout comme la génération d’une preuve de
104 System
Figure 4.13 – Paramétrage de la PoR
Propriétés Caractéristiques
Complexité de génération de méta-données (client) Temps acceptable (quelques minutes)
Taille des données stockées pour vérification Petite
Taille des données stockées par le serveur Pas d’importance
Taille des preuves Petite
Complexité de la génération d’une preuve (serveur) Temps acceptable (quelques minutes)
Complexité de vérification d’une preuve Faible
récupérabilité. La vérification d’une preuve de récupérabilité doit quant à elle être

faisable très rapidement, puisque tous les noeuds du réseau vont devoir réaliser cette
action fréquemment.
Au niveau du stockage, la preuve et la méta-donnée seront sauvegardées sur la
chaîne, par tous les noeuds. Elles doivent donc être de tailles réduites. Par contre,
la taille des données stockées par le serveur n’est pas limitée, puisque le serveur a
par définition un grand espace de stockage.
Une thèse est actuellement en cours pour évaluer les différents systèmes de
preuves de récupérabilité, et ainsi aboutir à un choix argumenté.
La publication [69] propose un récapitulatif des nombreuses preuves de posses-
sion et preuves de récupérabilité, avec un classement selon plusieurs critères. Les
preuves présentées dans l’état de l’art, section 2.4, semblent être de bonnes candi-
dates.
4.6 L’aléatoire dans les blockchains

4.6.1 Besoin
Les serveurs réalisent des preuves de récupérabilité à partir de challenges aléa-

toires, fournis au fur et à mesure, pour éviter qu’ils puissent les calculer à l’avance.
Pour que BlockHouse fonctionne correctement, nous avons donc besoin de pouvoir
générer cet aléatoire. Par aléatoire, nous entendons ici un nombre non prévisible
mais déterministe. En effet, les noeuds serveurs ne doivent pas pouvoir prévoir à
l’avance les challenges qui vont leur être soumis, afin de ne pas pouvoir tricher. Ce-
pendant, à l’instant t où le challenge est "envoyé" au serveur (c’est-à-dire en réalité
déduit de l’état de la blockchain), n’importe quel noeud doit pouvoir re-générer le
même challenge à partir de l’algorithme du générateur pseudo-aléatoire choisi et de
sa copie de la blockchain.
Ce besoin se fait également ressentir au niveau du fonctionnement même de la
blockchain, et est nécessaire à de nombreuses applications liées aux blockchains. Par
4.6. L’aléatoire dans les blockchains 105
exemple, l’équipe d’Ethereum travaille intensivement sur un nouveau consensus,

la preuve d’enjeu (expliquée dans la section 2.2.3), qui nécessite de pouvoir élire
pseudo-aléatoirement un noeud en charge de la création du futur bloc.
De plus, de nombreux contrats intelligents nécessitent de pouvoir générer de
l’aléatoire, comme par exemple des contrats de jeux de hasard, de loterie, de vote,...
Un état de l’art de la situation actuelle a été exposé pendant le "Randomness
submit", le 13 août 2020. Des acteurs de la fondation Ethereum et de Protocol
Labs (l’équipe en charge de IPFS et FileCoin) ont ainsi présenté leurs solutions
et propositions. Plusieurs d’entre elles pourraient convenir à notre système, nous
allons donc les présenter ici.
4.6.2 Solutions existantes
Randao est un protocole fonctionnant dans Ethereum 2 [70], utilisant un contrat

intelligent auquel plusieurs noeuds participent (N dans notre exemple). La généra-
tion d’un nombre aléatoire se déroule en trois phases. Tout d’abord, chaque par-
ticipant génère une graine secrète, appelée s, dont il envoie l’empreinte h(s) au
contrat.
Dans un second temps, tous les noeuds envoient leurs graines secrètes s au
contrat. Après vérification, si elles correspondent effectivement aux empreintes pré-
cédemment envoyées, elles sont ajoutées à la liste de toutes les graines .
La troisième étape est la génération du nombre aléatoire. Pour cela, RANDAO
possède une fonction notée f , qui prend en paramètres d’entrée la liste des graines
secrètes, et propose en sortie un nombre aléatoire. Ce nombre est f (s1 , s2 , ..., sN ).
Avec cette solution, chaque noeud ne peut manipuler qu’une seule graine parmi les
N , sans connaître à l’avance celles des autres.
Drand est un protocole [71] utilisé par filecoin pour le consensus, afin de déter-
miner qui construit le bloc, ainsi que pour la preuve de spacetime et pour la preuve
de réplication.
La génération d’un nombre aléatoire se fait en deux étapes, grâce à la partici-
pation de N noeuds différents.
La première étape est l’initialisation. Chaque noeud génère une clé privée et une
clé publique associée. Toutes les clés publiques sont envoyées sur la blockchain, et
regroupées afin de créer une clé publique collective et une clé privée partielle par
serveur. Les participants n’ont pas accès à la totalité de cette clé privée.
La deuxième étape est la génération du nombre aléatoire. Elle se fait sur la
106 System
demande d’un noeud, qui envoie un message à l’ensemble des participants. Les
autres noeuds vont lui répondre en signant ce message avec une signature partielle
(t,n) BLS, à partir de leurs clés privées partielles. Lorsqu’au moins t signatures
partielles sont recueillies, il est possible de construire la signature BLS complète.
Pour accentuer l’aléatoire, cette signature est hachée, et c’est son empreinte qui sert
de nombre pseudo-aléatoire. Ce nombre peut être facilement vérifié grâce à la clé
publique collective.
Les VDF pour verifiable delay functions [72], sont des fonctions nécessitant des
calculs séquentiels pour être évaluées, mais dont la solution est rapide et facile à
vérifier. Elles permettent de rajouter un délai à la sortie du générateur aléatoire,
afin d’empêcher des acteurs de modifier certaines entrées pour que la valeur pseudo-
aléatoire leur convienne. Avec ce délai, les entrées seront fixées avant de pouvoir
obtenir le nombre généré et il est donc impossible de tester plusieurs entrées pour
influer sur le résultat.
Un exemple simple est d’effectuer plusieurs fonctions de hachage imbriquées,
h(h(h(...h(x)))). Le principal défaut ici est que l’unique façon de vérifier est de
re-effectuer le calcul, qui est par définition coûteux en temps. D’autres articles ont
proposé diverses solutions, comme des équations prenant un temps assez précis à
résoudre, et faciles à vérifier.
4.6.3 Intégration dans BlockHouse
Lors de l’explication détaillée de la phase de stockage et d’audit, dans la sec-

tion 4.3.2, nous avons posé l’hypothèse que le challenge était déduit de la blockchain.
Nous allons ici proposer deux façons différentes de générer ces challenges, en utili-
sant les travaux cités précédemment.
4.6.3.1 Challenge généré par un sous-ensemble de noeuds
Dans cette proposition, nous reprenons l’idée générale présentée dans Drand et
Randao, à savoir que pour obtenir un nombre aléatoire, il est nécessaire que N
noeuds du réseau participent à son élaboration grâce à un contrat intelligent. Le
principal problème ici est que cette génération n’est pas instantanée mais se fait
en plusieurs étapes, et donc en plusieurs blocs. En fonction du système dans lequel
nous nous trouvons, deux solutions peuvent être envisagées :
4.6. L’aléatoire dans les blockchains 107
La première est de confier la demande de la génération d’un nombre aléatoire

au serveur devant fournir prochainement une preuve. Il doit donc anticiper le temps
que les différentes étapes du contrat intelligent soient réalisées.
Une deuxième solution est de demander la génération automatique d’un

nombre aléatoire à chaque nouveau bloc. Le serveur devant réaliser une preuve
utilise celui du dernier bloc.
L’inconvénient principal de ces solutions est que chaque génération entraîne

le stockage de plusieurs valeurs sur la blockchain, comme les graines secrètes ou
encore les paires de clés privées / publiques. De plus, il faut s’assurer de disposer
d’un nombre suffisant de participants à chaque nouveau bloc, sous peine de bloquer
le système car sans nombre aléatoire les serveurs n’auront pas de challenge et ne
pourront donc pas émettre leurs preuves.
Dans un système avec beaucoup de noeuds et de contrats de location, il est
probable que plusieurs serveurs doivent générer leurs preuves au même moment,
dans le même bloc. Plutôt que de demander la génération de plusieurs nombres
aléatoires par bloc, et donc d’augmenter les coûts en stockage et la participation aux
contrats intelligents, il peut être judicieux dans ce contexte de choisir la deuxième
solution. Pour anticiper l’éventuelle situation où plusieurs noeuds stockant la même
donnée devraient faire une preuve au même instant, avec donc le même challenge,
il est possible de personnaliser le challenge, par exemple en concaténant le dernier
nombre aléatoire généré avec l’identifiant unique du noeud.
Dans un système avec peu de noeuds et peu de contrats de location, à l’inverse,
la probabilité que plusieurs serveurs doivent générer une preuve dans le même bloc
diminue. Ainsi, il n’y aura pas forcément besoin de nombre aléatoire dans chacun
des blocs et la première solution est à privilégier.
4.6.3.2 Challenge généré à partir de l’état de la blockchain
Avec cette solution, nous proposons d’utiliser une VDF, c’est-à-dire une fonction
séquentielle, en lui donnant en entrée des paramètres directement issus de l’état de la
blockchain à un instant t. La fonction VDF permet de sécuriser ce processus, puisque
par définition le temps de calculer son résultat, le bloc contenant les paramètres
sera déjà validé et sécurisé. Le nombre aléatoire issu de ce calcul ne sera donc plus
modifiable, et les noeuds du réseau ne pourront pas tricher.
Ce calcul étant relativement long, il peut être laissé à la charge du noeud serveur
qui inclura son résultat, donc le challenge, dans la transaction contenant la preuve
108 System
de récupérabilité. Les autres noeuds pourront facilement vérifier que le challenge a

été correctement généré en connaissant l’état de la blockchain à l’instant t.
Comme dans la proposition précédente, afin d’éviter que deux serveurs aient à
générer une preuve identique au même moment sur les mêmes données, le challenge
peut être obtenu à partir du nombre aléatoire concaténé à l’identifiant du serveur.
4.7 Conclusion
Dans ce chapitre, nous avons présenté notre solution de location d’espace de
stockage, appelée BlockHouse, reposant sur une blockchain. La particularité de
BlockHouse par rapport aux blockchains de stockage existantes est le fait que toutes
les étapes se déroulent sur la chaîne, à l’exception du stockage même de la donnée.
En utilisant des contrats intelligents associés à des preuves de récupérabilité, la
vérification de la donnée et le paiement associé sont automatiques et sécurisés, car
tous les noeuds du réseau vont pouvoir les vérifier.
Le point critique de cette solution est atteint lorsque le noeud client, qui loue
l’espace de stockage, souhaite récupérer sa donnée, présente sur le noeud serveur.
Cette action se déroulant en dehors de la blockchain, il est impossible pour le réseau
de vérifier que tout s’est correctement déroulé. En effet, en cas de désaccord, les
autres noeuds ignorent si le problème se trouve du coté du client ou du coté du
serveur. Pour résoudre cela, nous avons proposé une solution utilisant un ensemble
d’autres noeuds, appelés auditeurs, dont le but est de vérifier que le fichier est
réellement disponible ou non, afin de connaître l’origine du problème. Ces noeuds
sont récompensés pour leur travail, grâce à un séquestre spécial mis de coté par les
deux noeuds.
Une autre thèse est actuellement en cours, avec pour objectifs d’effectuer une
évaluation complète de BlockHouse, en étudiant notamment les tailles des preuves
de récupérabilité et des méta-données associées, ainsi que leurs complexités et leurs
temps d’exécution.
Chapitre 5
Conclusion et perspectives
Dans ce chapitre, nous résumons tout d’abord les principales contributions pré-
sentées dans ce manuscrit, puis nous donnons quelques perspectives futures avant
de conclure sur ces travaux.
5.1 Résumé du manuscrit
Cette thèse s’est articulée autour des concepts de la blockchain et du stockage.

Dans un premier temps, nous avons abordé dans le chapitre 3 ces thèmes dans
la situation où un noeud souhaite participer à la blockchain avec des ressources de
stockage limitées. Nous avons évalué le problème de la forte augmentation de la
taille de la chaîne, lui demandant un effort important pour la stocker entièrement.
Pour cela, nous avons proposé un nouveau type de noeud, appelé low storage (LS).
L’avantage de cette proposition réside dans le fait que ces noeuds LS peuvent s’in-
tégrer dans une blockchain existante sans avoir besoin de modifier l’existant. Ils
permettent de participer activement à la blockchain, à sa distribution et à sa dé-
centralisation, en réduisant l’espace nécessaire pour la stocker dans sa totalité. Un
autre point bloquant actuel dans les blockchains est l’engorgement du réseau, dû
au fait que le nombre de noeuds mettant à disposition la blockchain est trop faible
en comparaison de la demande. Ils se retrouvent donc saturés. Avec notre solu-
tion, nous pouvons espérer une augmentation significative du nombre de noeuds, ce
qui conduirait à un désengorgement du réseau en proposant plus de noeuds depuis
lesquels télécharger la chaîne.
Pour ce faire, nous proposons de stocker la blockchain sous forme codée. Chaque
bloc est divisé en fragments, de tailles fixes, on effectue des combinaisons linéaires
de ces fragments afin de créer des fragments codés. Seuls ces fragments codés sont
conserver, ainsi que l’en-tête du bloc. Le bloc originel est supprimé. Pour accéder à
la donnée initiale, un noeud doit télécharger suffisamment de fragments codés pour
effectuer une opération de décodage, et reconstruire le bloc. Il peut être vérifier
grâce à son empreinte, conservée dans l’en-tête.
110 Chapitre 5. Conclusion et perspectives
Afin de pouvoir décoder en présence de fragments codés erronés ou malveillants,

nous avons présenté deux solutions. La première utilise des codes correcteurs,
pour décoder en téléchargeant plus de fragments codés et ainsi augmenter la
proportion de fragments codés valides par rapport à ceux en faute. La deuxième
utilises des empreintes homomorphes, dans le but de vérifier la cohérence des
fragments codés avant même de les télécharger et de tenter l’opération de décodage.
Dans un second temps, nous nous sommes intéressés au cas où l’utilisateur dis-
pose d’un espace de stockage non utilisé. Nous avons présenté dans le chapitre 4 une
solution de location d’espace de stockage basée sur la blockchain, appelée Block-
House. Celle-ci met en relation un client, souhaitant faire stocker une donnée, et un
ou plusieurs serveurs, disposant d’espaces de stockage non utilisés. Les deux entités
se mettent d’accord sur différents paramètres, comme le prix et la durée de location,
et inscrivent le tout de façon infalsifiable dans un contrat intelligent. Pour être payé
de façon régulière pour son service, le serveur va devoir prouver à l’ensemble de la
blockchain qu’il dispose toujours de la donnée. Pour cela, BlockHouse utilise des
preuves de récupérabilité (PoR). Les PoR fonctionnent sous la forme de challenges-
réponses, et permettent de s’assurer avec une forte probabilité de la disponibilité et
de l’intégrité de la donnée. Le challenge de chaque preuve sera issue directement de
l’état de la blockchain, donc accessible à tous les acteurs du réseau, et la réponse
fournie par le serveur sera inscrite dans la blockchain. Chaque noeud pourra ainsi
vérifier sa validité, et le serveur sera récompensé.
5.2 Perspectives futures

Dans le chapitre 3, nous avons effectué plusieurs tests sur ordinateurs et sur
raspberry, qui se sont montrés concluant. L’internet des objets est un domaine en
pleine expansion, et de nombreux travaux sont en cours pour les utiliser avec les
blockchains. Les objets connectés ont par définition des caractéristiques limités, en
terme de puissance de calculs, de connectiques réseau et de stockage. Il pourrait être
intéressant de réaliser plus de tests de notre système sur différents objets connectés,
car l’utilisation de noeuds LS pourraient résoudre les problèmes de débit réseau
limité et de besoin en stockage trop important.
Nos tests actuels se sont contentés de vérifier la cohérence des temps d’exécu-
tion du codage et du décodage, sans analyser le contexte autour. Afin de valider
réellement le système, il serait utile de modifier le client d’une blockchain existante,
ou bien d’en créer un nouveau, afin d’y intégrer les nouveautés apportées par les
5.2. Perspectives futures 111
noeuds LS, et pouvoir réaliser des tests plus poussés. Un point à comparer serait
par exemple les débits minimum requis dans le cas où on aurait un réseau composé
de peu de noeuds complets, et dans le cas d’un réseau comprenant un nombre plus
élevé de noeuds LS.
Les travaux effectués dans le chapitre 4 s’inscrivent dans un cadre plus global
sur lequel un autre doctorant continue à travailler. Pour le moment, peu de tests ont
été réalisés, et il n’existe pas de réelles études permettant d’estimer le temps ajouté
par la vérification des différentes preuves de récupérabilité. De même, il est difficile
d’évaluer les tailles des différents types de données d’un PoR : méta-données,
challenges, preuves, ainsi que leurs complexités et temps d’exécution. Il serait
intéressant là encore de réaliser une implémentation du système, afin de mesurer
l’impact de la génération et la vérification des preuves, pour s’assurer qu’elles ne
sont pas bloquantes pour le système.
La deuxième contribution de ce manuscrit présente une application qui aurait

tendance à alourdir la blockchain, tandis que la première propose au contraire de
l’alléger, en la codant. Une idée de travaux futurs pourrait être de combiner ces deux
systèmes, en proposant une blockchain de location d’espaces de stockage libres, dont
les anciens blocs seraient codés afin d’en limiter l’impact.
Annexe A
Liste des publications
Conférences internationales
— Perard, D., Lacan, J., Bachy, Y., and Detchart, J. (2018). Erasure code-based
low storage blockchain node. Publiée à Blockchain 2018 (Halifax, Canada),
Juillet 2018.
— Perard D. , Gicquel L., and Lacan J. , "BLOCKHOUSE : Blockchain-based
distributed storehouse system". Publiée à 9th Latin-American Symposium
on Dependable Computing (LADC), Novembre 2019.
— Perard D. , Goffin X., and Lacan J. , "Using Homomorphic hashes in coded
blockchains". Accepté pour présentation à SERIAL20, 4th Workshop on
Scalable and Resilient Infrastructures for Distributed Ledgers, August 2020.
En cours de rédaction
— Gicquel L., Perard D., and Lacan J. , "Implementation and evaluation of
BlockHouse". À soumettre à une revue.
Présentation à des groupes de recherche

— Perard, D. Nouveau type de noeud blockchain basé sur les codes à efface-
ment. Présentation au Séminaire Toulousain en Réseau (Toulouse, France),
Octobre 2018.
Bibliographie
[1] K. Wüst and A. Gervais, “Do you need a blockchain ?” in 2018 Crypto Valley
Conference on Blockchain Technology (CVCBT). IEEE, 2018, pp. 45–54.
(Cited in pages ix et 23.)
[2] M. J. Dworkin, “Sha-3 standard : Permutation-based hash and extendable-
output functions,” Tech. Rep., 2015. (Cited in page 9.)
[3] M. N. Krohn, M. J. Freedman, and D. Mazieres, “On-the-fly verification of
rateless erasure codes for efficient content distribution,” in IEEE Symposium
on Security and Privacy, 2004. Proceedings. 2004. IEEE, 2004, pp. 226–240.
(Cited in pages 10, 64, 67 et 69.)
[4] C. Gkantsidis, P. Rodriguez et al., “Cooperative security for network coding
file distribution.” in INFOCOM, vol. 3, no. 2006, 2006, p. 5. (Cited in pages 10,
67 et 69.)
[5] R. L. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digital si-
gnatures and public-key cryptosystems,” Communications of the ACM, vol. 21,
no. 2, pp. 120–126, 1978. (Cited in page 12.)
[6] T. ElGamal, “A public key cryptosystem and a signature scheme based on
discrete logarithms,” IEEE transactions on information theory, vol. 31, no. 4,
pp. 469–472, 1985. (Cited in page 12.)
[7] D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digital signature
algorithm (ecdsa),” International journal of information security, vol. 1, no. 1,
pp. 36–63, 2001. (Cited in page 12.)
[8] C.-P. Schnorr, “Efficient identification and signatures for smart cards,” in
Conference on the Theory and Application of Cryptology. Springer, 1989,
pp. 239–252. (Cited in page 12.)
[9] R. C. Merkle, “A digital signature based on a conventional encryption func-
tion,” in Conference on the theory and application of cryptographic techniques.
Springer, 1987, pp. 369–378. (Cited in page 13.)
[10] D. Chaum, A. Fiat, and M. Naor, “Untraceable electronic cash,” in Conference
on the Theory and Application of Cryptography. Springer, 1988, pp. 319–327.
(Cited in page 14.)
[11] D. Chaum, “Blind signatures for untraceable payments,” in Advances in cryp-
tology. Springer, 1983, pp. 199–203. (Cited in page 14.)
116 Bibliographie
[12] S. Haber and W. S. Stornetta, “How to time-stamp a digital document,” in

Conference on the Theory and Application of Cryptography. Springer, 1990,
[13] D. Bayer, S. Haber, and W. S. Stornetta, “Improving the efficiency and relia-
bility of digital time-stamping,” in Sequences Ii. Springer, 1993, pp. 329–334.
(Cited in page 14.)
[14] N. Ferguson, “Single term off-line coins,” in Workshop on the Theory and Ap-
plication of of Cryptographic Techniques. Springer, 1993, pp. 318–328. (Cited
in page 14.)
[15] S. Brands, “Untraceable off-line cash in wallet with observers,” in Annual in-
ternational cryptology conference. Springer, 1993, pp. 302–318. (Cited in
page 14.)
[16] L. Law, S. Sabett, and J. Solinas, “How to make a mint : the cryptography of
anonymous electronic cash,” Am. UL Rev., vol. 46, p. 1131, 1996. (Cited in
page 14.)
[17] A. Back et al., “Hashcash-a denial of service counter-measure,” 2002. (Cited
in pages 15 et 25.)
[18] W. Dai, “b-money : A scheme for a group of untraceable digital pseudonyms
to pay each other with money and to enforce contracts amongst themselves
without outside help. weidai. com,” 1998. (Cited in page 15.)
[19] N. Szabo, “Bit gold,” Website/Blog, 2008. (Cited in page 15.)
[20] S. Nakamoto, “Bitcoin : A peer-to-peer electronic cash system,” Manubot,
Tech. Rep., 2019. (Cited in pages 15, 25 et 46.)
[21] V. Buterin et al., “Ethereum white paper,” GitHub repository, vol. 1, pp. 22–23,
2013. (Cited in page 15.)
[22] N. Szabo, “Smart contracts,” Unpublished manuscript, 1994. (Cited in page 15.)
[23] M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of distributed
consensus with one faulty process,” Journal of the ACM (JACM), vol. 32, no. 2,
pp. 374–382, 1985. (Cited in page 24.)
[24] L. Lamport et al., “Paxos made simple,” ACM Sigact News, no. 4, pp. 18–25,
[25] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals problem,”
in Concurrency : the Works of Leslie Lamport, 2019, pp. 203–226. (Cited in
pages 24 et 25.)
Bibliographie 117
[26] M. Castro, B. Liskov et al., “Practical byzantine fault tolerance,” in OSDI,

vol. 99, no. 1999, 1999, pp. 173–186. (Cited in page 24.)
[27] D. Ongaro and J. Ousterhout, “In search of an understandable consensus algo-
rithm,” in 2014 {USENIX} Annual Technical Conference ({USENIX}{ATC}
14), 2014, pp. 305–319. (Cited in page 26.)
[28] S. Dziembowski, S. Faust, V. Kolmogorov, and K. Pietrzak, “Proofs of space,”
in Annual Cryptology Conference. Springer, 2015, pp. 585–605. (Cited in
page 27.)
[29] S. Wilkinson, T. Boshevski, J. Brandoff, and V. Buterin, “Storj a peer-to-peer
cloud storage network,” 2014. (Cited in pages 27 et 85.)
[30] V. Buterin and E. fondation, “Ethereum : A next-generation smart
contract and decentralized application platform,” 2013. [Online]. Available :
https://github.com/ethereum/wiki/wiki/White-Paper (Cited in page 27.)
[31] G. Wood and E. fondation, “Ethereum : A secure decentralised generalised
transaction ledger,” 2014. [Online]. Available : https://ethereum.github.io/
yellowpaper/paper.pdf (Cited in page 27.)
[32] M. Dameron, “Beigepaper : An ethereum technical specification,” 2018.
[Online]. Available : https://github.com/chronaeon/beigepaper/blob/master/
beigepaper.pdf (Cited in page 27.)
[33] V. Buterin, “Ethereum 2.0 mauve paper,” in Ethereum developer conference,
vol. 2, 2016. (Cited in page 27.)
[34] N. Szabo, “Smart contracts : building blocks for digital markets,” EXTROPY :
The Journal of Transhumanist Thought,(16), vol. 18, no. 2, 1996. (Cited in
page 28.)
[35] C. E. Shannon, “A mathematical theory of communication,” Bell system tech-
nical journal, vol. 27, no. 3, pp. 379–423, 1948. (Cited in page 31.)
[36] I. S. Reed, Reed–Solomon codes : A historical overview. New York : IEEE
Press, 1991. (Cited in page 34.)
[37] I. S. Reed and G. Solomon, “Polynomial codes over certain finite fields,” Jour-
nal of the society for industrial and applied mathematics, vol. 8, no. 2, pp.
300–304, 1960. (Cited in page 34.)
[38] J. W. Byers, M. Luby, M. Mitzenmacher, and A. Rege, “A digital fountain
approach to reliable distribution of bulk data,” ACM SIGCOMM Computer
Communication Review, vol. 28, no. 4, pp. 56–67, 1998. (Cited in page 34.)
118 Bibliographie
[39] M. Luby, “Lt codes,” in The 43rd Annual IEEE Symposium on Foundations
of Computer Science, 2002. Proceedings. IEEE, 2002, pp. 271–280. (Cited in
pages 34 et 52.)
[40] A. Shokrollahi, “Raptor codes,” IEEE transactions on information theory,
vol. 52, no. 6, pp. 2551–2567, 2006. (Cited in page 35.)
[41] P. Maymounkov, “Online codes,” Technical report, New York University, Tech.
Rep., 2002. (Cited in page 35.)
[42] M. A. Shah, M. Baker, J. C. Mogul, R. Swaminathan et al., “Auditing to keep
online storage services honest.” in HotOS, 2007. (Cited in pages 37 et 38.)
[43] A. Juels and B. S. Kaliski Jr, “Pors : Proofs of retrievability for large files,”
in Proceedings of the 14th ACM conference on Computer and communications
security. Acm, 2007, pp. 584–597. (Cited in pages 38 et 39.)
[44] K. D. Bowers, A. Juels, and A. Oprea, “Proofs of retrievability : Theory and
implementation,” in Proceedings of the 2009 ACM workshop on Cloud compu-
ting security, 2009, pp. 43–54. (Cited in page 39.)
[45] H. Shacham and B. Waters, “Compact proofs of retrievability,” in Internatio-
nal Conference on the Theory and Application of Cryptology and Information
Security. Springer, 2008, pp. 90–107. (Cited in page 39.)
[46] S. Park, S. Im, Y. Seol, and J. Paek, “Nodes in the bitcoin network : Compa-
rative measurement study and survey,” IEEE Access, vol. 7, pp. 57 009–57 022,
[47] S. K. Kim, Z. Ma, S. Murali, J. Mason, A. Miller, and M. Bailey,
“Measuring ethereum network peers,” in Proceedings of the Internet
Measurement Conference 2018, ser. IMC ’18. New York, NY, USA :
Association for Computing Machinery, 2018, p. 91–104. [Online]. Available :
https://doi.org/10.1145/3278532.3278542 (Cited in page 44.)
[48] EthHub, “Running an ethereum node.” [Online]. Available : https://docs.
ethhub.io/using-ethereum/running-an-ethereum-node/ (Cited in page 45.)
[49] L. Rizzo, “Effective Erasure Codes For Reliable Computer Communication
Protocols,” ACM Computer Communication Review, vol. 27, no. 2, pp. 24–36,
April 1997. (Cited in page 51.)
[50] C. Studholme and I. F. Blake, “Random matrices and codes for the era-
sure channel,” Algorithmica, vol. 56, no. 4, pp. 605–620, Apr 2010. (Cited
in page 54.)
Bibliographie 119
[51] T. Le, J. S., and S. B., “Code sample : Intel isa-l erasure code and reco-
very,” software.intel.com/en-us/articles/intel-isa-l-erasure-code-and-recovery,
[52] J. Detchart, “Dépot github les programmes tests d’isa-l.” [Online]. Available :
github.com/jdetchart/isa-l (Cited in page 55.)
[53] M. Al-Bassam, A. Sonnino, and V. Buterin, “Fraud proofs : Maximising light
client security and scaling blockchains with dishonest majorities,” arXiv pre-
print arXiv :1809.09044, 2018. (Cited in page 61.)
[54] S. Kadhe, J. Chung, and K. Ramchandran, “Sef : A secure fountain architecture
for slashing storage costs in blockchains,” arXiv preprint arXiv :1906.12140,
2019. (Cited in pages 61, 63 et 79.)
[55] D. Perard, J. Lacan, Y. Bachy, and J. Detchart, “Erasure code-based low
storage blockchain node,” in IEEE International Conference on Blockchain.
IEEE, 2018. (Cited in pages 61 et 63.)
[56] D. Perard, X. Goffin, and J. Lacan, “Using homomorphic hashes
in coded blockchains,” in SERIAL20 4th Workshop on Scalable and
Resilient Infrastructures for Distributed Ledgers, 2020. [Online]. Available :
https://arxiv.org/pdf/2010.04607.pdf (Cited in page 64.)
[57] V. Buterin, “A note on data availability and erasure coding,” November
2017. [Online]. Available : github.com/ethereum/research/wiki/A-note-on-
data-availability-and-erasure-coding (Cited in page 77.)
[58] X. Chen, S. Lin, and N. Yu, “Bitcoin blockchain compression algorithm for
blank node synchronization,” in 2019 11th International Conference on Wire-
less Communications and Signal Processing (WCSP). IEEE, 2019, pp. 1–6.
(Cited in page 79.)
[59] L. Quan and Q. Huang, “Transparent coded blockchain,” in Proceedings of
the 15th International Conference on emerging Networking EXperiments and
Technologies, 2019, pp. 12–13. (Cited in page 79.)
[60] D. Mitra and L. Dolecek, “Patterned erasure correcting codes for low storage-
overhead blockchain systems,” in 2019 53rd Asilomar Conference on Signals,
Systems, and Computers. IEEE, 2019, pp. 1734–1738. (Cited in page 79.)
[61] R. Blum and T. Bocek, “Superlight–a permissionless, light-client only block-
chain with self-contained proofs and bls signatures,” in 2019 IFIP/IEEE Sym-
posium on Integrated Network and Service Management (IM). IEEE, 2019,
120 Bibliographie
[62] J. Li and B. Li, “Erasure coding for cloud storage systems : A survey,” Tsinghua
Science and Technology, vol. 18, no. 3, pp. 259–272, June 2013. (Cited in
page 85.)
[63] D. Vorick and L. Champine, “Sia : Simple decentralized storage,” Nebulous
Inc, 2014. (Cited in page 85.)
[64] S. Ruj, M. S. Rahman, A. Basu, and S. Kiyomoto, “Blockstore : A secure decen-
tralized storage framework on blockchain,” in 2018 IEEE 32nd International
Conference on Advanced Information Networking and Applications (AINA).
IEEE, 2018, pp. 1096–1103. (Cited in page 86.)
[65] P. Labs, “Filecoin website.” [Online]. Available : https://filecoin.io/ (Cited in
page 86.)
[66] S. Park, A. Kwon, G. Fuchsbauer, P. Gaži, J. Alwen, and K. Pietrzak, “Space-
mint : A cryptocurrency based on proofs of space,” in International Conference
on Financial Cryptography and Data Security. Springer, 2018, pp. 480–499.
(Cited in page 86.)
[67] D. Perard, L. Gicquel, and J. Lacan, “Blockhouse : Blockchain-based distribu-
ted storehouse system,” in 2019 9th Latin-American Symposium on Dependable
Computing (LADC). IEEE, 2019, pp. 1–4. (Cited in page 87.)
[68] E. Ruchevits, “Block protocole 2.0,” 2015. [On-
line]. Available : https://github.com/ethereum/wiki/blob/
c02254611f218f43cbb07517ca8e5d00fd6d6d75/Block-Protocol-2.0.md (Cited
in page 91.)
[69] C. B. Tan, M. H. A. Hijazi, Y. Lim, and A. Gani, “A survey on proof of
retrievability for cloud data integrity and availability : Cloud storage state-of-
the-art, issues, solutions and future trends,” Journal of Network and Computer
Applications, vol. 110, pp. 75–86, 2018. (Cited in page 104.)
[70] randao, “Randao : Verifiable random number generation.” Randao, 2017.
(Cited in page 105.)
[71] D. organization, “Drand - a distributed randomness beacon daemon.” [Online].
Available : github.com/drand/drand (Cited in page 105.)
[72] D. Boneh, J. Bonneau, B. Bünz, and B. Fisch, “Verifiable delay functions,”
in Annual international cryptology conference. Springer, 2018, pp. 757–788.
(Cited in page 106.)
"Mais moi, malheureusement, je ne sais pas voir les moutons à travers les caisses.
Je suis peut-être un peu comme les grandes personnes. J’ai dû vieillir."
Antoine de Saint-Exupéry

2020 Perard Doriane

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2020 Perard Doriane

Transféré par

Droits d'auteur :

Formats disponibles

5)µ4&

Blockchain et stockage efficace

²DPMF EPDUPSBMF et discipline ou spécialité 

Merci à mes amis et à ma famille.

merci d’être venue si souvent me voir à chocolatine-land, pour encourager le Stade

3 Client blockchain basé sur les codes à effacement 41

3.4.1 Taille du corps fini . . . . . . . . . . . . . . . . . . . . . . . . 54

4 BlockHouse : Blockchain-based Distributed Storehouse System 81

5 Conclusion et perspectives 109

A Liste des publications 113

2.1 Exemple d’un arbre de Merkle . . . . . . . . . . . . . . . . . . . . . 13

3.1 Evolution de la taille de la blockchain Bitcoin . . . . . . . . . . . . . 43

4.1 EMEA, répartition par origine . . . . . . . . . . . . . . . . . . . . . 82

Key words : Blockchain, scalability, storagee, erasure code, proof of retrieva-

1.2 Plan du manuscrit

2.1 Cryptographie et sécurité informatique

2.1.1 Propriétés de la sécurité informatique

2.1.2 Fonctions de hachage classiques

∀X ∈ h ({0, 1}∗ ) il doit être impossible calculatoirement de trouver

— Résistance au calcul d’une deuxième préimage : Pour un texte donné et son

∀x ∈ {0, 1}∗ il doit être impossible calculatoirement de trouver

— Résistance aux collisions : il est impossible calculatoirement de construire 2

il doit être impossible calculatoirement de trouver

2.1.3 Fonctions de hachage homomorphes

Les paramètres du système à générer sont p et q, deux grands nombres premiers

La signature numérique a pour but de garantir les propriétés d’authenticité de

Figure 2.1 – Exemple d’un arbre de Merkle

2.1.5 Arbre de Merkle

Un arbre de Merkle est une structure informatique particulière, présenté en 1987

Pour le construire on commence par découper le fichier en plusieurs blocs, ici

En 1988, D. Chaum, propose un nouveau système de paiement, anonyme, afin

— Les lois ne peuvent pas directement être adaptées à la monnaie électronique.

En 1997, A. Back propose une méthode de preuve de travail, sous le nom de

Mais le hashcash permet également de venir à bout du problème du consensus,

En 2008, Satoshi Nakamoto écrit l’article fondateur du Bitcoin, la première vraie

En 2013, V. Buterin décide de reprendre le concept de la blockchain, en y ajou-

La technologie blockchain est peu à peu devenue connue du grand public, et de

2.2.1.2 Principe général d’une blockchain

Afin d’expliquer le plus simplement possible le fonctionnement général d’une

Dans sa définition formelle, la blockchain est un registre distribué et décentralisé

2.2.1.3 Structure du réseau

Chaque participant du réseau, appelé noeud, est en réalité un ordinateur sur

2.2.1.4 Structure d’un bloc et de la blockchain

Figure 2.2 – Exemple d’un bloc simple

Figure 2.3 – Exemple d’une blockchain

— L’empreinte du bloc courant.

2.2.1.5 Données et transactions

la signature permet de garantir l’authenticité et l’intégrité des données, ainsi que

2.2.1.6 Propriété d’immuabilité de la blockchain

Il faudrait ainsi changer le bloc suivant, et ainsi de suite. Le tout suffisamment

Figure 2.4 – Tentative de modification d’un ancien bloc

rapidement pour rattraper et dépasser la chaîne courante légitime, puisque, comme

2. Considérons maintenant le cas où le noeud malveillant réussirait à modifier

2.2.2 Blockchain publique, blockchain privée

Comme nous l’avons vu précédemment, la blockchain est par définition un réseau

2.2.2.1 Blockchain publique

La première blockchain, Bitcoin, est une blockchain publique, même si la préci-

2.2.2.2 Blockchain privée

Les blockchains de consortium sont généralement utilisées dans les cas où

procéder à un vote pour se mettre d’accord sur l’acceptation ou le refus d’accueillir

Les blockchains privées avec autorité centrale fonctionnent grâce à un tiers

Le choix d’utilisation d’une blockchain, publique ou privée (de consortium ou

Figure 2.5 – Ai-je besoin d’une blockchain ? Traduction du diagramme de l’ar-

²DPMF EPDUPSBMF et discipline ou spécialité