Estoy construyendo un contrato inteligente de Ethereum que permite a los usuarios crear listados. Aquí está parte de mi contrato, la parte que es culpable del uso de gas:
struct LiveListing {
uint id;
string name;
string description;
string condition;
uint price;
address buyer;
address seller;
}
mapping(uint => LiveListing) public liveListingsMapping;
uint id;
function createListing(string _name, string _description, string _condition, uint _price) public {
id++;
LiveListing memory listing = LiveListing({name: _name,
description: _description,
condition: _condition,
price: _price,
seller: msg.sender,
id: id,
buyer: 0x0,
});
liveListingsMapping[id] = listing;
}
Cuando se comenta el mapeo y mi asignación de una lista a una identificación, el gas pasa de más de 1,000,000 a 300,000. Además, la lista de creación va de 300.000 a alrededor de 21.000-22.000. ¿Algún consejo? ¡Gracias!
No es el Mapeo lo que consume mucha gasolina; es el hecho de que está almacenando una gran cantidad de datos en un objeto grande.
Un concepto que debe tener claro es que cuando almacena datos en Ethereum, actualmente todos los nodos de la red deben almacenarlos (excluyendo los nodos ligeros). Por lo tanto, hay un costo de gasolina asociado con el almacenamiento de datos que aumenta a medida que aumenta la cantidad de datos que desea almacenar. La idea es descentivizar el almacenamiento de muchos datos en la cadena.
Posibles soluciones Aquí hay algunas posibles soluciones a considerar:
Por ejemplo, uint es un alias para uint256, lo que le permitiría tener alrededor de 1.1579209e+77 listados.
¿Espera que haya más de 18.446.744.073.709.551.615 listados? Si no, quizás uint64 sería más adecuado.
Del mismo modo, es conditionmás como una enumeración; ¿podría almacenar 1-2 caracteres en bytes2lugar de requerir toda la memoria utilizada para almacenar un string?
¿Otros contratos necesitan leer todos los datos? De lo contrario, quizás los datos no tengan que almacenarse en Ethereum y puedan almacenarse fuera de la cadena en IPFS o algo similar.
Tal vez podría inspirarse en ERC-721 , que define una tokenMetadatafunción y un estándar de almacenamiento, para almacenar metadatos de tokens fuera de la cadena, y algunos de los tokens de implementación (por ejemplo , CrytoKitties ).