Block Assembly Marketplace (BAM)

핵심 인사이트

• 현재 Solana 리더는 자신의 슬롯에서 트랜잭션 순서를 단독으로 결정하며, 블록 구성 방식은 거의 공개되지 않습니다. BAM은 시퀀싱 로직을 감사할 수 있는 검증 가능하고 탈중앙화된 대안을 제시합니다.
• BAM 네트워크는 역할을 명확히 분리합니다. BAM 노드는 Solana 트랜잭션의 수집, 우선순위 지정, 필터링을 관리하고, BAM 검증인은 실행, 합의, 상태 관리를 담당합니다. 이 방식은 Solana를 제안자-빌더 분리(Proposer-Builder Separation, PBS)와 유사한 아키텍처에 더 가깝게 만듭니다.
• BAM의 플러그인 프레임워크를 사용하면 개발자가 맞춤형 순서 지정 로직과 새로운 스케줄링 프리미티브를 정의할 수 있습니다. 이를 통해 앱이 자체 트랜잭션 스케줄링 규칙을 적용하는 애플리케이션 제어 실행(Application-Controlled Execution, ACE)이 가능해집니다.
• Jito는 향후 BAM을 오픈 소스로 공개하고 투명성을 핵심 원칙으로 설계하겠다고 약속했습니다. 비공개 소스이며 신뢰받는 단일 주체가 운영하는 현재의 Jito 블록 엔진보다 크게 개선된 방식입니다.
• BAM 노드는 향상된 Secure Encrypted Virtualization with Secure Nested Paging(SEV-SNP)을 지원하는 AMD 프로세서에서 실행됩니다. 하드웨어 가속 덕분에 SEV-SNP의 오버헤드는 2~5%에 불과해 실시간 처리에 충분히 빠릅니다.
• BAM 노드에 최초로 구현될 스케줄러는 멤풀 내에서 주기적인 블록 내부 경매를 실행합니다. 블록을 N개의 슬롯으로 나누고 각 경매에 CU를 동일하게 할당합니다.
• 애플리케이션 제어 실행(ACE)은 맞춤형 로직을 적용하기 위한 롤업이나 네트워크 확장의 필요성을 줄여 Solana 메인넷에 더 많은 활동을 유지할 수 있습니다. 프로그래밍 가능한 블록 공간을 활용하는 새로운 애플리케이션의 설계 가능성도 크게 넓어집니다.
• Jito는 블록 엔진과 향후 BAM 시스템에서 발생하는 프로토콜 수수료의 100%를 Jito DAO 금고로 보낼 계획입니다. 현재 Jito는 팁에 6%의 수수료를 부과하고 이를 Jito Labs와 DAO가 절반씩 나눕니다. 2025년 2분기에 DAO는 Tip Router를 통해 이 수수료로 22,391.31 SOL(약 400만 달러)을 벌었습니다.
• BAM은 Flashbots의 BuilderNet에서 영감을 받아 신뢰 실행 환경 내에서 블록을 구성하는 유사한 방식을 채택합니다. Ethereum 메인넷에서는 이미 약 40%의 블록이 TEE에서 구성됩니다.

소개

Jito의 Block Assembly Marketplace(BAM)는 지금까지 Solana 블록 구성 프로세스에 적용된 가장 야심 찬 재설계입니다. 8개월 넘게 개발된 BAM은 차세대 고급 애플리케이션을 지원하기 위해 Solana에서 더 높은 프라이버시와 투명성, 결정론적 슬롯 내부 실행을 구현하려는 목표에서 시작됐습니다. 그 결과, 현재의 불투명한 검증인 중심 순서 지정 모델을 비공개이며 프로그래밍 가능하고 공정성을 검증할 수 있는 트랜잭션 시퀀싱 시스템으로 대체한 새로운 트랜잭션 파이프라인이 탄생했습니다.

BAM은 신뢰 실행 환경(TEE) 내부에서 실행되는 암호화된 멤풀을 도입합니다. 모든 트랜잭션은 실행될 때까지 기밀로 유지됩니다. 프라이버시를 보호하는 이 아키텍처는 가장 착취적인 여러 형태의 MEV를 크게 줄이거나 제거하여 사용자에게 더 강력한 실행 보장과 더 나은 가격을 제공하는 것을 목표로 합니다. 검증인은 더 높은 품질의 실행을 제공할 수 있고, 개발자와 서처는 프로그래밍 가능한 새로운 블록 공간 레이어 위에서 직접 구축할 수 있습니다.

BAM은 플러그인 시스템을 통해 애플리케이션 제어 실행(ACE) 로직을 도입합니다. 이를 통해 무기한 선물의 메이커 우선 매칭, 적시 오라클 업데이트, 주문 유효 기간 적용, 기타 맞춤형 라우팅 및 실행 같은 사용 사례를 구현할 수 있습니다. 개발자는 트랜잭션 순서를 세밀하게 제어하여 중앙 지정가 주문장, 다크 풀, 애그리게이터 레이어 등 더 정교하고 안정적인 금융 프리미티브를 Solana에 구축할 수 있습니다.

이를 통해 BAM은 Solana 블록 생성 모델이 오랫동안 받아온 여러 비판을 직접 해결합니다. 불투명한 검증인 동작, 일관되지 않은 실행 품질, 비공개 멤풀과 대역 외 거래를 통한 회색 시장의 확산이 대표적입니다. 현재 Solana 리더는 자신의 슬롯에서 트랜잭션 순서를 일방적으로 통제하며 최종 블록의 구성 방식은 거의 공개되지 않습니다. BAM은 이를 Solana의 고성능 런타임과 원활하게 통합되는 검증 가능하고 탈중앙화된 대안으로 교체합니다.

BAM은 실제 사례를 기반으로 하며 Flashbots의 BuilderNet에서 영감을 받아 신뢰 실행 환경 내에서 블록을 구성하는 유사한 방식을 채택합니다. Ethereum 메인넷에서는 이미 약 40%의 블록이 TEE에서 구성되며, Unichain(Uniswap의 맞춤형 L2)에서는 그 비율이 100%에 이릅니다. BAM은 이 모델을 Solana로 확장하면서 애플리케이션 수준 프로그래밍 기능, 짧은 지연 시간의 실행, 현재 Jito-Agave와 Jito-Firedancer 전반에서 전체 스테이크의 89% 이상을 보호하는 Jito 검증인 클라이언트와의 긴밀한 통합이라는 이점을 제공합니다.

무엇보다 Jito는 향후 BAM을 오픈 소스로 공개하고 투명성을 핵심 원칙으로 설계하겠다고 약속했습니다. 비공개 소스이며 신뢰받는 단일 주체가 운영하는 현재의 Jito 블록 엔진보다 크게 개선된 방식입니다. BAM은 어떤 코드가 실행됐고 트랜잭션이 어떤 순서로 정렬됐는지 정확히 확인하는 암호학적으로 서명된 증명인 온체인 증명을 생성합니다. 이를 통해 누구나 공정한 실행을 검증할 수 있습니다.

BAM 개요

BAM의 핵심은 트랜잭션 시퀀싱 네트워크입니다. BAM 노드는 Solana 트랜잭션의 수집, 우선순위 지정, 필터링을 처리하고, BAM 검증인은 실행, 합의, 상태 관리에 집중합니다. 이러한 역할 분리는 네트워크 활성 유지에 중요한 핵심 책임을 검증인에 남겨두면서 BAM 노드 내 시퀀싱 로직의 유연성과 실험 가능성을 높입니다.

BAM 노드는 TEE 내에서 작동하는 트랜잭션 처리 장치(TPU)와 트랜잭션 스케줄러로 구성됩니다. 연결된 검증인과 통신하기 위한 gRPC 서버도 실행합니다. 수정된 Jito-validator 클라이언트에는 계정 인식 잠금을 통해 동시성과 병렬성에 최적화된 선입선출(FIFO) 실행기가 포함됩니다.

각 BAM 노드는 여러 검증인을 지원할 수 있지만, 각 검증인은 한 번에 하나의 BAM 노드에만 연결됩니다. 현재 Jito는 7개의 블록 엔진을 운영합니다. BAM 네트워크는 탈중앙화와 중복성을 높이기 위해 모든 주요 지역에 분산된 50~100개 이상의 BAM 노드를 목표로 대폭 확장할 예정입니다. BAM 노드와 검증인은 양방향 gRPC 스트림으로 통신하며, 실행 결과는 실시간 피드백을 위해 검증인에서 BAM 노드로 다시 스트리밍됩니다.

BAM 노드 내 모든 트랜잭션은 실행되는 순간까지 신뢰 실행 환경(TEE) 안에서 암호화됩니다. 따라서 트랜잭션 흐름은 실행 전까지 비공개로 유지됩니다.

공정한 실행을 보장하기 위해 트랜잭션 순서는 증명을 사용해 검증 가능한 형태로 기록됩니다. 증명은 특정 이벤트나 조건이 관찰됐음을 확인하기 위해 BAM 노드가 서명하고 타임스탬프를 기록한 암호학적 증거입니다. 그 결과 변경 불가능한 감사 추적이 만들어지며, 관찰자는 트랜잭션이 올바른 순서로 실행됐음을 입증할 수 있습니다.

감사 추적에는 검증인으로 전달된 트랜잭션과 시퀀싱 정보가 포함됩니다. 예를 들어 이 슬롯에서 트랜잭션 A, B, C가 Helius 검증인으로 전송됐다는 내용입니다. 시스템은 실시간 모니터링 도구와 분석 기능을 제공하므로 사용자는 제출부터 실행까지 트랜잭션을 추적할 수 있습니다. 사용자와 애플리케이션은 BAM 검증인이 지정된 순서를 준수했는지 확인하고 BAM 노드에서 정확히 어떤 코드가 실행됐는지 알 수 있습니다.

BAM 노드는 기존 Jito 릴레이어와 마찬가지로 네트워크에 투명하게 공개됩니다. 검증인이 BAM에 연결되면 트랜잭션 수신 진입점 역할을 하는 TPU 및 TPU 전달 포트를 통해 BAM 인스턴스를 알립니다.

사용자는 기존 RPC 클라이언트로 계속 트랜잭션을 제출할 수 있습니다. 보안을 강화하려면 BAM 인스턴스로 직접 트랜잭션을 전송하여 악의적인 검증인이 트랜잭션 패킷을 가로채거나 보지 못하게 할 수도 있습니다.

트랜잭션이 BAM에 들어오면 중복 제거, 서명 검증, 유효한 형식, 블록해시, 수수료 지불자, 논스, Address Lookup Tables 확인을 포함하는 표준 정제 프로세스를 거칩니다.

검증된 트랜잭션은 BAM의 멤풀에 들어가 빈번한 주기적 경매에 참여합니다. 경매가 끝나면 트랜잭션이 검증인에게 전달됩니다. 전체 트랜잭션 시퀀스는 BAM 소프트웨어가 서명하고 데이터베이스에 기록합니다. 이후 검증인은 Anza의 모듈식 스케줄러가 제안한 API를 모델로 한 API를 통해 실행 결과를 다시 스트리밍합니다.

안전한 스케줄링 환경과 로컬 수수료 시장을 통해 검증인은 훨씬 강력한 옵트인 계약 아래에서 작동합니다. 검증인은 제공된 그대로 정확히 스케줄링해야 하는 사전 정의된 트랜잭션 시퀀스를 받습니다. 악의적인 목적으로 트랜잭션을 삽입하거나 순서를 바꿀 기회가 사라집니다.

감사 추적 증거를 바탕으로 샌드위치 공격 같은 검증인의 부정행위에 대응할 여러 집행 메커니즘이 검토되고 있습니다. 아직 확정되지는 않았지만 가능한 대응은 다음과 같습니다.

• 위반 검증인을 BAM 네트워크에서 제거합니다.
• 검증인에게 채권 형태의 담보를 요구하고 부정행위 시 이를 삭감합니다. 다만 신규 검증인의 진입 장벽이 높아질 수 있습니다.
• 블랙리스트나 그레이리스트를 적용해 위반자의 참여를 부분적으로 제한합니다.

수수료

Jito Labs와 Jito Foundation은 블록 엔진과 향후 BAM 시스템에서 징수되는 프로토콜 수수료의 100%를 Jito DAO 금고로 보내는 Jito 개선 제안(JIP)을 공동 작성하고 있습니다. 앞으로 몇 주 안에 정식 제출될 예정인 이 제안은 Jito의 경제 모델에 중대한 변화를 가져오며 DAO의 승인이 필요합니다. 통과되면 Jito 생태계에서 DAO와 JTO 토큰 보유자의 핵심 역할이 강화됩니다.

현재 Jito 프로토콜은 팁에 6%의 수수료를 부과하며 Jito Labs와 DAO가 이를 절반씩 나눕니다. 2025년 2분기에만 DAO는 22,391.31 SOL을 벌었습니다. Tip Router를 통해 이 수수료에서 발생한 약 400만 달러입니다. DAO의 또 다른 주요 수익원은 jitoSOL 수수료이며, 같은 기간 총 13,223.73 SOL(약 238만 달러)을 기록했습니다.

신뢰 실행 환경(TEE)

신뢰 실행 환경(TEE)은 연산과 메모리의 기밀성과 무결성을 보장하도록 설계된 하드웨어 기반 아키텍처입니다. 엔클레이브라고도 하는 TEE는 일반적으로 하드웨어 수준의 분리를 통해 코드 실행을 호스트 시스템의 운영체제, 커널, 하이퍼바이저와 격리합니다. 이 격리는 공격 표면을 크게 줄여 엔클레이브 작업을 관찰하거나 변조하기 매우 어렵게 만듭니다. 다만 불가능한 것은 아닙니다.

