Chainlink CCIP 별도 검증망으로 이중 확인 구조 설계

Chainlink CCIP 별도 검증망으로 이중 확인 구조 설계

Chainlink는 블록체인 간 데이터와 토큰을 이동시키는 Cross Chain Interoperability Protocol CCIP를 구축하면서 주된 메시지 처리 시스템과 별도로 동작하는 Risk Management Network를 설계했다.

기존 CCIP 구조에서 RMN은 직접 크로스체인 거래를 처리하는 네트워크가 아니라 기본 CCIP 시스템이 처리한 메시지를 독립적으로 다시 확인하는 역할을 맡았다. 소스 체인에서 발생한 메시지를 주 네트워크가 확인한 뒤 별도의 노드 집합이 동일한 데이터를 자체적으로 검증하는 방식이었다.

Chainlink는 2023년 CCIP 메인넷 출시 당시 RMN을 주 CCIP 시스템과 독립적으로 운영되는 별도의 네트워크로 소개했다. 노드 구성과 개발팀, 소프트웨어 구현까지 분리해 하나의 시스템에서 발생한 오류가 동일한 형태로 다른 검증 시스템에 나타나는 것을 줄이는 구조를 적용했다.

기존 CCIP에서는 메시지를 두 차례 검증

초기 CCIP 아키텍처에서는 크로스체인 메시지가 목적지 체인에서 실행되기 전에 주 CCIP 네트워크와 RMN이 각각 메시지를 확인했다.

먼저 Committing Decentralized Oracle Network가 소스 블록체인에서 발생한 메시지를 관찰했다. 여러 Chainlink 노드가 데이터를 확인한 뒤 합의를 거쳐 처리 대기 중인 메시지를 Merkle Tree 형태로 묶고 Merkle Root를 생성했다.

이 Commit 결과가 목적지 블록체인으로 전달되는 동안 RMN도 동일한 크로스체인 메시지를 별도로 관찰했다. RMN은 주 네트워크가 만든 결과를 그대로 복사하는 것이 아니라 자체적으로 암호학적 commitment를 생성해 검증 결과를 만들었다.

두 시스템에서 확인된 결과가 일치하면 메시지가 목적지 체인에서 실행될 수 있는 상태가 됐다. Chainlink는 이 두 번째 확인 절차를 secondary approval 또는 blessing으로 불렀다.

RMN은 별도 노드와 별도 코드로 운영

RMN의 독립성은 단순히 같은 프로그램을 다른 서버에서 한 번 더 실행하는 방식이 아니었다.

Chainlink가 공개한 기존 설계에서 RMN을 운영하는 노드 사업자는 CCIP의 주요 트랜잭션 DON에 참여하는 노드 사업자와 겹치지 않도록 구성됐다. 서로 다른 노드 집합이 각각 메시지를 검증하도록 한 것이다.

소프트웨어 구현도 분리됐다. 주 CCIP 시스템은 Go를 중심으로 구축된 반면 RMN은 Rust로 별도 구현됐다. Chainlink Labs 내부에서도 서로 다른 개발팀이 두 시스템을 담당했다.

Chainlink는 이 방식을 항공우주 분야 등에서 사용돼온 N version programming 방식과 연결해 설명했다. 하나의 시스템을 서로 독립적인 여러 방식으로 구현한 뒤 같은 입력에 대해 결과를 비교하는 구조다.

RMN에는 외부 소프트웨어 의존성도 최소화한 별도의 Chainlink 노드 구현이 사용됐다. 주 시스템과 다른 코드베이스를 유지하면서 크로스체인 메시지를 별도로 확인하는 것이 기존 RMN의 핵심 역할이었다.

결과가 다르면 curse로 크로스체인 기능 중단

기존 RMN 구조에는 메시지를 승인하는 blessing과 반대로 CCIP 작동을 멈출 수 있는 curse 기능도 포함됐다.

RMN이 주 CCIP 시스템과 다른 메시지를 확인하거나 비정상적인 크로스체인 활동을 발견하면 Risk Management Contract에 curse 거래를 전달할 수 있도록 설계됐다.

curse가 활성화되면 설정 대상에 따라 특정 체인과 연결된 CCIP 기능 또는 더 넓은 범위의 크로스체인 활동이 중단될 수 있었다. 메시지 처리 과정에 이상이 감지됐을 때 추가 실행을 정지하는 구조다.

각 체인에는 RMN 관련 온체인 계약이 배포됐으며 Router와 OnRamp, OffRamp, Token Pool 등 CCIP 구성요소가 해당 계약의 상태를 확인하도록 설계됐다.

Ronin Wormhole Nomad 해킹 이후 크로스체인 보안 부각

CCIP의 이중 검증 구조는 대규모 크로스체인 브리지 사고가 잇따랐던 시기에 개발됐다.

2022년 3월 Ronin Bridge에서는 밸리데이터 개인키가 탈취되면서 약 6억2400만달러 규모의 자산이 빠져나갔다. 공격자는 당시 9개 밸리데이터 가운데 거래 승인에 필요한 5개의 권한을 확보했다.

같은 해 2월 Wormhole에서는 메시지 검증 과정을 우회하는 취약점이 이용돼 12만 WETH가 비정상적으로 발행됐다. 당시 피해액은 약 3억2600만달러로 집계됐다.

8월 Nomad Bridge에서는 메시지 검증 과정과 관련된 초기화 오류가 발생해 약 1억9000만달러의 자산이 유출됐다. CertiK 집계에 따르면 2022년 발생한 5건의 주요 크로스체인 브리지 공격에서 발생한 손실은 약 13억1700만달러에 달했다.

