Miden, 모두의 프라이버시를 위한 투명 망토

목차

1. 웹3 매스 어돕션의 큰 장벽 - 프라이버시

2. 기존 프라이버시 체인들의 한계

3. 프라이버시와 확장성을 모두 잡는 Miden의 차별성

4. 그래서 이게 어떻게 가능한가?

5. Miden에서는 무엇이 가능해지는가? (Use Case)

6. 마무리: ZK 네이티브 체인은 새로운 표준이 될 수 있을까

 

1. 웹3 매스 어돕션의 큰 장벽 - 프라이버시

전세계적으로 5.9억명 이상의 가상자산 보유자가 존재하고, 국내 가상자산 거래소 가입자가 1,600만명을 넘어가며 비트코인과 이더리움 ETF가 승인되고 있는 지금은 이미 매스 어돕션이 이루어졌다고 볼 수 있을까? 진정한 매스 어돕션은 전통 금융과 기관들이 보유한 막대한 유동성이 웹3 시장으로 흘러들어왔을 때 비로소 실현될 수 있다. 그러나 아직도 여전히 기관이나 국가가 본격적으로 웹3 시장에 진입하기에는 많은 진입장벽이 존재한다.

기관들이 직접 가상자산을 매수하고 보유하는 과정만 보더라도 현실적인 제약이 크다. 우선 중앙화 거래소(CEX)를 통해 가상자산을 매수하고자 할 경우, 법인 명의의 계좌 개설 자체가 높은 진입장벽으로 작용한다. 국내에서는 2025년에 들어서야 일부 거래소에서 법인 계좌 개설이 허용되기 시작했으며, 해외의 경우에도 KYC·AML 요건, 실질소유자(UBO) 확인, 거래 목적 증명 등 까다로운 절차를 거쳐야만 계정 개설이 가능했다. 설사 계좌를 개설하더라도, 기관이 대규모 자금으로 포지션을 구축하면 시장 충격이 발생해 원하는 가격으로 주문을 체결하기 어렵고, 거래 자체가 시장에 노출되는 문제가 발생한다.

출처: Arkham X

그렇다고 탈중앙화 거래소(DEX)로 눈을 돌리기도 쉽지 않다. DEX는 완전한 온체인 구조이기 때문에 거래 기록이 모두 공개되며, 대규모 주문은 CEX보다도 더욱 큰 슬리피지(slippage)와 가격 급변을 유발한다. 또한 DEX 이용에는 지갑 관리, 키 보관, 네트워크 수수료 등 전통 금융기관이 감당하기 어려운 운영 및 규제 리스크가 수반된다.

이처럼 제도권 수준의 자산 보관 및 거래 인프라가 완비되지 않은 상황에서, 기관이 수십억 달러 규모의 자금을 온체인에 직접 배치하기는 여전히 어렵다. 실제로 미국과 유럽의 다수 금융기관은 가상자산을 직접 보유하거나 거래하기보다 ETF나 신탁상품을 통한 간접 투자 방식에 머물러 있다.

이는 단순히 커스터디, 회계, 규제 인프라가 미비해서일 뿐이 아니라, 온체인 환경의 ‘지나친 투명성’이 기관의 리스크 관리와 법적 의무 준수를 동시에 어렵게 만들기 때문이다. 블록체인에서는 모든 거래가 실시간으로 공개되기 때문에, 기관이 고객 자산을 운용하거나 내부 포지션을 조정하는 과정에서 거래 전략, 자산 규모, 고객 정보가 그대로 노출될 위험이 있다. 이는 금융기관이 가장 엄격히 지켜야 하는 정보보호·프라이버시 규제(GDPR, AML/KYC 등)와 정면으로 충돌한다.

결국, 커스터디나 회계 인프라의 부족보다 더 근본적인 문제는 ‘프라이버시가 없는 공개 장부’라는 블록체인의 구조적 한계다. 기관이 웹3 생태계로 진입하기 위해서는 거래의 무결성과 투명성을 유지하면서도, 법적 규제와 보안 요구를 충족할 수 있는 프라이버시 계층(privacy layer) 이 반드시 필요하다. 따라서 웹3에서 기관 자금이 본격적으로 운용되기 위한 가장 핵심적인 전제 조건은 ‘프라이버시의 확보’ 라고 할 수 있다.

블록체인의 본질적 특성인 투명성(Transparency)은 탈중앙 네트워크의 신뢰 기반을 형성하는 강점이지만, 기관 입장에서는 오히려 프라이버시 침해와 보안 리스크를 초래한다. 이는 다음 세 가지 문제로 구체화된다.

1) 규제 준수와 데이터 보호의 딜레마 기관은 고객 자산을 위탁·운용하는 과정에서 고객의 신원과 거래 정보를 안전하게 보호해야 한다. 개인정보보호법(GDPR)이나 금융정보보호 규정에 따라, 고객 정보가 외부에 노출되면 법적 제재를 받을 수 있다. 그러나 블록체인에서는 모든 거래가 공개 장부에 기록되기 때문에, 이를 그대로 이용하면 기관은 규제 위반 위험에 직면한다. 결국 기관이 고객 자금을 온체인에서 운용하려면, 거래의 무결성을 유지하면서도 민감한 정보를 비공개로 처리할 수 있는 프라이버시 보존형 인프라가 필요하다.

2) 프라이버시를 지키는 행위 자체가 규제 위반이 되는 역설 반대로, 기관이 거래 내역을 보호하기 위해 프라이버시 체인이나 믹서 서비스를 활용할 경우, 이번엔 자금세탁방지(AML) 규제 위반으로 간주될 수 있다. 실제로 Zcash, Monero 등 주요 프라이버시 코인은 EU 및 미국 주요 거래소에서 상장 폐지 되었으며, Tornado Cash는 미 재무부 산하 OFAC의 제재 명단에 오르며 서비스 차단 및 개발자 구속까지 이어졌다. 즉, 기관은 “정보를 공개해도 규제 위반, 숨겨도 규제 위반”이라는 구조적 모순 속에 놓여 있는 셈이다.

3) 포지션 노출로 인한 시장 공격 리스크

위 두 가지 규제적 리스크 외에도 시장 차원의 리스크가 존재한다. 기관이 대규모 포지션을 온체인에 개시할 경우, 해당 거래 내역이 실시간으로 공개되어 시장의 공격 대상이 될 수 있다. 전통 금융에서는 이런 위험을 피하기 위해 다크풀(dark pool) 이나 OTC(Over-the-Counter) 거래를 활용하여 거래 내역과 주문 정보를 비공개로 유지하지만, 블록체인에서는 거래 시점과 금액, 주소가 모두 공개된다.

