Quorum Blockchain: Estado Privado, Consenso y Operaciones Empresariales en Ethereum

Qué es Quorum y qué cubre esta guía

Quorum es una implementación permisionada de Ethereum. La línea de cliente mantenida es GoQuorum, un fork ligero de Go Ethereum (geth) que conserva el modelo de cuentas, la EVM, la superficie JSON-RPC y las herramientas de Solidity de Ethereum, al tiempo que cambia el consenso, la admisión de pares y el manejo del estado. El proyecto original se inició en J.P. Morgan y posteriormente pasó a la tutela de ConsenSys; el repositorio upstream archivado es de solo lectura, así que fije la versión específica del cliente y la distribución que pretende operar en lugar de asumir un upstream en evolución.

La pregunta práctica que responde Quorum no es "cómo hacemos Ethereum más rápido" sino "cómo comparten varias organizaciones un solo libro mayor sin difundir cargas útiles comercialmente sensibles a todos los participantes". Ese enfoque impulsa cada decisión de diseño a continuación. Esta guía cubre el modelo de estado, las familias de consenso, un flujo de trabajo ejecutable de transacciones privadas, la verificación, la solución de problemas y los límites que debe sopesar antes de comprometerse.

Nota de alcance: esta página explica el mecanismo y la metodología. No recomienda un endpoint gestionado ni un proveedor de hosting específico; si necesita una decisión concreta de endpoint RPC para una red compatible con Ethereum, utilice el Asistente de RPC en lugar de tratar esta página como una comparación de proveedores.

• Asume familiaridad con cuentas de Ethereum, gas y contratos Solidity.
• Asume que puede ejecutar Docker o varios procesos de host para una red de prueba pequeña.
• Todos los comandos usan marcadores de posición como RPC_URL y PRIVATE_KEY; sustituya sus propios valores.

Estado público, estado privado y el gestor de privacidad

Un nodo de Quorum mantiene dos árboles de estado. El árbol de estado público se comporta como Ethereum: cada nodo ejecuta transacciones públicas y valida la raíz del estado público global registrada en la cabecera del bloque. El árbol de estado privado contiene el resultado de las transacciones privadas y existe solo en los nodos cuyo gestor de privacidad fue destinatario de esa transacción. La validación de bloques se modificó para que la cabecera se comprometa con la raíz del estado público, por lo que todos los nodos pueden ponerse de acuerdo sobre la validez del bloque sin poseer datos privados idénticos.

Las transacciones privadas están mediadas por un gestor de privacidad (históricamente Tessera, y Constellation en despliegues anteriores) que se ejecuta junto al nodo. Cuando envía una transacción privada, la carga útil se cifra con las claves de los destinatarios y se distribuye a través de la red de gestores de privacidad; la cadena en sí solo recibe un hash de la carga útil cifrada. Los nodos destinatarios recuperan la carga útil, la descifran y la ejecutan contra su estado privado local. Los no destinatarios ven una transacción con un hash de carga útil que no pueden resolver, por lo que su estado privado no se modifica.

Este es el modelo mental que debe retener: la cadena es la capa de coordinación compartida y el gestor de privacidad es el canal lateral que transporta el contenido confidencial. Casi todos los problemas operativos de Quorum se reducen a un desajuste entre esas dos capas: un nodo que tiene el bloque pero no la carga útil, o una carga útil entregada a la clave equivocada.

Opciones de consenso y el modelo de confianza que codifican

Quorum reemplaza la prueba de trabajo por consenso basado en votación. Raft es un algoritmo tolerante a fallos de caída: asume que los nodos fallan pero no mienten activamente, y produce una finalidad rápida con un líder que añade entradas. Istanbul BFT (y su sucesor QBFT en versiones posteriores de GoQuorum) es tolerante a fallos bizantinos: tolera una fracción acotada de validadores maliciosos o divergentes a costa de rondas de mensajes adicionales.

La elección es una decisión de confianza, no un ajuste de rendimiento. Si cada validador es operado por su propia organización o por contrapartes vinculadas por acuerdos legales y control operativo compartido, los supuestos de Raft son defendibles y el protocolo es más simple. Si los validadores son operados de forma independiente y uno podría equivocarse, necesita una familia BFT. Documente el supuesto explícitamente, porque una red que ejecuta Raft en silencio entre partes que desconfían mutuamente tiene una postura de seguridad que nadie escribió.

La permisionación es la segunda mitad del modelo de confianza. La capa entre pares se modifica para que los nodos se conecten solo a pares permitidos, y la permisionación a nivel de cuenta puede restringir quién puede desplegar o llamar contratos. Trate la configuración de permisionación como código de producción: versiónela, revise los cambios y pruebe las rutas de admisión y revocación antes de necesitarlas.

