LayerZero A to Z — 1부: 크로스체인 메세징과 레이어제로
본 게시글은 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 ‘LayerZero A to Z’를 주제로 Weekly Session에서 발표한 내용을 담았습니다. 본 글은 크로스체인 메세징 프로토콜의 전반적인 생태계를 살펴보고, 레이어제로의 구조 및 보안 이슈, 활용 사례에 대한 내용을 다루고 있습니다.
Author: 전승민(@organ_mo), 박찬우(@canu0205)
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By Decipher Media Team 하성환, 임요한
[LayerZero A to Z] — 1. 크로스체인 메세징과 레이어제로
1. 크로스체인 메세징 프로토콜
1.1. Introduction
비탈릭 부테린은 22년 초 트위터에 다음과 같은 요지의 글을 올렸다.
the future will be multi-chain, but it will not be cross-chain
크로스체인에 의존할 수록 보안 측면에서 해당 블록체인이나 프로토콜의 취약점이 더욱 커지기 때문에, 각 블록체인이 본인의 생태계를 단단하게 구축해 나가는 것이 중요하다는 내용이었다. 그러나 블록체인 생태계가 더욱 다양한 체인들이 생기는 방향으로 진행될수록, 크로스체인 솔루션도 중요해질 수 밖에 없다. 사용자 관점에서 블록체인 간 상호운용성 증대는 체인 간 스왑 및 자산 운용 등 자본 효율성의 증가를 의미한다. 또한 빌더 및 블록체인 입장에서는, 본인의 애플리케이션이 크로스체인을 통해 타 체인의 고객을 유치할 수 있다는 점에서 크로스체인 솔루션은 큰 효용을 낳을 수 있다.
이번 글에서는 최근 큰 규모의 투자 유치, 토큰 출시에 대한 기대감으로 주목받고 있는 크로스체인 솔루션 레이어제로에 대해 알아보고, 그 의의와 한계점에 대해 알아본다.
1.2. 크로스체인 메세징 프로토콜
크로스체인 메세징 프로토콜은 여러 체인 간 메세지를 보낼 수 있게 정한 통신 규약을 의미한다. 크로스체인 메세징에서 중요한 점은 검증(Validation)이다. 예시를 들어 알아보자.
Alice가 USDC를 A 체인에서 B 체인으로 보내고 싶은 상황이라고 가정해보겠다. 그러면 Alice가 해야 할 일은 다음과 같이 두 가지이다.
- A 체인에 USDC를 락업하는 작업을 수행하고,
- 동시에 B 체인에 ‘A 네트워크에 USDC를 락업했으니 여기서 USDC를 민팅해주세요!’ 라는 메세지를 보내 작업을 요청해야 한다.
여기서 문제점은, B 체인의 입장에서 Alice가 보낸 ‘A 네트워크에 USDC를 락업했으니 여기서 USDC를 민팅해주세요!’라는 메세지를 믿을 수 없다는 것이다. 즉, B 체인은 그 트랜잭션이 수행된 사실 혹은 트랜잭션이 잘 수행되었다는 증명을 Alice에게 요구한다.
크로스체인 프로토콜은 이 검증 단계를 어떻게 구현하는지에 따라 크게 두 가지로 나뉜다.
- 외부 검증자가 Alice의 A 체인 내 작업(USDC 락업)을 확인하고, 이에 대해 보증하는 증명을 생성하여 B 체인에 전달한다.
- Alice가 A 체인에서 수행한 트랜잭션 증명과 그 트랜잭션이 포함된 블록 헤더를 B 체인에서 직접 받아와, 실제로 A 체인에 Alice의 트랜잭션이 포함되어 있는지 확인한다.
이를 아래 섹션에서 더 자세히 알아보도록 하자.
1.3. 크로스체인 메세징 프로토콜 (1) — 외부 밸리데이터
외부 검증자를 통한 증명 수행은 가장 일반적으로 사용되는 크로스체인 프로토콜이다. 해당 프로토콜에서는 다음과 같은 방식으로 메세지 생성 및 검증이 이루어진다.
- 트랜잭션 내 이벤트를 통해 사용자가 작업을 수행하고 싶은 대상 체인이 무엇인지(Destination Chain), 어떤 작업을 수행하고 싶은지(Payload) 등의 데이터를 담은 메세지를 생성한다.
- 해당 메세지의 유효성을 외부 검증자 혹은 검증자 집단이 검증하고, 증명을 생성해 대상 체인으로 전달한다.
이러한 메커니즘을 가진 크로스체인 프로토콜은 아래와 같이 중앙화 브릿지, 미들체인, 본딩 프로토콜 세 가지로 나눌 수 있다.
1.3.1. 중앙화 브릿지
중앙화 브릿지는 중앙화된 밸리데이터 혹은 관리자가 서로 다른 체인 간 메세지에 대한 유효성을 검증하는 방식이다. 대표적으로 Wormhole은 Guardian이라고 불리는 검증자들이 메세지에 대한 행위 증명(Verifiable Action Approvals, VAA)을 생성해 대상 체인으로 전달한다.
그러나 중앙화 브릿지는 그 이름에서도 알 수 있듯이 중앙화에 따른 문제가 존재한다. 몇몇 프로토콜은 멀티시그 혹은 MPC(Multi-Party Computation) 기술을 써서 권한을 분산화하는 경우도 존재하지만, 지정된 주체만 밸리데이터가 될 수 있다는 점에서 그들을 신뢰해야 한다는 한계점이 명확하다.
현재까지 중앙화 브릿지들은 다양한 문제에 직면해 왔다. 대표적인 예시로 작년 Ronin과 Wormhole Bridge의 해킹, 그리고 최근 Multichain의 정지 및 해킹 사례를 들 수 있다. Ronin과 Wormhole 모두 중앙화된 밸리데이터 셋에 의존하여 크로스체인 메세지의 유효성을 검증하고 있었고, 개인 키 및 서명 탈취로 인해 브릿지 내에 예치된 자산이 모두 해킹되었다. 두 브릿지 해킹으로 인한 피해액은 총 $950M, 한화로 약 1조가 넘는다.
올 6월 초 Multichain 또한 CEO가 중국에서 연락두절되는 일이 있었다. 이에 따라 멀티체인 팀은 CEO가 가지고 있었던 라우터 서버 관리에 대한 액세스를 잃어버렸고, 노드 네트워크 문제에 대응하지 못해 Kekchain, PublicMint 등과 같은 블록체인에 대한 크로스 체인 서비스를 중단하는 일이 발생했다.
이어 7월 초 Multichain이 운영하던 Fantom, BNB 체인의 SMPC 지갑의 개인 키가 해킹되어 약 $120M의 자금이 탈취되는 일도 발생하였다.
이 역시 노드 네트워크가 중앙화되었음에 따른 부작용이라고 할 수 있다.
1.3.2. 미들체인
미들체인은 중앙화 브릿지의 문제를 해결하고자 메세지 검증 과정을 별도의 중간 블록체인에서 실행하는 크로스체인 메세징 프로토콜이다. 대표적인 예시인 Celer Network를 예를 들어서 알아보자.
Celer Network는 State Guardian Network(SGN)이라는 텐더민트 기반 미들체인을 구축해 체인 간 메세지에 대한 검증을 실행하고 있다. SGN의 밸리데이터들은 $CELR 토큰을 기반으로 투표를 진행해 사용자가 생성한 메세지에 서명하고, 2/3 이상의 투표를 받으면 검증이 완료되는 방식이다.
이러한 미들체인 방식은 개념적으로 중앙화 브릿지보다 더 Trustless하다는 장점이 존재하지만, 검증자의 수나 체인에서 사용되는 코인의 시가 총액이 작다면 역시 네트워크 자체가 단일 실패 지점으로 작용할 수 있게 된다.
현재 Celer Network는 20명의 밸리데이터로 구성되어 있고, 프로토콜에 스테이킹된 $CELR 토큰의 총량은 약 $130M이다. 즉, 이 금액의 3분의 1에 해당하는 $36M만 있다면 Celer Network에 대한 공격을 할 수 있게 된다.
1.3.3. 본딩 프로토콜
본딩 프로토콜은 미들체인과는 달리 별도의 합의 알고리즘이 존재하진 않지만, 사용자들의 자금 전송에 대한 안전성을 어느 정도 보장하기 위해 슬래싱 및 보상 구조를 갖추고 있는 크로스체인 프로토콜이다. 대표적으로 Polygon PoS Bridge와 Hop Protocol이 그 예시입니다. Hop Protocol의 예시로 간단히 설명해보도록 하겠다.
Hop protocol의 오프체인 브릿징 서비스는 Bonder를 중심으로, 옵티미스틱한 방식으로 이루어진다. 각 Bonder는 레이어2 간 사용자의 자산 브릿징 과정에서 메세지를 검증하는 역할을 맡는다. 여기서 Bonder의 악의적인 행동 등으로 사용자가 피해받는 것을 방지하기 위해, Hop protocol은 Bonder로 하여금 일정 금액을 스테이킹하도록 한다. 만약 Bonder의 악의적인 메세지 검증으로 사용자가 피해를 보았고, 이것이 발견된다면 Bonder의 스테이크에서 일정 금액을 슬래싱한다. 이러한 방식으로 Hop protocol은 악의적인 행위를 어느 정도 방지할 수 있다.
1.4. 크로스체인 메세징 프로토콜 (2) — 블록 헤더 & 트랜잭션 증명
위와 같이 커스텀 메세지를 전달하는 방식은 별도의 검증인이 필요하고, 이들이 잘못하거나 악의적으로 행동했을 때 막을 수 없다는 단점 및 신뢰 비용이 존재했다. 이를 보다 Trustless한 방식으로, 온체인으로 확인하고자 등장한 방식이 라이트 클라이언트 브릿지이다.
라이트 클라이언트는 블록체인 내 모든 데이터가 아니라 특정 데이터만 저장하는 노드이다. 라이트 클라이언트 브릿지는 이를 통해 메세지 검증을 라이트 클라이언트가 트래킹하는 특정 데이터를 통해 수행함으로써, 무신뢰적으로 체인 간 통신을 수행할 수 있다.
1.4.1. 라이트 클라이언트
라이트 클라이언트 방식의 크로스체인 프로토콜은 별도의 검증자를 두지 않고, 대상 체인에서 소스 체인의 블록 헤더와 트랜잭션 해시를 가지고 와서 검증한다. 대표적인 예시인 코스모스를 예시로 들어보자.
코스모스는 IBC(Inter-Blockchain Communication)을 할 수 있도록 구축된 블록체인이다. 여기서는 라이트 클라이언트와 릴레이어를 통해 체인 간 메세지 뿐만 아니라 블록 헤더 및 트랜잭션 증명을 전달한다. 이 과정을 간단하게 설명하면 다음과 같다.
- 사용자가 소스 체인에서 대상 체인으로 자산을 보내기 위해 소스 체인 내에서 트랜잭션을 실행한다.
- 릴레이어는 소스 체인에서 발생한 이벤트를 확인하고, 이를 패킷 형태로 만든다. 이때 소스 체인의 풀 노드로부터 트랜잭션의 머클 증명을 받아온다.
- 릴레이어는 이를 대상 체인에 전달한다.
- 대상 체인은 소스 체인에서 실제로 트랜잭션이 발생해 상태가 변경되었는지 확인하기 위해, 라이트 클라이언트가 트래킹하는 상대 체인의 상태 루트(
CommitmentRoot)를 활용해 검증한다. - 검증이 완료되면 대상 체인은 패킷의 데이터를 디코딩해서 사용자가 요청한 트랜잭션을 실행한다.
각 체인 내 존재하는 라이트 클라이언트를 통해, 코스모스 생태계 내 체인들은 제 3의 신뢰 주체 없이도 크로스체인 통신을 자유롭게 실행할 수 있게 된다.
이러한 방식은 연결된 모든 체인에 대해 라이트 클라이언트를 배포해야 한다. 그러나, 이는 비용이 비싸다는 단점이 존재한다. 이더리움에서 텐더민트 라이트 클라이언트를 실행하려는 경우, 연결된 코스모스 체인 내 밸리데이터들의 모든 ed25519 서명을 검증해야 한다(이더리움은 현재 ed25519에 대한 검증에 대해 프리컴파일 컨트랙트를 지원하고 있지 않다). 이더리움에서 한 개의 ed25519 서명에 대한 검증 비용은 최대 500,000 가스이므로, 100명의 밸리데이터가 존재하는 코스모스 생태계 내 체인의 경우 최대 5억 가스가 소모된다는 단점이 존재한다.
또한, 비트코인이나 이더리움, 최근에 나온 앱토스와 같이 즉각적인 블록 완결성을 보장하지 않는 체인들의 경우 코스모스 허브와 연결되기 까다롭다는 단점도 존재한다. 현재 코스모스 허브가 생태계 내 텐더민트 SDK를 통해 구축된 체인과의 연결만을 보장하는 이유이다.
1.4.2. 레이어제로
레이어제로 역시 라이트 클라이언트의 방식을 차용해, 소스 체인의 블록 헤더 및 트랜잭션 증명을 대상 체인에서 확인하는 방식을 채택하고 있다.
레이어제로는 어떠한 메커니즘으로 이를 구현하고 있는지, 라이트 클라이언트의 단점을 어떻게 극복하고 있는지에 대해서는 이후 섹션에서 자세히 알아보도록 하자.
2. 레이어제로 아키텍처 및 보안
레이어제로는 릴레이어(Relayer)와 오라클(Oracle)이라는 주체가 한 체인에서 다른 체인으로 보내는 메세지의 비교를 통해 크로스체인 메세징을 가능케 한다. 메세지의 검증 및 전파가 어떤식으로 일어나는지 구체적으로 살펴보겠다.
2.1 레이어제로 컴포넌트
레이어제로의 크로스체인 메세징에 참여하는 컴포넌트는 크게 네 가지로 분류할 수 있다. 메세지를 받아오고, 검증 및 전파하는 핵심적인 엔드포인트, 메세지를 한 체인에서 다른 체인으로 옮겨주는 역할을 하는 릴레이어와 오라클, 마지막으로 레이어제로를 이용해서 한 체인에서 다른 체인으로 메세지를 보내고 받는 **User Application(UA)**이 있다. 각각에 대해서 조금 더 자세히 살펴보겠다.
- 엔드포인트
유저와의 직접적인 소통을 통해 메세지를 받아오고 전달해주는 Communicator, 메세지의 유효성을 검증하는 Validator, 메세지를 다른 체인으로 전달하고 받아오는 Network의 역할을 하는 UltraLightNodeV2.sol 과 각 체인별로 다른 특성을 반영하기 위한 Libraries 역할을 하는 Endpoint.sol 로 구성되어 있다. - 릴레이어
Relayer.sol 컨트랙트를 통해 메세지에 대한 증명을 받아오고, 다른 체인으로 해당 증명을 전달해주는 역할을 한다. 릴레이어는 오프체인에 존재하는 주체이기 때문에, 메세지에 대한 증명을 전달해주는 과정을 온체인에서 확인할 수는 없다. - 오라클
릴레이어와 마찬가지로 한 체인의 정보를 다른 체인으로 전달해주는 역할을 한다. 이때, 릴레이어와 다른 점은 릴레이어는 메세지의 증명에 대한 정보를 전달하는 한편, 오라클은 해당 메세지가 포함되어 있는 블록의 헤더를 전달한다. 따라서, 한 블록 내에서 여러 메세지가 전달될 경우에, 블록 헤더는 단 한번만 전달된다. 현재는 체인링크에서 제공하는 오라클을 디폴트로 사용하고 있으며, 체인링크에서 사용하는 오라클 코드는 공개되어 있지 않다. 그러나, 레이어제로에서 요구하는 오라클 인터페이스는 제공되어 있다. - User Application(UA)
크로스체인 메세지를 보내고 받기 위해서 레이어제로를 사용하는 어플리케이션이다. 어떤 릴레이어와 오라클을 사용할지, 크로스체인 메세지를 보내기 위해 대기할 블록 컨펌 횟수는 얼마인지 설정할 수 있다.
// These are the default Block Confirmations waited by LayerZero before delivering messages
const defaultBlockConfs = {
[ChainId.ETHEREUM]: 15,
[ChainId.BSC]: 20,
[ChainId.AVALANCHE]: 12,
[ChainId.POLYGON]: 512,
[ChainId.ARBITRUM]: 20,
[ChainId.OPTIMISM]: 20,
[ChainId.FANTOM]: 5,
[ChainId.SWIMMER]: 20,
[ChainId.DFK]: 10,
[ChainId.HARMONY]: 5,
[ChainId.MOONBEAM]: 10,
[ChainId.APTOS]: 500000,
[ChainId.CELO]: 5,
[ChainId.DEXALOT]: 10,
[ChainId.KLAYTN]: 5,
[ChainId.METIS]: 5,
[ChainId.FUSE]: 5,
[ChainId.GNOSIS]: 5,
[ChainId.INTAIN]: 5,
}2.2 레이어제로 메세징 플로우
레이어제로의 실제 크로스체인 메세징에 관여하는 컨트랙트와 함수 및 이벤트는 위의 그림에서 보는 것과 같다. 그럼 이제 체인 A에서 오프체인에 있는 릴레이어와 오라클을 거쳐 체인 B로 메세지가 전달되는 과정에서 각각의 컨트랙트가 어떤 역할을 하는지 함께 살펴보겠다.
체인 A
- 크로스체인 메세징이 가능한 디앱을 통해 사용자가 User Application(UA)의
_lzSend()함수를 호출한다. 이때, 어떤 체인으로 보낼것인지, 어떤 메세지를 전달할것인지 설정한다. - UA 컨트랙트에서 Endpoint.sol의
send()가 호출된다.
3. Endpoint.sol에서 UltraLightNodeV2.sol의 send()가 호출된다.
4. UltraLightNodeV2.sol에서 Packet(encodedPayload) 이벤트를 발생시킨다.
오프체인
- 릴레이어와 오라클은
Packet이벤트가 발생하기를 기다리고 있는다. - Packet 이벤트 발생을 감지하고, UA가 따로 지정한 아웃바운드 블록 컨펌 횟수가 지나면, 릴레이어는 체인 B에 존재하는 RelayerV2.sol의
validateTransactionProofV2()함수를 호출한다. 이때, 함수의 인자로 트랜잭션 증명과 블록 헤더 정보를 입력한다. - 그런데, 이때 오라클이 UltraLightNodeV2.sol의 블록 헤더 해시값을 업데이트하지 않으면 릴레이어는 블록 헤더 정보를 모른다. 오라클도 마찬가지로 UA가 지정한 아웃바운드 블록 컨펌 횟수가 지난 후에, 체인 B의 UltraLightNodeV2.sol의
updateHash()함수를 호출해서 블록 헤더 해시값을 업데이트한다. 이때,HashReceived(_srcChainId, msg.sender, _lookupHash, _blockData, _confirmations)라는 이벤트가 발생한다.
4. 릴레이어는 HashReceived라는 이벤트에서 블록 정보를 받아온 다음에 앞선 2번 과정을 다시 실행한다.
5. UltraLightNodeV2.sol의 validateTransactionProof() 함수가 호출되고, 트랜잭션 증명과 블록 헤더 해시값이 일치한다면 크로스체인 메세지의 검증은 완료된다.
체인 B
- UltraLightNodeV2.sol의
validateTransactionProof()함수 내부에서 Endpoint.sol의receivePayload()함수가 호출된다. - Endpoint.sol의 storedPayload 변수에 메세지 저장이 완료된다.
3. UA가 체인 A의 id와 메세지를 보낸 체인 A 위의 계정 주소를 통해 Endpoint.sol의 메세지를 가져온 후, 해당 어플리케이션을 사용하는 유저에게 보여주면 크로스체인 메세징 과정은 끝이 난다.
2.3 레이어제로 보안
크로스체인 프로토콜은 서로 다른 네트워크와 실행 환경에 걸쳐 있는 수많은 구성 요소로 구성된 복잡한 시스템이다. 여기에는 다양한 보안 고려 사항, 가정, 트레이드 오프(trade-off)가 수반될 뿐만 아니라 다양한 인센티브와 신뢰 모델을 가진 주체들의 조정이 필요하다. Crosschain Risk Framework에 의해 크로스체인 프로토콜의 위험 요소는 크게 프로토콜의 설계, 구현, 운영에 관련된 것으로 나눠서 평가할 수 있는데, 이 글에서는 설계 및 운영 측면에서 레이어제로의 보안을 살펴보겠다.
2.3.1 Operation Risk
- Shared Security vs. Isolated Security
Shared security란 특정 인프라에서 실행되는 어플리케이션이 보안 모델을 자유롭게 선택할 수 없는 구조이며, 인프라가 부과하는 모든 보안 요구사항을 따라야 한다. 예를 들어, 옵티미스틱 롤업은 일반적으로 7일의 DTD(Dispute Time Delay)를 거치는데, 이러한 롤업이라는 인프라 위에서 실행되는 어플리케이션은 이 기간을 단순히 무시하거나 단축할 수 없다. 이는 사용자의 경험을 저해한다고 생각되지만, 이유가 있어서 설정된 기간이다. 어플리케이션의 내부 보안 정책과 상관없이 해당 롤업에서 사용 중인 어플리케이션이 사용자에게 안전을 보장할 수 있도록 하기 위해서이다. 즉, 어플리케이션은 롤업의 정책을 강화할 수 있을뿐, DTD를 줄이는 등의 정책을 약화하는 행위는 하지 못한다.
per-Application security(앞으론 isolated security라고 하겠다.)는 모든 어플리케이션이 인프라의 제약을 받지 않고 스스로 보안에 대한 책임이 있는 구조이다. 어플리케이션을 개발한 팀에서 해당 어플리케이션에 어떤 보안 요소가 필요한지 가장 잘 알고 있기 때문에 좋은 아이디어라고 생각할 수 있다. 하지만 이는 동시에 어플리케이션의 보안 정책과 관련된 위험을 평가할 책임을 인프라가 아니라 최종 사용자에게 전가하는 것으로 볼 수도 있다. 또한 어플리케이션 개발팀에서 어플리케이션 정책을 자유롭게 선택할 수 있다면 언제든 변경할 수도 있다. 따라서 모든 어플리케이션에 대해 한 번만 위험을 평가하는 것으로 충분하지 않으며 어플리케이션의 정책이 변경될 때마다 위험을 평가하는 과정을 거쳐야 한다.
레이어제로는 개별 UA에서 사용하려는 릴레이어, 오라클, 블록컨펌 횟수 등을 설정할 수 있으므로, 레이어제로는 Isolated Security에 해당함을 알 수 있다.
2. Valid Delivery
레이어제로에선 Valid Delivery인 경우에만 크로스체인 메세징이 성립한다고 가정한다. 레이어제로에선 트랜잭션 증명과 블록헤더를 비교하여 일치할 경우에만 Valid Delivery라고 판단하는데, 이러한 결과가 발생하는 상황은 두 가지가 있다.
첫 번째는 릴레이어와 오라클이 제공하는 정보가 일치하면서 각각의 주체가 제공하는 정보가 모두 유효한 경우고, 두 번째는 릴레이어와 오라클이 제공하는 정보가 일치하지만, 각각의 주체가 제공하는 정보가 모두 유효하지 않은 경우이다. 두 번째 경우는 릴레이어와 오라클이 담합을 하는 경우에만 가능하다고 말하며, 레이어제로 설계의 특성상 담합의 가능성을 제거한다고 말한다.
그러나 실제로는 각각의 UA가 자체 릴레이어와 오라클을 정의할 수 있기 때문에 이 주장은 사실이 아니다. 레이어제로는 설계상 이러한 구성 요소가 독립적이며 담합할 수 없다는 것을 보장하지 않으며, 이러한 보장을 제공하는 것은 User Application(UA)의 몫이다. 게다가 기본적으로 모든 UA는 언제든지 사용할 릴레이어와 오라클, 블록 컨펌 기간을 변경할 수 있어 레이어제로의 담합에 대한 가정을 완전히 뒤엎을 수 있는 요소이다.
3. 예상 공격 방법
그렇다면 어떠한 순서로 레이어제로를 사용하는 어플리케이션에 허점이 생길 수 있는지 살펴보겠다. 먼저, 서로 다른 두 체인(체인 A, 체인 B) 위에 OFT(Omnichain Fungible Token) 컨트랙트를 배포한 뒤에 목적지를 설정해둔 상태라고 가정하자.
정상적인 크로스체인 메세징이라면, 체인 A 위의 OFT 컨트랙트에 특정한 토큰 수만큼 락 해뒀다는 메세지를 체인 B 위의 OFT 컨트랙트에 전달하면, 체인 B 에서 체인 A에 락 해둔 만큼의 토큰이 민팅된다. 반대의 경우엔 체인 B 위의 OFT를 소각했단 메세지를 체인 A로 보내면, 체인 A에 락 되었던 OFT가 언락 되면서 사용가능한 상태가 된다.
앞서 살펴봤듯이, 정상적인 상황에선 별 문제가 없어 보인다. 하지만, 레이어제로의 UA는 각각이 어떤 릴레이어와 오라클을 사용할지 직접 정할 수 있고, 변경할 수 있기 때문에 며칠전에 정상적으로 작동하던 OFT가 문제를 발생시킬 수 있다.
Shared Security vs. Isolated Security 에서 살펴봤던 setConfig 함수를 통해서 OFT 컨트랙트의 소유자는 릴레이어와 오라클을 EOA로 바꿀 수 있다. 이렇게 바꾼 다음에 릴레이어와 오라클이 체인 B 위에 남아있던 OFT가 소각되었단 메세지를 체인 A의 ULN로 전달하면서 해당 OFT 수신인을 원래 소유자가 아닌 악의적인 사용자로 설정하면, 해당 OFT는 탈취당하게 된다.
이 모든 것은 레이어제로의 유효한 기능이기 때문에 사용자들은 어플리케이션의 설정이 바뀜을 알아차릴 순 있지만, 그것이 바뀌었다고 해서 악의적인 의도인지 아닌지 바로 알아차리기 힘들다. 또한, 이론적으로는 어플리케이션 자체가 릴레이어와 오라클을 변경하지 못하도록 차단할 수 있지만, 이미 배포된 애플리케이션 중 이것이 적용된 사례는 없다.
결론적으로 이는 어플리케이션 자체의 결함이지 레이어제로의 결함은 아니지만, 레이어제로를 통해 크로스체인 메세징을 구현 및 운영하는 어플리케이션의 보안까지 보장하지는 못한다는 것을 증명한다. 레이어제로는 릴레이어 및 오라클과 관련된 보안 모델을 설명할 때 어플리케이션 소유자(또는 개인 키를 소유한 사람)가 비합리적인 행동을 하지 않을 것이라고 가정하지만, 적대적인 환경에서는 이러한 가정은 잘못된 것이다. 따라서 실제로는 레이어제로를 사용하여 구축된 애플리케이션의 보안에 대해 어떠한 가정도 할 수 없으며, 달리 입증될 때까지 각 어플리케이션은 위험한 것으로 간주해야 한다.
2.3.2 Architecture Risk
모든 크로스체인 프로토콜은 크로스체인 메시지의 유효성을 증명하기 위해 일련의 검증자를 필요로 하며, 이러한 프로토콜은 검증자가 적절하게 작동하도록 보장하기 위해 두 가지 모델 중 하나에 의존한다. 첫 번째 모델은 이러한 검증인을 운영하는 주체의 평판과 법적 조치의 가능성이 검증인의 잘못된 행동을 막는다고 가정한다. 이 모델을 권한 증명 모델(Proof of Authority)이라고 한다. 두 번째 모델은 검증자가 프로토콜에서 악의적인 행동을 할 경우 금전적 불이익을 받는 암호경제적 보증을 포함하는 지분 증명 모델(Proof of Stake)이다.
레이어제로는 릴레이어와 오라클이라는 두 집단의 검증자를 필요로 하는 권한 증명 모델이며, 오라클은 4개의 평판이 좋은 법인으로 구성된 체인링크 오라클을 사용하고 있다. 릴레이어는 레이어제로에서 직접 운영하는 하나의 주체밖에 없기 때문에 메세지의 검열 리스크가 존재한다고 볼 수 있다.
레이어제로 팀도 이러한 리스크를 인지하고 있으며, 릴레이어와 오라클을 운영하는 권한 증명 기반의 탈중앙화된 11개의 검증자 집단을 도입한 모델을 개발하고 있다. 이러한 구성에서 크로스체인 메세지가 유효하려면, 11개의 검증자 중 7개의 검증자의 사인을 필요로 한다. 추가로, Essence라는 프로젝트를 통해 릴레이어와 오라클을 쉽게 구현하고 운영할 수 있도록 해주는 프로덕트를 개발 중이며, 오프체인(릴레이어, 오라클 등) 구성요소를 오픈소스화할 계획을 하고 있다.
2부에서는 레이어제로 활용 사례와 레이어제로의 의의 및 한계에 대해서 좀 더 알아보겠다.
Reference
