¿Cuál es la parte críptica al final del código de bytes de un contrato de solidez?

Dado el siguiente contrato:

pragma solidity ^0.4.11;

contract Simple {
    bytes32 public v;
    function set(bytes32 _v) {
        v = _v;
    }
}

Al desensamblar, ni remix, solcni evmpueden interpretar correctamente el final del código. Además, el código parece inalcanzable (sigue una instrucción JUMP), y lo que parece hacer no tiene mucho sentido.

Se produce un código de seguimiento similar cuando se compila con solcy remix, con prefijos y sufijos similares, pero los contenidos son ligeramente diferentes:

 00a165627a7a72305820...0029

En el desensamblado, el bytecode de prefijo es interpretado por todos como:

 stop
 log1
 push6 0x627a7a723058 
 sha3
 ...

Cuando se compila con remix, el campo "ensamblaje" en la GUI web describe la pieza como una etiqueta ".data":

[...]
 SSTORE             v = _v
      POP           v = _v
    tag 10          function set(bytes32 _v) {\n        ...
      JUMPDEST          function set(bytes32 _v) {\n        ...
      POP           function set(bytes32 _v) {\n        ...
      JUMP [out]            function set(bytes32 _v) {\n        ...
    .data

Insinuando así que esto no es código en absoluto, sino algún tipo de campo de datos. Si es así, ¿para qué se usa esto? , en general y en este ejemplo específico?

  • remezclar: 0.4.14+commit.c2215d46.Emscripten.clang
  • evm: 1.7.0-inestable (git commit 3d32690b)
  • solc: 0.4.14-develop.2017.7.27+commit.16ca1eea.Linux.g++

Código de bytes de tiempo de ejecución (desde remix):

60606040526000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680637c2efcba146047578063db80813f146075575b600080fd5b3415605157600080fd5b60576099565b60405180826000191660001916815260200191505060405180910390f35b3415607f57600080fd5b6097600480803560001916906020019091905050609f565b005b60005481565b80600081600019169055505b505600a165627a7a72305820e62ffd25aaa1132d83ae4470e9f3991cb237178c38401db1857b9417b74603560029

Respuestas (1)

Este es el hash Swarm . Está documentado en https://solidity.readthedocs.io/en/develop/metadata.html

El extracto sigue

Metadatos del contrato

El compilador de Solidity genera automáticamente un archivo JSON, los metadatos del contrato, que contiene información sobre el contrato actual. Se puede usar para consultar la versión del compilador, las fuentes utilizadas, la documentación de ABI y NatSpec para interactuar de manera más segura con el contrato y verificar su código fuente.

El compilador agrega un hash de Swarm del archivo de metadatos al final del código de bytes (para obtener detalles, consulte a continuación) de cada contrato, de modo que pueda recuperar el archivo de forma autenticada sin tener que recurrir a un proveedor de datos centralizado.

El formato se ve así:

ingrese la descripción de la imagen aquí

Si tuviera que cargar por separado el archivo de metadatos en Swarm, los futuros usuarios de su contrato podrían encontrarlo a través de esta referencia en el código del contrato.

Actualización agosto 2019

Desde solidity 0.5.9, el formato de metadatos se ve así:

solidez 0.5.9

Y también una palabra de precaución:

Actualmente, el compilador usa el hash de "enjambre versión 0" de los metadatos, pero esto podría cambiar en el futuro, así que no confíe en esta secuencia para comenzar con 0xa2 0x65 'b' 'z' 'z' 'r' '0' . También podríamos agregar datos adicionales a esta estructura CBOR, por lo que la mejor opción es usar un analizador CBOR adecuado.

En solidity 0.5.10, veo 0xa2en lugar de 0xa1para el primer byte y 0x32en lugar de 0x29para el último byte
Actualización : De hecho, actualizaron la especificación de metadatos del contrato en Solidity 0.5.9.
¿Cuál es la parte críptica al final del código de bytes de un contrato de solidez?
RespuestasAquíPolítica de privacidad1y, 0v