범용메시징브릿지(Arbitrary Messaging Bridge) 톺아보기 - 下

*번역 Lani Oh(elcreto) | 범용메시징브릿지(上) | 영문보기

 

 

 

 

 

멀티체인 애니콜(Multichain’s anyCall)

개요

애니콜(anyCall)은 멀티체인(Multichain)이 SMPC (Secure Multi-Party Computation•안전한 다자간 연산) 네트워크를 기반으로 트랜잭션 서명, 이종체인간 메시지 및 컨트랙트콜 전송을 위해 구축한 범용(Generic) 크로스체인 메시징 프로토콜입니다. 개발팀은 애니콜이 디앱 설계의 진화를 이끌 것으로 기대하고 있습니다.

2022년 1월, 멀티체인 유동성 풀 컨트랙트와 라우터 컨트랙트에서 치명적 취약점이 공격에 악용돼 사용자 자금 300만 달러가 손실되는 사고가 발생했습니다. 화이트햇 해커들과의 긴밀한 협력 끝에 도난자금의 약 50%는 회수되었습니다.

멀티체인의 브랜드와 경험을 크로스체인 메시징으로 확장하는 애니콜의 주요 기능은 다음과 같습니다:

1) 쉬운 통합 – 애니콜은 쉽고 빠르게 통합할 수 있기 때문에 개발자는 크게 리소스를 투입하지 않고도 크로스체인 전송을 위한 비즈니스 로직을 디앱에 추가할 수 있습니다.

2) 체인 간 임의데이터 전송 - 애니콜은 단 한 번의 트랜잭션으로 스마트컨트랙트, 메시지, 토큰, NFT, 데이터 등 다양한 임의의 데이터를 이종체인간 송수신할 수 있습니다.

3) UX 개선 - 애니콜은 한 번의 컨트랙트 호출로 여러 기능(브리징, 스와핑 등)을 수행할 수 있습니다. 결과적으로 사용자가 거쳐야 하는 단계가 줄어들어 디앱의 UX가 크게 개선됩니다.

4) 크로스체인 컨트랙트 호출 - 이 기능을 사용하면 소스체인에서 직접 목적지체인의 컨트랙트를 호출할 수 있습니다. 애니콜은 체인 간 상태, 데이터, 메시지 등 정보 공유와 같은 모든 유형의 크로스체인 커뮤니케이션에 사용될 수 있습니다.

또한 애니콜은 다음과 같은 네트워크 효과를 창출하고 있습니다:

1) 멀티체인 생태계와의 연결 - 멀티체인은 가장 널리 사용되는 브리징 솔루션 중 하나입니다. 사용자는 EVM 및 비EVM 체인 포함 60개 이상의 블록체인에서 1600개 이상의 토큰을 브리징할 수 있습니다.

2) 멀티체인의 브리징 거래량 및 TVL - 멀티체인은 현재까지 총 860억 달러 이상의 브리징 거래량을 기록했으며, 고점에서는 100억 달러가 넘는 TVL을 기록하기도 했습니다. 매일 3,000명 이상의 일일활성유저(DAU)로부터 브릿지된 5,000만 달러 이상의 거래를 처리하고 있습니다.

3) 네트워크 연결성 - 2022년 9월 현재 애니콜은 11개 체인을 대상으로 임의 메시지 전달과 크로스체인 컨트랙트 호출을 지원합니다. (BNB 체인, 폴리곤, 이더리움, 옵티미즘, 노시스, 팬텀, 문리버, IoTeX, 아비트럼, 아발란체, 하모니)

4) 애니콜을 프로토콜단에 통합시킨 프로젝트들 – 커브(Curve)는 게이지(Gauge) 멀티체인 지원을 위해, 헌드레드파이낸스(Hundred Finance)는 균일한 보상 분배를 위해, 파이버(Fiver)는 스테이블코인 결제를 통한 가스토큰 획득을 위해, 팬텀애니멀(Fantom Animals)은 옴니체인 NFT 제공을 위해 애니콜을 프로토콜에 통합시켰습니다.

5) MULTI 토큰 - MULTI는 시가총액 약 1억 달러에 달하는 상위 300대 토큰입니다.

작동 방식 - 트랜잭션 라이프사이클

애니콜의 아키텍처는 하위레이어와 상위레이어로 나눌 수 있습니다. 하위레이어는 오프체인 신뢰매커니즘으로 구성되며, 상위레이어는 온체인 호출 및 트리거 API로 구성됩니다.

하위레이어의 오프체인 신뢰매커니즘은 소스체인의 메시지 검증을 담당합니다. 디앱이 지정한 로직에 따라 목적지체인의 정확한 주소를 확인후 필요한 작업을 트리거합니다. 상위레이어는 소스체인의 트리거 API와 목적지체인의 호출 API로 구성됩니다. 소스체인의 API가 트리거되면 오프체인 신뢰매커니즘이 합의를 위한 검증을 시작하고, 이후 목적지체인의 호출 API가 디앱이 지정한 대로 컨트랙트 호출을 완료합니다.

애니콜은 다음과 같이 함수와 컨트랙트를 통해 체인 간 메시지를 전송합니다:

