730 / 736FOCAL

Schelling Point

Focal point, solución destacada a un problema de coordinación sin árbitro central

Un Schelling Point es una solución que las personas consideran naturalmente destacada y esperan que los demás también elijan; en Bitcoin ayuda a explicar la coordinación social en torno a reglas y software comunes, pero no es una votación, una regla de consenso ni un sustituto de la validación independiente.

Thomas C. Schelling desarrolló el concepto de focal point en su libro The Strategy of Conflict de 1960: cuando existen varios equilibrios posibles y los participantes no pueden comunicarse plenamente, pueden converger en la opción más visible por su nombre, historia, simetría o expectativas compartidas. Bitcoin no elimina este problema humano de coordinación, pero lo separa de la verificación automática de bloques según las reglas que cada nodo eligió en su software.

Schelling Point también se denomina habitualmente focal point en teoría de juegos. Thomas C. Schelling lo desarrolló en su libro The Strategy of Conflict de 1960, y la explicación divulgativa del Nobel de 2005 resume su hallazgo experimental: en tareas de coordinación, las personas alcanzaban una solución común más a menudo de lo previsto por el modelo formal porque unas opciones destacaban más que otras. [1]

El mecanismo no exige que la opción elegida sea objetivamente la mejor. Cada participante escoge la solución que espera que los demás reconozcan como destacada, mientras ellos también razonan sobre esa expectativa. La sencillez, un nombre único, la historia, la simetría, una costumbre cultural o un precedente público pueden crear prominencia. Si cambia el contexto compartido, también puede cambiar el focal point. [2]

En Bitcoin hay que separar la coordinación humana de una decisión del protocolo. El whitepaper establece que los nodos solo aceptan transacciones y bloques válidos y que, entre ramas válidas, siguen la cadena con mayor proof of work. Un Schelling Point puede ayudar a converger en software, reglas o un procedimiento de emergencia, pero no convierte en válido un bloque inválido ni forma parte del cálculo de chainwork. [3]

El límite de seguridad está en la elección voluntaria de reglas. Bitcoin Core afirma expresamente que sus desarrolladores no deciden las reglas de consenso, que el software no se actualiza automáticamente y que los usuarios eligen qué ejecutar. Una implementación extendida, un repositorio conocido o desarrolladores fiables pueden actuar como focal point para revisión y despliegue, pero su influencia procede de la adopción repetida, no de un derecho a anular la validación del usuario. [4]

Un mecanismo de activación convierte un cambio ya propuesto en estados deterministas, pero no crea acuerdo social. BIP 9 cuenta la señalización en períodos de 2016 bloques y, con su umbral original de al menos 1916 bloques, pasa a LOCKED_IN; BIP 8 usa alturas de bloque, una altura mínima de activación y un estado MUST_SIGNAL opcional. La elección de propuesta, parámetros y versión de software ocurre antes y puede seguir siendo discutida. [6] [5]

La prominencia no demuestra verdad ni legitimidad. El ticker de una bolsa, la cuota de hashrate, el número de nodos visibles para un crawler, la marca del cliente o una encuesta social miden grupos distintos y pueden manipularse o interpretarse mal. Bitcoin Core recuerda que los usuarios pueden ejecutar software plenamente validador u otro y fijar su propia relay policy; ninguna métrica aislada es una votación vinculante de toda la red. [7]

La división de marzo de 2013 muestra la diferencia entre la selección automática de rama y la coordinación humana de emergencia. Cerca del 60% del hashrate minaba inicialmente la rama aceptada por la versión 0.8, por lo que la división no se resolvió rápidamente sola. Tras coordinarse públicamente, BTC Guild y Slush pasaron a 0.7, servicios comerciales suspendieron depósitos y la mayoría de trabajo se desplazó a la rama compatible. Fue una respuesta concreta al incidente, no una regla permanente que permita a personas conocidas elegir la cadena. [8]

Una afirmación sobre un Schelling Point solo puede comprobarse tras definir el juego: quién participa, qué opciones tiene, qué busca coordinar, de qué información y comunicación dispone y cómo se reconocerá el resultado. En una propuesta Bitcoin hay que indicar aparte el texto BIP, código exacto, reglas de validación, parámetros de activación, compatibilidad y despliegue observado. El estado Complete o Deployed del proceso BIP tiene un significado definido, pero no es una encuesta a todos los tenedores de bitcoin. [9]

Para obtener la imagen más completa, lee esta entrada junto con Bitcoin, Reglas de consenso, Nakamoto Consensus, Full Node, Proof of Work, Soft Fork Activation.

01¿El cliente Bitcoin más usado es automáticamente un Schelling Point para las reglas de la red?

Puede ser un focal point fuerte para revisar código, interoperar y formar expectativas, pero su popularidad no da a sus desarrolladores derecho a cambiar las reglas de los usuarios. Cada nodo plenamente validador aplica las reglas del software que ejecuta. Ante un cambio incompatible, distintos grupos pueden continuar en redes distintas aunque antes dominara una implementación.

02¿La señalización de mineros es una votación sobre qué es Bitcoin?

No. Solo tiene significado dentro de un mecanismo de activación concreto y muestra preparación del minero o el bit exigido por sus reglas. No incluye a todos los usuarios, tenedores, comercios o nodos ni determina qué software ejecutan. Es una señal de coordinación, no una votación universal de propietarios.

DOC · 001Nobel Prize — Thomas Schelling and focal pointsDocumentación DOC · 002Roger Myerson — Learning from Schelling’s Strategy of ConflictDocumentación DOC · 003Satoshi Nakamoto — Bitcoin: A Peer-to-Peer Electronic Cash SystemDocumentación DOC · 004Bitcoin Core — Statement from Bitcoin Core (2016)Documentación DOC · 005BIP 9 — Version bits with timeout and delayDocumentación DOC · 006BIP 8 — Version bits with lock-in by heightDocumentación DOC · 007Bitcoin Core — Development and transaction relay policyDocumentación DOC · 008BIP 50 — March 2013 Chain Fork Post-MortemDocumentación DOC · 009BIP 3 — Updated BIP ProcessDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero