크로스체인 커뮤니케이션 프로토콜 (CCCP)

소개

바이프로스트 네트워크의 크로스체인 커뮤니케이션 프로토콜 (CCCP)은 소켓 컨트랙트와 릴레이어 간의 긴밀한 상호작용을 통해 크로스체인 통신을 구현합니다. CCCP를 활용하면 한 블록체인의 사용자가 다른 블록체인에서 제공하는 디앱을 원활하게 이용할 수 있습니다.

소켓 컨트랙트는 바이프로스트 네트워크를 비롯해 이더리움 (Ethereum)과 같은 모든 외부 체인에 배포되는 핵심 시스템 컨트랙트입니다. 한 소켓 컨트랙트에서 CCC 요청 (CCC-Request)이 발생하면, 해당 컨트랙트는 CCC 이벤트 (CCC-Event)를 발생시키고, 이 이벤트는 릴레이어를 거쳐 다른 소켓 컨트랙트로 전송됩니다. 사용자 요청은 CCC-Event 형태로 여러 소켓 컨트랙트를 순차적으로 거치며, 필요한 모든 로직이 실행되면 비로소 완료됩니다.

복수의 릴레이어가 동시에 소켓 이벤트를 전송하므로, 일부 릴레이어에 장애가 발생하거나 보안 위협을 받더라도 프로토콜의 지속성을 유지할 수 있습니다. 또한, 모든 릴레이어가 동시에 실패하는 극단적인 상황에서도 "타임아웃 롤백 (Timeout Rollback)" 기능을 통해 사용자 자산이 소켓 컨트랙트에 영구적으로 묶이는 것을 방지합니다. 이처럼 효율적인 설계는 상대적으로 비용이 높은 외부 블록체인으로 전달되는 트랜잭션 수를 최소화하여, 릴레이어 그룹의 전체 운영 비용을 크게 절감하는 효과를 가져옵니다.

부록

• CCC Protocol (CCCP): 크로스체인 커뮤니케이션 프로토콜

• VS Protocol (VSP): 검증자 동기화 프로토콜

• Validator: 바이프로스트 네트워크의 합의 검증 노드

• Relayer: 바이프로스트 네트워크에서 CCC 프로토콜 작업을 수행하는 노드

• CCC-Request: 외부 블록체인에 배포된 f(x) 함수를 호출하기 위해 생성한 요청

• CCC-Event: CCC 요청의 세부 정보를 담고 있는 CCCP 메시지 (소켓 컨트랙트의 이벤트)

• External Chain: 바이프로스트 네트워크 외의 모든 블록체인 (예: Ethereum, BNB Chain, Polygon 등)

• f(x): 외부 블록체인에서 실행되도록 사전 정의된 함수 (스마트 컨트랙트)

• Positive status: "성공"을 나타내는 CCC 상태 (REQUESTED, EXECUTED, ACCEPTED, COMMITTED)

• Negative status: "실패"를 나타내는 CCC 상태. 각 상태는 대응되는 Positive 상태와 쌍을 이룸 (FAILED, REVERTED, REJECTED, ROLLBACKED)

컴포넌트 구성

사용자는 소켓 컨트랙트에 CCC 요청을 보내 다른 블록체인에 존재하는 f(x) 함수를 호출할 수 있습니다. 이때 f(x) 함수는 암호화폐 결제를 필요로 하므로, 소켓 컨트랙트가 사용자의 암호화폐를 안전하게 저장합니다.

릴레이어는 다음 데이터를 소켓 컨트랙트로 전달합니다:

• 현재 검증자 (릴레이어) 목록: 릴레이어는 모든 외부 체인에 최신 검증자 목록을 전달하며, 이는 각 블록체인이 접근 제어에 활용합니다.

• 오프체인 데이터: 특정 자산 가격이나 비트코인 블록체인의 블록 해시와 같은 오프체인 데이터는 바이프로스트 네트워크의 소켓 컨트랙트로 전달됩니다. 오라클 매니저 컨트랙트는 소켓 컨트랙트로부터 이 데이터를 받아 오라클 서비스를 제공합니다.

