Vitalik : Fourches dures, fourches molles, par défaut et obligatoires
TechFlow SélectionTechFlow Sélection
Vitalik : Fourches dures, fourches molles, par défaut et obligatoires
Dans le mécanisme de mise à niveau du protocole, est-il préférable d'opter pour un soft fork ou un hard fork ?
Dédié à des analyses Web3 approfondiesAuteur : Vitalik Buterin
Date de publication : 14 mars 2017
Dans les discussions relatives aux blockchains, un débat important concerne le choix préférentiel entre soft fork (bifurcation douce) et hard fork (bifurcation dure) pour la mise à jour des protocoles. La différence fondamentale entre une soft fork et une hard fork réside dans le fait qu'une soft fork modifie les règles du protocole en réduisant strictement l'ensemble des transactions valides, de sorte que les nœuds suivant l'ancienne règle peuvent rester sur la nouvelle chaîne (à condition que la majorité des mineurs ou validateurs appliquent la bifurcation). En revanche, une hard fork permet de rendre valides des transactions ou blocs auparavant invalides, ce qui oblige les utilisateurs à mettre à jour leur client afin de rester sur la nouvelle chaîne issue de la hard fork.
Il existe deux sous-types de hard forks :
1. Les hard forks strictement expansives (strictly expanding hard forks), qui élargissent complètement l'ensemble des transactions valides, rendant ainsi l'ancienne règle effectivement compatible avec la nouvelle ;
2. Les hard forks bilatérales (bilateral hard forks), où les deux ensembles de règles sont mutuellement incompatibles.
Voici un diagramme de Venn illustrant les différents types de forks :
Les avantages généralement invoqués sont les suivants :
- Les hard forks offrent plus de flexibilité aux développeurs lors des mises à niveau du protocole, car ils n'ont pas besoin de s'assurer que les nouvelles règles soient compatibles avec les anciennes.
- Les soft forks sont plus pratiques pour les utilisateurs, car ces derniers n'ont pas besoin de mettre à jour leur logiciel pour rester sur la nouvelle chaîne.
- Les soft forks ont moins de risques de provoquer une scission de la chaîne.
- Les soft forks nécessitent essentiellement uniquement l'accord des mineurs/validateurs (même si les utilisateurs conservent l'ancienne règle, tant que les nœuds appliquent la nouvelle règle, seules les transactions conformes à cette dernière seront intégrées à la chaîne). En revanche, les hard forks exigent un choix actif de la part des utilisateurs.
Par ailleurs, la principale critique adressée aux hard forks est qu'elles seraient « forcées ». Ce caractère forcé ne désigne pas une contrainte physique, mais plutôt une contrainte liée à l'effet de réseau. Autrement dit, si la règle du réseau passe de A à B, même si vous préférez personnellement A, si la majorité des utilisateurs adoptent B, alors vous devez vous aussi basculer vers B pour continuer à interagir avec eux au sein du même réseau — même si vous vous y opposez.
Les partisans des hard forks sont souvent accusés de vouloir imposer un « coup de force malveillant » sur le réseau, en « forçant » les utilisateurs à suivre leur voie. De plus, le risque de scission de la chaîne est fréquemment cité comme preuve de l'insécurité des hard forks.
Selon moi, ces critiques sont profondément erronées, et dans de nombreux cas, elles vont exactement à l'encontre de la réalité. Ce point de vue ne concerne ni spécifiquement Ethereum, ni Bitcoin, ni aucune blockchain en particulier : il découle des caractéristiques générales de ces systèmes et s'applique à tous. Par ailleurs, les arguments ci-dessous concernent uniquement les changements controversés, c’est-à-dire ceux où au moins l’un des groupes (mineurs/validateurs ou utilisateurs) s’oppose majoritairement au changement. Si le changement n'est pas controversé, il peut être réalisé en toute sécurité quelle que soit la méthode de fork utilisée.
Commençons par la question de la coercition. Toute modification du protocole, qu'elle soit réalisée via une soft fork ou une hard fork, change le fonctionnement du système d'une manière qui mécontentera certains utilisateurs. En particulier, dès lors que le changement ne bénéficie pas d'un soutien unanime, il entraînera nécessairement un certain mécontentement. De plus, il est presque inévitable que, dans tous les cas, les opposants accordent plus d'importance à l'effet de réseau — rester synchronisés avec la majorité — qu'à leur propre préférence protocolaire. Ainsi, du point de vue de l'effet de réseau, les deux types de forks sont coercitifs.
Cependant, il existe une différence fondamentale entre soft fork et hard fork : la hard fork est une option à adhésion volontaire, tandis que la soft fork laisse aux utilisateurs peu ou pas de choix. Pour rejoindre une chaîne issue d'une hard fork, un utilisateur doit explicitement installer un logiciel implémentant les nouvelles règles. Si un groupe d'utilisateurs s'oppose au changement de règle plus fermement qu'il ne valorise l'effet de réseau, il peut théoriquement rester sur l'ancienne chaîne — et en pratique, cela s'est déjà produit.
Cela vaut aussi bien pour les hard forks strictement expansives que pour les hard forks bilatérales. En revanche, dans le cas d'une soft fork réussie, la chaîne non divisée n'existe tout simplement plus. Ainsi, institutionnellement parlant, les soft forks favorisent nettement la coercition plutôt que la séparation, alors que les hard forks ont une tendance inverse. Sur le plan moral, je privilégie personnellement la séparation plutôt que la coercition, bien que d'autres puissent ne pas partager cet avis (l'argument le plus courant étant que l'effet de réseau est extrêmement important, voire indispensable pour maintenir une « monnaie unique », bien que des versions plus modérées existent).
Si je devais deviner pourquoi, malgré ce qui précède, les soft forks sont encore perçues comme « moins coercitives » que les hard forks, je dirais que cela tient probablement au fait que les hard forks donnent l'impression de « forcer » les utilisateurs à installer une mise à jour logicielle, alors que dans le cas d'une soft fork, les utilisateurs n'ont « rien à faire ». Cependant, je dois insister sur le fait que cette intuition est fausse. Ce qui importe n'est pas que l'utilisateur doive ou non accomplir une simple démarche bureaucratique comme cliquer sur « télécharger », mais bien de savoir s’il est contraint d’accepter un changement de protocole qu’il ne souhaite pas. Et selon ce critère, comme indiqué ci-dessus, les deux types de forks sont finalement coercitifs, et les hard forks offrent aux utilisateurs davantage de liberté que les soft forks.
Examinons maintenant les forks très controversés, en particulier ceux où les préférences des mineurs/validateurs entrent en conflit avec celles des utilisateurs. Trois cas se présentent : (i) une hard fork bilatérale, (ii) une hard fork strictement expansive, (iii) une soi-disant « user-activated soft fork » (UASF). Une quatrième catégorie, celle d’une soft fork activée par les mineurs sans l’accord des utilisateurs, sera abordée plus tard.
Commençons par la hard fork bilatérale. Dans le meilleur des cas, la situation est très simple : les deux monnaies sont cotées sur le marché, et ce dernier détermine leur valeur relative. À partir du cas ETH/ETC, nous disposons de preuves massives indiquant que la grande majorité des mineurs allouent leur puissance de calcul en fonction du ratio des prix, afin de maximiser leurs profits, sans tenir compte de considérations historiques ou idéologiques dans leur allocation.
Même si certains mineurs ont des préférences idéologiques marquées pour l'une ou l'autre chaîne, il est fort probable que suffisamment de mineurs soient prêts à profiter des écarts entre le ratio des prix et celui de la puissance de hachage pour assurer un arbitrage, ramenant ainsi ces ratios à l'équilibre. S’il existait une coalition de mineurs refusant de miner sur l’une des chaînes, cela créerait une distorsion d’incitation problématique.
Deux cas limites doivent être mentionnés. Le premier est celui où, en raison d’un algorithme de difficulté inefficace, la valeur minière diminue lorsque la valeur de la monnaie baisse, mais la difficulté ne suit pas. Cela rend l’extraction peu rentable. Aucun mineur ne continuera à faire avancer la chaîne à perte jusqu’à ce que la difficulté se réajuste. Ce n’est pas le cas d’Ethereum, mais cela pourrait très bien l’être pour Bitcoin. Ainsi, une chaîne minoritaire en puissance de calcul risque de ne jamais décoller et de mourir. Notez que ce n’est pas forcément une bonne chose : la réponse dépend de votre position sur la coercition et la séparation. Selon mon opinion exprimée plus haut, je considère qu’un tel algorithme de difficulté hostile envers une chaîne minoritaire n’est pas souhaitable.
Le second cas limite est celui où, si l’écart est très grand, la chaîne majoritaire en puissance de calcul pourrait lancer une attaque à 51 % contre la chaîne minoritaire. Mais même avec un ratio de 10:1 comme entre ETH et ETC, une telle attaque n’a pas eu lieu. Il ne s’agit donc pas d’un résultat garanti. Toutefois, si les mineurs de la chaîne dominante préfèrent imposer leur règle et empêcher la séparation, ils trouveront toujours un moyen d’y parvenir.
Passons maintenant aux hard forks strictement expansives (SEHF). Dans un SEHF, la chaîne non divisée reste valide selon les règles de la fork, donc si la chaîne divisée a un prix inférieur, sa valeur minière sera moindre, et la chaîne non divisée finira par être acceptée comme la plus longue par les clients originaux et divisés. Progressivement, la chaîne divisée sera « submergée ».
On peut arguer qu’un tel fork présente un biais structurel fort en faveur de son succès, car la chaîne divisée, en étant submergée et dépréciée, voit son prix baisser, ce qui augmente encore les chances d’être submergée. Cet argument me paraît solide, ce qui constitue une bonne raison de préférer une hard fork bilatérale à une expansion aveugle.
De nombreux développeurs Bitcoin proposent de corriger ce problème en opérant manuellement une hard fork bilatérale après une hard fork expansive. Mais une meilleure solution consiste à intégrer directement une incompatibilité bilatérale. Par exemple, dans le cas de Bitcoin, on pourrait ajouter une règle interdisant certains opcodes inutilisés, puis réaliser sur la chaîne non divisée une transaction incluant cet opcode, rendant ainsi la chaîne non divisée définitivement invalide selon les règles de la fork. Dans le cas d’Ethereum, concernant divers détails du calcul d’état, presque toutes les hard forks sont automatiquement bilatérales. D’autres blockchains auront des propriétés différentes selon leur architecture.
Le dernier type de fork mentionné ci-dessus est la user-activated soft fork (UASF). Dans une UASF, les utilisateurs activent directement les nouvelles règles sans attendre le consensus des mineurs ; ces derniers risquent alors d’être exclus des gains économiques. Si un grand nombre d’utilisateurs n’adoptent pas la UASF, la monnaie se scinde, créant une situation similaire à celle d’un SEHF. Même si la UASF est facultative, elle exploite une asymétrie économique pour pencher la balance en sa faveur (bien que cet avantage ne soit pas absolu : si la UASF est impopulaire, elle échouera, provoquant simplement une scission).
Toutefois, la UASF est un jeu dangereux. Imaginons qu’un développeur veuille créer un correctif UASF transformant un opcode inutilisé — qui acceptait auparavant toutes les transactions — en un opcode n’acceptant que les transactions conformes à de nouvelles règles. Ce changement serait techniquement et politiquement controversé, et les mineurs n’y seraient probablement pas favorables. Ces derniers disposent d’une riposte habile : ils peuvent unilatéralement implémenter une soft fork activée par les mineurs (miner-activated soft fork), rendant systématiquement infructueuses les transactions utilisant cette nouvelle fonctionnalité.
Nous avons alors trois règles :
- La règle initiale : l'opcode X est toujours valide.
- L'opcode X n'est valide que si la transaction respecte les nouvelles règles.
- L'opcode X est toujours invalide.
Notez que la règle 2 est une soft fork par rapport à la règle 1, et que la règle 3 est une soft fork par rapport à la règle 2. Or, une forte pression économique pousse vers la règle 3, ce qui empêche la soft fork initiale d’atteindre son objectif.
En conclusion, les soft forks constituent un jeu dangereux, surtout lorsqu’elles sont controversées : dès que les mineurs ripostent, la situation devient encore plus risquée. Les hard forks strictement expansives sont également dangereuses. Les soft forks activées par les mineurs sont coercitives ; celles activées par les utilisateurs le sont moins, mais restent partiellement coercitives en raison des pressions économiques, et comportent aussi des risques. Si vous souhaitez vraiment mettre en œuvre un changement controversé et jugez que le coût social en vaut la peine, optez pour une hard fork bilatérale claire et nette, prenez le temps d’ajouter des protections contre les attaques de réexécution (replay attacks), puis laissez la main invisible du marché trancher.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@VitalikButerin