TEE는 2000년대부터 디지털 권리 관리, 콘텐츠 보호, 보안 결제 시스템 등의 분야에서 사용됐습니다. 오늘날에는 민감한 데이터와 코드를 안전하게 처리하기 위해 소비자 기기와 클라우드 서비스 전반에서 널리 사용됩니다. 스마트폰과 노트북에서는 Apple의 Secure Enclave와 Android의 TrustZone이 생체 정보, 결제 자격 증명, 암호화 키를 보호합니다. PlayStation과 Xbox 같은 게임 콘솔은 AMD 또는 Pluton 기반 프로세서로 변조와 불법 복제를 방지합니다. 클라우드에서는 Azure와 Google Cloud 같은 제공업체가 AMD SEV-SNP, Intel TDX, AWS Nitro Enclaves를 활용해 워크로드를 격리하고 기밀 컴퓨팅을 지원합니다. Ledger와 Trezor 같은 암호화폐 지갑은 보안 요소로 개인 키를 보호하며, 새로운 Solana Seeker 휴대전화도 같은 목적으로 TEE를 사용합니다.

TEE는 비공개 데이터를 처리하는 표준 하드웨어 기반 방식이며, 완전 동형 암호화(FHE)와 안전한 다자간 연산(MPC) 같은 순수 암호학적 방법의 실용적인 대안입니다. FHE와 MPC는 이론적으로 강력한 보장을 제공하지만, 높은 복잡성과 성능 오버헤드 때문에 실제 환경에서는 비실용적인 경우가 많습니다.

BAM은 TEE의 두 가지 핵심 속성에 의존합니다.

기밀성: TEE 내부의 코드와 데이터는 암호화되며 시스템의 나머지 부분과 격리됩니다. 운영체제, 하이퍼바이저, 외부 소프트웨어 모두 엔클레이브 내에서 실행되는 항목에 접근하거나 이를 검사할 수 없습니다.

증명 가능성: TEE는 엔클레이브의 출처와 현재 상태에 대한 암호학적 증거를 생성하는 메커니즘인 증명을 지원합니다. 제3자는 이를 통해 결과가 침해되거나 에뮬레이션된 환경이 아니라 신뢰할 수 있는 코드를 실행하는 정품 TEE에서 생성됐는지 검증할 수 있습니다.

BAM의 TEE 구현

BAM은 향상된 Secure Encrypted Virtualization with Secure Nested Paging(SEV-SNP)을 지원하는 AMD 프로세서에서 실행됩니다. 소규모 엔클레이브 기반 방식과 달리 SEV-SNP는 성능 오버헤드를 최소화하면서 전체 BAM 애플리케이션을 보호하므로 처리량이 높고 지연 시간이 짧은 트랜잭션 시스템에 적합합니다.

하드웨어 가속 덕분에 SEV-SNP의 오버헤드는 2~5%에 불과해 실시간 처리에 충분히 빠릅니다. 격리된 연산뿐 아니라 복잡하고 상태를 유지하는 네트워크 애플리케이션도 지원합니다. 이 기술은 Google Cloud, Azure, AWS를 비롯한 주요 클라우드 제공업체에 배포되어 실전 검증을 거쳤으며, 다년간의 보안 연구와 운영 경험을 기반으로 합니다.

BAM에서 사용하는 SEV-SNP는 몇 가지 핵심 보안 보장을 제공합니다. 각 TEE 인스턴스는 자체적으로 하드웨어 격리된 가상 머신 안에서 실행되며, 런타임에 메모리를 암호화하여 강력한 VM 수준 격리를 보장합니다. BAM은 하드웨어에 기반한 증명을 활용하여 각 TEE가 수정되지 않은 정품 코드를 실행 중임을 암호학적으로 입증합니다. 이 증명 체인은 제조 과정에서 CPU에 물리적으로 내장된 AMD의 하드웨어 루트 키에 고정됩니다. 또한 TLS 키는 프로세서 내부의 하드웨어 난수 생성기로 생성되므로 암호화되지 않은 메모리에 노출되지 않습니다.

클라이언트가 BAM에 연결하면 표준 연결 인증서, AMD SEV-SNP 증명 보고서, TLS 개인 키가 증명된 TEE 내부에서 생성됐다는 암호학적 증거를 포함한 TLS 인증서를 받습니다. 이 인증서 체인은 AMD의 하드웨어 신뢰 루트에 암호학적으로 결합되어 있습니다. AMD의 개인 루트 키에 접근하지 않고는 위조할 수 없으므로 AMD의 칩 제조 공정 외에는 어떤 중개자도 신뢰할 필요가 없습니다.

플러그인

현재 Solana의 애플리케이션은 우선순위 수수료나 관련 팁이 포함된 번들 트랜잭션을 통해서만 트랜잭션 순서에 영향을 줄 수 있습니다. Agave와 Firedancer 같은 클라이언트 전반에서 여러 시퀀서가 사용되므로 어떤 순서 지정 로직이 적용될지 보장할 수 없습니다. 애플리케이션이 트랜잭션 순서를 제어할 수 있는 범위도 제한됩니다.

플러그인이 이를 해결합니다. 

개발자는 BAM의 플러그인 프레임워크를 통해 맞춤형 순서 지정 로직을 구현하고 새로운 스케줄링 프리미티브를 도입할 수 있습니다. 플러그인은 **애플리케이션 제어 실행(ACE)**을 지원하여 앱이 맞춤형 트랜잭션 스케줄링 정책을 정의할 수 있게 합니다. ACE의 잠재적 활용 사례는 많지만, 가장 널리 알려지고 논의된 사례는 주문장 취소를 우선 처리하는 것입니다. 이 메커니즘은 역선택을 줄이고 더 좁은 스프레드를 가능하게 합니다.

주문장 메이커 취소 우선 처리

현재 Solana의 온체인 주문장 시장 조성자는 불리한 조건에서 운영됩니다. 시장 조성자는 공정 가격이 바뀔 때 오래된 호가를 계속 업데이트하거나 취소하여 위험을 관리합니다. 시장 가격이 움직이면 정보 우위를 가진 테이커가 기회를 활용하기 전에 기존 주문을 취소해야 합니다.  

트랜잭션 순서를 세밀하게 제어할 수 없으면 오래된 가격을 노리는 유해한 흐름에 호가가 노출됩니다. 시장 조성자가 빠르게 대응해도 손실을 볼 수 있습니다. Jito 경매는 의도보다 입찰가를 우선하기 때문입니다. 결국 더 많이 지불한 주체가 먼저 시퀀싱됩니다.

이러한 구조는 시장 조성자가 위험 관리를 위해 스프레드를 넓히도록 압박합니다. 전체 유동성이 줄고 사용자 가격은 악화됩니다. 테이커가 오래된 가격으로 이익을 얻고 상대방은 거래 직후 이를 후회하는 유해 거래는 사용자 경험에는 거의 기여하지 않지만 시장 조성자와 유동성 공급자의 마찰은 크게 높입니다.

