어떤 블록체인은 서명 내용을 보여주고, 어떤 곳은 그렇지 않은가?

1단계: 구조적으로 투명 — 거래 의도가 설계상 읽을 수 있다

아래 네 가지 생태계는 클리어 사인이 외부 도구 없이 프로토콜 설계만으로 자연스럽게 구현되는 대표적인 사례예요.

XRP Ledger

XRP Ledger는 주요 블록체인 중 클리어 사인 구현이 가장 강력해요. 약 50가지 이상의 거래 타입(예: Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint 등)이 모두 이름과 타입이 지정된 필드로 명확히 정의돼 있어요.

바이너리 포맷도 자체 해석이 가능해 TransactionType 필드만으로 완전히 결정적인 파싱이 가능하고, 전체 필드 스키마는 rippled 소스 코드의 정의 파일에 유지돼요.

하드웨어 지갑은 모든 거래 타입의 모든 필드(수신자, 금액(토큰의 경우 통화 및 발행자 포함), 수수료, 메모, 타입별 파라미터)를 표시할 수 있어요. 계정 기반 모델이라 금액이 명확하게 드러나고(UTXO 복잡성 없음), 수수료도 단순 필드로 처리돼요.

현재 메인넷 거래의 거의 100%가 완전한 클리어 사인이 가능해요. 다만 새로운 거래 타입이 프로토콜 개정(예: Vault, Loan 등)으로 추가될 경우 하드웨어 지갑 앱 업데이트가 필요하고, 미지원 타입은 블라인드 사인으로 처리돼요.
 

Polkadot / Substrate

Polkadot은 업계에서 가장 기술적으로 정교한 클리어 사인 솔루션을 개발했어요. 런타임 메타데이터 시스템(MetadataV14/V15)은 런타임 내 모든 pallet(모듈), call, 데이터 타입에 대한 완전한 타입 레지스트리를 제공해요.

모든 거래(extrinsic)는 pallet_index || call_index || encoded_arguments 구조로 되어 있고, 메타데이터가 각 인덱스의 의미와 파라미터 해독법을 정확히 알려줘요.

주요 과제는 전체 메타데이터가 200KB를 초과해, 약 64KB RAM의 하드웨어 지갑에서는 너무 크다는 점이었어요. 이에 대한 해법이 RFC-0078(Merkleized Metadata)로, 메타데이터를 머클 트리로 만들고, 해당 거래에 필요한 타입만 부분적으로 전송하며, 포함 증명도 함께 제공해요.

메타데이터 해시는 CheckMetadataHash 서명 확장으로 온체인 검증되어 신뢰성을 확보해요. 덕분에 Ledger의 단일 앱으로 모든 Polkadot 패러체인과 릴레이 체인을 별도 업데이트 없이 지원할 수 있어요.

런타임 업그레이드가 발생해도, 인덱스가 바뀌면 새로운 메타데이터와 증명이 제공되어 서명 정확성을 유지해요.

Cosmos / Tendermint

Cosmos/Tendermint 체인은 각 거래가 하나 이상의 sdk.Msg 객체로 구성된 타입 메시지 구조를 사용해요. 이들은 Protobuf의 google.protobuf.Any로 래핑되고, type_url 필드로 메시지 타입을 식별해요.
표준 메시지인 MsgSend, MsgDelegate, MsgVote 등은 널리 알려진 스키마를 갖고 있어요.

생태계 차원의 클리어 사인 솔루션은 SIGN_MODE_TEXTUAL (ADR-050)로, Cosmos SDK v0.50에 도입됐어요. 거래를 소형 기기 화면에 맞게 여러 화면으로 나눠 보여주며, value renderers가 원시 데이터를 사람이 읽기 쉽게 변환해요. 예를 들어 "2000000uatom" 대신 "2 ATOM"으로, 주소는 bech32, 타임스탬프는 RFC3339 형식으로 표시해요.

개발자는 메시지 타입별로 커스텀 렌더러를 제공할 수 있고(포맷과 파싱 함수가 완전히 역변환 가능해야 함), 서명 페이로드에는 텍스트 표현과 원시 바이트 해시가 모두 포함되어 보안성을 유지해요.

NEAR Protocol

NEAR Protocol은 사람이 읽기 쉬운 설계를 우선시해 클리어 사인을 실현했어요. 계정 식별자가 "alice.near"처럼 사람이 읽을 수 있는 이름이고, 16진수 주소가 아니에요.

거래에는 항상 식별 가능한 Action enum(Transfer, Stake, FunctionCall, AddKey 등)이 포함돼요. 특히 FunctionCall 액션에는 메서드 이름이 일반 문자열로(예: "transfer", "set_greeting") 들어가고, 인자는 기본적으로 JSON 직렬화돼요.

