LayerZero A to Z — 2부: 활용사례, 의의 및 한계
본 게시글은 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 ‘LayerZero A to Z’를 주제로 Weekly Session에서 발표한 내용을 담았습니다. 본 글은 이전 글에 이어 LayerZero의 활용사례 세 가지를 다루고, 레이어제로의 의의 및 한계점을 제언합니다.
Author: 전승민(@organ_mo), 박찬우(@canu0205)
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By Decipher Media Team 하성환, 임요한
[LayerZero A to Z] — 1. 크로스체인 메세징과 레이어제로
[LayerZero A to Z] — 2. 활용사례, 의의 및 한계
3. 레이어제로 활용 사례
3.1 OFT / ONFT
OFT(Omnichain Fungible Token)는 레이어제로의 크로스체인 메세징 기능을 사용하면서 ERC20 표준을 따르는 토큰이다.
- 위 그림과 같이 체인 A위의 OFT를 가지고 있는 사용자가 체인 A의 OFT 컨트랙트에 체인 B로 OFT를 보낸다는 함수를 호출하면, 체인 A위의 OFT는 락 되거나 소각된다(이러한 액션은 OFT를 만드는 개발자의 선택에 달려있다).
- 그리고 해당 메세지가 체인 A의 엔드포인트를 거쳐 오프체인의 릴레이어와 오라클이 체인 B의 엔드포인트로 전달해준다.
- 체인 B의 OFT 컨트랙트가 해당 메세지를 받으면, OFT를 보낸 사람이 설정한 주소와 락(혹은 소각)시킨 양만큼 OFT가 체인 B위에서 발행된다.
일련의 과정을 거쳐 ERC20 토큰이 멀티체인에서 활용될 수 있음을 알 수 있다.
이때, 초기의 OFT는 EVM 체인에서만 사용할 수 있었고, 그러한 한계점을 해결하기 위해 OFTV2가 등장했다. non-EVM 체인(앱토스, 솔라나 등)은 uint64로 토큰 밸런스를 표기하기 때문에, OFTV2에선 uint64를 이용해서 토큰의 갯수를 표현한다. 이 경우에 소수점(decimal point)이 18자리이면 18 * 10^18개, 즉 18개의 토큰밖에 표기하지 못한다. 따라서 OFTV2는 소수점 10자리 이하의 토큰으로만 사용할 수 있다.
ONFT(Omnichain Non Fungible Token)도 OFT와 마찬가지로 ERC721, ERC1155 표준을 따르면서 레이어제로의 크로스체인 메세징 기능이 추가된 토큰이다.
3.2 Radiant Capital
Radiant Captial은 네이티브 유틸리티 토큰으로 OFTV2 표준을 따르는 $RDNT를 사용하는 멀티체인 렌딩 프로토콜이다. 해당 프로토콜의 토크노믹스에 대해서 간략하게 살펴보면, Lender는 토큰 예치에 대해서 LP 토큰인 dLP(dynamic Liquidity Provider)를 받고, 해당 토큰을 락 시키면 $RDNT를 추가로 받는다. $RDNT는 플랫폼 수수료를 분배 받을 수 있는 유틸리티를 가지고 있으며, Lender에게 지급하기 위한 이자와 $RDNT 홀더들에게 제공할 수수료는 Borrower의 플랫폼 사용 수수료로부터 발생한다. 이때, $RDNT는 OFTV2 토큰이므로 체인간 이동이 자유롭기 때문에 더 높은 수수료를 제공해주는 체인으로 $RDNT를 쉽게 옮겨둘 수 있다.
Lender의 관점에서 더 높은 수수료를 제공해주는 곳으로 $RDNT를 쉽게 이동할 수 있다는 장점이 있고, Borrower의 관점에서는 특정 체인 위의 자산으로 다른 체인의 자산을 빌릴 수 있다는 장점이 있다. Radiant Capital은 Aave의 대출 로직을 포크해온 프로토콜이며, Stargate 브릿지를 이용한 체인 간 자산 이동을 통해서 멀티체인 렌딩을 가능케 한다. 멀티체인 렌딩의 로직을 좀 더 자세히 살펴보면 아래 그림과 같다.
체인 A에 담보를 예치해 둔 유저가 체인 B의 USDT를 빌리는 함수를 호출한 상황에서 어떠한 경로로 멀티체인 렌딩이 발생하는지 살펴보겠다.
- 체인 A 위의 담보로 체인 A의 USDT를 빌린다.
- Stargate 브릿지를 통해 체인 A의 USDT를 체인 B의 USDT로 스왑한다.
- 체인 B의 USDT는 체인 A의 유저 주소와 동일한 체인 B의 유저 주소로 전송된다.
이러한 경로를 거쳐서 특정 체인의 담보물로 다양한 체인의 암호화폐를 대출 받을 수 있다. 대출금 상환의 경우에는 대출을 실행한 체인 위에서 진행해야 하는데, 앞서 예를 든 경우에 체인 B의 USDT를 상환하려면 체인 A위에서 상환을 진행해야 한다. 즉, 체인 A 위에 대출한 만큼의 USDT를 가지고 있어야 한다. 이러한 상환 메커니즘은 유저 입장에서 매우 불편하기 때문에, 추후에 개선되어야 할 사항 중에 하나이다.
Radiant Capital의 로드맵은 위 그림과 같다. 현재는 V2.0이며, 멀티체인 렌딩을 지원하는 토큰의 갯수도 매우 제한적이다. 추후에 계속해서 멀티체인 지원 토큰을 늘려나갈 예정이며, 궁극적으로 옴니체인 렌딩 프로토콜로 나아가려고 한다.
3.3. Stargate
Stargate는 레이어제로를 기반으로 구축된 첫 번째 애플리케이션으로, 크로스체인 스왑 및 파밍을 지원하는 브릿지이다.
- Why Stargate?
Stargate는 기존 브릿지 솔루션에 대해 다음과 같은 문제점이 존재한다고 지적한다.
- 네이티브 자산이 아닌 합성 자산
기존 Lock & Mint (혹은 Burn & Mint) 방식의 브릿지들은 A 체인의 네이티브 자산을 잠그고 B 체인에서 A 체인의 네이티브 자산을 랩핑한 토큰을 발행하는 방식을 택한다. 이는 한 자산에 대해 브릿지마다 다른 토큰을 발행한다는 의미이다.
위 그림처럼 체인 내 사용자들은 브릿지마다 다른 합성(랩핑) 자산으로 인한 혼란과, 브릿징된 자산을 해당 체인의 네이티브 자산으로 다시 한 번 바꿔야 되는 불편함을 겪는다.
2. 통합되지 않은 유동성
이 뿐만 아니라, 몇몇 브릿지들은 연결된 체인 별로 유동성이 파편화되어 있다. 이 경우, 자산 리밸런싱이 자주 일어나야 할 뿐더러 사용자 입장에서도 자산 교환을 seamless하게 하지 못할 가능성이 존재하게 된다.
3. 즉각적으로 보장되지 않는 완결성
Celer Network와 같이 여러 체인에 걸쳐 공통된 자산(USDT, USDC, …)에 대해 공유된 풀을 만들고 아토믹 스왑으로 자산을 교환하는 유동성 네트워크 방식의 크로스체인 솔루션도 존재한다. 이 방식은 기존 Lock & Mint 방식에 비해 더 통합된 방식으로 유동성을 모을 수 있고, 랩핑된 자산이 없기 때문에 자본도 더 효율적으로 쓰인다는 장점을 가지고 있다.
그러나 이러한 방식은 즉각적으로 트랜잭션이 완결되지 않는다는 문제가 발생할 수 있다. 체인 A에서 체인 C에게 $X를 요청해서 체인 A 내 트랜잭션은 완결된 상태에서, 트랜잭션 재정렬(MEV)로 인해 체인 C 내 트랜잭션이 실패한다면 상태를 되돌려야 한다. 상태를 되돌리려면 추가 비용이 들게 되는데, 이 비용이 만약 사용자에게 부과된다면 UX가 나빠질 것이고, 브릿지 자체적으로 비용을 부담한다면 잠재적인 공격 벡터(트랜잭션 스팸 공격)가 될 것이다.
이에 따라 아토믹 스왑에서는 해시 타임 락 컨트랙트(Hash Time Lock Contract)를 사용해서 트랜잭션 완결이 입증될 때까지 토큰을 일정 기간 잠그는 메커니즘을 사용하기도 하나, 이는 임시 방편으로 결국 완결이 되지 않았을 때 비용이 드는 문제는 해결할 수 없다.
- Delta Algorithm
Stargate는 자체적으로 구축한 델타 알고리즘을 통해 위와 같은 문제를 해결한다. 델타 알고리즘은 트랜잭션의 완결성 문제를 해결하기 위해 Stargate에서 자체적으로 구축한 메커니즘이다.
체인 X, Y, 그리고 Z에 각각 단일한 USDT 풀이 구성되어 있다고 해보자. X에는 100 USDT 만큼의 유동성이 있고, Y와 Z에는 50 USDT 만큼의 유동성이 있는 상황이다.
델타 알고리즘의 핵심은 각 체인마다 연결된 체인에 할당된 유동성 정보를 저장하여, 사용자의 트랜잭션이 발생할 때마다 연결된 체인에 할당된 유동성을 조절한다는 것이다. 이를 아래와 같이 화살표 notation으로 표시하겠다.
b(X → Y) : X 체인 내 유동성 중 Y 체인에 할당된 유동성.
위의 예시에서 b(X → Y)를 60 USDT, b(X → Z)를 40 USDT라고 해보자. 사용자가 10 USDT를 X 체인에서 Y 체인으로 보내는 트랜잭션을 요청한다면, 다음과 같은 세 가지 단계로 리밸런싱이 발생한다.
- b(X → Y)가 60 USDT — 10 USDT = 50 USDT로 감소한다.
- X 체인에서 Y 체인으로 “사용자가 10 USDT를 인출하려고 하고, b(Y → X)를 10 USDT 만큼 증가시켜줘”라는 메세지를 보낸다.
- 사용자가 Y 체인에서 10 USDT를 인출해가고, b(Y → X)가 10 USDT 증가한다.
이러한 메커니즘이 델타 알고리즘이다. Stargate는 대상 체인에 트랜잭션 양보다 유동성이 많기만 하다면 크로스체인 토큰 전송 트랜잭션의 완결성을 즉각적으로 보장할 수 있다는 것을 증명하였다. 즉, 소스 체인에서 트랜잭션이 완결되면 대상 체인에서의 트랜잭션도 완결될 수밖에 없는 것이다. 자세한 증명 과정은 백서를 참고하길 바란다.
델타 알고리즘 내에서 레이어제로의 메세징이 사용된다. 사용자가 X 체인에 자금을 예치하는 트랜잭션을 보내고 블록 컨펌 시간이 지나면, 레이어제로 엔드포인트를 통해 데스티네이션 체인인 Y 체인으로
- 사용자가 얼마만큼의 자산을 인출할 수 있는지,
- X 체인에 할당된 자산을 얼마만큼 리밸런싱해야 하는지
가 담긴 메세지를 보내게 된다.
그러나 이러한 메커니즘도 한계를 가지고 있다. 만약 트랜잭션의 즉각적인 완결성에 대한 전제가 깨질 경우, 다시 말해 대상 체인 내에 유동성이 충분하지 않을 경우 Stargate는 여느 유동성 네트워크 프로토콜과 같이 제대로 된 동작을 하지 못하게 된다.
Stargate는 ‘equilibrium fee’를 도입하여 이를 해결하고자 한다. Equilibrium fee는 유동성이 적은 체인에서 많은 체인으로 가는 크로스체인 메세지에 대해 수수료를 떼어서 반대 방향의 트랜잭션을 요청하는 사람들에게 보상으로 주는 방식의 인센티브 메커니즘이다. 즉, Stargate는 수수료 수취 및 보상 지급을 통해 각각의 체인에 대해 유동성의 균형을 맞추려고 하는 것이다.
Stargate는 또한 레이어제로와 마찬가지로 타 프로토콜에 쉽게 적용될 수 있도록 높은 결합성을 제공하기 위해 노력 중에 있다. 위에서 이야기한 Radiant Capital 외에도, 대표적으로 Sushiswap의 크로스체인 DEX인 SushiXSwap이 Stargate의 컨트랙트를 기반으로 구현되었다.
- Stargate의 리스크
아비트럼, 옵티미즘과 같은 옵티미스틱 롤업들은 레이어 1으로 자산을 브릿징하는 데에 있어 일주일 간의 시간을 필요로 한다. 이를 Dispute Time Delay(DTD)라고 한다.
그러나 현재 Stargate는 별도의 DTD 없이 아비트럼 혹은 옵티미즘에서 이더리움으로 자산 브릿징이 가능하다. 이는 Optimistic Time Travel 공격에 악용될 수 있고, 이 경우 아비트럼 혹은 옵티미즘 네트워크를 통해 Stargate에 유동성을 공급한 유동성 공급자들이 손해를 보게 된다. 이 과정을 간단하게 설명하면 다음과 같다.
- Alice(공격자는) 아비트럼 네트워크 내 100 ETH가 있는 Account 1에서 사기성 트랜잭션을 실행한다. 이 트랜잭션은 L2에서 실행되면 100 ETH를 Account 2로 보내지만, 사기 증명 과정에서 L1에서 시뮬레이션될 때는 revert된다.
- 이제 Account 2에서 100 ETH를 Stargate를 통해 이더리움 네트워크로 인출한다. 이는 7일의 출금 딜레이 없이 즉시 진행된다.
- Account 1에서 100 ETH를 L1으로 디폴트 브릿지를 통해 인출하는 트랜잭션을 요청한다. 당연히 Account 1에는 자금이 없기 때문에 트랜잭션은 실패한다.
- Alice는 6일을 기다린 후에 사기 증명을 제출하여 체인을 6일 롤백한다. 이 시점에서 아비트럼 네트워크는 시퀀서를 통한 상태 루트 제출을 정지하고, 악의적인 트랜잭션 결과를 수정하면서 체인을 롤포워드(Rollforward)한다.
- 다시 시퀀서가 온라인 상태가 되었을 때, Alice는 Account 1에 100 ETH를 가지고 있을 것이고, 3번에서 요청하였던 L1으로의 인출이 진행된다.
- 7일의 출금 딜레이를 기다리면, Alice는 100 ETH의 자금으로 200 ETH를 가지게 된다.
- 이때 Alice가 해킹한 100 ETH는 아비트럼의 Stargate 풀에 예치되었던 자금이다. 즉, 손해는 아비트럼에서 Stargate를 통해 ETH를 예치했던 LP들이 보게 되는 것이다.
현재 이러한 문제점은 Stargate 뿐만 아니라 DTD를 준수하지 않는 모든 L2 브릿지 프로토콜에 해당되는 문제이다. 옵티미스틱 롤업의 기본 보안 가정을 어기는 행위이기 때문이다. 즉, 이 문제는 Stargate가 아비트럼 혹은 옵티미즘에서 다른 블록체인으로 나가는 트랜잭션에 대한 구성 파일을 수정하지 않는 이상 해결할 수 없다.
다만 현재 아비트럼 혹은 옵티미즘은 사기성 트랜잭션(트랜잭션 자체는 문제가 없지만 트랜잭션의 상태 루트가 악의적으로 구성된 상태) 및 사기 증명을 제출할 수 있는 주체를 화이트리스팅하는 등 이 취약점에 대한 악용 가능성을 엄격하게 제한하고 있다. 즉 해킹이 발생할 수 있는 가능성은 매우 희박하다고 할 수 있지만, 만에 하나 해킹이 발생했을 때 Stargate를 포함해 DTD를 준수하고 있지 않는 브릿지 프로토콜의 LP는 큰 손해를 볼 수 있다.
4. 레이어제로의 의의 및 한계
4.1. 의의
4.1.1. 범용성 있는 라이트 클라이언트 구현
기존의 코스모스, 폴카닷 등이 구현하고 있었던 라이트 클라이언트 방식의 크로스체인 프로토콜은 같은 유형의 합의 알고리즘을 가진 체인들끼리만 지원된다는 점, 라이트 클라이언트 운영 비용이 비싸다는 점을 단점으로 꼽을 수 있다.
레이어제로는 라이트 클라이언트 대신 오라클과 릴레이어가 블록 헤더 및 트랜잭션 증명을 보내주는 메커니즘을 사용함으로써, 저렴하고 범용성 있는 동시에 라이트 클라이언트 만큼의 메세징 신뢰성도 보장하는 형태의 크로스체인 프로토콜을 구축하였다.
4.1.2. 모듈성
레이어제로는 애플리케이션이 직접 메세징 프로토콜(오라클 / 릴레이어)을 선택할 수 있도록 한다. 또한 이 뿐만 아니라, 레이어제로는 메세징 중 소스 및 대상 체인 내에서 얼만큼의 블록 컨펌을 기다려야 하는지도 애플리케이션 입장에서 선택할 수 있도록 하고 있다. 즉, 레이어제로는 애플리케이션 레벨의 보안을 빌더가 직접 선택할 수 있도록 한다.
위 그림과 같이, 레이어제로의 CEO인 Bryan Pellegrino는 각 앱이 각자의 토큰을 사용해 별도의 릴레이어 체인을 구축해서 본딩 메커니즘을 구현해도 된다고 하면서, 레이어제로는 이러한 작업에 최적화되어 있다고 이야기한다.
또한 현재 레이어제로의 릴레이어는 레이어제로 랩스가 운영하는 하나밖에 존재하지 않지만, 지난 4월 Essense라는 프로젝트를 발표하면서 누구나 릴레이어 및 오라클을 구축할 수 있는 SDK를 출시하겠다고 밝혔다.
이러한 레이어제로의 시도들은 개발자 입장에서 큰 유연성을 제공해 준다. 이전 크로스체인 솔루션들은 릴레이 방식 등을 포함한 모든 요소들을 모두 정해진 방식대로 제공하여 본인의 솔루션에 의존할 수 밖에 없게 만들었다면, 레이어제로는 개발자가 이를 스스로 커스텀할 수 있게끔 하는 것이다.
그러나 빌더들에게 높은 자율성을 부여하는 방식은 트레이드 오프가 존재한다. 애플리케이션 설계에 레이어제로의 기술을 맞춰 사용할 수 있다는 것, 그리고 자체 토큰의 유틸리티를 다양화할 수 있다는 점 등의 장점이 존재하는 반면, 단점도 존재한다. 이에 대해서는 다음 섹션에서 더 자세히 다루도록 하겠다.
4.2. 한계점
4.2.1. 보안 및 탈중앙화
레이어제로의 메세징 프로토콜은 오라클과 릴레이어 두 가지 주체에 의존한다. 현재 레이어제로의 오라클은 네 개의 신뢰 주체가 운영하는 체인링크 오라클로 구성되어 있고, 릴레이어는 레이어제로 랩스에서 운영하는 한 개밖에 존재하지 않는다.
코스모스의 라이트 클라이언트는 상대 체인의 블록 헤더 정보를 저장하기 전에 밸리데이터 서명이 제대로 이루어졌는지 검증 후 저장하기 때문에, 사실상 릴레이어가 악의적으로 블록 헤더를 조작할 수 없게 된다. 그러나 레이어제로는 오라클과 릴레이어가 각각 블록 헤더 및 트랜잭션 증명을 전달하는 메커니즘으로, 전달 과정에서 중간자의 개입으로 인한 블록 헤더 조작과 같은 공격 시나리오가 가능해진다. 즉, 레이어제로의 크로스체인 메세징은 완전히 trustless한 것이 아니다. 또한 레이어제로는 릴레이어 및 오라클 둘 중 하나만 동작하지 않아도 애플리케이션이 돌아가지 않기 때문에, griefing attack에도 취약하다고 볼 수 있다.
또한 레이어제로를 사용하는 각 애플리케이션은 각자의 보안 수준을 직접 커스텀할 수 있다. 즉, 레이어제로를 활용한 애플리케이션은 각 구현에 따라 다양한 보안 수준을 가지게 된다. 이는 사용자 입장에서 각 애플리케이션의 보안 수준을 직접 판단하게끔 만드는 불편함을 야기한다. 또한 앞서 L2Beat의 실험에서도 볼 수 있듯이, 어플리케이션 내 레이어제로 구성을 수정해도 아무런 제재가 없다는 점에서 각 애플리케이션의 러그 및 해킹 사례가 각 구현에 따라 손쉽게 발생할 수도 있을 것이다. 이는 레이어제로의 모듈성에 따른 단점으로, 애플리케이션의 보안 수준을 담보하는 별도의 장치가 부족하기 때문이다.
누구나 릴레이어가 될 수 있도록 SDK를 제공하는 Essense가 출시되고, 릴레이 메커니즘에 대한 개발자들의 다양한 시도를 통해 릴레이어의 탈중앙화에 대한 해결책을 찾는 것이 현 시점에서 중요해 보인다.
4.2.2. 비용
레이어제로의 메세징 프로토콜은 라이트 클라이언트의 방식을 일부 차용하여, 컨트랙트 상에서 블록 헤더와 트랜잭션 증명을 통해 전달된 메세지의 무결성을 검증한다. 이는 머클 트리 증명을 컨트랙트 내에서 수행해야 함을 의미하고, 이 때문에 방식에 타 프로토콜(외부 밸리데이터를 사용하는 방식)에 비해 더 많은 가스가 소모된다. 즉, 레이어제로는 트랜잭션을 보낼 때 다른 일반적인 크로스체인 프로토콜에 비해 더 많은 비용을 필요로 한다.
위 그래프는 아비트럼에서 폴리곤으로 ERC20 혹은 OFT를 전송하는 트랜잭션에 드는 가스의 양를 나타낸 그래프이다. OFT는 Router 없이 컨트랙트 자체에 레이어제로 프로토콜을 통한 크로스체인 전송이 내장되어 있음에도 Multichain에 비해 약 63% 많은 가스를 요구했으며, Stargate는 Multichain에 비해 약 107%, Celer Network에 비해 약 59% 많은 가스를 요구했다.
4.3. 향후 방향성
Uniswap의 브릿지 평가 보고서에 따르면, 레이어제로는 현재 총 4개의 객체로 구성된 오라클 / 릴레이어 조합을 11개로 증가시킬 예정이라고 한다. 11개의 객체는 PoA(Proof-of-Authority) 형태의 탈중앙화 네트워크를 형성해, 블록 헤더 및 트랜잭션 증명 전달 과정을 투명하게 온체인화할 것이라고 기대된다. 일종의 레이어제로 미들체인이 구축되고, 릴레이어에 존재하는 중앙화 문제를 일정 부분 해소할 수 있게 되는 것이다.
이와 동시에 올 4월 레이어제로는 누구나 릴레이어를 구축할 수 있도록 Essense라는 SDK를 만들 것이라고 밝혔다.
따라서 LayerZero를 사용하는 dApp들은 앞으로 다음과 같이 여러 가지의 선택지를 가지게 될 것이다.
- LayerZero가 구축한 오라클 / 릴레이어 체인에 크로스체인 메세징을 아웃소싱
- Essense를 통한 릴레이어 / 오라클 구축으로 자체적인 크로스체인 메세징 실행
- 별도의 dApp 특화 릴레이어 미들체인 구축을 통해 자체 토큰 유틸리티 다양화
5. 결론
레이어제로는 IBC의 라이트 클라이언트 방식을 차용해서 신뢰 주체를 줄이고, 빌더에게 높은 자유도를 준다는 점에서 다른 크로스체인 프로토콜들과는 다른 차별점을 가져간다. 그러나 레이어제로는 기존에 존재하던 크로스체인 프로토콜들의 문제점을 해결한다기 보다는, 보안과 효율성 사이의 절충안을 제안한 것에 더 가깝다고 생각한다. 보안적인 측면에서 레이어제로는 외부 밸리데이터에 의존하는 브릿지와 주기적으로 블록 헤더를 받아와서 크로스체인 메세징을 가능케 하는 라이트 클라이언트 방식 사이에 존재한다. 효율성 측면에서 레이어제로는 라이트 클라이언트의 블록 헤더 검증 비용을 오프체인 주체인 오라클을 통해 줄였다고 볼 수 있다.
레이어제로는 trustless 한 구조를 가지고 있다고 마케팅 하지만, 앞서 살펴봤듯이 완전히 trustless한 구조는 아니라고 볼 수 있다. 그러나 앞으로 오프체인 주체들이 참여하는 PoA 네트워크로의 전환, 오프체인 주체들의 오픈 소스화, 릴레이어 구현 허들의 하락 등 구조 다변화 및 현존하는 이슈들에 대한 해결이 어떻게 진행될지는 지켜볼만한 포인트라고 생각한다.
Reference
