매직블록, 블록체인의 실시간 실행 엔진

 

1. 블록체인이 가진 구조적 한계 : 실시간과 프라이버시

2. 블록체인의 구조적 한계를 넘는 일시적 롤업(Ephemeral Rollup)

3. 프라이빗 일시적 롤업 : PER(Private Ephemeral Rollup)

4. 매직블록, 어떻게 사용할 수 있을까?

5. 결론 : ER이 실시간 블록체인의 새로운 기준이 될 수 있을까

 

 

1. 블록체인이 가진 구조적 한계 : 실시간과 프라이버시

1-1. 실시간

오늘날 인터넷 사용자들은 일상적으로 실시간 서비스를 사용하고 있다. 온라인 게임, 거래소와 같은 서비스가 대표적인 예시다. 실시간 경험을 좌우하는 기준은 지연 시간으로, 사용자가 네트워크에 의도를 제출하고 의도가 반영되기까지 걸리는 반응 속도이다. 실시간의 기준을 지연 시간으로 표현한다면 그 기준은 얼마일까. 웹 사용성 분야에서 널리 인용되는 Jakob Nielsen의 기준에 따르면, 사용자는 응답이 100ms(0.1초) 이내로 돌아오면 시스템이 실시간으로 반응한다고 느낀다고 한다.

출처 : Binance, League of Legends

사용자들은 상대와 경쟁하는 온라인 게임이나 순간의 가격, 스프레드, 슬리피지에 반응해야 하는 거래소에서 지연 시간에 특히 더 민감하게 반응한다. 지구상에서 가장 큰 규모의 온라인 게임 중 하나인 리그 오브 레전드는 지연 시간 3ms(0.003초)로 서비스하고 있고, 바이낸스는 지연 시간 41ms(0.041초)로 서비스하고 있다. 이는 기기, 네트워크 환경, 물리적 거리, 서버 혼잡도 등의 변수에 따라 달라지지만, 대체로 실시간의 기준인 100ms를 넘지 않는다.

그렇다면 이런 실시간 서비스를 블록체인 위에 올릴 수 있을까. 실시간 서비스만 놓고 보면 중앙 서버가 여전히 가장 효율적인 선택인 경우가 많다. 다만 블록체인을 쓰는 이유는 단순히 더 빠른 시스템을 만들기 위해서가 아니라, 웹2 수준의 반응성을 유지하면서도 데이터의 처리 과정과 결과를 검증 가능한 형태로 남기기 위해서다. 중앙 서버에서는 운영 주체가 데이터와 실행 결과를 관리하므로 사용자는 정책 변경이나 서비스 종료에 따라 접근 권한을 잃을 수 있고, 내부 처리 과정도 검증하기 어렵다. 반면 블록체인에서는 상태와 자산이 네트워크에 기록되고 검증되므로, 특정 앱 운영이 중단되더라도 사용자는 자산에 계속 접근할 수 있고 서비스가 어떤 규칙에 따라 동작했는지도 사후적으로 확인할 수 있다.

이제 핵심은 블록체인이 블록 생성과 확정을 100ms 미만으로 제공할 수 있는지다. 하지만 현재의 블록체인은 실시간 환경을 안정적으로 제공하기 어렵다. 블록체인은 단일 서버가 즉시 결과를 결정하는 시스템이 아니라, 여러 참여자가 같은 상태 변화를 공유하고 검증하는 시스템이다. 따라서 사용자의 입력도 전파, 정렬, 실행, 검증·확정 과정을 거쳐야 하며, 이 구조 자체가 실시간 서비스를 제공하는 데 근본적인 제약으로 작용한다.

많은 사용자와 빠른 속도로 범용 레이어1 중 하나로 평가받는 솔라나를 보더라도 이 한계는 분명하다. 솔라나는 빠른 처리량과 짧은 블록타임으로 언급되는 대표적 레이어1이지만, 슬롯(블록타임) 시간은 약 400ms 수준이다. 사용자가 실시간으로 느끼는 기준인 100ms를 안정적으로 제공하기엔 어려운 수준이다.