BAM 플러그인을 사용하면 애플리케이션 수준에서 "체결 전 취소" 정책을 적용할 수 있습니다. 프로그램에 트랜잭션 순서를 세밀하게 제어할 권한을 부여하여 애플리케이션이 테이커 거래보다 메이커 취소를 먼저 처리하도록 선택할 수 있습니다. 이 간단한 정책 변경은 큰 영향을 줍니다.

• 역선택 감소: 시장이 움직일 때 메이커가 반복적으로 손해 보는 일을 방지합니다.
• 유해 흐름 필터링: 유해 거래가 줄어 전체 거래량은 감소할 수 있지만 흐름과 실행의 품질은 개선됩니다.
• 더 좁은 스프레드 지원: 위험이 줄어 메이커가 더 공격적으로 호가할 수 있습니다.
• 유동성 개선: 전문 메이커와 개인 트레이더 모두 더 확신을 갖고 호가를 제공하므로 유동성이 깊어집니다.

적시 오라클 업데이트

애플리케이션별 플러그인의 또 다른 사례는 Pyth가 구현할 예정인 적시 오라클 업데이트입니다. Solana의 선도적인 오라클 제공업체인 Pyth는 1,700개가 넘는 개별 가격 피드를 관리합니다. 모든 블록에서 이를 전부 업데이트하면 비용이 지나치게 높고 블록 공간도 비효율적으로 사용하게 됩니다.

BAM을 사용하면 Pyth는 같은 블록 내에서 사용자 트랜잭션 바로 앞에 오라클 업데이트를 삽입해 필요한 순간에 특정 가격 피드를 정확히 업데이트할 수 있습니다. 비효율적인 청산과 오라클 조작 등 오래된 오라클 데이터와 관련된 위험이 줄어들어 DeFi 애플리케이션이 더 안정적이고 경쟁력 있게 작동할 수 있습니다.

추가 플러그인

궁극적으로 BAM은 애플리케이션 개발자가 트랜잭션 시퀀싱을 제어할 플러그인을 구축, 테스트, 배포할 수 있는 무허가형 플랫폼을 지향합니다. 앞으로 더 많은 플러그인이 등장하며, 최종적으로 BAM 노드는 수백 개의 맞춤형 확장 기능을 지원할 것으로 예상됩니다. 대부분의 애플리케이션은 계속 기본 스케줄러를 사용하겠지만, 맞춤형 시퀀싱 로직이 필요한 애플리케이션은 자체 플러그인을 개발하고 유지해야 합니다. 

또한 애플리케이션은 플러그인 기능에 수수료를 부과하여 수익화할 수 있습니다. 수익 일부를 거버넌스 토큰 보유자나 검증인과 공유할 수도 있습니다.

범용 플러그인 후보

플러그인은 단일 애플리케이션에만 국한되지 않습니다. Jito는 BAM용으로 개발할 수 있는 여러 범용 교차 애플리케이션 플러그인 사례를 이미 제안했습니다.

블록 공간 선물: 사용자와 애플리케이션이 미래 특정 시점의 블록 공간 사용 권리를 예약하거나 거래할 수 있게 합니다. 네트워크 수요가 높은 기간에도 예측 가능한 접근성과 가격을 제공합니다.

주문 유효 기간(TIF): 주문이 완전히 체결되지 않을 경우 자동으로 취소되기 전까지 활성 상태로 유지되는 기간을 뜻합니다. 예를 들어 주문장 트랜잭션을 20밀리초 동안만 유효하게 만들 수 있습니다. 현재 Solana에서도 의도적으로 오래된 블록해시를 사용하여 트랜잭션이 가장 최근 블록에서만 유효하도록 하는 단순한 형태를 구현할 수 있습니다.

사전 확인: 트랜잭션이 실행되어 네트워크로 전파되기 전에 검증인에게 전달되면 사용자에게 알릴 수 있습니다. 더 이른 시점에 일정 수준의 확신을 가지고 트랜잭션을 확인합니다.

수수료 없는 트랜잭션: 사용자가 SOL 대신 SPL 토큰(예: 스테이블코인)으로 트랜잭션 비용을 지불할 수 있게 합니다. 네이티브 토큰 요구 사항을 추상화하고 유연한 수수료 결제를 지원합니다.

짧은 지연 시간의 애그리게이터 및 견적 요청(RFQ): 사용자가 거래 의도를 BAM에 직접 제출하면 로컬에서 실행되는 애그리게이터가 최적 경로를 찾습니다.

트랜잭션 취소 및 교체: 사용자가 이전에 제출한 트랜잭션을 취소, 삭제, 교체할 수 있는 특수 마커가 포함된 트랜잭션을 제출할 수 있습니다.

출시 계획

출시 단계에서는 Jito Labs가 초기 BAM 노드 세트를 운영하여 안정성, 성능, 보안을 보장합니다. Helius, SOL Strategies, Triton One, Figment를 포함한 허가형 초기 검증인 파트너 그룹이 BAM 클라이언트를 실행합니다. 출시 직후 전체 네트워크 스테이크 중 한 자릿수 후반 비율을 보호할 예정입니다. 

동시에 Drift, Pyth, DFlow를 포함한 초기 Solana 애플리케이션 그룹이 첫 번째 플러그인 개발과 테스트를 시작합니다. 출시 단계가 끝날 때까지 BAM은 핵심 기능을 검증하고 노드 운영자와 검증인의 폭넓은 참여를 위한 기반을 마련할 것으로 예상됩니다. 

BAM 참여에 관심 있는 검증인, 애플리케이션 개발자, 서처는 이 양식을 작성할 수 있습니다.

Solana Foundation을 비롯해 Solana 검증인 및 개발자 커뮤니티의 주요 이해관계자로 구성된 생태계 자문 위원회가 Jito Labs에 조언합니다. 이 위원회는 BAM 확장을 안내하고 탈중앙화를 촉진하며 커뮤니티 주도 혁신을 지원합니다.

현재 BAM 코드베이스는 비공개 소스입니다. 제3자 플러그인 개발을 지원하기 위해 가까운 시일 내에 공개할 계획입니다. 오픈 소스로 전환되면 BAM은 다음과 같은 핵심 영역에서 커뮤니티 기여를 받습니다.

• 플러그인 개발: BAM의 기능을 확장할 맞춤형 플러그인을 구축합니다.
• 스케줄링 알고리즘: 특정 사용 사례에 맞는 새로운 트랜잭션 순서 지정 전략을 설계하고 기여합니다.
• 통합 라이브러리: BAM 통합을 간소화할 여러 프로그래밍 언어용 SDK를 개발합니다.
• 분석 도구: BAM의 증명 데이터를 활용하는 대시보드와 모니터링 시스템을 만듭니다.
• 연구 기여: MEV 완화와 시스템 최적화를 위한 새로운 접근 방식을 제안하고 구현합니다.

영향

