Multicoin Capital 파트너: 7가지 측면에서 모듈화 블록체인이 과대평가된 이유 분석

저자: Kyle Samani, Multicoin Capital 파트너

편집: Luffy, Foresight News

지난 2년 동안 블록체인 확장성 논쟁은 "모듈화와 통합의 대결"이라는 중심 주제로 집중되었습니다.

주의할 점은, 암호화폐 내의 논의는 종종 "단일" 시스템과 "통합" 시스템을 혼동한다는 것입니다. 통합 시스템과 모듈화 시스템 간의 기술적 논쟁은 이미 40년의 긴 역사를 넘어서고 있습니다. 암호화폐 분야의 이 대화는 역사와 동일한 렌즈를 통해 구축되어야 하며, 이는 결코 새로운 논쟁이 아닙니다.

모듈화와 통합을 고려할 때, 블록체인이 내릴 수 있는 가장 중요한 설계 결정은 애플리케이션 개발자에게 스택의 복잡성을 어느 정도 공개할 것인가입니다. 블록체인의 고객은 애플리케이션 개발자이므로 최종 설계 결정은 그들의 입장을 고려해야 합니다.

현재 모듈화는 블록체인 확장의 주요 방법으로 널리 인정받고 있습니다. 이 글에서는 첫 번째 원칙에서 이 가정을 의문시하고, 모듈화 시스템의 문화적 신화와 숨겨진 비용을 드러내며, 지난 6년간 이 논쟁에 대해 생각하면서 얻은 결론을 공유하겠습니다.

모듈화 시스템은 개발 복잡성을 증가시킨다

지금까지 모듈화 시스템의 가장 큰 숨겨진 비용은 개발 과정의 복잡성을 증가시킨 것입니다.

모듈화 시스템은 애플리케이션 개발자가 관리해야 하는 복잡성을 크게 증가시킵니다. 이는 그들의 애플리케이션 맥락 내에서(기술적 복잡성)든, 다른 애플리케이션과 상호작용하는 맥락에서(사회적 복잡성)든 마찬가지입니다.

암호화폐 맥락에서 모듈화 블록체인은 이론적으로 더 전문화된 기능을 허용하지만, 그 대가는 새로운 복잡성을 창출하는 것입니다. 이러한 복잡성(본질적으로 기술적이고 사회적)은 애플리케이션 개발자에게 전달되어 결국 애플리케이션 구축을 더 어렵게 만듭니다.

예를 들어, OP Stack을 고려해 보십시오. 현재로서는 가장 인기 있는 모듈화 프레임워크처럼 보입니다. OP Stack은 개발자에게 Law of Chains를 채택할 것인지(이것은 많은 사회적 복잡성을 가져옵니다) 아니면 포크하고 개별적으로 관리할 것인지 선택하도록 강요합니다. 이 두 가지 선택 모두 구축자에게 엄청난 하류 복잡성을 가져옵니다. 포크를 선택하면 다른 생태계 참여자(CEX, 법정 화폐 진입 등)의 기술 지원을 받을 수 있을까요? 이러한 참여자들은 새로운 기술 표준에 맞추기 위해 비용을 부담해야 합니다. Law of Chains를 따르기로 선택하면 오늘과 내일 어떤 규칙과 제약이 당신에게 부과될까요?

출처: OSI 모델

현대 운영 체제(OS)는 수백 개의 하위 시스템을 포함하는 대규모 복잡한 시스템입니다. 현대 운영 체제는 위 그림의 2-6층을 처리합니다. 이는 애플리케이션 개발자에게 노출되는 스택 복잡성을 관리하기 위해 통합된 모듈화 구성 요소의 전형적인 예입니다. 애플리케이션 개발자는 7층 이하의 어떤 것도 처리하고 싶어하지 않으며, 이것이 운영 체제가 존재하는 이유입니다: 운영 체제는 아래층의 복잡성을 관리하여 애플리케이션 개발자가 7층에 집중할 수 있도록 합니다. 따라서 모듈화 자체가 목표가 되어서는 안 되며, 목표를 달성하기 위한 수단이어야 합니다.