레이어2도 상황은 비슷하다. 비용을 줄이고 속도를 높이기 위한 대안으로 등장했지만, 레이어1에 이미 집결된 자본과 유동성이 레이어2로 자연스럽게 이동하는 구조가 아니기 때문에 앱, 유동성, 사용자 확보가 필요하다. 이 과정에서 생태계를 다시 구축해야하는 시간과 비용이 발생한다. 여기에 트랜잭션 수요가 몰리는 순간에는 레이어2도 수수료가 급격히 상승하면서 안정성이 감소하는 등, 속도를 얻기 위해 네트워크를 완전히 분리하는 방식은, 레이어1에서 단일 상태와 유동성이 하나로 모일 때 생기는 장점을 희석시키면서도 실시간 경험을 안정적으로 보장하기 어렵다는 한계를 안고 있다.

블록체인은 본질적으로 실시간 처리를 위해 만들어진 시스템이 아니다. 블록체인의 우선순위는 누구나 검증 가능한 합의된 상태로, 게임이나 트레이딩 앱이 이미 제공하고 있는 밀리초 단위의 실시간 경험을 그대로 온체인에서 재현하려는 순간, 구조적 충돌이 발생한다. 이 충돌을 해소하려면 블록체인 위에서 실시간을 그대로 구현하는 접근이 아니라, 실시간이 필요한 구간을 별도의 실행 계층으로 분리하거나, 합의 방식을 재설계하는 새로운 접근이 필요하다.

1-2. 프라이버시

블록체인은 트랜잭션과 상태 변화가 공개되는 구조다. 기록이 블록에 포함된 뒤에 공개되는 것뿐 아니라, 트랜잭션이 처리되기 전 단계에서도 네트워크를 통해 전파되는 과정이 외부에 노출될 수 있다. 심지어 주소는 실명과 직접 연결되지 않을 수 있지만, 거래 패턴과 외부 단서를 결합하면 특정 주소의 소유자나 행동을 유추하는 것도 가능하다. 결국 블록체인이 제공하는 것은 프라이버시가 아닌, 가명성에 가깝다.

이 구조는 게임, 거래처럼 정보 비대칭이 곧바로 불공정으로 이어지는 서비스에서 문제를 만든다. 게임에서는 위치, 아이템, 능력치처럼 노출되는 순간 전략과 공정성이 무너지는 정보가 많고, 거래에서는 주문 규모, 포지션, 실행 타이밍이 드러날수록 체결 조건이 불리해진다. 블록체인에서는 이런 정보가 네트워크 상에서 실시간에 가깝게 관찰될 수 있으며, 관찰 가능하다는 사실 자체가 곧 개입 가능성을 만든다.

MEV가 그 예시로, 누군가가 제출한 트랜잭션을 멤풀에서 파악한 뒤 더 유리한 순서로 끼어들거나, 가격에 영향을 주는 행동을 앞서 실행해 경제적 이익을 가져가는 방식이 구조적으로 가능해진다. 실시간 상호작용이 중요한 서비스일수록 이런 취약점은 더 크게 드러나는데 비공개 경매, 결제, 정산, 기관 참여처럼 거래 상대, 금액, 조건 자체가 민감한 환경에서는 정보가 외부에 보이지 않는 실행이 전제되어야 하지만, 블록체인은 그 요구와 맞지 않는다.

프라이버시를 강화하는 방법이 없는 것은 아니다. 영지식증명과 FHE 같은 프라이버시 기술을 적용하면 정보를 숨긴 채로도 검증 가능한 구조를 만들 수 있다. 다만 이런 방식은 검증과 데이터 처리 부담을 키워, 밀리초 단위의 입력 반응을 요구하는 실시간 앱에서 성능을 안정적으로 확보하는걸 더 어렵게 만든다. 결국, 블록체인은 공개된 데이터와 다수의 합의를 중심으로 설계된 시스템이기 때문에, 실시간 성능과 서비스가 요구하는 프라이버시를 동시에 제공하기 어려운 구조적 한계를 지니고 있다.

 

2. 블록체인의 구조적 한계를 넘는 일시적 롤업(Ephemeral Rollup)

매직블록은 퍼블릭 블록체인이 실시간과 프라이버시를 동시에 제공하기 어렵다는 구조적 한계를 해결하기 위해 등장했다. 이 문제를 유동성과 사용자가 집합해 있는 솔라나의 장점을 활용하면서도, 실시간과 프라이빗 실행을 별도로 처리하는 기술인 일시적 롤업(Ephemeral Rollup, ER)을 통해 해결한다.

2-1. ER의 작동 방식 : 솔라나를 정산 레이어, ER을 실행 레이어로 분리