하드웨어 지갑은 "app.defi.near에서 'swap' 메서드 호출, args: {amount: 1000, token: 'usdc.near'}"처럼 명확하게 표시할 수 있어요. 셀렉터 기반 시스템보다 훨씬 읽기 쉽죠. 단, 일부 계약은 가스 효율을 위해 Borsh 직렬화를 선택하는데, 스키마가 없으면 불투명해져요.

2단계: 조건부 투명 — 기본 연산은 명확, 스마트 컨트랙트는 불투명

기본 계층 연산에서는 클리어 사인이 잘 작동하지만, 범용 프로그래밍이 들어오면 투명성이 크게 떨어져요.

Bitcoin

Bitcoin은 거래 모델 특성상, 스마트 컨트랙트가 없어도 클리어 사인에 어려움이 있어요. UTXO 모델은 입력 금액이 거래 내에 포함되지 않고, 입력은 이전 출력의 해시와 인덱스를 참조하지만 해당 금액 정보는 빠져 있어요.

이 정보가 없으면 하드웨어 지갑은 수수료(전체 입력-전체 출력) 계산이나 과다 지불 여부 확인이 불가능해요. PSBT (BIP 174)는 미서명 거래에 UTXO 메타데이터와 BIP32 파생 경로를 추가해 이 문제를 해결해요.

PSBT 덕분에 하드웨어 지갑은 표준 결제의 수신 주소, 금액, 수수료를 명확히 표시할 수 있고, 이는 전체 거래의 약 90%를 커버해요. 다중서명, 타임락 스크립트, Taproot script-path 사용 등 복잡한 구조에서는 난이도가 크게 올라가요. P2SH, P2WSH는 임의 스크립트를 해시 뒤에 숨기고, Taproot의 MAST 구조는 대체 지불 조건을 사용 전까지 보이지 않게 해요.

Aptos

Aptos는 Move의 강력한 타입 시스템과 온체인 ABI 덕분에 이점을 가져요. 거래 페이로드에는 0x1::aptos_account::transfer처럼 완전한 함수 식별자가 포함되고, 모듈 주소, 이름, 함수명도 모두 명확히 드러나요.

SDK가 온체인 ABI를 조회해 BCS-인코딩 인자를 역직렬화할 수 있어, ABI 접근이 가능한 하드웨어 지갑은 "0x1::aptos_account::transfer(recipient: 0xABC..., amount: 1000) 호출"처럼 표시할 수 있어요.

단, BCS(Binary Canonical Serialization)는 자체 해석이 불가능하므로, ABI 스키마 없이는 원시 BCS 바이트가 의미를 갖지 못해요. 스크립트 페이로드(임의 Move 바이트코드)는 구조화된 엔트리 함수 형식을 완전히 우회해요. Ledger Aptos 앱에는 복잡한 거래를 위한 "Enable Blind Signing" 설정이 따로 있어, 단순/복잡 거래의 차이를 명확히 보여줘요.

Stellar

2단계 패턴의 대표적인 예시예요. 26가지 고전적 연산 타입(Payment, ChangeTrust, ManageSellOffer 등)은 고정된 스키마로 완전히 파싱 가능해요. Ledger 앱에서는 연산 타입, 금액, 목적지, 자산, 메모, 수수료를 단계별로 검토할 수 있고, 고전 연산의 약 95%를 커버해요.

• Soroban 스마트 컨트랙트(2024년 도입)는 Ethereum에서와 동일한 불투명성 문제를 다시 불러와요. 호출은 InvokeHostFunction 연산으로 도착하고, 계약 주소는 불투명 포맷, 파라미터는 ScVal 타입으로 인코딩되어 계약별 지식 없이는 해독이 불가해요. 외부 메타데이터 없이는 Soroban 거래의 클리어 사인은 거의 0%에 가까워요.

Algorand

7가지 타입의 거래(Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof)는 모두 MessagePack 인코딩에서 완전히 파싱 가능해요. ARC-4 ABI 표준은 호환 스마트 컨트랙트에 대해 메서드 시그니처, 파라미터명, 설명을 제공해요.

• ARC-4 미지원 계약은 파라미터가 불투명해요.
• 모든 스마트 컨트랙트는 최대 256개의 내부 거래(최대 8단계 중첩 호출 포함)를 생성할 수 있고, 이들은 서명 시점에 완전히 보이지 않아요.

Cardano & Tezos

Cardano의 eUTXO 모델은 단순 거래의 입력, 출력, 수수료, 멀티에셋 값을 명확히 표시할 수 있어요. 하지만 Plutus 스크립트는 datums와 redeemers라는 임의의 CBOR-인코딩 데이터 구조를 사용해, 표준 해석 스키마가 없어요. CIP-21에는 Plutus 모드가 "최대 유연성을 추구하지만, 사용자가 오해할 위험이 있다"고 명시돼 있어요.

Tezos는 구조적으로 유리한데, 계약 파라미터 타입이 온체인에 저장되고, 엔트리포인트도 해시 기반 셀렉터가 아닌 문자열 이름을 사용해 충돌 문제를 피해요. 하지만 Micheline 바이너리 인코딩은 완전한 해독을 위해 계약 타입 스키마가 필요하고, Ledger Tezos 앱도 복잡한 파라미터는 표시가 제한됨을 인정해요.

