목차

1. 기관급 BTCFi 전략과 STRK20의 필요성

2. STRK20은 무엇이 달라지는가 (Account Model vs STRK20 Model)

3. STRK20의 구조와 동작 방식

4. Starknet BTCFi Roadmap

5. 마무리: 기관 채택을 위한 과제

1. 기관급 BTCFi 전략과 STRK20의 필요성

비트코인의 활용 방식은 개인 중심의 ‘보유와 전송’에서 점차 벗어나, 기관 중심의 운용 자산(BTCFi)으로 전환되고 있다. 최근 몇 년간 기관 보유 비트코인은 빠르게 증가하며 비중이 확대되고 있으며, 이는 향후 BTCFi의 확산이 개인보다 기관 자본을 중심으로 전개될 가능성을 시사한다. 이러한 흐름과 구조적 변화는 기존 리서치 ‘BTCFi: 개인에서 기관으로, 기관에서 Starknet으로’에서 자세히 다룬 바 있다.

다만 기관이 온체인에서 직접 자산을 운용하기 시작하는 순간, 블록체인의 완전한 투명성은 더 이상 장점이 아니라 리스크로 작용한다. 포지션 규모, 거래 시점, 자산 이동 흐름이 그대로 노출되며, 이는 프론트러닝이나 청산 유도와 같은 공격으로 이어질 수 있다. 온체인 분석 인프라의 발전으로 이러한 문제는 더욱 심화되고 있으며, 기관 입장에서는 전략 노출을 방지할 수 있는 환경이 필수적이다.

결국 기관이 요구하는 것은 단순한 익명성이 아니라, 전략적 운용을 보호할 수 있는 수준의 프라이버시다. 이를 위해서는 추적 방지, 충분한 유동성, 필수 금융 서비스, 규제 적합성이라는 네 가지 조건이 동시에 충족되어야 한다. 그러나 기존 프라이버시 체인들은 이 중 일부 조건에서는 강점을 보이지만, 네 가지를 모두 만족시키지는 못한다.

Solana와 Sui는 충분한 유동성과 금융 기능을 갖추고 있지만, 거래 흐름과 활동 패턴을 구조적으로 숨기지 못한다는 한계를 가진다. Aztec는 프라이버시와 스마트컨트랙트를 결합한 구조를 지향하고 있으나, 아직 유동성과 생태계 측면에서는 초기 단계에 머물러 있다. 반면 Zcash와 Monero는 강력한 프라이버시를 제공하지만 스마트컨트랙트 기반 금융 인프라가 부족하다는 제약이 존재한다. 이러한 비교는 기존 리서치 ‘BTCFi의 마지막 퍼즐, Starknet의 프라이버시’에서 보다 상세히 다루었다.

https://x.com/Starknet/status/2031339399015804954

이러한 맥락에서 Starknet은 기존 퍼블릭 DeFi 유동성과 실행 환경을 유지하면서도 프라이버시를 통합하는 방향을 취하고 있으며, 2026년 3월, 이를 구체화한 구조인 STRK20을 공식 발표했다. STRK20은 새로운 토큰을 발행하는 구조가 아니라, 기존 자산에 프라이버시 기능을 추가하는 프라이버시 자산 구조다. 이를 통해 동일한 자산을 공개 상태와 비공개 상태로 선택적으로 활용할 수 있으며, 이는 기관 중심 BTCFi 확장을 위한 기반을 제공한다.

2026년 2월 26일 발표된 strkBTC는 이러한 방향성을 구체화한 첫 사례다. strkBTC는 Starknet이 직접 설계한 비트코인 래핑 자산으로, Starknet 상에서 비트코인을 활용할 수 있도록 지원한다. 동시에 strkBTC는 필요에 따라 공개 상태와 비공개 상태를 선택할 수 있도록 설계되었다. 공개 상태에서는 일반 ERC-20 토큰처럼 잔고와 전송 내역이 온체인에 드러나지만, shielded mode, 즉 비공개 모드에서는 잔고와 거래 내역이 외부에 노출되지 않는다. 이는 Bitcoin을 단순 보유 자산이 아니라 DeFi 내 결제·담보·운용 자산으로 활용하면서도, 기관이 우려하는 포지션 노출과 거래 전략 유출 문제를 줄이려는 시도로 볼 수 있다.

본 글에서는 이러한 STRK20 구조를 중심으로, 기존 스타크넷의 토큰 모델 대비 어떤 변화가 발생하는지, 실제로 자산이 어떻게 관리되고 거래되는지, 그리고 이를 가능하게 하는 기술적 메커니즘이 무엇인지 단계적으로 살펴본다. 나아가 해당 구조가 기관 관점에서 어떤 의미를 가지는지와 향후 확장 가능성까지 함께 분석한다.

2. STRK20은 무엇이 달라지는가 (Account Model vs STRK20 Model)

STRK20은 프라이버시 기능을 도입하기 위해 기존 ERC-20 기반 구조에서 발생하던 한계를 보완하려는 접근이다. 이를 이해하기 위해서는 먼저 ERC-20 기반의 토큰 구조가 어떤 제약을 가지고 있는지, 그리고 STRK20이 이를 어떻게 개선하는지 살펴볼 필요가 있다.

2-1. 기존 토큰 구조의 한계

현재 스타크넷을 포함한 대부분의 블록체인은 ERC-20 표준을 기반으로 한 Account 모델 위에서 동작한다. 이 구조에서는 각 주소(address)가 명시적인 잔고(balance)를 가지며, 모든 거래는 이 잔고의 변화를 기준으로 기록된다. 즉, 자산의 보유 상태와 이동 내역이 온체인에 그대로 반영되는 구조다.