오늘날 세계의 모든 주요 소프트웨어 시스템—클라우드 백엔드, 운영 체제, 데이터베이스 엔진, 게임 엔진 등—은 고도로 통합되어 있으며 동시에 많은 모듈화 하위 시스템으로 구성되어 있습니다. 소프트웨어 시스템은 성능을 극대화하고 개발 복잡성을 줄이기 위해 종종 고도로 통합됩니다. 블록체인도 마찬가지입니다.

그런데 이더리움은 2011-2014년 비트코인 포크 시대에 발생한 복잡성을 줄이고 있습니다. 모듈화 지지자들은 종종 개방형 시스템 상호 연결(OSI) 모델을 강조하며 데이터 가용성(DA)과 실행을 분리해야 한다고 주장하지만, 이 주장은 널리 오해되고 있습니다. 현재 문제에 대한 올바른 이해는 반대의 결론을 도출합니다: OSI는 모듈화 시스템이 아니라 통합 시스템의 주장을 뒷받침합니다.

모듈화 체인은 코드를 더 빨리 실행할 수 없다

설계상 "모듈화 체인"의 일반적인 정의는 데이터 가용성(DA)과 실행의 분리입니다: 한 그룹의 노드는 DA를 담당하고, 다른 그룹(또는 여러 그룹)의 노드는 실행을 담당합니다. 노드 집합은 어떤 중복도 가질 필요는 없지만, 가질 수 있습니다.

실제로 DA와 실행을 분리한다고 해서 본질적으로 두 가지 성능이 향상되지는 않습니다. 반대로, 세계의 어딘가에서 특정 하드웨어가 DA를 실행해야 하고, 다른 곳에서 특정 하드웨어가 실행을 수행해야 합니다. 이러한 기능을 분리한다고 해서 어느 하나의 성능이 향상되지는 않습니다. 분리는 계산 비용을 줄일 수 있지만, 이는 집중 실행을 통해서만 가능합니다.

다시 강조할 점은: 모듈화든 통합 아키텍처든, 어딘가의 특정 하드웨어가 작업을 완료해야 하며, DA와 실행을 별도의 하드웨어로 분리한다고 해서 본질적으로 시스템의 총 용량이 가속화되거나 증가하지는 않습니다.

일부 사람들은 모듈화가 여러 EVM이 Rollup 방식으로 병렬 실행되도록 허용하여 실행이 수평으로 확장될 수 있다고 생각합니다. 이론적으로 맞는 말이지만, 이 관점은 실제로 EVM이 단일 스레드 프로세서로서의 한계를 강조하며, DA와 실행을 분리하는 기본 전제와는 관련이 없습니다.

독립적인 모듈화는 처리량을 증가시키지 않습니다.

모듈화는 사용자 거래 비용을 증가시킨다

정의상 각 L1과 L2는 자체 상태를 가진 독립적인 자산 장부입니다. 이러한 개별 상태 조각은 통신할 수 있지만, 거래 지연이 더 길고 개발자와 사용자가 직면하는 상황도 더 복잡해집니다(LayerZero 및 Wormhole과 같은 크로스 체인 브릿지를 통해).

자산 장부가 많을수록 모든 계정의 전역 상태 조각이 많아집니다. 이는 체인과 여러 체인에 걸친 사용자에게는 끔찍한 일입니다. 상태 조각화는 여러 가지 결과를 초래할 수 있습니다:

• 유동성이 감소하여 거래 슬리피지가 더 높아진다;
• 총 가스 소비가 증가한다(크로스 체인 거래는 최소 두 개의 자산 장부에서 최소 두 번의 거래가 필요하다);
• 자산 장부 간의 중복 계산이 증가하여 시스템의 총 처리량이 감소한다: ETH-USDC의 가격이 Binance 또는 Coinbase에서 변동할 때, 모든 자산 장부의 각 ETH-USDC 풀에서 차익 거래 기회가 발생한다(ETH-USDC 가격이 Binance 또는 Coinbase에서 변동할 때마다 다양한 자산 장부에서 10건 이상의 거래가 발생하는 세상을 쉽게 상상할 수 있다. 조각화된 상태에서 가격을 일관되게 유지하는 것은 블록 공간을 극도로 비효율적으로 사용하는 것이다).

