모든 언어
공유
저자: Pranav Garimidi, Joachim Neu, Max Resnick 컴파일러: Luffy, Foresight News
이제 블록체인은 기존 금융 인프라와 경쟁할 수 있는 능력을 갖추고 있다고 자신있게 주장할 수 있습니다. 현재 생산 시스템은 초당 수만 건의 트랜잭션을 처리할 수 있으며 앞으로 성능은 몇 배나 향상될 것입니다.
그러나 순수한 처리량을 넘어서는 금융 애플리케이션에는 예측 가능성이 필요합니다. 거래가 시작될 때, 그것이 거래이든, 경매 입찰이든, 옵션 행사이든, 온체인 거래 시점에 대한 신뢰성 있는 보장을 갖는 것은 금융 시스템의 정상적인 운영을 위해 필요한 조건입니다. 거래가 예측할 수 없는 지연에 직면하게 되면 수많은 애플리케이션을 사용할 수 없게 됩니다. 온체인 금융 애플리케이션이 경쟁력을 갖기 위해서는 블록체인이 단기 온체인 보증을 제공해야 합니다. 유효한 거래가 네트워크에 제출되는 한 가능한 한 빨리 블록에 패키징되도록 보장됩니다.
예를 들어 온체인 주문서의 경우입니다. 효율적인 주문서를 위해서는 시장 조성자가 지속적으로 유동성을 제공하고 시장에서 매수 및 매도 주문을 해야 합니다. 마켓메이커가 직면한 핵심 이슈는 호가가 시장과 동떨어져 역선택을 피하는 동시에 매수호가 스프레드를 최대한 줄이는 것입니다. 이를 위해 시장 조성자는 최신 시장 상황을 반영하여 주문을 지속적으로 업데이트해야 합니다. 예를 들어, 연준의 발표로 인해 자산 가격이 급격하게 변동할 경우 시장 조성자는 즉시 대응하고 주문을 새로운 가격으로 업데이트해야 합니다. 마켓 메이커가 주문을 업데이트하는 데 사용하는 거래가 즉시 체인에 업로드될 수 없는 경우 차익거래자는 오래된 가격으로 거래를 완료하여 마켓 메이커가 손실을 입게 됩니다. 그때쯤이면 마켓메이커는 위험을 줄이기 위해 가격 차이를 확대할 수밖에 없으며, 이는 온체인 거래 플랫폼의 경쟁력 저하로 이어질 것입니다.
예측 가능한 거래 온체인 메커니즘은 마켓 메이커에게 신뢰할 수 있는 보증을 제공하여 오프체인 이벤트에 신속하게 대응하고 온체인 시장의 효율적인 운영을 유지할 수 있도록 해줍니다.
현재 주류 블록체인은 최종 온체인 보증만 제공할 수 있으며 유효 기간은 초 단위로 측정되는 경우가 많습니다. 이러한 유형의 보호는 결제와 같은 애플리케이션에는 충분하지만 시장 참여자가 실시간으로 정보에 응답해야 하는 대부분의 금융 애플리케이션을 지원할 수는 없습니다.
주문서 예시로 돌아가서: 시장 조성자에게 차익거래자의 거래가 이전 블록으로 패키징될 수 있는 한 "초 이내에 온체인"을 보장하는 것은 의미가 없습니다. 강력한 온체인 보증이 없으면 시장 조성자는 가격 차이를 확대하고 사용자에게 더 나쁜 견적을 제공함으로써 위험을 방지할 수 있습니다. 이는 더 강력한 보장을 제공하는 다른 플랫폼보다 온체인 거래를 덜 매력적으로 만듭니다.
블록체인이 자본 시장을 위한 현대적인 인프라가 되겠다는 비전을 진정으로 실현하려면 개발자는 주문서와 같은 고부가가치 애플리케이션이 번성할 수 있도록 이러한 문제를 해결해야 합니다.
이러한 시나리오를 지원하기 위해 기존 블록체인에서 거래 온체인 보장을 강화하는 것은 극히 어렵습니다. 일부 프로토콜은 단일 노드(블록 생성 노드)를 사용하여 특정 기간 동안 트랜잭션 패키징 순서를 결정합니다. 이는 고성능 퍼블릭 체인의 엔지니어링 설계를 단순화하지만 블록 생성 노드가 가치를 포착할 수 있는 잠재적인 경제적 독점 지점을 생성하기도 합니다.
일반적으로 노드가 블록 노드로 선출되는 동안 해당 노드는 블록에 포함되는 트랜잭션을 완전히 제어할 수 있습니다.
많은 양의 금융 활동을 수행하는 블록체인의 경우 블록 생성 노드가 특권적인 위치에 있습니다. 노드가 트랜잭션 패키징을 거부하는 경우 사용자는 이를 패키징하려는 다음 블록 생성 노드만 기다릴 수 있습니다. 무허가형 네트워크에서 블록 생성 노드는 자연스럽게 가치를 추출하려는 인센티브를 갖게 되는데, 이를 흔히 MEV라고 부릅니다.
MEV는 샌드위치 공격 그 이상입니다. 블록 생성 노드가 거래를 수십 밀리초만 지연시키더라도 여전히 막대한 이익을 얻을 수 있으며 기본 애플리케이션의 운영 효율성을 저하시킬 수 있습니다. 일부 트레이더의 주문에만 우선순위를 두는 주문서는 다른 모든 트레이더에게 불공정한 입장을 취하게 됩니다. 최악의 경우, 블록 생산자의 악의적인 행동으로 인해 거래자가 플랫폼을 완전히 떠날 수도 있습니다.
금리 인상 소식이 발표되고 ETH 가격이 즉시 5% 하락한다고 가정해 보겠습니다. 주문서에 있는 모든 시장 조성자는 기존 주문을 취소하고 새 가격으로 다시 주문하기를 원합니다. 동시에 모든 차익거래자는 ETH를 이전 가격에 판매하라는 주문을 제출하게 됩니다.
오더북이 단일 블록 생산자 프로토콜에서 실행된다면 이 노드는 엄청난 힘을 갖게 될 것입니다. 모든 시장 조성자의 취소 거래를 검토하도록 선택할 수 있어 차익거래자가 막대한 이익을 얻을 수 있습니다. 또는 직접 검토할 수는 없지만 취소 거래를 지연시켜 재정 거래를 먼저 완료할 수 있습니다. 가격 편차로부터 이익을 얻기 위해 자체 재정 거래를 직접 삽입할 수도 있습니다.
이러한 이점에 직면하여 시장 조성자의 적극적인 참여는 비경제적이게 되며 가격이 변동하는 한 이용당할 수 있습니다. 문제는 본질적으로 블록 생성 노드의 두 가지 주요 권한에서 비롯됩니다:
다른 사람의 거래를 검토할 수 있습니다.
<리>다른 사람의 거래를 보고 그에 따라 자신의 거래를 제출할 수 있습니다.
이 두 가지 문제 중 하나라도 치명적인 결과를 초래할 수 있습니다.
우리는 이 문제를 정확하게 설명하기 위해 경매를 사용합니다. Alice와 Bob이라는 두 명의 입찰자가 있고 Bob이 경매가 위치한 블록의 블록 생산자라고 가정해 보겠습니다. (예를 들어 두 명의 입찰자만 사용되었으며 논리는 원하는 수의 사람에게 확장될 수 있습니다.)
경매는 블록 생성 주기 동안(예: 0부터 1까지) 입찰을 수락합니다. Alice는 tA 시간에 입찰 bA를 제출하고 Bob은 나중에 tB 시간에 입찰 bB를 제출합니다. Bob은 블록 생산자이기 때문에 항상 자신이 마지막에 행동하도록 보장할 수 있습니다.
두 사람 모두 지속적으로 업데이트되는 가격 소스(예: 중앙 집중식 거래소의 중앙 가격)에서 자산 가격을 얻어 시간 t의 가격을 pₜ로 기록할 수 있습니다. 우리는 언제든지 t에서 경매 종료 시(t=1) 자산의 양 당사자의 예상 가격이 현재 가격 pₜ와 같다고 가정합니다. 경매 규칙은 간단합니다. 가장 높은 입찰자가 낙찰되어 자신의 입찰가를 지불하는 것입니다.
Bob이 블록 생산자의 신원을 사용하여 Alice의 입찰을 검토할 수 있다면 경매 메커니즘은 완전히 효과가 없게 됩니다. Bob은 승리를 보장하기 위해 임의로 낮은 가격을 제시하기만 하면 되며 경매에서 발생하는 최종 수익은 0에 가깝습니다.
더 복잡한 상황은 Bob이 Alice의 입찰을 직접 검토할 수는 없지만 입찰하기 전에 Alice의 입찰을 볼 수 있다는 것입니다. 이 시점에서 Bob은 간단한 전략을 가지고 있습니다:
현재 가격 pₜ_B > bA인 경우 bA보다 약간 높은 가격을 제시합니다.
<리>그렇지 않으면 입찰을 직접 포기하세요.
이 전략을 통해 Bob은 Alice를 역선택에 노출시킵니다. Alice는 자신의 입찰가가 자산의 예상 가치보다 높은 경우에만 승리할 수 있으며 승리는 돈을 잃는 것을 의미하므로 결국 경매에서 철회하기로 결정하게 됩니다. 모든 경쟁자가 떠나면 Bob은 경매에서 낙찰되기 위해 매우 낮은 가격을 입찰할 수 있으며 수입도 거의 0에 가깝습니다.
핵심 결론은 입찰 기간은 중요하지 않다는 것입니다. Bob이 Alice의 입찰을 검토하거나 입찰하기 전에 Alice의 입찰을 볼 수 있는 한 경매는 실패할 것입니다.
이 논리는 현물, 무기한 계약, 파생상품 거래소를 포함한 빈도가 높은 거래 시나리오에도 적용됩니다. 이 경우 블록 생성 노드가 Bob의 힘을 갖고 있다면 시장은 완전히 실패할 것입니다. 그러한 시나리오를 지원하는 온체인 제품이 실현 가능하려면 블록 생성 노드에 그러한 권한을 부여해서는 안 됩니다.
위의 분석은 단일 블록 생성 노드가 허가 프로토콜 없이 체인에서 거래되는 암울한 전망을 보여줍니다. 그러나 이러한 많은 프로토콜에서 분산형 거래소(DEX)의 거래량은 여전히 상당합니다. 왜요?
실제로 위의 문제를 상쇄하는 두 가지 힘이 있습니다.
블록 생성 노드는 일반적으로 다수의 네이티브 토큰을 보유하고 있으며 퍼블릭 체인의 성공 또는 실패에 깊이 묶여 있으므로 경제적 힘을 완전히 남용하지 않습니다.
<리>애플리케이션 계층은 이러한 유형의 문제에 대한 취약성을 줄이기 위한 해결 방법을 개발했습니다.
이러한 두 가지 요소로 인해 DeFi가 지금까지 정상적으로 작동할 수 있었지만 장기적으로는 온체인 시장이 오프체인 상대와 진정으로 경쟁할 수 있게 되기에는 충분하지 않습니다.
경제 활동이 활발한 퍼블릭 체인에서 블록 생산 노드가 되려면 많은 양의 서약이 필요합니다. 따라서 노드는 자체적으로 많은 수의 토큰을 보유하거나 다른 보유자로부터 위임을 받을 만큼 충분한 평판을 가지고 있습니다. 두 경우 모두 대규모 노드 운영자는 평판이 좋은 잘 알려진 단체입니다. 또한, 약속된 자산은 퍼블릭 체인의 발전을 유지하기 위한 인센티브도 제공합니다. 이 때문에 아직 노드가 완전히 권력을 남용하는 경우는 본 적이 없지만 그렇다고 문제가 존재하지 않는다는 의미는 아닙니다.
우선, 노드 운영자의 선의, 사회적 압력, 장기적인 인센티브에 의존하는 것은 미래 금융의 믿을 만한 초석이 아닙니다. 온체인 금융의 규모가 확대됨에 따라 노드의 잠재적 수익도 동시에 증가할 것입니다. 이러한 유혹이 클수록 노드가 단기적인 이익에 반하는 것을 제지하는 사회적 차원의 압력은 더욱 취약해질 것입니다.
둘째, 노드가 자신의 권력을 남용하는 정도는 온화한 행동부터 노골적인 시장 파괴까지 연속체에 있습니다. 노드 운영자는 더 높은 수익을 얻기 위해 일방적이고 점진적으로 자신의 힘을 확장할 수 있으며, 누군가가 수익을 깨면 다른 사람들도 빠르게 따라올 것입니다. 단일 노드의 행동은 제한된 영향을 미치는 것처럼 보일 수 있지만 집단적인 행동은 분명한 결과를 가져올 수 있습니다.
가장 일반적인 예는 타이밍 게임입니다. 블록 생성 노드는 프로토콜이 허용하는 범위 내에서 이익을 극대화하기 위해 가능한 한 늦게 블록을 게시합니다. 이로 인해 블록 시간이 연장되고 심지어 블록이 누락될 수도 있습니다. 이러한 전략의 수익성은 잘 알려져 있지만, 처음에는 노드가 퍼블릭 체인을 유지하기 위한 책임 때문에 자제를 선택했습니다. 그러나 이러한 사회적 균형은 매우 취약하다. 노드가 비용 없이 재정 거래를 시작하면 다른 노드도 빠르게 따라오게 됩니다.
타이밍 게임은 노드가 자신의 권력을 완전히 남용하지 않고도 수익을 늘릴 수 있는 방법의 한 예일 뿐입니다. 노드가 애플리케이션을 희생하여 수익을 높이는 방법도 많이 있습니다. 이러한 행동은 단독으로 용인될 수 있지만 결국에는 온체인 실행 비용이 이점보다 더 큰 전환점에 도달합니다.
DeFi가 여전히 작동하는 또 다른 이유는 애플리케이션이 핵심 로직을 오프체인으로 이동하고 결과만 온체인에 저장하기 때문입니다. 예를 들어, 빠른 경매 실행이 필요한 프로토콜은 일반적으로 오프체인 프로세스를 완료하며, 악의적인 노드의 문제를 피하기 위해 허가된 노드 그룹을 통해 메커니즘을 작동하는 경우가 많습니다. UniswapX의 이더리움 메인 네트워크 네덜란드 경매와 Cowswap의 일괄 경매는 모두 오프체인에서 실행됩니다.
이 솔루션을 사용하면 애플리케이션을 실행할 수 있지만 기본 퍼블릭 체인과 해당 가치 제안이 당황스러운 상황에 놓이게 됩니다. 즉, 애플리케이션 실행 로직이 분산되어 기본 퍼블릭 체인이 단순한 결제 계층으로 축소됩니다. DeFi의 핵심 장점 중 하나는 구성 가능성이며, 모든 실행이 오프체인인 세상에서는 애플리케이션이 자연스럽게 섬에 격리됩니다. 오프체인 실행에 의존하면 애플리케이션의 신뢰 모델에 새로운 가정이 추가됩니다. 기본 퍼블릭 체인의 가용성 외에도 오프체인 인프라도 제대로 작동해야 합니다.
이러한 문제를 해결하려면 프로토콜은 안정적인 온체인 거래 및 주문 규칙, 거래 확인 전 개인 정보 보호라는 두 가지 주요 특성을 충족해야 합니다.
첫 번째 기능을 단기 검열 저항으로 요약합니다. 거래가 정직한 노드에 도달하면 다음 사용 가능한 블록에 포함되도록 보장됩니다.
단기 검열 저항: 제 시간에 정직한 노드에 도달하는 모든 유효한 거래는 다음 블록에 패키징되어야 합니다.
더 정확하게 말하면 프로토콜이 고정된 시계, 즉 100밀리초마다 한 블록씩 실행된다고 가정합니다. 거래가 250밀리초 이내에 정직한 노드에 도달하면 300밀리초 블록에 포함되어야 합니다. 공격자는 트랜잭션을 선택적으로 패키징하거나 무시할 수 있는 능력이 없습니다. 이 정의의 핵심 정신은 다음과 같습니다. 사용자와 애플리케이션은 트랜잭션을 체인에 업로드할 수 있는 매우 안정적인 방법을 가져야 하며, 악의적인 패킷 손실이나 단일 노드의 작동 오류로 인해 트랜잭션이 실패하지 않아야 합니다.
이 정의에서는 모든 정직한 노드에 도착하는 트랜잭션을 패키징할 수 있어야 하지만 실제 구현 오버헤드가 너무 높을 수 있습니다. 핵심은 트랜잭션 진입점을 매우 예측 가능하게 만들고 논리를 간단하고 이해하기 쉽게 만들 수 있을 만큼 프로토콜이 충분히 강력해야 한다는 것입니다.
무허가 단일 블록 생성 노드 프로토콜은 분명히 이 기능을 충족하지 않습니다. 현재 블록 생성 노드가 악의적인 행위를 하면 트랜잭션을 체인에 업로드할 수 있는 다른 방법이 없습니다. 반대로, 4개의 노드로 구성된 그룹만이 매 기간마다 패키지 트랜잭션을 보장할 수 있더라도 사용자와 애플리케이션을 위한 온체인 옵션이 크게 늘어납니다. 애플리케이션이 강력하고 번영하기 위해서는 일부 성능을 희생할 가치가 있습니다. 견고성과 성능 사이의 최적의 균형을 찾으려면 여전히 더 많은 연구가 필요하지만 기존 프로토콜을 보호하는 것만으로는 충분하지 않습니다.
프로토콜이 온체인을 보장할 수 있게 되면 주문 문제가 해결될 것입니다. 프로토콜은 결정론적 순서 규칙을 채택할 수 있습니다. 가장 간단한 방법은 우선 순위 수수료를 기준으로 정렬하거나 애플리케이션이 자체 상태와 상호 작용하는 트랜잭션을 유연하게 주문하도록 허용하는 것입니다. 거래를 주문하는 최적의 방법은 여전히 활발한 연구 분야이지만, 어떤 경우에도 주문 규칙은 거래가 체인에 성공적으로 업로드될 수 있는 경우에만 의미가 있습니다.
단기 검열 저항 이후 프로토콜이 충족해야 하는 또 다른 중요한 기능은 은폐라고 부르는 개인 정보 보호 보장입니다.
은폐성: 거래 제출 노드를 제외하고, 거래가 최종적으로 확인되고 프로토콜에 따라 정렬되기 전에는 어떤 당사자도 거래에 대한 정보를 얻을 수 없습니다.
은폐를 충족하는 프로토콜은 트랜잭션을 수신하는 노드가 트랜잭션 내용을 일반 텍스트로 볼 수 있도록 허용하지만 합의가 완료되고 트랜잭션 순서가 결정될 때까지 네트워크의 나머지 부분은 불가지론 상태를 유지하도록 요구합니다. 예를 들어, 프로토콜은 지연된 암호화를 사용하여 마감일 전에 블록 콘텐츠를 보이지 않게 할 수 있습니다. 또는 임계값 암호화를 사용하여 블록을 해독하기 전에 위원회가 해당 블록을 되돌릴 수 없음을 확인하도록 하세요.
이는 노드가 자신에게 제출된 거래 정보를 남용할 수 있지만 네트워크의 다른 노드는 사실 이후에만 거래 내용에 대해 알게 된다는 것을 의미합니다. 거래 정보가 전체 네트워크에 공개되면 해당 정보의 정렬 및 확인이 완료되며 다른 당사자가 거래를 선점할 수 없습니다. 이 정의가 적용되기 위한 전제는 각 기간에 트랜잭션을 패키지화할 수 있는 여러 노드가 있다는 것입니다.
우리는 프로토콜이 스팸 거래를 필터링해야 하기 때문에 더 강력한 개인 정보 보호 정의(예: 암호화된 메모리 풀), 즉 사용자만이 거래 정보를 알 수 있다는 정의를 채택하지 않았습니다. 거래 내용이 전체 네트워크에서 완전히 숨겨지면 네트워크는 스팸 거래와 유효한 거래를 구별할 수 없게 됩니다. 유일한 해결책은 거래의 유효성 여부에 관계없이 수수료가 공제되는 지불 주소와 같은 일부 암호화되지 않은 메타데이터를 유출하는 것입니다. 그러나 이러한 종류의 메타데이터는 공격자가 이점을 활용할 수 있는 기회를 제공하기에 충분한 정보를 공개할 수 있습니다. 따라서 우리는 절충안을 선택합니다. 단일 노드만 트랜잭션 내용을 볼 수 있고 나머지 네트워크는 볼 수 없습니다. 이는 또한 사용자가 각 기간의 온체인 진입점으로 최소한 하나의 정직한 노드를 보유해야 함을 의미합니다.
단기 검열 저항과 은폐를 모두 갖춘 프로토콜은 금융 애플리케이션 구축을 위한 이상적인 기반입니다. 온체인 경매의 예로 돌아가면, 이 두 가지 기능은 Bob이 시장을 파괴할 수 있는 두 가지 방법을 직접적으로 제거합니다. Bob은 Alice의 입찰을 검토할 수도 없고 Alice의 입찰을 사용하여 자신의 행동을 안내할 수도 없으며, 이는 위에서 언급한 두 가지 주요 문제를 완벽하게 해결합니다.
단기 검열 저항을 보장하면 모든 거래(보류 주문이든 경매 입찰이든)가 즉시 체인에 업로드되는 것이 보장됩니다. 시장 조성자는 주문을 수정할 수 있고, 입찰자는 신속하게 입찰할 수 있으며, 청산은 효율적으로 실행될 수 있습니다. 사용자는 자신의 작업이 즉시 실행되어 지연 시간이 짧은 차세대 실제 금융 애플리케이션을 완전히 온체인에 구축할 수 있다는 확신을 가질 수 있습니다.
블록체인이 기존 금융 인프라와 진정으로 경쟁하고 이를 능가하려면 처리량 문제보다 훨씬 더 많은 문제를 해결해야 합니다.