예를 들어, 특정 주소 A가 주소 B로 100 토큰을 전송하는 경우, 해당 거래는 발신자, 수신자, 전송 금액, 시점과 함께 온체인에 기록된다. 이러한 정보는 누구나 조회 가능하며, 개별 거래뿐 아니라 주소 간 관계 역시 자연스럽게 드러난다. 실제로 이처럼 투명한 블록체인 환경에서는 특정 주소를 기준으로 자금 흐름을 추적함으로써, 다음과 같은 정보까지 도출하는 것이 가능하다.

• 포지션 진입 및 청산 시점
• 자산 간 이동 경로
• 사용된 디앱의 종류
• 반복적으로 거래되는 상대 주소

즉, 기존 구조의 블록체인은 보유 자산 뿐 아니라 거래 패턴과 전략까지 포함한 활동 전반이 노출되는 특성을 가진다.

이러한 투명성은 블록체인의 신뢰성을 강화하는 요소로 작용하지만, 동시에 기관 투자자에게는 구조적인 제약이 된다. 대규모 자금을 운용하는 과정에서 거래 전략이나 포지션이 외부에 노출될 경우, 시장 영향 비용이 증가하거나 정보 비대칭으로 인한 불리한 결과를 초래할 수 있기 때문이다. 결과적으로 ERC-20 기반의 Account 모델은 기관의 온체인 참여를 제한하는 주요 요인으로 작용해왔다.

2-2. STRK20의 핵심 개념

Starknet의 프라이버시 구조에서는 자산이 ‘계정의 잔고’가 아니라, 암호화된 Note 형태로 표현된다. 이 Note에는 소유자, 자산의 종류, 수량 등의 정보가 포함되지만, 온체인에는 이 정보가 그대로 노출되지 않고 암호화된 형태로 저장된다.

트랜잭션 역시 동일한 방식으로 처리된다. 기존에는 “누가 누구에게 얼마를 보냈는지”가 그대로 블록체인에 기록되었다면, STRK20에서는 소유자, 자산의 종류, 수량 등 거래의 세부 내용이 공개되지 않는다. 대신, 거래의 세부 정보는 암호화된 Note 안에 저장되며, 외부에서는 그 내용을 직접 확인할 수 없다. 네트워크는 zk-proof를 통해 해당 Note가 유효한지만 검증하며, 입력과 출력의 합이 일치하는지, 이중 지출(double-spend)이 없는지 등을 확인한다.

이를 통해 STRK20은 “구체적인 트랜잭션의 내용을 볼 수는 없지만, 그 유효성은 누구나 검증할 수 있는 자산” 이라는 새로운 형태의 토큰 모델을 제시한다.

2-3. 사용자(기관) 관점에서의 변화

이러한 변화는 사용자, 특히 기관 관점에서 보다 명확한 구조적 차이로 나타난다.

우선, 보유한 자산의 규모가 드러나지 않는다. 기존 블록체인에서는 특정 주소의 자산 규모가 그대로 노출되기 때문에, 대규모 자금을 운용하는 기관 입장에서는 포지션 규모나 리스크 노출이 외부에 드러나는 문제가 존재했다. STRK20에서는 자산이 암호화된 Note 형태로 관리되며, 외부에서는 특정 주소의 자산 규모를 확인할 수 없다. 이를 통해 기관의 포지션과 리스크가 외부에 드러나는 문제를 줄일 수 있다.

둘째, 거래 내용이 드러나지 않는다. 기존에는 “누가, 누구에게, 얼마를 보냈는지”뿐 아니라 어떤 프로토콜을 어떻게 활용했는지까지 온체인에서 추적이 가능했다. 이로 인해 거래 흐름이 누적될수록 투자 전략, 포지션 이동, 리밸런싱 시점까지 외부에 노출되는 문제가 발생했다. STRK20에서는 거래의 세부 정보 대신 해당 거래가 유효한지 여부만 zk-proof로 검증된다. 입력과 출력의 합이 일치하는지, 이중 지출이 없는지와 같은 조건만 검증되며 실제 거래 내용은 공개되지 않는다. 결과적으로 거래의 내용이 아닌 거래의 정당성만 확인되는 구조다.

셋째, 기관의 온체인 활용 범위를 확대한다. 기존에는 투명성으로 인해 자산 규모와 거래 전략이 외부에 드러날 수 있었기 때문에 온체인 활용이 제한적이었다. 특히 DeFi 환경에서는 거래 흐름과 포지션 변화가 그대로 노출되면서 경쟁 환경에서 불리하게 작용했다. 이로 인해 기관들은 온체인에 직접 참여하기보다는 ETF와 같은 상품을 활용하거나, 커스터디 및 중개 기관을 통해 간접적이고 제한적으로 접근해왔다. STRK20에서는 잔고와 거래 정보가 비공개로 유지되며 이러한 제약이 완화된다. 이에 따라 기관이 중개 없이도 전략 노출 없이 온체인에서 자산을 운용할 수 있는 환경이 형성된다. 이는 온체인을 실제 자산 운용이 가능한 금융 인프라로 활용할 수 있게 만든다.

3. STRK20의 구조와 동작 방식

STRK20이 활용하는 Note-nullifier 기반 프라이버시 모델은 2014년 Zerocash 논문에서 본격적으로 정립된 구조다. Zerocash는 자산을 계정의 공개 잔고가 아니라 소유자, 값, nonce를 포함한 개별 Note로 표현하고, 사용된 Note는 nullifier로 표시해 이중 지출을 방지하면서도 거래 간 연결성을 숨기는 방식을 제시했다. 특히 이 연구에는 StarkWare 공동창업자 Eli Ben-Sasson이 공동저자로 참여했으며, 이는 StarkWare가 zk-rollup 확장성뿐 아니라 영지식증명 기반 프라이버시 설계의 핵심 기술 계보와도 깊게 연결되어 있음을 보여준다.