더욱 중요한 것은, 더 많은 자산 장부를 생성하면 이러한 모든 차원에서의 비용이 명백히 증가하며, 특히 DeFi와 관련된 비용이 증가한다는 점입니다.

DeFi의 주요 입력은 체인 상의 상태(즉, 누가 어떤 자산을 소유하고 있는지)입니다. 팀이 애플리케이션 체인/Rollup을 시작할 때, 그들은 자연스럽게 상태 조각화를 발생시키며, 이는 DeFi에 매우 불리합니다. 이는 애플리케이션 복잡성을 관리하는 개발자(브릿지, 지갑, 지연, 크로스 체인 MEV 등)와 사용자(슬리피지, 결제 지연) 모두에게 해당됩니다.

DeFi에 가장 이상적인 조건은 자산이 단일 자산 장부에서 발행되고 단일 상태 기계 내에서 거래되는 것입니다. 자산 장부가 많을수록 애플리케이션 개발자가 관리해야 하는 복잡성이 증가하고, 사용자가 부담해야 하는 비용도 증가합니다.

애플리케이션 Rollup은 개발자에게 새로운 수익 기회를 창출하지 않는다

애플리케이션 체인/Rollup의 지지자들은 인센티브가 애플리케이션 개발자가 L1 또는 L2에서 구축하는 대신 Rollup을 개발하도록 유도할 것이라고 주장합니다. 그러나 이 생각은 결함이 있습니다. 애플리케이션 Rollup을 운영하는 것이 MEV를 애플리케이션 레이어 토큰으로 되돌리는 유일한 방법이 아니며, 대부분의 경우 최선의 방법도 아닙니다. 애플리케이션 레이어 토큰은 단순히 일반 체인 상의 스마트 계약에 로직을 코딩하여 MEV를 자신의 토큰으로 되돌릴 수 있습니다. 몇 가지 예를 고려해 보겠습니다:

• 청산: Compound 또는 Aave DAO가 청산 로봇으로 흐르는 MEV의 일부를 포착하고 싶다면, 그들은 각자의 계약을 업데이트하여 현재 청산인에게 흐르는 수수료의 일부를 자신의 DAO에 지급하도록 하면 됩니다. 새로운 체인/Rollup이 필요하지 않습니다.
• 오라클: 오라클 토큰은 백러닝 서비스를 제공하여 MEV를 포착할 수 있습니다. 가격 업데이트 외에도, 오라클은 가격 업데이트 후 즉시 실행되는 임의의 체인 상 거래를 묶을 수 있습니다. 따라서 오라클은 검색자, 블록 생성자 등에게 백러닝 서비스를 제공하여 MEV를 포착할 수 있습니다.
• NFT 민팅: NFT 민팅은 되팔기 로봇으로 가득 차 있습니다. 단순히 감소하는 수익을 재분배하는 로직을 코딩함으로써 이 문제를 쉽게 완화할 수 있습니다. 예를 들어, 누군가 NFT 민팅 후 2주 이내에 자신의 NFT를 재판매하려고 한다면, 100%의 수익이 발행자 또는 DAO로 돌아가게 할 수 있습니다. 시간이 지남에 따라 이 비율은 변동할 수 있습니다.

MEV를 애플리케이션 레이어 토큰으로 포착하는 데는 보편적인 답이 없습니다. 그러나 약간의 생각만으로도 애플리케이션 개발자는 MEV를 일반 체인 상의 자신의 토큰으로 쉽게 포착할 수 있습니다. 완전히 새로운 체인을 출시할 필요는 없으며, 이는 개발자에게 추가적인 기술적 및 사회적 복잡성을 가져오고 사용자에게는 더 많은 지갑과 유동성 문제를 초래합니다.

애플리케이션 Rollup은 애플리케이션 간 혼잡 문제를 해결하지 못한다