• Raft: tolerancia a fallos de caída, adición basada en líder, adecuado para redes de un solo operador o estrechamente federadas.
• IBFT/QBFT: tolerancia a fallos bizantinos, adecuado para validadores operados de forma independiente.
• Permisionación: admisión de pares más restricciones opcionales de cuenta/rol; pruebe la revocación, no solo la admisión.

Requisitos previos para una red de prueba reproducible

Antes de ejecutar el procedimiento a continuación, confirme que tiene un despliegue de Quorum en funcionamiento con al menos cuatro nodos, un gestor de privacidad por nodo y una cuenta con fondos en el nodo que utilizará como objetivo RPC. Las herramientas exactas de arranque varían según la distribución: algunos equipos usan la configuración de Compose al estilo Quorum Dev Quickstart, otros usan su propio génesis y configuración estática de nodos. El procedimiento es deliberadamente independiente de la herramienta para que sobreviva a los cambios de distribución.

También necesita una forma de acceder a la interfaz JSON-RPC del nodo. Para una red de prueba local, normalmente es http://127.0.0.1:8545 en el primer nodo; para cualquier cosa compartida, coloque el endpoint detrás de sus controles de acceso habituales y nunca exponga una cuenta desbloqueada a través de una interfaz abierta. Si está evaluando cómo exponer RPC compatible con Ethereum de forma segura a escala, la guía sobre alojamiento de nodos blockchain es un complemento útil.

Registre lo siguiente antes de comenzar: la URL RPC de un nodo participante, la URL RPC de un nodo no participante, la clave pública de cada gestor de privacidad y la dirección de una cuenta con fondos. Comparará los dos nodos al final, y esa comparación es la prueba real.

Despliegue y llamada a un contrato privado

El flujo de trabajo a continuación utiliza web3.js contra un nodo en ejecución. El detalle crítico es el campo privateFor (o privacyGroupId en configuraciones más recientes del gestor de privacidad): nombra los destinatarios cuyos gestores de privacidad deben recibir la carga útil. Omítalo y la transacción será pública, que es la causa más común de los informes de "mis datos privados son visibles".

Primero, confirme que el nodo es accesible y verifique qué versión de API del gestor de privacidad espera. La llamada curl a continuación es una comprobación de solo lectura.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Expected: a JSON result containing a hex block number, e.g. {"jsonrpc":"2.0","id":1,"result":"0x1a"}
# A connection error means the node is down or the URL/port is wrong;
# a JSON-RPC error usually means the method or params are malformed.

Script de despliegue privado y salida esperada

El script a continuación despliega un contrato mínimo con un único valor almacenado, enviándolo de forma privada a una contraparte. Reemplace los marcadores de posición con sus propios valores. La clave pública del destinatario es la clave del gestor de privacidad del nodo de la contraparte, no una dirección de cuenta de Ethereum; confundirlos es el segundo fallo más común.

Después del despliegue, lea el valor tanto desde el nodo participante como desde el nodo no participante. El nodo participante debería devolver el valor almacenado; el nodo no participante debería devolver el valor cero o fallar al resolver el estado privado del contrato, porque nunca recibió la carga útil.

const Web3 = require('web3');
const web3 = new Web3(process.env.RPC_URL);

const abi = [{"inputs":[],"name":"value","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint256","name":"v","type":"uint256"}],"name":"setValue","outputs":[],"stateMutability":"nonpayable","type":"function"}];
const bytecode = '0x...'; // compiled contract bytecode

async function main() {
  const account = web3.eth.accounts.privateKeyToAccount(process.env.PRIVATE_KEY);
  web3.eth.accounts.wallet.add(account);

  const contract = new web3.eth.Contract(abi);
  const deploy = contract.deploy({ data: bytecode });

  const tx = {
    from: account.address,
    data: deploy.encodeABI(),
    gas: 3000000,
    privateFor: [process.env.RECIPIENT_PRIVACY_PUBLIC_KEY],
  };

  const receipt = await web3.eth.sendTransaction(tx);
  console.log('contract address:', receipt.contractAddress);
  console.log('transaction hash:', receipt.transactionHash);
}

main().catch((e) => { console.error(e); process.exit(1); });

Verificación: cómo se ve un resultado correcto

La verificación tiene tres capas, y aprobar solo una de ellas no es prueba de privacidad. Primero, confirme que la transacción está minada y tiene un recibo en la cadena pública; todos los nodos deberían estar de acuerdo en que la transacción existe. Segundo, confirme que el nodo participante puede leer el estado privado: llame a la función de vista del contrato y espere el valor que estableció. Tercero, confirme que el nodo no participante no puede: la misma llamada debería devolver cero, revertir o fallar de otro modo al exponer el valor.