BAM은 Solana의 중요한 전환점입니다. MEV 착취와 효율적인 블록 패킹에 대한 우려를 해소하여 새로운 혁신을 촉발할 잠재력이 있습니다. TEE로 보호되는 시퀀싱과 BAM의 플러그인 프레임워크는 애플리케이션 팀이 자체 맞춤형 로직이나 특정 블록 공간 정책을 적용하기 위해 네트워크 확장, 롤업, Solana 허가형 환경을 구축할 동기를 줄일 수 있습니다. 그 결과 더 많은 활동이 Solana 메인넷에 남습니다. 또한 블록당 연산 한도 증가와 더 적은 CU를 사용하는 효율적인 토큰 프로그램 및 프레임워크에 대한 수요 증가(예: Pinocchio와 p-token의 인기 상승)로 메인넷 대역폭이 늘어나 개발자가 맞춤형 솔루션을 구축할 동기가 더욱 줄어듭니다.

BAM의 프라이버시 기능은 트랜잭션이 실행될 때까지 숨겨지도록 하여 봇이 사용자를 선행 매매하는 능력을 제한하므로 샌드위치 공격도 크게 줄일 수 있습니다. DEX 효율이 개선되고 사용자에게 더 경쟁력 있는 가격이 제공될 가능성이 큽니다. 하지만 BAM이 MEV를 완전히 제거하기는 어렵습니다. MEV는 본질적으로 쫓고 쫓기는 게임이므로 샌드위치 공격자는 미묘한 플러그인 취약점을 악용하거나 암호화된 파이프라인에 포함되지 않는 외부 오라클, 즉 자체 플러그인이 없는 오라클을 조작하는 방식으로 적응할 수 있습니다. 

BAM을 통한 MEV 감소는 Jito 수익에 부정적인 영향을 줄 수 있습니다. 단기 수익을 줄였지만 궁극적으로 네트워크에 도움이 된 2024년 멤풀 종료와 유사합니다. BAM의 개선 사항은 전체 트랜잭션 거래량과 플러그인 수수료를 늘려 이를 상쇄하고, 도입률 개선을 통해 장기 수익을 높일 수 있습니다. 하지만 BAM의 구체적인 구현, 단계적 출시, 경제 모델에는 잠재적인 중앙화 위험과 미해결 문제가 있습니다. 다음 섹션에서 이를 살펴봅니다. 한편 이러한 위험과 미해결 문제에 대응하는 여러 이점도 있으며, 각각 MEV 재분배, PBS, "새로운" 클라이언트 개발과 관련된 영향을 수반합니다.

MEV 재분배

BAM은 Solana의 MEV 환경을 통제되지 않는 착취에서 더 체계적인 재분배 모델로 근본적으로 바꿉니다. 기존 구조에서는 선행 매매나 스팸을 통해 사용자 가치가 MEV로 유출되는 경우가 많으며, 검증인이나 봇이 샌드위치 공격 같은 유해한 전략으로 가치를 포착합니다. 반면 BAM의 TEE 암호화 멤풀은 실행 전까지 트랜잭션을 숨겨 부정적 MEV에 대한 가시성을 제한합니다. 대신 플러그인과 맞춤형 시퀀싱을 통해 가치가 내부화됩니다. 이에 따라 앱, 개발자, 서처는 생태계 효율을 높이는 긍정적 형태의 MEV를 포착할 수 있습니다. 예를 들어 DeFi 스프레드를 좁히고 오라클 스팸을 줄일 수 있습니다.

플러그인 수수료를 BAM 노드 운영자, 검증인, 스테이커, Jito의 DAO가 공유하므로 이러한 재분배는 MEV 수익을 이해관계자에게 돌려줍니다. 지속 가능한 수익원을 만들 가능성이 있습니다. 예를 들어 DEX는 주문 매칭을 최적화하고 검증인이 추출할 수 있었던 MEV를 앱 생성 수수료로 전환하는 플러그인을 사용할 수 있습니다. 이 수수료는 토큰 보유자에게 재분배할 수 있습니다. 트레이더 활동을 "보호"하는 이 방식은 MEV를 제로섬 게임에서 유동성을 깊게 하고 기관 자본을 유치하는 구조로 바꿀 수 있습니다.

하지만 재분배에는 위험이 따릅니다. 중요한 점은 BAM이 MEV를 없애는 것이 아니라 위치를 바꾼다는 것입니다. 그 결과 초기 플러그인 작성자, BAM 노드 운영자, Jito 관련 주체가 과도한 이익을 축적할 수 있습니다. 암호학적 증명의 제약이 있더라도 TEE 취약점(예: 사이드 채널 공격)이 발생하면 서처의 특권 접근이 새롭고 미묘한 가치 추출 경로를 만들고 결국 프라이버시 보장을 훼손할 수 있습니다. 이는 "보호된" 형태의 백러닝도 가능하게 합니다. 서처는 전략을 노출하거나 선행 매매를 허용하지 않으면서 사용자 트랜잭션 뒤에 트랜잭션을 추가하는 코드를 배포할 수 있습니다. 예를 들어 가격을 움직이는 스왑에서 차익거래를 포착할 수 있습니다. 또한 프로그래밍 방식의 삭감이 없으면 적응형 공격자가 실행 후 생성되고 현재 커뮤니티 집행에 의존하는 증명을 중심으로 유해한 전략을 시도할 수 있습니다.

궁극적으로 MEV 재분배는 BAM을 Solana의 북극성, 즉 탈중앙화된 NASDAQ을 위한 촉매로 자리매김하게 합니다. 하지만 성공 여부는 공정한 수수료 모델의 도입과 강력한 TEE 보안에 달려 있습니다. 잘못 처리하면 네트워크가 파편화되고 사용자 신뢰가 약화되며, "보호"되지만 불투명한 서처 활동에 대한 감시가 강화될 수 있습니다.

제안자-빌더 분리(PBS)

대부분의 블록체인은 동일한 주체가 블록을 제안하고 구성하도록 설계됩니다. 따라서 해당 주체는 지정된 슬롯에서 트랜잭션 순서와 포함 여부를 독점적으로 통제합니다. 이는 트랜잭션 흐름을 자유롭게 검열하거나 조작할 수 있는 해당 주체에 유리합니다. 예를 들어 정교하지만 유해한 전략으로 특정 순서의 트랜잭션을 포함하도록 블록을 제안하고 구성하여 MEV를 극대화할 수 있습니다.

제안자-빌더 분리(Proposer-Builder Separation, PBS)는 블록 구성과 블록 제안을 분리하여 이 문제를 해결하는 설계 패턴입니다. 이 설계에서 블록 빌더는 순서가 지정된 트랜잭션 목록을 만들고 해당 블록에 입찰합니다. 일반적으로 검증인인 블록 제안자는 최고 입찰 블록을 수락하고 확정합니다. 직접 정교한 시퀀싱 전략을 실행하지 않고도 경매나 팁을 통해 MEV를 재분배합니다. 