출처: Lookonchain X

2025년 5월, Hyperliquid 선물 시장에서는 대형 트레이더인 Wynn이 자신의 포지션을 공개한 뒤, 대규모 숏 포지션 세력에 의해 의도적인 포지션 청산 공격(liquidation attack) 을 당하는 사례가 발생했다. 이는 온체인 상에서 거래 투명성이 얼마나 쉽게 정보 비대칭을 깨뜨리고 시장 조작의 기회를 제공할 수 있는지를 보여주는 대표적 사례다.

결국, 기관이 온체인 자산을 운용하기 위해서는 단순한 기술적 편의성보다 프라이버시 보호와 규제 적합성 간의 균형이 필수적이다. 투명성과 신뢰를 기반으로 성장한 블록체인 생태계가 다음 단계로 나아가기 위해서는, 합법적이고 감사 가능한 프라이버시 계층의 구축이 무엇보다 중요하다.

이러한 문제의식을 바탕으로 다양한 프라이버시 체인과 디앱들이 등장했지만, 확장성·상호운용성·거버넌스 구조의 한계로 인해 여전히 기관 수준의 신뢰를 확보하지는 못했다. Miden은 이러한 기존 블록체인 및 프라이버시 체인의 구조적 한계를 모두 극복하고자 설계되었다.

 

2. 기존 프라이버시 체인들의 한계

기존의 프라이버시 체인들은 분명 거래 익명성이나 프라이버시 보장을 강화하는 데 의미 있는 시도를 해왔지만, 확정성(finality), 실행 모델, 상호운용성 측면에서 한계를 드러냈다.

2-1. 확장성과 프라이버시의 Trade-Off

프라이버시 체인들은 사용자 정보와 거래 내용을 숨기기 위해 영지식 증명(ZK), MPC, FHE 등 연산 비용이 큰 암호 기술을 사용한다. 이러한 기술은 높은 수준의 프라이버시를 제공하지만, 그만큼 트랜잭션 크기가 커지고 블록 생성·검증 단계에서 필요한 연산량도 증가해 확장성이 제한되는 구조적 제약을 만든다.

대표적인 사례가 Zcash다. Zcash는 비트코인을 포크한 구조 위에 zk-SNARK 기반의 shielded 트랜잭션을 추가했는데, 이러한 설계는 본래 비트코인과 유사한 보수적 합의 파라미터(블록 크기 2MB, 블록 생성 75초)를 유지하면서도 ZK 증명의 추가 연산 부담까지 갖게 만든다. 이 구조에서는 블록 크기를 크게 확장하거나 블록타임을 과감하게 단축하기 어렵고, 그 결과 실제 처리량은 shielded 중심일 때 약 5~6 TPS, 퍼블릭 트랜잭션을 포함해도 약 20 TPS 수준에 머문다. 프라이버시 강화가 곧 확장성 제약으로 이어지는 대표적인 사례다.

프라이버시를 기본값으로 채택한 Monero도 유사한 문제를 겪는다. Monero는 링 서명, RingCT, Bulletproofs+ 등 다양한 프라이버시 기술을 동시에 적용해 강력한 익명성을 제공하지만, 그만큼 트랜잭션 데이터가 커지고 검증 비용이 증가한다. 블록 생성 시간 또한 120초로 고정되어 있어 처리량이 구조적으로 제한된다. 실제 평균 블록 크기(약 70–80KB)와 트랜잭션 크기(약 2KB)를 기준으로 계산하면 한 블록에는 수십 건의 트랜잭션만 담을 수 있으며, 실질 처리량은 약 0.2~0.4 TPS 수준에 불과하다. 동적 블록 크기 모델을 채택하고 있어 이론적으로는 더 높은 처리량을 기대할 수 있지만, 검증 부담과 안정성 문제 때문에 실제 메인넷에서는 크게 확장되기 어렵다. 이로 인해 혼잡 시 수수료가 자연스럽게 증가하는 구조가 형성된다.

즉, 기존 프라이버시 체인들은 프라이버시 강도를 높일수록 처리속도와 비용 측면에서 한계를 겪는 경우가 많았고, 이러한 구조적 Trade-Off를 완전히 해결하지는 못했다.

2-2. 단순한 전송에만 사용되고, 스마트 컨트랙트 구현이 어려움

출처: Sandeep X

최근 Polygon의 CEO Sandeep이 “Zcash가 프라이빗 비트코인이라면, Miden은 프라이빗 이더리움이다”라고 언급한 것처럼, 기존 프라이버시 체인 대부분은 단순 자금 전송 기능에 초점을 맞춰 설계돼 왔다. 특히 Zcash는 비트코인 코드를 기반으로 포크된 구조이기 때문에 스마트컨트랙트 실행 환경을 갖추지 못했고, 복잡한 로직을 온체인에서 처리하기 어렵다. 더불어 shielded 트랜잭션의 높은 연산 비용으로 인해 속도도 느리고 수수료 부담 역시 크다. 결국 Zcash는 강력한 프라이버시는 제공했지만, 기능적 측면에서는 “프라이빗 버전의 비트코인”에 가까운 역할을 해왔다.

이에 반해 Miden은 온체인에서 스마트컨트랙트를 실행할 수 있는 구조로 설계돼 있다. 단순한 자산 전송을 넘어 다양한 온체인 활동을 프라이버시를 유지한 상태에서 구현할 수 있으며, 개발자가 복잡한 애플리케이션 로직을 작성할 수 있는 확장된 환경을 제공한다. 이러한 점에서 Miden은 기존 프라이버시 체인들이 갖지 못했던 프라이버시 + 범용 스마트컨트랙트 기능을 동시에 제공하는 새로운 형태의 프라이버시 확장 솔루션이라고 할 수 있다.

2-3. 중앙화된 실행 모델 의존

여러 프라이버시 체인은 프라이버시 기능을 구현하기 위해 중앙화된 리레이어(relayer), 트러스트드 셋업(trusted setup), 혹은 중앙화된 키 관리 구조에 의존하는 경우가 많았다. 이러한 설계는 초기에는 구현 편의성을 제공하지만, 장기적으로는 네트워크의 신뢰성과 프라이버시 자체를 해치는 구조적 한계를 낳는다.

출처: 미국 재무부

