¿Qué fue la actualización Nakamoto?
La versión Nakamoto fue un hard fork, en el cuarto trimestre de 2024, en la red Stacks diseñado para aportar varios beneficios, entre los principales están el aumento del rendimiento de transacciones y la finalización 100% en Bitcoin.
Con Nakamoto, la producción de bloques de Stacks ya no estaría vinculada a las elecciones de mineros. En su lugar, los mineros producen bloques a un ritmo fijo, y el conjunto de Stackers de PoX se basa en las elecciones de mineros para determinar cuándo el minero actual debe dejar de producir bloques y debe comenzar uno nuevo. Esta cadena de bloques solo se bifurcará si el 70% de los Stackers aprueba la bifurcación, y la reorganización de la cadena será tan difícil como reorganizar Bitcoin.
La versión Nakamoto aportó muchas capacidades y mejoras nuevas a la cadena de bloques Stacks al centrarse en un conjunto de avances clave: mejorar la velocidad de las transacciones, reforzar las garantías de finalización de las transacciones, mitigar las oportunidades de MEV de los mineros de Bitcoin que afectan a PoX y aumentar la robustez frente a reorganizaciones de la cadena.
Diseño previo de producción de bloques de Stacks
La cadena de bloques Stacks hoy produce bloques de acuerdo con los algoritmos descritos en SIP-001 y SIP-007, y SIP-015. Los mineros compiten para añadir un bloque a la cadena de bloques a través del proceso de selección de mineros facilitado por un proceso de sorteo respaldado por VRF. Los mineros envían una transacción de compromiso de bloque a Bitcoin, que se compromete con el hash del bloque que el minero pretende añadir. El proceso de sorteo selecciona como máximo un compromiso de bloque en el siguiente bloque de Bitcoin, lo que da derecho al remitente a propagar su bloque y ganar una recompensa por bloque.
Los problemas
En los últimos tres años la comunidad de Stacks ha identificado varios problemas con el diseño actual del sistema:
Bloques lentos de Bitcoin, bifurcaciones en Stacks y sorteos perdidos son disruptivos para las aplicaciones on-chain. El acto de esperar para producir un nuevo bloque hasta después de que un sorteo elija un minero válido vincula la tasa de producción de bloques de Stacks en el mejor de los casos a la tasa de producción de bloques de Bitcoin, lo que conduce a una latencia de confirmación de transacciones muy alta.
Los microbloques no son efectivos para acelerar el tiempo de confirmación de transacciones. Aunque los microbloques tienen el potencial de mitigar sorteos perdidos y mejorar el tiempo de inclusión de transacciones, no funcionan en la práctica porque el protocolo no puede garantizar que los microbloques se confirmarán hasta que ocurra el siguiente sorteo. Además, los nuevos mineros a menudo dejarán huérfanas las transacciones recientemente confirmadas por el minero anterior que se incluyeron en microbloques porque no existe un procedimiento crítico para el consenso que obligue al siguiente minero a construir sobre el microbloque más reciente.
Las bifurcaciones de Stacks no están vinculadas a las bifurcaciones de Bitcoin, lo que permite reorganizaciones baratas El costo para reorganizar los últimos N bloques en la cadena de bloques Stacks es el costo de producir los siguientes N + 1 bloques de Stacks (es decir, gastando BTC), lo cual es barato en comparación con el costo de reorganizar Bitcoin. Este SIP describe una oportunidad para vincular la bifurcación canónica de Stacks a la cadena de bloques de Bitcoin de modo que el acto de reorganizar la historia de la cadena de Stacks requiera que el minero de Stacks produzca la bifurcación con la aprobación del 70% de los stackers.
Las bifurcaciones de Stacks surgen debido a mineros mal conectados. Si un conjunto de mineros tiene dificultades para conocer la punta de la cadena canónica de Stacks cuando envían compromisos de bloque, entonces colectivamente dejarán huérfanos a otros mineros que están mejor conectados. Esto ha sucedido en la práctica.
Algunos mineros de Bitcoin ejecutan sus propios mineros de Stacks y deliberadamente excluyen a otros mineros de Stacks'
compromisos de bloquede sus bloques de Bitcoin. Una vez que la recompensa en STX por bloque se volvió lo suficientemente grande, esto les permitió pagar un pago trivial de PoX mientras garantizaban que ganarían el sorteo criptográfico en su bloque de Bitcoin. Esto se anticipó en el diseño original pero la regularidad con la que ocurre hoy es mayor de lo que el protocolo original contemplaba, y por tanto debe abordarse ahora.
Las soluciones
Para abordar estas deficiencias, Nakamoto aplica tres cambios fundamentales en la forma en que funciona Stacks.
Bloques rápidos: El tiempo que tarda una transacción enviada por un usuario en ser minada dentro de un bloque (y por tanto confirmada) ahora tomará del orden de segundos, en lugar de decenas de minutos. Esto se logra separando la producción de bloques de los sorteos criptográficos: un minero ganador puede producir muchos bloques entre dos sorteos sucesivos.
Finalidad de Bitcoin: Una vez que una transacción está confirmada, revertirla es al menos tan difícil como revertir una transacción de Bitcoin. La cadena de bloques Stacks ya no se bifurca por sí sola.
Resistencia al MEV de mineros de Bitcoin: Esta propuesta altera el algoritmo de sorteo para asegurar que los mineros de Bitcoin no tengan ventaja como mineros de Stacks. Deben gastar cantidades competitivas de moneda Bitcoin para tener la oportunidad de ganar STX.
Diseño Nakamoto
Para lograr estos objetivos Nakamoto introdujo los siguientes cambios en el protocolo de Stacks:
Desacoplar los cambios de tenencia en Stacks de las llegadas de bloques de Bitcoin. En el sistema actual y en Nakamoto, los mineros se turnan para añadir bloques a la cadena de Stacks: el siguiente minero es seleccionado por sorteo criptográfico, y el minero tiene la duración del bloque de Bitcoin (su tenencia) para anunciar un nuevo estado de bloque. Nakamoto permite que un minero produzca muchos bloques de Stacks por bloque de Bitcoin en lugar de uno, y exige que el siguiente minero confirme todos ellos. Ya no hay microbloques ni bloques anclados a Bitcoin; en cambio, solo hay bloques Nakamoto de Stacks. Esto logrará tiempos de bloque rápidos.
Requerir que los stackers colaboren antes de que pueda producirse el siguiente bloque. Los Stackers deberán validar, almacenar, firmar y propagar colectivamente cada bloque Nakamoto de Stacks que el minero produzca antes de que pueda producirse el siguiente bloque. Los Stackers deben hacer esto para ganar sus pagos de PoX y desbloquear sus STX (es decir, PoX ahora se considera una compensación del minero por desempeñar este papel esencial). En Nakamoto, un sorteo solo selecciona un nuevo minero; no le da al minero el poder de dejar huérfanas unilateralmente transacciones confirmadas como ocurre hoy. Esto garantizará que los mineros no produzcan bifurcaciones y sean capaces de confirmar todos los bloques de Stacks previos antes de la selección.
Usar a los stackers para supervisar el comportamiento de los mineros. Un sorteo hace que los Stackers lleven a cabo un cambio de tenencia mediante (a) acordar un bloque "último firmado" del minero actual, y (b) acordar firmar únicamente bloques del nuevo minero que desciendan de ese bloque último firmado. Por tanto, los Stackers supervisan el comportamiento de los mineros: los Stackers evitan que los mineros minen bifurcaciones durante su tenencia y se aseguran de que comiencen sus tenencias construyendo sobre la punta de cadena canónica. El nuevo minero no puede dejar huérfanas las transacciones recientemente confirmadas por el minero anterior porque los firmantes que aprobaron el cambio de tenencia necesariamente son conscientes de todos los bloques de Stacks que vinieron antes. Esto previene además que los mineros bifurquen la cadena de bloques Stacks.
Requerir que los mineros de Stacks comprometan el hash del bloque indexado del primer bloque producido por el último minero de Stacks en sus transacciones de compromiso de bloque en la cadena de bloques de Bitcoin. Este es el hash SHA512/256 tanto del hash de consenso de todas las transacciones de Bitcoin previamente aceptadas que Stacks reconoce, como del hash del propio bloque (un compromiso de bloque hoy solo contiene el hash del bloque de Stacks). Esto anclará la historia de la cadena de Stacks a la de Bitcoin hasta el inicio de la tenencia del minero anterior, así como todo el estado de Bitcoin causalmente dependiente que Stacks ha procesado. Esto garantiza la finalidad de Bitcoin y resuelve los problemas de conectividad de los mineros al poner la prevención de bifurcaciones en los Stackers.
Adoptar una solución de MEV en Bitcoin que castigue la censura de compromisos de bloque. La probabilidad de que un minero de stacks gane un sorteo debería alterarse de manera que omitir los compromisos de bloque de mineros honestos de Stacks no sea rentable para los mineros de Bitcoin. La mecánica de esto se describen a continuación.
Recursos Adicionales
[Blog de Hiro] Entendiendo los Bloques Rápidos de Nakamoto en Stacks
[YT de Stacks] Qué sigue para Stacks después de la actualización Nakamoto
Última actualización
¿Te fue útil?