PBS는 2022년 The Merge 이후 Ethereum에서 MEV-Boost를 통해 프로토콜 외부 방식으로 구현됐습니다. MEV-Boost는 검증인의 이중 실행 레이어 및 합의 레이어 클라이언트 소프트웨어와 함께 실행되는 "사이드카"입니다. MEV-Boost를 실행하는 검증인은 여러 릴레이에 연결하고 블록 빌더가 미리 구성한 블록을 수락할 수 있습니다. 릴레이로부터 블록 보상 금액과 블록 헤더만 받으므로 온체인에 포함되기 전에는 블록 내용을 볼 수 없습니다. PBS는 검열을 더욱 완화하는 포함 목록 같은 기능을 포함할 수 있는 완전한 프로토콜 내재화(ePBS)를 기다리고 있으므로 이 설계는 여전히 활발한 연구 단계에 있습니다.

BAM을 통해 Solana는 블록 구성, 즉 TEE로 보호되는 BAM 노드의 시퀀싱과 검증인이 계속 담당하는 실행을 분리하는 PBS와 유사한 미래로 나아갑니다. 플러그인을 통해 앱과 서처에게 긍정적 형태의 MEV를 민주화할 잠재력이 있습니다. 하지만 플러그인 경제가 기존 참여자에게 유리하면 Solana의 스테이크 중앙화를 악화할 위험도 있습니다. Ethereum에서는 세 빌더(Titan Builder, BuilderNet, Beaverbuild)가 현재 전체 블록의 약 90% 이상을 장악하여 릴레이 신뢰 문제와 소규모 참여자의 진입 장벽을 만들고 있습니다. 

MEV-Boost가 Ethereum에 PBS를 도입했지만 여기서는 BuilderNet이 더 적절한 비교 대상입니다. BuilderNet은 2024년 11월 출시된 탈중앙화 블록 구성 네트워크로 Flashbots, Beaverbuild, Nethermind가 운영합니다. BuilderNet은 TEE를 사용한 비공개 블록 구성을 여러 노드 운영자에게 분산하여 독점 주문 흐름 거래를 무력화하고 중앙화를 줄입니다. 비공개 거래를 차지하기 위해 경쟁하는 주문 흐름 게임보다 사용자, 지갑, 앱 같은 주문 흐름 제공자와 MEV 환급을 공유하는 가치 창출에 집중합니다. BuilderNet은 여전히 MEV-Boost 릴레이를 사용하지만 필수는 아니므로 TEE 내에서 빌더와 제안자가 직접 상호작용할 수 있습니다. 

BAM의 단계적 허가형 출시는 Ethereum의 이러한 문제를 완화하기 위해 공정한 수수료와 오픈 소스 플러그인을 우선해야 합니다. 특히 소프트웨어 릴레이를 사용하는 Ethereum과 달리 TEE에 의존하는 하드웨어 종속성은 공급업체 종속과 유지관리 비용을 초래합니다. Solana는 주문 흐름 게임을 건너뛰고 가치 창출에 집중하는 BuilderNet과 유사한 시스템으로 도약하려 합니다. 

궁극적으로 블록 구성과 제안 방식의 이러한 변화는 검증인의 역할을 축소합니다. 시퀀싱의 복잡성을 덜어주지만 수수료가 폭넓게 공유되지 않으면 검증인의 자율성과 수익이 줄어들 수 있습니다. 축소되는 검증인의 역할 섹션에서 이를 더 자세히 살펴봅니다.

위: Ethereum의 PBS와 Solana의 BAM 비교

"새로운" 클라이언트의 등장

Jito-Agave 클라이언트는 핵심 Agave 코드베이스를 매우 밀접하게 따르며, 주로 MEV 기능을 추가한 점에서 차이가 납니다. Jito의 "Agave+MEV" 모델은 핵심 아키텍처의 변경을 최소화하면서 클라이언트를 Solana의 기존 검증인 생태계와 원활하게 통합하고 보상을 높였습니다. 그 결과 작성 시점 기준 Jito-Agave 클라이언트는 검증인 도입률 79%로 네트워크를 주도합니다. 검증인은 Agave의 기반 로직을 사용하면서 Jito의 추가 수익원을 활용할 수 있습니다.

BAM은 Agave를 밀접하게 따르던 Jito의 이전 접근 방식에서 벗어납니다. 전용 BAM 노드 네트워크가 도입되면서 새로운 인프라 레이어가 구축됩니다. 이러한 진화로 Jito는 단순한 "향상된 Agave"에서 애플리케이션별 로직을 내장할 수 있는 자체 프로그래밍 생태계를 갖춘 더 차별화된 클라이언트로 전환합니다.

이러한 차이는 Anza가 5월에 발표한 Agave의 예정된 스케줄러 바인딩에서 분명히 드러납니다. Solana의 MEV가 성숙하면서 맞춤형 스케줄러 구현이 점점 보편화되고 있습니다. 맞춤형 스케줄러는 운영자 수익을 높일 수 있지만 현재 구현에는 여러 단점이 있습니다. 다른 버전의 검증인 바이너리를 실행해야 하고, 비공개 소스 코드에 의존하며, 활성 유지 문제도 발생할 수 있습니다. 

Anza의 예정된 스케줄러 바인딩은 검증인이 핵심 검증인 바이너리를 변경하지 않고 외부 블록 구성 서비스에 연결할 수 있게 하여 모듈성을 도입하고 맞춤형 스케줄러를 지원합니다. 이 설계는 투명성, 안전성, 더 쉬운 DevOps를 촉진합니다. 하지만 BAM은 BAM 노드 스케줄러가 업스트림에서 시퀀싱을 처리하므로 Jito 사용자가 이러한 바인딩을 사용할 필요를 없앱니다. 이는 Agave가 계획한 스케줄러 바인딩을 우회하여 운영을 간소화할 수 있지만, Anza의 표준화 노력과 달라짐에 따라 향후 생태계가 파편화될 수 있다는 우려를 낳습니다. 예를 들어 Firedancer 통합이 복잡해질 수 있습니다.

하지만 Jito는 BAM을 통합 검증인 클라이언트의 일부로 제시합니다. BAM 검증인은 BAM 스케줄러를 통합한 업데이트 버전의 Agave 클라이언트를 실행하며 BAM 노드의 트랜잭션만 FIFO 순서로 수락합니다. 이 설계는 클라이언트 파편화를 방지하면서 시스템 복원력을 높입니다. Jito는 Anza의 모듈식 스케줄러 출시에 앞서 BAM 호환 클라이언트를 공개할 계획입니다. 이는 BAM의 두 가지 영향을 보여줍니다. 혁신을 촉진하고 Solana의 MEV 인프라를 발전시키지만, Jito가 지배적인 검증인 클라이언트로 더욱 고착될 위험도 있습니다.

BAM이 이러한 바인딩을 사용할 가능성도 있습니다. BAM이 모듈식 스케줄러 안에서 작동하면 Firedancer 지원이 간단해지고, Jito에 실제로 검증인 클라이언트가 필요한지라는 새로운 의문이 생깁니다. BAM의 오픈 소스 코드 구현과 출시를 기다려야 알 수 있습니다.

미해결 문제

