Preguntas relacionadas con las consecuencias de romper un bucle iterativo

Los bucles que no tienen un número fijo de iteraciones, por ejemplo, los bucles que dependen de los valores de almacenamiento, deben usarse con cuidado: debido al límite de gas del bloque, las transacciones solo pueden consumir una cierta cantidad de gas. Ya sea explícitamente o simplemente debido a la operación normal, la cantidad de iteraciones en un ciclo puede crecer más allá del límite de gas del bloque, lo que puede provocar que el contrato completo se detenga en un punto determinado.

¿Qué sucede si ocurre un escenario en el que un bucle crece más allá del límite de gas del bloque? particularmente; ¿Por cuánto tiempo estará estancado el contrato?
Para ampliar, si solo 50 de los 500 (un número aleatorio) valores de una matriz fueran afectados por la iteración del ciclo, ¿la función que inició el ciclo sería invocable otras 9 veces y afectaría los 450 valores restantes de la matriz o sería ¿simplemente efectuar continuamente solo los mismos primeros 50 de los 500?
Finalmente, ¿cómo se mitiga esto adecuadamente cuando se recorren los valores de almacenamiento y no los argumentos de entrada de los parámetros de función?

Respuestas (1)

Si el contrato está estancado o no depende de su implementación exacta.

Si tiene alguna función en su contrato que itera sobre toda la matriz cada vez que se llama, entonces el contrato se detendrá permanentemente cuando la matriz crezca a un tamaño que supere el límite de gas del bloque (a menos que tenga otra función que le permite eliminar entradas de la matriz arbitrariamente).

Si, por otro lado, tiene una función que acepta una matriz de índices y solo itera sobre una matriz de almacenamiento usando esos índices directamente (es decir, recorre su matriz de entrada, no la matriz de almacenamiento), entonces podría evitar el estancamiento situación simplemente pasando tantos índices como permita el límite de gas del bloque.

Mitigarlo se reduce a la estructura del código. Es posible tener una matriz que sea demasiado grande para iterar todo a la vez, pero puede crear fácilmente funciones que accederán directamente a los índices sin bucles.

Por ejemplo, si desea modificar una entrada de matriz donde el valor es 4839, y su matriz tiene 10000 entradas, una forma ingenua sería simplemente recorrerla, verificar cada entrada y modificarla cuando encuentre una que sea igual a 4839. Esto es susceptible de alcanzar el límite de gas del bloque a medida que crece el tamaño de la matriz.

Una mejor implementación sería leer su matriz, recorrerla fuera de la cadena y luego tener una función que acepte una lista de índices que desea modificar y sus nuevos valores. Ahora, en lugar de recorrer toda la matriz dentro del contrato, puede recorrer la lista de índice y simplemente actualizar esas entradas.

Hola Raghav, si estoy iterando a través de una función con el propósito de liberar un cierto porcentaje de participación de tokens a todos los participantes, ¿sería una mala idea iterar a través de una matriz de almacenamiento de participantes (que podría crecer a miles) y debería hacerlo? iterar a través de, por ejemplo, 50 direcciones por transacción a través de una función en la matriz de argumentos de memoria de direcciones (para finalmente evitar romper el límite de bloque)?