대표적으로 Tornado Cash는 익명 전송 기능을 위해 리레이어(relayer)라는 중간 실행자에 의존했다. 리레이어는 사용자를 대신해 출금 트랜잭션을 실행하여 지갑 노출을 막아주는 역할을 한다. 그러나 이 구조는 미국 OFAC 제재 이후 프론트엔드 차단과 리레이어 운영 위축이 겹치면서 서비스 접근성과 사용성이 크게 떨어졌다. 이는 프라이버시 시스템의 일부가 중앙화되어 있을 경우, 외부 압력에 따라 기능이 쉽게 제한될 수 있음을 보여준다.

또한 중앙화된 실행 모델에서는 트랜잭션을 재실행하는 주체가 존재하기 때문에, 이 과정에서 사용자 트랜잭션 정보가 부분적으로라도 노출될 가능성이 있으며, 이는 프라이버시 체인이 추구하는 근본적 목표와 충돌한다.

반면 Miden은 이러한 중앙화된 실행 모델을 전제로 하지 않는다. 모든 트랜잭션은 사용자가 로컬에서 직접 실행하고, 그 결과를 ZK 증명 형태로 제출하는 구조이기 때문에, 네트워크가 재실행할 필요도 없고 트랜잭션 내용이 외부로 노출될 여지도 없다. 즉, 프라이버시·탈중앙성·확장성이라는 세 가지 목표를 충돌 없이 동시에 달성할 수 있도록 설계되었다.

2-4. 상호운용성의 부재

대부분의 프라이버시 체인은 독립된 L1 또는 앱체인 형태로 구축되어 외부 생태계와의 상호운용성이 제한적이다. 이로 인해 프라이버시 체인에서 생성된 자산이나 거래 데이터가 다른 체인(Ethereum, Polygon 등)으로 자유롭게 이동하지 못하며, 프라이버시와 유동성 간의 단절이 발생한다. 결국 프라이버시를 확보하는 대신 사용성과 확장성을 희생하게 되는 구조다.

반면 Miden은 Agglayer 통합을 통해 이 문제를 근본적으로 해소한다. 클라이언트 사이드 실행과 ZK 증명 구조를 기반으로 프라이버시를 유지하면서도 Ethereum을 포함한 다양한 웹3 생태계와 직접적으로 연결될 수 있는 환경을 제공한다. 이를 통해 기존 프라이버시 체인이 겪어온 고립 문제를 제거하고, 프라이버시와 상호운용성을 동시에 확보할 수 있게 된다.

즉, Miden은 프라이버시 중심 체인들이 선택의 대가로 포기해야 했던 확정성, 탈중앙성, 유동성, 상호운용성을 모두 양립시키는 새로운 아키텍처를 제시한다.

 

3. 프라이버시와 확장성을 모두 잡는 Miden의 차별성

지금까지 여러 프라이버시 체인들이 등장했지만, 여전히 기관의 본격적인 도입은 이루어지지 못하고 있다. 앞서 살펴본 바와 같이 기존 솔루션들은 확정성, 실행 모델, 상호운용성 등 여러 측면에서 구조적 한계를 지니고 있다. Miden은 이러한 한계들을 근본적으로 보완하기 위해 탄생한 새로운 형태의 ZK 기반 레이어2로, 강력한 기술적 배경과 클라이언트 사이드 실행(Client-side Execution) 이라는 혁신적인 아키텍처를 바탕으로 프라이버시와 확장성을 동시에 달성하고자 한다. 본 장에서는 Miden이 이러한 목표를 실현하기 위해 제시하는 핵심적인 차별성을 살펴본다.

3-1. 강한 팀: 폴리곤 기반, 팀원들 출신, 시드 투자 등

Miden은 Polygon Labs에서 인큐베이팅된 ZK 기반 프라이버시 레이어2 프로젝트로, 기존 폴리곤 생태계 내에서 진행되던 기술을 바탕으로 독립한 별도의 플랫폼이다. Miden은 폴리곤의 Agglayer 프로그램을 통해 스핀아웃된 후, Andreessen Horowitz(a16z crypto), 1kx, Hack VC 등 톱티어 벤처캐피탈의 리드를 통해 총 2,500만 달러(Seed 라운드) 투자를 유치했다.

Polygon은 다양한 ZK 프로젝트를 인수·통합하며 ZK 기술 전반을 가장 폭넓게 확보한 생태계다. zkEVM, Mir, Miden 등을 통해 빠른 증명 속도, 높은 확장성, 그리고 프라이버시를 모두 지원하며, 특히 자체 개발한 Plonky2, Starky와 같은 자체 프루빙(Proving) 기술로 효율적인 ZK 롤업을 구현했다. 특히 Polygon이 개발한 Plonky2는 업계에서 가장 빠른 재귀 증명 시스템 중 하나로, zkEVM과 Miden 모두의 핵심 엔진으로 활용되고 있다.

팀 구성도 매우 탄탄하다. 공동창업자 Azeem Khan은 Polygon Labs에서 생태계 확장과 비즈니스 전략을 총괄했던 인물로, 이후 레이어2 프로젝트인 Morph의 공동창업자(CO-Founder) 겸 COO로 참여한 이력이 있다. 현재는 Miden의 운영과 파트너십 전반을 이끌며 프로젝트 확장 전략을 주도하고 있다.

기술 개발을 이끄는 핵심 인물은 Bobbin Threadbare로, 이전에는 Facebook(Novi) 의 암호화 연구팀에서 Move VM과 ZK-STARK 관련 시스템을 설계했던 엔지니어다. 그는 Polygon MidenVM과 STARK 프로버의 아키텍처 설계를 총괄하며, Miden의 기술적 방향성을 주도하고 있다.

결국 Miden 팀은 메타·폴리곤 등 대형 테크 및 블록체인 기업 출신 인재들이 핵심 개발을 주도하고 있으며, 전문성을 갖춘 팀으로 평가된다. 이처럼 팀과 투자, 그리고 배경 기술력이 모두 확실히 갖춰져 있다는 점이 Miden의 가장 큰 강점이다.

3-2. 4가지 프라이버시

일반적으로 블록체인에서 제공할 수 있는 프라이버시는 이렇게 4가지의 프라이버시로 분류해볼 수 있다. 0단계의 경우 아무 프라이버시도 없는 일반적인 블록체인이다. 블록체인은 기본적으로 투명성을 중요한 특성으로 가지기 때문에 모두가 블록체인 내에서 발행하는 모든 정보를 볼 수 있다. 하지만 앞서 언급했듯 프라이버시가 없는 블록체인의 한계는 진정한 웹3 매스 어돕션을 막는 큰 장애물이 되고 있다.

