Cómo crear un proyecto blockchain: decisiones y fases

Un proyecto blockchain combina una necesidad de negocio con un sistema que permite compartir y verificar información entre participantes. Puede tratarse de registrar operaciones, representar un activo o coordinar un proceso entre organizaciones. Convertir esa idea en un producto requiere definir qué hará cada participante y cómo se conectará la nueva solución con los sistemas existentes.

La primera decisión consiste en determinar si ese proceso necesita un registro compartido y qué mejora se espera obtener. A partir de ahí se pueden comparar arquitecturas, concretar un piloto y organizar el desarrollo. Una base de datos con permisos puede ser suficiente para algunos casos; la elección debe responder a las necesidades del proyecto.

1. Define el problema y la prueba de éxito

Identifica usuarios, entidades participantes y conflictos de información. En una trazabilidad de mercancías, por ejemplo, distingue la prueba de que alguien registró una recepción de la prueba de que la mercancía llegó en buen estado. La segunda necesita controles físicos y responsables, aunque la primera se ancle en una red.

Acuerda una medida de resultado antes de programar: tiempo de conciliación, errores de registro o facilidad para verificar una evidencia. Define también un proceso de excepción. Un piloto que no contempla errores y excepciones todavía no demuestra que el producto sea operable.

2. Decide qué vive dentro y fuera de la cadena

Los contratos pueden compartir reglas de autorización y transferencia; los documentos, búsquedas y datos personales suelen requerir otros sistemas. La anatomía de un contrato en Ethereum ayuda a distinguir estado persistente y funciones ejecutadas por transacciones.

Dibuja el recorrido completo: interfaz, wallet o firma, nodo RPC, contrato, almacenamiento e integraciones. Indica quién opera cada pieza y qué ocurre si falla. Ese mapa aclara la dependencia real de proveedores y administradores mejor que una etiqueta genérica de «descentralizado».

3. Elige red y herramientas con requisitos medibles

Compara permisos de participación, finalidad, costes bajo carga, privacidad, herramientas y experiencia del equipo. Una red EVM facilita reutilizar conocimientos de Solidity, pero la compatibilidad no hace idénticos sus puentes, gobierno ni condiciones operativas.

Prueba las operaciones representativas antes de decidir. Incluye transacciones rechazadas y picos de uso; una media de comisiones no explica el coste de un proceso completo. La documentación de gas de Ethereum explica cómo el trabajo de ejecución y el precio del gas contribuyen al coste.

4. Emite un token solo si cumple una función

No todo proyecto blockchain necesita token propio. Un registro de evidencias puede funcionar sin emitir un activo; un sistema de pagos puede usar un activo existente. Si hace falta un token, define los derechos, restricciones, responsables y condiciones de recuperación antes de elegir un estándar.

La clasificación jurídica depende del producto, las actividades y la jurisdicción. En la UE, MiCA no sustituye toda la normativa financiera. La CNMV explica su ámbito y autorizaciones. La evaluación regulatoria debe acompañar al diseño, no añadirse al terminar el código.

5. Construye un piloto que permita encontrar fallos

• Especifica permisos y propiedades que nunca deben romperse.
• Prueba contratos e integraciones con errores, límites y datos inesperados.
• Documenta cómo se actualiza el sistema y quién puede hacerlo.
• Revisa de forma independiente las partes que custodian valor o autorizan operaciones críticas.

La auditoría no cierra el proyecto: permite resolver hallazgos y volver a comprobar la versión corregida. Mantén vinculados requisitos, código, pruebas e informe para que el despliegue sea trazable.

Qué debería demostrar el piloto antes de ampliar su alcance

Para un registro compartido de mercancías, un piloto podría seguir una entrega entre fabricante, transportista y receptor. Cada actor registra únicamente los eventos que le corresponden y el sistema permite localizar discrepancias. El objetivo de la prueba sería reconstruir el recorrido con evidencias identificables, no demostrar que cualquier dato introducido es verdadero.

Incluye una recepción discutida, una corrección y la indisponibilidad temporal de un participante. Define cómo se conserva el evento original y quién puede añadir una rectificación. Si todo debe resolverse editando manualmente una base de datos sin trazabilidad, el piloto todavía no acredita la propiedad que pretendía aportar el registro compartido.

Antes de pasar a producción, compara ese recorrido con la alternativa convencional utilizando los mismos casos y criterios. Registra el trabajo necesario para integrar sistemas existentes y atender excepciones. El resultado puede justificar ampliar el proyecto, reducir el alcance o prescindir de una cadena; cualquiera de esas decisiones necesita evidencia.

El cierre del piloto debería entregar requisitos contrastados, límites conocidos y un presupuesto de operación. Así la siguiente inversión se apoya en lo aprendido sobre el proceso, en lugar de asumir que una demostración técnica equivale a un producto listo para todos los participantes.

6. Lanza con responsables y continuidad

Prepara monitorización, copias de los datos recuperables, gestión de claves y respuesta a incidentes. La interfaz debe explicar el estado de una operación y evitar que el usuario repita una transacción que sigue pendiente.

El entregable de un proyecto incluye código, documentación, acceso a infraestructura y procedimientos de operación. En Metlabs, el desarrollo blockchain a medida parte de esa arquitectura completa, con un alcance que el equipo pueda probar y mantener.