• CCC-Event: 릴레이어는 지원되는 모든 블록체인 네트워크에서 CCC-이벤트를 감지하고, 이를 해당 소켓 컨트랙트로 전달합니다. 이 과정에서 소켓 컨트랙트 정보는 CCC-이벤트에서 파생될 수 있습니다.

시스템 컨트랙트

바이프로스트 네트워크는 세 가지 주요 시스템 컨트랙트를 지원합니다.

• 소켓 컨트랙트: 다른 소켓 컨트랙트가 처리할 CCC 이벤트를 생성하거나, 다른 소켓 컨트랙트에서 발생한 CCC 이벤트를 수신하여 처리합니다. 특히, 명시된 요청에 따라 프로토콜 사양에 따른 작업(예: 민팅, 대출, 레버리지 투자 등)을 실행합니다.

• 내장형 DeFi 스위트: DeFi 스위트 함수는 f(x)로 추상화되어 표현됩니다.

• 오라클 매니저 컨트랙트: 지정된 오프체인 데이터를 수집하고 온체인 오라클 서비스를 제공합니다.

프로토콜 디자인

다음의 설계 요소들은 스마트 컨트랙트 실행 환경의 한계를 극복하기 위해 CCCP에 적용되었습니다.

설계 요소

• 스마트 컨트랙트는 충분한 데이터 저장 공간을 제공하지 않으므로, 전체 데이터 대신 데이터의 해시만 저장합니다. 데이터를 재사용해야 할 경우 다시 전송해야 합니다. 이는 해시값을 비교하는 것이 데이터를 초기 저장하는 것보다 비용 효율적이기 때문입니다.

• 트랜잭션의 원자적 특성으로 인해 트랜잭션이 실패할 수 있습니다. 이러한 경우, 스마트 컨트랙트에 실패 상태를 기록하기 위해 해당 "실패"를 나타내는 다른 트랜잭션을 다시 전송해야 합니다.

• 스마트 컨트랙트는 배열 정렬이나 키/값 반환 매핑과 같은 내장 기능을 제공하지 않으며, 이러한 기능을 구현하는 것은 트랜잭션 수수료 측면에서 비효율적입니다. 따라서 트랜잭션 발신자는 스마트 컨트랙트가 별도로 정렬할 필요가 없도록, 이미 정렬된 배열 데이터를 전송해야 할 수 있습니다.

• 상대적으로 높은 수수료를 부과하는 외부 체인으로 전달되는 트랜잭션 수를 최소화합니다. 릴레이어 그룹이 CCC 이벤트를 외부 체인에 전달할 때, 먼저 서명과 함께 CCC 이벤트가 바이프로스트 네트워크에 제출됩니다. 그런 다음 기본 릴레이어가 모든 서명을 취합하여 외부 체인에 한 번에 전달합니다.

VSP (Validator Synchronization Protocol)는 CCCP의 하위 프로토콜로, 바이프로스트 네트워크의 최신 검증자 목록을 모든 외부 체인과 동기화합니다. 네트워크의 검증자는 주기적으로 변경될 수 있으므로, 소켓 컨트랙트가 접근 제어에 사용하는 검증자 정보는 항상 최신 상태로 유지되어야 합니다.

전제 조건

다음은 릴레이어 운영의 기본 전제 조건입니다.

• 릴레이어는 모든 CCC 이벤트를 모니터링합니다.

• 릴레이어는 트랜잭션 수수료로 충분한 양의 네이티브 코인 (예: BFC, ETH, BNB)을 보유합니다.

• 릴레이어가 요청을 위조할 경우 페널티가 부과됩니다. (릴레이어는 소액의 이익을 위해 프로토콜에 해를 끼치지 않습니다.)

• 대다수의 릴레이어는 프로토콜을 충실히 실행합니다. (셧다운 상태이거나 요청 위조 공격을 수행하는 릴레이어의 수는 항상 과반수보다 적습니다.)

