머리말:

머리말:

최근 자주 발생하는 교차 체인 보안 문제는 시장의 광범위한 관심을 끌었습니다.이 기사는 제품 디자인의 관점에서 시작하여 독자들에게 왜 이 트랙에 많은 제품 보안 문제가 있는지 설명하고자 합니다. 기사에서 지적한 문제가 모든 프로젝트에 존재하는 것은 아니라는 점을 선언해야 합니다.대부분의 문제는 관련 대처 전략으로 설계되었습니다.주된 목적은 더 많은 사람들이 이 트랙의 복잡성을 이해할 수 있기를 바라는 것입니다.

보조 제목

01. 끊임없이 변화하는 크로스체인 솔루션

이전 연구 보고서는 실제로 여러 유형의 정보 크로스 체인 솔루션을 모든 사람에게 설명했습니다 최종 프레젠테이션이 무엇이든 제품 디자인의 관점에서 볼 때 사이드 체인 (본문에서 넓은 의미의 사이드 체인) 말하기 롤업의 경우에도 사이드 체인, 해시 시간 잠금 및 공증의 세 가지 메커니즘으로 요약할 수 있습니다.

(1) 사이드 체인

세 가지 방식 중 사이드체인 방식은 다양한 롤업과 폴카닷 파라체인 등 보안성이 가장 높다. 보안은 메인 체인과 사이드 체인 간에 공유됩니다. 그러나 사이드체인 체계는 일반적으로 원래 체인과 대상 체인이 동형이어야 하므로 적용 가능한 시나리오가 훨씬 적습니다. 비탈릭이 크로스체인이 아닌 멀티체인에 동의하는 이유이기도 합니다. 크로스체인 솔루션은 보안을 공유할 수 없는 문제가 너무 많기 때문입니다.

(2) 해시 시간 잠금

이 솔루션은 가장 탈중앙화된 P2P 이종 교차 체인 솔루션이라고 주장하지만 비용이 높고 사용자 대기 시간이 너무 길어 현재 채택률이 높지 않습니다. 그리고 통화 교환을 위한 중간 노드 역할을 할 제3자가 여전히 필요한 경우 보안 및 분산 요구 사항을 충족하기 위해 소위 중간 합의 레이어가 필요합니다.

(3) 공증 기구

현재 가장 보편적으로 사용되는 이기종 크로스체인 브릿지 솔루션으로 시중의 대부분의 제품은 기본적으로 동일한 원산지이며 제품 디자인의 관점에서 거의 차이가 없습니다. 주요 차이점은 정보 확인 방법 및 단계, 공증인의 합의 알고리즘, 에스크로 지갑의 서명 알고리즘 등에 중점을 둘 수 있습니다. 사용자 경험과 안전 측면에서 큰 차이는 없습니다. 따라서 보안 관점에서 볼 때 직면한 보안 위험에는 많은 공통 기능이 있습니다.

보조 제목

02. 공증 메커니즘의 제품 논리 흐름

공증 메커니즘이 직면한 다양한 위험을 이해하기 전에 제품 관점에서 이러한 유형의 솔루션의 설계 논리를 이해해야 합니다.

(1) 간략한 소개

이미지 설명

가장 단순화된 크로스 체인 프로세스

(2) 디자인의 어려움

이것에 많은 문제가 있을 텐데, 가장 큰 문제는 다중서명 지갑의 관리인데, 이더리움에서 팬텀으로 넘어가는 ETH가 예치금이기 때문에 사용자 A가 크로스백을 원하면 코인을 인출하는 문제가 수반됩니다.

입출금의 탈 중앙화와 보안이 가장 큰 어려움이되었습니다.

1. 누가 돈을 관리할 것인가? 2. 누가 시작합니까? 3. 누가 트랜잭션을 모니터링합니까? 4. 사용자가 돈을 송금했는지 확인하는 방법은 무엇입니까? 5. 사용자의 돈이 실제로 사용자가 인출하려는 돈인지 확인하는 방법은 무엇입니까? 6. 재생 공격을 방지하는 방법은 무엇입니까? 7. 실패한 거래를 다시 제출하는 방법은 무엇입니까? 8. 다중 서명 관리자가 악행을 저지르면 어떻게 해야 합니까? 9. 가동 중지 시간이 있으면 어떻게 해야 합니까?

감히 생각하지 못하고 생각하면 할수록 더 복잡하게 느껴진다. 크로스 체인 브리지 기술은 다중 서명을 포함할 뿐만 아니라 자산 발행, 크로스 체인 모니터링, 비동기 검증을 포함하며 독립적인 중간 합의 레이어(새로운 체인)를 발행해야 합니다.