현재 은행, 카드사, 결제사 등이 제공하는 프라이버시를 가장 기본적인 1단계의 프라이버시라고 할 수 있다. 일반적으로 고객들이 돈을 전송하거나 결제를 하게 되면 그 정보는 거래 당사자인 나와 거래 상대방, 그리고 중개자 역할을 하는 은행, 카드사, 결제사 등만 알게 되고 나머지 사람들은 이 정보에 접근할 수 없다.

다음으로 2단계는 거래 당사자들만이 해당 거래에 대해서 알 수 있는 거래이다. 이에 대한 예시로는 대면으로 현금 거래를 하는 것을 들 수 있다. 해당 거래에 대해서 알 수 있는 당사자는 오직 물건을 구매한 사람과 판매한 사람이며, 이 기록은 두 사람의 장부 외에 어느 곳에도 기록되지 않는다.

마지막으로 3단계의 프라이버시는 모두가 자신의 데이터만 볼 수 있는 프라이버시이다. 거래를 했지만, 수취자는 전송자가 누구인지 알 수 없는 것이다. 유저들은 오로지 자신이 보냈거나 받은 거래에 대해서만 알 수 있고, 자산의 자산 상태만 알 수 있다. 이처럼 오직 본인의 데이터는 본인만이 알 수 있고 관리할 수 있는 3단계의 프라이버시가 Miden이 최종적으로 바라는 프라이버시이다.

3-3. 클라이언트 측 실행 (Client-Side Execution)

Miden이 목표로 하는 3단계 프라이버시를 구현하기 위해서는, 기존 블록체인이 사용해온 온체인 실행 중심 모델로는 도달할 수 없다. 비트코인이나 이더리움과 같은 블록체인은 모든 트랜잭션을 온체인에서 직접 실행하고, 그 과정과 결과가 전부 공개된다. 따라서 체인 데이터는 누구나 열람할 수 있으며, Arkham과 Chainalysis 같은 온체인 분석 서비스들은 온체인 데이터를 오프체인 정보와 결합해 특정 주소가 누구와 연결돼 있는지, 어떤 자금 흐름을 갖고 있는지까지 추적한다. 이 때문에 사용자의 잔고·거래 내역뿐 아니라 전략적 행위까지 노출되는 구조적 프라이버시 문제가 발생한다.

이는 모든 노드가 모든 트랜잭션을 직접 실행하고 검증하는 구조에서 비롯된다. 실행 과정 자체가 투명하게 공개되기 때문에 프라이버시가 사라질 뿐 아니라, 트랜잭션이 직렬로 처리되는 전통 블록체인의 특성상 처리량(TPS)과 비용 측면에서도 한계가 발생했다. 트랜잭션이 몰릴 때마다 병목이 생기고, 가스비가 급등하는 문제도 이 구조의 연장선이다.

솔라나, 수이, 앱토스 등은 병렬 실행 모델을 도입해 속도·비용 문제는 어느 정도 완화했지만, 여전히 모든 노드가 유저 트랜잭션의 내용을 직접 들여다보고 실행한다는 점 자체는 변하지 않았기 때문에 프라이버시 문제는 그대로 남아 있었다.

Miden은 이 지점을 근본적으로 재설계해, 트랜잭션 실행을 네트워크가 아니라 사용자 단말(클라이언트)로 이전하는 ‘클라이언트 측 실행’을 도입했다. 사용자는 자신의 트랜잭션을 로컬에서 직접 실행하고 그 결과를 ZK 증명 형태로 제출하며, 네트워크 노드는 이 증명만 검증하면 된다. 이 구조를 통해 Miden은 병렬 실행의 확장성과 프라이버시 보호를 동시에 달성할 수 있다.

‘클라이언트 측 실행’에 대해서 조금 더 자세히 살펴보자면, 기존의 트랜잭션 처리방식은

[유저가 트랜잭션 생성 → 네트워크가 실행 → 네트워크가 검증 → 블록 생성]

이라는 흐름이었지만, Miden은 이 실행 단계를 유저 측으로 이동시킨다. Miden에서는 트랜잭션의 흐름이 다음과 같이 바뀐다.

[유저가 트랜잭션 생성 → 로컬에서 직접 실행 → 로컬에서 ZK 증명 생성 → 네트워크는 증명만 검증 → 블록 생성] 즉, 트랜잭션의 실행(execution) 과 증명(proving) 은 유저가 담당하고, 네트워크는 증명의 유효성만 검증해 블록을 만든다. 노드는 더 이상 유저의 내용을 들여다보며 실행할 필요가 없고, 유저가 어떤 상태 변화를 일으켰는지 원문 데이터를 볼 필요도 없다. 오직 “이 트랜잭션은 정당하게 실행된 것이 맞다”는 ZK 증명만 확인하면 된다.

이 구조는 두 가지 효과를 동시에 가져온다.

• 확장성 강화
  • 네트워크가 담당하던 가장 무거운 작업(트랜잭션 실행)을 유저에게 넘기기 때문에 노드의 부하가 크게 줄어든다.
  • 블록체인 레벨에서는 검증만 하기 때문에 TPS가 크게 늘어난다.
• 프라이버시 확보
  • 유저는 트랜잭션 실행에 필요한 데이터를 오프체인에 두고, 네트워크에는 커밋(commitment)과 ZK 증명만 제출할 수 있다.
  • 어떤 데이터가 사용됐는지, 어떤 로직을 실행했는지 공개할 필요가 없다.

결과적으로 Miden은 기존 블록체인이 달성하지 못한 ‘확장성과 프라이버시의 동시 달성’을 가능하게 만든다. 블록체인이 갖고 있던 구조적 한계를, 실행 모델을 근본적으로 변경함으로써 해결한 것이다.

 

4. 그래서 이게 어떻게 가능한가?

Miden이 클라이언트 사이드 실행을 통해 프라이버시·확장성·상호운용성을 모두 확보할 수 있는 핵심 이유는, 기존 블록체인이 사용하던 “모든 노드가 모든 트랜잭션을 재실행하는 구조”를 버리고, 오프체인 실행 + 온체인 검증 + 최소한의 상태 커밋만 유지하는 새로운 상태 모델(State Model)을 도입했기 때문이다.

Miden은 이를 위해 Actor 모델을 기반으로, 네 가지 핵심 구성요소인 Account, Notes, Nullifier, Agglayer를 결합해 완전히 새로운 형태의 L2 설계를 만들어냈다.

