La plataforma Besu de Oracle: código EVM, permisos distintos

Un anuncio con disponibilidad limitada

El 27 de octubre de 2026, Oracle publicó una presentación de Blockchain Platform Enterprise Edition 26.3.1. Describe un conjunto integrado de servicios para aplicaciones de activos digitales con permisos y señala Limited Availability en octubre de 2026, es decir, disponibilidad limitada. Es un anuncio de producto con un alcance de acceso restringido, no una prueba de que esas aplicaciones ya estén funcionando en determinadas entidades financieras.^[1]

La versión también importa al leer el titular. La documentación anterior de 26.2 ya incluye validadores Besu que utilizan QBFT, acceso mediante Ethereum JSON-RPC y un servicio de carteras en custodia. Por tanto, no corresponde presentar Besu, QBFT ni la firma en custodia como capacidades que aparecen por primera vez en este anuncio. La pregunta útil es cómo se reparten las funciones los controles descritos.^[3][1]

Instrucciones compatibles, un registro separado

La arquitectura de 26.3 ejecuta contratos Solidity en la máquina virtual de Ethereum, o EVM. Expone interfaces de Ethereum a través del RPC Proxy, el servicio por el que las aplicaciones envían sus solicitudes. Sin embargo, la misma documentación describe redes privadas de Ethereum con permisos, con sus propias instancias Besu y funciones de nodo.^[2]

La compatibilidad de ejecución y la participación en una red son propiedades distintas. Usar EVM no hace que una transacción se registre por sí sola en Ethereum público. En este diseño, se dirige a la red Besu configurada. Para comprender la aplicación hay que saber quién opera esa red y quién puede participar, además de qué lenguaje de contratos acepta.^[2]

Firmar una solicitud no es acordar un bloque

Oracle separa las tareas. El RPC Proxy identifica la organización del solicitante y aplica los controles de acceso de la plataforma. Universal Wallet as a Service, o UWaaS, proporciona servicios de carteras en custodia y políticas; un servicio de cartera por instancia realiza las operaciones de firma y difusión específicas de Besu. El servicio de firma gestiona las claves en nombre de los usuarios, en lugar de exigir que la aplicación maneje directamente las claves privadas.^[2]

Los validadores Besu utilizan QBFT para acordar los bloques. Oracle describe una validación compartida por organizaciones autorizadas y finalidad determinista para las transacciones confirmadas por el consenso, dentro de los límites de tolerancia a fallos del protocolo. Una firma válida, el permiso para enviar una solicitud y el acuerdo sobre su lugar en el registro son partes distintas del recorrido. La etiqueta «compatible con EVM» no identifica quién controla cada una.^[1][2]

Las versiones de los contratos tienen su propia aprobación

El anuncio describe un modo de despliegue sujeto a gobernanza en el que los contratos empiezan inactivos. Se activan después de que las aprobaciones configuradas queden registradas en cadena mediante un contrato Governance. Las actualizaciones siguen la misma vía de aprobación. Es un modo y una política que la organización elige y opera; no significa que todo contrato Solidity reciba automáticamente estos controles.^[1]

El registro de contratos conserva artefactos por versión, como la ABI, el bytecode y la disposición del almacenamiento. Describen cómo el software llama a un contrato, qué código se despliega y cómo se organiza su estado. Así, los revisores pueden aprobar una implementación concreta y se dispone de contexto para interpretar estados históricos. Esa aprobación de la versión es una decisión distinta del acuerdo de los validadores sobre los bloques.^[1]

El historial SQL es una vista del registro

Rich History puede copiar e indexar transacciones, eventos, trazas de ejecución y estado en Oracle Database o MySQL. Los administradores pueden consultar los datos con SQL y combinarlos con registros empresariales externos para elaborar informes o conciliaciones. La descripción de 26.3 indica expresamente que Rich History y los nodos de archivo son opcionales.^[2][4]

La arquitectura distingue esa vista histórica de la ejecución y el consenso: los validadores acuerdan los bloques y los componentes de Rich History incorporan información del registro. Los miembros del consorcio pueden compartir una base de datos proporcionada por la organización fundadora o mantener bases separadas conectadas a sus propios nodos. Un resultado SQL consulta, por tanto, un historial capturado; no constituye una nueva ronda de acuerdo entre validadores.^[2][4]

Leer los controles además de la etiqueta

El anuncio de Oracle ofrece un ejemplo concreto de varias decisiones independientes alrededor de un código de contrato conocido: participación en la red, custodia de claves, aprobación de versiones y consultas históricas. La documentación explica el comportamiento previsto de la plataforma. Ni la disponibilidad anunciada ni la arquitectura demuestran un despliegue en producción en una institución concreta, ni convierten estas redes privadas en parte de Ethereum público. Esas distinciones permiten entender el alcance del anuncio.^[1][2]