Reorganizaciones de Bitcoin

Las transacciones en Stacks no se reorganizan de forma impactante debido a un fork de Bitcoin. No solo las reorganizaciones son relativamente poco frecuentes, sino que las transacciones en Stacks que se reorganizaron por un fork de Bitcoin se comportan tal como lo hacen 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 no afectadas.

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

Stacks no se bifurca por sí solo. Está diseñado para no bifurcarse salvo excepciones especiales, y es completamente inviable que Stacks se bifurque por sí solo 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 es si los forks de Bitcoin lo hacen bifurcarse.

En lugar de ganar el derecho a hacer un solo bloque, los mineros ganan el derecho a hacer una gran cantidad de bloques, y durante ese tiempo decimos que están bajo una “tenencia”. Cada bloque de Stacks producido en una tenencia requiere que al menos el 70% de los Stackers lo aprueben (firmen) 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 fork de Bitcoin mejor, y comenzarían a firmar los bloques dentro de las tenencias a partir de allí. Nótese que el 70% de los Stackers hará lo mismo al mismo tiempo, y en el momento en que el 70% esté de acuerdo en comenzar a firmar desde la última tenencia en el nuevo fork de Bitcoin, hay una nueva blockchain de Stacks singularmente óptima.

Entonces, ¿qué pasa con las transacciones que se confirmaron 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 reorganizando una transacción de Bitcoin. No deberías considerar una transacción en Bitcoin como final si está cerca de la punta de la cadena, y no deberías considerar una transacción en Stacks como final si está cerca de la punta de la tenencia.

Repetició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 reorganización de Stacks.

Hay una pega que dificulta su aplicación: si una transacción dependía 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 ahora huérfana blockchain de Bitcoin de una manera que las hace inválidas (contaminadas) en la nueva cadena” y luego también “qué transacciones interactuaron con la transacción ahora inválida (contaminada) de modo que ahora también son inválidas”. Hay un efecto en cascada, pero hacer cumplir cualquier tipo de repetición requiere que los Stackers y los Mineros puedan identificar qué transacciones pueden ser repetidas en absoluto.

El análisis de contaminación y, posteriormente, la aplicación de la repetició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 cualquier momento dado. Esto es completamente 1:1 con el comportamiento de la blockchain de Bitcoin, pero a escala de tenencia.