¿Qué fue la Actualización Nakamoto?
El Nakamoto Release 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 un mayor rendimiento de transacciones y una finalidad de Bitcoin del 100%.
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 con un ritmo fijo, y el conjunto de Stackers de PoX depende de las elecciones de mineros para determinar cuándo el minero actual debe dejar de producir bloques y cuándo debe comenzar un nuevo minero. 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 nuevas capacidades y mejoras a la cadena de bloques de Stacks al centrarse en un conjunto de avances fundamentales: mejorar la velocidad de las transacciones, reforzar las garantías de finalidad de las transacciones, mitigar las oportunidades de MEV de los mineros de Bitcoin (valor extraíble por el minero) que afectan a PoX, y aumentar la robustez frente a reorganizaciones de la cadena.
Diseño anterior de producción de bloques de Stacks
La cadena de bloques de Stacks hoy produce bloques de acuerdo con los algoritmos descritos en SIP-001 y SIP-007, y SIP-015. Los mineros compiten por añadir un bloque a la cadena de bloques mediante el proceso de selección de mineros facilitado por un proceso de sorteo respaldado por VRF. Los mineros envían una transacción de block-commit 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 block-commit en el bloque de Bitcoin posterior, lo que da derecho al remitente a propagar su bloque y obtener una recompensa por bloque.
Los problemas
Durante los últimos tres años, la comunidad de Stacks ha identificado varios problemas con el diseño actual del sistema:
Los bloques lentos de Bitcoin, las bifurcaciones de Stacks y los sorteos fallidos son disruptivos para las aplicaciones en cadena. La práctica de esperar para producir un nuevo bloque hasta que un sorteo elija un minero válido vincula la mejor tasa posible de producción de bloques de Stacks 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 los sorteos fallidos y mejorar el tiempo de inclusión de las transacciones, en la práctica no funcionan 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 del 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 de reorganizar los últimos N bloques en la cadena de bloques de 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 la reorganización del historial 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 canónica de la cadena de Stacks cuando envían block-commits, entonces colectivamente dejarán huérfanos a otros mineros que tienen mejor conectividad. Esto ha ocurrido en la práctica.
Algunos mineros de Bitcoin ejecutan sus propios mineros de Stacks y excluyen deliberadamente los block-commits de otros mineros de Stacks
block-commitsde sus bloques de Bitcoin. Una vez que la recompensa por bloque de STX se hizo lo suficientemente grande, esto les permitió pagar un pago PoX trivial mientras garantizaban que ganarían el sorteo criptográfico en su bloque de Bitcoin. Esto se anticipó en el diseño original, pero la frecuencia con la que ocurre hoy es mayor de lo que contemplaba el protocolo original, y por lo 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 lo tanto confirmada) ahora será 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 confirmada una transacción, revertirla es al menos tan difícil como revertir una transacción de Bitcoin. La cadena de bloques de Stacks ya no se bifurca por sí sola.
Resistencia al MEV de los mineros de Bitcoin: Esta propuesta modifica el algoritmo de sorteo para garantizar que los mineros de Bitcoin no tengan ventaja como mineros de Stacks. Deben gastar cantidades competitivas de la 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 de Stacks de la llegada de bloques de Bitcoin. Tanto en el sistema actual como en Nakamoto, los mineros se turnan para añadir bloques a la cadena de bloques de Stacks: el siguiente minero se selecciona mediante sorteo criptográfico, y el minero dispone de 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 su lugar, solo existen bloques de Stacks de Nakamoto. Esto logrará tiempos de bloque rápidos.
Exigir que los stackers colaboren antes de que pueda producirse el siguiente bloque. Los stackers necesitarán validar, almacenar, firmar y propagar colectivamente cada bloque de Stacks de Nakamoto que produzca el minero antes de que pueda producirse el siguiente bloque. Los stackers deben hacerlo 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 a un nuevo minero; no le da al minero el poder de dejar huérfanas unilateralmente las transacciones confirmadas, como ocurre hoy. Esto garantizará que los mineros no produzcan bifurcaciones y que puedan confirmar todos los bloques de Stacks anteriores antes de ser seleccionados.
Usar a los stackers para vigilar el comportamiento de los mineros. Un sorteo hace que los Stackers lleven a cabo un cambio de tenencia al (a) ponerse de acuerdo sobre un bloque "últimamente firmado" del minero actual, y (b) acordar firmar solo bloques del nuevo minero que desciendan de este bloque últimamente firmado. Así, los Stackers vigilan el comportamiento de los mineros: los Stackers impiden que los mineros hagan bifurcaciones durante su tenencia, y se aseguran de que comiencen sus tenencias construyendo sobre la punta canónica de la cadena. El nuevo minero no puede dejar huérfanas las transacciones recientemente confirmadas del minero anterior porque los firmantes que aprobaron el cambio de tenencia necesariamente conocen todos los bloques de Stacks que existieron antes. Esto impide además que los mineros bifurquen la cadena de bloques de Stacks.
Exigir a los mineros de Stacks que comprometan el hash indexado del primer bloque producido por el último minero de Stacks en sus transacciones de block-commit 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 block-commit hoy solo contiene el hash del bloque de Stacks). Esto anclará el historial de la cadena de Stacks a Bitcoin hasta el inicio de la tenencia del minero anterior, así como a todo el estado de Bitcoin causalmente dependiente que Stacks haya 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 de Bitcoin que castigue la censura de block-commit. La probabilidad de que un minero de Stacks gane un sorteo debería modificarse de modo que omitir los block-commits de mineros honestos de Stacks no resulte rentable para los mineros de Bitcoin. La mecánica de esto se describe a continuación.
Recursos adicionales
[Blog de Hiro] Comprender los bloques rápidos de Nakamoto en Stacks
[Stacks YT] Qué sigue para Stacks después de la actualización Nakamoto
Última actualización
¿Te fue útil?