Jump Crypto: LayerZero, Wormhole 등 크로스 체인 브리지의 장단점 분석

원제목：++보안 스택업: 브릿지가 어떻게 비교되는가++

원저자：Jonathan Claudius, Anirudh Suresh, Eric Wong, Akshath Sivaprasad

편집：0x9F, 0x214, BlockBeats

물리적 세계와 암호화된 세계에서 다리(브릿지)는 장애물로 분리된 두 장소를 연결하기 위해 존재합니다. 물리적 다리는 계곡, 강 등 자연 장벽으로 분리된 땅을 연결하고, 크로스 체인 브릿지 프로토콜은 원래 통신 및 동기화할 수 없는 블록체인을 연결합니다. 다리가 파괴되거나 공격을 받을 때마다 그 중요성이 드러납니다. 물리적 세계에서 역사적으로 기록된 ++재앙적인 다리 붕괴 사건++은 이들이 얼마나 중요한지, 그리고 설계나 건설이 잘못된 다리가 얼마나 위험한지를 보여줍니다.

암호화된 세계의 크로스 체인 브릿지 프로토콜도 마찬가지입니다. 크로스 체인 브릿지는 보안 위험 측면에서 쉽게 표적이 됩니다. 스마트 계약의 잠재적 취약점과 공격 규모의 관점에서 크로스 체인 브릿지는 제곱 위험 면을 나타냅니다: 브릿지된 블록체인의 수가 증가함에 따라 크로스 체인 브릿지를 운영하는 데 필요한 스마트 계약의 수 또한 제곱으로 증가합니다(최소한 피어 투 피어 모델에서는 그렇습니다). 맞춤형 구성으로 다양한 실행 시간에 작성된 더 많은 스마트 계약은 크로스 체인 브릿지의 위험을 급속히 증가시킵니다. 바퀴살 모델에서는 중심 체인/네트워크와 관련된 취약점이 비대칭 위험을 초래합니다.

최근의 ++노마드 공격 사건++에서 보듯이, 하나의 실수로 인해 브릿지의 대부분 또는 모든 자금이 손실될 수 있습니다. 그러나 취약점은 크로스 체인 브릿지와 무관할 수 있으며, 단순히 운영상의 실수에서 기인할 수 있습니다. 로닌 크로스 체인 브릿지의 경우, ++형편없는 운영 보안 조치++로 인해 피싱 공격이 발생했고, ++해커는 네트워크 보안을 위한 대부분의 검증 노드에 대한 통제권을 얻었습니다++. 이로 인해 5억 달러 이상의 자금을 가지고 도망칠 수 있었습니다. 2월에 발생한 웜홀 공격 사건도 검증 검토의 부족으로 인해 공격자가 가짜 서명을 생성하여 ++3억 2천만 달러를 훔쳤습니다++.

보안에 주의를 기울이지 않으면 더 많은 부주의가 불가피하게 발생하여 공격과 손실을 초래할 것입니다. 해커에게 크로스 체인 브릿지의 막대한 TVL은 일반 프로토콜보다 더 매력적입니다.

위의 공격 사건들은 프로토콜의 브릿지 논리와는 무관하며, 스마트 계약의 취약점과 운영상의 부주의와 관련이 있습니다. 가장 정교하게 작성된 코드와 최고의 보안 감사가 있더라도, 연결된 블록체인과 활성화된 기능의 수가 증가함에 따라 누락된 취약점이 반드시 존재할 것입니다. 이러한 이유로 크로스 체인 브릿지는 정상적인 상황에서 안전하게 작동할 수 있을 뿐만 아니라, 극단적인 상황에도 대응할 수 있도록 구성되어야 합니다.

사용자가 크로스 체인 브릿지를 사용할 때 주로 관심을 가지는 특성은 다음과 같습니다: 좋은 사용자 경험, 낮은 슬리피지와 높은 효율성, 자산의 안전성. 이 중에서 안전성은 크로스 체인 브릿지를 평가하는 데 가장 중요한 요소입니다.

이를 염두에 두고, 다양한 브릿지가 어떻게 보안을 강화하는지 살펴보겠습니다. 우리는 다음 세 가지 측면에서 논의하여 다양한 크로스 체인 브릿지의 보안을 비교할 것입니다.

1. 신뢰 가정
2. 코드 품질 보증
3. 보안 기능

앞의 두 가지는 크로스 체인 브릿지가 신뢰 계층과 소스 코드라는 두 측면에서 그 취약성/취약점의 근원을 충분히 고려했는지를 논의할 것입니다. 마지막으로, 어떤 프로토콜이 얼마나 세심하게 코딩하고 감사하더라도 취약점은 불가피하며, 이에 따라 사용자의 잠재적 손실을 최소화하기 위해 추가적인 보안 조치를 구축했는지를 다룹니다.

완전한 투명성을 유지하기 위해, 심층 논의에 들어가기 전에 Jump Crypto가 웜홀 프로젝트의 운영 관리자이며 웜홀의 핵심 기여자 중 하나임을 인정합니다. 그러나 우리는 이 글에서 가능한 한 객관적으로 평가할 것이며, 크로스 체인 브릿지 간의 차이를 자세히 보여주기 위해 이 글을 개선할 방법에 대한 피드백을 환영하고 수용합니다.

신뢰 가정

크로스 체인 브릿지는 그 핵심 구성 요소로 3개의 구성 요소로 분해될 수 있습니다:

1. 스마트 계약(Smart contract): 각 블록체인 정보를 발신/수신
2. 오라클(Oracle): 정보가 원래 체인에서 온 것인지 검증
3. 릴레이터(Relayer): 메시지를 목표 체인에 제출

실제로 크로스 체인 브릿지는 오라클에서 정보의 유효성에 대한 합의를 이루는 데 큰 차이가 있을 수 있으며, 이는 릴레이터에도 영향을 미칩니다.

우리가 심층 연구에 들어가기 전에, 이 분야에서 가장 인기 있는 브릿지에서 사용되는 합의 메커니즘에 대한 빠른 소개입니다.

Axelar

Axelar는 Cosmos PoS 네트워크를 기반으로 운영되며, 검증자는 토큰 보유자에 의해 선출되고 비례적으로 투표권을 얻습니다. 투표권의 가중치는 위임된 지분에 따라 계산됩니다. Axelar 네트워크는 (t,n) 임계값 서명 방식을 통해 크로스 체인 정보를 검증하며, 서명자의 투표권은 n으로 정규화되고, n은 t(프로토콜 임계값)보다 커야 정보를 서명할 수 있습니다. Axelar 네트워크는 현재 최대 50명의 검증자가 있으며, 메시지를 서명하기 위해 66.67% 이상의 다수 투표를 얻어야 합니다(이 두 변수는 거버넌스 투표를 통해 수정될 수 있습니다).

이론적으로 검증자의 수는 무한할 수 있지만, 실제로는 검증자가 각 블록체인에 대해 노드를 운영할 필요가 없기 때문에 투표권이 편향될 수 있습니다. Axelar의 현재 ++검증자 목록++에는 47명의 검증자가 있지만, 실제로 유효한 투표권을 가진 검증자는 20명뿐입니다. 특정 블록체인에서 이 숫자는 더 작습니다. 예를 들어, 우리가 오로라에서의 정보만 고려한다면, 메시지를 성공적으로 전송하기 위해서는 8개의 노드만 필요하고, 이 메시지를 검토하기 위해서는 4개의 노드가 필요합니다.

LayerZero

LayerZero는 블록체인 간의 신뢰 없는 통신 문제를 오라클(Oracle)과 릴레이터(Relayer)라는 두 개체 간의 독립성 문제로 단순화한 크로스 체인 상호 운용 프로토콜입니다. 오라클은 블록 헤더를 목표 체인에 전달하고, 릴레이터는 거래 증명을 목표 체인에 전달하여 두 개체가 메시지가 유효하고 정보가 실제로 원래 체인에 제출되었음을 증명합니다. 사용자 애플리케이션(UA)은 LayerZero의 기본 오라클과 릴레이터를 자유롭게 사용할 수 있으며, 자신의 오라클과 릴레이터를 생성하고 운영할 수도 있습니다.

기본 오라클은 Chainlink 탈중앙화 오라클 네트워크(DON)로, 세 명의 참여자(FTX, Polygon 및 Sequoia) 간에 임계값 서명 방식을 사용합니다. 이 글을 작성할 당시 LayerZero 코드베이스의 폐쇄성으로 인해 필자는 그 실행 상황에 대한 이해가 부족합니다. 특정 애플리케이션 버전의 오라클에 대해 LayerZero의 자체 Ackee 감사는 자신의 오라클과 릴레이터를 생성하고 운영하는 애플리케이션에 대해 유효하지 않은 거래 증명과 블록 헤더를 성공적으로 제출하는 것이 어렵지 않다고 지적했습니다. 그러나 이러한 모듈화는 실제로 이점이 있으며, 향후 어떤 취약점이 발생하더라도 영향을 받는 오라클-릴레이터 쌍을 사용하는 애플리케이션에만 영향을 미칠 것입니다.

LayerZero의 신뢰 가정은 두 개체의 행동에 따라 달라집니다. 즉, 오라클과 릴레이터가 서로 독립적으로 작동하는 한 유효하지 않은 메시지를 성공적으로 전송할 수 없습니다. 그러나 반대로, 이 시스템은 오라클과 릴레이터가 정상적으로 작동해야 정보를 검증할 수 있기 때문에, 두 개체 중 어느 한 쪽이든 정보를 임의로 삭제할 수 있습니다.

Multichain

Multichain은 이전의 Anyswap에서 파생된 크로스 체인 정보 전송 프로토콜입니다. Multichain은 안전한 다자간 계산(SMPC)을 사용하여 임계값 서명 방식을 실행하고, 공개 키를 생성하고 체인 간에 전달되는 메시지를 서명합니다. 이러한 노드는 신뢰 없는 방식으로 사용자 계정(EOA)을 제어하며, 지갑 주소는 분할된 개인 키와 일대일로 대응됩니다. 이러한 계정은 자산을 저장하고 목표 체인으로 자산을 전송하는 데 사용되며, 목표 체인은 발신자의 주소가 신뢰할 수 있는지 확인하기만 하면 되며 메시지 자체를 검증할 필요가 없습니다.

Multichain 네트워크는 현재 24개의 SMPC 노드로 구성되어 있으며, 서로 다른 기관에서 운영되고 있으며, 메시지를 공동으로 검증하기 위해 대다수 노드(「대다수」의 양적 기준은 공개되지 않은 것 같습니다)가 필요합니다. 따라서 이 프로토콜의 보안성은 SMPC 노드의 평판 보안에 의존하며, 모든 노드 중 정직한 노드가 절반 이상을 차지한다고 가정합니다. 크로스 체인 데이터 전송에는 13명의 서명자가 필요하고, 메시지 검토에는 12개의 노드가 필요합니다.

Nomad

Nomad는 EVM 중심의 크로스 체인 정보 전송 프로토콜로, 메시지를 검증하기 위해 낙관적(optimistic) 메커니즘을 사용합니다. 메시지는 머클 트리에 추가되고 해시 암호화되어 새로운 루트로 변환되며, 업데이트자(Updater)가 원래 체인에 게시합니다. 업데이트자는 보증금을 지불해야 하며, 이를 통해 유효한 증명을 게시하고 가동 중지 시간을 최소화하도록 유도합니다. 이후 관찰자(Watcher)는 새로운 루트에 대해 이의를 제기하고 사기 증명을 제출할 수 있는 시간이 주어집니다. 시간이 초과되면 이 머클 루트는 유효한 것으로 간주되어 목표 체인으로 전송되어 게시됩니다. 원래 메시지는 머클 루트가 메시지의 하나의 "화신"이기 때문에 목표 체인에 게시됩니다.

