Elementos Internos de Despliegue de Contratos Inteligentes

Las transacciones de despliegue de contratos son únicas en varios aspectos. En este artículo, diseccionamos una transacción de este tipo, examinando de cerca el bytecode que da vida a un nuevo contrato.

¿Con quién estamos hablando?

Las transacciones son un intercambio entre dos partes.

Al realizar transacciones con la criptomoneda nativa, las direcciones de "desde" y "hacia" identifican a los propietarios iniciales y finales de la moneda. Al ejecutar un contrato inteligente, el remitente de la transacción le pide al contrato inteligente que ejecute una función. Así, el contrato se convierte en el destinatario de la transacción.

De manera similar, en el despliegue de contratos, el remitente de la transacción es quien crea el nuevo contrato en la cadena. Pero, ¿quién es el destinatario? ¡Es la propia blockchain! La cadena de bloques designa una dirección especial para que cualquiera pueda solicitar este servicio. Esta dirección especial es la dirección nula.

¡Aquí está el código! ¡Desplieguelo!

Teniendo una contraparte de despliegue, ¿podríamos simplemente enviar el código del contrato inteligente a la dirección NULL, verdad? No exactamente. La carga útil de datos de la transacción de despliegue es un poco más complicada, y por una buena razón.

La razón es el constructor, un fragmento de código encargado de la validación del despliegue y la inicialización del contrato. Un constructor puede...

• … abortar el despliegue si falla la validación.
• … proporcionar inicialización única para variables de estado.

Además, el constructor sólo se ejecuta durante el despliegue. Por lo tanto, no tiene sentido guardarlo en la cadena.

Ahora estamos listos para definir la carga útil de datos de la transacción de despliegue, que claramente debe integrar la lógica del constructor.

De hecho, la carga útil de despliegue es una versión ligeramente modificada del código del constructor. Incluye toda la lógica del constructor, pero cuando se ejecuta con éxito, devuelve la parte del contrato inteligente que se escribirá en la cadena.

Hablo de una parte del contrato inteligente, ya que como se mencionó anteriormente, el constructor no se escribe en la cadena. La figura muestra la cadena de bloques recibiendo una transacción de despliegue y ejecutando el constructor. Finalmente, esto devuelve exitosamente el código del contrato o lo revierte, abortando el despliegue.

Despliegue de Contrato Inteligente

Desplegando un Contrato

Ahora es el momento de investigar la carga útil de despliegue de la transacción. He preparado un proyecto de Hardhat con un contrato simple.

Clonar e Instalar Dependencias

Para seguir el proceso, clona e instala las dependencias del proyecto:

git clone [email protected]:kaxxa123/BlockchainThings.git 

cd ./BlockchainThings/ContractBytecode

npm install

Configurar y Compilar

A continuación, necesitamos personalizar ligeramente el proyecto:

• Este código se ejecutará en cualquier cadena compatible con EVM. Aquí, Hardhat se configuró para ejecutarse en la red de prueba Avalanche Fuji. Se eligió Fuji debido a su grifo (faucet) fácil de usar que nos proporciona 2 AVAX sin complicaciones. Así que comienza por solicitar algunos AVAX de la red de prueba.

• En la carpeta ContractBytecode, cambia el nombre del archivo:

  De: ./BlockchainThings/ContractBytecode/.env_template

  A: ./BlockchainThings/ContractBytecode/.env

• Edita el archivo .env para establecer la clave privada de la cuenta a la que se enviaron los AVAX. Una vez listo, el contenido debería lucir algo como esto:

  PRIVATE_KEY_1=”0x1234567890abcd…..”

Ahora estamos listos para compilar el proyecto:

npx hardhat compile

El Código

A continuación, revisa el código del contrato con el que estaremos trabajando.

pragma solidity 0.8.18;

contract Demo {
   address public owner;
   uint public counter;

   constructor(uint start) payable {
       require (start > 100, "Demasiado pequeño");
       owner = msg.sender;
       counter = start;
   }

   function increase() external {
       ++counter;
   }
}

El constructor:

1. Toma un parámetro de entrada.
2. Incluye una cláusula require que podría abortar el despliegue.
3. Inicializa dos variables de estado.

Para simplificar nuestro ejemplo, el constructor está marcado como payable (pagadero). De lo contrario, el compilador inyectaría una segunda cláusula require asegurando que no se incluya ninguna cantidad de criptomoneda con la transacción de despliegue. Esto haría que el bytecode fuera más difícil de seguir.

Despliegue

Antes de adentrarnos en el bytecode, veamos qué datos se requieren al desplegarlo utilizando sendTransaction.

Anteriormente, compilamos el contrato inteligente, busca la salida resultante en ./artifacts/contracts/Demo.sol/Demo.json

Nos interesa especialmente:

bytecode - el código completo del contrato, incluido el constructor. deployedBytecode - la parte del código del contrato que excluye al constructor.

A continuación, ejecutamos una consola de node.js conectada a Avalanche Fuji:

npx hardhat console --network fuji

Verifica que el archivo .env se configuró correctamente al obtener la dirección de tu cuenta:

accounts = await ethers.getSigners() 
accounts[0].address

Carga el archivo de salida de compilación:

fs = require("fs") 
fs.readFile('./artifacts/contracts/Demo.sol/Demo.json', 'utf8', 
(err, data) => compile = JSON.parse(data))

Esto incluirá los valores de bytecode y deployedBytecode:

compile.bytecode 
compile.deployedBytecode

Estos valores están formateados de la siguiente manera:

compile.bytecode = Código de Inicialización (también conocido como constructor) | Parte del Contrato en la Cadena
compile.deployedBytecode = Parte del Contrato en la Cadena

Si el constructor no requiere parámetros de entrada, podríamos enviar una transacción con compile.bytecode como carga útil. Dado que tenemos un parámetro, esto debe agregarse al bytecode. Dejaré que ethers.js haga esto.

paramIn = 200
DemoFactory = await ethers.getContractFactory("Demo")
complete = await DemoFactory.getDeployTransaction(paramIn)
complete.data

El valor en complete.data tiene todo lo que necesitamos y está formateado de la siguiente manera:

complete.data = Código de Inicialización | Parte del Contrato en la Cadena | Parámetros del Constructor

Confirmamos que los valores que acabamos de discutir están realmente formateados como se describió...

// Eliminar el prefijo "0x" de las cadenas
bytecode = compile.bytecode.slice(2)
deployedBytecode = compile.deployedBytecode.slice(2)
bytecodeEx = complete.data.slice(2)

// Confirmar que el bytecode termina con deployedBytecode
assert(bytecode.length - bytecode.indexOf(deployedBytecode) ==  
    deployedBytecode.length)

// Confirmar que bytecodeEx comienza con bytecode
assert(bytecodeEx.indexOf(bytecode) == 0)

// Confirmar que el parámetro de entrada del constructor coincide con nuestra entrada
//'00000000000000000000000000000000000000000000000000000000000000c8'
param = bytecodeEx.slice(bytecode.length)
assert(parseInt(param, 16) == paramIn)

Bien, ahora estamos listos para desplegar el contrato utilizando sendTransaction con la carga útil complete.data:

trn = await accounts[0].sendTransaction({to: null, data: complete.data}) 
receipt = await trn.provider.getTransactionReceipt(trn.hash)

receipt.contractAddress

Y verificamos el despliegue ejecutando sus funciones:

abi = DemoFactory.interface.fragments 
addr = receipt.contractAddress 
demo = new ethers.Contract(addr, abi, accounts[0])

await demo.owner() 
await demo.counter() 
await demo.increase() 
await demo.counter()

El Bytecode

La mejor manera de ver cómo el código de inicialización incluye la lógica del constructor es pasando por el bytecode. El bytecode no es fácil de leer, pero si nos preparamos con algunos valores clave de referencia, se vuelve más sencillo. Aquí tienes una tabla de valores que veremos mientras recorremos el código.

A continuación, recorreremos los bytes individuales, convertiremos cada opcode utilizando una tabla como esta y para cada opcode determinaremos el estado de la pila. No muestro los valores almacenados en memoria, pero el código es lo suficientemente simple como para no requerir esto.

El orden del bytecode también se ajustó para que pueda leerse de manera secuencial. Básicamente, mi volcado muestra el índice del bytecode 7c justo después del salto en el índice 21 y luego vuelve al índice 22 cuando el código regresa.

Este código acaba de copiar el parámetro de entrada del constructor en la memoria.

Valores de la pila:

20 — tamaño del parámetro del ctr

80 — ubicación en memoria del parámetro del ctr

| 1a | 61 0022 | PUSH2 0022 | [22, a0, 80] | Empujar el valor 22 a la pila |
| 1d | 91 | SWAP2 | [80, a0, 22] | Intercambiar valores en la pila |
| 1e | 61 007c | PUSH2 007c | [7c, 80, a0, 22]| Empujar el valor 7c a la pila |
| 21 | 56 | JUMP | [80, a0, 22] | Saltar a la ubicación 7c |

Valores de la pila:

a0 — ubicación en memoria siguiente después del parámetro del

ctr 22 — ubicación para "volver" para continuar desde donde el código se detuvo

80 — ubicación en memoria del parámetro del ctr

Este código verificó el tamaño esperado de los parámetros ctr.

Valores de pila:

80 — ubicación de memoria del parámetro ctr
a0 — ubicación de memoria después del parámetro ctr

22 - ubicación de "retroceso"

Valores de la pila:

c8 — valor del parámetro de entrada del constructor

Este código verificó la condición requerida en:

require (start > 100, "Demasiado pequeño")

Si la verificación falla, el código no saltará y la secuencia de códigos que sigue se revierte.

Valores de pila:

c8 — valor del parámetro de entrada ctr

Cuando se cumple la condición require, el código continúa desde aquí…

Declaraciones de almacenamiento:

owner = msg.sender
counter = start

Este código maneja el caso de una ejecución exitosa del constructor que devuelve el código del contrato inteligente para escribirlo en la cadena.

Artículo original publicado por Alexander Zammit. Traducción de Paulinho Giovannini.