따라서 사용자가 이해하기 어려운 부분을 더욱 단순화하기 위해 전체 크로스체인 프로세스를 입금과 출금의 두 부분으로 나누어 설명하겠습니다. 이해를 돕기 위해.

(3) 프로세스의 추가 개선

1. 입금

우선 아래 그림에 그려진 과정은 신중한 논증 없이 저만의 추론한 설계안임을 선언합니다 그 목적은 설계 논리에서 발생할 수 있는 보안 문제를 탐색하는 것이며 확정된 계획으로 채택될 수 없습니다. 모든 헛소리.

그림에서 볼 수 있듯이 원래 체인에서 대상 체인으로의 입금 트랜잭션에는 원칙적으로 다음 단계가 포함됩니다.

(1) 사용자는 호스팅 주소로 충전

(2) 리스너가 트랜잭션을 모니터링한 후 BP(합의 노드는 다중 서명 관리자이기도 함)가 트랜잭션을 시작합니다.

(3) 계약은 BP 서명의 정확성을 확인합니다.

(4) 노드 내결함성 메커니즘이 있는지 여부

(5) 콜백이 없으면 매핑된 주소의 관계에 따라 대상 체인 주소를 충전합니다.

(6) BP는 충전 거래를 확인합니다.

(7) Byzantium을 통과한 후 매핑 토큰을 대상 체인의 사용자 주소로 전송

이 프로세스는 일반적인 이기종 교차 체인을 논의하는 것을 목표로 하므로 anyswap 및 기타 솔루션과 비교할 때 사용자가 중간 합의 레이어에서 주소 관계를 바인딩할 수 있도록 추가 단계가 추가됩니다. 이것은 주로 서로 다른 이기종 체인 트랜잭션에 정보를 첨부하는 방식이 다르기 때문입니다. EVM 체인에서 트랜잭션을 처리하는 경우 이 단계가 필요하지 않으며 트랜잭션을 시작할 때 대상 체인의 주소를 첨부하기만 하면 됩니다.

주제로 돌아가서 두 번째 단계부터 시작하여 다양한 상황에서 다양한 논리 검증 문제 및 처리 문제가 발생한다는 것을 위의 프로세스에서 볼 수 있습니다.

주요 확인 논리에는 다음이 포함됩니다.

(1) 트랜잭션 청취 후 자산 매핑이 시작되어 사용자 A의 대상 체인 트랜잭션으로 전송되었는지 확인

(2) 대상 체인 거래 개시 및 거래 결과 검증 물론 내 프로세스에서 도출한 검증 로직 외에 위조화폐 충전 문제 검증, 서로 다른 통화 시 수행해야 하는 특수 처리 문제도 포함되어야 합니다. 토큰. 앞으로 발생할 수 있는 잠재적인 안전 위험을 더 잘 요약하기 위해 코인을 인출하는 과정을 계속 이해해 봅시다.

2. 코인 출금

코인 인출에 의해 입증된 프로세스는 대상 체인 자산을 원래 체인 자산으로 다시 교환하는 논리입니다.현재 많은 토큰이 여러 체인 버전을 가지고 있다는 점에 유의하는 것이 중요합니다. 따라서 일부 브리지 프로젝트는 종종 자산 풀을 설정합니다. 충분한 자금 풀의 경우 사용자는 anyDAI와 같은 매핑된 자산의 존재를 느끼지 않고 대상 체인 버전의 토큰으로 직접 대체하지만 이는 전체 논리에 영향을 미치지 않습니다. 따라서 분석은 계속됩니다.

그림과 같이 대상 체인에서 원본 체인으로의 트랜잭션 프로세스는 다음과 같습니다. (1) 사용자가 트랜잭션을 시작합니다. ) BP의 신원 확인 BP는 코인 출금 ​​요청 개시 (3) 코인 출금 ​​권한 확인 및 서명 (4) 비잔티움 통과 후 원래 체인에서 코인 출금 ​​요청 완료, 에스크로 지갑에서 자금 이체 사용자 A(5)에게 원래 체인의 중간에 노드가 있는 경우 검증 오류 또는 다운타임과 같은 문제를 롤백하고 다시 시작해야 합니다.위 프로세스에서 주요 검증 로직이 관련되어 있음을 알 수 있습니다. (1) 시작 및 서명 권한 확인 (2) 문제 발생 후 내결함성 메커니즘

(4) 보안 위험

1. 디자인 로직의 보안 문제