STRK20 역시 이러한 Note-nullifier 기반 구조를 기본 틀로 활용한다. 다만 기존 Zcash 계열 설계는 단순 전송 프라이버시에는 효과적이었지만, 온체인 금융 환경으로 확장되는 과정에서는 여러 한계를 드러냈다. 예를 들어 사용자가 자신의 자산을 찾기 위해 많은 데이터를 직접 스캔해야 하거나, 프라이버시를 유지한 채 기존 DeFi 유동성과 연결되기 어렵거나, 기관이 요구하는 감사와 규제 대응 기능을 충분히 제공하지 못하는 문제가 있었다. STRK20은 Starknet의 실행 환경 위에서 이러한 한계를 보완해, 프라이버시를 단순 전송 기능이 아니라 DeFi와 기관 활용까지 확장 가능한 자산 구조로 구현하려는 시도다.

이에 따라 3-1절부터 3-3절까지는 STRK20의 기본 동작 원리를 먼저 살펴본다. 자산이 어떤 형태로 표현되는지, 온체인에는 어떤 데이터가 저장되는지, 트랜잭션은 어떻게 생성되고 검증되는지를 중심으로 구조를 정리한다. 이후 3-4절에서는 STRK20이 기존 프라이버시 프로젝트들과 구분되는 지점을 다룬다. 특히 자산 탐색, 감사 가능성, DeFi 연동과 같은 실제 사용 단계의 문제를 어떤 방식으로 해결하려 하는지 살펴본다.

3-1. 핵심 구조: 상태 비공개 + 증명 기반 검증

STRK20의 핵심은 온체인이 모든 정보를 직접 알고 있어야만 거래를 검증할 수 있다는 기존 전제를 바꾸는 데 있다. 기존 Account 모델에서는 모든 상태와 실행이 온체인에서 이루어진다. 특정 주소의 잔고와 거래 내역이 공개적으로 기록되며, 체인은 트랜잭션을 직접 실행하고 그 결과를 검증한 후 상태를 업데이트한다. 즉, “누가 누구에게 얼마를 보냈는지”가 그대로 드러나고, 체인은 이 정보를 기반으로 실행과 검증을 동시에 수행한다.

반면 STRK20에서는 이 구조가 근본적으로 바뀐다. 트랜잭션은 온체인에서 실행되는 것이 아니라, 먼저 오프체인에서 구성된다. 사용자는 자신이 보유한 Note를 소비하고 새로운 Note를 생성하는 방식으로 거래를 구성한다. 이후 해당 거래가 유효하다는 사실만 zk-proof 형태로 생성된다. 이 증명은 사용된 Note가 실제로 존재하는지, 해당 Note에 대한 권한을 보유하고 있는지, 이미 사용된 Note가 아닌지(nullifier 검증), 그리고 입력과 출력의 합이 일치하는지와 같은 조건들을 검증한다. 중요한 점은 이 과정에서 실제 금액이나 거래 상대방 정보는 공개되지 않는다는 것이다.

사용자는 이 zk-proof를 온체인에 제출하고, 체인은 이를 검증한다. 이때 체인은 트랜잭션을 재실행하지 않으며, 단지 proof의 유효성만 확인한다. 검증이 완료되면, 사용된 Note에 대한 nullifier가 기록되고 새로운 암호화된 Note가 추가되는 방식으로 상태가 업데이트된다.

결과적으로 STRK20은 기존의 “상태 공개 + 온체인 실행 + 온체인 검증” 구조에서, “상태 비공개 + 오프체인 실행 + 온체인 검증” 구조로 전환된 모델이다.

3-2. 자산 구조: Note 기반 모델

STRK20에서는 자산을 표현하는 기본 단위가 기존의 balance가 아니라 Note로 전환된다. 기존 Account 모델에서는 특정 주소의 잔고가 직접 기록되고, 거래가 발생할 때 해당 잔고 값이 증가하거나 감소한다. 반면 STRK20에서는 특정 주소가 얼마를 보유하고 있는지 직접 기록하지 않는다. 대신 자산을 여러 개의 암호화된 Note 단위로 표현하고, 거래가 발생할 때 기존 Note를 소비하고 새로운 Note를 생성하는 방식으로 상태가 변화한다.

1) Note의 구조

Note는 STRK20에서 개별 자산 단위를 나타내는 불변 객체다. 각 Note는 특정 자산에 대한 소유권을 표현하며, 기본적으로 다음과 같은 정보를 포함한다.

• Owner: 해당 Note에 대한 사용 권한이 있는 주소
• Token: 자산 종류, 즉 해당 자산의 토큰 주소
• Amount: 보유 수량

다만 이 정보들은 온체인에 그대로 공개되지 않는다. Note 안에는 소유자, 자산 종류, 수량과 같은 거래의 핵심 정보가 담겨 있지만, 온체인에는 암호화된 형태로 저장된다. 따라서 외부 관찰자는 특정 Note가 누구의 것인지, 어떤 자산을 담고 있는지, 얼마의 수량을 나타내는지 직접 확인할 수 없다.

2) Note의 소비와 생성

STRK20에서는 거래가 발생해도 기존 잔고 숫자를 수정하지 않는다. 대신 기존 Note를 소비하고, 그 결과로 새로운 Note를 만든다.

예를 들어 A가 100을 담고 있는 Note 하나를 가지고 있고, 이 중 60을 B에게 전송한다고 가정해보자. 기존 Account 모델이라면 A의 잔고가 100에서 40으로 줄고, B의 잔고가 60만큼 늘어난다. 하지만 STRK20에서는 기존 Note(100)가 일부만 수정되는 것이 아니라 완전히 소비된다. 그리고 그 결과로 B에게 귀속되는 60짜리 Note와, A에게 다시 돌아가는 40짜리 Note가 새로 생성된다.