많은 사람들은 애플리케이션 체인/Rollup이 애플리케이션이 다른 체인에서 발생하는 활동(예: 인기 있는 NFT 민팅)으로 인한 가스 피크의 영향을 받지 않도록 보장한다고 생각합니다. 이 관점은 부분적으로 맞지만, 대부분은 틀립니다.

이는 역사적 문제로, 근본 원인은 EVM의 단일 스레드 특성이지 DA와 실행이 분리되지 않아서가 아닙니다. 모든 L2는 L1에 비용을 지불해야 하며, L1 비용은 언제든지 증가할 수 있습니다. 올해 초의 meme코인 열풍에서 Arbitrum과 Optimism의 거래 비용은 한때 10달러를 초과했습니다. 최근에는 Optimism의 비용이 Worldcoin 출시 이후 급증했습니다.

비용 피크를 해결하는 유일한 해결책은: 1) L1 DA를 최대화하고, 2) 가능한 한 세분화된 비용 시장을 만드는 것입니다:

L1의 자원이 제한되면, 각 L2의 사용 피크는 L1으로 전달되어 모든 다른 L2에 더 높은 비용을 초래합니다. 따라서 애플리케이션 체인/Rollup은 가스 피크의 영향을 피할 수 없습니다.

많은 EVM L2가 공존하는 것은 비용 시장을 지역화하려는 조잡한 방법일 뿐입니다. 이는 단일 EVM L1에 비용 시장을 두는 것보다 나은 방법이지만, 핵심 문제를 해결하지는 못합니다. 해결책이 비용 시장의 지역화라는 것을 인식하면, 논리적 종착지는 각 상태의 비용 시장(각 L2의 비용 시장이 아니라)입니다.

다른 체인들은 이 결론에 도달했습니다. Solana와 Aptos는 자연스럽게 비용 시장을 지역화했습니다. 이는 수년간 각자의 실행 환경을 위한 대규모 엔지니어링 작업이 필요합니다. 대부분의 모듈화 지지자들은 지역 비용 시장 엔지니어링의 중요성과 난이도를 심각하게 과소평가하고 있습니다.

지역화된 비용 시장, 출처: https://blog.labeleven.dev/why-solana

여러 체인을 출시한다고 해서 개발자는 진정한 성능 이점을 얻을 수 없습니다. 애플리케이션이 거래량을 증가시킬 때, 모든 L2 체인의 비용이 영향을 받습니다.

유연성이 과대평가되었다

모듈화 체인의 지지자들은 모듈화 아키텍처가 더 유연하다고 주장합니다. 이 말은 분명히 맞지만, 정말 중요한가요?

6년 동안 저는 일반 L1이 제공할 수 없는 의미 있는 유연성을 찾기 위해 노력해왔습니다. 그러나 지금까지 세 가지 매우 구체적인 사용 사례를 제외하고는 유연성이 왜 중요한지, 그리고 그것이 어떻게 확장에 직접적으로 도움이 되는지를 명확히 설명한 사람은 없었습니다. 제가 유연성이 중요하다고 생각하는 세 가지 구체적인 사용 사례는 다음과 같습니다:

"핫" 상태를 활용하는 애플리케이션. 핫 상태는 특정 작업 집합을 실시간으로 조정하는 데 필요한 상태이지만, 일시적으로 체인에 제출되며 영구적으로 존재하지 않습니다. 핫 상태의 몇 가지 예는 다음과 같습니다:

• DEX의 제한 주문, 예를 들어 dYdX와 Sei(많은 제한 주문이 결국 취소됩니다).
• dFlow에서 실시간으로 주문 흐름을 조정하고 식별하는 것(dFlow는 시장 조성자와 지갑 간의 분산 주문 흐름 시장을 촉진하는 프로토콜입니다).
• Pyth와 같은 오라클, 이는 저지연 오라클입니다. Pyth는 독립적인 SVM 체인으로 운영됩니다. Pyth는 너무 많은 데이터를 생성하여 핵심 Pyth 팀은 고주파 가격 업데이트를 독립 체인으로 보내고 필요에 따라 Wormhole을 사용하여 가격을 다른 체인으로 브릿지하는 것이 가장 좋다고 결정했습니다.