매직블록의 핵심은 솔라나의 계정 모델을 그대로 활용하면서, 실시간 갱신이 필요한 데이터 계정만 별도의 실시간 실행 환경으로 분리하는 데 있다. 솔라나는 프로그램(스마트 컨트랙트)의 실행을 담당하는 프로그램 계정과 상태를 저장하는 데이터 계정이 분리되어 있는데, 이 데이터 계정은 보통 PDA(Program Derived Address) 형태로 관리된다. PDA는 프로그램이 정해진 규칙에 따라 생성하고 제어하는 계정으로, 플레이어 위치나 게임 진행 정보, 주문 상태처럼 앱의 상태를 저장하는 데 주로 사용된다. 매직블록은 바로 이런 PDA 기반 데이터 계정의 제어권을 일시적으로 ER에 위임해, 실시간으로 바뀌는 상태만 빠르게 처리한 뒤 그 결과만 다시 솔라나에 커밋한다. 즉, ER은 앱의 데이터 계정에 대한 제어권을 일시적으로 위임받아 실시간으로 상태를 처리하고, 그 결과만 솔라나에 정산하는 구조다.

ER은 실시간 처리가 필요한 솔라나 앱이 데이터 계정의 Owner 권한을 ER 프로비저너에게 위임하면서 시작된다. 이때 위임 기간, 커밋 주기, 목표 블록타임을 함께 지정한다. 위임받은 ER 프로비저너는 해당 조건에 맞는 ER 세션을 열고, 솔라나의 최신 상태를 기준으로 위임된 계정과 실행에 필요한 계정들을 ER 안에 복제한다. 이후 위임된 계정의 상태 갱신은 솔라나가 아니라 ER 안에서만 처리된다. 그 결과 실시간으로 반복되는 입력 처리나 연속적인 상태 변경을 ER의 실행 환경 안에서 더 빠르게 수행할 수 있다.

ER에서 변경된 상태는 지정된 간격마다 솔라나에 커밋되며, 세션이 끝나면 계정 제어권도 원래 프로그램으로 돌아간다. 위임된 상태에서 해당 계정은 솔라나에서 직접 수정할 수 없고, 상태 변경은 ER 안에서만 일어난다. 반면 읽기는 계속 가능하므로, 솔라나의 다른 프로그램은 해당 계정을 계속 참조할 수 있다.

이 구조에서는 일반적인 레이어2처럼 앱과 유동성, 사용자를 별도 네트워크로 옮길 필요가 없다. 솔라나 위에 남아 있는 사용자, 자산, 프로그램을 그대로 활용하면서 필요한 부분만 선택적으로 가속할 수 있기 때문이다. 그 결과 개발자는 기존 솔라나 생태계의 조합성과 자산 기반을 유지하면서도, 게임이나 트레이딩처럼 빠른 반응 속도가 중요한 구간만 별도로 최적화할 수 있다. 이처럼 매직블록은 솔라나가 가진 생태계의 장점을 유지한 채 실시간 실행이 필요한 구간만 보완하는 방식이다.

2-2. 실시간 실행 환경을 위한 최적화

위에서 본 것처럼 ER은 솔라나의 데이터 계정을 위임받아 실시간 실행 환경에서 처리하는 구조다. 하지만 실행 환경만 빠르다고 해서 충분한 것은 아니다. 사용자의 요청이 ER 실행 환경에 도달하기까지의 과정, ER 세션의 시작을 준비하는 방식, 그리고 사용자의 요청을 적절한 실행 레이어로 보내는 과정까지를 최적화해야 ER을 사용하는 앱에게 진정한 실시간 실행 환경을 제공할 수 있다.

동적 코로케이션(Dynamic Colocation)

실시간 앱에서는 실행 속도만큼이나, 사용자의 요청이 실행 지점까지 도달하는 데 걸리는 시간도 중요하다. ER 내부 실행이 아무리 빠르더라도, 요청이 먼 지역의 노드까지 왕복해야 한다면 전체 지연시간은 그만큼 길어진다. 예를 들어, 도쿄와 뉴욕 사이의 네트워크 왕복 시간은 약 150~200ms 수준으로 알려져 있는데, 실시간 상호작용이 중요한 앱에서는 이 물리적 거리 자체가 큰 병목이 된다. 즉, 실행 환경을 얼마나 빠르게 만들었는가와 별개로, 그 실행 환경이 어디에 놓여 있는지도 전체 반응 속도를 결정한다.