즉, STRK20의 자산 이동은 “잔고를 수정하는 방식”이 아니라 “기존 자산 단위를 소모하고 새로운 자산 단위로 교체하는 방식”에 가깝다. 이는 Bitcoin의 UTXO 모델과 유사하다. 다만 STRK20에서는 각 Note의 소유자와 금액이 암호화되어 있고, 거래의 유효성만 zk-proof로 증명된다는 점에서 일반적인 UTXO 모델과 다르다.

3) Nullifier의 역할

Note 기반 구조에서는 한 가지 문제가 생긴다. 이미 사용한 Note를 다시 사용하지 못하게 막아야 한다는 점이다. 이때 사용되는 장치가 nullifier다.

nullifier는 특정 Note가 이미 소비되었는지를 표시하는 값이다. 사용자가 Note를 소비하면, 해당 Note에 대응되는 nullifier가 온체인에 기록된다. 이후 같은 Note를 다시 사용하려고 하면 동일한 nullifier가 다시 등장하게 되고, 체인은 이를 이미 사용된 Note로 판단해 거래를 거부한다.

중요한 점은 nullifier가 이중 지출을 막기 위한 표시값일 뿐, 원래 Note의 내용을 그대로 드러내지는 않는다는 것이다. 외부 관찰자는 어떤 nullifier가 기록되었다는 사실은 볼 수 있지만, 그 nullifier가 어떤 소유자의 Note에서 나왔는지, 어떤 자산과 금액을 의미하는지, 어떤 거래와 연결되는지는 알 수 없다.

따라서 nullifier는 두 가지 역할을 동시에 수행한다. 하나는 같은 Note가 두 번 사용되는 것을 방지하는 것이고, 다른 하나는 그 과정에서도 Note와 거래 간의 연결성을 노출하지 않는 것이다.

4) Privacy Pool에 저장되는 정보

STRK20의 온체인 상태는 Privacy Pool 컨트랙트를 중심으로 관리된다. 일반적인 블록체인에서는 주소별 잔고가 상태로 저장된다. 예를 들어 A 주소가 100개를 가지고 있고, B 주소가 50개를 가지고 있다는 식이다. 그래서 누구나 특정 주소를 조회하면 해당 주소의 자산 규모와 거래 흐름을 확인할 수 있다.

반면 STRK20의 Privacy Pool은 “누가 얼마를 가지고 있는지”를 직접 저장하지 않는다. 대신 크게 두 가지 정보를 관리한다.

• Encrypted Note Set: 현재 존재하는 암호화된 Note들의 목록이다. 각 Note에는 소유자, 자산 종류, 수량이 포함되어 있지만, 외부에서는 그 내용을 확인할 수 없다.
• Nullifier Set: 이미 소비된 Note에 대응되는 nullifier들의 목록이다. 체인은 이 목록을 통해 같은 Note가 다시 사용되는 것을 방지한다.

결국 STRK20에서 체인이 확인하는 것은 주소별 잔고가 아니다. 체인은 새로운 암호화 Note가 생성되었는지, 소비된 Note의 nullifier가 이미 사용된 적 없는지, 그리고 제출된 zk-proof가 올바른지만 검증한다. 이를 통해 자산의 소유자와 금액은 외부에 공개되지 않지만, 이중 지출 없이 유효한 거래만 처리될 수 있다.

3-3. 트랜잭션 흐름: 구체적인 예시

STRK20에서 트랜잭션은 기존처럼 온체인에서 실행되는 것이 아니라, 먼저 오프체인에서 구성되고 이후 온체인에서 검증되는 방식으로 처리된다. 이 과정은 크게 다섯 단계로 나눌 수 있다.

1) 예치 (Deposit)

사용자는 먼저 공개 상태의 토큰(예: ERC-20)을 Privacy Pool에 예치한다. 이 과정에서 해당 자산을 나타내는 암호화된 Note가 생성되어 Privacy Pool 내부에 저장된다. 즉, 공개된 balance 형태의 자산이 비공개 Note 형태로 전환되는 단계다.

2) 프라이빗 전송 (Private Transfer)

사용자는 자신이 보유한 Note를 선택하고, 이를 소비하는 동시에 새로운 Note를 생성한다. 예를 들어 하나의 Note를 사용해 자산을 전송하면, 해당 Note는 더 이상 사용할 수 없으며, 수신자를 위한 새로운 Note와 남은 자산에 해당하는 Note가 생성된다. 이 과정에서 해당 Note의 재사용을 방지하기 위해 nullifier가 함께 생성되며, 이를 통해 해당 Note가 이미 사용되었음을 온체인에 기록한다.

3) zk-proof 생성 (Off-chain)

앞선 단계에서 생성된 Note의 소비 및 생성 결과를 바탕으로, 해당 상태 변화가 올바르게 이루어졌다는 사실을 zk-proof로 생성한다. 이 proof는 트랜잭션의 세부 내용을 공개하지 않으면서도, 다음과 같은 조건들이 충족됨을 증명한다.

• 사용된 Note가 실제로 존재하는지
• 사용자가 해당 Note를 사용할 권한을 보유하고 있는지
• nullifier가 올바르게 계산되었는지 (이중 지출 방지)
• 입력과 출력 값의 합이 일치하는지

4) 트랜잭션 제출 (Paymaster)

생성된 zk-proof는 Paymaster를 통해 온체인에 제출된다. Paymaster는 사용자를 대신하여 트랜잭션을 브로드캐스트하고 gas 비용을 지불하는 역할을 한다. 이로 인해 온체인에서는 트랜잭션의 발신자가 실제 사용자 주소가 아닌 Paymaster로 나타나며, 사용자의 온체인 식별 정보 노출이 최소화된다.

5) 온체인 검증 및 상태 업데이트

온체인에서는 트랜잭션을 직접 실행하지 않고, 제출된 zk-proof의 유효성만 검증한다. 이 과정에서 proof의 정합성과 함께 nullifier가 이미 사용된 값인지 여부를 확인한다.