• 1단계 anyCall 함수 - anyCall 함수는 소스체인에 존재하며, 목적지체인으로 전송될 데이터를 저장합니다. anyCall 컨트랙트는 메시지를 검증하고 목적지체인으로 전달합니다.
• 2단계 멀티체인(Multichain)의 MPC 네트워크 - MPC 네트워크는 24개 노드로 구성되어 있으며, anyCall 함수에 의해 anyCall 컨트랙트로 전송된 메시지의 유효성을 검사합니다. 지원되는 모든 체인에는 anyCall 컨트랙트가 존재하며 하나의 MPC 주소를 공유합니다. anyCall 함수에 의해 메시지가 전송되면, MPC 노드는 메시지를 목적지체인으로 보내기에 앞서 메시지의 보안을 확인합니다.
• 3단계 anyExec 함수 - anyExec 함수는 anyCall 컨트랙트로부터 메시지를 수신하고 목적지체인에서 요청을 실행합니다.

보안

애니콜은 다음과 같은 보안 기능을 제공합니다.

1) 멀티체인의 MPC 네트워크 - 애니콜은 멀티체인의 다자간연산노드(Multi-Party Computation)에 의존하여 여러 체인의 정보를 확인합니다. MPC 네트워크는 시스템 보안을 위해 하나의 개인키를 여러 노드로 쪼개서 암호화하는 방식을 채택하고 있습니다. 즉, 체인 간 자산 이동을 승인하기 위해 미리 정해진 만큼의 서명을 실행하는 노드들로 이루어진 분산화된 매커니즘입니다.

2) 외부보안업체의 기술감사 - 멀티체인은 보안업체를 통해 세부적인 보안감사를 실시합니다. 애니콜팀은 BlockSec을 통해 구버전과 신버전 애니콜에 대해 두 차례 감사를 실시했습니다(두 버전 모두 현재 라이브 상태).

3) 공개 버그 바운티 - 멀티체인은 Immunefi에서 가장 큰 규모의 버그 바운티를 운영 중이며, 시스템의 취약점을 발견하면 최대 2백만 달러의 보상을 제공합니다. 멀티체인은 또한 화이트햇 해커들이 잠재취약점을 찾을 수 있도록 다른 버그바운티 플랫폼에서도 활발히 활동하고 있습니다.

4) 거래 한도 – 멀티체인은 자금의 안전을 확보하기 위해 거래금액에 비례하는 지연인출제를 채택했습니다. 이를 통해 멀티체인은 거래를 검증 하기 위해 충분한 시간을 확보할 수 있습니다.

5) 신규체인에 대한 총거래량 제한 - 상대적으로 보안성이 낮은 신규체인에는 브리징할 수 있는 총거래량이 제한됩니다(일정기간동안). 해킹 발생 시, 도난의 여파가 다른 체인으로 확대되는 것을 방지할 수 있습니다(예: 하모니 1억 달러 해킹).

6) 보안기금(Insurance Fund) - 멀티체인에는 모든 트랜잭션 수수료의 10%가 예치되는 보험기금이 있습니다. 이 기금은 특정 조건 하에 사용자 손실을 구제하기 위해 사용될 수 있습니다.

신뢰 가정

애니콜의 신뢰가정은 다음과 같습니다:

1) MPC 네트워크에 의한 외부검증 – 애니콜의 모든 전송은 24개 검증노드로 이루어진 MPC 네트워크가 검증합니다. 따라서 노드들이 정직하게 행동하고, 메시지와 전송을 정확하게 검증할 것이라는 사용자들의 신뢰가 필요한 반면, ½ 또는 13개의 노드가 공모하면 사용자 자금 유출로 이어질 수 있습니다.

2) 노드 평판의 중요성 - 애니콜 보안의 상당 부분은 MPC 네트워크를 구성하는 노드들의 평판에 달려있습니다. 기본적으로 애니콜은 노드들이 사용자 자금 탈취를 위해 악의적으로 행동하고 공모해서 얻을 수 있는 잠재이익보다 평판비용이 더 클 것이라고 가정합니다.

3) 검열리스크 - 12개의 MPC 노드가 담합하면 애니콜을 통해 메시지를 검열할 수 있습니다.

커뮤니티 및 리소스

멀티체인 애니콜에 대한 더 자세한 내용과 커뮤니티의 최신정보는 아래의 링크를 통해 확인하실 수 있습니다:

·         Official Website

·         Docs

·         Whitepaper

·         Github

·         Analytics Dashboard

·         Medium

·         Twitter

·         Telegram

하이퍼레인(Hyperlane)

개요

하이퍼레인(구. Abacus)은 범용(Generalized) 인터체인 메시징 프로토콜로서 이종체인 간 메시지 송수신을 위한 온체인 API를 제공합니다. 하이퍼레인은 체인 간 데이터 전송과 네이티브 크로스체인(프로토콜단에 크로스체인 기능이 내재화되어있는) 애플리케이션 개발을 돕는 툴입니다. API를 통한 데이터 전송에 특화된 프로토콜이라는 점, 디앱들이 유연하게 애플리케이션별로 검증자를 설정할 수 있다는 점. 이 2가지가 하이퍼레인을 차별화하는 핵심요소들입니다.

하이퍼레인의 핵심기능은 다음과 같습니다:

