Multicoin Capital의 파트너인 Kyle Samani는 모듈 블록체인이 과대평가되는 7가지 이유를 자세히 설명했습니다.
원문: 모듈형 시스템의 숨겨진 비용
작성자: Kyle Samani , Multicoin Capital 파트너
편집자: Luffy, Foresight News
표지: Unsplash 의 Nathan Watson 사진
지난 2년 동안 블록체인 확장성 논쟁은 "모듈 통합 사이의 논쟁"이라는 중심 주제에 집중되어 왔습니다.
암호화폐에 대한 논의는 종종 "단일" 시스템과 "통합" 시스템을 혼동한다는 점에 유의하십시오. 통합 시스템과 모듈 시스템에 대한 기술적인 논쟁은 40년의 오랜 역사를 갖고 있습니다. 암호화폐 공간에서의 이러한 대화는 역사와 동일한 렌즈를 통해 구성되어야 하며 이는 새로운 논쟁과는 거리가 멀습니다.
모듈 통합을 고려할 때 블록체인이 내릴 수 있는 가장 중요한 설계 결정은 스택의 복잡성이 애플리케이션 개발자에게 노출되는 정도입니다. 블록체인의 고객은 애플리케이션 개발자이므로 최종 설계 결정은 이들의 관점을 고려해야 합니다.
오늘날 모듈 블록체인이 확장되는 주요 방법으로 널리 환영받고 있습니다. 이 기사에서는 첫 번째 원칙에서 이 가정에 도전하고, 모듈 시스템의 문화적 신화와 숨겨진 비용을 밝히고, 지난 6년 동안 이 논쟁에 대해 생각하면서 얻은 결론을 공유할 것입니다.
모듈 시스템은 개발 복잡성을 증가시킵니다.
모듈 시스템의 숨겨진 가장 큰 비용은 개발 프로세스에 복잡성이 추가된다는 점입니다.
모듈 시스템은 자체 애플리케이션의 맥락(기술적 복잡성)과 다른 애플리케이션과의 상호 작용의 맥락(사회적 복잡성) 모두에서 애플리케이션 개발자가 관리해야 하는 복잡성을 크게 증가시킵니다.
암호화폐의 맥락에서 모듈 블록체인은 이론적으로 더 큰 전문화를 허용하지만 새로운 복잡성을 생성하는 대가를 치르게 됩니다. 이러한 복잡성(기술적 및 사회적 성격 모두)은 애플리케이션 개발자에게 전달되어 궁극적으로 애플리케이션 구축을 더욱 어렵게 만듭니다.
예를 들어 OP 스택을 생각해 보세요. 현재로서는 가장 널리 사용되는 모듈 프레임 인 것 같습니다. OP Stack은 개발자가 체인의 법칙 (많은 사회적 복잡성을 가져옴)을 채택하거나 별도로 포크 하고 관리하는 것 중에서 선택하도록 강요합니다. 두 옵션 모두 건축업자에게 상당한 다운스트림 복잡성을 야기합니다. 포크 선택하면 새로운 기술 표준을 준수하기 위해 비용을 지불해야 하는 다른 생태계 참여자(CEX, 법정화폐 온램프 등)로부터 기술 지원을 받게 됩니까? 만약 당신이 사슬의 법칙을 따르기로 선택한다면, 오늘과 내일 당신에게 어떤 규칙과 제약이 부과될 것인가?
최신 운영 체제(OS)는 수백 개의 하위 시스템을 포함하는 크고 복잡한 시스템입니다. 최신 운영 체제는 위 다이어그램에서 레이어 2-6을 처리합니다. 이는 애플리케이션 개발자에게 노출되는 스택 복잡성을 관리하기 위해 모듈 구성 요소를 통합하는 전형적인 예입니다. 애플리케이션 개발자는 레이어 7 아래의 어떤 것도 다루고 싶지 않습니다. 이것이 바로 운영 체제가 존재하는 이유입니다. 애플리케이션 개발자가 레이어 7에 집중할 수 있도록 아래 레이어의 복잡성을 관리하기 위해서입니다. 그러므로 모듈 그 자체가 목표가 아니라 목적을 위한 수단이 되어야 합니다.
오늘날 전 세계의 모든 주요 소프트웨어 시스템(클라우드 백엔드, 운영 체제, 데이터베이스 엔진, 게임 엔진 등)은 고도로 통합되어 있으며 많은 모듈 하위 시스템으로 구성되어 있습니다. 소프트웨어 시스템은 성능을 극대화하고 개발 복잡성을 줄이기 위해 고도로 통합되는 경향이 있습니다. 블록체인의 경우에도 마찬가지입니다.
그런데 이더 2011~2014년 비트코인 포크 시대에 나타난 복잡성을 줄이고 있습니다. 모듈 지지자들은 종종 OSI(개방형 시스템 상호 연결) 모델을 강조하며 DA(데이터 가용성)와 실행이 분리되어야 한다고 주장하지만 이 주장은 널리 오해되고 있습니다. 당면한 문제를 올바르게 이해하면 반대 결론, 즉 OSI가 모듈 시스템이 아니라 통합 시스템이라는 주장으로 이어집니다.
모듈 형 체인은 코드를 더 빠르게 실행할 수 없습니다
설계상 "모듈 형 체인"의 일반적인 정의는 데이터 가용성(DA)과 실행을 분리하는 것입니다. 한 노드 세트는 DA를 담당하고 다른 노드 세트(또는 세트)는 실행을 담당합니다. 노드 컬렉션은 중복될 필요는 없지만 중복될 수 있습니다.
실제로 DA와 실행을 분리한다고 해서 둘 중 하나의 성능이 본질적으로 향상되는 것은 아닙니다. 오히려 세계 어딘가의 일부 하드웨어는 DA를 수행해야 하고 일부 하드웨어는 실행을 구현해야 합니다. 이러한 기능을 분리해도 성능이 향상되지는 않습니다. 분리하면 계산 비용을 줄일 수 있지만 실행을 중앙 집중화해야만 줄일 수 있습니다.
다시 강조하자면, 모듈 또는 통합 아키텍처에 관계없이 일부 하드웨어는 어딘가에서 작업을 완료해야 하며 DA와 실행을 별도의 하드웨어로 분리한다고 해서 본질적으로 전체 시스템 용량이 빨라지거나 늘어나지는 않습니다.
어떤 사람들은 모듈 통해 여러 EVM이 롤업 방식으로 병렬로 실행될 수 있어 실행이 수평으로 확장될 수 있다고 주장합니다. 이론적으로는 이것이 맞지만, 이 관점 실제로 전체 시스템 처리량을 확장하는 맥락에서 DA와 실행을 분리한다는 기본 전제보다는 단일 스레드 프로세서로서 EVM의 한계를 강조합니다.
모듈 만으로는 처리량이 향상되지 않습니다.
모듈 사용자의 거래 비용이 증가합니다.
정의에 따르면 각 L1과 L2는 자체 상태를 갖는 독립적인 자산 원장입니다. 비록 LayerZero 및 Wormhole과 같은 크로스체인 브리지를 통해 개발자와 사용자에게 더 긴 트랜잭션 지연과 더 많은 복잡성이 있더라도 이러한 개별 상태 조각은 통신할 수 있습니다.
자산 원장이 많을수록 모든 계정의 글로벌 상태가 더욱 단편화됩니다. 이는 여러 체인에 걸쳐 있는 체인과 사용자 모두에게 끔찍한 일입니다. 상태 조각화는 다음과 같은 일련의 결과를 가져올 수 있습니다.
- 유동성 감소로 인한 거래 슬리피지 증가
- 더 많은 총 가스 소비(크로스체인 거래에는 최소 두 개의 자산 원장에서 최소 두 번의 거래가 필요함)
- 자산 원장 전반에 걸쳐 이중 계산 증가(따라서 전체 시스템 처리량 감소): ETH-USDC의 가격이 Binance 또는 Coinbase에서 움직일 때 모든 자산 원장의 모든 ETH-USDC 풀에서 차익 거래 기회가 발생합니다(쉽게 상상할 수 있듯이 Binance 또는 Coinbase에서 ETH-USDC 가격이 움직일 때마다 10개의 변동이 있습니다. 둘 이상의 거래가 조각난 상태에서 가격을 일관되게 유지하는 것은 블록 공간을 매우 비효율적으로 사용하는 것입니다.
더 많은 자산 원장을 생성하면 이러한 모든 차원, 특히 DeFi와 관련된 차원에서 비용이 크게 증가한다는 점을 인식하는 것이 중요합니다.
DeFi에 대한 주요 입력은 온체인 상태(즉, 누가 어떤 자산을 소유하고 있는지)입니다. 팀이 애플리케이션 체인/롤업을 출시하면 자연스럽게 상태 조각화가 생성됩니다. 이는 애플리케이션의 복잡성(브리지, 지갑, 지연, 크로스체인 MEV 등)을 관리하는 개발자와 사용자( 미끄러짐, 결제 지연).
DeFi의 가장 이상적인 조건은 자산이 단일 자산 원장에서 발행되고 단일 상태 머신 내에서 거래된다는 것입니다. 자산 원장이 클수록 애플리케이션 개발자가 관리해야 하는 복잡성도 커지고 사용자가 부담해야 하는 비용도 높아집니다.
앱 롤업은 개발자에게 새로운 수익 기회를 창출하지 않습니다.
AppChain/Rollup 지지자들은 인센티브가 애플리케이션 개발자가 L1이나 L2에 구축하는 대신 롤업을 개발하도록 유도하여 애플리케이션이 MEV 가치 자체를 포착할 수 있다고 믿습니다. 그러나 애플리케이션 롤업을 실행하는 것이 MEV를 애플리케이션 계층 토큰으로 다시 캡처하는 유일한 방법이 아니며 대부분의 경우 최선의 방법이 아니기 때문에 이 아이디어에는 결함이 있습니다. 애플리케이션 계층 토큰은 온체인 스마트 계약에 로직을 코딩하기만 하면 MEV를 자체 토큰으로 다시 캡처할 수 있습니다. 몇 가지 예를 고려해 보겠습니다.
- 청산: 컴파운드 또는 Aave DAO가 청산 봇으로 흐르는 MEV의 일부를 캡처하려는 경우 현재 청산인에게 흐르는 수수료의 일부가 별도의 필요 없이 자체 DAO에 지불되도록 각자의 계약을 간단히 업데이트할 수 있습니다. 새로운 체인/롤업의 경우.
- 오라클: 오라클 토큰은 백 러닝 서비스를 제공하여 MEV를 캡처할 수 있습니다. 가격 업데이트 외에도 오라클 가격 업데이트 후 즉시 실행되도록 보장되는 임의의 온체인 트랜잭션을 번들로 묶을 수 있습니다. 따라서 오라클 검색자, 블록 빌더 등에 백러닝 서비스를 제공하여 MEV를 캡처할 수 있습니다.
- NFT 민트: NFT 민트 에는 봇 재판매가 만연합니다. 이는 감소하는 이익의 재분배를 코딩하기만 하면 쉽게 완화할 수 있습니다. 예를 들어 누군가 NFT 발행 후 2주 이내에 재판매를 시도하면 수익금의 100%가 발행자 또는 DAO에게 돌아갑니다. 이 비율은 시간이 지남에 따라 변경될 수 있습니다.
MEV를 애플리케이션 계층 토큰으로 캡처하는 데 대한 보편적인 대답은 없습니다. 그러나 조금만 생각하면 애플리케이션 개발자는 쉽게 MEV를 온체인 자체 토큰으로 다시 캡처할 수 있습니다. 완전히 새로운 체인을 출시하는 것은 단순히 불필요하며 개발자에게 추가적인 기술적, 사회적 복잡성을 가져올 뿐만 아니라 사용자에게 더 많은 지갑 및 유동성 문제를 가져올 것입니다.
애플리케이션 롤업은 애플리케이션 간 정체 문제를 해결할 수 없습니다.
많은 사람들은 애플리케이션 체인/롤업이 인기 있는 NFT 민트 과 같은 다른 온체인 활동으로 인한 가스 급증으로 인해 애플리케이션이 영향을 받지 않도록 보장한다고 믿습니다. 이 관점 대부분은 틀렸다.
이는 역사적인 문제이며 근본 원인은 DA와 실행이 분리되지 않아서가 아니라 EVM의 단일 스레드 특성에 있습니다. 모든 L2는 L1에 수수료를 지불하며 L1 수수료는 언제든지 인상될 수 있습니다. 올해 초 밈코인 열풍 당시 Arbitrum과 Optimism의 거래 수수료는 잠시 10달러를 초과했습니다. 최근에는 Worldcoin 출시 이후 Optimism의 수수료도 급등했습니다.
수수료 급증을 해결하기 위한 유일한 솔루션은 1) L1 DA를 최대화하고 2) 수수료 시장을 최대한 개선하는 것입니다.
L1의 리소스가 제한되면 각 L2의 최대 사용량이 L1으로 전달되어 다른 모든 L2에 더 높은 비용이 부과됩니다. 따라서 애플리케이션 체인/롤업은 가스 급증의 영향을 받지 않습니다.
많은 EVM L2의 공존은 현지화 수수료 시장을 시험해 보는 조잡한 방법일 뿐입니다. 단일 EVM L1에 수수료 시장을 두는 것보다는 낫지만, 핵심 문제를 해결하지는 못합니다. 솔루션이 지역화된 수수료 시장 이라는 것을 알게 되면 논리적 엔드포인트는 L2별 수수료 시장이 아니라 주별 수수료 시장이 됩니다.
다른 체인에서는 이미 이러한 결론에 도달했습니다. Solana와 Aptos는 자연스럽게 수수료 시장을 현지화합니다. 이를 위해서는 각 실행 환경에 대해 수년에 걸친 대량 엔지니어링 작업이 필요했습니다. 대부분의 모듈 식 지지자들은 지역 수수료 시장 엔지니어링의 중요성과 어려움을 심각하게 과소평가합니다.
현지화 수수료 시장, 출처: https://blog.labeleven.dev/why-solana
여러 체인을 출시함으로써 개발자는 실제 성능 향상을 얻을 수 없습니다. 트랜잭션 볼륨을 증가시키는 애플리케이션이 있는 경우 모든 L2 체인의 비용이 영향을 받습니다.
유연성이 과대평가되었습니다
모듈 체인 지지자들은 모듈 아키텍처가 더 유연하다고 주장합니다. 이 진술은 분명히 사실이지만, 그것이 정말로 중요합니까?
6년 동안 저는 일반 L1이 제공할 수 없는 의미 있는 유연성을 갖춘 애플리케이션 개발자를 찾으려고 노력해 왔습니다. 그러나 지금까지 세 가지 매우 구체적인 사용 사례 외에 유연성이 중요한 이유와 유연성이 확장에 직접적으로 어떻게 도움이 되는지 명확히 설명할 수 있는 사람은 아무도 없었습니다. 유연성이 중요한 세 가지 구체적인 사용 사례는 다음과 같습니다.
"핫" 상태를 활용하는 애플리케이션입니다. 핫 상태는 일부 작업 집합을 실시간으로 조정하는 데 필요한 상태이지만 일시적으로만 온체인 에 제출되며 영원히 존재하지 않습니다. 열 상태의 몇 가지 예:
- dYdX, Sei 등 DEX의 지정가 주문(많은 지정가 주문이 취소됨)
- 주문 흐름은 MM (Market Making) 와 지갑 사이의 탈중앙화 주문 흐름 시장을 촉진하는 프로토콜인 dFlow에서 실시간으로 조정되고 식별됩니다.
- 지연 시간이 짧은 오라클 인 Pyth와 같은 오라클 입니다. Pyth는 독립형 SVM 체인으로 실행됩니다. Pyth는 너무 많은 데이터를 생성하므로 핵심 Pyth 팀은 고주파 가격 업데이트를 독립형 체인에 보낸 다음 Wormhole을 사용하여 필요에 따라 가격을 다른 체인에 연결하는 것이 가장 좋다고 결정했습니다.
합의 체인을 수정합니다. 가장 좋은 예는 모든 거래가 검증자에게 전송되기 전에 암호화되는 Osmosis와 지불된 수수료에 따라 블록 내 거래의 순서 되는 Thorchain입니다.
어떤 방식으로든 임계값 서명 체계(TSS)를 활용하는 인프라가 필요합니다. 이에 대한 몇 가지 예로는 Sommelier, Thorchain, Osmosis, Wormhole 및 Web3Auth가 있습니다.
Pyth 및 Wormhole을 제외하고 위에 나열된 모든 예제는 Cosmos SDK를 사용하여 구축되었으며 독립형 체인으로 실행됩니다. 이는 핫 상태, 합의 수정, 임계값 서명 체계(TSS) 시스템 등 세 가지 사용 사례 모두에 대한 Cosmos SDK의 적용 가능성과 확장성에 대해 많은 것을 말해줍니다.
그러나 위 세 가지 사용 사례의 프로젝트 대부분은 애플리케이션이 아니라 인프라입니다.
Python과 dFlow는 애플리케이션이 아니라 인프라입니다. Sommelier, Wormhole, Sei 및 Web3Auth는 애플리케이션이 아니라 인프라입니다. 그중 사용자 대상 애플리케이션의 특정 유형은 DEX(dYdX, Osmosis, Thorchain)뿐입니다.
6년 동안 저는 Cosmos와 Polkadot 지지자들에게 그들이 제공하는 유연성으로 인해 발생하는 사용 사례에 대해 질문해 왔습니다. 나는 몇 가지 추론을 할 수 있을 만큼 충분한 데이터가 있다고 생각합니다.
우선, 인프라 예제는 가치가 낮은 데이터(예: 핫 상태, 핫 상태의 요점은 데이터가 L1에 다시 커밋되지 않는다는 점)를 너무 많이 생성하거나 롤업으로 존재해서는 안 됩니다. 원장의 자산과 의도적으로 일치하지 않는 것 상태 업데이트 관련 기능(예: 모든 TSS 사용 사례)
둘째, 핵심 시스템 설계 변경으로 이익을 얻을 수 있는 유일한 애플리케이션은 DEX였습니다. DEX에는 MEV가 넘쳐나고, 유니버설 체인은 CEX의 지연 시간을 따라잡을 수 없기 때문입니다. 합의는 거래 실행 품질과 MEV의 기초이므로 합의에 따른 변화는 자연스럽게 DEX에 많은 혁신 기회를 가져올 것입니다. 그러나 이 기사의 앞부분에서 언급했듯이 현물 DEX에 대한 주요 입력은 거래되는 자산입니다. DEX는 자산과 자산 발행자를 두고 경쟁합니다. 이 프레임 에서는 자산 발행자가 자산 발행 시 고려하는 주요 문제가 DEX 관련 MEV가 아니라 일반적인 스마트 계약 기능과 이 기능을 개발자의 각 애플리케이션에 통합하기 때문에 독립적인 DEX 체인이 성공할 가능성이 없습니다.
그러나 파생상품 DEX는 자산 발행자를 놓고 경쟁할 필요가 없으며 가격을 제공하기 위해 주로 USDC 및 오라클 과 같은 담보에 의존하며 본질적으로 파생상품 포지션을 담보로 사용자 자산을 고정해야 합니다. 따라서 독립적인 DEX 체인이라는 의미에서는 dYdX, Sei 등 파생상품 중심의 DEX에 적용될 가능성이 가장 높습니다.
게임, DeSoc 시스템(예: Farcaster 및 Lens), DePIN 프로토콜(예: Helium, Hivemapper, Render Network, DIMO 및 Daylight), 사운드, NFT 거래소 등을 포함하여 현재 존재하는 일반적인 통합 L1 애플리케이션을 고려해 보겠습니다. 이들 중 어느 것도 합의 수정으로 인한 유연성의 이점을 전혀 누리지 못하며 각각의 자산 원장은 낮은 수수료, 낮은 대기 시간, 현물 DEX에 대한 액세스, 스테이블코인에 대한 액세스 및 법정화폐 채널(예: CEX)
이제 우리는 대다수의 사용자 대상 애플리케이션이 이전 단락에 열거된 것과 동일한 일반 요구 사항을 갖고 있다고 어느 정도 말할 수 있을 만큼 충분한 데이터를 보유하고 있다고 생각합니다. 일부 응용 프로그램은 스택의 사용자 정의 기능을 사용하여 여백에서 다른 변수를 최적화할 수 있지만 이러한 사용자 정의에 따른 절충은 일반적으로 그만한 가치가 없습니다(더 많은 브리지, 지갑 지원 감소, 인덱싱/조회 프로그램 지원 감소, 법적 통화 감소). 채널 등).
새로운 자산 원장을 출시하는 것은 유연성을 달성하는 한 가지 방법이지만 가치를 추가하는 경우는 거의 없으며 거의 항상 애플리케이션 개발자에게 궁극적인 이점이 거의 없는 기술 및 사회적 복잡성을 도입합니다.
DA 연장에는 재담보대출이 필요하지 않습니다.
또한 확장의 맥락에서 재가설에 관해 모듈 식 지지자들이 이야기하는 것을 듣게 될 것입니다. 이것은 모듈 체인 지지자들의 가장 추측적인 주장이지만 논의할 가치가 있습니다.
재스테이킹(예: EigenLayer와 같은 시스템을 통해)으로 인해 전체 암호화폐 생태계가 ETH를 무제한으로 다시 스테이킹할 수 있어 DA 레이어(예: EigenDA) 및 실행 레이어에 무제한의 권한을 부여할 수 있다고 대략적으로 설명합니다. 따라서 ETH 가치의 상승을 보장하면서 모든 측면에서 확장성을 해결합니다.
현재 상황과 이론적 미래 사이의 엄청난 불확실성에도 불구하고 우리는 모든 계층화 가정이 광고된 대로 작동한다는 것을 당연하게 여깁니다.
현재 이더 의 DA는 약 83KB/s입니다. 올해 말 EIP-4844가 도입되면 이 속도는 대략 두 배인 약 166KB/s가 될 것입니다. EigenDA는 10MB/s를 추가할 수 있지만 다른 보안 가정이 필요합니다(모든 ETH가 EigenDA에 다시 담보되는 것은 아닙니다).
이에 비해 솔라나는 현재 약 125MB/s(블록당 32,000개의 파쇄, 파쇄당 1,280바이트, 초당 2.5블록)의 DA를 제공합니다. Solana는 이더 및 EigenDA보다 훨씬 효율적입니다. 또한 Nelson의 법칙 에 따르면 Solana의 DA는 시간이 지남에 따라 확장됩니다.
재스테이킹 및 모듈 통해 DA를 확장하는 방법에는 여러 가지가 있지만 이러한 메커니즘은 오늘날에는 필요하지 않으며 상당한 기술적, 사회적 복잡성을 초래할 수 있습니다.
애플리케이션 개발자를 위해 제작됨
수년간 고민한 끝에 저는 모듈 자체가 목표가 되어서는 안 된다는 결론에 도달했습니다.
블록체인은 고객(예: 애플리케이션 개발자)에게 서비스를 제공해야 합니다. 따라서 블록체인은 개발자가 세계적 수준의 애플리케이션을 구축하는 데 집중할 수 있도록 인프라 수준의 복잡성을 추상화해야 합니다.
모듈 은 훌륭합니다. 그러나 승리하는 기술을 구축하는 열쇠는 스택의 어떤 부분을 통합해야 하고 어떤 부분을 다른 부분에 남겨야 하는지 파악하는 것입니다. 현재로서는 DA와 실행 체인을 통합하면 본질적으로 최종 사용자와 개발자에게 더 간단한 경험을 제공하고 궁극적으로 동급 최고의 애플리케이션을 위한 더 나은 기반을 제공하게 될 것입니다.
면책조항: 블록체인 정보 플랫폼으로서 이 사이트에 게시된 기사는 작성자와 게스트 관점 만을 나타낼 뿐이며 Web3Caff의 입장과는 아무런 관련이 없습니다. 이 기사의 내용은 정보 공유만을 위한 것이며 투자 조언이나 제안을 구성하지 않습니다. 귀하가 위치한 국가 또는 지역의 관련 법률 및 규정을 준수하십시오.