교차 체인 브리지의 설계를 보다 자세히 이해한 후 교차 체인 브리지의 설계 논리에 많은 문제가 있음을 알 수 있습니다.요약하면 세 가지 주요 문제가 있습니다(관련 도난 사례는 다음에 표시됩니다. 질문 끝)

(1) 보증금

a) 코인 충전 계약의 권한에 허점이 있어 충전된 금액이 직접 이체됩니다. 이것은 거의 모든 계약 프로젝트가 직면하게 될 어리석은 문제입니다. b) 위조 통화 재충전 문제, 일부 프로젝트는 크로스 체인 토큰의 진위를 확인하지 않았으며 결과적으로 fakeTOKEN -> realTOKEN(anyswap), 솔직히 말하면, 이것은 또한 약간 바보입니다. d) 위조 통화 충전, ETH 및 기타 고유 자산의 문제는 ERC20 계약과 다르며 많은 공격이 ETH의 부적절한 취급으로 인해 가짜 ETH -> realETH로 이어져 WETH와 같은 래핑된 자산이 인기 있는 이유입니다. (thorchain) c) 서로 다른 토큰은 모두 ERC20 표준이지만 구체적인 구현 방법이 다르거나 추가 로직(rebase, fallback 등)이 있지만 개발자가 적응할 때 ( WETH, PERI, OMT, WBNB, MATIC, AVAX) 등은 전송 완료 후 추가 작업을 수행하기 위해 발신자의 사용자 지정 폴백 기능을 호출하므로 교차 체인 브리지 판단의 복잡성이 증가합니다(anyswap 2022.1.18).

(2) 크로스체인 메시지 전송

체인 a의 코인 재충전이 완료된 후 체인 b의 자산이 계정에 도착하기 전에 교차 체인 브리지는 독립적인 블록체인 시스템처럼 처리되며 일반적으로 dpos를 사용하는 합의 메커니즘이 필요하며 다음은 모두 다음과 같습니다. dpos를 사용한다고 가정하고 고려해야 할 문제가 있지만 모든 노드가 프로젝트 측에 속해 있고 애초에 중앙 집중화의 위험이 있다고 의심됩니다. a) 코인 입금 메시지를 모니터링하기 위해 누가 가장 먼저 크로스 체인 처리 제안을 무작위로 시작합니까? 아니면 차례대로? 아니면 중간 합의 레이어에서 생성된 블록의 순서에 따라? b) 여러 공증인이 예금의 정확성을 어떻게 확인합니까 데이터 소스가 모두 infura와 같은 데이터 제공자로부터 온 경우 infura는 단일 위험 지점입니다.가장 안전한 것은 비용이 많이 드는 자체 노드를 유지하는 것입니다. c) 교차 체인 처리가 완료되었는지 확인하는 방법(b가 적립됨), 처리되지 않은 몇 가지 상황이 있습니다. i. 교차 체인 브리지가 처리를 시작하지 않았습니다. ii. 교차 체인 브리지가 처리를 시작했습니다. , 그러나 검증 및 합의가 통과되지 않음 iii. 브리지 검증이 통과되었지만 b-chain에서 트랜잭션이 시작되지 않음 iv. b-chain에 트랜잭션이 있지만 실패(자금 부족 또는 기타 상황)

(3) 다중 서명 검증 문제

문제가 자주 발생하는 가장 어려운 영역은 대부분 코드 논리 문제입니다. b) 명목상 다중 서명인 중앙 집중화 문제는 실제로 프로젝트 당사자의 손에 달려 있으며 중앙 집중화의 큰 위험이 있습니다. c) 서명 확인 방법, 다른 체인의 개발 모델이 다르기 때문에 불가피한 누락이 발생합니다. 개발자 접속시, 웜홀 예시: solana의 검증 서명 기능은 시스템 컨트랙트에 있는 기능입니다. 여기에 시스템 컨트랙트를 매개변수로 해커 코인 출금 ​​시 가짜 시스템 컨트랙트 주소를 통과해 서명 검증을 우회해 원활하게 코인을 출금했다.

(4) 환불

a) (2)-c에서 논의한 바와 같이 크로스체인 상태에 대한 많은 가능성이 있으며, 어떠한 경우에도 사용자에게 환불 방법을 제공할 필요가 있습니다. 그런 다음 대상 체인의 사용자에게 anyToken을 보낸 다음 소스 체인의 anyToken을 소각합니다.이 목적은 어디에 문제가 있든 사용자가 anyToken을 보유함으로써 자신이 보유한 자산을 나타낼 수 있다는 것입니다. 이 프로세스에는 3개의 체인(소스, 대상, 교차 체인 브리지)과 4개의 자산(소스 체인 및 대상 체인의 원본 토큰/anyToken)이 있으며 코드 논리 문제가 발생하기 쉽습니다. b) Thorchain은 2021년 7월 23일에 유출되었습니다.해커는 코드 논리 문제를 사용하여 엄청난 양의 가짜 충전을 구성했습니다.크로스체인 브리지가 이를 처리할 수 없어 환불 논리에 들어가 해커가 막대한 환불을 받았습니다.