1) 손쉬운 API 통합 - 하이퍼레인은 디앱에 통합하여 이종체인 간 메시지를 주고받을 수 있는 온체인 API를 제공합니다. 팀에 따르면 개발자는 간단한 인터체인 메시지를 5분 이내에 기설정된 스마트 컨트랙트에 전송할 수 있습니다.

2) 애플리케이션별 검증자세트로 로컬보안 가능 - 애플리케이션은 보안을 위해 하이퍼레인의 PoS 프로토콜 외에 추가적으로 자체 검증자세트를 채택할 수 있습니다.

3) 메시지 추적 가능 - 애플리케이션은 메시지가 목적지체인에서 처리되는 동안 인터체인 메시지를 추적하고 필요한 작업을 수행할 수 있습니다. 하이퍼레인 팀은 가까운 시일 내에 인터체인 메시지 탐색기(Interchain Message Explorer)를 추가하여 메시지에 대한 완전한 가시성을 제공할 계획입니다.

4) 7개 네트워크 지원 - 2022년 9월 현재 하이퍼레인은 총 7개 체인에서 임의 메시지 전송 및 크로스체인 컨트랙트 호출을 지원합니다. (아비트럼, 아발란체, BNB 체인, Celo, 이더리움, 옵티미즘, 폴리곤)

5) 인터체인 DAO 거버넌스 - 하이퍼레인은 DAO 거버넌스에 의해 의사결정이 이루어지며, ABC 토큰보유자는 하이퍼레인이 지원하는 모든 체인에서 투표를 통해 하이퍼레인 프로토콜에 대한 변경사항을 제안/도입할 수 있습니다.

작동 방식 - 트랜잭션 라이프사이클

하이퍼레인은 체인간 메시지 송수신에 ‘인박스(Inbox)’와 ‘아웃박스(Outbox)’ 스마트 컨트랙트를 사용합니다. 하이퍼레인이 지원하는 모든 체인에는 하나의 아웃박스와 n-1개의 인박스가 있습니다(자신을 제외한 모든 타체인에 있으므로). 하이퍼레인은 3단계에 걸쳐 메시지를 주고받습니다:

• 1단계 - 애플리케이션이 소스체인에서 Outbox.dispatch()를 호출합니다. 각 메시지는 가스 효율성을 위해 아웃박스의 머클트리 증분값에 리프(Leaf) 형태로 삽입됩니다. 
  *참고: Outbox.dispatch() 함수에는 트랜잭션과 관련된 모든 정보(예: 메시지내용, 목적지체인 ID, 수신자주소)가 담깁니다.
• 2단계 – 가장 마지막으로 발생한 아웃박스 머클루트에 소스체인의 검증자세트가 서명합니다. 애플리케이션에 따라서는 애플리케이션 자체 검증자세트도 이 머클루트에 서명합니다(로컬보안).
• 3단계 - 릴레이어는 InboxValidatorManager.process()를 호출하여 메시지, 메시지의 머클증명, 그리고 2단계에서 서명한 머클루트를 수신자에게 전달합니다. InboxValidatorManager는 이 루트가 검증자세트에 의해 서명되었는지 확인한 다음 Inbox.process를 호출하여 머클증명을 확인합니다. 확인이 끝나면 인박스 컨트랙트가 recipient.handle() 함수를 호출하여 메시지를 애플리케이션으로 전달합니다.

보안

하이퍼레인의 보안기능은 다음과 같습니다:

1) PoS 검증시스템의 경제적 보안 – 하이퍼레인의 보안은 DPoS(Delegated Proof-of-Stake) 프로토콜에 의존합니다. 하이퍼레인이 지원하는 각 체인에는 자체 검증자세트가 있으며, 지분증명체계에 따라 악의적인 행동에는 금전적 대가가 따릅니다.

2) 사용자가 선택하는 검증자 - 사용자들은 ABC 토큰을 스테이킹하여 하이퍼레인 검증자에게 위임할 수 있습니다. 가장 많은 토큰을 위임받은 검증자가 검증자세트의 일원이 됩니다. 사용자는 검증자세트의 구성원 변경도 제안할 수 있습니다.

3) 애플리케이션별 자주적 합의(Sovereign Consensus) - 하이퍼레인은 범용메시징브릿지(AMB)에 새로운 개념을 도입했습니다. 개발자들은 하이퍼레인을 기반으로 구축되는 모든 디앱의 메시지를 검증하는 DPoS 프로토콜외에 추가적으로 애플리케이션별 자체 검증자세트를 지정할 수 있습니다. 이는 개발자들에게 유연성을 준다는 의미에서 코스모스의 앱특화 개발환경과 문맥을 같이합니다. 개발자는 자체 검증자세트를 통해 디앱의 보안을 확보할 수 있습니다.

4) 검열 저항성 - 대부분의 범용메시징브릿지(AMB)와 달리 하이퍼레인의 검증자는 개별 메시지에 서명하지 않습니다. 대신, 모든 메시지가 함께 묶여있는 아웃박스의 머클루트에 서명합니다. 검증자가 특정 메시지를 검열할 수 없기 때문에 하이퍼레인의 검열 저항성이 강화됩니다.