합의를 수정하는 체인. 가장 좋은 예는 Osmosis(모든 거래가 검증자에게 전송되기 전에 암호화됨)와 Thorchain(지불된 수수료에 따라 블록 내 거래의 우선 순위를 매김)입니다.

어떤 방식으로든 임계 서명 계획(TSS)을 활용해야 하는 인프라. 이와 관련된 몇 가지 예는 Sommelier, Thorchain, Osmosis, Wormhole 및 Web3Auth입니다.

Pyth와 Wormhole을 제외한 위의 모든 예는 Cosmos SDK를 사용하여 구축되었으며 독립 체인으로 운영됩니다. 이는 Cosmos SDK가 세 가지 사용 사례(핫 상태, 합의 수정 및 임계 서명 계획(TSS) 시스템)에 대해 얼마나 적합하고 확장 가능한지를 잘 보여줍니다.

그러나 위의 세 가지 사용 사례 중 대부분의 프로젝트는 애플리케이션이 아니라 인프라입니다.

Pyth와 dFlow는 애플리케이션이 아니라 인프라입니다. Sommelier, Wormhole, Sei 및 Web3Auth는 애플리케이션이 아니라 인프라입니다. 그들 중 사용자 지향 애플리케이션은 DEX(예: dYdX, Osmosis, Thorchain)라는 특정 유형뿐입니다.

6년 동안 저는 Cosmos와 Polkadot 지지자들에게 그들이 제공하는 유연성이 가져오는 사용 사례에 대해 질문해왔습니다. 저는 어느 정도 추론을 할 수 있는 충분한 데이터가 있다고 생각합니다:

첫째, 인프라 예시는 Rollup으로 존재해서는 안 됩니다. 왜냐하면 이들은 너무 많은 저가치 데이터를 생성하거나(예: 핫 상태, 핫 상태의 전부는 데이터가 L1으로 제출되지 않는 것에 있기 때문) 자산 장부의 상태 업데이트와 관련된 기능을 의도적으로 수행하기 때문입니다(예: 모든 TSS 사용 사례).

둘째, 제가 본 유일한 애플리케이션은 핵심 시스템 설계 변경으로부터 이익을 얻을 수 있는 DEX입니다. DEX는 MEV로 가득 차 있으며, 일반 체인은 CEX의 지연과 일치할 수 없습니다. 합의는 거래 실행 품질과 MEV의 기초이므로, 합기 기반의 변화는 자연스럽게 DEX에 많은 혁신 기회를 제공합니다. 그러나 본문에서 언급했듯이, 현물 DEX의 주요 입력은 거래되는 자산입니다. DEX는 자산을 차지하기 위해 자산 발행자를 차지합니다. 이 프레임워크에서 독립 DEX 체인은 성공할 가능성이 낮습니다. 왜냐하면 자산 발행자가 자산 발행 시 고려하는 주요 문제는 DEX 관련 MEV가 아니라 일반 스마트 계약 기능과 그 기능을 개발자 각자의 애플리케이션에 통합하는 것이기 때문입니다.

그러나 파생상품 DEX는 자산 발행자를 차지할 필요가 없으며, 주로 USDC와 같은 담보 및 오라클 가격 피드를 의존하며 본질적으로 사용자의 자산을 잠가 파생상품 포지션을 담보해야 합니다. 따라서 독립 DEX 체인의 의미에서, dYdX 및 Sei와 같은 파생상품에 집중하는 DEX에 가장 적합할 가능성이 높습니다.

현재 존재하는 일반 통합 L1 애플리케이션을 고려해 보겠습니다: 게임, DeSoc 시스템(예: Farcaster 및 Lens), DePIN 프로토콜(예: Helium, Hivemapper, Render Network, DIMO 및 Daylight), Sound, NFT 거래소 등. 이들은 합의 수정으로 인한 유연성의 혜택을 특별히 받지 않으며, 각자의 자산 장부는 상당히 간단하고 명백하며 공통된 요구 사항을 가지고 있습니다: 낮은 수수료, 낮은 지연, 현물 DEX 접근, 스테이블코인 접근 및 CEX와 같은 법정 화폐 경로 접근.