매직블록은 이 문제를 동적 코로케이션으로 해결한다. 위임된 상태를 처리할 ER 세션을 하나의 고정된 물리적 지점에서만 운영하는 것이 아니라, 사용자와 가까운 지역의 ER 노드에서 실행하도록 구성한 것이다. 이를 위해 아시아, 유럽, 미국 단위의 지역별 RPC 엔드포인트를 제공하며, 사용자는 특정 지역 엔드포인트에 직접 연결하거나 아래에서 설명할 매직 라우터를 통해 가까운 지역의 노드로 자동 연결될 수 있다. 즉, 같은 ER 구조라도 사용자가 어디에서 접속하느냐에 따라 물리적 위치를 조정해, 요청이 ER에 도달하기까지의 물리적 거리 자체를 줄여, ER의 성능이 실제 사용자 반응 속도로 이어지게 만드는 역할을 한다.

매직 라우터

앱 입장에서는 사용자가 보낸 요청을 솔라나에서 처리해야 하는지, ER로 보내야 하는지를 매번 직접 판단해야 한다. 어떤 요청은 위임된 데이터 계정을 수정해야 하고, 어떤 요청은 솔라나에 남아 있는 계정을 그대로 읽거나 써야 한다. 이를 애플리케이션이 직접 처리하면, 요청마다 어느 계층에서 실행할지와 어느 엔드포인트로 보낼지를 별도로 관리해야 한다.

매직 라우터는 이 문제를 트랜잭션이 접근하는 계정을 기준으로 해결한다. 사용자가 트랜잭션을 보내면, 라우터는 해당 트랜잭션이 읽고 쓰는 계정을 확인한 뒤 실행 레이어를 정한다. 이 구조의 핵심은 요청이 어느 레이어에서, 어느 물리적 위치에서 실행돼야 하는지를 앱이 직접 나누지 않아도 된다는 점이다. 매직 라우터가 실행 레이어와 엔드포인트를 분류해주기 때문에, 앱이 ER의 실시간 실행과 솔라나를 동시에 사용하는 구조라도 하나의 흐름으로 구성할 수 있다. 사용자 입장에서는 기존과 비슷한 방식으로 지갑을 연결하고 사용하면 되므로, 앱이 ER과 솔라나에서 동시에 동작하더라도 이를 별도의 환경으로 구분할 필요 없이 하나의 앱처럼 사용할 수 있다.

JIT 클로닝

ER 세션은 먼저 열어둘 수 있지만, 실제 실행에 필요한 상태는 사용자가 어떤 요청을 보내는지에 따라 달라진다. 만약 세션이 열리는 순간부터 필요한 계정을 전부 미리 가져오려 한다면, 준비해야 할 상태 범위가 커질수록 시작 단계가 병목이 될 수 있다. 실시간 앱에서는 세션이 열린 뒤의 실행 속도만 중요한 것이 아니라, 실제 요청이 들어왔을 때 현재 상태를 얼마나 빠르게 붙여 바로 처리로 넘어갈 수 있는지도 중요하다. 매직블록이 JIT 클로닝을 쓰는 이유가 여기에 있다.

JIT 클로닝은 위임된 계정에 접근하는 최초 트랜잭션이 들어오는 시점에, 그 계정의 현재 상태를 솔라나에서 가져와 ER 안에 복제하는 방식이다. 즉, 세션이 열리는 순간 필요한 상태를 한꺼번에 미리 옮겨두는 구조가 아니라, 실제 요청이 들어와 어떤 계정이 필요한지가 드러나는 순간 그 계정만 현재 기준으로 붙이는 구조다. 예를 들어 세션은 이미 열려 있어도, 사용자가 특정 데이터 계정에 처음 상호작용을 시도하는 순간에야 그 계정의 최신 상태가 ER 쪽으로 복제된다. 이후에는 그 복제된 상태를 기준으로 ER 안에서 연속적인 입력 처리와 상태 갱신이 이어진다.

이 방식의 핵심은 세션 준비와 상태 준비를 분리한다는 데 있다. 세션 자체는 먼저 열어두고, 상태는 실제로 필요해지는 순간에만 붙이기 때문에, 실행 전에 모든 것을 미리 준비해둘 필요가 없다. 그 결과 사용자는 이미 열린 세션에 곧바로 진입할 수 있고, ER은 필요한 상태만 현재 기준으로 받아와 바로 실행을 시작할 수 있다.

 

