No sé cuándo y con qué frecuencia se ejecuta un script, pero me parece que habría un problema si un único script (o la suma de todos los scripts de un bloque) supera el tiempo que tarda en incluirse en un bloquear.
Dado que la tendencia en las monedas alternativas es disminuir la duración del tiempo del bloque, creo que esto podría convertirse en un problema o una condición de carrera en la que el TX nunca se incluya en un bloque.
Teniendo en cuenta que a medida que crecen los diversos tamaños de bloques de monedas alternativas... Tal vez más de 1 mb, este riesgo también crecería, dada la mayor cantidad de transacciones.
Entonces mi pregunta es:
Escuché que ciertos scripts de TX antiguos no se validan durante la sincronización inicial para acelerar el proceso, por lo que tal vez haya otras ocasiones en las que no se ejecute un TX. (Tal vez es un script desconocido.)
Tal vez solo los mineros se vean afectados... No estoy seguro.
No deberías tener que preocuparte de que esto suceda.
No hay códigos de operación de bucle en los scripts. Cada código de operación de script solo se puede ejecutar una vez, y el código de operación más lento es probablemente la verificación de firma ECDSA (porque involucra EC_point_multiply). Aun así, solo se necesitan entre 50 y 100 μs en un solo núcleo de una CPU moderna para procesar.
Supongamos que un bloque de 1 MB (tamaño máximo) contiene 100 % de códigos de operación de verificación de firmas, eso es 1 millón de verificación de firmas y toma como máximo 100 segundos de tiempo de CPU de un solo núcleo, esto sigue siendo mucho menor que el tiempo de bloque. En la práctica, cada scriptSig va acompañado de al menos 100 bytes de datos (clave pública + firma ECDSA), por lo que probablemente requiera menos de 1 segundo de tiempo de CPU.
Este es un problema potencial en bitcoin, pero mucho más en altcoins. Bitcoin es muy conservador en la riqueza de su script de transacciones. Las altcoins con un tiempo de bloqueo más rápido y/o motores de secuencias de comandos menos restrictivos deben realizar optimizaciones sustanciales para que esto no sea un riesgo.
Este es uno de los problemas relacionados con el aumento del tamaño del bloque a algo así como 8 MB.
Rusty Russell habla en una publicación sobre la megatransacción ( https://rusty.ozlabs.org/?p=522 ).
Según Rusty
si los bloques fueran de 8 MB: una transacción de 8 MB con 22 500 entradas y 3,95 MB de salidas tarda más de 11 minutos en procesarse. Si puede minar uno de esos, puede alejar a los competidores para siempre y ser dueño de la red bitcoin.
Los desarrolladores del núcleo de bitcoin han realizado mejoras sustanciales en la infraestructura de bitcoin (como libsecp256k1) para hacer posible la futura expansión. Pero este es un ejemplo de cómo un simple cambio constante puede tener efectos de largo alcance.
Si es solo un nodo el que se queda atrás, cualquiera de sus bloques generados podría convertirse fácilmente en un bloque huérfano no aceptado por la red. Si esto es una falla/error en la altcoin, la dificultad se ajusta hacia abajo hasta el mínimo, ya que no ve que los nodos estén completando bloques lo suficientemente rápido (lo cual es imposible si el procesamiento de bloques siempre tomará más tiempo que el tiempo de bloqueo).
Como se mencionó, es poco probable que ocurra este error, ya que los tiempos de procesamiento son insignificantes para los bloques. A menos que su tiempo de bloqueo sea tan bajo, pero se encontrará con problemas mayores si su tiempo de bloqueo es inferior a un segundo.
fabricante de cosas7
jose pineda