작동 원리약 4분

Oracle의 Besu 플랫폼: EVM 호환과 공개 체인은 다르다

Oracle의 26.3.1 발표는 Besu를 둘러싼 기업용 플랫폼을 설명한다. 계약 실행, 참여 권한, 수탁 서명, 배포 승인, SQL 이력 조회는 서로 다른 역할이다.

Oracle의 Besu 플랫폼: EVM 호환과 공개 체인은 다르다

코드 호환성과 참여 허가를 구분한 AI 생성 개념도. 실제 Oracle 시설이나 확인된 도입 사례를 재현한 장면이 아니다.

핵심 요약

  • Oracle은 10월 27일 발표에서 26.3.1을 10월 Limited Availability로 명시했다. Besu·QBFT·수탁 지갑은 이미 26.2 문서에 있었다.
  • EVM 호환은 계약 실행에 관한 설명이다. 승인된 검증자, 지갑 서명, 계약 배포 승인은 각각 다른 결정을 담당한다.
  • Rich History는 원장 활동을 SQL로 조회하기 위한 선택적 색인이다. 조사와 보고에 쓰이며 블록체인 합의를 대체하지 않는다.

사건의 흐름 한눈에 보기

2026-10-27Oracle이 26.3.1 플랫폼을 소개

디지털 자산 애플리케이션의 통합 제어 기능을 설명하며 2026년 10월 Limited Availability라고 명시했다.

제한된 제공 범위를 가진 발표

2026년 10월 27일, Oracle은 Blockchain Platform Enterprise Edition 26.3.1을 소개했다. 허가형 디지털 자산 애플리케이션을 위한 통합 구성을 설명하면서 제공 상태를 2026년 10월 Limited Availability, 즉 제한적 제공으로 명시했다. 제품과 제공 범위에 대한 발표이지, 설명된 애플리케이션이 특정 금융기관에서 이미 가동됐다는 증거는 아니다.[1]

제목을 읽을 때는 버전도 살펴야 한다. 이전 26.2 문서에도 QBFT를 쓰는 Besu 검증자, 이더리움 JSON-RPC 인터페이스와 수탁 지갑 서비스가 등장한다. 따라서 이번 발표를 Besu·QBFT·수탁 서명의 첫 지원으로 소개해서는 안 된다. 살펴볼 만한 지점은 문서에 나온 제어 기능들이 어떻게 역할을 나누느냐다.[3][1]

같은 실행 규칙을 써도 원장은 별개다

26.3 아키텍처는 이더리움 가상머신인 EVM에서 Solidity 계약을 실행한다. 애플리케이션의 요청을 받는 RPC Proxy를 통해 이더리움 방식의 인터페이스를 제공한다. 그러나 같은 문서는 이를 독자적인 Besu 인스턴스와 노드 역할을 가진 허가형 사설 이더리움 네트워크로 설명한다.[2]

실행 호환성과 네트워크 참여 권한은 다른 속성이다. EVM을 쓴다고 거래가 저절로 퍼블릭 이더리움에 기록되는 것은 아니다. 이 설계에서 거래는 설정된 Besu 네트워크로 향한다. 애플리케이션을 이해하려면 어떤 계약 언어를 받는지와 함께 누가 네트워크를 운영하고 누가 참여할 수 있는지 알아야 한다.[2]

요청에 서명하는 일과 블록에 합의하는 일

Oracle은 역할을 나눠 놓았다. RPC Proxy는 호출자의 조직을 확인하고 플랫폼 접근 권한을 적용한다. Universal Wallet as a Service, 즉 UWaaS는 수탁 지갑과 정책 서비스를 제공하고, 인스턴스별 지갑 서비스는 Besu용 서명과 거래 전파를 담당한다. 애플리케이션이 개인키를 직접 다루도록 하는 대신 서명 서비스가 사용자를 대신해 키를 관리하는 구조다.[2]

Besu 검증자는 QBFT로 블록에 합의한다. Oracle은 승인된 조직들이 검증을 나눠 맡고, 프로토콜의 장애 허용 범위 안에서 커밋된 거래에 확정적인 최종성을 제공한다고 설명한다. 유효한 서명, 요청을 보낼 권한, 원장에 기록할 순서에 대한 합의는 이 경로의 서로 다른 부분이다. EVM 호환이라는 말만으로는 각각을 누가 통제하는지 알 수 없다.[1][2]

계약 배포에는 별도의 승인 경로가 있다

발표문은 계약을 처음에 비활성 상태로 배포하는 거버넌스 기반 배포 모드를 설명한다. 설정된 승인이 Governance 계약을 통해 온체인에 기록돼야 활성화되며, 업그레이드에도 같은 승인 경로가 적용된다. 조직이 선택하고 정책을 설정해 운영하는 모드다. 모든 Solidity 계약에 이런 제어 기능이 자동으로 붙는다는 뜻은 아니다.[1]

계약 레지스트리는 ABI·바이트코드·스토리지 레이아웃 같은 자료를 버전별로 보관한다. 이는 소프트웨어가 계약을 호출하는 방식, 배포한 코드, 상태를 저장하는 구조를 설명한다. 검토자는 구체적인 구현을 대상으로 승인할 수 있고, 과거 상태를 해석할 때도 이 자료를 쓴다. 이 배포 승인은 검증자들이 블록에 합의하는 것과 별도의 결정이다.[1]

SQL 이력은 원장을 조회하는 또 하나의 방식이다

Rich History는 블록체인의 거래·이벤트·실행 추적·상태를 Oracle Database나 MySQL로 복제하고 색인할 수 있다. 관리자는 SQL로 조회하고 오프체인 업무 기록과 결합해 보고나 대사에 활용한다. 26.3 개요는 Rich History와 아카이브 노드가 선택 사항임을 명시한다.[2][4]

아키텍처는 이 조회용 이력을 실행·합의와 구분한다. 검증자가 블록에 합의하고 Rich History 구성 요소가 원장의 정보를 가져간다. 컨소시엄 참여자는 설립 조직이 제공하는 데이터베이스를 공유하거나 자기 노드에 연결된 데이터베이스를 따로 둘 수 있다. 따라서 SQL 결과는 수집된 이력을 조회한 것이지 검증자들이 새로 합의한 결과가 아니다.[2][4]

호환성 표시 다음에 읽어야 할 것

Oracle 발표는 익숙한 계약 코드 주변에 네트워크 참여, 키 수탁, 계약 배포 승인, 이력 조회라는 독립된 선택이 있음을 보여 주는 구체적인 사례다. 문서는 플랫폼이 의도한 작동 방식을 설명한다. 제공 상태와 아키텍처 설명만으로 특정 기관의 실운영 도입을 확인할 수 없으며, 이런 사설 네트워크가 퍼블릭 이더리움의 일부가 되는 것도 아니다. 발표의 의미를 이해하려면 이 경계를 함께 읽어야 한다.[1][2]

다음 질문으로

이어서 읽을 이야기

같은 주제를 다른 사례와 배경에서 살펴보세요.

출처 및 참고 자료

  1. [1]출처 1: OBP Enterprise Edition 26.3.1: governed digital asset applicationsOracle / Mark Rakhmilevich · 2026-10-27확인 2026-10-27
  2. [2]출처 2: OBP Enterprise Edition overview — Release 26.3Oracle Documentation확인 2026-10-27
  3. [3]출처 3: Getting started with OBP Enterprise Edition for Hyperledger Besu — Release 26.2Oracle Documentation확인 2026-10-27
  4. [4]출처 4: Create a Rich History database configuration — Release 26.3Oracle Documentation확인 2026-10-27