Slush Pool: una idea praguesa contra la lotería minera

En ese momento, Bitcoin recompensaba al ganador del bloque con cincuenta monedas. Para la red, era un mecanismo simple, pero para los individuos, era una lotería dura. La probabilidad de encontrar un bloque correspondía a la proporción de su rendimiento de hash en toda la red. A medida que el rendimiento total aumentaba, un minero pequeño podía esperar durante más tiempo, a pesar de que su máquina funcionara sin parar.

El promedio a largo plazo podía parecer favorable, pero las facturas de electricidad llegaban cada mes. Un individuo necesitaba soportar una gran variabilidad: o ganaba la recompensa completa, o no ganaba nada durante un período largo. Esto expulsaba a las personas con menor rendimiento, aunque su trabajo fuera igual de útil para la red que el de una operación grande.

Palatinus conocía el problema por experiencia propia. En el foro, describió cómo un servidor común podía unir miles de intentos pequeños y dividir los resultados. Un participante ya no tendría que esperar su raro éxito; recibiría una pequeña parte cada vez que se minara un bloque en el grupo.

El grupo de minería no cambia la probabilidad del grupo en su conjunto ni crea más bitcoins. Cambia la distribución del riesgo en el tiempo. Es la diferencia entre un sorteo con un gran premio y una parte regular de un gran lote de sorteos. A cambio de una renta más estable, el minero paga una tarifa y depende de la contabilidad correcta del operador.

Slush no presentó su propuesta como una victoria técnica pura. Ya en el primer hilo, enumeró las ventajas, desventajas y la confianza necesaria. El servidor debía medir el trabajo realizado de manera correcta, no robar recompensas y permanecer accesible. El grupo eliminaba una incertidumbre, pero agregaba un intermediario que el consenso de Bitcoin no controlaba.

Para un pequeño minero, el mayor problema no era el rendimiento medio, sino el tiempo. Estadísticamente podía tener derecho a una fracción de la recompensa cada día, pero el protocolo real no pagaba fracciones por el esfuerzo. O bien su máquina encontraba un bloque válido y obtenía cincuenta bitcoins enteros, o no obtenía nada. Una larga serie de fracasos no significaba que el equipo no estuviera funcionando; solo significaba que la lotería aún no había caído a su favor. Un servidor común convertía este evento irregular en participaciones más pequeñas según el trabajo demostrado. El pool no aumentaba el número esperado de bloques encontrados, sino que cambiaba el ritmo de los ingresos, y era precisamente esa diferencia la que podía determinar si una persona podía permitirse seguir minando.

El anuncio del 27 de noviembre de 2010 no fue un producto empresarial terminado. Palatinus buscaba personas dispuestas a probar el protocolo, la conexión y el método de recompensa. El sistema debía aceptar pruebas parciales de trabajo — resultados demasiado débiles para un bloque válido, pero suficientes para demostrar que el minero realmente estaba calculando.

Estos resultados parciales, llamados shares, permitían al pool estimar la contribución de cada máquina. Cuando un participante encontraba un hash que cumplía la dificultad de toda la red, el pool recibía la recompensa del bloque y la repartía según la regla contable elegida. Para un minero corriente, aquello suponía pasar de recibir cincuenta bitcoins de forma irregular a cobrar cantidades más pequeñas con mayor frecuencia.

La primera forma del servicio funcionaba bajo el nombre de Bitcoin.cz Mining Pool. El sitio web, el servidor y el soporte fueron en gran parte el trabajo de una sola persona. Esto da al liderazgo checo una dimensión más precisa: no fue un proyecto nacional ni un programa estatal, sino un programador que desde Praga resolvió un problema económico específico de la red global.

El grupo también necesitaba ensamblar un bloque candidato y distribuir la tarea a los mineros. Las máquinas individuales proporcionaban el rendimiento, pero el operador determinaba en qué encabezado trabajaban y qué transacciones contenía la plantilla. La división del hardware entre muchas personas no garantizaba por sí sola la división de la toma de decisiones.

El desarrollo posterior de los protocolos de minería, incluido Stratum V1, intentó hacer que la comunicación entre los grupos y los dispositivos fuera más eficiente. Sin embargo, el comercio básico permaneció igual: el grupo vende un pago más predecible y el minero le confía una parte de la coordinación. El primer servidor creó un modelo que otros siguieron rápidamente.