5) 콘트롤타워 - 하이퍼레인에는 부정메시지, 검열 등 악의적 검증자활동을 탐지하는 ‘감시탑(Watchtower)’이 있어 아웃박스와 인박스(해당 아웃박스와 연결된)를 관찰합니다. 감시탑은 악의적인 활동을 감지하면 소스체인에 증거를 제출해 보상을 받고, 검증자는 지분이 슬래싱됩니다.

신뢰 가정

하이퍼레인의 신뢰가정은 다음과 같습니다:

1) 검증자세트에 의한 외부 검증 - 하이퍼레인은 각 체인별 검증자세트가 메시지에 서명합니다. 따라서 검증자가 트랜잭션을 정직하게 검증하고 자금탈취를 위해 공모하지 않을 것이라는 사용자의 신뢰를 전제로 합니다.

*참고: 하이퍼레인의 검증자수, 스테이킹금액 등 검증자세트에 대한 세부정보는 공개되지 않습니다.

2) 보안격차 - 하이퍼레인이 지원하는 모든 체인에는 자체 검증자세트가 있습니다. 즉, 검증자의 존재를 강제하지않고 각 체인에 맡기는 것이죠. 따라서 검증자 수가 적은 체인은 공격에 따르는 기회비용(Economic Security)이 낮아 다른 체인보다 보안성이 떨어질 수 있습니다. 하지만 하이퍼레인의 애플리케이션에게는 메시지를 주고받을 체인을 선택할 자유가 주어지기 때문에, 보안이 부실하다고 판단되는 체인과 통합하지 않을 수 있습니다.

3) 슬래싱으로 제거되는 담합 유인 - 하이퍼레인 검증자의 지분에는 연대책임분(Bonding Stake)이 있어, 악의적인 행동(담합 또는 메시지 검열)에 가담할 경우 해당지분이 삭감됩니다. 이처럼 슬래싱 매커니즘이 고객자산을 보호하는 것은 사실이지만, 어떠한 시나리오에서도 경제적 보안(Economic Security)이 보장된다는 가정이 필요합니다. 담합이익이 공격비용(슬래싱 패널티 및 평판)을 초과할 경우, 검증자가 정직하게 행동하기보단 담합을 통해 자금을 탈취할 유인이 커질 수 있습니다.

커뮤니티 및 리소스

하이퍼레인에 대한 더 자세한 내용과 커뮤니티의 최신정보는 아래의 링크를 통해 확인하실 수 있습니다:

·         Official Website

·         Docs

·         Github

·         Twitter

·         Discord

 

디브릿지(deBridge)

개요

디브릿지는 범용 크로스체인 메시징 및 상호운용성 프로토콜입니다. 간단한 메시지부터 복잡한 데이터(임의의 메시지 또는 통화 데이터 등)까지. 사용자와 개발자에게 이종체인간 전송을 제공해 기존 브릿지의 개념을 확장하는 것을 목표로 합니다.

복잡한 크로스체인 애플리케이션을 구축하고, 다양한 결합/통합 가능성을 열어주는 개발자 친화적 툴을 제공한다는 것이 디브릿지의 핵심 소구점입니다. 인프라 플랫폼인 디브릿지는 개발자가 본인에 니즈에 맞춰 SDK, API, 위젯 등을 통합해 이종체인간 메시지를 교환함으로써, 토큰브릿지, NFT브릿지, 크로스체인 스테이킹/대출/결제/자격증명 등과 같은 다양한 크로스체인 사용사례를 구축할 수 있도록 합니다. 

디브릿지의 핵심기능은 다음과 같습니다:

1) 디스왑 유동성 네트워크(deSwap Liquidity Network·DLN)를 통한 무제한 자산전송 - DLN은 디브릿지 위에 구축된 프로토콜로서, 유동성풀에 자산을 락업하는 대신 온디맨드 방식으로 이종체인간 유동성을 활용하는 새로운 방식을 도입해, 락업되는 자산 0 TVL의 상태로 체인 간 무제한 자산전송이 가능합니다. 

2) 하드햇(Hardhat) 플러그인 - 디브릿지의 하드햇 플러그인은 디브릿지를 기반으로 구축되는 디앱의 다양한 기능들을 출시 전에 안전하게 테스트할 수 있는 환경을 제공합니다.

3) 크로스체인 트랜잭션 번들링 - 디브릿지를 사용하면 디앱이 여러 트랜잭션을 단일 트랜잭션으로 번들링할 수 있기 때문에 스왑과 상호작용을 한 번에 할 수 있습니다(예. 스테이킹).

4) (일부 블록체인의 다운타임시에도 유지되는) 작업연속성 - 디브릿지는 오프체인 트랜잭션 검증매커니즘을 사용합니다. 따라서 디브릿지가 지원하는 특정 블록체인에 다운타임이 발생하더라도 나머지 모든 체인의 트랜잭션은 계속해서 처리됩니다. 또한 오프체인 검증매커니즘을 감안할 때, 디브릿지의 검증자는 트랜잭션을 중계할 필요가 없어 처리량이 무제한입니다. 검증자가 서로 통신할 필요도 없기 때문에 IP 주소가 노출되지 않아 인프라 전반의 보안도 강화됩니다.