이러한 낙관적 모델은 유효하지 않은 업데이트가 게시되었는지를 검증하기 위해 최소한 하나의 정직한 관찰자가 필요합니다. 이 보안 모델의 대가는 관찰자가 사기 증명을 제출할 수 있는 약 30분의 시간이 주어지며, 이는 메시지 전송을 30분 지연시킵니다. 관찰자는 목표 계약에 가짜 사기 증명을 보내 메시지 처리를 방해할 수 있으므로, Nomad는 애플리케이션이 지정하고 허가된 관찰자 집합을 사용합니다. 프로토콜의 보안성은 최소한 하나의 정직한 관찰자가 존재할 가능성과 악의적인 행동으로 인해 업데이트자의 경제적 보안성이 감소하는 것에 기반합니다.

Nomad 스마트 계약은 ++다중 서명 거버넌스 모델++을 통해 업그레이드할 수 있으며, 5명의 서명자 중 3명이 거버넌스 변경을 실행하고 복구 관리를 처리해야 합니다.

최근의 Nomad 해킹 사건은 그 합의 메커니즘의 보안성과는 무관합니다. 이는 불행한 ++계약 구성 오류++로 인해 스마트 계약 단말에서 악의적인 행동이 발생한 것입니다.

Wormhole

Wormhole은 권위 증명(PoA) 수호자 네트워크를 오라클로 사용하고, 허가 없는 릴레이터 네트워크를 통해 크로스 체인 메시지를 전송합니다. 19명의 수호자 각각은 Wormhole이 지원하는 각 체인에 대해 전체 노드를 운영하고, 각 체인에서 Wormhole 핵심 계약이 발신하는 메시지를 청취합니다. 이러한 수호자들은 이 메시지를 검증하고 서명한 후 P2P 네트워크를 통해 서로 전달합니다. 메시지가 2/3 이상의 수호자(최소 13명)의 서명을 받으면 목표 체인으로 전송됩니다. 이 설계의 부수적인 결과는, 수호자들이 서명한 정보이기 때문에 완전히 신뢰할 수 없는 릴레이터 네트워크가 메시지를 목표 체인에 게시할 수 있다는 것입니다. 메시지 내용은 변경될 수 없으며 검열될 수 없기 때문에, 누구나 릴레이터를 운영하여 어떤 정보를 제출할 수 있습니다.

프로토콜의 보안 보장은 수호자의 평판 권위에서 비롯됩니다. Wormhole의 경우, 이는 ++Web3의 19개 주요 스테이킹 및 인프라 공급업체++로 구성된 집단입니다. 가짜 메시지에 서명하려면 13명의 수호자가 필요하며, 메시지를 검토하려면 7명의 수호자가 필요합니다. 또한 기존 수호자는 다른 수호자를 제거하거나 교체하는 투표를 할 수 있는 능력이 있습니다.

코드 품질 보증

코드 품질 보증은 체인에 코드를 배포하기 전에 완료해야 하는 작업을 의미합니다. 이는 다음과 같은 여러 측면을 포함할 수 있습니다:

1. 감사: 공개된 핵심 기능 및 새로운 기능에 대한 여러 차례의 독립적인 품질 감사
2. 보상: 취약점 공개자에게 매력적인 보상을 제공하고, 대규모 보상을 신속하게 지급할 수 있는 업계 평판
3. 테스트: 각 코드 변경에 대해 가능한 한 많은 프로토콜 스택을 테스트하여 지속적으로 성장하는 소프트웨어 생태계에서 회귀 테스트 수행
4. 배포 보안: 공개 환경에서 개발 및 코드 병합 전에 검토, 계약 바이트코드 검증, 업그레이드 전에 시뮬레이션 테스트 수행

아래 표는 다섯 개의 크로스 체인 브릿지 프로토콜이 이 네 가지 측면에서 어떻게 수행되고 있는지를 요약합니다.

Axelar

