크로스체인에서 다시 털리다: 제품 관점에서 본 크로스체인 분야 설계 로직의 심층 분석
저자: 0xOar
제작: Seer Labs
서론:
최근 자주 발생하는 크로스체인 보안 문제는 시장의 큰 관심을 끌고 있다. 본문은 제품 설계 관점에서 왜 이 분야의 제품들이 이렇게 많은 보안 문제를 겪는지 독자들에게 설명하고자 한다. 명시하건대, 본문에서 지적하는 문제들은 모든 프로젝트에 해당되는 것은 아니며, 대부분의 문제는 설계 단계에서 이미 대응 전략이 마련되어 있다. 주된 목적은 이 분야의 복잡성을 더 많은 사람들이 이해할 수 있도록 하는 것이다.
먼저 일반적인 크로스체인 브리지를 어떻게 설계하는지 알아보고, 그런 브리지가 직면할 수 있는 보안 문제들을 알려드리겠다.
01 만변하지만 근본은 변치 않는 크로스체인 방식
이전 보고서에서는 실제로 여러 유형의 정보 크로스체인 방식을 이미 설명한 바 있다. 최종 형태가 어떠하든 제품 설계 측면에서 보면 오직 사이드체인(광의의 사이드체인으로 본 문단에서는 롤업도 사이드체인에 포함한다. 논쟁하지 말 것), 해시 타임락(HTLC), 공증인(Public Notary) 세 가지 메커니즘뿐이다.
(일) 사이드체인
이 세 가지 방식 중 사이드체인 방식이 가장 안전하다. 예를 들어 다양한 롤업과 폴카닷의 평행체인 등이 있다.
메인체인과 사이드체인 간에 보안성이 공유된다. 그러나 사이드체인 방식은 일반적으로 원본 체인과 대상 체인이 동형인 것을 요구하기 때문에 적용 가능한 시나리오가 훨씬 적어진다. 이것이 바로 V신이 다중 체인에는 찬성하지만 크로스체인에는 반대하는 이유이며, 보안성을 공유할 수 없는 크로스체인 방식은 너무 많은 문제가 있기 때문이다.
(이) 해시 타임락(HTLC)
이 방식은 점대점(P2P) 방식으로 가장 탈중앙화된 이기종 크로스체인 솔루션이라고 일컬어지지만, 비용이 높고 사용자의 대기 시간이 길어 현재 채택률이 낮다. 또한 여전히 제3자가 환전 중개 노드 역할을 해야 하며, 보안성과 탈중앙화를 보장하기 위해所谓 중간 컨센서스 계층이 필요하다.
(삼) 공증인 메커니즘
이는 현재 가장 널리 사용되는 이기종 크로스체인 브리지 방식으로, 시장의 대부분 제품들이 거의 동일한 기원을 가지고 있으며, 제품 설계 측면에서는 거의 차이가 없다. 주요 차이점은 정보 검증 방식, 공증인의 합의 알고리즘, 위탁 지갑의 서명 알고리즘 등에 집중될 수 있다. 사용 경험과 보안성 면에서도 큰 차이는 없으며, 따라서 보안 측면에서 직면하는 리스크에도 많은 공통점이 있다.
본문은 특히 공증인 메커니즘 기반 크로스체인 브리지가 마주하는 공통적인 보안 리스크들을 집중적으로 정리하고 분석하겠다.
02 공증인 메커니즘의 제품 로직 프로세스
공증인 메커니즘이 직면하는 다양한 리스크를 이해하기 전에, 이런 유형의 솔루션이 제품 측면에서 어떤 설계 로직을 따르는지 먼저 알아야 한다.
(일) 개요
설계 철학 측면에서 보면 이 방식은 매우 간단하다. 우리가 이기종 자산의 크로스체인을 필요로 할 때 가장 직관적인 방법은 "매핑(mapping)"이다. 매핑이란 사용자 A가 ETH를 이더리움에서 팬텀(Fantom)으로 옮길 때, 자산을 실제로 이동시키거나 팬텀 상에서 다시 발행할 필요가 없다는 의미다(실제로도 불가능하다). 대신 사용자 A의 ETH를 움직일 수 없는 주소에 예치한 후, 그 주소에 예치된 사용자 A의 ETH 수량에 따라 팬텀 상에서 1:1 비율로 대응하는 매핑 자산을 발행하는 것이다. 이 매핑 자산은 이더리움 메인체인 상의 해당 ETH 사용 권한을 나타낸다. 1:1 앵커링이 되어 있으므로 팬텀 사용자들도 이 자산의 가치를 인정한다.
가장 단순화된 크로스체인 프로세스:
(이) 설계의 난점
여기에는 많은 문제가 존재하며, 그 중 가장 큰 문제는 멀티시그 지갑 관리 문제다. 왜냐하면 ETH를 이더리움에서 팬텀으로 보내는 것은 입금이고, 사용자 A가 다시 돌아가고 싶다면 출금 문제가 발생하기 때문이다.
입금과 출금의 탈중앙화 및 보안성이 가장 큰 난제가 된다.
1. 누가 돈을 관리할 것인가? 2. 누가 거래를 시작할 것인가? 3. 누가 거래를 모니터링할 것인가? 4. 실제로 사용자가 돈을 입금했는지 어떻게 확인할 것인가? 5. 사용자가 돈을 인출하려는 것이 본인의 의사인지 어떻게 확인할 것인가? 6. 리플레이 공격은 어떻게 방지할 것인가? 7. 실패한 거래는 어떻게 다시 제출할 것인가? 8. 멀티시그 관리자가 악의를 가질 경우는 어떻게 할 것인가? 9. 다운타임 발생 시는 어떻게 할 것인가?
생각조차 하기 싫다. 생각할수록 점점 복잡해진다. 크로스체인 브리지 기술은 멀티시그뿐만 아니라 자산 발행, 크로스체인 모니터링, 비동기 검증, 심지어는 독립적인 중간 컨센서스 계층(새로운 체인)을 발행해야 하는 문제까지 포함한다.
따라서 사용자들의 이해를 더욱 단순화하기 위해 전체 크로스체인 프로세스를 입금과 출금 두 부분으로 나누어 설명하겠다. 이를 통해 여러분의 이해를 돕고자 한다.
(삼) 프로세스의 추가 세분화
1. 입금
먼저 밝히건대, 아래 그림의 프로세스는 필자가 추론하여 작성한 설계 방안일 뿐이며, 철저한 검증을 거친 것은 아니다. 설계 로직 내에서 발생할 수 있는 보안 문제를 탐구하기 위한 것이며, 성숙한 솔루션으로 채택해서는 안 되며, 모두 막연한 추측이다.
위 그림에서 보듯이, 원본 체인에서 대상 체인으로의 입금 거래는 원칙적으로 다음과 같은 단계를 포함한다:
(1) 사용자가 위탁 주소로 입금
(2) 모니터링 도구가 거래를 감지한 후 BP(합의 노드이자 멀티시그 관리자)가 거래를 시작
(3) 스마트 계약이 BP 서명의 정확성을 검증
(4) 노드 허용 오차 메커니즘을 통과했는지 여부 확인
(5) 통과하지 못하면 거래를 취소하고, 통과하면 매핑 주소 관계에 따라 대상 체인 주소에 입금 처리
(6) BP가 이 입금 거래를 확인
(7) 비잔틴 장애 허용 이후 매핑 토큰을 사용자의 대상 체인 주소로 전송
주의할 점은 이 프로세스가 일반적인 이기종 크로스체인을 논의하기 위한 것이므로 anyswap 등의 방식보다 중간 컨센서스 계층에서 사용자가 주소 관계를 미리 연결하는 단계를 추가했다는 점이다. 이는 서로 다른 이기종 체인이 거래 정보를 첨부하는 방식이 다르기 때문에 통합 처리를 위해 사용자가 미리 매핑 관계를 설정하도록 한 것이다. EVM 체인들 간의 거래라면 이 단계는 필요 없고, 거래 시작 시 대상 체인 주소를 바로 첨부하면 된다.
본론으로 돌아와, 위 프로세스에서 두 번째 단계부터 각종 로직 검증 문제와 다양한 상황에서의 처리 문제가 발생함을 알 수 있다.
주요 검증 로직은 다음과 같다:
(1) 거래를 감지한 후, 자산 매핑 요청과 사용자 A의 대상 체인으로의 전송 거래를 검증
(2) 대상 체인에서의 거래 시작 및 결과 검증
내가 그린 프로세스의 검증 로직 외에도 가짜 토큰 입금 문제 검증, 그리고 서로 다른 토큰 호출 시 특수 처리가 필요하다.
향후 발생할 수 있는 보안 위험 요소를 효과적으로 정리하기 위해 먼저 출금 프로세스를 이해하자.
2. 출금
출금 프로세스는 대상 체인의 매핑 자산을 원본 체인 자산으로 교환하는 로직을 보여준다. 주목할 점은 현재 많은 토큰들이 여러 체인 버전을 가지고 있어, 많은 토큰들이 여러 체인에서 네이티브 토큰을 보유하고 있다는 것이다. 따라서 일부 브리지 프로젝트는 종종 자산 풀을 설정한다. 자금이 충분할 경우 사용자는 anyDAI와 같은 매핑 자산의 존재를 느끼지 못하게 하고, 바로 대상 체인 버전의 토큰으로 교환하게 한다. 그러나 이는 전체 로직에 영향을 주지 않는다. 분석을 계속 진행하자.
그림에서 보듯이, 대상 체인에서 원본 체인으로의 출금 거래 프로세스는 다음과 같다: (1) 사용자가 거래를 시작(등량의 매핑 자산을 대상 체인의 위탁 지갑으로 전송) (2) BP 신원 검증 후 특정 BP가 출금 요청 시작 (3) 출금 권한 및 서명 확인 (4) 비잔틴 합의 후 원본 체인에서 출금 요청 완료, 원본 체인의 위탁 지갑에서 사용자 A에게 자금 전송 (5) 중간에 노드 검증 오류나 다운타임 등 문제가 발생하면 롤백 후 다시 요청 시작
위 프로세스에서 알 수 있듯이, 여기서 주요 검증 로직은 다음과 같다: (1) 요청 시작 및 서명 권한 검증 (2) 문제 발생 시 허용 오차 메커니즘
(사) 보안 리스크
1. 설계 로직상의 보안 문제
크로스체인 브리지의 설계를 좀 더 꼼꼼히 살펴본 후, 설계 로직상 크로스체인 브리지가 직면하는 도전 과제가 매우 많음을 알 수 있다. 요약하면 주로 세 가지 문제로 나뉜다(관련 도난 사례는 각 문제 마지막에 표기).
(1) 입금
a) 입금 계약 권한 취약점으로 인해 입금된 자금이 즉시 이체되는 문제. 이는 거의 모든 계약 프로젝트가 겪는 어리석은 문제다. b) 가짜 토큰 입금 문제. 일부 프로젝트가 크로스체인 토큰의 진위를 검증하지 않아 fakeTOKEN → realTOKEN 현상 발생(anyswap). 사실 이것도 다소 어리석다. d) 가짜 토큰 입금 문제. ETH 등 네이티브 자산은 ERC20 계약과 다르며, 많은 공격이 ETH에 대한 부적절한 특수 처리로 인해 fakeETH → realETH가 발생한다. 이것이 WETH 등의 wrapped 자산이 유행하는 이유다.(thorchain) c) 서로 다른 토큰들이 모두 ERC20 표준이지만 구현 방식이나 추가 로직(rebase, fallback 등)이 달라, 개발자가 적응 시 조사를 제대로 하지 않으면 문제 발생. 예를 들어(WETH, PERI, OMT, WBNB, MATIC, AVAX)는 전송 완료 후 sender의 커스텀 fallback 함수를 호출해 추가 작업을 수행하므로 크로스체인 브리지 판단의 복잡성이 증가한다.(anyswap 2022.1.18)
(2) 크로스체인 메시지 전송
a 체인에서 입금 완료 후 b 체인 자산 수령 전까지, 크로스체인 브리지 처리는 독립된 블록체인 시스템처럼 작동하며, 일반적으로 dPoS와 같은 합의 메커니즘이 필요하다. 아래 내용은 dPoS를 가정한 경우 고려해야 할 문제들이다. 하지만 나는 모든 노드가 프로젝트 팀 소유라고 의심되며, 이는 우선적으로 중앙집중화 리스크를 의미한다. a) 입금 메시지 모니터링. 누가 크로스체인 처리 제안을 처음으로 시작할 것인가? 무작위? 순차적? 아니면 중간 컨센서스 계층의 블록 생성 순서에 따라? b) 다수의 공증인이 입금의 정확성을 어떻게 검증할 것인가? 만약 데이터 소스가 Infura 등의 데이터 제공업체에서 모두 오면 Infura는 단일 장애 지점(single point of failure)이 된다. 가장 안전한 방법은 각자가 노드를 운영하는 것이나, 비용이 매우 크다. c) 크로스체인 처리가 완료되었는지(즉 b 체인에 도착했는지) 어떻게 확인할 것인가? 미완료 상태는 여러 경우가 있다. i. 크로스체인 브리지가 처리를 시작하지 않음 ii. 크로스체인 브리지가 처리를 시작했으나 검증 및 합의가 통과되지 않음 iii. 크로스체인 브리지가 검증은 통과했으나 b 체인에서 거래를 시작하지 않음 iv. b 체인에 거래가 있으나 실패함(자금 부족 또는 기타 사유)
(3) 멀티시그 검증 문제
문제가 많이 발생하는 중점 지역으로, 대부분 코드 로직 문제다. a) 3/5 서명에서 멀티시그 목록에 없는 임의의 서명을 구성해도 +1로 계산됨(chainswap). b) 중앙집중화 문제.名义上는 멀티시그지만 실질적으로는 프로젝트 팀이 장악하고 있어 큰 중앙집중화 리스크 존재. c) 서명 검증 방법. 서로 다른 체인의 개발 모델이 달라 접속 시 개발자가 놓치는 경우가 생긴다. wormhole 사례: 솔라나에서 서명 검증 함수는 시스템 계약 내 함수인데, 정상적으로는 시스템 계약을 호출해야 하며, 시스템 계약 주소는 코드에 하드코딩되어야 한다. 그런데 이곳에서는 시스템 계약 주소를 파라미터로 입력받았고, 해커가 출금 시 가짜 시스템 계약 주소를 입력해 서명 검증을 우회하고 무사히 코인을 인출했다.
(4) 환불
a) 앞서 (2)-c에서 논의한 바와 같이, 크로스체인 상태는 다양한 가능성이 있으며, 어떤 경우라도 사용자에게 환불 방법을 제공해야 한다. 예를 들어 anyswap은 입금 시 먼저 소스 체인에서 사용자에게 anyToken을 발행한 후, 대상 체인에서도 anyToken을 발행하고, 소스 체인의 anyToken을 소각한다. 이렇게 함으로써 어느 단계에서 문제가 발생하든 사용자가 anyToken을 소지함으로써 자신의 자산을 주장할 수 있게 된다. 이 과정에는 3개의 체인(소스, 대상, 크로스체인 브리지)과 4개의 자산(소스 체인과 대상 체인의 원본 토큰/anyToken)이 개입되어 코드 로직 오류가 매우 쉽게 발생한다. b) Thorchain이 2021.7.23에 발견된 취약점으로, 해커가 코드 로직 결함을 이용해 거액의 가짜 입금을 조작했고, 크로스체인 브리지가 이를 처리하지 못해 환불 로직으로 넘어가 해커가 거액의 환불을 받았다.
2. 기타 보안 리스크
그러나 로직 프로세스를 통해 드러나는 문제는 단지 업무 로직상의 문제일 뿐이며 전부가 아니다. 보안 관점에서 우리는 또 다른 세 가지 측면의 리스크도 고려해야 한다.
(1) 시스템적 리스크
예를 들어 원본 체인의 입금이 처음엔 성공했지만 이후 롤백되는 경우. 이는 매우 큰 문제다. V신이 논의한 바 있는데, Solana에서 Ethereum으로 자산을 크로스체인한 후 크로스체인이 완료된 후 Solana가 롤백되면 사용자 자산이 두 배가 되며, 이에 대한 해결책은 전혀 없다. 그러나 이더리움과 보안성을 공유하는 롤업과 같은 L2는 이런 문제가 없다.
(2) 프론트엔드 리스크
a) 위조된 URL. 예: oxdao.fi, 0xdao.fi, oxdai.fi 등 b) XSS 공격(Cross-site Scripting): 코드 인젝션 공격의 일종. 예: www.xxxx.finance/?params=hackerscode12345. URL 자체는 공식 사이트이지만, URL에 해커의 코드가 포함되어 있다. 프론트엔드 개발자가 XSS 방지를 고려하지 않으면 이 코드가 페이지에서 실행되어 사용자가 해커에게 자금 이체 권한을 서명하게 되므로 출처가 불분명한 링크는 열지 말아야 한다. c) CORS(Cross-Origin Resource Sharing) 공격: 엄격한 동일 출처 정책(Same-Origin Policy) 하에서 브라우저는 자사 사이트의 콘텐츠만 허용한다. 즉, www.xxxx.finance 사이트에 표시되는 모든 콘텐츠와 호출하는 인터페이스는 xxxx.finance 도메인에서 와야 한다. 그러나 현재 대부분의 프로젝트는 크로스사이트 호출을 허용한다. 즉, xxxx 프론트엔드가 quickswap 인터페이스를 호출할 수 있고 그 반대도 가능하다. 이는 개발에 편의를 주지만 리스크도 가져온다. 내가 xxxx.finance를 방문해 브라우저 캐시에 민감한 데이터를 저장한 후 악성 사이트를 방문하면, xxxx의 동일 출처 정책이 제한하지 않았다면 악성 사이트가 캐시된 xxxx 데이터를 마음대로 가져갈 수 있다.
(3) 추가 기능 리스크
일부 크로스체인 브리지 프로젝트는 자산 크로스체인뿐 아니라 크로스체인 스마트 계약 호출 기능도 제공하는데, 이는 추가적인 복잡성을 초래한다. 공격자가 a 체인에서 b 체인의 x 계약 호출을 요청하면, 크로스체인 브리지는 x 계약이 무엇인지 확인하지 않고 바로 호출한다. 그런데 x 계약이 b 체인 상의 크로스체인 브리지 멀티시그 계약일 수 있고, 이 호출이 멀티시그 계정을 공격자 본인 주소로 변경하는 거래라면, 실행 성공 후 해커는 b 체인 상 크로스체인 브리지 자금을 마음대로 사용할 수 있게 된다(poly network).
03 맺음말
1. 본 보고서의 목적은 사용자가 크로스체인 브리지의 보안 리스크를 명확히 이해하도록 돕는 것이며, 크로스체인 브리지가 얼마나 쉽게 공격당하는지 부정확하게 과장하는 것이 아니다.
2. 공증인 메커니즘 기반 크로스체인 브리지 솔루션은 적어도 현재로서는 사용자 경험 면에서 가장 좋고, 적용 범위가 가장 넓으며, 비용이 가장 낮은 방식이다. 또한 어떤 제품도 상처투성이에서 성숙으로 가는 과정을 겪는다. 블록체인 제품이 당하는 공격은 대개 "논리적 문제"다. 이러한 문제들은 시간이 지나고 경험을 쌓으면서 반드시 점점 더 나아질 것이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
