Los datos de la cadena de bloques son inmutables, por lo que una vez que sea válida, una transacción siempre será válida y los nodos completos podrán verificarla.
Hay varias razones por las que creo que tenerlas sería una idea terrible.
Escalabilidad. Si los scripts pueden acceder a partes arbitrarias de la cadena de bloques, la validación completa de los nodos requeriría un acceso (¡rápido!) a toda la cadena. Actualmente, este no es el caso: los nodos de validación completa no necesitan la cadena completa, sino solo una pequeña base de datos de salidas de transacciones no gastadas (que es menos de 3 GiB y crece mucho más lentamente).
Gestión de Mempool. Si la validez del script puede depender del estado de la cadena de bloques, las transacciones no confirmadas pueden ser invalidadas por nuevos bloques. Es posible construir estos códigos de operación hipotéticos de inspección de cadena de bloques para que los nuevos bloques nunca invaliden las cosas (por ejemplo, solo tienen códigos de operación que se extraen de un bloque y, si no se encuentra ese bloque, provocan una falla inmediata en el script). Sin embargo, incluso en ese caso la validez puede verse afectada por reorganizaciones. Eso significaría efectivamente que todo el mempool tendría que ser revalidado después de cada reorganización.
fungibilidad. Relacionado con el punto anterior, incluso se da el caso de que reorganizaciones más profundas que 1 pueden afectar la validez de transacciones ya confirmadas. Esto significa que el software de billetera debería tener mucho cuidado al aceptar pagos con transacciones cuya validez depende del estado de la cadena de bloques, ya que las reorganizaciones tienen una mayor probabilidad de eliminarlas, incluso cuando el remitente es completamente honesto. Esto no es cierto para las transacciones en este momento: las transacciones eliminadas durante una reorganización siempre se pueden volver a aceptar en nuevos bloques en la nueva sucursal.
david schwartz