검증이 완료되면 상태는 온체인은 다음과 같이 업데이트된다.

• 사용된 Note에 대응하는 nullifier가 기록됨 (이중 지출 방지)
• 새롭게 생성된 암호화된 Note가 Privacy Pool에 추가됨

이 과정에서 체인은 거래의 세부 내용을 복호화하거나 재실행하지 않으며, proof를 기반으로 최소한의 상태 변화만 반영한다.

3-4. STRK20의 차별화된 프라이버시 설계

앞선 절에서 살펴본 Note-nullifier 구조는 STRK20 프라이버시의 기본 뼈대다. 그러나 실제 온체인 금융에서 프라이버시가 활용되기 위해서는 단순한 거래 은닉을 넘어, 사용성·감사 가능성·DeFi 연동까지 함께 고려되어야 한다. STRK20은 이를 위해 Note Discovery, Viewing Key, Open Note와 같은 구성 요소를 결합한다. 이를 통해 사용자는 자신의 자산을 효율적으로 찾을 수 있고, 기관은 필요한 범위 내에서 감사 경로를 확보할 수 있으며, 프라이버시를 유지한 상태로 기존 DeFi 유동성과도 상호작용할 수 있다.

1) Note Discovery: 효율적인 자산 탐색 구조

프라이버시 시스템에서 가장 먼저 발생하는 문제 중 하나는 “사용자가 자신의 자산을 어떻게 찾는가”다. 일반적인 블록체인에서는 특정 주소의 잔고를 조회하면 되지만, 프라이버시 시스템에서는 자산의 소유 정보가 공개되지 않는다. 따라서 사용자는 어떤 Note가 자신의 것인지 직접적으로 알 수 없고, 이를 찾기 위한 별도의 탐색 구조가 필요하다.

Zcash와 같은 기존 Note 기반 프라이버시 시스템에서는 사용자가 자신에게 온 Note를 찾기 위해 전체 트랜잭션 출력값을 스캔하고 복호화를 시도해야 한다. 이는 프라이버시를 강하게 유지할 수 있다는 장점은 있지만, 네트워크 사용량이 증가할수록 탐색 비용도 함께 증가한다는 한계를 가진다. 즉, 사용자의 실제 활동량과 무관하게 전체 네트워크 규모가 커질수록 지갑이 처리해야 하는 데이터도 많아지는 구조다.

STRK20은 이 문제를 해결하기 위해 Note를 단순히 하나의 풀 안에 무작위로 저장하지 않고, Channel → Subchannel → Note 의 계층적인 구조로 정리한다. Channel은 특정 sender에서 recipient로 이어지는 일방향 연결이며, Subchannel은 그 Channel 내부에서 자산 종류별로 Note를 구분하는 단위다. 실제 자산 단위인 Note는 각 Subchannel 안에 순차적으로 저장된다.

이 구조를 통해 사용자는 전체 네트워크를 모두 스캔하지 않고, 자신과 연결된 Channel을 중심으로 자산을 탐색할 수 있다. 먼저 자신에게 연결된 channel 목록을 확인하고, 각 Channel 내부의 Subchannel을 살펴본 뒤, 해당 Subchannel에 포함된 Note를 확인하는 방식이다. 결과적으로 탐색 범위는 전체 네트워크 활동량이 아니라 사용자 자신의 활동 범위로 제한된다.

이를 단순화하면 다음과 같다:

• 기존 프라이버시 모델: O(N) → 전체 네트워크 트랜잭션 수에 비례
• STRK20: O(k) → 사용자 관련 트랜잭션 수에 비례 (k ≪ N)

예를 들어 네트워크에 1,000만 개의 트랜잭션이 존재하더라도, 사용자가 실제로 상호작용한 거래가 100건이라면, 기존 구조에서는 1,000만 개를 모두 확인해야 하지만 STRK20에서는 약 100건만 탐색하면 된다.

따라서 STRK20의 Note Discovery는 프라이버시를 유지하면서도 지갑 사용성과 확장성을 개선하기 위한 장치다. 이는 단순한 암호학적 프라이버시를 넘어, 실제 사용자가 프라이빗 자산을 관리할 수 있게 만드는 핵심 차별점이다.

2) Viewing Key: 프라이버시와 감사 가능성의 접점

프라이버시가 실제 금융 환경에서 사용되기 위해서는 거래 정보를 외부에 숨기는 것만으로는 충분하지 않다. 기관이나 기업은 시장에는 포지션, 거래 흐름, 상대방 정보를 노출하고 싶지 않지만, 내부 감사, 회계, 세무, 규제기관 요청에는 대응할 수 있어야 한다. 즉, 프라이버시는 “아무도 볼 수 없는 구조”가 아니라, 일반 관찰자에게는 비공개로 유지하되 필요한 경우 정당한 권한을 가진 주체가 특정 범위 안에서 확인할 수 있는 구조여야 한다.

기존 프라이버시 프로젝트들도 선택적 공개 기능을 일부 제공하지만, 감사 구조의 성격은 유사한 한계를 가진다. 예를 들어 Zcash에는 viewing key 개념이 있어 사용자가 필요할 경우 자신의 거래 내역을 제3자에게 공유할 수 있다. Aztec 역시 private Note를 수신하고 복호화하기 위한 viewing key 계열 구조를 사용하며, 사용자가 키를 공유하거나 애플리케이션이 별도로 설계될 경우 특정 주체가 거래 정보를 확인할 수 있다. 다만 이 방식은 모두 사용자가 직접 viewing key를 제공해야만 작동하기 때문에, 사용자가 협조하지 않으면 감사가 어렵다는 한계가 있다. 즉, Zcash와 Aztec의의 viewing key는 규제 대응을 위한 기본 감사 인프라라기보다, 사용자가 자발적으로 거래 내역을 공개할 수 있는 도구에 가깝다.