El pool empezó a funcionar el 16 de diciembre de 2010 y ese mismo día minó el bloque 97 834. Hoy el registro de la cadena muestra el resultado, pero no la tensión previa: ¿aceptaría el servidor correctamente el trabajo enviado, reconocería un bloque válido y contabilizaría las participaciones de quienes habían aportado su potencia de cálculo?

El primer bloque confirmó que la coordinación funciona, no solo en la prueba. La recompensa se podía dividir entre los participantes, la mayoría de los cuales no habrían obtenido nada por sí mismos en ese momento. Para los mineros pequeños, fue una prueba tangible de que sus máquinas más débiles no tenían que ser expulsadas de la economía de la red de inmediato.

La fecha es importante para distinguir del anuncio de noviembre. La idea, las pruebas públicas y el resultado en vivo fueron tres pasos diferentes. La historia no comienza con el bloque encontrado de repente, sino con las semanas anteriores, cuando Slush describió abiertamente la propuesta y pidió a la comunidad que lo ayudara a encontrar errores.

El éxito trajo más rendimiento y con él, la responsabilidad. Cuanto más grande era la parte de la red que el grupo reunía, más sensible era cada falla o mala decisión. El servicio debía proteger las cuentas, calcular las recompensas y responder a los ataques. Ya no era solo un script para igualar la suerte; era una infraestructura cuya contabilidad dependían personas ajenas.

El bloque 97 834, por lo tanto, no es significativo por su monto. Otros mineros también ganaban los mismos cincuenta bitcoins. Lo excepcional fue la manera en que lo lograron y cómo lo dividieron. Una sola línea en la cadena de bloques representaba el trabajo común de muchas máquinas y la primera prueba práctica de que la agrupación puede funcionar en una red pública.

El proyecto más tarde pasó por los nombres Slush Pool y Braiins Pool. El equipo Braiins profesionalizó el servicio, mientras que Marek Palatinus dedicó más energía a SatoshiLabs y la cartera de hardware Trezor. Sin embargo, del servidor original permaneció una línea histórica ininterrumpida hacia uno de los nombres más antiguos de la minería de Bitcoin.

La agrupación amplió la posibilidad de minar, pero también concentró gradualmente la creación de plantillas de bloques en un número menor de servicios. Un minero en solitario decide qué bloque construye. Un participante en un grupo de minería común a menudo solo calcula la tarea que recibió. El rendimiento físico puede estar disperso, mientras que la toma de decisiones de coordinación permanece centralizada.

Esta concentración no significa que el grupo posea todas las máquinas conectadas. Los mineros pueden redirigir su rendimiento a otro lugar si no están de acuerdo con las tarifas, la censura o el comportamiento del operador. Sin embargo, el cambio requiere información y la voluntad de reaccionar. La descentralización, por lo tanto, se mide no solo por la cantidad de dispositivos, sino también por quién ensambla los bloques y cuán fácilmente se puede cambiar el coordinador.

El primer texto de Slush no ocultó este compromiso. Ofreció una solución al problema económico y nombró la confianza que la solución requiere. Es precisamente esta apertura lo que ayuda a leer la historia sin el triunfalismo posterior: el grupo no fue la respuesta final, sino una nueva herramienta con costos claros.

El proyecto pragüense cambió la minería al separar el trabajo de la suerte. Un individuo ya no tenía que ganar todo el bloque por sí mismo para que su tasa de hash recibiera un precio continuo. Al mismo tiempo, mostró que incluso un sistema diseñado sin un banco central creará servicios a los que la gente confía la coordinación. La pregunta no es si surgirán, sino si los participantes pueden controlarlos, abandonarlos y reemplazarlos.

Por lo tanto, la concentración de los pools no puede medirse solo por el número de máquinas conectadas. Lo importante es quién arma la plantilla del bloque, selecciona las transacciones, establece las reglas de pago y logra convencer a los participantes de que cambien el software cuando hay un problema. Un minero puede abandonar un pool solo si tiene otra opción viable y realmente vigila lo que hace el servicio. La descripción original de Slush sobre la confianza sigue siendo vigente en este sentido. El pooling resolvió un problema económico real y al mismo tiempo creó un nuevo ámbito en el que son necesarios la competencia, la transparencia y la posibilidad de irse. La descentralización no se mantiene prohibiendo la coordinación, sino impidiendo que esta se endurezca en un poder incontrolable.