Axelar는 여러 차례 공개적이고 신뢰할 수 있는 감사를 받았으며, 상당히 강력한(최근 몇 달간 활동이 감소했지만) 테스트 스위트를 운영하고 있습니다: 지속적 통합(CI) 및 지속적 배포(CD) 실행, bash 빌드 스크립트 및 체크섬 검증. Axelar는 Immunefi와 협력하여 취약점 보상 프로그램을 설정하였으며, 심각한 취약점 공개자에게 최대 100만 달러의 보상을 제공합니다. 그러나 다른 수준의 보상 금액은 상대적으로 작습니다. Axelar 레포지토리에는 기여자가 정기적으로 코드를 제출하며, Pull Request는 최소 1명의 검토자의 승인이 필요합니다.

LayerZero

LayerZero는 코드 배포 측면에서 다소 불투명해 보입니다. 최고 감사자들로부터 몇 차례의 공개 감사가 있었지만, 공개적인 지속적 통합(CI) 및 지속적 배포(CD) 프로세스가 부족합니다. 코드는 일회성으로 공개되는 것 같으며, 민첩한 개발 프로세스가 아닙니다. 진행된 테스트는 상대적으로 구식이며 JavaScript 테스트에 국한된 것으로 보입니다. Pull Request는 강제적인 동료 검토 단계가 부족해 보입니다. LayerZero는 4월에 Immunefi와 협력하여 1500만 달러 규모의 취약점 보상 프로그램을 발표했습니다. 그러나 지금까지 관련 프로젝트는 공개되지 않았으며, 취약점을 제출하여 보상을 받는 방법에 대한 설명도 없습니다.

Multichain

Multichain은 여러 차례 공개 감사를 받았으며, Immunefi와 함께 최대 200만 달러의 보상 프로그램을 운영하고 있습니다. Multichain에서 진행된 테스트는 정체된 것으로 보이며, 일반적인 ABI 및 간단한 전송 테스트에 국한된 것 같습니다. 지속적 통합(CI) 및 지속적 배포(CD) 실행과 제한된 단위 및 통합 테스트가 있지만, 배포 과정은 주로 수동으로 이루어지는 것 같습니다. Multichain의 레포지토리에는 기여자가 정기적으로 코드를 제출하지만, 보이는 바와 같이 한 쪽에서만 코드를 병합할 수 있는 것 같습니다(원래 개발자가 자신의 코드를 병합할 수 있습니다).

Nomad

Nomad는 최근 Quantstamp의 공개 감사를 받았으며, Immunefi의 취약점 보상 프로그램이 있으며, 보상은 최대 100만 달러입니다. Nomad의 테스트 스위트에는 Foundry를 이용한 라우팅 및 메시징에 대한 테스트가 포함되어 있으며, Axelar와 마찬가지로 바쉬 빌드 스크립트를 통해 바이트코드를 빌드하고 검증합니다. Nomad의 레포지토리에는 기여자가 정기적으로 코드를 제출하며, Pull Request는 최소 두 쪽의 병합이 필요합니다(원래 개발자와 1명의 독립 검토자).

Wormhole

Wormhole의 보안 페이지는 업계 최고의 감사 회사들로부터 완료된 감사 및 진행 중인 감사가 있음을 강조합니다. Wormhole은 Immunefi에서 1000만 달러의 보상 프로그램을 운영하고 있습니다. 2월에 해킹 공격을 받은 이후, Wormhole은 1100만 달러 이상의 취약점 보상을 지급했으며, 5월에는 한 화이트 해커에게 1000만 달러를 지급했습니다. Wormhole의 레포지토리는 혼합 단위 및 통합 테스트를 사용하며, 확장 가능한 지속적 통합(CI) 및 지속적 배포(CD) 스위트를 운영하고 있으며, 업그레이드의 하위 호환성과 향후 업그레이드 능력을 검증하기 위해 일련의 시뮬레이션 테스트를 수행했습니다. 또한 Wormhole은 적극적인 제출 및 기여자를 통해 공개적인 코드 검토와 책임 있는 공개를 실현하고 있습니다. Wormhole의 Pull Request는 최소 세 쪽의 병합이 필요합니다(원래 개발자와 2명의 독립 검토자).

