[Cross-Layer Series] Fast Withdrawals In Optimistic Rollups — Part 2
Author
엄정용, 한충현 of Decipher
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed By 정재환
Note : 이 글은 Praveen Surendran의 Fast Withdrawals In Optimistic Rollups — Part 2 번역본입니다. 오역 발견시 피드백 주시면 반영하겠습니다.
An Introduction to Cross Layer Transfer
Fast Withdrawals In Optimistic Rollups — Part 1
이 게시물은 Optimistic Rollup 시리즈의 빠른 인출(Fast withdrawal)의 두번째 파트로, 인출 지연을 줄일 수 있는 방법에 대한 논의에 해당합니다. 파트 2에서는 파트 1에서 검토한 내용을 바탕으로 문제를 해결할 아이디어를 도출하고 있기 때문에 파트 1을 읽지 않으신 분은 먼저 파트 1을 읽어보시길 권합니다.
QUICK RECAP
간단한 요약으로 시작해보겠습니다.
- Rollup에서의 L2 트랜잭션 데이터 가용성은 Layer 1인 이더리움에 데이터를 게시하는 것으로 보장됩니다.
- 시퀀서는 Layer 2 트랜잭션을 배치로 “롤업”하고 Layer 1 컨트랙트(Canonical Transaction Chain)에 게시합니다.
- CTC에 데이터를 퍼블리시하기 위한 FIFO 큐(Queue)도 존재합니다. 큐는 사용자가 L1에서 L2로 트랜잭션을 수행하려는 경우(예: Layer 1에서 Layer 2로 자산을 이동하는 경우) 또는 시퀀서가 사용자를 검열하는 경우(즉, 트랜잭션을 배치 처리에 포함시키지 않는 경우) 사용됩니다.
- 사용자는 토큰 브리지를 사용하여 Layer 2 Rollup과 기본 Layer 간에 자산을 전송합니다. 이 토큰 브리지는 메신저 컨트랙트를 통해 L1/L2 통신을 구성합니다.
- 일반적으로 예치는 즉시 이루어지지만 인출은 사기 증명 기간으로 인하여 추가적인 시간이 필요합니다.
- CTC에 기록된 배치는 누구나 확인할 수 있습니다. 이는 빠른 인출에 대한 단서를 제공합니다.
옵티미즘의 빠른 인출 메커니즘 논의의 시발점이 된 MakerDAO의 논의에 감사드립니다. MakerDAO의 아이디어는 Tokamak 네트워크를 위한 최적의 빠른 인출 아키텍처를 찾는데 영감을 주었습니다.
Liquidity Provider Assisted Fast Withdrawal
단순한 방식을 적용하여 인출 지연 시간을 줄여보겠습니다. 그리고 이 방식이 어떻게 작동하는지 분석하여 잠재적 한계에 대해 논의해볼 것입니다. 여기서 얻은 개념들을 바탕으로 하여 문제를 해결하기 위한 새로운 기술을 도입해볼 수 있을 것입니다.
인출 지연을 줄이는 가장 간단하고 쉬운 방법은 유동성 공급자(LP)를 도입하는 것입니다. 앞에서 언급하였듯이 유동성 공급자는 CTC에서 initiateWithdrawal 거래 결과를 확인할 수 있습니다. Verifier 노드(또는 풀 L2 노드)를 실행하고 CTC 트랜잭션을 로컬 상태에 적용하여 이를 수행해 볼 수 있습니다. 따라서 유동성 공급자는 사기 증명 기간동안 거래가 성공할 것인지 또는 이의를 제기할 수 있는지 확인이 가능합니다.
유동성 공급자는 검증 결과에 따라 즉시 출금에 대한 사용자 요청을 거부하거나 수락할 수 있습니다. 유동성 공급자가 요청을 받아들이기로 결정하면 수수료를 부과하여 사용자에게 유동성을 제공하게 됩니다. 유동성 공급자는 토큰 브리지의 사용자 토큰에 대한 클레임할 권리를 갖게 되고, 사기 증명 기간이 끝난 후 해당 토큰은 유동성 공급자에게 릴리즈됩니다. 사용자와 유동성 공급자 모두에게 윈-윈인 상황입니다.
아래 이미지는 이 구조를 이해하는 데 도움이 될 것입니다.
인출 요청을 처리하기 위해 유동성 공급자는 시퀀서가 트랜잭션 배치에 대한 상태 루트(State Root)를 게시할 때까지 기다릴 필요가 없습니다. 시퀀서가 잘못된 상태 루트를 게시하더라도 사기 증명 기간에 Verifier가 시퀀서 클레임을 제기할 것이기 때문에 유동성 공급자는 걱정할 필요가 없습니다. 따라서 유동성 공급자가 내리는 결정은 순전히 CTC에 로그인된 트랜잭션 배치를 기반으로 합니다. 물론 CTC 검증 중 유동성 공급자가 잘못 검증하게 되는 경우, 자금 손실이 발생할 수 있습니다.
Drawbacks
- 유동성 공급이 낮은 유동성 토큰의 경우 비용이 많이 들 수 있습니다.
- 큰 금액을 인출하는 중에는 유동성 위기가 발생할 수 있습니다.
Unlimited Liquidity by MakerDAO
유동성 위기는 우리의 계획에 중대한 문제가 될 수 있습니다. 낮은 유동성은 사용자 경험에 영향을 미치고 이 접근법을 실용성을 떨어트립니다. 이를 개선할 수 있는 방법이 있을까요?
유동성 공급자는 무제한 유동성을 사용하여 더 많은 유동성을 확보할 수 있습니다. 무제한 유동성이라는 용어는 꽤 혼란스러울 수 있습니다. Maker 프로토콜(MakerDAO)의 사례로 무제한 유동성 구현 방법을 설명해보도록 하겠습니다. Maker는 1주일 동안 DAI를 발행하여 할인된 제한없는 유동성을 제공할 수 있습니다(일주일 기간을 갖는 플래시 민트와 같은 개념). 일주일 후 사용자는 새로 발행된 DAI를 받고 토큰 브리지의 DAI는 유동성 풀로 반환되어 소각됩니다. 무한 유동성이라고 언급했지만 시스템이 실패하지 않는 한 유효한 인출 요청은 DAI 발행을 뒷받침할 것입니다.
유효한 담보 없이 발행된 DAI는 DAI가 더 많이 유통되게 만들어 DAI 보유자에게 영향을 미칩니다. 이 방식을 개선하려면 두 가지 주요 핵심 사항을 해결해야 합니다.
- CTC에서 인출 요청 확인을 개선하기 위해 새로운 메커니즘을 도입할 수 있습니까?
- 검증 실패 시 DAI 보유자에서 MKR 보유자로 위험을 이전할 수 있습니까?
Maker와 달리 Tokamak 네트워크에는 새로운 TON을 발행할 수 있는 방법이 없습니다.
Can Oracles verify the CTC?
CTC를 검증하는 유동성 공급자 대신에 네트워크에 오라클을 도입하여 Canonical Transaction Chain에서 트랜잭션을 검증함으로써 이전 방식을 개선할 수 있습니다. 토큰 브리지에 예치된 토큰은 오라클이 출금 요청의 진위 여부를 확인한 후 해제되어 사용자에게 제공됩니다.
그러나 이 방식에는 잠재적인 위험이 존재합니다. 만일 오라클의 검증이 실패하게 되는 경우, 이 아키텍처는 이중 지출을 유발할 수 있습니다. 예를 들어 설명해보겠습니다.
Alice가 Layer 2 Optimism에서 총 100개의 ABC 토큰을 가지고 있다고 가정해 보겠습니다. 그녀는 이 100개의 ABC 토큰을 Layer 2의 Bob에게 보낸 다음 Layer 1에 대한 100개의 ABC 토큰 인출을 요청하였습니다. 이중 지출을 시도한 것입니다.
- Transfer Request
2. Withdrawal Request
처음에는 transfer() 요청이 CTC에 기록되고 나중에 withdrawalRequest()이 기록됩니다. 두 번째 거래는 토큰을 이중으로 사용하려는 시도이므로 실패해야 합니다. 표준 시나리오에서 토큰 브리지는 시퀀서가 상태 루트를 게시하고 일주일(사기 증명 기간)을 기다립니다. initialWithdrawal() 트랜잭션은 실패할 것이고 브리지는 사용자에게 토큰을 릴리즈하지 않을 것입니다.
Key takeaway: CTC에서 initialWithdrawal() 요청하는 것은 토큰 브리지에서 토큰을 릴리즈하기에 충분한 증거가 되지 못합니다. initialWithdrawal()이 성공하고 브리지에서 토큰을 릴리즈하는지를 확인해야 합니다.
현재 방식은 오라클이 CTC 트랜잭션을 실행하고 출금 요청을 검증하는 것입니다. 오라클의 응답에 따라 브리지는 사용자에게 토큰을 릴리즈할 것입니다. 오라클 검증이 실패하면 이중 지출이 발생할 수 있으며 Alice는 Layer 2에서 100개의 ABC 토큰을 사용하고 Layer 1에서 100개의 토큰을 인출할 수 있습니다. 이는 ABC 보유자의 손실로 이어집니다.
MakerDAO 사례로 돌아가서 오라클 검증 실패로 인해 DAI 토큰에 이중 지출이 발생하면 DAI 보유자가 손실을 감수해야 합니다.
그렇다면 DAI 보유자에서 MKR 보유자(Maker 프로토콜 거버넌스에 대한 책임)로 위험을 어떻게 이전할 수 있을까요?
Who will take the loss if the Oracle fails?
이제 인출 확인 시 브리지에서 직접 토큰을 릴리즈하는 것은 영리한 방법이 아니라는 것을 알게 되었습니다.
Maker가 이 문제를 해결하기 위해 Maker Vault를 도입한 방법을 분석해 보겠습니다.
즉시 인출을 원하는 사용자는 토큰 브리지에 도움을 요청합니다. 브리지는 Maker Vault와 상호 작용하며 Maker Vault는 오라클에 인출 요청의 진위 여부를 확인하도록 요청합니다. 오라클이 인출 요청 검증에 성공하면 Maker Vault는 새로운 DAI를 발행하여 사용자에게 제공합니다. 결과적으로 Maker 금고에 부채가 생성되고, 토큰 브리지가 에스크로한 DAI를 금고에 반환할 때(사기 증명 기간 이후) 상환됩니다.
What would happen if the oracle fails in this architecture?
중요한 부분은 이벤트가 진행되는 동안 손실을 누가 떠맡을 것인가 하는 것입니다. Maker Vault(Maker 프로토콜로 관리)는 요청(인출 청구)을 뒷받침하는 유효한 담보가 있다고 가정하여 새로운 DAI를 발행했습니다. 결과적으로 Maker 프로토콜과 MKR 보유자는 새로 발행된 DAI에 대한 유효한 담보가 없는 경우 손실을 감수해야 합니다. 따라서 네트워크를 위한 강력한 오라클 시스템을 정의하는 것은 Maker 프로토콜의 책임입니다.
Key Takeaway :위험이 DAI 보유자에서 MKR 보유자로 어떻게 이동했는지 주목하십시오.
이제 Tokamak 네트워크에서 이러한 시스템을 채택할 수 있을까요?
이미 알고 계시겠지만, Vault를 사용하여 직접 TON을 발행한 다음 사용자와 공유할 수 있는 방법이 없습니다. 또한 시스템에 DAI와 같은 스테이블 코인이 없습니다. 사용자 요청을 처리하기 위해서는 다른 소스에서 TON 유동성을 풀링해야 합니다. 후속 게시물에서 우리는 Tokamak 네트워크에서 이 문제를 해결하는 방법에 대한 더 자세한 개요를 설명할 것입니다.
Improving design by tokenizing the Withdrawal claims
이 버전에서 사용자는 인출 청구를 토큰화하여 즉시 인출에 사용하는 방법을 적용해볼 것입니다. 사용자는 이제 브리지나 Vault에 요청하는 대신 발행인(Minter)과 직접 상호 작용하고 발행인에게 인출 요청을 토큰화하도록 요청하게 됩니다. 발행자는 오라클에 인출 요청의 진위 여부를 확인한 다음 인출 요청을 토큰화하도록 요청할 수 있습니다. 아래 이미지는 이 구조가 Maker 프로토콜에서 어떻게 작동하는지 설명하고 있습니다.
사용자는 이제 이러한 토큰화된 클레임(fDAI)을 사용하여 2차 시장에서 이를 교환하거나 수집한 다음 Vault의 담보로 사용할 수 있습니다. Vault는 fDAI 담보를 받아들이고 사용자를 위해 DAI를 발행합니다. 사용자는 또한 모든 토큰화된 클레임을 수집하여 Vault로 대량 발행을 할 수 있으므로 가스 비용을 아낄 수 있습니다.
Key Takeaway: 출금 요청을 토큰화할 수 있으며 원하는 토큰을 받기 위한 담보로 사용할 수 있습니다.
다음 포스트에서 우리는 Tokamak 네트워크에 가장 적합한 방식에 대해 논의할 것입니다.