2-3. 신뢰할 수 있는 합의 과정

ER에서 실행된 상태는 커밋(정산)을 위해 다시 솔라나로 돌아간다. 이때 중요한 것은 ER의 실행 결과, 즉 상태를 어떤 절차를 거쳐 솔라나에 반영하고 확정하는지다. 매직블록은 이 과정을 옵티미스틱 실행과 동적 사기 증명(Dynamic Fraud Proof)으로 처리한다. 구조 자체는 옵티미스틱 롤업과 유사한데, 먼저 상태 변경을 제출하고 이후 일정 기간 동안 이의 제기를 받을 수 있게 둔 뒤, 문제가 없으면 확정(Finalize)하는 방식이다.

ER에서 처리된 상태는 지정한 주기나 필요 시점, 혹은 세션 종료 시 솔라나로 커밋된다. 이때 함께 올라가는 것은 새로 반영할 상태 변경점(State diff)과, ER 세션에서 실행된 트랜잭션 기록의 위치 정보, 그리고 어떤 조건에서 해당 상태를 승인하고 확정할지를 담은 위임 기록이다. 여기서 트랜잭션 기록의 위치 정보는, 해당 상태 변경이 어떤 실행 과정을 거쳐 만들어졌는지 나중에 다시 검토할 수 있도록 남겨둔 실행 기록의 위치를 뜻한다. 즉, 솔라나에는 결과만 올라가는 것이 아니라, 그 결과를 다시 검증할 수 있는 실행 기록과 승인 조건도 함께 커밋된다.

이후에는 챌린지 기간이 시작된다. 이 기간 동안 제출된 상태 변경분은 일단 유효한 것으로 간주되지만, 활성 챌린저들은 함께 제출된 증거와 실행 기록을 바탕으로 이를 다시 검증한다. 이들은 상태 변경이 정당하게 만들어졌다고 판단하면 서명하고, 오류나 부정행위가 있다고 판단하면 챌린지를 제기해 분쟁 해결 절차로 넘긴다. 그리고 챌린지 기간이 끝났을 때 충분한 수의 서명이 모이면 상태 변경분은 최종 확정된다. 매직블록은 일반적인 옵티미스틱 롤업처럼 긴 고정 챌린지 기간을 두는 대신, 짧게 시작한 뒤 필요할 때만 연장하는 동적 사기 증명 구조를 사용한다. 정상적인 조건에서는 약 500ms 수준의 짧은 챌린지 기간만으로도 상태 확정을 노릴 수 있어, 실시간 앱에 필요한 반응 속도를 확보할 수 있다.

여기서 중요한 것은 매직블록이 빠른 확정을 단순히 낙관적으로 가정하는 것이 아니라, 그 가정을 유지하도록 경제적 장치를 함께 둔다는 점이다. ER 세션을 운영하는 노드는 잘못된 상태 변경을 제출하면 본딩한 자산을 잃거나 슬래싱될 수 있다. 상태 변경을 검토하는 챌린저는 잘못된 커밋을 발견하고 챌린지를 제기할 유인을 가진다. 매직블록은 이렇게 제출자와 검증자 모두에게 경제적 책임과 유인을 부여해, 빠른 확정이 무작정 낙관에만 기대지 않도록 설계했다.

 

3. 프라이빗 일시적 롤업 : PER(Private Ephemeral Rollup)

모든 것이 공개된 블록체인 환경에서는 실시간 실행만으로 해결되지 않는 문제가 남는다. 결제, 트레이딩, 기업형 워크플로우처럼 상호작용의 내용 자체가 노출되면 치명적인 영역이 있기 때문이다. 이러한 프라이버시를 지키기 위해 등장한 PER은 ER에 TEE(Trusted Execution Environment) 기반의 비공개 기능을 더한 구조다. TEE는 CPU 내부의 격리된 실행 환경으로, 코드와 데이터를 외부 운영체제나 제3자가 직접 들여다볼 수 없도록 보호한다. PER은 이 환경 안에서 민감한 상태와 상호작용을 처리한 뒤, 필요한 결과만 외부에 반영하는 방식으로 프라이버시를 확보한다. 그 결과 솔라나의 실시간 실행 성능은 유지하면서도, 민감한 정보는 외부에 노출하지 않는 구조를 만들 수 있다.