• 이전 CCC 이벤트의 누적이 이후 CCC 이벤트 생성에 실패를 유발하지 않습니다.

• 릴레이어는 어떤 이유로든 위임이 해제되더라도 위임된 시간 동안 생성된 모든 이벤트를 처리합니다.

  • 릴레이어는 자신의 임기 동안 발생하는 모든 요청을 처리합니다.

  • 바이프로스트 네트워크는 다음 검증자 세트를 릴레이합니다.

위에 명시된 조건이 지켜지지 않을 경우, 해당 릴레이어에게는 페널티가 부과됩니다.

인바운드 CCCP

인바운드 (Inbound) 프로토콜은 외부 체인에서 바이프로스트 네트워크로 CCC 요청을 전달하는 방식을 보여줍니다. 아래 그림은 인바운드 프로토콜의 CCC 이벤트 흐름을 나타냅니다. 각 릴레이에 표시된 "릴레이 유형 (Relay Type)"은 "두 가지 유형의 릴레이 투표" 섹션에서 자세히 설명합니다.

외부 체인의 소켓 컨트랙트로 전송된 각 사용자 요청은 순차적으로 "REQUESTED", "EXECUTED'", "ACCEPTED" 상태를 거쳐 최종적으로 "COMMITTED" 상태로 완료됩니다. 하지만 페이즈 1의 f(x) 실행이 실패하면, 요청은 "REQUESTED", "REVERTED", "REJECTED" 상태를 거쳐 'ROLLBACKED' 상태로 종료됩니다. "ROLLBACKED" 상태로 완료된 요청은 사용자 트랜잭션 중에 수집된 토큰을 반환합니다.

아웃바운드 CCCP

아웃바운드 (Outbound) 프로토콜은 바이프로스트 네트워크에서 외부 체인으로 사용자 요청을 전달하는 방식을 나타냅니다. 아래 그림은 아웃바운드 프로토콜의 CCC 이벤트 흐름을 보여줍니다. 각 릴레이에 표시된 "릴레이 유형"은 "두 가지 유형의 릴레이 투표" 섹션에서 자세히 설명하고 있습니다.

외부 체인의 소켓 컨트랙트에 전달된 각 사용자 요청은 순차적으로 "REQUESTED", "ACCEPTED", "EXECUTED" 상태를 거쳐 최종적으로 "COMMITTED" 상태로 완료됩니다. 하지만 페이즈 2의 f(x) 실행이 실패할 경우, 요청은 "REQUESTED", "REVERTED", "REJECTED" 상태를 거쳐 "ROLLBACKED" 상태로 종료됩니다. "ROLLBACKED"으로 완료된 요청은 사용자의 트랜잭션 중에 수집된 토큰을 반환합니다.

검증자 동기화 프로토콜 (Validator Synchronization Protocol, VSP)

VSP는 지원되는 모든 외부 체인의 모든 소켓 컨트랙트에 바이프로스트 네트워크의 검증자 (=릴레이어) 세트에 대한 업데이트된 정보를 전달합니다. 소켓 컨트랙트는 전달받은 검증자 세트로 접근 권한 목록을 업데이트합니다.

이 프로토콜은 아웃바운드 프로토콜의 1단계 및 2단계와 유사하게 작동합니다.

두 가지 릴레이 투표 유형

CCC 요청은 데이터 위조 위험을 낮추기 위해 여러 릴레이어에 의해 전달됩니다. 하지만 유효한 CCC 이벤트가 두 개의 다른 블록체인에 동시에 전달되면, 사용자 자산이 양쪽에서 증가하거나 감소하는 문제가 발생할 수 있습니다. 예를 들어, 5개의 릴레이어 중 쿼럼(정족수)이 3개인 상황을 가정해 봅시다. 이더리움에서 민팅(Minting)하는 CCC 이벤트 트랜잭션을 전송할 때, 릴레이어 2개는 성공하고 3개는 실패할 수 있습니다. 이 경우 "실패한 릴레이어"는 Bifrost 네트워크로 CCC 이벤트 트랜잭션을 전송하고, 사용자는 이더리움으로 환불을 받습니다. 그러나 만약 "실패한 릴레이어" 중 하나가 민팅 트랜잭션을 다시 전송하여 성공한다면, Bifrost 네트워크의 사용자 자산이 증가하여 "이중 지급"이 발생하게 됩니다. 이처럼 단 하나의 악의적인 릴레이어가 프로토콜 실패를 유발할 수 있습니다.

