730 / 736FOCAL

Schelling Point

Focal point, solution saillante à un problème de coordination sans arbitre central

Un Schelling Point est une solution que les personnes jugent naturellement saillante et dont elles attendent aussi le choix par les autres ; dans Bitcoin, il aide à expliquer la coordination sociale autour de règles et de logiciels communs, sans être un vote, une règle de consensus ni un substitut à la validation indépendante.

Thomas C. Schelling a développé le concept de focal point dans son livre The Strategy of Conflict de 1960 : lorsque plusieurs équilibres sont possibles et que les participants ne peuvent communiquer pleinement, ils peuvent converger vers l’option rendue la plus visible par son nom, son histoire, sa symétrie ou leurs attentes communes. Bitcoin ne supprime pas ce problème humain de coordination, mais le sépare de la vérification automatique des blocs selon les règles choisies par chaque nœud dans son logiciel.

Schelling Point est aussi couramment appelé focal point en théorie des jeux. Thomas C. Schelling l’a développé dans son livre The Strategy of Conflict de 1960, et la présentation grand public du Nobel de 2005 résume son constat expérimental : dans les tâches de coordination, les personnes trouvaient une solution commune plus souvent que ne le prévoyait le seul modèle formel, car certaines options ressortaient davantage. [1]

Le mécanisme n’exige pas que l’option retenue soit objectivement la meilleure. Un participant choisit la solution dont il pense que les autres reconnaîtront aussi la saillance, tandis qu’ils raisonnent sur cette attente. Simplicité, nom unique, histoire, symétrie, convention culturelle ou précédent public peuvent créer cette saillance. Si le contexte commun change, le focal point peut lui aussi changer. [2]

Dans Bitcoin, il faut distinguer coordination humaine et décision du protocole. Le whitepaper indique que les nœuds n’acceptent que les transactions et blocs valides et suivent, parmi les branches valides, la chaîne ayant le plus de proof of work. Un Schelling Point peut aider les personnes à converger vers un logiciel, des règles ou une procédure d’urgence, mais ne rend pas valide un bloc invalide et n’entre pas dans le calcul de chainwork. [3]

La limite de sécurité tient au choix volontaire des règles. Bitcoin Core affirme explicitement que ses développeurs ne décident pas des règles de consensus, que le logiciel ne se met pas à jour automatiquement et que les utilisateurs choisissent ce qu’ils exécutent. Une implémentation répandue, un dépôt connu ou des développeurs fiables peuvent servir de focal point pour l’examen et le déploiement, mais leur influence vient de l’adoption répétée, pas d’un droit à remplacer la validation d’un utilisateur. [4]

Un mécanisme d’activation transforme une modification déjà proposée en états déterministes, sans créer d’accord social. BIP 9 compte les signaux par périodes de 2016 blocs et passe à LOCKED_IN au seuil initial d’au moins 1916 blocs ; BIP 8 emploie des hauteurs de bloc, une hauteur minimale d’activation et un état MUST_SIGNAL facultatif. Le choix de la proposition, des paramètres et de la version logicielle intervient avant et peut rester contesté. [6] [5]

La saillance ne prouve ni vérité ni légitimité. Le ticker d’une plateforme, la part de hashrate, le nombre de nœuds visibles par un crawler, la marque d’un client ou un sondage social mesurent des groupes différents et peuvent être manipulés ou mal interprétés. Bitcoin Core rappelle que les utilisateurs peuvent exécuter un logiciel pleinement validant ou autre et fixer leur propre relay policy ; aucune métrique unique ne constitue donc un vote contraignant de tout le réseau. [7]

La scission de mars 2013 montre la différence entre sélection automatique d’une branche et coordination humaine d’urgence. Environ 60% du hashrate minait d’abord la branche acceptée par la version 0.8, de sorte que la scission ne s’est pas rapidement résolue seule. Après coordination publique, BTC Guild et Slush sont passés à 0.7, des services commerciaux ont suspendu les dépôts et la majorité du travail s’est déplacée vers la branche compatible. C’était une réponse précise à un incident, pas une règle permanente autorisant des personnes connues à choisir la chaîne. [8]

Une affirmation sur un Schelling Point n’est vérifiable qu’après définition du jeu : qui participe, quelles options existent, que cherche-t-on à coordonner, quelles informations et communications sont disponibles et comment reconnaître le résultat. Pour une proposition Bitcoin, il faut en outre distinguer le texte du BIP, le code exact, les règles de validation, les paramètres d’activation, la compatibilité et le déploiement observé. Le statut Complete ou Deployed du processus BIP a un sens défini, mais ne constitue pas un sondage de tous les détenteurs de bitcoin. [9]

Pour une vision complète, lisez aussi Bitcoin, Règles de consensus, Nakamoto Consensus, Full Node, Proof of Work, Soft Fork Activation.

01Le client Bitcoin le plus utilisé est-il automatiquement un Schelling Point pour les règles du réseau ?

Il peut constituer un focal point fort pour l’examen du code, l’interopérabilité et les attentes, mais sa popularité ne donne pas à ses développeurs le droit de changer les règles des utilisateurs. Chaque nœud pleinement validant applique les règles du logiciel exécuté. En cas de modification incompatible, des groupes peuvent poursuivre sur des réseaux différents même si une implémentation dominait auparavant.

02La signalisation des mineurs est-elle un vote sur ce qu’est Bitcoin ?

Non. Elle n’a de sens que dans un mécanisme d’activation précis et indique la préparation du mineur ou le bit exigé par ses règles. Elle n’inclut pas tous les utilisateurs, détenteurs, commerçants ou nœuds et ne détermine pas leur logiciel. C’est un signal de coordination, pas un vote universel de propriétaires.

DOC · 001Nobel Prize — Thomas Schelling and focal pointsDocumentation DOC · 002Roger Myerson — Learning from Schelling’s Strategy of ConflictDocumentation DOC · 003Satoshi Nakamoto — Bitcoin: A Peer-to-Peer Electronic Cash SystemDocumentation DOC · 004Bitcoin Core — Statement from Bitcoin Core (2016)Documentation DOC · 005BIP 9 — Version bits with timeout and delayDocumentation DOC · 006BIP 8 — Version bits with lock-in by heightDocumentation DOC · 007Bitcoin Core — Development and transaction relay policyDocumentation DOC · 008BIP 50 — March 2013 Chain Fork Post-MortemDocumentation DOC · 009BIP 3 — Updated BIP ProcessDocumentation
Révisé le: Sources d’abord · Pas un conseil financier