Miden 아키텍쳐의 핵심인 Actor 모델은 병렬 및 분산 시스템의 확장을 위해 사용되어온 안정적인 모델이다. 이 모델에서 각각의 독립적인 주체인 “Actor”는 메세지 교환을 통해 서로 통신을 하며, 자체적으로 자신의 상태를 관리한다. 다만, 자신의 상태가 아니라 다른 Actor의 상태는 직접 변경할 수는 없으며, 오직 메시지 전달을 통해 간접적으로만 서로에게 영향을 줄 수 있다.

이를 통해 각각의 “Actor”가 독립적으로 활동하고 독립적으로 본인들의 상태를 관리하게 함으로써 굳이 이들의 트랜잭션 순서를 정하거나, 하나의 상태로 통합하여 관리할 필요성이 없어져 병렬적인 처리가 가능하게 된다.

Miden에서는 하나의 지갑 주소라고 할 수 있는 Account가 Actor의 역할을 한다. 각각의 Account는 자신의 독립적인 상태, 코드, 스토리지를 직접 관리하며, 자신의 상태에 대한 정보를 전혀 공유하지 않고 본인만 알 수 있다. 또한 Account 간 전달되는 메세지는 Miden에서 Notes라고 부르며, Notes들은 UXTO 기반으로 만들어진다.

4-1. Account와 Note의 구성 요소

Account와 Note는 다음과 같이 구성되어 있다.

Account는 ID, Nonce, MidenVM 코드, Storage, Asset으로 이루어진다

• ID: 계정을 구분하는 고유 식별자다. 각 Account는 고유한 ID를 가지며, 이 ID를 통해 계정 소유권 및 상태 변화가 추적된다.
• Nonce: 재사용 공격(replay attack)을 방지하기 위한 일련 번호다. 트랜잭션이 처리될 때마다 증가하며, 계정의 상태 전이가 올바르게 순서대로 진행되도록 강제한다.
• MidenVM code: 해당 Account에 연결된 실행 코드로, MidenVM에서 동작한다. 계정의 권한, 검증 방식, 상태 변화 규칙 등 계정이 따라야 할 로직 전반을 정의한다.
• Storage: 계정이 유지하는 상태 데이터(storage)다. Key–Value 형태의 자료 구조로 구성되며, 컨트랙트의 영구 상태를 저장한다.
• Assets: 계정이 보유한 자산 목록이다. FT/NFT/커스텀 자산 등 다양한 형태의 자산을 저장할 수 있다.

Notes는 Script, Inputs, Serial Number, Assets 로 이루어진다.

• Script: Note가 소비될 때 검증해야 하는 실행 로직이다. Note를 누가 소비할 수 있는지, 어떤 조건을 만족해야 하는지를 정의한다.
• Inputs: Script가 실행될 때 전달되는 입력값들이다. 소비 조건 충족 여부 판단, 서명 검증, 도메인 로직 수행 등에 활용된다.
• Serial Number: Note가 소비될 때 해당 Note에서 파생되는 고유 값이다. 이 값으로 Note가 이미 사용됐는지 확인해 이중 소비를 방지한다.
• Assets: 이 Note가 실제로 보유하고 있는 자산 목록이다. Account에서 Note로 자산이 이동하고, Note가 소비되면 다시 계정 자산으로 반영된다.

4-2. Miden에서의 트랜잭션 흐름

실제로 유저가 트랜잭션을 보내는 흐름을 다른 곳들과 비교해서 보자면 다음과 같다

1. L1: 유저가 트랜잭션을 직접 이더리움에 전송
2. L2: 유저가 L2에 트랜잭션을 전송하고, L2는 해당 트랜잭션을 모아 ZK 증명 생성, 전달함
3. Miden: 유저가 트랜잭션을 직접 실행&ZK 증명을 생성해서 L2에 전송, L2는 해당 트랜잭션을 모아 ZK 증명 재생성

L1에서는 유저 트랜잭션이 그대로 공개되기 때문에 프라이버시가 전혀 보장되지 않으며, 모든 트랜잭션이 Raw 데이터로 처리되기 때문에 확장성에도 근본적 한계가 있다. 기존 L2는 트랜잭션을 압축해 ZK 증명만 L1에 전달하므로 L1에 대해서는 프라이버시가 확보되지만, L2 시퀀서가 유저 트랜잭션을 직접 실행·검증한다는 점에서 시퀀서에게는 모든 정보가 그대로 노출된다는 한계가 있다.

반면 Miden에서는 유저가 로컬에서 트랜잭션을 실행하고 ZK 증명을 만들어 제출하기 때문에, L2의 운영자조차 유저의 실제 트랜잭션 내용을 볼 수 없다. 네트워크는 증명만 검증하면 되므로 확장성 역시 크게 향상된다.

Miden 내에서 트랜잭션이 보내지는 흐름을 조금 더 구체적으로 보자면 다음과 같다

1. 유저 A가 자신이 보유한 100 ETH 중 10 ETH를 유저 B에게 전송하고자 한다.

2. 유저 A는 유저 B에게 10 ETH를 보내는 Note를 생성하고, 이를 포함한 트랜잭션을 로컬에서 실행한다. 실행 과정에서 A는 자신의 계정 상태를 업데이트하고, 해당 트랜잭션에 대한 ZK 증명을 생성한다.

3. 유저 B는 A가 생성한 Note를 소비(consumption)하는 트랜잭션을 로컬에서 실행해 10 ETH를 수령한다. 이때 역시 B는 자신의 계정 상태를 로컬에서 업데이트하고, 이에 대한 ZK 증명을 만든다.

A와 B가 생성한 모든 트랜잭션은 각각의 ZK 증명과 함께 Miden 네트워크로 전송된다. 네트워크의 노드들은 트랜잭션 내용이나 Note의 구체적 정보(전송 금액, 상대 주소)를 전혀 알지 못한 상태에서, 증명만 검증해 해당 트랜잭션이 올바르게 실행되었는지 판단할 수 있다. 이로 인해 트랜잭션의 실제 내용은 오직 당사자인 A와 B만 알 수 있다. 이 구조가 바로 Miden의 핵심인 클라이언트 측 실행이다.

출처: https://github.com/0xMiden/miden-vm, 싱글코어 기준 실행/증명 생성 시간

트랜잭션 실행과 ZK 증명 생성은 모두 유저의 로컬 하드웨어(CPU/GPU)를 사용해 처리된다. 일반적인 PC 환경인 싱글 코어 기준으로 실행 자체는 1초 미만으로 매우 빠르게 완료되며, 뒤이어 이루어지는 증명 생성은 평균 약 3초 정도가 소요된다. 트랜잭션이 복잡해질수록 연산량이 증가해 증명 생성 시간도 함께 늘어난다.

