Desarrollo de protocolos blockchain
El desarrollo de protocolos blockchain consiste en diseñar la capa base de una red: mecanismo de consenso, estructura de bloques, modelo de incentivos y reglas de validación. Es distinto de programar aplicaciones sobre una red ya existente. Unknown Gravity diseña e implementa protocolos propios y capas de segundo nivel.
Diseñamos protocolos blockchain desde la capa de consenso: especificación técnica, red de pruebas y documentación para que tu equipo opere los nodos.
Antes de escribir código te decimos si de verdad necesitas una red propia. La mayoría de proyectos no la necesita.
01 / Qué es un protocolo blockchain y cuándo necesitas uno propio
Un protocolo blockchain es el conjunto de reglas que define quién puede escribir en la red, cómo se ordenan las transacciones, qué bloque es válido y cómo se resuelven los desacuerdos entre nodos.
Construir uno propio tiene sentido en pocos escenarios concretos: el modelo de ejecución no cabe en una máquina virtual existente; la confidencialidad entre participantes exige que ningún tercero vea las transacciones; la latencia o el coste por operación de las redes públicas rompen el caso de uso; o un consorcio necesita repartir el poder de validación entre sus miembros con reglas acordadas de antemano.
02 / Cuándo NO necesitas un protocolo propio
En la mayoría de proyectos que llegan a nuestra mesa la respuesta correcta es desplegar sobre una L1 o L2 que ya existe.
Una red pública madura te da validadores que no pagas, herramientas probadas, auditores que conocen el entorno, custodios y exchanges ya integrados, y usuarios que no instalan nada nuevo. Una cadena propia arranca sin nada de eso.
Señales claras de que no te hace falta: tu lógica cabe en contratos inteligentes, necesitas que los tokens circulen en mercados existentes, tu equipo no va a mantener infraestructura 24/7 o el volumen previsto no justifica una red dedicada. Si lo que buscabas era control o privacidad, suele resolverse con una red permisionada o con un despliegue sobre Ethereum y redes EVM.
03 / Consenso, nodos y gobernanza: las tres decisiones que lo condicionan todo
Consenso: quién valida y con qué incentivo. Proof of Stake, Proof of Authority o BFT permisionado no son intercambiables: cambian el número mínimo de validadores, la tolerancia a fallos, la finalidad y qué ocurre cuando un operador cae o actúa de mala fe.
Nodos: cuántos, quién los opera y en qué jurisdicciones. Cuatro nodos del mismo proveedor no son una red descentralizada; son un punto único de fallo con pasos de más.
Gobernanza: cómo se aprueban los cambios de parámetros y las actualizaciones de protocolo, y qué pasa si los operadores no se ponen de acuerdo. Cerrarlo antes del lanzamiento evita bifurcaciones improvisadas. Si el modelo incluye voto on-chain, lo tratamos en gobernanza y votaciones.
04 / El coste real de mantener una red propia
Una red propia no termina el día del lanzamiento: empieza ahí.
Hay que sostener validadores y nodos de archivo, monitorización y alertas, actualizaciones coordinadas entre operadores, respuesta a incidentes fuera de horario, explorador y endpoints RPC para que alguien pueda usar la cadena, y documentación viva para los operadores que entren después. Eso son personas y facturas recurrentes, no un pago único.
Si el protocolo emite un token nativo, su clasificación jurídica condiciona el diseño: MiCA cubre criptoactivos y tokens de utilidad, mientras que un token con naturaleza de instrumento financiero queda fuera de MiCA y bajo normativa de valores (LMVSI, MiFID II), con la figura ERIR para el registro. Para situarte puedes usar el clasificador MiCA/MiFID; el criterio jurídico lo firma tu asesor.
05 / Qué recibes: especificación, testnet y documentación de nodo
Trabajamos por fases y cada una cierra con un entregable revisable.
- Especificación técnica: modelo de consenso, formato de bloque y transacción, parámetros de red, política de comisiones, permisos y criterios de finalidad.
- Testnet operativa: red de pruebas con varios validadores, faucet, explorador y datos de ejemplo para que tu equipo pruebe contra algo real.
- Documentación de nodo: requisitos de hardware, instalación, arranque desde génesis, sincronización, custodia y rotación de claves y procedimiento de actualización.
- Plan de operación: métricas a vigilar, umbrales de alerta y runbook de incidentes.
Somos una consultora con base en Málaga: 75+ proyectos entregados, 30+ clientes y 0 hacks en producción. Si tu caso se resuelve mejor sin red propia, te lo diremos en la primera reunión.
FAQ
Preguntas frecuentes
¿Cuándo compensa un protocolo propio frente a una L2 existente?
Compensa cuando necesitas reglas de validación o de privacidad que una red pública no permite, cuando un consorcio debe repartir el poder de validación entre sus miembros o cuando la latencia y el volumen justifican infraestructura dedicada. Si tu lógica cabe en contratos inteligentes y quieres liquidez desde el primer día, una L2 existente sale antes y más barata.
¿Con qué mecanismos de consenso trabajáis?
Proof of Stake, Proof of Authority y variantes BFT permisionadas, además de despliegues sobre pilas ya existentes del ecosistema EVM. La elección depende del número de operadores, del nivel de confianza entre ellos y de si la finalidad debe ser inmediata o probabilística.
¿Se puede actualizar un protocolo después de su lanzamiento?
Sí, y se planifica desde el diseño: versionado, ventanas de actualización coordinada entre operadores y compatibilidad hacia atrás para evitar bifurcaciones no deseadas. Cuanto más tarde se define la gobernanza de las actualizaciones, más caro sale cada cambio.