Reorgs de Bitcoin

Bajo Nakamoto, las transacciones de Stacks no se reorganizan de forma significativa debido a un fork de Bitcoin. No solo las reorganizaciones son relativamente infrecuentes, sino que las transacciones en Stacks que se reorganizaron debido a un fork de Bitcoin se comportan igual que las transacciones reorganizadas de Bitcoin. Con algún análisis futuro, las transacciones puramente en la cadena L2 podrían algún día quedar completamente afectadas.

Comprender este concepto se reduce fundamentalmente a entender la finalización en Stacks post-Nakamoto.

Bajo Nakamoto, la cadena Stacks no se bifurcará por sí sola. Está diseñada para no bifurcarse salvo excepciones especiales, y es totalmente inviable que Stacks se bifurque por sí sola si incluso el 31% de los Stackers no quiere que se bifurque, y aun así probablemente solo ocurriría dentro del lapso de una sola tenencia.

El único caso en el que Stacks se bifurca post-Nakamoto es si forks de Bitcoin la hacen bifurcarse.

Bajo Nakamoto, en lugar de ganar el derecho a crear un único bloque, los mineros ganan el derecho a crear una gran cantidad de bloques, y durante ese tiempo decimos que están bajo “tenencia”. Cada bloque de Stacks producido en una tenencia requiere al menos el 70% de los Stackers para aprobarlo (firmarlo) para que se incluya en la blockchain de Stacks. Los Stackers están observando la blockchain de Bitcoin y solo firmarán bloques del minero que ganó la última sortición.

Ahora, imaginemos que Bitcoin se reorganiza y los Stackers estaban observando un fork de Bitcoin que ahora es subóptimo. Los Stackers esencialmente retrocederían en el tiempo hasta la última sortición común entre el fork que estaban observando y el nuevo mejor fork de Bitcoin y comenzarían a firmar los bloques dentro de las tenencias a partir de ahí. Ten en cuenta que el 70% de los Stackers hará lo mismo simultáneamente, y en el momento en que el 70% acuerde comenzar a firmar desde la última tenencia en el nuevo fork de Bitcoin habrá una nueva cadena Stacks singularmente óptima.

¿Qué sucede con las transacciones que fueron confirmadas en la tenencia que se reorganizó? Nada. Siguen en el mempool como si la tenencia reorganizada no hubiera ocurrido. Para cualquier cosa dentro de la blockchain de Stacks, todo está bien.

Esto es 1:1 con un fork de Bitcoin que reorganiza una transacción de Bitcoin. No debes considerar una transacción en Bitcoin como final si está cerca de la punta de la cadena, y no debes considerar una transacción en Stacks como final si está cerca de la punta de la tenencia.

Reproducción de transacciones

Dado que el 70% de los firmantes tienen que firmar cualquier bloque de Stacks incluido en la cadena, al menos el 70% de los firmantes conocen el estado de la cadena antes y después de que un fork de Bitcoin cause una reorg de Stacks.

Hay una traba que hace difícil imponer esto: si una transacción dependiera de algo en la blockchain de Bitcoin que también se reorganizó (un peg-in, por ejemplo), esa transacción ahora sería inválida. El análisis de contaminación (taint analysis) es cuando intentas responder a las preguntas “qué transacción interactuó con la blockchain de Bitcoin ahora huérfana de una manera que las vuelve inválidas (contaminadas) en la nueva cadena” y luego también “qué transacciones interactuaron con la transacción ahora inválida (contaminada) de tal forma que ahora también son inválidas”. Hay un efecto en cascada, pero hacer cumplir cualquier tipo de reproducción requiere que los Stackers y los Mineros puedan identificar qué transacciones se pueden reproducir en absoluto.

El análisis de contaminación y, posteriormente, la imposición de reproducción, pueden añadirse en el futuro.

Para la primera versión, Nakamoto vincula explícitamente la blockchain de Stacks a la blockchain de Bitcoin de tal manera que solo hay un fork óptimo de Stacks vinculado a Bitcoin en un momento dado. Esto es completamente 1:1 con el comportamiento de la blockchain de Bitcoin, pero a la escala de la tenencia.