3-1. TEE를 선택한 이유

현재 블록체인에서 프라이버시를 구현하는 방법은 크게 4가지가 있지만, 매직블록은 그중 TEE를 택했다. PER이 노리는 것은 단순한 비공개성이 아니라, 실시간 앱이 실제로 사용할 수 있는 속도를 유지하면서도 민감한 상태를 보호하는 것이기 때문이다. ZK, FHE, MPC 같은 방식은 각각 장점이 분명하지만, 실시간 앱에 필요한 짧은 지연시간을 유지한 채 범용 실행을 처리하기에는 지연 시간, 실행 비용이 크다. 반면 TEE는 CPU 내부의 보호된 실행 구역에서 코드를 처리하므로, 일반적인 실행 환경에 가까운 방식으로 연산을 수행하면서도 외부로부터 상태와 메모리를 보호할 수 있다. 실시간성이 중요한 환경에서 성능 저하를 최소화하면서 비공개적으로 처리할 수 있다는 점이 TEE의 가장 큰 장점이다.

이 점은 ER의 구조와도 잘 맞는다. ER은 솔라나 상태 일부만 분리해 실시간으로 실행하는 구조다. 여기에 TEE를 결합하면, 빠르게 처리해야 하는 실행 환경을 그대로 유지하면서도 그 과정과 결과인 상태를 외부에 드러내지 않을 수 있다. 개발자는 일반 솔라나 프로그램에 가까운 방식으로 실시간 프라이버시 앱을 만들 수 있고, 사용자는 기존의 솔라나 계정으로 상호작용할 수 있다. 즉, TEE는 ER의 실시간 실행 구조를 유지한 채 비공개 실행을 추가하면서도, 별도의 체인이나 새로운 사용 환경을 요구하지 않기 때문이다.

3-2. PER이 접근을 제어하는 방법

PER은 솔라나에 배포된 접근 제어 프로그램을 통해 그룹 단위로 접근 범위를 나누고, 각 그룹에 허용된 사용자만 특정 계정의 상태를 볼 수 있게 만드는 구조다. 즉, 계정을 기준으로 어떤 사용자 집단에게 어떤 상태를 열어둘지를 정하는 방식이다. 예를 들어 결제 서비스라면 운영 담당자, 규정 준수 담당자, 감사 담당자처럼 역할별로 접근 그룹을 나누고, 같은 계정이라도 각 집단이 볼 수 있는 범위를 다르게 설정할 수 있다. 이렇게 지정된 비공개 상태는 PER 세션 안에서 보호되며, 권한이 없는 제3자는 이를 조회할 수 없다.

이후 사용자가 앱에 접속하면, 앱은 매직블록의 TEE 엔드포인트에 서명을 제출해 접근 자격을 확인받고 액세스 토큰을 발급받는 과정을 처리한다. 사용자는 그 다음부터 별도의 비밀번호를 다시 입력하거나 추가 인증을 거치지 않아도, 발급받은 토큰만으로 접근이 제한된 비공개 상태를 조회할 수 있다. 즉, 사용자는 일반적인 앱을 쓰듯 접속하지만, 실제로는 그 뒤에서 권한 확인과 비공개 상태 접근이 자연스럽게 처리되는 구조다.

이를 통해 비공개 결제, 트레이딩, 기관용 워크플로처럼 공개 상태만으로는 구현하기 어려웠던 앱도 매직블록을 통해 솔라나 위에서 구축할 수 있다. 중요한 점은 이 구조를 앱이 처음부터 직접 구현할 필요가 없다는 데 있다. 즉, 별도의 프라이버시 네트워크를 새로 구축하거나 전용 서버 인프라를 직접 운영하지 않아도, 프라이빗 실시간 앱을 솔라나 위에 붙일 수 있는 구조다. 매직블록이 실시간 실행 성능과 프라이빗 실행 환경을 함께 제공하므로, 앱은 이를 직접 구현하는 데 드는 비용과 시간을 줄이고 서비스 기획, 기능 설계, 비즈니스 모델에 더 집중할 수 있다.

 

4. 매직블록, 어떻게 사용할 수 있을까?

4-1. ER의 활용 방법