축소되는 검증인의 역할

BAM의 설계는 트랜잭션 시퀀싱을 TEE로 보호되는 별도의 BAM 노드 네트워크로 이전하여 Solana 검증인 환경을 근본적으로 바꿉니다. 이에 따라 검증인은 주로 실행, 합의, 상태 관리를 담당합니다. 이러한 분리는 맞춤형 시퀀싱과 토큰 보유자 수익 공유를 가능하게 하므로 앱에 유리합니다. 부정적 MEV를 줄이고 더 유리한 가격을 제공하므로 사용자에게도 이점이 있습니다. 하지만 검증인의 자율성과 경제적 인센티브가 줄어드는 문제를 제기합니다.

현재 검증인이 리더로서 블록을 생성할 때는 트랜잭션 순서를 완전히 재량으로 결정할 수 있으며, 맞춤형 스케줄러를 실행해 원하는 방식으로 블록을 최적화할 수 있습니다. BAM은 검증인에게서 이 책임을 제거합니다. 이제 검증인은 미리 시퀀싱된 트랜잭션을 받아 엄격한 FIFO 순서로 실행하므로 블록 구성에 대한 자율성을 잃습니다. 극단적으로 모든 트랜잭션이 BAM을 통과하면 검증인은 단순한 "고무도장"이 되며 탈중앙화된 검증인이 필요한지 자체가 의문시될 수 있습니다. 

하지만 이를 상쇄하는 요인도 있습니다. 플러그인 수수료는 검증인과 스테이커가 공유하는 새로운 수익원을 제공합니다. BAM의 통합 클라이언트와 자동 장애 조치는 사익을 네트워크 건전성과 일치시켜 전체 복원력을 높입니다. 옵트인 방식의 단계적 출시는 선택권도 보존합니다. 장기적으로 오픈 소스화되면 검증인이 BAM 개발에 의견을 내고 커뮤니티 주도 개선을 촉진하며 일정 수준의 자율성을 유지할 수 있습니다.  검증인은 BAM에 스케줄러 개선안을 제안할 수도 있어 더 많은 거래량에서 수수료를 얻을 가능성이 열립니다. 또한 검증인은 여전히 합의와 포크 선택에서 핵심 역할을 하므로 단순한 고무도장이라는 표현은 과장일 수 있습니다. 진짜 질문은 검증인이 자율성을 실제로 얼마나 잃을 것인가입니다. BAM이 오히려 검증인이 활성 유지와 상태 무결성에 집중하도록 도울 수 있을까요?

몇 가지 질문이 남아 있습니다.

• BAM 노드가 시퀀싱과 MEV 추출을 처리한다면 검증인은 하드웨어와 가동 시간 외에 무엇으로 경쟁할까요? 
• 도입률이 높은 상황에서 검증인이 실행에만 집중하면 Solana의 전반적인 탈중앙화가 약화될까요? 그렇다면 어떤 지표로 이를 측정할 수 있을까요?
• BAM으로 인해 검증인이 수익을 찾아 더 악의적인 경로를 선택한다면 인센티브를 더 줄이지 않으면서 이를 방지할 증명 외의 안전장치는 무엇일까요?
• TEE 취약점이나 플러그인 악용으로 검증인이 부당하게 처벌받을 수 있을까요? 
• Ethereum의 PBS 경험을 바탕으로 Solana는 검증인의 자율성 감소에 어떻게 대응할 수 있을까요?

악의적인 노드 운영자

BAM 아키텍처는 검증인에 관한 새로운 신뢰 가정을 도입합니다. 즉, 검증인이 미리 시퀀싱된 트랜잭션을 변조하거나 데이터를 유출하는 등 BAM 노드와 상호작용할 때 악의적으로 행동하지 않는다고 가정합니다. 출시 시점에는 TEE의 한계 때문에 BAM이 허가형 운영자 세트에 의존합니다. 이 허가형 세트는 업데이트된 Jito-Solana 클라이언트를 실행하고 전달된 트랜잭션을 충실히 실행할 책임을 맡습니다. 이 검증인은 BAM 노드가 인그레스를 조작하지 않는다고 신뢰해야 합니다. 따라서 BAM 노드의 TEE 전 단계와 검증인의 TEE 후 단계라는 이중 레이어 신뢰가 생겨 허가형 구조의 위험이 커집니다. 핵심 질문은 BAM 노드 운영자가 트랜잭션이 TEE에 도달하기 전에 엿보지 못하도록 무엇이 막느냐는 것입니다. 답은 검증된 노드를 위한 QUIC 암호화입니다. 증명이 QUIC 인증서에 포함됩니다. BAM 노드가 정직한지 확인하는 또 다른 방법은 해당 노드의 해시를 BAM의 오픈 소스 저장소와 비교하여 주장한 소프트웨어를 실제로 실행하는지 확인하는 것입니다. 누군가 TEE를 침해하지 않았다고 가정하면 TPU용 QUIC 인증서는 TEE 내부에서 생성됩니다. 따라서 모든 인바운드 및 아웃바운드 트래픽이 암호화됩니다.

하지만 네트워크 인그레스와 이그레스 지점에서 트랜잭션 패킷을 검열하거나 선택적으로 조작할 가능성은 중요한 우려 사항입니다. 악의적인 운영자는 암호화된 트랜잭션의 세부 정보를 볼 수 없더라도 상당한 검열 능력을 유지합니다. TLS 서명으로 프로토콜 유형을 식별하고, 연결 엔드포인트에 따라 필터링하며, 타이밍 분석으로 특정 패턴을 찾아내고, 특정 특성과 일치하는 암호화 데이터를 모두 차단할 수 있습니다. 악의적인 운영자는 전송되는 정확한 트랜잭션을 알지 못해도 메타데이터와 특정 트래픽 패턴에 따라 패킷을 폐기할 수 있습니다. 이를 완화하기 위해 DoubleZero의 패킷 필터링과 타임스탬프 기능을 도입하여 투명성을 높일 수 있습니다. 궁극적으로 네트워크 검열 공격을 완화하는 것은 허가형 출시의 타당한 근거입니다.

물리적 접근을 둘러싼 새로운 신뢰 가정도 있습니다. 물리적 접근은 거의 언제나 보안 실패로 이어지며 TEE도 예외가 아닙니다. TEE는 강력한 보안을 보장하지만 공격자가 서버에 물리적으로 접근하면 침해될 수 있습니다. SOC 2를 준수하는 제공업체와의 독점 파트너십은 이를 완화하고 데이터 센터 수준에서 견고한 다층 보안을 보장하는 데 도움이 됩니다.

몇 가지 질문이 남아 있습니다.

• 악의적인 운영자가 패킷을 검열하거나 데이터를 유출하면 어떻게 제재할까요?
• 허가형 단계에서 운영자 선정 과정은 어떻게 담합을 방지하며, 탈중앙화 진척도를 측정하는 데 어떤 지표를 사용할 수 있을까요? 

조합 가능성과 플러그인 상호작용