Miden은 모바일 환경에서도 원활하게 트랜잭션을 생성할 수 있도록 최적화를 지속하고 있다. 현재 모바일에서는 증명 생성에 약 20초가 걸리지만, 메인넷 시점까지 이를 약 5초 수준으로 단축하는 것을 목표로 하고 있다.

또한 사용자 경험을 개선하기 위해 증명 생성 작업을 외부 서버로 위임할 수 있는 Delegated Proving 옵션을 제공하며, 이 방식을 사용할 경우 전체 지연 시간은 1초 미만으로 줄어든다. 이때 사용자는 해당 위임 서버에 대해서만 일부 프라이버시를 포기하게 되며, 네트워크 전체나 다른 사용자에 대해서는 프라이버시가 그대로 유지된다.

4-3. Agglayer 통합을 통한 상호운용성

Miden은 Polygon의 Agglayer 위에서 동작한다. Agglayer는 여러 L2와 앱체인이 생성한 ZK 증명을 하나의 네트워크에서 집계해 연결해주는 레이어로, 서로 다른 체인들이 마치 한 체인처럼 자연스럽게 상호작용할 수 있도록 만든다.

Miden이 Agglayer 위에서 출시된다는 것은, 프라이버시 L2임에도 불구하고 Ethereum과 다른 L2 생태계로 직접 연결되는 통로를 기본적으로 확보한다는 의미다. 이를 통해 기존 프라이버시 체인들이 공통적으로 겪어온 “유동성 고립” 문제를 피해 갈 수 있으며, Agglayer로부터 초기 유동성을 쉽게 흡수할 수 있어 유동성 파편화 문제도 크게 줄어든다.

또한 Miden 트랜잭션은 로컬에서 실행되고 온체인에는 ZK 증명과 커밋먼트만 올라가기 때문에, Agglayer는 이 커밋이 다른 체인의 상태 전이와 충돌 없이 결합될 수 있도록 전역 상태 일관성을 제공한다. 이 구조에서 Miden은 프라이버시·확장성을 담당하고, Agglayer는 상호운용성과 유동성 연결을 담당하는 식으로 역할이 분리된다.

출처: Agglayer X

현재 Agglayer와 연결되었거나 연결 예정인 체인은 총 18개로, Polygon PoS, Katana, X Layer, IoTeX 등이 이미 포함되며, Sentient·LitecoinVM 등도 조만간 통합될 예정이다.

이 덕분에 Miden은 일반적인 프라이버시 체인처럼 생태계 바깥으로 고립되지 않는다. 프라이버시가 필요한 로직은 Miden에서 실행하고, 공개가 필요한 활동은 다른 L2에서 수행하는 식의 크로스체인 워크플로우가 자연스럽게 가능하기 때문이다. 즉, Miden은 “닫힌 프라이버시 체인”이 아니라, Agglayer 생태계 전체와 연결된 프라이버시 실행 레이어(Privacy Execution Layer) 로 기능하며, 기존 프라이버시 체인들이 가진 폐쇄적인 한계를 뛰어넘을 수 있다.

4-4. Rust 기반의 개발 편리성

Miden은 EVM이 아닌 자체 VM인 MidenVM을 기반으로 하며, 이에 따라 개발 언어도 Solidity가 아닌 Rust를 채택한다. Miden이 기존 EVM 기반 실행 환경을 버리고 독자 VM을 선택한 이유는 크게 두 가지다.

첫째, EVM은 ZK 증명 생성에 근본적으로 비효율적이기 때문이다. EVM은 영지식 증명을 전제로 설계된 VM이 아니며, 연산 구조가 ZK와 잘 맞지 않는다. 이 때문에 EVM 트랜잭션을 ZK로 증명하려면 지나치게 많은 연산 리소스가 필요하고, 증명 생성 시간이 급격히 증가한다. 결과적으로 일반 사용자가 자신의 기기(PC·모바일)에서 트랜잭션을 실행하고 증명까지 생성하는 Miden의 핵심 처리 방식은 EVM 환경에서는 구현이 사실상 불가능하다. 반면 MidenVM은 처음부터 ZK기반 프루빙에 최적화되어 있어, 클라이언트 사이드 실행과 로컬 증명 생성이 자연스럽게 작동한다.

둘째, 제약 없는 개발 환경과 더 나은 개발자 경험을 제공하기 위해서다. Rust는 메모리 안전성, 강력한 타입 시스템, 높은 성능, 풍부한 라이브러리 생태계를 갖춘 언어로, 복잡한 애플리케이션과 ZK 로직을 구현하기에 매우 적합하다. MidenVM은 이러한 Rust의 특성과 구조적으로 잘 맞아 떨어져, 개발자가 보다 안전하고 예측 가능한 코드를 작성할 수 있도록 한다. Solidity/EVM 구조의 제약을 그대로 가져갈 필요가 없기 때문에 DevEx 측면에서도 더 높은 자유도를 제공한다.

물론 이러한 선택에는 명확한 대가도 따른다. 기존 EVM 기반 디앱을 그대로 가져오기 어려워 Miden 고유의 생태계를 만들어야 한다는 점이다. EVM 호환성을 포기함으로써 더 넓은 설계 자유도를 얻었지만, 그만큼 독자적인 애플리케이션 생태계를 구축하는 것이 초기 단계의 핵심 마일스톤이 된다. Miden은 단기적 확산을 위한 EVM 호환성보다, 장기적으로 ZK 기술의 잠재력을 최대한 활용해 새로운 설계 공간을 열어가는 전략을 선택한 것이다.

 

5. Miden에서는 무엇이 가능해지는가? (Use Case)

Miden의 클라이언트 사이드 실행과 Note 기반 Actor 모델은 기존 블록체인 구조로는 구현하기 어려웠던 새로운 형태의 온체인 애플리케이션을 가능하게 만든다. 특히 프라이버시·확장성·조작 불가능성·MEV 회피가 동시에 요구되는 금융 애플리케이션에서 강점을 보인다. 아래에서는 Miden의 구조가 어떤 유형의 애플리케이션을 근본적으로 개선하는지를 살펴본다.

5-1. Private Payment: 프라이버시가 내재된 기본 결제

1 대 1 결제