STRK20은 이를 위해 Viewing Key를 프로토콜 차원의 컴플라이언스 구조에 포함한다. 사용자는 Privacy Pool에 진입할 때 자신의 거래 내역을 복호화할 수 있는 Viewing Key를 생성하고, 이 키를 감사 주체의 공개키로 암호화해 온체인에 등록한다. 이후 정당한 법적 요청이 있을 경우, 지정된 감사 주체는 특정 사용자의 Viewing Key를 복호화해 해당 사용자의 거래 경로를 복원할 수 있다.

다만 이 권한이 단일 주체에게 집중되는 구조는 아니다. Viewing Key를 복호화할 수 있는 감사 주체는 여러 구성원으로 이루어진 위원회 또는 threshold 방식의 키 관리 구조로 설계될 수 있으며, 특정 사용자의 거래 내역을 확인하기 위해서는 일정 수 이상의 구성원이 동의해야 한다. 즉, 한 명의 관리자나 기관이 임의로 사용자의 거래 내역을 열람하는 방식이 아니라, 정해진 절차와 합의 조건을 거쳐 제한적으로 접근하는 구조에 가깝다.

중요한 점은 이 구조가 전체 네트워크의 프라이버시를 깨는 방식이 아니라는 점이다. 감사는 특정 사용자 단위로 제한되며, 한 사용자의 Viewing Key가 복호화되더라도 다른 사용자의 거래 내역은 공개되지 않는다. 따라서 STRK20의 Viewing Key는 블록체인 전체의 “백도어”라기보다, 기관과 규제 환경에서 필요한 사용자 단위 선택적 투명성을 제공하는 장치에 가깝다.

3) Open Note: 프라이버시와 퍼블릭 DeFi 연결을 위한 장치

프라이버시가 온체인 금융에서 의미를 가지기 위해서는 단순 전송을 넘어 DeFi와 연결될 수 있어야 한다. 문제는 기존 프라이버시 모델들이 이 지점에서 한계를 드러냈다는 점이다.

Zcash와 Monero는 프라이버시 송금에 특화된 체인이다. 설계 자체가 프라이빗 결제 네트워크를 목표로 하고 있기 때문에, 스마트컨트랙트 기반 실행 환경을 지원하지 않는다. 이로 인해 AMM, 대출, 파생상품과 같은 복합적인 DeFi 구조를 온체인에서 구현하기 어렵고, 실제로 해당 체인 위에 활성화된 DeFi 생태계도 거의 존재하지 않는다. 결과적으로 Zcash와 Monero는 프라이빗 결제 수단으로는 기능할 수 있지만, 기관이 요구하는 금융 인프라를 제공하는 실행 레이어로 보기는 어렵다.

Aztec은 이러한 한계를 보완하기 위해 프라이버시와 스마트컨트랙트를 결합한 구조를 지향한다. private smart contract를 통해 거래 실행 자체를 비공개로 처리할 수 있어, 스왑이나 대출과 같은 DeFi 로직도 프라이버시 환경 안에서 구현하는 것이 가능하다. 다만 이 방식은 기존 Uniswap과 같은 공개 DeFi 유동성을 그대로 활용하기보다는, 신규 체인인 Aztec의 프라이버시 환경 내부에 별도의 애플리케이션과 유동성을 구축하는 방향에 가깝다. 이로 인해 프라이버시는 확보할 수 있지만, 공개 DeFi 시장과 유동성이 분리될 수 있다는 한계가 존재한다.

이러한 한계 속에서 STRK20은 다른 접근을 취한다. 기존 공개 DeFi 유동성을 유지하면서도 사용자 신원을 보호할 수 있도록 설계되었으며, 이를 가능하게 하는 구조가 Open Note다.

Open Note는 AMM 스왑처럼 결과 금액을 미리 확정하기 어려운 DeFi 거래를 처리하기 위해 도입된 특수한 Note다. 일반적인 암호화 Note는 생성 시점에 자산 종류와 금액이 정해져야 한다. 그러나 AMM 스왑에서는 실행 시점의 풀 상태, 가격, 슬리피지, 직전 거래에 따라 최종 출력 금액이 달라질 수 있다. 따라서 사용자가 증명을 생성하는 시점에 “스왑 결과로 정확히 얼마를 받을지”를 미리 알기 어렵고, 일반 Note 구조만으로는 공개 AMM과 자연스럽게 연결되기 어렵다.

Open Note는 이 문제를 “빈 Note를 먼저 만들고, 실행 후 실제 결과값을 채워 넣는 방식”으로 해결한다. 사용자는 먼저 기존 Source Note를 소비하고, 결과 자산을 받을 빈 Open Note를 생성한다. 이후 Source Token은 Helper Contract로 전달되고, Helper Contract는 기존 공개 AMM에서 스왑을 실행한다. 스왑이 완료되면 실제로 받은 Destination Token이 앞서 생성한 Open Note에 입금된다. 즉, 출력 금액을 미리 확정하지 않아도, 실행 시점에 결정된 결과값을 Open Note에 채워 넣을 수 있는 구조다.

이 모든 과정은 하나의 원자적 트랜잭션(Atomic Transaction) 안에서 처리된다. Source Note 소비, 빈 Open Note 생성, Helper Contract 출금, AMM 스왑, Open Note 입금이 분리된 거래로 실행되는 것이 아니라 하나의 흐름으로 묶인다. 따라서 중간 단계에서 스왑이 실패하거나 조건이 맞지 않으면 전체 과정이 함께 실패하고, 성공할 경우에만 기존 Note 소비와 결과 Note 입금이 동시에 완료된다.