5) 검증 가능한 공개 트랜잭션 - 디브릿지 인프라를 통과하는 모든 크로스체인 전송의 세부정보는 디브릿지 익스플로러에서 누구나 확인할 수 있습니다.

다음으로, 디브릿지의 네트워크효과는 다음과 같습니다:

1) 디브릿지 애플리케이션 - 디브릿지팀은 디브릿지의 기능이 잘 드러나는 deApp들을 선보였습니다. ① deSwap: 크로스체인 스왑 솔루션, ② dePort: 애플리케이션이 합성(Synthetic)토큰을 발행할 수 있는 브릿지, ③ deNFT(출시예정): 크로스체인 네이티브 NFT 구축 솔루션.

2) 디앱 구축 인프라 – 다수의 애플리케이션이 디브릿지의 인프라를 사용하고 있습니다. 예를 들어, Thunder Lands는 최근 dePort를 통합해 썬더토큰(TNDR)을 여러 체인으로 확장했습니다. dePort가 디브릿지 프로토콜을 기반으로 구축되었기 때문에, Thunder Lands도 디브릿지 인프라에 올라가 있다고 할 수 있습니다. 이외에도 Frontier Wallet, Wirex Wallet, Plato, Minimax 등도 디브릿지의 애플리케이션들을 사용하고 있습니다. 

3) 체인링크 해커톤 우승 - 디브릿지는 2021년 4월 체인링크 글로벌 해커톤에서 우승하면서 시작된 프로젝트입니다.

4) 펀딩 - deBridge는 ParaFi가 주도한 펀딩 라운드에서 550만 달러를 모금했습니다. 이 라운드에는 후오비벤처스, 크립토닷컴캐피털, 애니모카브랜즈 등이 참여했습니다.

5) 7개 체인 지원 - 2022년 11월 현재, 디브릿지는 총 7개의 블록체인을 지원하고 있으며(이더리움, BNB 체인, 폴리곤, 아비트럼, 헤코, 팬텀, 아발란체), 곧 솔라나 등 비 EVM 체인에 대한 지원을 추가할 예정입니다.

작동 방식 - 트랜잭션 라이프사이클

디브릿지의 아키텍처에서 트랜잭션은 2개의 레이어를 통과합니다:

1) 프로토콜 레이어(온체인) - 디브릿지가 지원하는 모든 체인에 배포되어있는 한 세트의 온체인 스마트컨트랙트입니다. 디브릿지 거버넌스가 수수료, 체인, 검증자 등 스마트컨트랙트의 다양한 매개변수를 관리합니다.

2) 인프라 레이어(오프체인) - 디브릿지의 거버넌스를 통해 선출된 검증자가 운영하는 노드입니다. 이들 검증자들이 디브릿지가 지원하는 모든 블록체인에서 풀(Full)노드도 운영합니다.

이제 디브릿지의 작동방식을 조망해보겠습니다:

• 1단계: 트랜잭션이 소스체인(deBridgeGate)의 스마트컨트랙트를 통과할 때 Submission ID(고유 해시)가 부여됩니다. 이 ID는 각 트랜잭션의 식별자로서, 디브릿지 프로토콜 내에서 메시지의 고유성을 보장합니다.
• 2단계: 디브릿지 검증자(12개)는 deBridgeGate 스마트컨트랙트가 생성한 모든 이벤트를 추적합니다. 검증자는 일정수(체인마다 상이)의 블록확정이 모여 블록완결에 도달할 때까지 기다린 후 검증을 시작합니다. 제출물(Submission)의 정보가 정확하면 각 검증자는 자신의 프라이빗키로 서명하고 디브릿지 API에 게시합니다.
• 3단계: 검증자 서명은 IPFS에 저장되고(Arweave 곧 도입 예정) 사용자나 키퍼 누구든 이 서명들을 검색해 목적지체인(타깃체인)의 deBridgeGate 스마트컨트랙트를 통해 전달할 수 있습니다.
• 4단계: 최소 ⅔(12명 중 8명) 이상의 검증자가 메시지에 서명해야 목적지체인에서 메시지를 확인 및 회수할 수 있습니다. 필요한 서명 수가 충족되면, 트랜잭션은 deBridgeGate 스마트컨트랙트에 의해 실행되고 콜데이터(실행에 필요한 트랜잭션 데이터)는 타킷체인으로 전송됩니다.

_{디브릿지 트랜잭션 라이프사이클 (또는 크로스체인 호출의 라이프사이클)}

보안

디브릿지의 보안기능은 다음과 같습니다:

1) 슬래싱 매커니즘 - 디브릿지 아키텍처에서 검증자는 핵심적입니다. 디브릿지는 슬래싱 매커니즘을 통해 검증자의 담합유인을 낮춥니다. 모든 디브릿지 검증자는 위임스테이킹 스마트컨트랙트에 담보물(본인의 담보 + 위임받은 담보)을 락업합니다. 이 담보물은 검증자의 공정성을 보장하기 위해 설정되며, 부정직한 검증자의 담보물은 슬래싱됩니다.

