¿Por qué se implementa la eliminación en arreglos de una manera que desperdicia energía y gas?

Si elimino toda la matriz (estática/dinámica), todos los elementos de una matriz se establecen en el valor predeterminado. Entonces, significa que si una matriz tiene un millón de elementos, entonces tengo que pagar gasolina para configurar un millón de elementos a cero, y probablemente exceda el límite de Ethereum.

Sin embargo, eliminar en blockchain es diferente a eliminar en la memoria de una máquina. Nunca se puede eliminar nada de blockchain y, por lo tanto, la única razón por la que puede existir la operación de eliminación es simplemente "marcar algún campo para invalidarlo" con el propósito de un código de contrato inteligente. No hay otra razon. En el caso de los tipos de valor (int, float, etc.), no importa si solo invalidamos poniendo a cero la variable de almacenamiento o ajustando su propiedad. Sin embargo, el problema viene con las matrices: no hay razón para poner a cero todos los campos de una matriz solo debido a su invalidación. En su lugar, solo el atributo de longitud de una matriz debe establecerse en cero y se debe agregar una verificación de índice para acceder a una matriz.

¿Me equivoco?

Respuestas (1)

Para los arreglos de almacenamiento, hay algún uso en la eliminación de elementos. Cada dirección de almacenamiento que se establece en cero a partir de un valor distinto de cero produce un reembolso de gas de 15000 gas, que puede compensar los costos de otras operaciones, como almacenar un nuevo valor.

Para obtener información específica, consulte ¿Cuáles son los límites para los reembolsos de gasolina? .

En muchos casos, sin embargo, tiene razón en que eliminar elementos no es rentable y, por lo tanto, en la práctica, la mayoría de las veces los datos de los contratos inteligentes no se eliminan.

También por razones de seguridad, si elimina algo de una matriz, no desea que el contenido sea accesible de otra manera más adelante.
@Tjaden: Veo que el reembolso de gasolina está muy poco incentivado y, además, es aplicable solo para algunos casos de uso. Considero una matriz de, digamos, 1000 elementos y solo quiero "eliminar la matriz". Pero, en lugar de pagar solo por ajustar la longitud de la matriz (una variable de almacenamiento), tengo que pagar 1000x por SSTORE, y el reembolso es realmente ridículo por ese costo. Entonces, en lugar de usar arreglos nativos, estoy más incentivado para crear un envoltorio de arreglo eficiente construido sobre arreglos nativos. Esto es muy triste para mí.
Estoy de acuerdo en que tendría sentido tener una semántica separada de eliminación/reducción de longitud. Créanme, este está lejos de ser el único lugar donde la solidez podría estar mejor diseñada.
Por cierto, puede configurar manualmente la longitud en 0 usando 1 línea de ensamblaje, que podría ser la mejor opción aquí