위와 같은 상황은 소켓 컨트랙트가 다음 단계로 진행하기 전에 CCC 이벤트 처리 결과를 명확하게 확정하지 않았기 때문에 발생합니다. 따라서 CCC 요청은 이벤트를 발행하기 전에 각 단계에서 하나의 상태로 확정되어야 합니다. 릴레이어는 다음 상태의 CCC 이벤트가 감지되었을 때만 다음 단계로 진행해야 합니다.

프로토콜의 각 단계는 아래 설명된 유형 메서드 중 하나를 통해 소켓 컨트랙트에 릴레이 투표를 전달합니다. 또한, 릴레이 투표 결과로 특정 함수 f(x)를 실행하는 단계의 경우, "CCC 트랜잭션 실패 복구 메커니즘"이 추가적으로 적용됩니다.

CCC 트랜잭션 실패 복구 매커니즘

특정 함수 f(x)가 실행되는 단계 (예: 인바운드 페이즈 1 또는 아웃바운드 페이즈 2)에서, 릴레이어가 유효한 CCC 이벤트를 전달하더라도 f(x)의 로직 오류로 인해 트랜잭션이 실패할 수 있습니다. 그러나 트랜잭션의 원자성 특성상, 실패한 트랜잭션은 소켓 컨트랙트에 영향을 주지 못하므로 "실행 실패" CCC 이벤트가 발생할 수 없습니다.

따라서 릴레이어는 CCC 이벤트 상태를 "실패 (negative)"로 설정하고 이를 소켓 컨트랙트로 전송합니다. 소켓 컨트랙트가 다수의 릴레이어로부터 실패 CCC 이벤트를 수신하면, "실행 실패" CCC 이벤트를 발생시키고 프로세스를 다음 단계로 강제 진행합니다. (실패 상태는 성공 상태로 복구될 수 없습니다.)

또한, 트랜잭션의 비동기적 특성으로 인해 다음 상태의 CCC 이벤트 발생 시점을 예측하기 어렵습니다. 예를 들어, 5개의 릴레이어 중 2개는 '성공 (positive)' CCC 이벤트를, 나머지 2개는 '실패' CCC 이벤트를 발생시키는 상황이 발생할 수 있습니다. 이때 잔여 릴레이어가 동작하지 않으면 해당 CCC 이벤트는 처리되지 못합니다. 이 사례는 단 하나의 릴레이어로 인해 프로토콜이 어떻게 중단될 수 있는지를 보여줍니다.

이러한 문제점을 해결하기 위해, '성공' 상태에 투표했던 릴레이어는 t초 후 해당 요청이 '성공' 상태로 최종 확정되었는지 확인합니다. 만약 확정되지 않았다면, 릴레이어는 기존의 CCC 이벤트를 '실패' 상태로 변경하여 재전송합니다. 결과적으로 모든 CCC 이벤트는 항상 t초 이내에 처리됨을 보장합니다. (위 예시의 경우, 최종 상태는 '실패'로 확정됩니다.)

그림 설명

1. 각 릴레이어는 감지된 "성공 (positive)" 상태의 이벤트를 다음 소켓 컨트랙트에 전달합니다.

   1. 트랜잭션 성공 → 타이머 설정

   2. 트랜잭션 실패 → 이벤트를 부정 상태로 변경하고 재전송

2. 타임아웃 → 이벤트를 "실패 (negative)" 상태로 변경하고 재전송

각 상태에 대해 소켓 컨트랙트는 과반수에 도달하는 n번째 릴레이 투표 트랜잭션에서 f(x)를 실행하고 다음 CCC-이벤트를 전송합니다.