2) 위임스테이킹 - 검증자와 위임자는 디브릿지 보안에 대한 경제적 인센티브로 프로토콜 수수료를 받고, 언스테이킹 시에는 자산수령까지 14일간의 ‘쿨다운 기간’을 거쳐야 합니다. 이를 통해 1) 선행매매(Front-Running)와 기회주의적 스테이킹(거래량이 많은 기간에 보상을 노리고 스테이킹하는 것)을 방지하고, 2) 악의적인 활동의 경우 거버넌스가 검증자의 지분을 삭감할 수 있는 시간을 확보할 수 있습니다.

3) 트랜잭션 완결요건 – 디브릿지 검증자는 블록확정이 일정 수에 도달할 때까지 기다렸다가 트랜잭션이 완결성을 득할 때에만 서명해야 합니다. 트랜잭션은 한번 확정되면 되돌릴 수 없기 때문에 프로토콜은 이중지출을 방지할 수 있습니다. 또한, 검증자는 블록범위가 짧은데 많은 양의 자금이 이체될 경우 보안 강화를 위해 더 엄격한 완결성 규칙을 적용할 수 있습니다. 프로토콜은 이렇게 공격 비용을 증가시켜 51% 공격을 저지할 수 있습니다(블록범위 또는 시간이 더 많이 소요되므로).

4) 논스 순번(Sequence)을 통한 검증 - 논스는 디브릿지 스마트컨트랙트를 통과하는 모든 트랜잭션에 할당된 고유 순번을 의미합니다. 디브릿지의 검증자는 항상 ‘논스’의 오름차순으로 트랜잭션을 확인해야 합니다. 프로토콜은 이를 통해 이중지출을 방지하고 리오그(블록재구성) 및 51% 공격에 대한 보안을 강화합니다.

5) 합성자산 vs 근거자산 잔액대조 - 디브릿지 노드에서 계산된 잔액이 스마트컨트랙트 상의 잔액과 일치하는지 확인하기 위해 검증자는 대차대조를 실시하며, 편차가 있을 경우 검증을 중단합니다. 이는 합성자산과 근거자산의 연동을 유지하는 중요한 역할을 합니다.

6) 기술감사 및 Immunefi 버그바운티 - 디브릿지 프로토콜과 주변모듈에 대해 Halborn, Zokyo, Ackee Blockchain, Neodyme 등이 17회에 걸쳐 기술감사를 실시했습니다. 또한, 디브릿지는 Immunefi에서 20만 달러의 바운티프로그램을 진행합니다.

7) DAO 거버넌스 - 디브릿지팀은 토큰보유자가 프로토콜 관련 의사결정시(트레저리 분배, 프로토콜 매개변수 변경 등) 투표권을 행사할 수 있게 함으로써 거버넌스를 탈중앙화하고자 합니다.

신뢰가정

디브릿지의 신뢰가정은 다음과 같습니다:

1) 검증자세트에 의한 외부검증 - 디브릿지에서는 단 12명의 검증자로 구성된 검증자세트가 트랜잭션을 검증하고 실행합니다. 트랜잭션이 확정되려면 최소 ⅔ 이상의 검증자, 즉 8명의 검증자가 서명해야 합니다. 따라서 8명의 검증자가 공모하면 자산 탈취로 이어질 수 있습니다. 그러나 위임스테이킹과 슬래싱에 따라 재정적 손실을 감수해야하기 때문에 악의적으로 행동할 유인을 얻기 힘듭니다. 최근 디브릿지팀은 검증자담합에 노출되는 자산범위을 프로토콜 전체 TVL이 아닌 단일전송으로 축소시키는 디스왑 유동성 네트워크(DLN)를 도입했습니다. 또한, 디브릿지는 ECDSA 임계값 서명(Threshold Signatures) 또는 융합 알고리즘을 사용해 검증자세트에 확장성을 더하고, 담합에 필요한 서명의 임계값을 높여 프로토콜의 전반적인 보안을 강화할 계획입니다.

2) 검증자의 평판비용과 슬래싱으로 인한 금전적비용 - 디브릿지는 검증자(또는 모든 위임자)의 정직성을 확보하기 위해 담보 스테이킹을 요구합니다. 부정행위 발생 시, 이 담보는 슬래싱되고, 피해보상에 사용될 수 있습니다. 따라서 디브릿지는 담합으로 인한 평판 및 금전적 비용(위임스테이킹 및 슬래싱 계약에 묶인 자금)이 담합으로 인한 잠재이익보다 크다는 신뢰에 바탕을 둔 구조라고 볼 수 있습니다.

3) 담합에 의한 메시지 검열 - 디브릿지 검증자 중 5/12가 담합하여 악의적으로 메시지를 검열할 수 있습니다.

4) 필수가 아닌 검증자의 담보 스테이킹 - 디브릿지의 검증자는 본인의 담보를 스테이킹하지 않고 위임받은 담보만 사용할 수 있습니다. 검증자의 담보스테이킹 요건이 코드단에 정의되어 있는 것은 아니기 때문입니다. 검증자가 담보를 스테이킹하지 않을 경우, 담합에 가담하는 검증자들이 감수해야할 비용이 줄어들게 됩니다. 그러나 담보가 없는 검증자가 위임을 받을 가능성은 낮습니다. 또한 거버넌스에 의해 담보가 없는 검증자는 담보가 있는 검증자로 대체될 것으로 보입니다.