2. 기타 보안 위험

하지만 논리적인 과정을 통해 보여질 수 있는 문제는 비즈니스 로직 문제일 뿐 전부는 아니다. 보안 관점에서 세 가지 다른 위험도 고려해야 합니다.

(1) 시스템 리스크

예를 들어 원래 체인의 입금이 초기에 성공적이었다가 다시 롤백되는게 큰 문제인데 V God이 자산을 솔라나에서 이더리움으로 옮기는 것에 대해 논의했습니다.솔루션. 그러나 예를 들어 롤업과 같이 이더리움과 보안을 공유하는 레이어 2는 이러한 문제가 없을 것입니다.

(2) 프런트 엔드 위험

a) oxdao.fi 0xdao.fi oxdai.fi 등과 같은 위조된 URL b) Xss 공격, 즉 Cross-Site Scripting 공격은 www.xxxx.finance/?params=와 같은 코드 인젝션 공격입니다. hackerscode12345, URL은 참으로 공식 웹사이트이지만 웹사이트에는 해커의 코드가 포함되어 있습니다. 프론트 엔드 개발이 xss를 방지하는 데 주의를 기울이지 않으면 이 코드가 페이지에서 실행되어 사용자가 해커의 이체 트랜잭션 서명을 승인하므로 출처를 알 수 없는 링크를 열지 마십시오. c) Cors 사이트 간 서비스 공격 엄격한 동일 출처 정책에 따라 브라우저는 이 사이트의 콘텐츠만 로드할 수 있습니다. .Finance 도메인네임이지만 현재 대부분의 프로젝트는 cross-site call을 허용하는데, 즉 xxxx의 프론트엔드에서 quickswap 인터페이스를 호출할 수 있고, 그 반대의 경우도 가능하여 개발에 편리함을 가져다주지만 위험성도 함께 내포하고 있습니다. xxxx.finance는 브라우저 캐시에 민감한 데이터를 저장한 후 악성 웹사이트를 방문했는데 xxxx의 동일 출처 정책이 제한되지 않으면 이 악성 웹사이트는 xxxx의 캐시에 저장된 데이터를 자유롭게 얻을 수 있습니다.

(3) 추가 기능의 위험성

보조 제목

03. 에필로그

1. 이 보고서의 목적은 사용자가 크로스체인 브리지의 보안 위험을 보다 명확하게 이해하도록 돕는 것이며, 크로스체인 브리지가 얼마나 취약한 공격을 받는지에 대한 악의적인 렌더링이 아닙니다.

2. 공증 메커니즘의 크로스 체인 브리지 솔루션은 적어도 현재로서는 최고의 경험, 가장 넓은 적용 범위 및 가장 저렴한 비용을 가진 솔루션입니다. 그리고 어떤 제품이든 상흔에서 성숙으로 가는 과정을 거치게 되며, 블록체인 제품에 대한 공격은 종종 "논리적 문제"입니다. 이러한 질문은 시간과 경험이 쌓이면 나아질 수밖에 없습니다.

QR 코드를 스캔하여 커뮤니티에 가입하세요. 제품 문제, @0xOar에 대해 토론하려면 Jackson의 개인 Twitter를 팔로우하세요.

SeerLabs 정보:

SeerLabs(Prophet Labs)는 블록체인 시장 인큐베이션에 중점을 둔 아시아 최고의 기관입니다.저희는 글로벌 최첨단 마케팅 개념과 그로스 해커를 보유하고 있으며 프로젝트 당사자와 스타트업이 번개처럼 빠른 성장을 이룰 수 있도록 돕기 위해 최선을 다하고 있습니다. Ploygon(MATIC), HoDooi.com, DIA, Paralink, Swingby, XEND Finance, BOSON 등 30개 이상의 프로젝트 인큐베이션에 성공적으로 참여

우리와 함께:

트위터: https://twitter.com/seerlabs_crypto

제품 커뮤니케이션: https://twitter.com/0xOar

협력 이메일: sharon@seerlabs.io

위험 경고: 디지털 자산은 고위험 투자 대상이므로 일반 대중은 블록체인을 합리적으로 보고 위험 인식을 높이고 올바른 통화 개념 및 투자 개념을 확립하도록 요청합니다.