주의할 점은, 프로토콜의 코드 품질 보증 방식은 심각한 보안 사건을 겪은 후 크게 개선될 수 있다는 것입니다. 예를 들어, 해킹 공격을 받은 후 Wormhole의 코드 품질 보증 방식은 신속하게 개선되었습니다. 마찬가지로 이번 주의 공격 사건 이후 Nomad 프로토콜은 가까운 미래에 더 많은 코드 품질 보증 방식을 채택할 가능성이 높습니다. 사건이 발생하기 전에 이러한 관행을 채택하는 것이 가장 좋지만, 안타깝게도 이러한 관행이 항상 우선 순위 목록에 있는 것은 아닙니다.

보안 기능

앞서 언급했듯이, 크로스 체인 브릿지가 보안 문제를 겪으면 그 대가는 매우 큽니다. 위의 코드 품질 보증 조치는 크로스 체인 브릿지 공급자의 보안 계획에 필수적입니다. 본 섹션에서는 각 크로스 체인 브릿지가 개발하거나 배포 중인 프로토콜 내 보안 기능을 면밀히 살펴보아, 핵심 신뢰 가정과 코드 품질 보증이 근본적으로 부족한 상황에서 이러한 크로스 체인 브릿지가 어떻게 다층 방어를 구현하는지를 이해하고자 합니다.

Axelar

Axelar의 백서에서는 네트워크에서 할당된 자금 풀을 설명하며, 이는 거버넌스 제어의 보장 및 백업 메커니즘으로, Axelar가 중단될 경우 사용자에게 복구 거버넌스를 제공하는 지침이 됩니다. 이러한 위기 상황에서 임계값 계약(Axelar 검증자 관리)에서 보관된 "긴급 해제 키"는 보조 복구 사용자 집합과 공유됩니다. 필요할 경우 이 대기열은 수천 명의 개인 및 기관으로 확장될 수 있으며, 이들은 집단적으로 네트워크를 제어하여:

• 특정 체인으로 들어오거나 나갈 수 있는 자금의 양에 대한 속도 제한을 설정
• 체인 상의 원주율 자산의 포장 형태를 결정

이러한 기능은 현재 독점적으로 보이며, 아직 오픈 소스화되지 않았습니다. 또한 이러한 제안된 기능은 위험을 제한하기 위한 수동적 보안을 제공하지 않으며, 생사에 관한 위기 상황에서 활성화됩니다.

LayerZero

LayerZero의 브릿지 모델은 거래 애플리케이션이 목표 체인에서 릴레이터를 선택해야 하는 요구 사항을 포함합니다. 따라서 이 모델에서 프로토콜 내 보안 기능의 핵심은 릴레이터에 있습니다.

4월에 LayerZero 팀은 그들의 프로토콜 내 보안 기능 접근 방식을 "돔(the dome)"과 "사전 범죄(pre-crime)"라고 소개했습니다. 돔 기능에 대한 공개 정보는 거의 없지만, 블로그 게시물에서는 사전 범죄가 어떻게 작동하는지에 대한 단서를 제공합니다. 사전 범죄 모델은 기본적으로 사용자 애플리케이션(UA)이 특정 상태 집합을 정의할 수 있게 하며, 릴레이터는 이러한 상태를 기반으로 검증해야 합니다. 이러한 상태가 검증되지 않으면 릴레이터는 거래를 중계하지 않습니다.

주의할 점은 이러한 기능이 현재 독점적으로 보이며, 아직 오픈 소스화되지 않았습니다. 개념적으로 매우 강력하지만, 그 유효성을 독립적으로 평가하기는 어렵습니다.

Multichain

Multichain은 최근의 한 기사에서 그들의 일부 보안 조치를 공개했으며, 그들의 브릿지 구성의 일부 보안 기능을 언급했습니다:

