# Compilación reproducible

> Receta con solc 0.8.37, hash de la entrada exacta y comprobaciones de fuentes, artefactos y código desplegado.

Source: https://docs.botradix.com/es/reproducible-build/

Una compilación reproducible permite comprobar que unas fuentes y ajustes concretos producen los artefactos esperados. Es una comprobación de correspondencia; **no es una auditoría de seguridad** ni demuestra que una implementación siga activa. Para esto último hay que [leer las rutas de los proxies](https://docs.botradix.com/es/proxies/) en un bloque determinado.

## Compilador y ajustes

La receta de referencia v2.2 utiliza:

| Ajuste | Valor |
|---|---|
| Solidity | `solc 0.8.37+commit.f401782d` |
| Lenguaje de entrada | `Solidity`, formato Standard JSON |
| Optimizador | `enabled: true`, `runs: 200` |
| Compilación mediante IR | `viaIR: true` |
| EVM objetivo | `evmVersion: "paris"` |
| Hash de metadatos en bytecode | `metadata.bytecodeHash: "none"` |
| Dependencias de la entrada de referencia | OpenZeppelin `5.6.1`, incluidas con sus nombres de unidad originales |

Este es el fragmento de ajustes que afecta a la receta. Para compilar se usa la entrada completa, incluidas las fuentes y `outputSelection`, sin reconstruirla a partir del fragmento:

```json
{
  "optimizer": { "enabled": true, "runs": 200 },
  "viaIR": true,
  "evmVersion": "paris",
  "metadata": { "bytecodeHash": "none" }
}
```

## Identificar la entrada exacta

La entrada Standard JSON reúne el contenido de las fuentes y dependencias bajo sus rutas originales. Conserva nombres de archivo, nombres de unidades importadas, ajustes y versiones. No sustituyas dependencias por la versión más reciente ni combines fuentes de varias entregas.

**Referencia documental: 11 de octubre de 2026.** La entrada `v22.standard-input.json` del paquete de referencia `20261011-145007` contiene 54 unidades. Su SHA-256, calculado sobre los bytes del archivo, es:

```text
54a204b3dd61ceb7196f84c7337927fbf5b3af5c721e6eac1319487da050ddf6
```

Este hash identifica esa entrada concreta, no un paquete final aún por publicar. Cambiar comentarios o el formato del JSON cambia el hash del archivo aunque el bytecode pueda seguir siendo idéntico. La publicación deberá identificar su propia entrada y su SHA-256, junto con el resultado de la comparación de bytecode.

**Estado de publicación:** las fuentes verificadas se publicarán conjuntamente en BaseScan cerca del cierre. La descarga pública de la entrada final y sus artefactos está pendiente; no se presenta aquí una URL de descarga que aún no está disponible.

## Reproducir sin publicar

Con el compilador exacto ya instalado y la entrada completa disponible, trabaja en un directorio local. Estos comandos no envían transacciones ni publican código:

```bash
solc --version
sha256sum v22.standard-input.json
solc --standard-json < v22.standard-input.json > v22.compiler-output.json
```

Comprueba que la versión incluye `0.8.37+commit.f401782d` y que el hash corresponde al archivo de la entrega que estás verificando. El hash anterior solo corresponde a la entrada de referencia indicada. Si una entrada tiene todas las fuentes embebidas, no necesita resolver importaciones por red.

Comprueba además los errores del JSON de salida: el código de salida del proceso, por sí solo, no demuestra que Solidity haya compilado correctamente.

```python
import json
from pathlib import Path

result = json.loads(Path("v22.compiler-output.json").read_text())
errors = [item for item in result.get("errors", []) if item.get("severity") == "error"]
for item in errors:
    print(item.get("formattedMessage", item.get("message", "")))
assert not errors, "Solidity compilation failed"
assert result.get("contracts"), "No contract output"
print("Compilation completed; compare artifacts next")
```

Revisa también los avisos y conserva compilador, entrada, salida y hashes. No hace falta una wallet, una clave privada ni una clave de API para esta compilación local.

## Comparar los artefactos y el despliegue

Compara por **nombre de unidad y nombre de contrato**, no solo por nombre de archivo de salida. Para fuentes idénticas deben compararse tanto `evm.bytecode.object` (creación) como `evm.deployedBytecode.object` (runtime), junto con ABI y disposición de almacenamiento cuando se evalúe una actualización.

El runtime del compilador puede contener ubicaciones para valores `immutable` que el constructor fija al desplegar. La comprobación de una dirección debe resolver `immutableReferences`, argumentos de constructor y, si existen, referencias a librerías enlazadas. El código de creación y los argumentos del constructor tampoco son lo mismo. No descartes diferencias arbitrarias para forzar una coincidencia.

`bytecodeHash: "none"` omite el hash de metadatos del bytecode; no significa que cualquier cambio de fuentes sea inocuo ni que desaparezca toda información de metadatos. Un cambio solo de comentarios puede conservar el código generado, pero hay que recompilar y comparar para demostrarlo. Cambiar lógica, literales o nombres usados para calcular identificadores puede cambiar el resultado.

La comparación con código en cadena requiere indicar red, dirección y bloque, y tratar por separado anfitrión, implementaciones y módulos. Una coincidencia del proxy no acredita la lógica a la que delega. Consulta [Seguridad y contratos](https://docs.botradix.com/es/security-contracts/) para el alcance de las revisiones y los cambios posibles mientras las piezas estén OPEN.