앞서 설명한 ER은 구조 자체만 보면 다소 추상적으로 느껴질 수 있다. 상태를 위임해 별도 환경에서 실행한다는 설명만으로는, 이것이 실제 앱에서 어떤 차이를 만드는지 바로 연결하기 어렵다. 그래서 매직블록이 제시한 오라클, 프라이버시, 게임과 같은 효과가 가장 직관적으로 드러나는 데모를 중심으로 ER의 활용 사례를 살펴본다.

1) 오라클 : Magicblock x Pyth

매직블록과 Pyth가 구현한 실시간 오라클은 Pyth가 전달한 가격 정보를 ER에 위임한 데이터 계정에 반영하고, 앱은 그 계정을 직접 읽어 가격을 갱신하는 방식으로 동작한다. 사용자는 별도 서버를 거쳐 늦게 들어오는 시세가 아니라, 온체인에 반영된 가격을 바로 사용할 수 있다. 가격은 약 50ms마다 업데이트되며, 이는 실시간의 기준으로 자주 언급되는 100ms보다 더 짧다. 이러한 실시간 오라클이 자리 잡으면 거래소처럼 가격 반영 속도가 중요한 앱도 온체인에서 더 자연스럽게 구현할 수 있다.

이 구조의 핵심은 가격 정보가 외부 서버에 따로 머무는 것이 아니라, ER에 위임한 데이터 계정에 바로 반영된다는 점이다. 앱은 그 계정을 직접 읽으면 되기 때문에, 가격 반영을 위해 별도 서버를 따로 두는 구조보다 더 단순하게 설계할 수 있다. 또 부동산, 토큰화 주식, 원자재처럼 주로 오프체인에서 거래되고 가격이 형성되는 자산도 같은 방식으로 온체인 오라클 피드에 연결할 수 있으므로 랜딩 프로토콜, 프라이빗 크레딧, 구조화 상품처럼 오프체인 자산의 실시간 가격 반영이 중요한 디파이 서비스까지 확장할 수 있는 잠재력으로 이어진다.

2) 프라이버시 : Private Payments

비공개 결제의 경우, 사용자가 솔라나에 자산을 예치한 뒤 해당 계정을 PER에 위임하면, 이후 송금은 PER 내에서 비공개로 처리할 수 있다. 예를 들어 Bob이 100 USDC를 넣으면, 그 잔액은 TEE 기반 실행 환경 안에서 Alice에게 비공개로 이동한다. 이후 Alice는 원할 때 undelegate해 출금할 수 있다. 자산의 입출금과 최종 정산은 솔라나에서 유지하면서, 중간의 결제 내역과 잔액 변화는 PER을 통해 권한이 있는 주체만 확인할 수 있도록 외부에 드러나지 않게 분리한 방식이다.

이 구조의 특징은 결제 데이터를 무조건 감추는 데 있지 않고, 권한에 따라 필요한 주체에게만 열 수 있다는 점에 있다. 실제 결제 당사자뿐 아니라, KYC·KYB를 수행하는 결제 제공자나 운영 주체도 계정 단위 접근 권한을 바탕으로 필요한 정보를 확인할 수 있다. 그래서 온체인 자산 관리와 정산은 유지하면서도, 민감한 결제 데이터는 제한된 범위 안에서만 공유하는 방식이 가능해진다. 이 구조가 자리 잡으면 급여 지급, 기업 정산, 파트너 결제처럼 기밀성과 규정 준수를 함께 요구하는 업무는 물론이고, 더 나아가 금융기관이나 규제 대응 주체가 필요한 범위에서 정보를 확인해야 하는 워크플로우로도 확장될 수 있다.

3) 게임 : Solana-Generals

상대와 경쟁하는 실시간 전략 게임인 Solana-Generals는 사용자가 맵 위에서 이동하고, 영역을 넓혀가며 게임을 진행한다. 이 게임은 솔라나와 매직블록 개발 환경 위에서 서버 없이 완전히 온체인 기반으로 동작하고, 게임 데이터를 저장하는 구조와 이를 바꾸는 로직이 모두 온체인 프로그램 안에 들어 있다. 두 사용자가 게임을 시작한 뒤 행동을 입력하면, 그 결과가 즉시 게임 상태에 반영된다. 전략 게임은 이동, 점령, 전투처럼 짧은 간격으로 반복되는 입력과 상태 변화를 계속 요구하는데, Solana-Generals는 이 부분을 실시간으로 처리할 수 있도록 설계돼 있다.

