[Bridge Series] 2. Trustless Bridge
이번 Bridge Series에서는 블록체인 네트워크 간 자산 혹은 메세지 전송을 가능하게 하는 각종 Bridge 솔루션들의 분류 및 작동 방식에 대해 살펴봅니다.
Bridge Series
Author
Jason, 안유리, 한충현 of Decipher
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By 이병헌, 정재환
이번 편에서는 Trustless bridges를 중심으로 특징과 작동원리 및 방식을 알아봅니다.
Connext xPollinate Bridge
1. 개요
xPollinate Bridge는 이더리움 가상 머신(EVM)이 호환 가능한 체인들 사이에서 자산의 이동을 용이하게 해주는 bridge 입니다. 자산 이동을 위해 아토믹스왑을 사용하는 유동성 네트워크방식을 사용하며 사용자의 입장에서는 중개인을 신뢰할 필요가 없이 믿고 사용할 수 있는 Trustless 방식입니다. 따라서 중개인의 악의적인 행동으로 인해 자금을 탈취될 가능성이 없으며, 블록체인 네트워크 전체의 보안이 위협받지 않는 이상 안전하다고 말할 수 있습니다.
2. 특징
xPollinate Bridge는 아토믹 스왑을 가능하게 하는 스마트 컨트랙트를 사용하기 때문에, 이더리움 가상 머신(EVM)이 호환 가능한 다양한 체인들에 쉽게 배포될 수 있다는 장점이 있습니다. 현재 지원하는 네트워크는 총 11개로, ETH, BSC, MATIC, Arbitrum, Optimism, AVAX, FTM, GNO, MOVR, FUSE, GLMR이 있습니다. 2022년 2월 12일 기준 bridge에 예치된 총 TVL(Total Value Locked)은 $37.4M이며 여태까지 이동 된 총 거래량은 $672.0M을 기록하고 있습니다.
3. xPollinate Bridge의 작동 원리
예시로 Alice가 자신의 $ETH를 Arbitrum 네트워크에서 Optimism 네트워크로 옮기고 싶다고 가정해보겠습니다. 기존 방식을 사용하여 자산을 옮기게 되면 굉장히 복잡하고 많은 시간이 소요되는 방법을 거치게 됩니다. 우선 $ETH를 Arbitrum 네트워크에서 이더리움 네트워크로 옮긴 후, 그 다음 이더리움 네트워크에 있는 $ETH를 다시 Optimism 네트워크로 옮겨야 합니다. 하지만 Arbitrum 네트워크는 옵티미스틱 롤업을 이용한 이더리움 레이어2 네트워크이기 때문에, 옵티미스틱 롤업의 검증방식인 사기증명(Fraud proof)의 특성상 다시 이더리움 네트워크로 출금하는데 약 7~14일의 기간이 소요됩니다. 따라서 이 방식으로 $ETH를 옮기게 되면 값비싼 수수료를 지불해야하며 많은 시간이 소요됩니다.
이 상황에서 Connext xPollinate Bridge와 같은 유동성 네트워크를 사용하는 bridge를 사용하게 된다면, 훨씬 더 빠르고 간단하게 $ETH를 Arbitrum 네트워크에서 Optimism 네트워크로 이동할 수 있습니다. xPollinate Bridge에서는 자산의 이동을 중개하는 중개인이 존재하고, 이를 Router 라고 부릅니다. Router는 Arbitrum 네트워크와 Optimism 네트워크에 동시에 넉넉한 양의 $ETH를 소유하고 있어야 합니다. 그러면 Alice는 Arbitrum 네트워크에서 Router에게 $ETH를 보낸 후, Router는 이를 확인하고 Optimism 네트워크에서 보유하고 있던 $ETH를 Alice에게 전송하게 된다면, 결과적으로는 Alice는 $ETH를 Arbitrum 네트워크에서 Optimism 네트워크로 7~14일이라는 출금기간 없이 한 번에 전송할 수 있는 것입니다.
이 과정을 더 자세히 살펴보면 Connext는 크로스체인 전송을 위한 lightweight 프로토콜인 nxtp를 사용합니다. 총 3가지 단계로 전송이 일어나게 되는데, 사용자가 A체인에서 B체인으로 $ETH를 보낸다고 가정해보겠습니다.
1. Route Auction: 사용자들은 원하는 루트의 트랜잭션(A에서 B로 $ETH 전송)을 Connext의 네트워크에 전파하면, Router들은 특정 시간과 가격으로 사용자가 제출한 트랜잭션을 성사시킬 내용을 담은 비공개 방식 입찰로 응답합니다.
2. Prepare: Auction이 완료되면, 트랜잭션이 준비될 수 있습니다. 사용자는 A체인에서 Transaction Manager 컨트랙트에 $ETH를 잠시 lock을 걸고, 이 이벤트를 B체인에서 Router가 감지하게 되면, Router도 B체인의 Transaction Manager 컨트랙트에 $ETH를 잠시 lock을 겁니다. 대신 B체인에서 Router가 lock을 거는 $ETH의 양은 사용자가 보내려는 $ETH의 양에서 자신의 수수료를 차감한 만큼입니다.
3. Fulfill: 트랜잭션이 준비가 완료되면, 사용자는 Relayer(Router와 또 다른 중개인)에게 서명한 메세지를 보내게 되면, Relayer는 소정의 수수료를 받고 B체인에서 Transaction Manager 컨트랙트에 메세지를 보내 사용자가 B체인에서 $ETH를 받을 수 있게 합니다. 그 후에 Router는 A체인의 Transaction Manager 컨트랙트에 서명한 메세지를 보내 A체인에서 $ETH를 받을 수 있게 되고 트랜잭션은 완료가 됩니다.
만약 정해진 시간내에 거래가 완료되지 않으면 자금은 다시 원래의 주인으로 돌아가게 됩니다. 자금이 완전히 전송되기전까지는 스마트컨트랙트 내에 존재하기 때문에 자금을 탈취당하지않고 다시 안전하게 돌려받을 수 있기 때문에 신뢰가 필요없는(Trustless)방식의 bridge라고 할 수 있습니다.
4. Connext Low Level 분석
Connext를 통해 트랜잭션을 전송하는 핵심 흐름은 다음과 같습니다.
- 전송 quote 가져오기: 전송에 있어 예상가격과 commitment를 결과값으로 받습니다.
- 전송 시작: 체인A에서 사용자의 트랜잭션을 전송한 후 네트워크가 유동성을 공급할 때 까지 대기합니다.
- 전송 완료: 체인B에서 사용자의 트랜잭션을 완료합니다.
1. GetTrasferQuote
getTransferQuote 는 다음 구성요소들을포합합니다.
sendingAssetId: (필수) 전송을 시작하는 체인에서의 토큰의 주소. $ETH와 같은 네이티브 자산에 있어서는Address(0)을 사용.sendingChainId: (필수) 전송을 시작하는 체인의 ChainID.receivingAssetId: (필수) 전송을 받는 체인에서의 토큰의 주소. $ETH와 같은 네이티브 자산에 있어서는Address(0)을 사용.receivingChainId: (필수) 전송을 받는 체인의 ChainID.receivingAddress: (필수) 전송을 받는 체인에서 토큰을 수령할 주소.amount: (필수) 전송하려는 자금의 양.
2. 트랜잭션 실행
먼저, 컨트랙트에서 트랜잭션을 시작하기위해 prepareTransfer 을 실행합니다. 그 후, 전송을 받는 체인에서 트랜잭션이 준비되기까지 기다린 후, fulfillTransfer 을 요청합니다.
References
- Connext Docs (https://docs.connext.network/)
- Connext (https://docs.connext.network/Integration/QuickStart/transfer)
Celer cBridge
1. 개요
Celer cBridge는 이더리움 레이어2 솔루션 프로젝트 중 하나인 Celer의 Bridge 서비스이며, Connext xPollinate Bridge와 마찬가지로 EVM 호환 네트워크 간 자산이동을 도와줍니다. 마찬가지로 유동성 네트워크 방식을 채택했으며, 블록체인 네트워크의 보안이 무너지지 않는 이상 사용자 입장에서 자금 탈취는 불가능합니다.
2. 특징
Celer cBridge도 아토믹 스왑을 가능하게 하는 스마트 컨트랙트를 사용하기 때문에, 이더리움 가상 머신(EVM)이 호환 가능한 다양한 체인들에 쉽게 배포될 수 있다는 장점이 있습니다. 현재 지원하는 네트워크는 총 20개로 ETH, BSC, Astar, AVAX, MATIC, Arbitrum, FTM, Metis, Oasis Emerald, Celo, Aurora, Harmony, GLMR, MOVR, Optimism, Boba, OKEx Chain, Heco, Gnosis, Shiden이 있습니다. 2022년 2월 12일 기준 bridge에 예치된 총 TVL(Total Value Locked)은 $284.6M이며 여태까지 이동 된 총 거래량은 $3.3B을 기록하고 있습니다.
3. Celer cBridge의 작동 원리
Celer cBridge의 작동원리는 아토믹스왑의 해시타임락(Hashed Time Lock)을 활용하며, 위에서 설명한 Connext xPollinate Bridge와 거의 동일한 원리를 가지고 있어 자세한 설명은 생략하겠습니다. xPollinate Bridge와 비교하여 Celer cBridge만의 특징은 유동성 네트워크 방식에서 유동성 공급에 중개인 뿐 만 아니라 일반 사용자들도 참여할 수 있기 때문입니다.
유동성 네트워크 방식에서는 각 네트워크 별로 이미 존재하는 유동성 풀이 존재하길 마련인데, 만약 자산의 이동이 균일하게 발생하지 않고, 치우쳐져 발생한다면 한 네트워크에서 유동성 풀이 고갈될 위험에 처할 수 있습니다. 따라서 유동성 조정 과정이 필요하게 되는데, Celer cBridge에서는 유동성 풀에 자금을 예치한 사용자에게도 거버넌스 토큰을 이자 보상으로 지급하며 인센티브 시스템을 통해 사용자들도 bridge 내의 유동성 조정 과정에 참여하여 도움을 줄 수 있도록 합니다.
4. Celer cBridge Low Level 분석
cBridge SDK는 어플리케이션에 bridge 기능을 도입하기 쉽도록 도와줍니다. 자산을 이동시키기위해 cBridge SDK를 통해 cBridge Gateway에 요청을 전송하고, Source chain에 존재하는 cBridge contract에 전송 요청을 보내야합니다.
cBridge 컨트랙트 send 함수를 작동하여 사용자의 자산을 source chain에 있는 cBridge contract에 전송하게 되면, cBridge gateway와 Celer SGN (Celer 노드)은 destination chain에서 사용자에게 합당한 자산을 지급되는 방식으로 진행됩니다. 가스비로 사용되는 토큰을 전송할 때는 토큰 주소를 입력할 필요가없는 sendNative 함수를 사용하고, 그 외의 ERC20 토큰을 전송할 때는 토큰 주소를 입력하는 send 함수를 사용해야 합니다.
기본적으로 사용자의 지갑주소, 전송하려는 토큰의 양, Destination chain의 chainID, 논스값, 최대 슬리피지 값이 인자로 필요하며 위에서 언급했듯이 send 와 sendNative 함수의 차이는 토큰 주소의 유무입니다.
References
- Celer cBridge Docs (https://cbridge-docs.celer.network/)
- Celer cBridge (https://cbridge-docs.celer.network/developer/api-reference/contract-pool-based-transfer)
IBC
1. 개요
IBC는 Inter-Blockchain Communication protocol의 약자로, 블록체인 간의 통신에서 데이터를 주고 받을 때 활용되는 프로토콜입니다. 코스모스(Cosmos)는 단일 허브(Hub) 체인과 이와 상호작용하는 존(Zone)의 구조로 구성되어 있는데, 이 때 허브와 존, 존과 존 간의 통신에 IBC가 활용됩니다.
IBC는 트랜잭션을 처리하는 코스모스의 보안성이 IBC의 보안성을 보장하는 구조이므로, 코스모스 체인의 합의 레벨에서 공격이 이루어져야만 자금을 탈취할 수 있습니다. 때문에 코스모스 네트워크가 공격받지 않는 한, 안전하다고 볼 수 있습니다. 또한 현재까지 알려진 IBC의 중개인의 수는 85명으로, 높은 수준의 탈중앙성을 확보하고 있습니다.
2. 특징
IBC는 텐더민트(Tendermint) 기반 체인에서 활용될 수 있다는 점에서 높은 범용성을 확보하고 있습니다. 2021년 12월을 기준으로 Osmosis, Cosmos, Juno, Chihuahua, Terra, Crypto.Org, Cronos, Stargaze, Secret을 포함해 25개의 체인이 공식적으로 IBC를 이용하고 있습니다. IBC를 통해 서로 연결된 네트워크를 #IBCGang이라고 하며, #IBCGang의 가치는 이미 600억 달러를 넘어섰습니다. Cosmos 기반 DEX인 Osmosis를 예로 들면, 6월에 출시된 이후 충분한 사용자 기반을 확보했으며, 4,900만 달러에서 시작해 12월에는 7억 3,000만 달러가 넘는 유동성 풀을 조성하였습니다. 2022년에는 코스모스 기반 체인 뿐만 아니라 Bitcoin, Ethereum, Polkadot, Celo를 포함한 다른 체인에 연결되어 블록체인 생태계에 더 많은 유동성을 공급할 계획을 가지고 있습니다.
3. IBC 작동 원리
IBC의 동작 원리는 매우 간단합니다. 블록체인 A에서 10개의 ‘X 코인’ 을 블록체인 B로 보내는 경우를 가정해 봅시다. 먼저 이 10개의 X 코인이 체인 A에서 임의로 움직일 수 없도록 ‘잠겨야' 할 것입니다. 그 뒤 ‘X 코인 10개가 블록체인 A에서 움직이지 못하게 잠겼다는 사실'이 체인 A에서 체인 B로 전달됩니다. 그러면 체인 B는 체인 A의 ‘검증인의 집합'이 어떻게 변했는지를 확인합니다. 만약 체인 A의 검증인 2/3가 해당 사실(X 코인 10개가 A 체인 상에서 잠겨 있다)에 서명한 경우 체인 B의 검증인들은 이를 유효하다고 승인하고, 체인 B 상에서 10개의 코인 X를 발행합니다.
체인 A에 잠겨 있는 코인을 풀기 위해서 체인 B에 있는 X 코인 10개를 체인 A로 되돌리는 과정도 유사한 매커니즘이 적용됩니다. 현재 IBC 프로토콜은 이종 블록체인 간의 가치 이동에 최적화되어 있으며, 추후 이종 블록체인 간 로직 이동을 지원할 계획을 가지고 있습니다.
허브(Hubs) 와 존(Zones)
지금까지 우리는 이종 체인 간의 코인 교환을 가능하게 만드는 IBC 프로토콜에 대해서 살펴봤습니다. 그러나 IBC가 강력한 매커니즘을 가지는 이유는, 허브(Hubs)와 존(Zones)의 구조를 통해 높은 신뢰 수준을 유지하면서도 효율적으로 체인을 연결함에 있습니다.
IBC를 바탕으로 블록체인 네트워크를 만든다고 생각해 봅시다. 어떤 방법이 있을까요? 가장 쉽게 떠올릴 수 있는 방법은 네트워크 상에 존재하는 모든 블록체인이 IBC를 통해 서로 직접 연결되는 것입니다. 그러나 이러한 접근 방법은 두 가지의 문제를 가지고 있습니다. 만약 100개의 블록체인이 네트워크 상에 존재하고 이들이 모두 IBC를 통해 서로 직접 연결된다면, 총 4,950개의 연결 지점을 필요로 합니다. 이러한 방법을 사용하는 경우 네트워크 상의 블록체인의 수가 증가하면 연결 지점의 숫자가 기하급수적으로 증가하는 문제가 발생합니다.
체인 A가 코인을 발행한 블록체인으로부터 해당 코인을 직접 전달받는 경우, 오직 한 단계의 신뢰성만 요구됩니다(해당 코인을 발행한 블록체인을 신뢰하면 됩니다). 즉, 체인 A는 오직 코인을 보낸 검증인들이 ‘보낸 수만큼 코인을 잠그지 않거나', ‘이중 지불'을 하지 않을 것임을 믿으면 됩니다. 하지만, 체인 A가 해당 블록체인에서 발행하지 않은 코인을 전달받는 경우 체인 A는 더 높은 신뢰도를 요구 받습니다. 왜냐하면 코인을 받는 체인 A의 입장에서 해당 코인을 신뢰하기 위해서는 ‘코인이 발행된 블록체인에 해당 코인이 제대로 잠겨있고’, ‘해당 코인이 거쳐온 모든 블록체인에서 더블 스팬딩이 하나도 없다’라는 전제 조건을 신뢰해야 하기 때문입니다. 코인이 거쳐온 블록체인의 숫자가 증가할수록 해당 코인을 받는 블록체인은 더 많은 신뢰성을 요구받습니다. 이것은 현실적이지 않습니다. 이러한 문제를 막기 위해 코인이 생성된 블록체인에서 해당 코인의 잠김을 푼 뒤 다시 다른 블록체인에 보내는 방법을 사용할 수 있습니다(무조건 코인을 발행한 블록체인에서 보내는 코인만 받는 방식). 하지만 이것보다 더 좋은 해결 방법이 있습니다.
이러한 문제를 풀기 위해서 코스모스는 두 가지 형태의 블록체인(허브와 존)을 모듈화한 구조를 제안합니다. 존(Zone)은 일반적으로 존재하는 서로 다른 블록체인을 의미하고, 허브(Hubs)는 존을 연결하는 특별한 블록체인을 의미합니다. 하나의 존이 허브와 IBC를 통해 연결되면, 이 존은 허브에 연결된 다른 존들과 코인을 교환할 수 있게 됩니다. 이로써 각 존은 제한된 숫자의 허브와 제한된 숫자의 IBC 연결만 유지하면 됩니다. 이로써 허브는 존들의 더블 스팬딩을 막을 수 있고, 각 존은 다른 코인을 받을 때 연결된 허브와 그 코인이 생성된 존만 신뢰하면 됩니다.
이러한 IBC의 매커니즘에 대해 Tedermint CEO인 Peng Zhong은 다음과 같은 비유를 들어 평가합니다. “현재의 모든 블록체인은 드넓은 군도 속의 작은 섬에서 살고 있습니다. IBC는 선박을 만드는 새로운 기술이며, 각 섬에 사는 부족이 다른 섬으로 이동할 수 있게 만들어 줍니다. 블록체인이 IBC로 연결되는 순간, 사람들은 자유롭게 여행하고 각 섬에서 전문적으로 만들어지는 물품을 무역을 통해 거래할 수 있습니다.”
4. IBC Low Level 분석
- Channel State Machine
IBC는 모듈이 채널을 통한 패킷 흐름을 처리하기 위해 callback을 구현할 것으로 예상합니다. 모듈 A와 모듈 B가 연결되면 Relayer는 채널에서 패킷을 중계하고 확인된 내용을 응답할 수 있습니다.
패킷이 성공적으로 작동한다면, 다음의 흐름을 따라갑니다.
- 모듈 A는 IBC 모듈을 통해 패킷을 전송합니다.
- 패킷이 모듈 B에 의해 수신됩니다.
- 모듈 B가 패킷에 대한 승인을 작성하면 모듈 A는 승인을 처리합니다.
- 패킷이 정해진 시간 내에 성공적으로 수신되지 않으면 모듈 A는 패킷의 타임아웃을 처리합니다.
2. 패킷 전송
모듈은 IBC 모듈로 패킷을 보내고, 콜백을 통해 패킷을 보내지 않습니다. 이는 다른 패킷 흐름에서 IBC 모듈을 통해 수신된 메시지가 콜백을 통해 포트 바인딩된 모듈에서 실행을 처리하는 것과는 차이가 있습니다. 패킷을 보내기 위해 모듈은 간단하게IBCChannelKeeper에 있는 SendPacket을 호출합니다.
3. 패킷 수신
수신된 패킷을 처리하려면 모듈에서 OnRecvPacket콜백을 실행해야 합니다. 이는 패킷의 유효성이 검증되고 IBC Keeper에 의해 올바르게 처리된 후 IBC 모듈에 의해 호출됩니다. 따라서 OnRecvPacket콜백은 패킷이 유효한지 여부를 고려하지 않고 주어진 패킷 데이터에 대해 적절한 상태로 변경하는 것을 수행하면 됩니다.
모듈은 승인을 바이트 문자열로 IBC Handler에 반환하게 됩니다. 그런 다음 IBC Handler는 이 패킷 승인을 커밋하여 Relayer가 발신한 모듈로 승인 여부를 다시 전달할 수 있도록 합니다.
이 콜백 중에 발생한 상태 변경은 다음과 같은 경우에만 기록됩니다.
Success()함수에 표시된 대로 승인이 성공한 경우- 반환된 승인 값이 비동기화 프로세스가 발생하고 있음을 나타내는 ‘nil’인 경우
비동기된 승인을 처리하는 애플리케이션은 적절한 시점에 상태 변경을 복구하는 작업을 해야 합니다. OnRecvPacket콜백 중에 발생한 모든 상태 변경은 비동기화 승인을 위해 기록됩니다.
4. 패킷 확인
모듈이 승인을 처리한 후 Relayer는 승인을 발신자 모듈로 다시 전달합니다. 그런 다음 발신자 모듈은 OnAcknowledgementPacket콜백을 사용하여 승인을 처리합니다. 승인 내용은 패킷 데이터와 마찬가지로 전적으로 채널의 모듈에 달려 있습니다. 그러나 패킷 처리가 실패한 경우, 패킷이 성공적으로 처리되었는지 여부와 함께 수정에 필요한 추가 데이터에 대한 정보가 포함될 수 있습니다.
모듈은 패킷 데이터 및 승인에 대한 encoding/decoding 표준을 따를 책임이 있으므로 IBC는 콜백에 대한 승인을 []byte타입으로 전달합니다. 콜백은 승인을 decoding하고 처리합니다
References
- Cosmos Docs (https://v1.cosmos.network/resources/whitepaper)
- Cosmos Blog (https://blog.cosmos.network/ibc-update-the-internet-of-blockchains-is-growing-fast-dae883228ebf)
- Cosmos Blog (https://blog.cosmos.network/understanding-the-value-proposition-of-cosmos-ecaef63350d)
- IBC-Go https://ibc.cosmos.network/main/ibc/apps.html
XCMP
1. 개요
XCMP(Cross-Chain Message-Passing)는 폴카닷(Polkadot)의 크로스 체인 메시지 전달 프로토콜로, 각 파라체인은 XCMP를 통해 메시지를 송수신하고 있습니다. Polkadot은 서로 다른 목적을 가진 파라체인들에서 각각 병렬적으로 트랜잭션을 처리하고, 이를 Polkadot의 메인 체인인 릴레이체인으로 제출하여 릴레이체인의 검증인이 이를 완결하는 형태로 구성되어 있습니다. 본 절에서는 체인 외부에서 오는 데이터를 참조하고, 내부 논리에 따라 체인이 작동한다는 점에서 트랜잭션과 거의 같은 방식으로 메시지라는 용어를 사용하도록 하겠습니다. 한편, XCMP의 프로토콜은 다음의 개념을 모두 포함하고 있습니다.
- 합의의 관점 : 메시지의 대기열 및 순서 지정을 위한 매커니즘
- 릴레이 체인의 나머지 부분과 연결성의 관점(특히 GRANDPA 완결성) : 데이터 가용성
- 파라체인 유효성 검사의 관점 : 메시지 입출력
XCMP는 파라체인 사이에서 메시지를 교환하는 주체를 Collator라고 하며, Collator의 수는 파라체인마다 다르게 구성되어 있습니다. XCMP의 메시지 발생 여부 자체는 릴레이체인의 검증인이 확인하는데, 릴레이체인의 검증인은 2022년 1월 7일 기준 297명으로 알려져 있습니다. XCMP는 파라체인 간 메시지 전달에 활용되고 메시지의 메타데이터는 릴레이체인을 통해 검증되므로, 릴레이체인 레벨에서의 공격이 이루어져야만 자금을 탈취할 수 있습니다. 이에 따라 높은 수준의 탈중앙성을 확보하고 있다고 볼 수 있습니다.
2. 특징
Web 3 재단에 의하면, XCMP의 체계는 Trustlessness, Consistency, Availability, Maintaining the right ordering, Efficiency의 속성을 확보하고 있습니다.
Trustlessness는 검증인의 집합이 하나의 파라체인을 보호하는 동시에 올바른 메시지 전달을 보장하여 단일 블록체인보다 더 많은 신뢰를 요구하지 않는다는 것을 의미합니다. Consistency는 수신된 메시지가 정확히 전송되었음을 절대적으로 보장하는 것을 의미합니다(체인이 다시 구성되는 경우에도 마찬가지입니다). Polkadot의 메시지가 손상되지 않고 계속 사용 가능하다는 점에서 Availability가 확보되며, 삭제된 코딩 조각을 배포하여 메시지를 재구성함으로써 달성됩니다. 파라체인 블록에 의해 출력되는 메시지가 Maintaing the right ordering하는 것은 Input/Output 유효성 검사에 의해 보장됩니다. 마지막으로 Efficiency는 과도한 오버헤드를 방지하고 메시지가 가능한 빨리 도착할 수 있도록 함을 의미합니다. 이와 더불어 기본적으로 XCMP 프로토콜에 대한 수수료가 부과되지 않는다는 점에서 경제적입니다. 다만 파라체인에 따라 수수료가 부과되는 경우도 있습니다.
3. XCMP의 작동 방식
XCMP를 사용하면 동일한 릴레이체인 상에 있는 파라체인끼리 메시지를 주고 받을 수 있습니다. 크로스체인 트랜잭션은 머클 트리(Merkel Tree) 기반의 간단한 대기열 매커니즘을 사용하여 정확성을 보장합니다. 머클 트리는 블록에 포함된 트랜잭션을 트리 형태로 요약한 자료구조로, 블록체인의 효용성 향상에 크게 기여한다는 장점을 가집니다. 하나의 파라체인 출력 대기열에 있는 트랜잭션을 수신 파라체인의 입력 대기열로 옮기는 것은 릴레이체인 검증인의 업무입니다. 그러나 릴레이체인 저장소에 저장되는 것은 연관된 메타 데이터만 해당되며, 이는 해시 값으로 저장됩니다.
메시지의 대기열 순서 지정
Polkadot의 모든 파라체인 블록은 다른 블록으로 라우팅할 빈 메시지 목록을 생성합니다. 이를 송신 대기열(egress queue)라고 합니다. 메시지가 라우팅되면 파라체인의 수신 대기열(ingress queue)에 들어갑니다. 파라체인은 수신 대기열에 있는 순서대로 메시지를 처리합니다. 특정 파라체인의 송신 대기열에 대한 메시지를 수집하고자 하는 Collator 또는 Validator는 해당 파라체인에 대한 수신 대기열을 호출하고, 아직 전달되지 않은 메시지를 기다리게 됩니다.
메시지 전달 (공통 노드가 존재하는 경우)
각 파라체인에 대해 풀노드가 연결된 네트워크를 떠올려 봅시다. 각 풀노드가 시스템에 속한 다른 풀노드(인접 노드)의 하위 집합을 알고 있다고 가정해 보겠습니다. 이러한 네트워크의 위치 및 상태, 크기에 대해서는 어떠한 가정도 하지 않습니다. 메시지를 전달하는 가장 간단한 방법은 Gossip protocol을 활용하는 것입니다. Collator 노드는 파라체인에 필요한 모든 정보를 유지하며, 현재의 상태에 대한 자신의 견해를 지속적으로 소통하고 있습니다. 더욱 효율적인 전송을 위해, 라우팅되지 않은 메시지는 동일한 뷰를 가진 인접 노드에만 확산됩니다.
두 네트워크 사이에 공통 노드가 있는 경우 메시지는 한 파라체인 네트워크에서 다른 파라체인 네트워크로 전달될 것입니다
Fallback delivery (공통 노드가 존재하지 않는 경우)
만약 수신 파라체인의 검증인이 메시지가 수신 파라체인에서 확산되지 않았다는 것을 알게 되면, 송신 파라체인의 검증인에게 메시지를 요청합니다. 일단 수신이 이루어지면 수신 파라체인 네트워크에서 해당 메시지를 확산합니다.
Fallback delivery의 배커니즘은 그림 3을 통해 확인할 수 있습니다. 여기서 파라체인 A는 공통 풀노드를 공유하지 않는 파라체인 C에 메시지를 보내려고 한다고 가정하고 있습니다. 파라체인 C의 검증인이 ‘메시지가 도착하지 않았다는 사실’을 알게되면 파라체인 A에서 발신되는 메시지를 보관할 책임이 있는 검증인에게 요청을 보냅니다. 요청에 대한 응답이 도착하면, 파라체인 C의 검증인은 C 내에서 메시지를 확산합니다.
입출력 검증
다음으로는 파라체인에서 입력과 출력값에 대한 검증이 이루어지는 방식을 살펴보겠습니다. 파라체인은 State-Transition Verification Function(STVF)을 사용하여 입력 메시지가 작동하는지를 확인합니다. 유효성 검사 기능은 파라체인의 상태 변화가 실제로 유효한지를 검증하는 웹어셈블리의 한 부분으로 볼 수 있습니다. 이는 파라체인의 상태와 출력 메시지의 집합을 이전 상태 요약, 파라체인 블록 데이터 및 다른 파라체인 혹은 릴레이 체인에서 라우팅된 입력 메시지의 집합과 연관시키는 역할을 합니다.
위의 이미지는 파라체인 A, B, C 사이에서 생성된 파라체인 블록과 메시지가 Round 0, 1, 2에 대해 표시되는 예를 보여줍니다. 파라체인 B는 Round 0에서 블록을 생성하지 않고, 파라체인 C는 Round 1에서 생성하지 않는다고 가정해 봅시다. Round 1에서 생성된 파라체인 블록 B0은 메시지 m1을 입력값으로 받아 파라체인 A에게 m3을 전송하여 야 합니다. Round 2에서 생성된 파라체인 블록 C1은 메시지 m2를 받아야 하며, m4는 처리되지 않은 상태로 입력 대기열에 남아 있습니다.
4. XCMP 메시지 형식
메시지 전달이 일어날 때는 XcmpMessageFormat 인터페이스를 따라야 합니다. 여기에는 isConcatenatedVersionedXcm,isConcatenatedEncodedBlob , isSignals여부를 확인하는 변수와 type을 지정하는 변수가 포함됩니다.
References
- Polkadot Wiki (https://wiki.polkadot.network/docs/learn-crosschain)
- Web3 Foundation Medium (https://medium.com/web3foundation/polkadots-messaging-scheme-b1ec560908b7)
Rainbow Bridge
1. 개요
Rainbow Bridge는 Near Foundation이 2020년 8월 개발한 bridge 서비스로, 이더리움, NEAR, AURORA 네트워크의 자산들을 다양한 체인들로 전송할 수 있는 기능을 제공하고 있습니다. Rainbow Bridge는 Dex 토큰, Wrapped 토큰, 스테이블 코인, 랜딩 토큰 등 다양한 자산들의 전송 기능을 제공합니다.
Rainbow는 트랜잭션을 처리하는 메인 체인의 보안성에 의존하는 Trustless 구조입니다. 따라서 중개인의 수가 크게 중요하지 않으며, 해킹을 시도하려면 메인 체인 합의 레벨에서 공격이 이루어져야 한다는 점에서 해킹의 기술적 난이도가 매우 높다고 평가할 수 있습니다. 따라서, 중개인의 수나 중개인 각각의 신뢰도가 중요하지 않기 때문에, 중개인이 되기 위한 특별한 조건을 없습니다. 누구나 중개인으로 활동할 수 있기 때문에 중개인으로서의 진입장벽은 낮으며, 탈중앙화 정도도 높다고 평가할 수 있습니다.
2. 특징
Rainbow Bridge의 성능은 수수료 속도, 유동성 조정의 측면에서 평가가 가능합니다. 가장 먼저 수수료의 경우, Rainbow Bridge 공식 사이트에 따르면 통상적으로 $0.01의 수수료를 트랜잭션을 처리하는 Near 네트워크에 지불합니다. 다만, 송수신하는 체인에 수수료를 지불해야 하면, 그 체인의 완결성과 성능에 따라 전송 속도가 상이합니다. ERC-20 토큰을 이더리움에서 Near로 전송할 때는 41K(약 $10) gas와 6분 정도의 시간이 소요됩니다. 반면, Near 토큰을 이더리움으로 전송할 때에는 300K(약 $60)의 수수료와 최대 16시간이 소용됩니다 이는 Near에서 검증에 활용하는 Optimistic 검증 절차로 인한 시간 지연입니다.
Rainbow Bridge의 경우에도 Lock-and-Mint 방식을 활용하기 때문에 자산을 이동시키기 위해 유동성을 고려할 필요가 없습니다. 사용자는 원하는 ERC-20 자산 또는 Near 프로토콜의 자산을 bridge에 Lock하고, bridge는 그에 상응하는 가치의 토큰을 발행하게 됩니다. 그 과정에서 Relayer Watchdog이라는 Player가 트랜잭션의 유효성을 검증하게 됩니다.
Trustless 구조의 경우 다른 구조의 bridge보다 보안성이 우수합니다. 실제 Rainbow Bridge는 해킹당한 사례가 없습니다.
Rainbow Bridge는 FT뿐만 아니라 NFT와 오라클 데이터를 주고받을 수 있습니다. 또한, Near, Aurora, Ethereum 간 자산 이동을 지원한다는 점에서 범용성이 높다고 평가할 수 있습니다.
이러한 장점들에 힘입어 Rainbow Bridge는 빠르게 성장하고 있습니다. 2022년 1월 27일 기준 $0.8B의 TVL을 기록하고 있습니다. 관련 정보는 bridge 별 TVL 정보를 제공하고 있는 사이트(https://dune.xyz/queries/147739/291036)에서 확인이 가능합니다.
Rainbow Bridge는 Near Protocol에서 암호학적으로 증명할 수 있는 어떤 정보든 이더리운 네트워크에서 이용할 수 있고, 그 반대의 경우도 가능하게 한다는 점에서 제너릭한 프로토콜입니다.
4. Rainbow Bridge Low Level 분석
FT 브리지 예시
레인보우 브리지에서 토큰을 전송하기 위해서는 자산을 보낼 주소를 생성해야 합니다. 이는 사용자가 가입한 Near 계좌의 하위 계좌입니다.
near create-account bob.$ID --masterAccount $ID --initialBalance 1이제 Bob의 계좌에서 deposit storage를 생성합니다.
near call $ID storage_deposit '' --accountId bob.$ID --amount 0.00125계좌의 잔액을 확인하기 위해서는 다음과 같은 함수를 사용합니다.
near view $ID ft_balance_of '{"account_id": "'bob.$ID'"}'Bob의 계좌에서 토큰을 전송하기 위해서는 transfer 함수를 이용합니다.
near call $ID ft_transfer '{"receiver_id": "'bob.$ID'", "amount": "19"}' --accountId $ID --amount 0.000000000000000000000001
