Folks Finance사의 개발문서를 보고 Cross-Chain Lending Protocol이 어떻게 이루어졌고 구상되었는지 알아보기 위해 읽고 정리해보았다.
Cross-Chain Lending Protocol을 구축하는 이유
- 대출 프로토콜(lending protocol)에서 가장 중요한 요인은 유동성이다. 안정적인 코인이 예치되어 있다면 사용자들은 필연적으로 대출하게 된다. 더 많은 블록체인에 연결함으로써 안정적인 코인을 공급할 수 있는 기회와 용이성이 증가하게 된다.
- 사용자들은 편리함을 선호한다. 사용자는 자신이 선호하는 지갑과 익숙한 블록체인을 통해 프로토콜과 상호작용하기를 원한다. 따라서 Cross-Chain 프로토콜은 사용자들에게 일반적으로 진입 장벽이 낮다.
여기서 주의해야 할 점은 Cross-Chain과 Multi-Chain의 차이이다. "Multi-Chain"은 동일한 프로토콜을 여러 블록체인에 배포하는 것을 의미하는 반면, "Cross-Chain"은 단일 프로토콜을 여러 블록체인에 배포하는 것을 의미한다.
"Multi-Chain" 프로토콜은 사용자가 배포된 블록체인에 따라 원하는 특정 인스턴스를 선택할 수 있게 함으로써 편리성 문제를 해결한다. 그러나 유동성 문제를 해결하지는 못한다. Multi-Chain에서는 서로 고립된 여러 프로토콜 복사본이 존재하여 한 프로토콜에 예치된 자산을 다른 프로토콜에서 대출할 수 없다. 반면에 Cross-Chain은 어떤 체인에 있든 상관없이 모든 유동성을 사용할 수 있어서 Multi-Chain보다 자본 효율성이 훨씬 높다.
특히 대출 프로토콜의 경우, Cross-Chain의 또 다른 이점은 사용자가 한 체인에 예치된 자금을 담보로 다른 체인의 자금을 대출할 수 있다는 점이다. 만약 Cross-Chain 프로토콜이 없다면, 사용자는 자신이 담보로 사용할 자산을 대출하고자 하는 블록체인으로 이동(브릿지)시켜야 한다. 이 과정은 여러 단계를 거쳐야 하는 복잡하고 번거로운 과정이다. 예를 들어, Ethereum 블록체인에 ETH를 예치했지만, Binance Smart Chain(BSC)에서 대출을 받고자 한다면, 사용자는 ETH를 BSC로 브릿지해야 한다. 이 과정은 시간이 걸리고 수수료가 발생할 수 있다. 또한 브리지된 자산은 종종 래핑(wrapped)되어 사용된다(예: ETH → BSC ⇒ wrapped ETH(wETH)). 사용자는 해당 블록체인에서 wETH를 담보로 받아들이는 대출 프로토콜을 찾아야 한다. 모든 대출 프로토콜이 래핑된 자산을 담보로 받아들이는 것은 아니므로, 이 과정은 복잡하고 제한적일 수 있다. 일부 블록체인에서는 특정 자산의 브리지나 래핑이 불가능할 수 있다. 따라서 사용자는 원래의 자산을 다른 체인에서 사용할 수 없게 되어 대출 자체가 불가능해질 수 있다. Cross-Chain 프로토콜은 이러한 문제를 해결한다. 사용자는 자신이 예치한 자산을 어느 블록체인에서든지 담보로 사용할 수 있기 때문에 브리지나 래핑 과정이 필요 없고, 자산을 쉽게 대출할 수 있다.
Hub & Spoke Architecture
Hub & Spoke 모델은 주변 블록체인을 중앙 Hub 블록체인에 연결하는 일련의 Spokes가 있다.
아키텍처 개요
- Hub 체인과 Spoke 체인 간의 통신: Hub 체인과 Spoke 체인은 Generic Messaging Protocol(GMP)을 사용하여 상호 통신한다. 이 경우, 사용될 GMP는 Wormhole과 Chainlink CCIP이다.
- 프로토콜 상태 저장: 프로토콜의 전체 상태는 Hub 체인에 저장된다. 대출 기능과 관련된 상태는 Spoke 체인에 저장되지 않으며, Spoke 체인에는 Hub 체인과의 통신 방법과 관련된 상태만 저장된다. 이러한 결정의 주요 이유는 체인 간 상태 비동기성과 경합 조건을 피하기 위해서다.
To Bridge or Not To Bridge
위에서 프로토콜 상태가 오직 Hub 체인에만 존재한다는 것을 확인했다. 그러나 프로토콜 토큰이 Hub 체인으로 브리지될 것인지 아니면 각각의 Spoke 체인에 남아 있을 것인지에 대한 추가적인 질문이 있다.
브리징의 장단점을 모두 고려하여 하이브리드 접근 방식을 채택했다. 일부 토큰은 Hub 체인으로 브리지되고, 일부 토큰은 각각의 Spoke 체인에 남아 있을 것이다.
하이브리드 접근 방식
- Hub 체인으로 브리지되는 토큰:
- USDC와 기타 크로스체인 네이티브 토큰은 Hub 체인으로 브리지된다.
- 브리지 선택은 토큰에 따라 다르며, 토큰의 래핑된 버전이 생성되지 않는 브리지를 사용할 것이다.
- 예를 들어, USDC의 크로스체인 네이티브 전송을 원활하게 하기 위해 Circle CCTP를 사용할 것이다.
- 사용자는 지원되는 Spoke 체인 중 어느 체인에서나 이러한 토큰을 예치하고 대출할 수 있다(토큰과 브리지 쌍이 원하는 블록체인을 지원하는 경우).
- Spoke 체인에 남아 있는 토큰:
- AVAX와 같은 Spoke 가스 토큰은 각각의 Spoke 체인에 남아 있을 것이다.
- 사용자는 이 토큰을 해당 Spoke 체인에서만 예치하고 대출할 수 있다.
- 사용자가 이러한 토큰을 다른 Spoke 체인에서 받고자 한다면, 다른 Spoke 체인에서 받은 후에 추가적인 브리징 단계를 거쳐야 한다.
USDC
- USDC 다이어그램: Chain A에서 예치된 USDC는 Hub 체인으로 전송되고, Chain B에서 대출된 USDC는 Hub 체인에서 출금되어 전달된다. Hub 체인은 예치와 대출 상태를 관리하며, 유동성을 유지한다.
ETH
- ETH 다이어그램: Ethereum 체인에서 전송된 ETH는 Hub 체인으로 예치되고, Chain A에서 대출된 ETH는 Hub 체인에서 출금되어 전달된다. Hub 체인은 예치와 대출 상태를 관리하며, 유동성을 유지한다.
요약
- 프로토콜 상태: 오직 Hub 체인에만 저장.
- 토큰 브리징 전략:
- 브리지되는 토큰: USDC 등, 크로스체인 네이티브 토큰 (예: Circle CCTP 사용).
- 브리지되지 않는 토큰: AVAX 등, Spoke 체인의 가스 토큰.
- 사용자 지침:
- 브리지된 토큰은 여러 Spoke 체인에서 예치 및 대출 가능.
- Spoke 체인의 가스 토큰은 해당 체인에서만 예치 및 대출 가능.
- 다른 Spoke 체인에서 가스 토큰을 받고자 할 경우, 추가적인 브리징 필요.
Cross-Chain Communication and Finality
블록체인 네트워크에서 포크와 재구성
어떤 블록체인은 다음 Block Proposer가 누구인지 정의하지 않으며, 정의하는 경우에도 Proposer가 오프라인일 때 어떻게 복구할지 정의해야 한다. 이러한 상황은 네트워크가 포크(2개 이상의 유효한 블록이 존재하는 상황)될 수 있으며, 네트워크는 어떤 포크를 기준으로 체인을 구축할지 합의해야 한다.
포크는 네트워크의 다른 부분이 메인 체인에 대해 합의하지 못할 때 여러 블록 동안 지속될 수 있다. 결국 포크는 블록체인의 규칙에 따라 해결되지만, 버려진 블록에 포함된 모든 거래는 제거된다. 이 과정을 '재구성(re-org)'이라고 한다.
재구성 방지와 이중 지출 공격
재구성은 예상할 수 있지만, 재구성을 이용한 공격( Ex) Double Spend Attack : 이중 지출 공격 )을 방지하기 위해 조치를 취해야 한다. 예를 들어, 사용자가 Ethereum에서 Avalanche로 USDC를 브리지한다고 가정하자. 사용자는 Ethereum에서 USDC를 소각하는 거래를 제출하고, 브리지는 이 거래가 Ethereum 체인에 추가로 Avalanche에서 USDC를 발행한다. 그런데 Ethereum에서 재구성이 발생하여 소각 거래가 체인에서 제거되면, 공격자는 USDC를 Ethereum과 Avalanche에서 모두 사용할 수 있게 된다.
이러한 상황을 회피하기 위해서는 최종성(Finality) 개념을 고려해야 한다. 최종성은 거래가 최정적으로 간주되어 재구성이 불가능하거나 확률적으로 매우 희박한 상태를 의미한다.
사용자가 Spoke Chain에 자금을 예치하면 Hub Chain에 있는 Folks Finance 계정에 크레딧이 발생한다. 재구성이 발생하여 사용자의 자금이 스마트 계약에 도달하지 않은 경우, 사용자는 일종의 이중 지출 공격을 성공적으로 수행한 것이다. 이 예시에서 이중 지출 공격은 토큰 브리지뿐만 아니라 더 넓은 의미에서 ‘value’(자산, 화폐 등)를 브리지하는 것에도 적용될 수 있다. Spoke 체인에서는 예치와 상환 작업에 대해 최종성을 가져야 하며, Hub 체인에서는 인출과 대출 작업에 대해 최종성을 가져야 한다.
- T1 시점:
- Chain A (Spoke Chain)에서 예치가 발생하지만, 해당 블록이 아직 최종화되지 않음.
- 따라서, 예치 메시지가 Hub 체인으로 전달되지 않음.
- T2 시점:
- Chain A에서 예치가 발생한 블록이 최종화됨.
- 예치 메시지가 Hub 체인으로 전달되어 최종적으로 처리됨.
최종성을 고려하지 않아도 되는 경우
일부 작업, 특히 "가치"(예: 자산, 화폐)가 전송되지 않는 경우에는 최종성 여부가 중요하지 않다. 이러한 경우에는 사용자 경험을 향상시키기 위해 메시지를 즉시 중계할 수 있다. 네트워크에서 원래 거래가 제거되더라도 다시 제출할 필요가 없다.
예를 들어, 프로토콜에서 "Invite Address"라는 작업이 있다. 이 작업의 목적은 Folks Finance 대출 계정에 다른 체인의 주소를 추가하는 것이다. 추가된 주소는 기존 주소처럼 계정을 관리할 수 있다. (예: 인출, 다른 주소 초대 등)
사용자가 Spoke 체인에서 "Invite Address" 거래를 제출했다고 가정하자. 우리는 최종성을 기다리지 않고 메시지를 즉시 Hub 체인으로 중계한다. Hub 체인은 새로운 정보를 가지고 상태를 업데이트한다. 이후 Spoke 체인이 재구성(re-org)되어 원래 거래가 네트워크에서 제거된다 하더라도, 이 사실은 프로토콜에 아무런 영향을 미치지 않는다. 원래 거래의 목적은 사용자가 새로운 주소를 계정에 추가하고자 하는 의도를 나타내는 것이기 때문에, 이 거래에는 "가치"가 포함되지 않아 이중 지출 공격의 위험이 없다.
이 원칙은 프로토콜의 많은 작업에 적용된다. 사실, 인출 및 대출 작업의 일부에서도 최종성을 기다릴 필요가 없다. 사용자는 Spoke Chain A에서 ETH를 대출하고자 하는 요청을 제출할 수 있다.
사용자가 1 ETH를 대출하려는 요청을 나타내는 거래에 대해서는 최종성을 기다리지 않는다. 다시 말해, 이러한 거래는 사용자의 의도를 정의하는 데만 사용되기 때문이다. 그러나 Hub 체인에서 Spoke 체인으로 전송되는 메시지의 경우에는 최종성을 기다려야 한다. 이는 해당 메시지가 가치 전송을 인코딩하기 때문이다. Hub 체인은 사용자가 추가로 1 ETH를 대출받았음을 나타내도록 상태를 업데이트한다. 만약 사용자가 1 ETH를 받은 후에 이 거래가 Hub 체인에서 제거된다면, 사용자는 동일한 예치금을 사용해 더 많은 자금을 대출하거나 전액 인출할 수 있는 형태의 이중 지출 공격을 성공적으로 수행하게 된다.
현재 CCIP는 소스 체인 거래의 최종성 수준을 지정하는 기능을 제공하지 않는다. 따라서 이러한 유형의 거래에 대해서는 기본적으로 Wormhole을 사용할 것이다. 이 기능이 CCIP에 구현될 때까지 말이다.
요약
- 최종성을 고려하지 않는 경우: "가치"가 전송되지 않는 작업에서는 최종성을 기다리지 않아도 된다.
- 메시지를 즉시 중계하여 원래 거래가 제거되더라도 다시 제출할 필요가 없다.
- 예시: Invite Address: Folks Finance 대출 계정에 다른 체인의 주소를 추가하는 작업으로, 최종성을 기다리지 않아도 된다.
- 사용자가 1 ETH를 대출하려는 요청 거래는 사용자의 의도를 나타내므로 최종성을 기다리지 않는다.
- 그러나 Hub 체인에서 Spoke 체인으로의 가치 전송 메시지는 최종성을 기다려야 한다.
- 현재 CCIP는 소스 체인 거래의 최종성 수준을 지정할 수 없으므로 Wormhole을 사용한다.
'Blockchain' 카테고리의 다른 글
| 간단한 개념 정리 (1) | 2024.07.25 |
|---|---|
| Cross-Chain Lending Protocol: 유동성 확보와 편의성을 위한 설계 및 비교 분석 - Part 2 (0) | 2024.07.20 |
| Uniswap이 뭘까? (2) | 2024.07.18 |
| Damn Vulnerable DeFi Challenge #7 - Compromised (0) | 2024.07.06 |
| Damn Vulnerable DeFi Challenge #6 - Selfie (0) | 2024.07.05 |