유형 1: 일반 릴레이

결과 로직에 f(x)가 없는 단계의 경우, 각 릴레이어는 트랜잭션을 통해 CCC 이벤트를 전달하기만 하면 됩니다.

그림 설명

1. 모든 릴레이어는 감지된 이벤트를 다음 소켓 컨트랙트에 전달합니다.

소켓 컨트랙트는 과반수에 도달하는 n번째 릴레이 투표 트랜잭션에서 다음 CCC 이벤트를 전송합니다.

유형 1-1: 서명이 포함된 일반 릴레이

릴레이어는 "유형 1: 일반 릴레이"를 실행하기 위해 서명을 추가로 첨부합니다. 소켓 컨트랙트는 첨부된 서명을 저장하며, 나중에 소켓 컨트랙트에서 일괄적으로 조회할 수 있습니다.

유형 2: 릴레이어 서명 집계 및 통합 전송

모든 릴레이어가 상대적으로 높은 수수료를 지불하고 외부 체인에 CCC 이벤트를 전달하는 대신, 하나의 기본 릴레이어가 모든 릴레이어의 서명을 취합하여 CCC 이벤트를 발행합니다. (기본 릴레이어가 지정되면 다른 릴레이어는 자동으로 보조 릴레이어로 간주됩니다).

기본 릴레이어의 실패가 프로토콜의 실패로 이어지지 않도록 하기 위해 보조 릴레이어는 t초 후에 CCC 이벤트가 성공적으로 전송되었는지 여부를 확인합니다. 전송되지 않은 경우 모든 보조 릴레이어가 기본 릴레이어의 역할을 맡아 CCC 이벤트를 전송합니다.

그림 설명

1. 기본 릴레이어 인덱스를 계산합니다: (이벤트가 포함된 블록의 높이) % (총 검증자 수). 계산된 기본 릴레이 인덱스가 있는 릴레이가 기본 릴레이로 지정됩니다. (나머지는 보조 릴레이어가 됩니다.)

2. 보조 릴레이어

   1. 이전 단계에서 제출된 릴레이어의 서명 값에 대한 소켓 컨트랙트를 조회합니다.

   2. 과반수 서명을 첨부하여 다음 소켓 컨트랙트에 전달합니다.

3. 보조 릴레이어

   1. 기본 릴레이의 성공적인 이벤트 전송을 t초 후에 확인할 수 없는 경우 대신 기본 릴레이 프로세스를 실행합니다.

소켓 컨트랙트는 수신된 서명의 과반수를 확인하면 다음 CCC 이벤트를 생성합니다.

애플리케이션 (Applications)

CCCP는 외부 체인 사용자들이 바이프로스트 네트워크의 디앱 서비스를 원활하게 이용할 수 있도록 지원합니다.

예를 들어, 바이프로스트 네트워크에 배포된 f(x) 함수가 "Lending::Deposit"이라고 가정해 보겠습니다. 이 경우, 이더리움 사용자는 단순히 이더리움 소켓 컨트랙트에 토큰을 입금하는 것만으로 바이프로스트 네트워크의 대출 서비스에 자동으로 토큰이 예치됩니다. 또 다른 예시로, 바이프로스트 네트워크의 f(x) 함수가 "Swap"이라고 가정하면, 사용자는 인바운드 프로토콜을 통해 이더리움의 토큰 A를 예치하여 바이프로스트 네트워크에서 토큰 B를 획득한 후, 아웃바운드 프로토콜을 통해 아발란체 (Avalanche)의 토큰 B를 인출할 수 있습니다. 이러한 과정은 크로스체인 스왑을 효율적으로 구현합니다.

궁극적으로, 바이프로스트 네트워크의 CCCP는 사용자에게 상대적으로 낮은 수수료와 빠른 속도로 디파이 (DeFi) 서비스를 이용하고 체인 간 자산을 손쉽게 전송할 수 있는 환경을 제공합니다.