Del artículo: ¿Existen patrones de almacenamiento simples y bien resueltos para Solidity?
Ignorando los costos, ¿alguien sabe cuántas variables/filas puede manejar un contrato de solidez usando cada uno de los tipos? ¿O está esto limitado por el tamaño de la transacción más que nada?
Más específicamente, ¿cuándo terminará mi contrato?
struct DocumentStruct{
bytes32 name;
uint value;
}
mapping(bytes32 => DocumentStruct) public documentStructs;
function StoreDocument(bytes32 key, bytes32 name, uint value) returns (bool success) {
documentStructs[key].name = name;
documentStructs[key].value = value;
return true;
}
Las soluciones de variantes de escala, lo que significa que los procesos con demandas computacionales que aumentan con el tamaño de la tabla son (en términos generales) una mala forma para los Contratos de Solidez, ya que el costo de las funciones seguramente aumentará hasta que a) el costo de usar el contrato sea antieconómico o b) se excede el límite de gas del bloque. La condición b) hace que la función sea imposible de ejecutar a cualquier precio.
Cada uno de los patrones está diseñado para ser invariable en escala. El costo del gas será consistente a cualquier escala . Como señaló Thomas, filas máximas es un número realmente grande. Representaría una inversión de gas realmente grande.
Puede ejecutar cualquiera de los ejemplos, o su propia implementación de los patrones, probar (por ejemplo, con Remix) y continuar con la seguridad de que el gas y el rendimiento no cambiarán a medida que las tablas crezcan en tamaño. En otras palabras, puede (y debe) conocer su costo.
El propietario del contrato no asumiría necesariamente el costo. Cuando los contratos están diseñados para alinear los gastos de gas con los beneficios para el usuario, podemos imaginar que este costo se asigna de manera justa entre los usuarios que crean el conjunto de datos.
Si bien los ejemplos de contratos de Solidity están diseñados para tarifas eficientes y consistentemente modestas, dos factores afectan el precio futuro de las actualizaciones. Primero, las fuerzas del mercado afectan el precio de ETH y, por lo tanto, del gas. En segundo lugar, los cambios de protocolo futuros pueden alterar los costos de las operaciones de bajo nivel a partir de las cuales se calcula el gas total.
Vale la pena mencionar este segundo punto. Aunque el código mantiene operaciones de igual tamaño y controla los flujos a cualquier escala, las estimaciones actuales de gas se calculan, por supuesto, según la "lista de precios" de Ethereum para los códigos de operación. Son concebibles ajustes periódicos a la lista de precios (cambios de protocolo). En mi opinión, los cambios futuros en la lista de precios y el valor futuro de Eth no se pueden pronosticar con precisión .
Como diseñador de contratos, la mejor postura, en mi opinión , es apuntar a un costo general constante y bajo, ya que esto asegura que las funciones sean ejecutables a cualquier escala.
Espero eso ayude.
La respuesta anterior es técnicamente incorrecta. Su contrato no podrá almacenar más de 2^256-1 entradas, pero ese número es tan grande que no es posible llegar a estar casi lleno.
El punto más importante es el costo asociado con el almacenamiento de datos en la cadena de bloques. Leí en alguna parte que almacenar tan poco como un megabyte podría costar muchos miles de dólares, y eso fue antes de que el precio del éter se disparara.
Definitivamente debe comprender cuánto costará antes de planear almacenar demasiados datos en cadena. En cambio, lo que la gente ha estado haciendo es almacenar los datos en IPFS y almacenar solo el hash de esos datos en la cadena.
En realidad tu pregunta no es tan clara. ¿Quiere decir que hay alguna limitación en el tamaño de la variable del contrato?
El contrato que escribe arriba es legal y no debe preocuparse por el documentStructsdesbordamiento de la variable.
Maptype es un tipo dinámico en solidez, a cada elemento en el mapa se le asignará una ranura de almacenamiento única (dirección calculada por función hash) para almacenar. el tamaño de almacenamiento es ilimitado. Por lo tanto, conceptualmente hablando, un mapa nunca se desbordará.
Aquí hay un enlace , en él se describe claramente la organización del almacenamiento por contrato. Espero que te ayude.
Ignorando los costos, ¿alguien sabe cuántas variables/filas puede manejar un contrato de solidez usando cada uno de los tipos?
Esto no se aplica específicamente a la adición de entradas a su mapping, pero en general, una cosa a tener en cuenta es el tamaño de la pila.
Agregar variables locales a una función determinada probablemente daría como resultado un error de "Pila demasiado profunda", según este hilo anterior:
Error al compilar: pila demasiado profunda
Solía ser que 17 variables locales (invariante de tipo, creo ) era el límite.
el feto