다만 Open Note 기반 스왑은 완전한 Private Swap은 아니다. 공개 AMM을 그대로 사용하기 때문에 어떤 자산이 얼마만큼 스왑되었는지, AMM 풀의 상태가 어떻게 변했는지는 온체인에서 관찰될 수 있다. 즉, Token과 Amount는 공개될 수 있다. 대신 STRK20이 이 과정에서 보호하려는 것은 거래를 수행한 사용자의 신원이다. 외부 관찰자는 스왑 금액과 자산 종류는 볼 수 있지만, 해당 거래가 어떤 사용자의 프라이빗 Note에서 시작되었는지는 직접 확인하기 어렵다.

결과적으로 Open Note는 STRK20이 단순한 비공개 전송에 머무르지 않고 기존 공개 DeFi 유동성과 연결될 수 있도록 만드는 핵심 장치다. 완전한 프라이버시를 제공하는 구조는 아니지만, 공개 AMM의 유동성과 가격 발견 기능을 유지하면서 사용자 식별 정보는 숨기는 방식으로, 프라이버시와 DeFi 활용성 사이의 현실적인 균형을 제시한다.

4. Starknet BTCFi Roadmap

4-1. strkBTC와 Shinobi 업그레이드: 프라이버시 자산의 실제 적용

Starknet의 프라이버시 기능은 단일 기능의 도입이 아니라, 기관 중심 BTCFi를 구축하기 위한 흐름 속에서 단계적으로 구현되고 있다. STRK20 역시 이러한 흐름 속에서 등장한 결과물이며, 이를 실제 자산에 적용하기 위한 핵심 인프라가 함께 구축되고 있다.

그 중심에는 2026년 2월 26일 발표된 strkBTC가 있다. strkBTC는 Starknet이 주도해 설계한 wrapped BTC 자산으로, 네이티브 BTC와 1:1로 연동되며 필요할 경우 다시 BTC로 상환할 수 있는 구조를 가진다. 사용자는 BTC를 Starknet으로 가져올 때 비트코인을 예치하고 그에 대응되는 strkBTC를 발행받으며, 반대로 Starknet에서 strkBTC를 소각하면 네이티브 BTC로 출금할 수 있다.

기존 BTC 래핑 자산들이 온체인에서의 투명성을 그대로 유지했던 것과 달리, strkBTC는 필요에 따라 공개 상태와 비공개 상태를 선택할 수 있도록 구성되어 있다. 공개 모드에서는 일반 ERC-20처럼 작동하지만, 비공개 모드에서는 잔고와 거래 정보가 외부에 노출되지 않으며, 필요 시에만 선택적으로 공개할 수 있는 구조를 가진다. 이는 Bitcoin을 DeFi 환경에서 실제로 활용하는 과정에서 발생하던 거래 노출 문제를 완화하기 위한 설계다.

현재 strkBTC는 초기 단계에서 Federation 기반 멀티시그 구조로 운영된다. 복수의 독립된 기관이 Bitcoin 멀티시그를 공동으로 운영하고, 입출금 과정에서 트랜잭션을 검증하고 서명하는 방식이다. 이는 단일 커스터디나 소수 운영자에 의존하는 기존 wrapped BTC 구조와 달리, 신뢰 가정을 분산시키고 보다 명확하게 정의하기 위한 설계다.

한편, 이러한 프라이버시 자산이 실제로 작동하기 위해서는 단순히 이론적으로 설계한 구조만으로는 부족하다. 실제로 이러한 구조가 실행될 수 있는 실행 환경이 필요하다. 이를 가능하게 하는 기반이 바로 Starknet “Shinobi” 업그레이드(v0.14.2)다.

https://x.com/Starknet/status/2046232796625068334

기존에도 Starknet은 zk-rollup 구조를 통해 오프체인에서 트랜잭션을 실행하고 그 결과를 proof 형태로 제출해 검증하는 방식을 사용해왔다. 다만 이 과정에서 proof의 최종 검증은 Ethereum(L1)에서 이루어졌기 때문에, L2 내부에서는 개별 트랜잭션 단위로 proof를 유연하게 활용하는 데 한계가 있었다.

Shinobi 업그레이드는 이러한 구조를 확장해, Starknet 자체에서 proof를 직접 검증할 수 있는 기능(in-protocol proof verification)을 도입했다. 이를 통해 사용자가 오프체인에서 생성한 proof를 L2에 제출하면, 네트워크가 이를 내부에서 바로 검증할 수 있게 되었으며, 블록 단위가 아닌 트랜잭션 단위로 proof를 처리하는 보다 유연한 실행 구조가 마련되었다.

이러한 변화는 STRK20과 같은 프라이버시 자산 모델을 구현하기 위한 핵심 전제 조건이다. 프라이버시 기반 트랜잭션은 각 사용자가 거래 내용을 공개하지 않은 상태에서 개별적으로 proof를 생성하고, 이를 독립적으로 검증할 수 있어야 한다. Shinobi 업그레이드는 이러한 사용자 단위 proof 검증을 가능하게 함으로써, 거래의 세부 내용을 노출하지 않으면서도 정합성을 보장할 수 있는 환경을 제공한다.

결과적으로 Shinobi 업그레이드는 “프라이버시를 검증할 수 있는 실행 구조”를 제공하고, strkBTC는 이를 “실제 자산에 적용한 사례”다. STRK20은 이 둘을 연결하는 프라이버시 자산 구조로, 프라이버시 자산이 실제로 발행·운용될 수 있는 기반을 완성한다.

4-2. 스타크넷 탈중앙화 로드맵

https://www.starknet.io/roadmap/

현재 STRK20과 strkBTC 구조는 최종 형태가 아니라, 보다 근본적인 탈중앙화를 향한 초기 단계에 해당한다. Starknet은 네트워크 전반의 구조를 점진적으로 분산시키는 방향을 목표로 하고 있으며, 실행-증명-검증(execution–proving–verification) 전 과정이 단일 주체에 의존하지 않는 탈중앙화된 형태로 확장될 예정이다.