Registre los resultados en una tabla para que el resultado sea auditable en lugar de anecdótico. No complete números que no haya observado; la tabla a continuación es una plantilla y los valores deben provenir de su propia ejecución.

• Hash de transacción presente en todos los nodos: sí/no.
• Estado del recibo exitoso en todos los nodos: sí/no.
• Valor privado legible en el nodo participante: valor observado.
• Valor privado legible en el nodo no participante: valor observado o error.
• Los registros del gestor de privacidad muestran entrega de la carga útil solo al destinatario previsto: sí/no.

Solución de problemas de transacciones privadas fallidas

La mayoría de los fallos se agrupan en un pequeño conjunto de categorías. Revíselos en orden, porque los síntomas posteriores a menudo enmascaran causas anteriores.

Si la transacción está minada pero el estado privado está vacío en el destinatario previsto, la carga útil nunca llegó. Revise los registros del gestor de privacidad en ambos lados para detectar errores de entrega y descifrado, confirme que la clave pública del destinatario coincide con la clave real del gestor de privacidad de la contraparte y confirme que el gestor de privacidad es accesible desde el nodo del remitente. Una rotación de claves en un lado sin actualizar el otro es una causa clásica.

Si la transacción se rechaza antes de la minería, revise primero el gas y el nonce, luego la permisionación. Una transacción privada sigue consumiendo gas en la cadena pública aunque la carga útil sea confidencial, y la permisionación a nivel de cuenta puede rechazar a un remitente que es válido en otro nodo. Si solo algunos nodos la rechazan, compare su configuración de permisionación en lugar de su configuración de consenso.

Si el consenso se estanca, distinga un líder caído de un validador particionado. En Raft, un líder estancado normalmente se recupera tras la elección; en las familias BFT, la pérdida de quórum produce una falta visible de progreso en lugar de una divergencia silenciosa. Verifique los recuentos de pares y la vitalidad de los validadores antes de tocar el código de la aplicación.

Limitaciones y compensaciones a considerar antes de comprometerse

El modelo de privacidad de Quorum es confidencialidad entre participantes, no secreto criptográfico contra el operador. Un nodo que posee la clave de descifrado puede leer la carga útil, y el gestor de privacidad es un componente de confianza en la arquitectura. Si su modelo de amenaza incluye al operador de la infraestructura, Quorum por sí solo no lo aborda.

El ecosistema se ha consolidado. El repositorio upstream de GoQuorum está archivado y es de solo lectura, por lo que el mantenimiento a largo plazo depende de la distribución o el proveedor que elija. Planifique la fijación de versiones, una ruta de actualización probada y una estrategia de salida. La compatibilidad con las herramientas de Ethereum pública es una ventaja genuina, pero es compatibilidad con un objetivo en movimiento, no una garantía.

Las afirmaciones de rendimiento deben tratarse como dependientes de la carga de trabajo. El consenso por votación elimina la sobrecarga de la prueba de trabajo, pero el rendimiento está limitado por los límites de gas por bloque, la latencia del gestor de privacidad y el número de destinatarios por transacción privada. Mida en su propia topología con su propia mezcla de contratos; no adopte una cifra de transacciones por segundo de la página de un proveedor como dato de planificación.

Por último, considere si necesita una red privada en absoluto. Si el requisito de confidencialidad es limitado, una red pública compatible con Ethereum con cifrado a nivel de aplicación puede ser más sencilla de operar. Si necesita un nodo gestionado para una red compatible con Ethereum mientras evalúa, las opciones de nodo dedicado y la página de precios de RPC describen el modelo operativo.

Próximos pasos y lecturas relacionadas

Una vez que el procedimiento de verificación pase, el siguiente trabajo es operativo en lugar de conceptual: automatice las comprobaciones de estado del gestor de privacidad, añada la verificación de tres capas a su canal de CI para las actualizaciones de contratos y ensaye la rotación de claves de validadores y la revocación de pares. Esos simulacros son lo que separa una red de demostración de una que puede ejecutar en producción.

Para obtener un contexto más amplio sobre la ejecución de infraestructura blockchain, la guía de alojamiento de nodos cubre patrones de aprovisionamiento y monitoreo que también se aplican a los nodos de Quorum. Si está comparando Quorum con despliegues en redes públicas, la guía de endpoints RPC multicadena explica cómo funciona la abstracción de endpoints entre redes, y el directorio de redes enumera las cadenas que OnFinality admite. Cuando esté listo para elegir un endpoint concreto para una red compatible con Ethereum, el Asistente de RPC ofrece una recomendación directa en lugar de una comparación extensa.