@mmjahanara , @pierre 님이 작성
이 글을 작성하는 데 도움을 주신 @b-wagn , @soispoke , @levs57 님께 감사드립니다.
요약: 웜홀의 부인 가능성 속성이 이더리움의 160비트 주소와 호환되지 않는 이유를 살펴봅니다. 또한, EIP-7503에서 주장하는 익명성 집합이 실제 기대치보다 훨씬 낮은 이유를 분석합니다. 후자의 문제는 해결 가능해 보이지만, 전자의 문제는 웜홀의 전체적인 구조를 재고해야 할 수도 있다고 생각합니다. 마지막으로 비콘 체인 예치금을 활용한 잠재적인 후속 설계 방안을 간략하게 설명합니다.
웜홀에 관하여
이더리움 개인정보 보호 솔루션은 역사적으로 애플리케이션별 익명성 집합에 의존해 왔습니다. 토네이도 캐시(Tornado Cash) 와 같은 프로토콜에서 자금 입금은 특정 스마트 계약과의 명시적인 상호 작용을 통해 이루어집니다. 이는 근본적인 결함을 초래합니다. 입금자와 출금자 간의 연결은 끊어지지만, 개인정보 보호 프로토콜 참여 자체는 공개되기 때문입니다. 이러한 설계 방식은 블록체인 관찰자가 익명성 집합에 속한 모든 입금자를 식별하고 잠재적으로 검열할 수 있도록 허용합니다.
EIP-7503(영지식 웜홀)은 그럴듯한 부인 가능성에 기반한 다른 패러다임을 제안합니다.
이 메커니즘은 간단합니다. 사용자는 암호화 방식으로 결정된 사용 불가능한 주소로 자금을 전송하여 "소각"합니다. 그런 다음, 해당 주소의 사전 이미지(pre-image)를 알고 있다는 (비대화형) 영지식 증명(NIZK)을 제공하여 새 계정으로 자금을 다시 발행합니다. 중요한 점은 이러한 "입금"(또는 "소각") 과정이 일반적인 이더리움(ETH)을 새 주소로 전송하는 것과 구별할 수 없다는 것입니다.
하지만, 우리는 그럴듯한 부인 가능성과 보안 사이에 근본적인 상충 관계가 존재할 수 있으며, 이것이 현재 L1 계층에 웜홀을 고정시키는 데 걸림돌이 될 수 있다고 생각합니다. 또한, EIP-7503의 실효 익명성 집합이 예상보다 낮을 수 있다는 문제점도 지적했습니다.
표기법 및 가정
우리는 다음을 사용할 것입니다:
- 일반적인 256비트 해시 함수(예: SHA3, SHA-256 등)의 경우 \mathsf{H}(\cdot) H ( ⋅ ) 입니다 .
- \operatorname{trunc}_{160}(x) trunc 160 ( x ) 256비트 값 x x를 160비트 이더리움 주소로 자르기.
- 도메인 분리 해시는 \mathsf{H}(\text{“TAG”} \parallel \cdots) H ( “TAG” ∥ ⋯ ) 와 같이 표현되며, 여기서 \text{“TAG”} “TAG” 는 고정된 ASCII 접두사입니다(예: \text{“worm”} “worm” , \text{“null”} “null” ).
EIP-7503
원래 EIP-7503 사양에서 소각 주소는 단일 비밀 키로 부터 파생됩니다.
첫 번째 단계에서 사용자는 임의의 s 를 선택하여 Addr_{burn}(s) 로 전송함으로써 자금을 소각합니다 . 이후 사용자는 스마트 계약에 널리파이어 \ nu = \ mathsf { H } ( \ text {“null”} \parallel s) ν = H ( “null” ∥ s ) 와 \nu ν 가 기존 트랜잭션 A\to B A → B (즉, s s st B = Addr_{burn}(s) B = A d d r b u r n ( s ) 를 사용)와 일치한다는 NIZK 증명을 제공하여 자금을 발행할 수 있습니다. 계약은 증명을 검증하고 \nu ν가 이전에 제출되지 않았는지 확인합니다. 이러한 검사를 통과하면 자금이 발행됩니다.
이러한 소각-발행 메커니즘의 보안 속성은 명시적으로 드러나지 않으므로, 비공식적으로 정의해 보겠습니다.
정확성/완전성
사용자가 정직하게 행동한다면, 소각 후 발행이 가능합니다.
은둔
- 연결 불가능성
직관적으로, 여기서 프라이버시는 사용자 본인을 제외한 누구도 소각 거래와 발행 과정, 즉 발행 계약에 제출된 발행 거래를 연결할 수 없다는 것을 의미합니다. 좀 더 정확히 말하자면, 이 경우 사용자가 정직하다고 가정하고, 블록체인 관찰자가 어떤 거래가 소각 거래이고 어떤 거래가 발행 거래인지 알 수 없도록 하는 것입니다.
- 그럴듯한 부인 가능성
두 번째로 우리가 원하는 개인정보 보호 속성은 소각 거래가 "일반" 거래처럼 보여야 한다는 것입니다. 특히, 소각 주소 B 는 임의의 주소처럼 보여야 합니다. 부인 가능성은 중요하며, 명시적인 계약 상호 작용을 요구하는 토네이도캐시(Tornado-Cash)와 같은 프로토콜과의 주요 차이점 중 하나입니다. 웜홀(Wormhole)을 사용하면 소각 프로토콜 참여는 비공개로 유지됩니다. 단, 인출은 공개됩니다.
비인플레이션
이는 ETH가 무에서 유를 창조하는 것을 원치 않으며, 소각을 먼저 수행한 후에만 새로운 ETH를 발행할 수 있도록 하자는 의미입니다. 즉, 모든 성공적인 발행 거래에서 소각 거래로의 매핑은 단사 함수적이어야 합니다. 언뜻 보기에 이는 공격자가 동일한 소각 거래에 대해 서로 다른 두 개의 무효화 객체를 생성하는 것을 방지하는 것을 의미합니다. 실제로 공격자가 동일한 소각 거래에 대해 서로 다른 두 개의 무효화 객체를 생성할 수 있다면 인플레이션 버그가 발생할 수 있습니다.
\mathsf{H}(\cdot) H ( ⋅ ) 가 숨겨져 있으니 간단하지 않을까요? 하지만 Scroll 팀이 일찍이 알아차렸듯이, 바로 이 부분에서 어려움이 발생합니다.
생일 역설
생일 역설은 160비트 주소가 충돌하는 두 개의 비밀 s_1, s_2 를 찾는 것이 가능 하다는 것을 의미합니다.
대략 2⁸⁰ 2⁸⁰ 번의 연산이 필요합니다. 이 숫자는 크지만, 국가나 대규모 채굴 풀이 충분히 처리할 수 있는 수준입니다. 공격자가 이러한 충돌을 발견하면 프로토콜이 무너집니다.
- 충돌하는 주소로 100 ETH를 한 번 입금하세요.
- 널리파이어 \nu_1=\mathsf{H}(\text{"null"} \parallel s_1) ν 1 = H ( "null" ∥ s 1 ) 및 \nu_2=\mathsf{H}(\text{"null"} \parallel s_2) ν 2 = H ( "null" ∥ s 2 ) 를 사용하여 발행합니다. 이 두 널리파이어는 서로 다르 므로 100 ETH가 두 번 발행됩니다.
- 200 ETH를 인출하세요.
검증자는 각 널라이저가 한 번만 사용되었는지 확인하기 때문에 이 두 인출이 동일한 온체인 예치금으로 뒷받침되는지 여부를 알 수 없습니다. 이는 무한 인플레이션 버그입니다. 2^{80} 2 80번째 생일 경계에서 발생하는 160비트 주소 충돌은 이중 발행으로 직접 이어집니다.
하지만 주소 공간이 더 큰 체인은 이러한 보안상의 단점에 직면하지 않아도 된다는 점에 유의해야 합니다. 320비트 전체 주소 공간을 사용하면 해당 체계의 보안은 충분히 만족스러울 것입니다. 이더리움의 160비트 주소 축소는 이론적으로는 제거할 수 있는 최적화 방식입니다.
잠정적인 해결책: 충돌 검색을 제거하고 대신 dlog를 사용하여 체계를 깨뜨리기 어렵게 만드는 것은 어떨까요?
한 가지 아이디어를 제안해 보겠습니다. 생일 역설을 해결하기 위해 공격자에게 충돌을 찾도록 요구하는 대신 dlog를 파괴하도록 요청하는 것은 어떨까요?
다음 제약 조건에 따라 명제 (\mathcal{R}_{root}, \nu) ( R r o o t , ν ) 및 증거 (sk,s_{worm},tx = (A,B,pk),\text{salt},\pi_{merkle}) ( sk , s w o r m , t x = ( A , B , p k ) , salt , π m e r k l e ) 에 대해 다음 NIZK를 사용하여 작업한다고 가정합니다 .
(1) \pi_{merkle} π m e r k l e는 \mathcal{R}_{root} R r o o t 에서 tx t x를 인증합니다.
(2) pk == \mathsf{SkToPk}(sk) p k = = S k T o P k ( s k ) , 즉 ECDSA 키의 경우 pk = sk \cdot G p k = s k ⋅ G 입니다.
(4) B == \operatorname{trunc}_{160}\!\big(\mathsf{H}(\text{"worm"} \parallel sk \parallel \text{salt})\big) B = = trunc 160 ( H ( "벌레" ∥ s k ∥ 소금 ) ) ;
(5) \nu == \mathsf{H}(\text{"null"} \parallel sk \parallel tx). ν = = H ( "null" ∥ s k ∥ t x ) .
그런 설정이 있으면 꽤 괜찮을 것 같습니다. 사용자는 동일한 솔트 값을 사용하여 두 개의 서로 다른 소각 거래를 할 때 소각 주소를 재사용할 수도 있습니다!
보안 논거 또한 간단합니다. 이제 이중 발행은 2⁸⁰ 2⁸⁰ 비용 주소 충돌을 악용하는 대신 NIZK, ECDSA 또는 \nuν 에 사용되는 해시를 해독해야 합니다. 실제로 고정된 소각 거래(따라서 고정된 A, pk, B A , p k , B )의 경우 유효한 sk는 하나뿐입니다. 그렇지 않으면 거래를 시작한 동일한 공개 키 에 매핑되는 서로 다른 두 개의 비밀 키를 찾을 수 있기 때문입니다. 따라서 충돌하는 모든 증인은 동일한 널리파이어에 매핑됩니다.
이게 해결책인가요?
꼭 그렇지는 않아요. 널리파이어 충돌 방지만이 유일한 문제는 아니니까요!
웜홀은 또한 소각 주소가 사용 가능하지 않도록 방지해야 합니다. 원래 EIP-7503에서 지적했듯이, 공격자는 create2_address(..., s1) == sha256("wormhole" || s2) 로 소각 한 후 create2_address ( ... , sha256("wormhole" || s2) create2_address(..., s1) 에서 다시 인출할 수 있습니다. 이는 공격자가 이더리움을 두 번(단 두 번) 빼낼 수 있다는 의미이지만, 그럼에도 불구하고 공격 실패로 간주되어야 합니다.
하지만 위에서 업데이트한 회로를 고려할 때 정말 걱정해야 할까요? 우리 설계는 공격자가 dlog를 파괴해야 하므로, 단순히 자금을 소각할 때 EXTCODESIZE 0 아니어야 한다는 조건을 추가 하면 되지 않을까요? 그렇게 하면 공격자가 create2_address(..., s1) 에 소각된 자금을 인출하는 것을 방지할 수 있을 것입니다.
문제는 위 방식이 공격자가 dlog를 해킹해야만 가능하다는 생각 자체가 잘못이라는 점입니다. 공격자가 소각 주소를 제어하는 방식은 개인 키에 대한 지식 증명 여부와 관계없이 CREATE2 명령어를 사용하는 방식과 사실상 동일합니다.
본 설정에서 소각 주소가 사용 가능하려면 다음과 같은 조건이 충족되어야 합니다. 공격자가 trunc160(H(\text{“ worm ” } || s_1 ) ) == trunc160(H(skToPk (s_2))) t r u n c 160 ( H ( “worm” | | s 1 ) ) = = t r u n c 160 ( H ( sk To P k ( s 2 ) ) ) 를 만족 하는 두 개의 비밀 ( s_1 , s_2 ) ( s 1 , s 2 ) 를 찾을 수 있다면 승리합니다. 실제로, 그런 경우 공격자는 사용 가능한 소각 주소를 얻게 됩니다. 왜냐하면 그러한 쌍을 찾으면 공격자는 trunc160(H(skToPk(s_1))) t r u n c 160 ( H ( sk To P k ( s 1 ) ) ) 에서 trunc160 (H(\text{“worm”} || s1)) t r u n c 160 ( H ( “worm” | | s 1 ) ) 로의 트랜잭션을 시작할 수 있기 때문입니다. 이 주소는 s_2 s 2 !로 제어됩니다.
우리는 원점으로 돌아왔습니다. 이는 복잡도가 80비트에 불과한 동일한 충돌 검색 문제입니다.
오늘날 부인 가능한 웜홀을 구현하려면 충돌 저항성을 고려해야 합니다.
탐지 휴리스틱을 무시하면, 웜홀의 부인 가능성 요건은 L1 계층을 관찰하는 누구도 웜홀 거래와 일반 거래를 구분할 수 없어야 함을 의미합니다. 이러한 속성은 소각 주소 계산이 소각을 시작하는 사용자에게만 비공개로 유지되어야 함을 자연스럽게 요구합니다. 그러나 충돌 저항성 문제 때문에, 사용자는 80비트 이상의 보안 수준으로 160비트 소각 주소를 생성하는 데 사용한 비밀 키가 해당 주소를 제어하지 않는다는 것을 증명할 방법이 없습니다.
한 가지 해결책은 소각 주소를 프로토콜 자체에 명시하는 것입니다(예: trunc160(H(\text{“worm”})) t r u n c 160 ( H ( “worm” ) ) 로 자금을 보내는 방식). 이렇게 하면 문제가 역상 탐색 문제로 바뀝니다. 하지만 이 설정은 우리가 추구하는 부인 가능성을 없애버립니다. 결국 우리는 보안성은 약하지만 부인 가능성이 있는 설계와 토네이도 캐시와 거의 동일한 설계 사이에서 선택해야 하는 상황에 놓이게 됩니다.
웜홀의 상태를 개선하는 데 유용하다고 생각되는 세 가지 질문을 여기에 나열합니다.
- L1 차원에 부인 가능한 웜홀을 고정하기 위해 활용할 수 있는 다른 기본 요소가 있을까요? 저희는 있다고 생각하며, 비콘 저장소를 활용하는 방안에 대한 후속 연구를 진행하고 있습니다. 아래 추가 자료에서 이 아이디어를 간략하게 설명합니다.
- 부정 가능성을 유지하면서 역상 탐색 문제를 통해 웜홀을 구축할 수 있는 방법이 있을까요? 확실하지는 않지만, 결정론적이면서도 비공개적인 소각 주소를 사용하는 것은 상당히 어려워 보입니다.
- 위의 두 질문 중 하나에 긍정적으로 답할 수 있도록 해주는, 쉽게 적용할 수 있는 L1 변경 사항이 있을까요?
추가 기능
EIP-7503 유효 익명성 집합
실질적인 문제 중 하나가 있는데, 이 부분에 대해 제대로 논의가 이루어졌는지 확신할 수 없습니다. 따라서 불확실한 점이 있어 여기에 내용을 명확히 적어둡니다.
EIP-7503은 beacon_block_root 를 발행 증명의 공개 입력값으로 노출합니다. 그러나 이 결정은 주장된 익명성 집합( 송금 거래가 없는 모든 이더리움 계정 )을 해당 블록에서 발생한 거래로 축소합니다. 왜냐하면 해당 소각 거래는 참조된 블록에 있어야 하기 때문입니다. 웜홀 프로토콜이 거래 영수증 루트를 사용자 발행 증명의 입력값으로 사용하기로 결정한다면, 충분히 큰 익명성 집합을 유지하려면 이전의 모든 거래에 대한 인증 경로를 얻을 수 있는 누적기에 대한 접근이 필요할 것입니다.
이론적으로는 가능해야 하지만, 모든 블록 루트 해시는 해당 블록 이전의 모든 트랜잭션에 대한 커밋먼트이므로, 이 증명을 위해서는 효율적인 클라이언트 측 재귀적 SNARK 또는 특정 L1 설정이 필요합니다. 예를 들어, 케칵(keccak)을 산술 연산에 적합한 해시로 대체하거나, 블록 헤더에 이전 블록의 해시를 모두 포함하는 머클화된 블록 루트에 대한 커밋먼트 필드를 추가하는 방식입니다.
후속 연구: 웜홀과 신호기 퇴적물과의 만남
비콘 예치 계약은 실행 계층에서 비콘 체인으로 가는 단방향 브리지입니다. 현재 배포된 버전에서는 각 검증자가 자신의 예치 및 출금 대상에 공개적으로 연결될 수 있습니다. 계약은 검증자의 pubkey 와 출금 자격 증명( withdrawal_credentials )과 함께 예치금을 받는 단일 deposit 기능을 제공합니다.
pubkey 와 withdrawal_credentials 해당 숨김 커밋먼트로 대체하는 비공개 버전의 계약을 설계하는 방법이 있을 수 있습니다. 그러면 예치금은 zk 지식 증명을 제공하여 비콘 체인에서 청구됩니다. 이 구조에서는 검증자가 비콘 체인에서 예치금이 청구된 후에만 활성화 대기열에 추가됩니다. 청구되지 않은 예치금은 일반 검증자와 마찬가지로 인출 대기열에 추가될 수 있습니다.
이를 위해서는 프로토콜 재설계가 필요하겠지만, 검증자 프라이버시를 크게 향상시키는 동시에 그럴듯한 부인 가능성을 가진 프로토콜 내 웜홀과 같은 메커니즘으로 작용할 수 있습니다. 더욱이, 전체 이더리움의 약 3분의 1이 스테이킹되어 있고 일일 인출액이 수천만 달러(또는 그 이상)에 달하는 상황에서, 결과적으로 확보될 수 있는 익명성 집합은 상당히 클 수 있습니다.