❌ 구조적으로 불투명 — 클리어 사인은 구조적 한계

도구 부족이 아니라, 근본적인 설계 선택 때문에 이 계층에서는 클리어 사인이 본질적으로 어렵습니다. 외부 메타데이터 레이어가 부분적으로 도움은 되지만, 근본 구조를 바꿀 수는 없어요.

Ethereum / EVM 체인

가장 대표적이고 연구도 가장 많이 된 사례예요. 사용자가 스마트 컨트랙트와 상호작용할 때, 거래 데이터 필드에는 함수 시그니처의 keccak256 첫 4바이트(함수 셀렉터)와, 32바이트 단위로 ABI 인코딩된 파라미터가 들어가요. 계약의 ABI JSON이 온체인에 저장되지 않으므로, 이는 사실상 16진수 노이즈에 불과해요. 하드웨어 지갑이 0xa9059cbb000...03e8을 봐도, 외부 메타데이터 없이는 "0xABC...에게 1000 토큰 전송"임을 알 수 없어요.

EVM의 고질적 패턴들이 문제를 더 복잡하게 만들어요:

• 함수 셀렉터 충돌: 4byte.directory 데이터베이스에는 거의 100만 개의 시그니처가 있어, 32비트 공간의 생일 문제 임계치를 넘어섰어요. 서로 다른 함수가 동일한 셀렉터를 가질 수 있습니다.
• 프록시 계약: delegatecall을 통해 실행을 구현 계약으로 위임하는데, 구현 주소는 언제든 바뀔 수 있어요. Bybit 해킹도 이 허점을 노렸어요.
• 멀티콜 패턴: ABI 인코딩된 calldata를 파라미터 안에 중첩해, 재귀적 해독이 필요해요.
• EIP-712: 오프체인 메시지(permit, order 등) 가독성은 개선하지만, 온체인 거래의 불투명성은 해결하지 못해요.

Solana

클리어 사인 측면에서 가장 난이도가 높은 구조 중 하나예요. 거래 명령에는 program_id, 계정 목록, 불투명한 바이트 배열의 명령 데이터가 들어가요. 표준화된 ABI가 없고, 각 프로그램이 자체 직렬화 포맷을 정의해요. Anchor 프레임워크는 명령 이름의 SHA-256에서 8바이트를 추출하는 방식의 준표준을 제공하지만, 어디까지나 프레임워크 관례일 뿐 프로토콜 요구사항은 아니에요. 많은 프로그램이 Anchor를 사용하지 않거나 IDL을 공개하지 않아요.

• 버전 거래의 Address Lookup Table은 32바이트 주소를 1바이트 인덱스로 압축해요. 하드웨어 지갑은 온체인 접근 권한이 없으므로 테이블 내용을 검증할 수 없고, Solana 공식 문서도 이를 명확히 인정해요.
• Cross-Program Invocation 체인은 서명 시점에 완전히 보이지 않아요.
• 단순 SOL 전송, SPL 토큰 연산은 Ledger가 파싱할 수 있지만, Solana 전체 거래량의 대다수를 차지하는 DeFi 상호작용은 사실상 블라인드 사인이 필수예요.

TON

클리어 사인을 어렵게 만드는 여러 구조적 특성을 동시에 갖고 있어요.

• Cell 기반 데이터 구조: 모든 데이터가 셀 트리(각 셀은 최대 1023비트, 최대 4개 참조)로 표현되어, 셀 하나를 넘는 메시지는 재귀적으로 트리를 순회해야 해요.
• TL-B 인코딩: 비트 단위에서 복잡한 생성자와 재귀 참조를 처리해, 바이트 정렬 포맷보다 하드웨어에서 파싱이 훨씬 어려워요.
• 범용 ABI 부재: 32비트 op 코드가 관례일 뿐, 프로토콜에서 강제하지 않아요.
• 비동기 실행: 한 번의 사용자 액션이 여러 계약과 샤드에 걸쳐 연쇄적인 내부 메시지를 트리거할 수 있어요. 사용자는 최초 외부 메시지에만 서명하고, 이후 모든 과정은 서명 시점에 보이지 않고 예측할 수 없어요.

Sui (참고)

Aptos와 같이 Move의 강력한 타입 시스템을 공유해 명령 단위에서는 도움이 돼요. 하지만 Sui의 Programmable Transaction Block(PTB)은 최대 1,024개의 명령을 포함할 수 있고, 각 명령 결과가 다음 명령으로 연쇄 전달돼요. 하드웨어 지갑 화면에서 이런 다단계 PTB를 실제로 의미 있게 표시하는 것은 극도의 UX 과제예요. 전체 거래를 이해하려면 모든 명령과 데이터 의존성을 분석해야 해요.