우선 네트워크 측면에서는 시퀀서뿐 아니라 proving 인프라까지 포함한 구조적 탈중앙화가 진행된다. 기존에는 특정 주체가 트랜잭션 실행과 증명 생성에 중요한 역할을 수행했다면, 향후에는 이러한 역할이 여러 참여자에게 분산되며, 검증 역시 보다 독립적인 형태로 이루어지게 된다. 이는 네트워크의 검열 저항성과 신뢰성을 동시에 높이는 방향이다.

strkBTC 역시 이러한 흐름과 맞물려 발전한다. 현재의 Federation 기반 구조는 명확한 신뢰 가정을 가진 초기 모델로, 복수의 기관이 멀티시그를 통해 BTC 예치와 strkBTC 발행·상환 과정을 관리하는 방식이다. 이는 단일 커스터디 리스크를 줄이기 위한 설계지만, 여전히 특정 참여자 집합에 대한 신뢰를 전제로 한다는 한계가 있다.

이에 따라 strkBTC는 장기적으로 BitVM 및 OP_CAT 기반 구조를 도입해, BTC ↔ strkBTC 전환을 비트코인 네트워크 위에서 보다 네이티브하게 검증할 수 있는 방향을 목표로 한다. BitVM과 OP_CAT은 비트코인 스크립트의 제약을 보완해, 외부 운영자의 판단이나 서명에 의존하지 않고도 예치, 발행, 소각, 상환의 정합성을 비트코인 상에서 검증할 수 있도록 만든다.

https://x.com/StarkWareLtd/status/1813929304209723700

실제로 StarkWare는 2024년 Bitcoin Signet 테스트넷에서 STARK verifier를 통해 ZK proof를 검증하는 데 성공한 바 있으며, 이는 비트코인 위에서도 zk 기반 검증 로직을 구현할 수 있음을 보여준 초기 사례로 평가된다. 즉, strkBTC의 장기 방향성은 federation 기반 운영을 넘어, 비트코인 자체의 검증 구조 안에서 trustless에 가까운 BTC 래핑·상환 모델을 구현하는 데 있다.

이러한 변화가 완성될 경우 Starknet은 단순한 Layer 2를 넘어, Bitcoin과 Ethereum을 동시에 정산 기반으로 활용하는 통합 실행 환경으로 발전할 수 있다. 이는 두 생태계 간 자산 이동이 신뢰 최소화 방식으로 이루어지는 구조를 의미하며, BTC 기반 거래, 담보, 유동성 공급 등 보다 복잡한 금융 활동을 온체인에서 수행할 수 있는 기반을 제공한다.

5. 마무리: 기관 채택을 위한 과제

STRK20과 strkBTC가 기술적으로 구현되더라도, 실제 시장에서 의미를 가지기 위해서는 기관 자금과 유동성이 유입되어야 한다. 현재는 아직 초기 인프라 구축 단계에 가깝지만, 동시에 Starknet은 기관 중심 BTCFi를 위한 핵심 조건들을 하나씩 갖춰 나가고 있다.

첫째, 유동성 확보 문제다. 프라이버시 구조는 단순 전송 기능만으로는 충분하지 않으며, 거래, 담보, 결제 등 실제 금융 활동이 가능해야 한다. 이를 위해서는 충분한 자산 규모와 유동성이 필수적이다. Starknet은 이를 위해 BTCFi Season과 같은 인센티브 프로그램을 운영하며 초기 유동성 확보를 시도하고 있고, strkBTC와 같은 자산 도입을 통해 BTC 기반 유동성 유입의 기반을 마련하고 있다. 다만 기관 자금이 본격적으로 유입되기 위해서는 더 다양한 자산과 깊은 유동성이 필요하다.

둘째, 규제 및 컴플라이언스 정합성이다. 기관은 자산의 출처와 거래 흐름을 설명할 수 있어야 하며, 감사 및 보고 요구에도 대응해야 한다. STRK20은 Viewing Key 기반의 선택적 공개 구조를 통해 이러한 요구를 충족하려 하고 있으며, 실제로 사용자 단위 감사가 가능한 구조를 프로토콜 레벨에서 포함하고 있다는 점에서 기존 프라이버시 시스템과 차별화된다. 다만 이러한 구조가 각국 규제 환경에서 어떻게 해석되고 수용될지는 여전히 중요한 변수로 남아 있다.

셋째, 신뢰 구조의 전환이다. 현재 strkBTC는 federation 기반 구조로 운영되며, 이는 초기 단계에서는 현실적인 접근이지만 완전한 trustless 구조는 아니다. 다만 초기부터 복수 기관 기반 멀티시그 구조를 채택해 단일 커스터디 리스크를 줄이고 있으며, 동시에 BitVM 및 OP_CAT 기반 구조로의 전환을 로드맵에 포함하고 있다는 점에서 점진적인 신뢰 최소화 방향이 명확하다. 향후 이 전환이 실제로 구현될 수 있는지가 기관 채택에 있어 핵심 변수로 작용할 것이다.

물론 이러한 과제들이 단기간에 해결되기는 어렵다. 그러나 중요한 점은 Starknet이 기관 중심 BTCFi에 필요한 조건들을 단순한 개념으로 제시하는 데 그치지 않고, 실제 프로토콜 설계와 로드맵 안에 반영하고 있다는 점이다. 유동성 확보, 규제 대응, 신뢰 최소화는 각각 독립된 문제가 아니라 기관이 온체인 금융에 참여하기 위한 기본 조건에 가깝다.

결국 STRK20과 strkBTC는 단순한 기능 추가라기보다, 기관이 활용할 수 있는 BTCFi 실행 환경을 만들기 위한 인프라적 시도다. 향후 유동성과 사용 사례가 확장될 경우, Starknet은 단순한 Layer 2를 넘어 BTC 기반 자산 운용, 거래, 담보 활용이 이루어지는 기관급 온체인 금융 레이어로 자리 잡을 수 있을 것이다.