5) 허가 기반 검증자세트 - 디브릿지팀은 프로토콜 부트스트래핑을 위해, 2021년 11월에 출시한 v2.0 테스트넷에서 성능(인프라 안정성, 트랜잭션 누락건수, 검증속도)을 기준으로 12개의 검증자를 선정했습니다. 따라서 현재로서는 디브릿지의 허가에 기반해 검증자세트가 운영되고 있습니다. 그러나 거버넌스 토큰이 출시되면 검증자를 선정하는 권한이 거버넌스로 넘어가게 되고, 누구나 거버넌스 제안을 통해 검증자에 지원할 수 있게 될 것으로 보입니다.

6) 위임스테이킹과 슬래싱모듈은 아직 라이브 전 - 위임스테이킹과 슬래싱매커니즘은 프로토콜에 경제적 보안을 추가해 디브릿지의 보안을 크게 향상시킬 것입니다. 다만 이 기능들이 아직 라이브 전이어서 검증자들의 담합을 막기 위한 사전예방조치가 현재로서는 미비한 상태입니다.

7) 점진적인 탈중앙화 – 디브릿지는 탈중앙화에 반복적(Iterative) 모델을 채택하고, 점증하는 방식으로 발전해왔습니다. 그러나 이번 거버넌스 토큰의 출시를 계기로 디브릿지의 네트워크가 비약적으로 탈중앙화할 것으로 보입니다. 다만 실제로 토큰이 출시되기 전까지는 팀이 거버넌스 권한을 가질 것입니다. 또한 위임스테이킹 모듈은 거버넌스 토큰 출시 이후에 적용될 것으로 보입니다.

커뮤니티 및 리소스

디브릿지에 대한 더 자세한 내용과 커뮤니티의 최신 정보는 아래의 링크에서 확인하실 수 있습니다:

·         Official Website

·         Docs

·         deBridge Security

·         Getting started with deBridge

·         deExplorer

·         Github

·         Medium

·         Twitter

·         Discord

 

비교분석: 어떤 AMB 위에서 개발해야 할까?

총 7개 범용/임의메시징브릿지(Arbitrary Messaging Bridge∙AMB)의 설계 및 기능 분석을 바탕으로 각 솔루션의 장단점, 핵심기능, 강약점을 표로 요약해 보겠습니다. 본 비교분석의 목표는 개발자/사용자가 다양한 AMB 솔루션을 한눈에 파악하고 각 솔루션의 장단점과 본인의 선호에 따라 솔루션을 선택할 수 있도록 AMB 생태계 스냅샷을 제공하는 것입니다.

비교는 다음의 5가지 범주(각 범주가 여러지표를 포함)로 진행하겠습니다:

1. 브릿지 설계 - 이론적 보안(Theoretical Security)

브릿지들은 서로 다른 방식으로 크로스체인 메시지를 검증하고, 설계도 각기 다릅니다. 그러다보니 브릿지별로 트레이드오프도 다 다를 뿐더러, 때로는 보안이 희생되기도 합니다. 이 섹션에서는 각 AMB의 이론적 보안을 네 가지 측면에서 분석해보겠습니다:

1) 합의 매커니즘 - AMB가 메시지의 유효성을 결정하는 방식

2) 검증자 담합 – 담합에 필요한 최소 검증자수

3) 검열 저항 – 메시지 검열에 필요한 최소 서명자수

4) 무허가성 - 검증자세트의 무허가성(Permissionless), 누구나 검증자로 참여할 수 있는지 여부와 이 경우, AMB가 무허가성을 달성하는 방법

2. 실질적 보안 조치

과거 브릿지해킹 사례들에서 보았듯이, 버그 하나로 수백만 달러가 도난당할 수 있습니다. 어떤 코드에든 버그가 있을 수 있고, 브릿지는 해커의 주요 표적이기 때문에 브릿지빌더들은 기술감사와 공개바운티에 지속적으로 투자해야 합니다. 이러한 실질적인 보안조치들이 코드의 실행오류 또는 버그로 인한 치명적 해킹을 방지할 수 있습니다.

1) 기술감사 – AMB의 피감사 횟수(횟수가 높을수록 긍정적)

2) Immunefi의 공개바운티 - 화이트햇해커가 Immunefi 버그바운티에서 AMB 코드의 중요 취약점을 찾아냈을 때 받을 수 있는 최고보상액

3. 프로토콜 이력

크립토 생태계는 끊임없이 진화하고 있습니다. 새로운 내러티브와 틈새시장이 계속해서 등장하기 때문에 시장지위과 화제성을 유지하는 것은 결코 쉬운 일이 아닙니다. 프로토콜 히스토리는 프로젝트의 운영기간을 보여줍니다. 신뢰도는 시간과 함께 쌓이는 것이기 때문에, 프로젝트가 얼마나 오랫동안 살아남아 시장지위를 유지했는지는 프로덕트의 품질과 팀의 경쟁력을 증명하는 중요한 지표입니다.

해킹 또한 프로젝트의 이력과 로드맵에서 중요한 이벤트이기 때문에 이 섹션에 포함되었습니다. 해킹이 프로젝트 전반에 미칠 수 있는 파괴력을 감안할 때, 해킹의 원인과 결과를 조사하고, 팀의 대응과 원복여부를 확인해보아야 합니다.