Ronin과 Wormhole, Nomad는 각각 서로 다른 방식의 취약점을 통해 공격받았으며 Chainlink는 CCIP 개발 과정에서 메시지 검증과 독립적인 리스크 관리 계층을 분리하는 구조를 채택했다.

Rate Limit도 별도 보안 기능으로 적용

CCIP에는 RMN 외에도 일정 시간 동안 이동할 수 있는 토큰 규모를 제한하는 Rate Limit 기능이 적용됐다.

토큰 풀에서는 일정 시간 동안 잠그거나 소각할 수 있는 물량과 반대 체인에서 발행 또는 해제할 수 있는 물량을 제한할 수 있다. 자산과 소스 체인, 목적지 체인에 따라 서로 다른 한도를 설정할 수 있다.

CCIP를 이용해 하나의 체인에서 다른 체인으로 이동할 수 있는 전체 가치에도 별도의 제한을 설정할 수 있도록 설계됐다.

Chainlink는 RMN의 독립 검증과 이상 탐지, Rate Limit을 CCIP 초기 보안 아키텍처를 구성하는 서로 다른 계층으로 운영했다.

CCIP v1.6에서 오프체인 구조 변경

이후 CCIP가 v1.6으로 업데이트되면서 오프체인 아키텍처도 변경됐다.

현재 Chainlink 공식 문서에 따르면 CCIP v1.6에서는 모든 참여 노드가 포함된 하나의 Role DON이 운영된다. 이 노드에서 Commit OCR Plugin과 Executing OCR Plugin이라는 두 가지 기능이 실행된다.

Commit OCR Plugin은 여러 소스 체인의 메시지를 관찰하고 합의를 거쳐 Merkle Root를 포함한 Commit Report를 만든다. 각 소스 체인을 담당하는 노드 그룹이 메시지 범위를 확인하고 필요한 임계치 이상의 관찰값이 확보되면 결과를 생성한다.

최종 Commit Report는 목적지 체인에 기록된다. 하나의 보고서에는 여러 소스 체인에서 생성된 Merkle Root와 수수료 계산에 필요한 가격 정보가 함께 포함될 수 있다.

Executing OCR이 소스 체인 거래 다시 확인

Commit Report가 목적지 블록체인에 기록된 이후에는 Executing OCR Plugin이 실행 대기 중인 메시지를 확인한다.

Executing OCR을 담당하는 노드들은 목적지 체인에 기록된 대기 메시지를 확인하고 이에 대응하는 소스 체인의 이벤트를 검증한다.

검증이 완료되면 여러 메시지를 목적지 체인에서 실행하기 위한 배치를 구성한다. 이 과정에서는 목적지 체인의 가스 한도와 체인별 실행 조건 등이 함께 반영된다.

Chainlink 문서에서는 편의를 위해 Commit 기능을 담당하는 노드를 Committing DON, 실행 기능을 담당하는 노드를 Executing DON이라고 표현하기도 하지만 현재 v1.6에서는 서로 완전히 분리된 두 개의 오라클 네트워크가 아니라 같은 Role DON 내부에서 역할이 나뉜 구조라고 설명하고 있다.

RMN 자동 오프체인 검증은 현재 배포에서 비활성화

초기 CCIP에서 사용했던 RMN의 자동 오프체인 검증 기능도 현재 아키텍처에서는 변경됐다.

Chainlink의 최신 CCIP 공식 문서에 따르면 Risk Management Network의 자동화된 오프체인 역할은 현재 CCIP 배포에서는 더 이상 활성화돼 있지 않다.

Chainlink는 CCIP의 보안과 컴플라이언스, 모니터링 기능을 이용자가 선택적으로 구성할 수 있는 방향으로 아키텍처를 변경하고 있으며 RMN 오프체인 검증 기능도 향후 선택 가능한 별도 검증 계층으로 다시 제공할 계획이라고 설명하고 있다.

이에 따라 기존 CCIP에서 RMN이 모든 메시지를 독립적으로 확인하고 blessing을 제공하던 구조는 현재 v1.6 배포의 기본 처리 과정에는 포함되지 않는다.

온체인 RMN 계약과 curse 기능은 유지

RMN의 자동 오프체인 역할이 변경된 이후에도 RMN과 관련된 온체인 계약 자체는 CCIP 아키텍처에 남아 있다.

RMN Contract는 CCIP가 통합된 각 블록체인에 배포되며 특정 체인 또는 네트워크 범위의 기능을 중단할 수 있는 비상 제어 기능을 제공한다.

현재 구조에서는 CCIP Owner가 curse를 수동으로 시작할 수 있다. curse가 설정되면 Router와 OnRamp, OffRamp, Token Pool 등의 온체인 구성요소가 RMNRemote 계약의 상태를 조회해 전체 또는 특정 원격 체인과 관련된 기능이 중단됐는지 확인한다.

CCIP는 이와 함께 체인과 토큰별로 설정할 수 있는 Rate Limit, 토큰 개발자가 사용하는 attestations, 네트워크 모니터링 기능 등을 운영하고 있다.

초기 CCIP에서 별도의 노드와 Rust 코드베이스로 모든 크로스체인 메시지를 다시 확인했던 RMN은 v1.6 이후 현재 기본 배포에서 자동 오프체인 검증을 수행하지 않으며, 온체인 RMN 계약은 체인별 또는 네트워크 전체의 비상 기능을 제어하는 구성요소로 유지되고 있다.