Miden의 1대1 결제는 사용자가 자신의 Account 상태를 로컬에서 직접 업데이트하고, 그 실행 결과에 대한 ZK 증명만 네트워크로 제출하는 방식으로 수행된다. 이 과정에서 잔액 차감, 수신자 확인, Note 생성 같은 로직은 모두 계정 코드에 따라 로컬에서 처리되며, 온체인에는 해당 실행이 올바르게 수행되었다는 증명과 커밋먼트만 기록된다. 이 구조 덕분에 누가 누구에게 얼마를 보냈는지, 계정 잔고가 얼마인지 같은 민감한 정보가 체인에 드러나지 않는다. 또한 각 계정은 병렬적으로 실행되기 때문에 많은 사용자가 동시에 결제를 수행해도 지연이 거의 없고, 계정 추상화 덕분에 가스비 처리나 키 관리는 애플리케이션 레벨에서 숨길 수 있어 Web2 수준의 결제 UX를 구현할 수 있다.

예를 들어 A가 친구 B에게 1 ETH를 보내고 싶다고 해보자. A는 자신의 로컬 환경에서 “내 지갑에서 1 ETH를 빼서 B에게 전달한다”는 실행을 돌리고, 그 결과로 B만 열어볼 수 있는 일종의 디지털 봉투(Note) 를 만든다. A는 이 봉투를 B에게 전송하고, B는 자신의 로컬 환경에서 봉투를 열어 0 ETH → 1 ETH로 잔액을 업데이트한다. 온체인에는 단지 “A가 만든 봉투가 유효했고, B가 올바르게 받았다”는 증명만 기록될 뿐, 누가 누구에게 얼마를 보냈는지 같은 실제 내용은 드러나지 않는다. 그 결과 A와 B는 서로의 거래 내역이나 잔고를 공개하지 않으면서도, 마치 송금 앱을 쓰듯 빠르고 안전하게 자산을 주고받을 수 있다. 특히 이 과정은 각 계정이 서로 간섭 없이 독립적으로 병렬 실행되기 때문에, 같은 시각에 여러 사용자가 서로에게 송금을 보내더라도 네트워크 전체가 이를 일일이 처리하느라 막히지 않는다.

1 대 N 결제

1대N 결제는 한 번의 실행으로 여러 사람에게 보낼 디지털 봉투(Note)를 한꺼번에 만드는 방식이다. 송신자는 로컬에서 “내 잔액을 N명에게 각각 얼마씩 나눠 보낸다”는 로직을 실행하고, 그 결과로 각 수신자에게 대응하는 여러 개의 Note가 만들어진다. 이후 송신자는 이 실행이 올바르게 처리되었다는 단일 ZK 증명만 네트워크에 제출하면 된다. 이때 프라이버시는 특히 중요하다. 기업 급여 지급이나 리워드 배포처럼 다수에게 동시에 자금을 보내는 상황에서는 개별 금액이나 대상이 외부에 공개되면 민감한 정보가 그대로 노출될 수 있기 때문이다. Miden에서는 실제 지급 내역을 전혀 드러내지 않은 채 대량 전송을 처리할 수 있어, 개인·기업 모두 더 안전하게 결제를 관리할 수 있다.

예를 들어 한 회사가 1,000명의 직원들에게 급여를 지급한다고 하자. 기존 퍼블릭 체인에서는 1,000개의 트랜잭션을 각각 올려야 하고, 그 과정에서 각 사람의 급여 금액과 지갑 주소가 모두 외부에 공개된다. 이는 기업의 내부 정보가 노출될 뿐 아니라, 개인에게도 민감한 재무 정보가 그대로 드러나는 문제가 된다.

Miden에서는 회사의 Account가 로컬에서 한 번의 실행으로 1,000개의 급여용 Note를 생성하고, 온체인에는 “총 지급액이 빠졌고 모든 Note가 규칙대로 만들어졌다”는 단일 ZK 증명과 커밋먼트만 남는다. 직원들은 전달받은 Note를 로컬에서 소비해 잔고만 업데이트하면 되고, 회사가 감사나 규제 보고가 필요할 때는 개별 직원의 정보 없이도 전체 급여 지급이 올바르게 이뤄졌다는 ZK 증명만 선택적으로 제공할 수 있다.

5-2. Private Defi: 프라이버시가 보장되는 온체인 거래소

프라이빗 오더북 덱스

Miden에서는 주문을 하나의 Note로 표현한다. 사용자는 로컬에서 “내가 어떤 가격에 얼마나 사고팔겠다”는 조건을 담은 Note를 만들고, 이를 오더북에 올린다. 이때 기본적으로 오더북에 올라가는 Note는 공개(Public)되는 것이 원칙이다. 다만, 주문을 공개하고 싶지 않은 경우에는 주문을 대신 전달해주는 Obfuscation 계층을 활용할 수 있다. Obfuscation는 사용자의 주문 Note를 직접 노출시키지 않고 중간 레이어가 주문을 대리 제출하는 방식으로, 사용자의 지갑 주소나 주문 세부 내용을 완전히 감춘 채 오더북 업데이트를 가능하게 만든다. 이를 통해 가격·수량·전략적 주문 조건을 외부에 드러내지 않고 프라이빗하게 거래할 수 있다.

예를 들어, 트레이더 A가 “1 ETH를 3,000 USDC에 팔겠다”는 지정가 주문을 넣는다고 해보자. A는 이 조건을 담은 Note를 로컬에서 만들고 오더북에 올린다. 반대로 트레이더 B가 이 주문을 체결하고 싶다면 자신의 로컬 환경에서 “이 Note를 소비한다”는 실행을 돌리고, 그에 대한 증명만 올리면 체결이 완료된다. 이러한 구조 덕분에 주문 업데이트는 빠르고 저렴하며, 필요할 경우 Obfuscation 계층을 이용해 주문 자체를 프라이빗하게 유지한 채 온체인 거래를 수행할 수 있다.

프라이빗 선물 시장

Miden에서는 각 Perpetual Market을 하나의 Account로 구현하고, 참여자는 Note를 통해 증거금을 예치하거나 포지션을 열고 닫는다. 포지션 변경, 펀딩비 정산, 청산 규칙은 Account 코드에 정의되며, 사용자는 자신의 로컬에서 실행을 돌려 포지션 상태를 업데이트한다. 네트워크는 포지션 규모, 레버리지, 청산 위험 같은 정보를 보지 않고, 단지 “Perp Account가 코드에 정의된 규칙을 정확히 따른 상태 전이인가”만 검증한다. 특히 많은 사용자가 동시에 포지션을 조정하는 상황에서도, 운영자는 이를 단일 로컬 트랜잭션으로 묶어 실행하고 단 하나의 증명만 제출하면 되어 확장성이 매우 높다. Market Account를 프라이빗으로 설정하면 네트워크에는 전체 상태의 커밋먼트만 남고, 참여자별 포지션 구조는 외부에 공개되지 않는다.