1. 거래량 제한 및 총 거래액 제한: 이 기능은 거래량이 많은 블록체인이 특정 한도 내에서 제한될 수 있도록 합니다. 또한 거래량이 적은 블록체인에 대해서는 총 거래액 제한 방식이 적용됩니다.
2. 체인 상 모니터링: 이 모델은 비정상적인 행동을 감지하고 긴급 사건 대응 행동을 촉발하기 위해 소프트웨어와 체인 상의 감시자를 모니터링하는 것을 포함합니다.
3. 제품 중단: 이 기능은 모든 제품을 중단할 수 있으며, 긴급 사건 대응 행동을 시행할 때 모든 제품을 효과적으로 중단할 수 있습니다.
4. 보안 기금: 이는 사실상 보장 기금으로, 모든 크로스 체인 수수료의 10%를 사용하여 특별한 상황에서 사용자의 재산 손실을 보상합니다.

Nomad

Nomad는 낙관적 검증 모델을 활용하여 메시지가 원래 체인에서 서명되고, 목표 체인에서 강제로 시행되는 내장된 시간 창이 있습니다. 어느 정도, 우리는 이것이 "이 시간 이전에 이 편지를 열지 마십시오"와 유사하다고 볼 수 있습니다. 이 시간은 "자동 회로 차단기"를 시행하고 머클 루트가 유효하다고 간주되기 전에 자산 전송을 중단하는 데 유용합니다. 이는 Nomad 문서에서 개념으로 나타났으며, 개발이 진행 중인 것으로 보입니다.

Wormhole의 메시지 전송 모델은 멀티캐스트(multi-cast)로, 메시지가 수호자/오라클 네트워크에 의해 원래 체인에서 공증되며, 목표 체인으로 메시지를 전달하는 릴레이터를 신뢰하지 않습니다. 이 모델은 기본적으로 매우 강력한 오라클 네트워크가 필요하며, 프로토콜 내 보안 기능은 이에 의존합니다.

Wormhole 프로젝트는 현재 세 가지 주요 프로토콜 내 보안 기능을 개발 중입니다: 규제, 회계 및 긴급 종료. 이러한 기능은 공개적으로 개발되고 있으며, 이로 인해 이들이 최종적으로 어떻게 작동할지에 대한 깊은 통찰을 제공합니다. 이러한 기능은 개발 완료를 기다리고 있으며 수호자에 의해 채택될 것입니다.

1. 규제: 이 기능은 수호자/오라클에서 구현되며, 수호자가 규제된 체인에서 가치 흐름의 명목 금액을 모니터링할 수 있게 합니다. 수호자는 각 체인에 대해 수용 가능한 한도를 설정할 수 있으며, 이 한도에 도달하면 해당 체인의 자산 흐름을 차단합니다.
2. 회계: 이 기능은 수호자/오라클에서 구현되며, 수호자가 서로 다른 체인 간의 크로스 체인 장부 역할을 할 수 있는 자신의 블록체인(일명 "웜체인")을 유지할 수 있게 합니다. 이 장부는 수호자가 체인 상의 검증자로 활동할 수 있게 할 뿐만 아니라 회계 플러그인 역할도 합니다. 수호자는 원래 체인에 충분한 자금이 없는 경우(검증은 스마트 계약 논리 외부에서 이루어짐) 크로스 체인 거래를 거부할 수 있습니다.
3. 종료: 이 기능은 체인 상에서 구현되며, 수호자가 크로스 체인 브릿지에 위협이 존재한다고 인식할 경우 합의에 의해 크로스 체인 브릿지에서 자산 흐름을 일시적으로 중단할 수 있게 합니다. 현재의 구현 방안은 제안된 구현 방안의 체인 상 함수 호출을 통해 이루어집니다.

결론

앞으로 몇 개월 또는 몇 년 안에, 우리는 보안이 크로스 체인 브릿지 간의 격차를 확대하는 요소가 될 것이라고 믿습니다. 보안을 우선시하는 크로스 체인 브릿지는 위기를 극복할 가능성이 더 높으며, 그렇지 않은 크로스 체인 브릿지는 생존하기 어려울 것입니다. 보안성은 과거에 경쟁 우위의 원천이었을 수 있지만, 이제는 모든 크로스 체인 브릿지가 우선적으로 고려해야 할 주요 기능이 되어야 합니다. 우리는 모든 크로스 체인 브릿지가 단결하여 크로스 체인 브릿지의 보안 기술 수준을 함께 향상시키기를 바랍니다.