1) 출시 이래 운영기간 - AMB 출시 이후 유지된 운영기간

2) 해킹 - 대규모 해킹 발생 여부

4. 지원체인수 및 사용사례

네트워크 연결성은 각 AMB가 지원하는 블록체인의 개수를 의미합니다. 이 지표는 간단해보이지만, 특정 AMB를 선택하는 중요한 이유가 될 수 있습니다. 프로젝트가 크로스체인화를 고려할 때는 연결하고자 하는 특정 블록체인이 있기 마련입니다. AMB가 해당 블록체인을 지원하지 않는다면, 아무리 기술적으로 뛰어난 AMB라 하더라도 프로젝트에게는 아무 효용이 없는 셈입니다. 예를 들어, 솔라나로 확장을 꾀하는 프로젝트인데 AMB가 솔라나를 지원하지 않는다면, 해당 프로젝트는 이 AMB를 포기하고 솔라나를 지원하는 다른 AMB를 선택할 가능성이 높습니다.

사용사례는 각 AMB의 서비스라인업을 활용해 실제로 크로스체인 애플리케이션을 구축한 디앱사례에 초점을 맞춥니다.

1) 네트워크 연결성 - AMB가 지원/연결하는 체인이 많을수록, 프로젝트의 선택지가 넓어짐

2) 각 AMB 기반 디앱구축사례 - 크로스체인 기능을 위해 AMB를 사용하는 프로젝트 목록

5. 토큰브릿지 실적

사용자는 토큰브릿지를 통해 체인A에서 체인B로 자산을 전송할 수 있습니다. 이는 개인사용자(Retail Users)를 대상으로 한 AMB의 대표적인 사용사례입니다. AMB는 통상 밀접하게 연결된 토큰브릿지가 있고, 동일한 팀이 구축하는 데다 대부분 동일한 AMB에 구축되기 때문에 AMB와 토큰브릿지는 많은 부분에서 겹칩니다. 이렇다보니 토큰브릿지의 성능은 AMB의 성능과 성공을 가늠할 중요한 표지가 됩니다.

이 섹션에서는 각 유동성레이어의 실적지표 네 가지에 대해 살펴보겠습니다:

1) 자본효율성 - 토큰브릿지가 풀에 예치된 자산을 얼마나 효율적으로 사용하는지를 측정하며, 30일간 브릿지된 거래량을 TVL로 나눈 값으로 계산됩니다(숫자가 높을수록 긍정적). 하지만 토큰브릿지는 다양한 매커니즘을 사용해 다양한 목적으로 구축될 수 있고, 이러한 매커니즘과 설계목적이 직접적으로 자본효율성에 영향을 미친다는 점에 유의해야 합니다. 예를 들어, 자본효율성지표는 스타게이트나 c브릿지와 같은 유동성네트워크에서 더 중요하고, 악셀라의 Satellite, 노매드 브릿지, 웜홀의 포털과 같은 락앤민트 브릿지에서는 덜 중요합니다.

2) 총 트랜잭션 수 - 출시 이래 유동성레이어를 통해 실행된 트랜잭션건수

3) 브릿지된 총거래량 - 출시 이래 유동성레이어를 거쳐간 거래량

4) 고점당시 총예치금(TVL) - 유동성레이어풀에 자산이 가장 많이 예치된 시점의 TVL

 

범용/임의메시징브릿지(AMB) 비교분석틀

AMB들의 차이점은 다음과 같습니다:

_{이미지 확대를 원하시면 새 탭에서 이미지를 여시거나 여기에서 확인하실 수 있습니다.
참고: 색상구분은 차트의 가독성 향상과 AMB 정량실적 비교 용이를 위해 사용되었습니다.}

토큰브릿지 실적지표

AMB와 밀접하게 연결된 토큰브릿지들의 주요실적은 다음과 같은 차이를 보이고 있습니다:

 

맺는 말

Web3 인프라에서 임의메시징브릿지의 중요성은 매우 큽니다. 체인간 장벽없는 쉽고 안전한 데이터 엑세스는 Web3에 있어 혈맥과도 같아서, 원활한 크로스체인 메시징이 불가능해지는 순간 상호운용성, 모듈성, 결합성도 요원해집니다.

전술한 바와 같이, AMB 분야는 아직 초창기이며, 다양한 설계들이 실사용 환경에서 테스트를 거듭하고 있습니다(따라서 해킹도 빈번함).

이번 아티클은 사용자/개발자의 AMB 이해 도모에 초점을 맞추었습니다. 모쪼록 AMB의 작동방식과 설계상의 트레이오프에 대한 명료한 설명이 되었길 바랍니다. 다만, AMB의 다양성을 감안할 때, 편향을 방지하기 위해 당분간 점수나 순위는 매기지 않으려고 합니다. LI.FI는 어떠한 브릿지와도 관련이 없으며 특정 브릿지 설계나 아키텍처에 대한 선호가 없습니다.

본 아티클에 대한 의견이 있으시면 언제든지 LI.FI팀에 연락주시기 바랍니다. LI.FI는 본 아티클을 통해, 혁신을 거듭하고 있는 AMB 분야의 최신정보를 가장 정확하게 제공하고자 합니다.

감사합니다 :)