저는 이제 충분한 데이터가 있어 대다수의 사용자 지향 애플리케이션이 이전 단락에서 열거한 것과 동일한 일반 요구 사항을 가지고 있다고 어느 정도 설명할 수 있다고 믿습니다. 특정 애플리케이션은 스택 내의 사용자 정의 기능을 통해 다른 변수를 한계적으로 최적화할 수 있지만, 이러한 사용자 정의가 가져오는 트레이드오프는 일반적으로 가치가 없습니다(더 많은 브릿지, 더 적은 지갑 지원, 더 적은 인덱스/쿼리 프로그램 지원, 법정 화폐 경로 감소 등).

새로운 자산 장부를 출시하는 것은 유연성을 실현하는 한 가지 방법이지만, 이는 거의 가치를 추가하지 않으며 거의 항상 기술적 및 사회적 복잡성을 초래하고 애플리케이션 개발자에게 최종적으로 얻는 이익은 미미합니다.

DA 확장은 재담보를 필요로 하지 않는다

모듈화 지지자들은 확장 맥락에서 재담보에 대해 이야기하는 것을 들을 수 있습니다. 이는 모듈화 체인 지지자들이 제기한 가장 추측적인 주장 중 하나이지만, 논의할 가치가 있습니다.

이는 대략적으로 재담보(예: EigenLayer와 같은 시스템)를 통해 전체 암호화 생태계가 ETH를 무한히 재담보하여 무한한 수의 DA 레이어(예: EigenDA)와 실행 레이어에 힘을 실어줄 수 있다는 점을 지적합니다. 따라서 ETH의 가치 상승을 보장하면서 모든 측면에서 확장성을 해결합니다.

현재 상황과 이론적인 미래 사이에는 큰 불확실성이 존재하지만, 우리는 모든 계층 가정이 광고된 대로 효과적이라고 당연하게 여깁니다.

현재 이더리움의 DA는 약 83 KB/s입니다. 올해 늦게 EIP-4844가 출시되면 이 속도가 약 166 KB/s로 두 배 증가할 수 있습니다. EigenDA는 추가로 10 MB/s를 증가시킬 수 있지만, 이는 서로 다른 보안 가정 조건 세트를 필요로 합니다(모든 ETH가 EigenDA에 재담보되지 않습니다).

대조적으로, Solana는 현재 약 125 MB/s의 DA를 제공합니다(각 블록 32,000개의 shred, 각 shred 1,280 바이트, 초당 2.5 블록). Solana는 이더리움과 EigenDA보다 훨씬 더 효율적입니다. 또한 닐슨 법칙에 따르면, Solana의 DA는 시간이 지남에 따라 확장됩니다.

재담보와 모듈화를 통해 DA를 확장하는 방법은 많지만, 이러한 메커니즘은 오늘날 전혀 필요하지 않으며 명백한 기술적 및 사회적 복잡성을 초래합니다.

애플리케이션 개발자를 위해 구축하기

수년간의 고민 끝에, 저는 모듈화 자체가 목표가 되어서는 안 된다는 결론에 도달했습니다.

블록체인은 고객(즉, 애플리케이션 개발자)을 위해 서비스해야 하므로, 블록체인은 인프라 수준의 복잡성을 추상화하여 개발자가 세계적 수준의 애플리케이션 구축에 집중할 수 있도록 해야 합니다.

모듈화는 훌륭합니다. 그러나 성공적인 기술을 구축하는 핵심은 스택의 어떤 부분을 통합해야 하고 어떤 부분을 다른 사람에게 맡겨야 하는지를 파악하는 것입니다. 현재로서는 DA와 실행을 통합한 체인이 본질적으로 더 간단한 최종 사용자 및 개발자 경험을 제공하며, 궁극적으로는 일류 애플리케이션에 더 나은 기반을 제공할 것입니다.