예를 들어, BTC Perp 시장에서 A는 BTC 상승을 예상해 1,000 USDC를 증거금으로 예치하고 롱 포지션을 연다. 동시에 B는 하락을 예상해 1,000 USDC를 넣고 숏 포지션을 연다. 두 사용자는 자신의 로컬 환경에서 포지션 실행을 돌려 Note를 만들고, Perp Account는 이 Note들을 소비해 포지션 상태를 업데이트한다. 이후 가격이 움직여 펀딩비를 서로 주고받아야 할 때도 운영자는 수백 명의 포지션 변경·펀딩 정산을 한 번에 로컬에서 처리하고 단일 증명만 제출한다. 이 과정에서 외부는 “해당 Perp Market의 포지션들이 규칙에 따라 업데이트되었다”는 사실만 보며, 각 사용자가 어떤 포지션을 얼마나 들고 있는지는 알 수 없다.

5-3. Private Multisig Treasury

Miden에서 Treasury는 단순한 지갑이 아니라 조직의 자산 운용 규칙을 직접 코드로 내재한 프라이빗 스마트 계정으로 구현된다. Treasury Account에는 “두 명 이상이 승인해야 고액 지출이 가능하다”, “특정 자산은 30일 이전에 인출할 수 없다”, “월간 예산 한도를 초과한 지출은 자동으로 거부한다”와 같은 정책이 Miden VM 코드로 정의되어 있으며, 이 계정에서 발생하는 모든 지출은 이러한 정책을 통과해야만 Note를 만들거나 소비할 수 있다. 사용자는 자신의 로컬 환경에서 Treasury 코드를 실행해 지출 트랜잭션을 구성하고, 해당 실행이 규칙을 정확히 따랐다는 ZK 증명을 만든 뒤 네트워크에 제출한다.

하지만 계정 상태가 모두 비공개인 Miden에서는, 멀티시그를 구성하는 여러 서명자가 서로의 최신 상태를 직접 볼 수 없기 때문에 “지금 어떤 제안이 올라와 있는지”, “누가 이미 서명했는지”, “내가 보고 있는 상태가 최신이 맞는지”를 알기 어렵다. 이를 해결하기 위해 개발 중인 PSM(Private State Management) 은 서명자들끼리 필요한 상태와 트랜잭션 정보를 오프체인에서 안전하게 동기화해 주는 계층이다. PSM을 활용하면 서명자들은 서로의 중요한 정보를 외부에 노출하지 않고도 동일한 상태를 공유하면서 멀티시그 승인 절차를 정상적으로 진행할 수 있다.

예를 들어 한 기업이 Miden 위에 Treasury를 만들고 ‘2-of-3 멀티시그’와 ‘일일 지출 한도 50,000 USDC’ 규칙을 설정했다고 하자. 운영비 20,000 USDC를 지급해야 한다면, 먼저 세 명의 서명자는 PSM을 통해 모두 같은 최신 상태를 보고 있다는 것을 확인한다. 이후 한 명의 제안자가 지출 요청을 올리면, 두 명의 서명자가 각자 로컬에서 이를 검토하고 승인 서명을 남긴다. 서명 두 개가 모이면 PSM은 그 과정이 정책을 정확히 따랐다는 ZK 증명을 네트워크에 제출한다. 네트워크에는 “2명이 승인했고, 지출 한도를 넘지 않았다”는 사실만 남고, 실제 지급 내역은 공개되지 않는다.

이 대표적인 케이스 3가지 외에도 신원증명, 투표 등 다양한 활용사례들이 나타날 수 있으며, 블록체인의 특성상 누구나 Miden 위에서 혁신적인 디앱들을 구현할 수 있다.

 

6. 마무리: ZK 네이티브 체인은 새로운 표준이 될 수 있을까

Miden은 프라이버시·확장성·스마트 컨트랙트를 결합해 새로운 실행 환경을 제시하지만, 해결해야 할 과제들도 분명 존재한다. 그 중에서도 가장 큰 이슈는 규제다. 완전한 익명성을 제공하는 네트워크는 제도권과의 충돌 가능성이 높고, 초기 운영·채택 측면에서도 부담이 크다. 최근 Tornado Cash의 블랙리스트 조치가 일부 완화되는 등 프라이버시 규제의 해석이 점진적으로 변화하고 있지만, 여전히 명확한 기준이 부재한 상황에서 신생 네트워크가 곧바로 “완전한 프라이버시 체인”로 출발하는 것은 상당한 리스크를 동반한다.

사용자 경험 측면에서도 도전 과제는 존재한다. 모든 실행과 증명 생성을 로컬에서 처리해야 하는 Miden의 구조상, 모바일 환경에서는 비교적 큰 지연이 발생할 수 있다. Miden은 현재 약 20초 수준인 증명 생성 시간을 메인넷 시점까지 5초로 줄이고, 필요 시 외부 서버에 증명 생성을 위임하는 delegated proving 옵션을 제공해 UX 부담을 완화할 계획이다.

이러한 현실적 제약을 고려해 Miden은 처음부터 완전한 프라이버시 모델을 도입하기보다, 운영자가 트랜잭션 내용을 확인할 수 있는 Web2에 가까운 ‘1단계(Phase 1)’로 출발한다. 이는 규제 리스크를 최소화하고 초기 생태계를 안정적으로 구축하기 위한 전략적 선택이다. 따라서 Miden은 1단계에서 보안·규제·UX 기반을 다진 뒤, 이후 점진적으로 완전 프라이버시 환경에 가까운 3단계로 확장해나가고자 한다.

현재 블록체인 시장은 PoW·PoS 기반 L1들이 과도하게 난립하고, L2 또한 뚜렷한 차별점 없이 확장되는 등 경쟁이 심화되고 있다. 이런 환경에서 새로운 체인이 주목받기 위해서는 풍부한 생태계나 강한 커뮤니티, 혹은 명확한 기술적 특장점이 필수적이다. Miden은 EVM과 호환되지 않기 때문에 초기 생태계 구축에 어려움이 있을 수 있지만, ZK-native 실행 환경과 클라이언트 측 실행이라는 근본적인 기술 혁신을 통해 기존 체인들과는 다른 경쟁력을 제시한다. Miden이 앞서 언급한 한계들을 안정적으로 극복해 간다면, 과거 EVM 체인들이 하나의 표준으로 자리 잡았듯이, Miden 역시 프라이버시와 로컬 실행을 기반으로 한 새로운 표준을 만들어갈 잠재력이 충분하다.