Blocs, guerres et controverses



  • Marek Palatinus, fondateur de Slushpool et Trezor, nous livre son point de vue sur le débat qui fait rage au sein de la communauté Bitcoin à propos de la limitation de la taille des blocs. Billet publié initialement sur le blog Medium de l’intéressé.

    Je n’ai pas commenté le débat autour de la taille des blocs jusqu’à présent et il y a plusieurs raisons à cela. La première est assez claire : les opinions ont été dites et les camps ont été choisis. Aussi, je sens que cette discussion devient si irrationnelle que tout ce que vous dites peut et sera utilisé contre vous à un moment donné. La dernière raison? Ma propre opinion n’a de toute façon pas un si grand poids.

    En effet, je possède une pool de mineurs (Slushpool), mais notre philosophie est de rester neutre et notre intérêt principal est d’offrir aux mineurs la meilleure infrastructure possible. Le seul hashrate que je contrôle à titre personnel est là :

    mineur slushpoolMon seul mineur de hachage à 300MH/s, utilisé pour des tests SlushPool :-).

    Pourtant, les gens me demandent quel côté ai-je pris. En ce moment, je dois souligner que tout ce qui est écrit dans cet article est mon opinion personnelle au moment de cette publication. Ce n’est pas une déclaration de SatoshiLabs ou SlushPool (qui reste strictement neutre et laisse aux utilisateurs le droit de se faire leur propre avis, même s’ils tranchent pour les propositions que je ne soutiens pas). Ok, voyons tout cela :

    Je suis pour élever la limite de la taille des blocs (peut-être même, l’enlever complètement). Pourtant, en ce moment, je suis avec les développeurs de chez Core.

    Laissez-moi vous expliquer pourquoi.

    Avons-nous besoin d’une limite de taille des blocs ?

    Quelle que soit la nécessité de l’augmentation de la taille des blocs, la limite a été introduite à titre de précaution pour les potentielles attaques DdoS sur le réseau. Lorsque Satoshi a introduit la limite en 2010, il a eu une décision très intelligente. Mais maintenant, nous avons des années d’expérience avec la gestion du réseau Bitcoin et il y a des moyens d’améliorer la validation des transactions afin de réduire de telles attaques. Après la suppression de ces vecteurs d’attaque, je ne pense pas qu’il sera nécessaire de maintenir une taille limitée pour les blocs.

    Retrait de la taille limite des blocs

    Bien sûr, les nœuds Bitcoin auraient également besoin d’autres mises à jour pour abaisser le taux de « stale block » (blocs exploités, mais pas encore inclus sur la Blockchain), mais il y a beaucoup de propositions simples comme « Thin Blocks », qui améliorent la propagation de bloc et réduisent le temps de latence pour les mineurs et sans frais supplémentaires. La principale raison pour laquelle ces optimisations ne sont pas encore largement déployées est que personne n’a besoin d’elles avec une limite de 1MB.

    En réparant ces erreurs évidentes sur le protocole P2P (qui nécessite une simple mise à jour logicielle, et pas même un soft fork) et en supprimant complètement la taille des blocs, le libre marché créerait un équilibre entre les frais de transaction (incitation aux mineurs à produire de plus grands blocs) et le taux de « stale blocks » (incitation aux mineurs à produire des blocs plus petits). Comme n’importe qu’elle autre approche du libre marché, cela induit toujours des incertitudes vis-à-vis des perspectives à court terme, mais cela fonctionnerait parfaitement dans une perspective à long terme. Gavin Andresen mène aussi des recherches intensives sur le sujet et j’apprécie toutes ses contributions au débat en général.

    Même si la suppression de la limite est techniquement possible et que je ne partage pas les visions désastreuses à ce sujet, je comprends parfaitement que l’enlever complètement (ou l’augmenter de façon exponentielle, comme la proposition BIP101) est fondamentalement impossible pour des raisons politiques à ce jour. Donc, si nous voulons garder les pieds sur terre et trouver un véritable consensus, considérons cette solution comme inutile (saluons Mike Hearn).

    Augmenter la limite de la taille des blocs

    Compromis le plus sûr entre la suppression de la limite et le statu quo. Bitcoin Classique, Bitcoin Unlimited, BIP100 et SegWit. Quatre des propositions les plus populaires.

    En premier lieu, SegWit est une proposition non-hardfork qui permet de réparer quelques bizarreries dans le protocole et qui doivent être réparées pour la scalabilité à long terme de la Blockchain. Cependant, j’apprécie cette solution surtout pour une autre raison, et je ne la vois pas avoir un impact immédiat les blocs. Il faudrait des changements majeurs au niveau des portefeuilles Bitcoin pour avoir au moins un petit effet.

    **BIP100 **suggère une sorte de limite flottante, qui introduit un tout nouveau type d’incertitude dans le modèle économique du réseau Bitcoin. Une attaque des 21% suffirait à garder la taille des blocs artificiellement petite (n’hésitez pas à me reprendre, si cela a été corrigé récemment). En outre, il n’y a pas encore eu de mise en application. Bien que j’apprécie beaucoup les idées de Jeff autour du débat, jusqu’à présent cela ressemble plus à des recherches faites maison qu’à une solution sérieuse.

    Bitcoin Unlimited introduit le concept « limites strictes définies par l’utilisateur », essentiellement en essayant un libre marché de la taille des blocs. Bien qu’ayant un niveau de motivation élevée et malgré leur travail récent sur Xtreme Thinblocks, j’y vois quelques problèmes techniques. Si je comprends bien la proposition, les petits noeuds pouvant fixer une taille de bloc basse, cela pourrait conduire à une situation où des blocs produits par les gros mineurs deviendraient invisibles pour les petits, et donc conduire à une division du réseau. Je préfère supprimer la limite explicitement et simplifier le code. Quoi qu’il en soit, cette solution est politiquement morte pour la même raison que ma solution préférée décrite un peu plus haut.

    Bitcoin Classic semble être la proposition la plus populaire ces jours-ci. Sur l’ensemble des alternatives, cette proposition d’un hardfork pour une taille de 2MB, est la plus conservatrice. En outre, ils n’ont pas essayé d’introduire un nouveau mécanisme, ce qui me plaît. Cependant, même pour élever la limite à 2MB, nous avons besoin de mettre en œuvre un hard fork. Est-ce qu’un hard fork est justifiable pour une solution si temporaire ? Ce qui me conduit à la question suivante:

    Avons-nous besoin d’augmenter la limite de taille des blocs maintenant ?

    Je veux dire, élever ou même supprimer la limite de la taille des blocs est techniquement faisable aujourd’hui, mais est-ce vraiment nécessaire dans la situation actuelle ? Est-ce LA solution aux problèmes actuels de Bitcoin ?

    C’est le moment où le sujet devient plus philosophique que technique : quel est le but de Bitcoin? Est-ce un réseau de paiement? Est-ce comme de l’or numérique ? Les réponses à ces questions sont très subjectives et le résultat à ces mêmes questions est théorique : quel est le vrai mérite de Bitcoin ? Avoir de faibles frais ou le fait que ses règles ne peuvent pas être modifiées facilement ? Et qui est responsable de telles décisions ? Peter « sipa » Wuille, est l’auteur du concept de SegWit et mon développeur Core favori, explique pourquoi il est contre les changements faciles sur le protocole. Bien que je ne partage pas toutes ses préoccupations, il faut dire que :

    Bitcoin, avec une limite de 1MB, n’est pas cassé. Il ne peut tout simplement pas rivaliser avec VISA.

    Mais il peut encore rivaliser avec l’or. Quoi qu’il en soit, j’aime la comparaison de Bitcoin à un rouleau de papier dans des toilettes publiques (légèrement reformulée à partir l’interview de Samson Mow) :

    Si quelqu’un pille tout le papier des toilettes de la toilette publique, la solution est-elle de doubler la quantité de papier à remettre chaque jour?

    Bien que le taux de transaction sur le réseau Bitcoin est en hausse, ce qui est généralement une bonne chose, je suis convaincu que beaucoup de ces transactions ne sont que des spams en soi et beaucoup d’autres transactions sont juste dues à des pique-assiettes.

    Par pique-assiette, je veux dire, utilisation de la Blockchain par des services tels que la célèbre roulette SatoshiDice. Ils ont profité du fait que les transactions étaient gratuites ou pas chères, compte tenu des coûts réels de fonctionnement du réseau Bitcoin à une échelle donnée.

    Le seul fait de doubler ou quadrupler la limite des blocs ne serait pas utile, et une hausse des frais de transaction entraînés par la demande de transactions de plus grande valeur sur le marché a fait le travail. Juste pour le rappel, à l’époque, les transactions étaient tout à fait gratuites. Aujourd’hui, il est normal de payer 4 cents ou plus. Cela nuit-il à Bitcoin de façon significative? Très probablement pas, à l’exception du fait que certains services ont du optimiser leur business modèle

    En fin de compte, je ne partage pas les préoccupations qui disent que le remplissage des blocs est un gros problème. D’un point de vue économique, il est naturel d’occuper des ressources partagées tant qu’elles sont gratuites ou pas cher. Comme la ressource est remplie, il y a une pression du libre marché qui l’a rend plus cher, et maintien l’équilibre entre les pique-assiettes et les transactions réellement importantes sur Blockchain. Avec une limite stricte de la taille des blocs le phénomène se produit plus tôt qu’avec des blocs illimités, mais reste de toute façon inévitable. Donc, ma réponse à la question qui consiste savoir si oui ou non il faut un hard fork : Ce serait bien, mais ce n’est pas encore nécessaire.

    Le principal problème de ces jours-ci est qu’il n’y a pas une bonne infrastructure pour déterminer les frais suffisants ou frais dynamiques pour les transactions. Cependant, Bitcoin Core en est conscient, et ils ont fait de gros progrès : CPFP (Child Pay For Parent) en développement, RBF (Replace By Fee) a déjà été intégré dans Bitcoin Core 0.12.

    Donc, vous êtes une marionnette de Blockstream ?

    Hum, ces théories du complot et les discussions surchauffées aux accusations personnelles nuisent à Bitcoin bien pire que la question de la taille des blocs elle-même. Je n’ai actuellement que pour seule motivation le fait que Bitcoin soit couronnée de succès (quelle que soit la solution trouvée). Bien qu’il existe différentes propositions et que je pense qu’il serait bien de faire quelque chose, je ne pense vraiment pas que l’équipe de Core tente de détruire Bitcoin.

    Le plus gros problème avec les développeurs de Core est qu’ils sont très intelligents, mais beaucoup d’entre eux manquent de souplesses ou ne ressentent pas l’envie de communiquer avec la communauté. J’ai plusieurs fois été frustré en communiquant avec certains et je me suis déjà exprimé à ce sujet. Leurs compétences peuvent conduire à des catastrophes en terme de relation publique et à quelques spéculations sauvages. Cependant, cela change ces dernières semaines et Core fait face à la concurrence croissante venant des autres forks. J’ai remarqué qu’ils rejettent lentement leur attitude arrogante et tentent d’expliquer leurs intentions plus clairement, même pour à une communauté plus large. Ceci, combiné avec leurs excellentes connaissances en matière de cryptographie et de programmation, est la raison pour laquelle je veux leur donner une chance de plus.

    Avertissement

    Le débat autour de la taille des blocs est vraiment compliqué et a beaucoup de conséquences économiques, politiques et techniques. Je ne cherche pas à tout expliquer dans le détail, mais plutôt à donner des pensées subjectives sur le sujet. Je recommande fortement de lire plus de ressources de Gavin, Sipa et Jeff. Ils ont passé une quantité folle de temps sur le sujet et ils fournissent des idées calmes, factuelles et de haute qualité. Parmi les non-développeurs, je recommande de lire les articles d’Aaron Van Wirdum de Bitcoin Magazine, qui tente de donner une vue impartiale sur le débat.

    Cet article Blocs, guerres et controverses est issue du site Le Coin Coin.