¿Por qué los ejemplos de Solidity usan el tipo bytes32 en lugar de una cadena?

En muchos ejemplos de Solidity leí que usan cadenas para parámetros o valores devueltos, veo que se escriben como bytes32si hubiera un stringtipo. ¿Cuál es la verdadera razón de eso? Gracias.

Respuestas (2)

2 razones principales:

  1. Los contratos actualmente no pueden leer unstring devuelto por otro contrato.
  2. El EVM tiene un tamaño de palabra de 32 bytes , por lo que está "optimizado" para manejar datos en fragmentos de 32 bytes. (Los compiladores, como Solidity, tienen que hacer más trabajo y generar más código de bytes cuando los datos no están en fragmentos de 32 bytes, lo que efectivamente conduce a un mayor costo de gas).
¿Significaría esto que si usa una cadena en lugar de byte32, esto haría que el contrato divida la cadena en un fragmento de 32 bytes y luego tenga una cantidad impredecible de fragmentos y, por lo tanto, tenga un uso de gas impredecible en esta parte del código?
Me parece correcto, y el uso impredecible de gas es otra buena consideración.

Tengo prueba en este sitio https://ethfiddle.com/zLxE5Y-8B4

contract TestGas {
    string constant statictext = "Hello World";
    bytes11 constant byteText11 = "Hello World";
    bytes32 constant byteText32 = "Hello World";

    function  getString() payable public  returns(string){
        return statictext;
    }

    function  getByte11() payable public returns(bytes11){
        return byteText11;
    }

    function  getByte32() payable public returns(bytes32){
        return byteText32;
    }
}

Y función getStringgastó 21875 gas,

función getByte11gastó 21509 gas,

función getByte32gastada 21487 gas.

Entonces, si la longitud de su cadena es fija, solo use bytes32.

¿Por qué getByte11cuesta más gasolina que getByte32?
@SaadMalik El EVM funciona con palabras de 32 bytes. Cuando sus datos tienen menos de 32 bytes, cada operación relacionada con estos datos se reducirá de 256 bits a 8 bits (32 bytes = 256 bits), por lo que EVM necesita mucho más gas.