기존 게임은 자산과 진행 데이터가 게임사 서버에 묶여 있어, 플레이어가 가진 아이템과 기록을 완전히 소유하기 어렵고 서버가 종료되면 게임도 함께 멈춘다. 결국 플레이어가 쌓아온 게임 내 기록과 자산의 존속 여부도 게임사 결정에 따라 달라진다. Solana-Generals처럼 게임 로직과 플레이 진행을 온체인에 두면, 플레이어가 쌓은 기록과 자산도 블록체인에 남아 계속 소유할 수 있고 승패 판정, 확률, 상태 변화가 어떤 규칙에 따라 이뤄졌는지도 확인하고 검증할 수 있다. 이는 실시간 게임도 중앙 서버 없이 솔라나와 ER만으로 구현할 수 있음을 보여주는 사례다.

4-2. 토크노믹스 : 네트워크 토큰 $BLOCK 사용

매직블록의 네트워크 토큰인 $BLOCK은 2026년 2분기 TGE를 앞두고 있으며, 스테이킹·슬래싱, 프로토콜 수수료, 성과 연동 인센티브를 하나의 구조로 묶어 설계했다. ER 노드 오퍼레이터는 요청된 ER 세션을 실행하고, 그 안에서 처리된 상태를 솔라나에 커밋한다. 이들은 $BLOCK을 담보로 스테이킹해 네트워크 운영에 참여하고, 그 대가로 보상을 받는다. 반면 가동 시간이나 성능 기준을 충족하지 못하거나 잘못된 상태 업데이트를 커밋하면 스테이킹한 담보가 슬래싱되는 패널티를 받는다.

앱이 더 많은 계정을 ER에 위임할수록 프로토콜 사용량이 늘고, ER의 상태 커밋과 위임 해제에서 발생하는 수수료도 함께 증가한다. 보상은 가장 많이 위임을 만든 앱에 발행량 일부를 분배하는 방식으로 설계되었으며, 프로토콜은 이 수수료를 바탕으로 향후 $BLOCK 바이백을 도입해, 네트워크 사용량 증가가 홀더의 가치로 연결되는 구조를 만들 계획이다.

 

5. 결론 : ER은 실시간 블록체인의 새로운 기준이 될 수 있을까

퍼블릭 블록체인은 실시간 앱을 온전히 담아내기 어렵고, 별도의 레이어2로 분리하면 상태와 유동성이 파편화된다. 매직블록은 이 문제를 ER을 통해 별도의 실시간 실행 레이어를 두되, 정산은 계속 솔라나에 남기는 방식으로 풀고 있다. 여기에 PER까지 더하면서, 실시간 실행과 프라이버시를 함께 제공하는 구조로 확장하고 있다. 2025년 6월 매직넷의 출시 이후 매직블록은 18개의 실제 애플리케이션에서 10억 건 이상의 트랜잭션을 처리했고, 25만 건의 위임과 2만7000개의 고유 주소를 기록하면서 실시간 앱에 대한 수요가 실재함을 보여줬다.

현재 매직블록은 생태계 확장 단계에 있다. 더 많은 개발자가 매직블록 위에서 앱을 만들고, 그 앱이 실제 사용자를 모으고, 다시 네트워크 사용량과 수수료로 이어지는 플라이휠을 형성해야 한다. 다만 아직 TGE가 진행되지 않은 만큼, 이후 토큰 인센티브와 생태계 확장 전략이 맞물리며 이 플라이휠이 얼마나 빠르게 작동하기 시작할지는 앞으로 지켜봐야 할 부분이다.

매직블록은 해법을 실제 구조로 제시하고 있다는 점에서 기술적 차별성과 강점이 분명하다. 블록체인이 자산 발행과 정산을 넘어 게임, 결제, 금융, SNS 같은 실시간 앱의 인프라로 확장되려면, 결국 유동성과 사용자가 이미 모여 있는 레이어1 위에서 속도와 프라이버시 문제를 푸는 방식이 가장 효과적이기 때문이다. 앞으로 더 많은 앱으로 사용이 확대된다면 ER 기반의 실시간 앱, 서버 없는 완전한 온체인 구조는 하나의 새로운 기준으로 자리 잡을 수 있을 것이다. 이런 점에서 매직블록은 앞으로의 전개가 더욱 주목된다.