Introducción\n\nEn un pool de minería de Bitcoin centralizado convencional, el operador normalmente selecciona las transacciones, contabiliza el trabajo de los mineros y administra los pagos. Los enfoques descentralizados pueden trasladar la selección de transacciones a los mineros, mientras que los diseños peer-to-peer como P2Pool también distribuyen la coordinación de las recompensas. Para los mineros, los cambios prácticos dependen de qué funciones se trasladen: tener más control sobre la plantilla (template) no significa automáticamente comisiones más bajas, menor varianza en los pagos o pagos no custodiales, y operar infraestructura de minería local añade responsabilidad operativa adicional.\n\nPor lo tanto, la distinción no es binaria. Este artículo separa las funciones que realiza un pool y compara las plantillas seleccionadas por el minero con un diseño de pool peer-to-peer.\n\n## Por qué los mineros se unen a los pools\n\nLa documentación para desarrolladores de Bitcoin describe la minería en pool como un mecanismo para recibir pagos más pequeños y frecuentes, con menor varianza que la minería en solitario, ya que los mineros envían shares que demuestran trabajo parcial incluso cuando no encuentran un bloque completo. Un share válido cumple con el objetivo (target) propio del pool; no necesariamente satisface el objetivo de bloque de la red Bitcoin. Los pools establecen su objetivo de share en un valor más fácil (numéricamente más alto) que el objetivo de la red, específicamente para que los mineros generen shares con la frecuencia suficiente como para ser medidos y compensados, aunque los bloques reales sean poco frecuentes. (developer.bitcoin.org)\n\nEs esta distinción —share frente a bloque— la que subyace a la mayor parte de la confusión sobre el «control» del pool. Un pool no decide si un bloque es válido según las reglas de consenso de Bitcoin; decide hacia qué bloque candidato trabaja su hashrate (poder de cómputo) y cómo se convierten los shares aportados en un reparto de recompensa.\n\n## Cuatro funciones agrupadas dentro de un pool convencional\n\nUna configuración típica de pool combina cuatro responsabilidades separadas:\n\n1. Construcción de la plantilla de bloque (block-template) — seleccionar qué transacciones entran en el bloque candidato y ensamblar el encabezado del bloque contra el cual los mineros realizan el hash.\n2. Validación de shares y contabilidad de recompensas — recibir los shares enviados, verificar que cumplen el objetivo del pool y calcular la contribución de cada participante según la fórmula de pago del pool.\n3. Administración de pagos — acreditar saldos y procesar retiros conforme a las reglas de liquidación del pool.\n4. Infraestructura de minería — operar endpoints Stratum, proxies, monitorización y sistemas de conmutación por error (failover) que mantienen el hashrate conectado.\n\nEn un pool Stratum v1 convencional, el pool normalmente controla las cuatro. La documentación para desarrolladores de Bitcoin señala que, a diferencia del RPC getblocktemplate, los mineros que utilizan el Stratum estándar no pueden inspeccionar ni añadir transacciones al bloque que están minando: el pool suministra el trabajo (job), y el hardware del minero simplemente busca un nonce válido para ese trabajo. (developer.bitcoin.org)\n\n## Qué cambian realmente los modelos de pool descentralizados\n\nAlgunos enfoques descentralizan la construcción de la plantilla de bloque dejando la contabilidad de recompensas y los pagos en manos de un operador. Otros distribuyen también la coordinación de los shares y las recompensas. Se trata de cambios distintos para los mineros.\n\nStratum V2 Job Declaration Protocol (JDP). Bajo esta especificación, un minero o una granja de minería puede ejecutar un Job Declarator Client que recibe una plantilla candidata de un Template Provider, normalmente un nodo de Bitcoin Core ejecutado localmente, y declara ese trabajo personalizado a un Job Declarator Server del lado del pool. El pool puede seguir validando los shares y distribuyendo las recompensas bajo sus reglas de pago existentes. Este diseño permite que un cliente a nivel de granja sirva a muchos ASIC río abajo sin que cada dispositivo necesite ejecutar su propio nodo. (stratumprotocol.org)\n\nDATUM. Esta implementación traslada la construcción de la plantilla y el envío de bloques a una puerta de enlace (gateway) operada por el minero y emparejada con el propio nodo de Bitcoin del minero, mientras que un pool compatible con DATUM sigue coordinando la distribución de recompensas. Según el repositorio oficial del proyecto, el minero conserva la selección de transacciones, pero el trabajo del pool aún debe satisfacer los requisitos de contabilidad del pool, incluidas las salidas específicas de la transacción de generación (generation-transaction) necesarias para el reparto de recompensas. El repositorio describe actualmente el software como beta pública, lo cual es una limitación relevante para cualquier minero que evalúe su uso en producción. (github.com)\n\nP2Pool. Este diseño peer-to-peer va más allá de las plantillas seleccionadas por el minero. Los nodos mantienen una cadena compartida de shares de prueba de trabajo, conocida como sharechain, y verifican que el trabajo propuesto incluye los pagos requeridos. Cuando se encuentra un bloque de Bitcoin, su transacción coinbase paga a los mineros participantes según las reglas de recompensa de la sharechain, en lugar de depender de un operador central que acredite saldos y procese retiros. Ejecutar un nodo P2Pool local también requiere un nodo de Bitcoin. Esto cambia la coordinación de recompensas y la vía de pago, además de la construcción de la plantilla; no garantiza una baja varianza en los pagos. (documentación del proyecto P2Pool, repositorio de P2Pool)\n\n## Qué no cambia automáticamente\n\nQue un minero obtenga control sobre las plantillas de bloque no implica automáticamente:\n\n- comisiones más bajas del pool;\n- una vía de pago no custodial;\n- menor varianza en los pagos;\n- la eliminación del pool como contraparte en la contabilidad de recompensas;\n- menor responsabilidad operativa.\n\nUn pool de soporte puede seguir exigiendo salidas coinbase específicas, hacer cumplir las reglas de la plantilla, validar cada share enviado y operar el sistema de liquidación exactamente igual que antes. La contabilidad de recompensas y la administración de pagos son decisiones de producto separadas del control de la plantilla, y un minero no debe asumir que adoptar un método de conexión con plantilla descentralizada cambia cómo o cuándo se pagan las recompensas.
Las reglas de pago en BTC publicadas por ViaBTC ilustran esta separación. El método PPS+ aplica la lógica PPS al componente de recompensa de bloque y la lógica PPLNS al componente de comisiones de transacción, cada uno con una tarifa diferente; el método PPLNS aplica la lógica PPLNS a ambos componentes. Según el cálculo PPLNS de ViaBTC, la parte de recompensa de un minero se basa en las shares (participaciones) aportadas durante las últimas cinco rondas de dificultad, y la liquidación se produce después de que el bloque encontrado por el pool alcanza seis confirmaciones. Estas son políticas específicas de ViaBTC, no reglas universales del protocolo, y ninguna de ellas describe quién construye la plantilla de bloque (block template); eso es una cuestión de arquitectura de conexión, independiente del método de pago elegido. (support.viabtc.com)
Una comparación práctica
La columna de P2Pool describe la participación a través de un nodo operado por el minero.
| Área de decisión | Pool convencional | Pool con plantillas seleccionadas por el minero | Diseño P2Pool entre pares (peer-to-peer) |
|---|---|---|---|
| Construcción de la plantilla de bloque | Del lado del pool | Del lado del minero o de la granja, mediante un nodo local o un proveedor de plantillas | Nodo local |
| Política de selección de transacciones | Sigue la política del pool | Puede seguir el nodo propio del minero y su política, dentro de los requisitos del pool | Sigue la política del nodo local, sujeta a trabajo válido en la sharechain |
| Validación de shares | Del lado del pool | Normalmente sigue siendo del lado del pool | Validación local y verificación entre pares de las shares de la sharechain |
| Contabilidad de recompensas | Del lado del pool | A menudo sigue siendo del lado del pool | Distribuida mediante las reglas de la sharechain |
| Administración de pagos | El pool acredita saldos y procesa retiros | Puede seguir siendo del lado del pool; depende del pool | Las recompensas se pagan mediante la transacción coinbase del bloque encontrado |
| Envío del bloque | Normalmente del lado del pool | Puede enviarse a través del propio nodo del minero | A través de un nodo participante |
| Complejidad operativa | Menor para el minero | Mayor: nodo, gateway/proxy, monitorización y compatibilidad de software | Nodo de Bitcoin, software P2Pool y conectividad entre pares a mantener |
La conclusión práctica es que el diseño del pago y el control de la plantilla son decisiones independientes. Un minero puede seleccionar un método de pago en función de la estructura de comisiones y su tolerancia a la varianza, mientras evalúa por separado si un pool admite plantillas seleccionadas por el minero, y si la carga operativa adicional —ejecutar un nodo, un gateway y monitorizar esa conexión— vale la pena para su operación.
La atribución de pools no establece el control de la plantilla
Los datos de atribución de pools describen cómo se asignan los bloques encontrados a los pools. Por sí solos, no identifican quién seleccionó las transacciones en cada bloque, quién posee los ASICs, ni quién controla de forma permanente el hashrate que contribuye.
Esta distinción importa cuando los mineros construyen sus propias plantillas mientras participan en el sistema de recompensas de un pool. DATUM, por ejemplo, mantiene la construcción de la plantilla en el nodo del minero, al tiempo que requiere información de pago proporcionada por el pool y una etiqueta coinbase principal. Por lo tanto, un bloque asociado a un pool puede contener transacciones seleccionadas por un minero. (documentación de DATUM Gateway)
Para evaluar la concentración del control de plantillas, los datos de atribución de bloques necesitarían evidencia adicional sobre cómo se construyeron las plantillas de esos bloques. Las clasificaciones de pools por sí solas no pueden establecer esa concentración.
Cómo evaluar un pool
Los mineros que comparan opciones de pools pueden considerar útil separar la evaluación en preguntas distintas, en lugar de tratar "centralizado frente a descentralizado" como una única etiqueta:
- Método de recompensa y comisiones. ¿El pool usa PPS, PPS+, PPLNS u otro método, y qué comisión se aplica a cada componente de recompensa?
- Condiciones de liquidación. ¿Qué requisitos de confirmación y ventanas de retrospección (lookback) se aplican antes de que las shares se conviertan en saldo acreditado?
- Arquitectura de conexión. ¿El endpoint específico del pool admite plantillas seleccionadas por el minero mediante Stratum V2 Job Declaration o un mecanismo equivalente, y qué software o hardware adicional se requiere? El soporte de Stratum V2 por sí solo no garantiza plantillas seleccionadas por el minero: una implementación puede usar únicamente el Mining Protocol sin selección de transacciones. (especificación de Stratum V2)
- Soporte operativo. ¿Qué enrutamiento de respaldo (failover), monitorización e historial de tiempo de actividad ofrece el pool para sus endpoints Stratum estándar?
- Controles de seguridad. ¿Qué protecciones a nivel de cuenta —autenticación de dos factores, lista blanca de direcciones de retiro, permisos de claves API— están disponibles para proteger la administración de pagos de forma independiente al control de la plantilla?
Ninguna de estas preguntas se responde simplemente sabiendo si un pool se anuncia a sí mismo como descentralizado.
Conclusión
La descentralización en los pools de minería de Bitcoin se entiende mejor como la desagregación de funciones que los pools convencionales han combinado históricamente, en lugar de como una única etiqueta de sí o no aplicada a todo el pool. Protocolos como Stratum V2 Job Declaration e implementaciones como DATUM ofrecen a los mineros una vía documentada para construir sus propias plantillas de bloque mientras siguen participando en la distribución conjunta de recompensas. P2Pool va más allá al distribuir la coordinación de shares e incorporar los pagos de recompensa en los bloques encontrados. Estas diferencias no pueden establecerse únicamente a partir de las clasificaciones de atribución de pools. El control de la plantilla, por sí solo, no determina las comisiones del pool, la varianza de los pagos ni la custodia de los fondos, y operar nodos y gateways locales añade responsabilidades para mantener fiables las conexiones de minería. Los mineros que evalúan un pool deben considerar el control de la plantilla, la contabilidad de recompensas, la administración de pagos y el soporte de infraestructura como cuatro decisiones separadas, cada una evaluada según sus propios méritos.
Preguntas frecuentes
¿Un pool descentralizado significa que conservo la custodia de mi propio Bitcoin?
No necesariamente. Los modelos de decentralización de plantillas, como Stratum V2 Job Declaration y DATUM, normalmente siguen dependiendo de un pool para la validación de shares y la contabilidad de recompensas, y la administración de los pagos —incluyendo si los fondos son custodiados hasta el retiro— depende de las reglas específicas de ese pool, no de quién construye la plantilla del bloque.
¿Elegir un pool con plantillas seleccionadas por el minero reduce la varianza de los pagos?
No. La varianza de los pagos está determinada principalmente por el método de contabilidad de recompensas (por ejemplo, PPS+ frente a PPLNS) y por el tamaño del pool, no por quién construye la plantilla candidata del bloque. Estas son decisiones de diseño independientes.
¿Es un share lo mismo que un bloque de Bitcoin?
No. Un share demuestra trabajo frente al objetivo de share, más sencillo, del pool, y se utiliza para la contabilidad de recompensas. Solo se convierte en un bloque válido de la red en el raro caso de que también satisfaga el objetivo de la red Bitcoin, mucho más difícil.
¿Necesito ejecutar mi propio nodo de Bitcoin para usar un modelo de pool con decentralización de plantillas?
Depende de la implementación. La documentación actual de DATUM exige que el minero opere un nodo de Bitcoin y una gateway compatibles. Stratum V2 Job Declaration puede implementarse a nivel de granja de minería, donde un Job Declarator Client y un proveedor de plantillas atienden a múltiples dispositivos de minería subordinados.