ASICBoost

Al tramitar pedidos parecidos, podemos preparar una vez los datos comunes, pero debemos terminar cada pedido por separado. Esa imagen ayuda a entender ASICBoost. Timo Hanke lo describió en 2016, reconociendo su colaboración con Sergio Demian Lerner. Un ASIC es un chip diseñado para una tarea de cálculo concreta; reorganizarla evita repeticiones. No cambia SHA-256, la función hash utilizada, ni las reglas de Bitcoin. El doble hash final de la cabecera debe seguir siendo menor o igual que el objetivo, y el bloque completo debe ser válido. [1]

El byte es una unidad que mide el tamaño de los datos digitales. La cabecera resume datos del bloque en 80 bytes. La primera pasada de la función hash procesa 64 bytes y luego los 16 restantes con el relleno establecido. La Merkle root, la huella conjunta de las transacciones, cruza esa frontera: sus últimos 4 bytes quedan en la segunda parte. Allí también están el tiempo, bits, la codificación compacta del objetivo de minería, y nonce, el contador que varía entre intentos. Los campos modificados determinan qué cálculos pueden reutilizarse. [1]

Hanke llama colliding work items a los conjuntos de tareas adecuados. Sus primeras partes de cabecera difieren y generan distintos midstate, los estados intermedios del cálculo. En cambio, la parte llamada Message coincide. Para un nonce elegido se puede compartir el message schedule, los valores auxiliares que procesan la segunda parte del primer SHA-256. Después, el cálculo continúa por separado desde cada estado intermedio. No se han encontrado hashes finales idénticos ni se ha roto la función. Aquí, colisión significa que coincide una parte concreta de la entrada; las primeras partes de las cabeceras son distintas. [1]

Sergio Demian Lerner distingue overt y covert ASICBoost. Overt cambia bits permitidos de nVersion, el campo de versión de la cabecera, sin necesitar buscar una coincidencia parcial de la Merkle root. Covert sí la busca: conserva los últimos 4 bytes de la Merkle root mientras cambia la primera parte. Puede variar datos permitidos de las transacciones o su orden, respetando sus dependencias y manteniendo las huellas registradas coherentes con los datos del bloque. Ver versiones de cabecera diferentes no demuestra por sí solo un ahorro energético ni identifica al operador. [2]

Un pool coordina el trabajo de los mineros. Su servidor, el servicio informático con el que se comunica el equipo, acepta los resultados conforme a las condiciones acordadas. El equipo de Pedro no puede modificar cualquier campo a voluntad. El documento identificado como BIP310 describe la negociación mediante mining.configure: version-rolling.mask indica los bits modificables y la respuesta selecciona la intersección de las posibilidades del minero y el servidor. La máscara señala posiciones permitidas, no promete mayor velocidad. La condición version_bits & ~last_mask == 0 exige que los bits enviados respeten la última máscara válida. Una notificación mining.set_version_mask entra en vigor inmediatamente, sin esperar al siguiente trabajo. El firmware, el programa que controla el equipo, debe respetar ese acuerdo. [3]

BIP320 propone 16 bits generales de nVersion; BIP323, su sustitución propuesta, describe 24 bits. En esta revisión editorial ambos documentos figuran como Draft, es decir, propuesta. Eso no significa por sí solo que nada esté implementado ni que todos los pools lo admitan. Los documentos describen el uso previsto del campo; una conexión real depende de la máscara y el software utilizados. Pedro no puede deducir los permisos de su máquina de un número de BIP ni confundir una propuesta con un cambio automático de las reglas de red. [4] [5]

Hanke expresa el ahorro del modelo como x × (n − 1) / n. La x representa la parte del cálculo que se comparte, y n la cantidad de tareas adecuadas. Con x = 25% y n = 4, resulta 18.75%. La preparación común se hace conjuntamente en lugar de repetirse para cada tarea. El resultado corresponde a ese modelo de trabajo, no automáticamente a la misma reducción de vatios en cualquier máquina. Los demás circuitos y las condiciones de funcionamiento también influyen. No debe trasladarse sin mediciones a una previsión de rendimiento o ingresos. [1]

Pedro comprueba primero la compatibilidad del chip, el firmware y el pool. Después verifica que el pool acepta el trabajo y mide el equipo completo en condiciones comparables. J/TH significa julios por terahash: la energía necesaria para un billón de intentos de hash. Para comparar, las mediciones deben abarcar los mismos componentes del equipo y el mismo periodo. La etiqueta ASICBoost no sustituye esas medidas. Tampoco significa overclocking, que aumenta la frecuencia de funcionamiento, ni garantiza encontrar bloques o ganar dinero. Permite realizar parte del trabajo de forma más eficiente cuando toda la configuración lo admite. [1] [3]