BAM의 가장 중요한 미해결 문제 중 하나는 실제로 플러그인이 서로 어떻게 상호작용할지입니다. 하나의 트랜잭션이 여러 플러그인에 동시에 의존할 수 있습니다. 예를 들어 적시 가격 업데이트용 오라클 플러그인, 최적 스왑 경로를 정하는 DEX 플러그인, 특정 SPL 토큰 동작을 처리하는 토큰 플러그인을 함께 사용할 수 있습니다. 이러한 구성요소가 예측 가능하고 안전하게 함께 작동하도록 보장하는 것이 중요합니다.

플러그인이 효과적으로 작동하려면 외부 데이터를 가져와야 할 수 있습니다. 하지만 악의적인 플러그인이 외부 호출을 악용해 민감한 트랜잭션 정보를 유출할 수 있으므로 잠재적인 공격 표면이 생깁니다. 시스템의 신뢰를 유지하려면 플러그인이 접근하고 공유할 수 있는 범위에 엄격한 경계를 정의해야 합니다.

애플리케이션 수준의 플러그인 로직과 Solana 수수료 메커니즘 간의 상호작용도 복잡성을 더합니다. 여러 플러그인이 블록 구성에 영향을 주려고 경쟁할 때 플러그인 실행 순서, Jito 팁, 우선순위 수수료는 어떻게 상호작용할까요? 의도치 않은 조작이나 남용을 방지하려면 이러한 경제적 역학을 명확히 정의하고 투명하게 적용해야 합니다.

이러한 위험을 관리하기 위해 BAM 플러그인은 허가형 환경에서 먼저 출시될 예정입니다. 무허가형 모델로 점진적으로 전환하기 전에 초기 단계에서 플러그인 동작을 실험하고 감사할 수 있습니다.

TEE 신뢰와 책임

TEE에 의존하면 검증 가능한 연산을 보장하기 위해 무신뢰 시스템을 만드는 대신 특수 하드웨어 엔클레이브를 사용하므로 새로운 신뢰 가정이 생깁니다. Intel이나 AMD 같은 단일 하드웨어 공급업체에 의존하면 단일 문화 위험이 발생합니다. 펌웨어 리콜이나 취약점으로 BAM이 중단될 수 있으며, 네트워크 도입 수준에 따라 네트워크 전체 중단까지 이어질 수 있습니다. 펌웨어, 마이크로코드, BIOS 업데이트로 취약점을 해결할 수 없다면 하드웨어 교체에 시간이 걸리고 BAM 노드 운영자에게 반복적인 자본 지출이 발생하여 잠재적 중단의 영향이 더 커집니다. 

이러한 우려는 TEE가 실패하고 암호화된 데이터를 노출할 수 있음을 보여준 과거 취약점에 근거합니다. 예를 들어 Intel의 Software Guard Extensions(SGX)는 블록체인에 영향을 준 여러 문제를 겪었습니다. 2022년 8월 Secret Network는 xAPIC와 MMIO 취약점에 노출됐습니다. 이 취약점을 함께 사용하면 네트워크에서 실행되는 비공개 트랜잭션의 마스터 복호화 키인 합의 시드를 추출할 수 있었습니다. 

수많은 다른 문제로 인해 결국 Intel은 11세대와 12세대 Intel Core 프로세서에서 SGX를 지원 중단했습니다. AMD의 Secure Encrypted Virtualization-Secure Nested Paging(SEV-SNP)에도 공개된 취약점이 여러 개 있습니다. 특히 2월에는 관리자 접근 권한으로 악성 마이크로코드를 삽입할 수 있는 취약점인 CVE-2024-56161이 공개됐습니다. 

취약점 완화 업데이트는 항상 하위 호환되지 않으며 물리적 업그레이드가 필요할 수 있습니다. 예를 들어 CVE02020-12967과 CVE-2021-26311이 공개되면서 AMD Secure Encrypted Virtualization-Encrypted State(SEV-ES) 머신의 게스트 가상 머신 내에서 임의 코드를 실행할 가능성이 드러났습니다. SEV-ES는 AMD의 이전 세대 TEE 구현입니다. AMD는 이러한 취약점을 해결하는 업데이트 펌웨어를 출시하지 않았고 3세대 AMD EPYC, 즉 "Milan" 프로세서에서만 지원되는 SEV-SNP 기능에 완화 조치를 제공했습니다. 

BAM의 TEE 인프라는 최신 세대 SEV-SNP 아키텍처를 기반으로 하며 알려진 취약점을 방지하는 데 필요한 하드웨어 수준 보호 기능을 포함합니다. 제로데이 취약점이 발견되더라도 Jito 검증인은 BAM 노드와 연결이 끊어지면 자체 TPU로 자동 전환할 수 있으므로 네트워크가 계속 작동할 수 있다는 점도 중요합니다. 이 장애 조치 메커니즘은 보안 패치가 적용되는 동안에도 검증인이 계속 실행되도록 합니다.

몇 가지 질문이 남아 있습니다.

• 과거 취약점을 고려할 때 BAM의 하드웨어 공급업체 의존은 장기적 신뢰에 어떤 영향을 줄까요? 이러한 의존성을 줄이기 위해 Zero Trust Execution Environments(ZTEE) 같은 대안을 사용할 수 있을까요?
• 침해된 TEE에서 비공개 트랜잭션 데이터가 유출되어 금전적 손실이 발생하면 누가 책임질까요?
• TEE 장애가 발생하면 신뢰를 어떻게 회복할까요? 대안을 제공할 수 있을까요?

결론

궁극적으로 검증인은 원하는 소프트웨어를 자유롭게 실행할 수 있습니다. 경쟁이 치열한 시장에서 이윤을 추구하는 기업인 만큼, 검증인의 결정은 자신과 위임자 모두에게 돌아갈 잠재적 수익에 따라 달라집니다. 위임자는 수익률이 가장 높은 곳으로 스테이크를 자유롭게 옮길 수 있습니다. Jito 클라이언트의 광범위한 도입은 이러한 역학을 반영합니다. 성공의 상당 부분은 운영자와 위임자 모두에게 추가 수익을 제공하는 능력에서 비롯됐습니다. BAM 도입도 유사한 역학에 좌우됩니다. BAM 실행이 기존 방식보다 지속적으로 더 높은 수익을 제공한다면 검증인은 이를 도입할 것입니다. 그렇지 않다면 BAM이 다른 이해관계자에게 큰 이점을 제공하더라도 전환을 주저할 수 있습니다.

BAM은 최근에야 발표됐으므로 설계와 운영에 관한 많은 질문이 아직 해결되지 않았습니다. 앞으로 몇 달 동안 이 흥미로운 발전에 관한 더 자세한 정보, 문서, 커뮤니티 논의가 이어지기를 기대합니다.

추가 자료

• BAM 소개: Solana 블록 구성의 미래 - Jito
• BAM 화이트보드 시리즈 - Jito Learn
• Jito BAM과 Solana의 미래 - 0xResearch