BitVM은 최근 Taproot Wizards의 Tyler와 Rijndael이 BitVM 기반의 양방향 페그 운영자에게 부과된 유동성 요구 사항에 대한 비판을 게시한 이후 일부 비판을 받게 되었습니다. BitVM 기반의 레이어 2 솔루션에 대한 최근 논의에서, 저는 이러한 문제를 논의하고 디자인 공간에 관심이 있는 사람들이 아키텍처가 운영자에게 부과하는 담보화/유동성 요구 사항을 이해하고 있다고 당연하게 여겼습니다. “유동성 위기” 문제에 대한 최근 논의는 제가 이 가정에 대해 잘못 생각하고 있었음을 보여주며, BitVM 개발에 적극적으로 참여하지 않는 많은 사람들이 이 문제를 인식하지 못하고 있음을 알게 되었습니다.
유동성 위기 문제에 대해 논의하기 전에, BitVM 페그(알트코인 개발자들이 브리지라고 부르는)의 고유한 특성 중 하나를 명확히 하는 것이 중요하다고 생각합니다. 다른 네트워크에 구축된 브리지에서는 자금이 실제로 네트워크 간의 자금 이동을 제어하는 브리지 계약에 보관되며, 이 자금이 실제로 인출을 처리하는 데 사용됩니다. BitVM 페그의 경우, 이러한 자금은 인출을 이행하기 위해 접근할 수 없습니다. 시스템의 운영자(롤업, 사이드체인 등)는 사용자 인출 요청을 처리하기 위해 실제로 자신의 유동성을 선불해야 합니다.
사용자 인출 요청이 들어오면, 롤업 상태를 실제로 진행하는 운영자는 모든 요청을 살펴보고 자신의 개인 자금을 사용하여 이러한 인출을 처리합니다. 일정 시간이 지나면 시스템은 모든 보류 중인 인출을 약속하는 컷오프에서 상태를 체크포인트합니다. 운영자가 마지막 상태에서 모든 보류 중인 인출을 이행한 후에는 BitVM 보안 자금에서 자신을 보상하기 위한 청구 프로세스에 참여할 수 있습니다. BitVM 계약은 운영자가 마지막 상태에서 모든 보류 중인 인출을 이행하지 않은 경우 이러한 자금을 청구할 수 있는 능력이 취소될 수 있도록 설정되어 있습니다.
따라서 일반적인 사용자 흐름은 BitVM에 의해 보호되는 계약에 예치금이 들어가고, 운영자는 인출을 처리하기 위해 자신의 자본을 선불하며, 이후 주기적으로 운영자는 BitVM 계약에서 자신이 지출한 금액을 보상받습니다. 이는 BitVM 페그를 다른 유형의 양방향 페그와 구별하며, 라이트닝 네트워크와 유사한 유동성 요구 사항을 도입합니다.
유동성 위기
Taproot Wizards가 그들의 글에서 지적한 문제는 운영자에게 부과된 선불 유동성 요구 사항과 BitVM의 검증자가 특정 롤업 에포크에서 모든 인출을 이행하지 않은 경우 운영자의 자금 접근을 취소할 수 있도록 하는 사기 증명 방식의 조합에서 비롯됩니다. 이는 시스템, 특히 운영자에게 큰 잠재적 문제를 만듭니다.
지금은 운영자가 악의적인 검열로 인해 인출 처리를 의도적으로 거부하는 잠재적 시나리오는 완전히 무시하겠습니다. 이는 현재 잠재적 문제를 살펴보는 데 우려할 사항이 아닙니다. 운영자가 그런 행동을 한다면, 그들은 자금 접근이 취소되어야 하며 인출 처리에 이미 지출한 자금을 잃게 될 것입니다.
정직한 운영자가 악의적인 의도 없이 단일 롤업 에포크에서 보류 중인 인출을 처리할 수 있는 충분한 유동성에 접근하지 못하는 상황에 처할 가능성이 절대적으로 있습니다. 이러한 일이 발생하면, 정직한 운영자는 BitVM 계약에서 자신이 처리한 것에 대해 보상받을 수 없게 되며, 단일 검증자가 그들에게 도전하여 자금에 대한 접근을 영구적으로 잃게 될 위험에 처하게 됩니다. 그 에포크에서 인출 처리에 지출한 모든 자금은 회수할 수 없는 손실이 됩니다.
이는 페그 운영자에게 큰 위험을 초래합니다. 악의적인 행동 없이, 단순히 자신의 자금 한계, 자금을 빌리는 이자율 증가, 자금 접근에 필요한 시간 등의 요인으로 인해 막대한 금액을 잃을 수 있습니다. 이는 페그의 큰 잠재적 불안정을 초래하며, 운영자가 사기 증명에 의해 타격을 받을 경우 사용자 자금이 어디로 가는지에 대한 질문을 제기합니다.
옵션
중요한 점은 자금의 궁극적인 종착지가 특정 페그 구현자의 디자인 선택에 따라 달라진다는 것입니다. 디자인 선택에서 상당한 자유가 있으며, 도전으로 운영자가 퇴출된 후 자금의 최종 목적지는 여러 가지 옵션이 있고, 운영자가 모든 인출을 이행해야 하는 에포크 종료 후 기간은 구성 가능하며, 이러한 것들은 단일한 방법으로 설정되어 있지 않습니다.
이제 문제를 이해했으니 몇 가지 잠재적 해결책을 살펴보겠습니다.
스로틀링
인출을 스로틀링하여 문제를 해결할 수 있습니다. 이는 운영자가 특정 롤업 에포크에서 이행해야 하는 자금의 최대 한도를 설정하는 것을 포함합니다. 이를 통해 운영자는 최대한 처리해야 할 자본이 충분한지 확인할 수 있습니다. 각 기간 동안 운영자는 그 수만큼의 인출을 처리하고, BitVM 계약에서 자신을 보상하기 위한 청구 프로세스를 거친 후, 다음 에포크에서 그 금액을 재활용하여 다음 인출 요청을 이행할 수 있습니다.
문제는 시스템에 자금이 대량으로 유입될 때가 언제인지 알 수 없고, 시장 활동이 대량의 자금이 시스템에서 페그 아웃되도록 유도할 때가 언제인지 알 수 없다는 것입니다. 더 많은 자금이 페그되면, 한 번에 페그 아웃하고자 하는 대량의 자금이 증가할 가능성이 높아집니다. 이러한 역학은 최대 에포크 인출 금액을 늘리지 않는 한, 시스템에서 나가려는 대기열이 계속해서 증가하게 만듭니다. 이는 운영자에게 유동성 요구 사항을 증가시킵니다.
이는 이러한 페그의 유동성 요구 사항을 악화시키며, 본질적으로 인출에 대한 큰 마찰을 생성합니다. 스왑 아웃은 문제를 해결하지 않으며, 이는 결국 상대방의 유동성을 이 끊임없이 증가하는 대기열에 가두게 됩니다. 다른 양방향 페그에서는 스왑을 촉진한 후 거의 즉시 나갈 수 있지만, 이 경우는 그렇지 않습니다.
다수의 운영자
BitVM 1과 BitVM 2는 여러 검증자를 지원하여 여러 개의 운영자가 자금에 대한 접근을 취소할 수 있도록 합니다. BitVM 2(및 Citrea 롤업과 같은 일부 BitVM 기반 페그)에서는 여러 운영자가 병렬로 작업할 수 있습니다. 여러 개의 엔티티가 페그에서 인출을 처리할 수 있으므로, 페그를 촉진하기 위한 여러 유동성 풀을 사용할 수 있습니다.
이론적으로 이는 전체 유동성 역학을 훨씬 더 확장 가능하게 만들며, 더 이상 단일 엔티티가 시스템에서 적시에 인출을 촉진하기 위해 유동성을 선불해야 하는 제약을 받지 않게 됩니다. 그러나 이는 복잡성에 대한 질문을 도입합니다. BitVM 페그에 예치된 각 UTXO는 청구 조건이 정의되어야 하며, 그 계약은 이제 여러 운영자를 구별할 수 있어야 하며, 어떤 인출이 어떤 운영자와 관련이 있는지를 구별할 수 있어야 하며, 다른 운영자를 위한 자금이 아닌 자신이 촉진한 것만 청구할 수 있도록 해야 합니다.
또한 모든 운영자가 충족해야 할 글로벌 인출 수요를 처리하는 방법을 고려해야 합니다. 모든 운영자가 가진 자본을 다 사용했지만 여전히 충족되지 않은 수요가 있다면 어떻게 될까요? 그들은 모두 BitVM 자금에 대한 접근이 취소되나요? 아무도? 대기열 스로틀과 유사한 롤오버 유예 기간이 있나요? 만약 그렇다면, 다음 에포크에서 인출이 여전히 이행되지 않을 경우 누가 책임을 집니까? 이러한 모든 사항은 구체적으로 해결되어야 합니다.
다수의 선형 운영자
병렬 운영자를 두는 것 외에도, 선형 운영자의 체인을 가질 수 있습니다. 단일 운영자가 한 번에 기능하여 인출을 촉진하고, 만약 그들이 유동성 문제에 직면하고 BitVM 자금에 대한 접근이 취소된다면, 도전/취소 프로세스 후 자금은 즉시 새로운 운영자가 있는 새로운 BitVM으로 전송될 수 있습니다. 이는 단일 운영자가 유동성 위기를 겪는 위험을 전혀 해결하지 않으며, 그들이 이미 예치한 인출금의 손실을 인식하게 되지만, 누군가가 개입하여 BitVM에서 보상을 청구할 수 있는 기회를 계속해서 인출을 촉진할 수 있도록 보장합니다.
그러나 이는 페그인 프로세스에 상당한 비용을 추가합니다. BitVM 인스턴스를 생성하는 것은 데이터와 상호작용 측면에서 저렴하지 않으며, 이처럼 선형 BitVM 운영자를 연결하려면 페그인에 필요한 수의 BitVM을 생성해야 합니다.
백스톱
BitVM을 사용하는 모든 페그의 경우 궁극적인 질문이 있습니다: 최악의 실패 시 자금은 결국 어디로 가는가? 궁극적으로 두 가지 옵션이 있습니다. 자금을 실제로 소각하거나, 검증자의 통제 하에 두는 것입니다. 첫 번째는 사용자의 자금이 파괴되며, 페그에 자금을 보유한 모든 사람이 피해를 입는 것을 의미합니다. 두 번째는 신뢰 모델이 개인 검증자 또는 연합의 검증자 그룹을 신뢰하는 것으로 완전히 전환되며, 이들이 자금을 일방적으로 통제하게 됩니다.
자금을 소각하는 것은 인출 스로틀이 없는 모델에서는 시작할 수 없는 문제입니다. 이는 Taproot Wizards가 제기한 최악의 시나리오 우려를 확인하는 것이기 때문입니다. 운영자가 일관되게 실패하는 경우, 병렬이든 선형이든 관계없이 사용자의 자금이 실제로 파괴되는 결과를 초래합니다. 이러한 모델이 상대적으로 안전할 수 있는 유일한 경우는 인출 스로틀이 있는 경우입니다. 그러나 그 경우에도 계약에 의해 정의된 운영자가 사라지거나 접근이 취소된다면, 자금의 영구 손실 위험은 여전히 존재합니다.
따라서 자금을 단일 검증자 또는 그들의 그룹의 통제 하에 두는 것이 남습니다. 모든 운영자가 완전히 실패할 경우, 이는 시스템에 참여한 검증자가 사용자 자금을 회수하고 보상할 수 있도록 합니다. 이는 나쁘지 않다고 생각합니다.
모든 BitVM 인스턴스는 BitVM 계약에 관련된 모든 사전 서명된 거래를 서명하는 n-of-n 멀티시그로 설정됩니다. 전체 계획의 궁극적인 보안 모델은 그 키 보유자 중 한 명이 정직해야 하며, 자금을 부정하게 분배하는 서명을 거부해야 시스템이 안전하다는 것입니다.
그 동일한 보안 모델은 모든 운영자가 실패할 경우 자금이 어디로 가는지(운영자 제외)에 적용될 수 있습니다. 그러나 이는 단일 키가 분실되거나 협조하지 않아 자금을 소각할 위험을 도입하므로, 이를 전통적인 m-of-n 멀티시그로 만들 수도 있습니다.
이러한 유형의 설정에는 전혀 문제가 없으며, 사용자의 자금이 되돌릴 수 없게 소각되지 않도록 보장하는 목표를 달성합니다. 궁극적으로 BitVM 계약의 직접적인 참여자가 아니라면, 즉 그 n-of-n 키 중 하나를 직접 보유하지 않는다면, 여전히 어떤 형태의 연합을 신뢰하게 됩니다. 안전하게 유지하기 위해 단일 구성원이 정직하다고 신뢰해야 하는 것은 5-of-7 멀티시그에서 3명을 신뢰해야 하는 것보다 분명히 우수하지만, 여전히 위임된 신뢰의 형태입니다.
마무리
결국, Taproot Wizards가 지적한 유동성 위기 문제는 매우 정당한 문제라고 생각합니다. 문제의 특정 아키텍처에 따라, 이는 사용자 자금을 완전히 소각하는 것부터, 악의적인 행동 없이 운영자의 자금을 잃는 것, 또는 대기열을 우회하지 않고도 인출을 중단하거나 n-of-n 그룹에 의존하게 만드는 것까지 문제를 일으킬 수 있습니다.
그러나 제 의견으로는, BitVM을 사용하여 양방향 페그를 확보하는 아이디어가 근본적으로 잘못된 아이디어라는 것을 의미하지는 않습니다. 특정 구현이 문제를 백스톱하거나 완화할 수 있는 방법을 여러 가지 제시했으며, 궁극적으로 n-of-n 그룹이 존재하고 실패 시 자금을 위임된 그룹으로 밀어 인출을 처리할 수 있는 가능성이 영구적인 자금 손실 위험을 해결할 수 있습니다.
마지막으로, 이 분야의 개발 속도가 지난 1년 동안 제가 여기서 본 적이 없는 속도로 증가했습니다. 이러한 개발에 대해 논의할 때, 거래와 위험에 대한 논의가 발생할 때 한 걸음 물러서서 차분한 마음을 유지하는 것이 중요하다고 생각합니다. 공공의 인식은 이러한 대화의 한 측면이지만, 이러한 논의는 문제에 대한 정확한 이해에 도달하는 목표에 뿌리를 두어야 합니다. 이는 특정 공공 인식을 유도하거나 방어하려는 것보다 우선시되어서는 안 됩니다.
