Vitalik 블로그 해석: Web3 인프라의 다음 단계는 패키징인가, 확장인가?

이더리움이 직면한 문제는 무엇인가? 포장 아니면 확장

'포장 vs 확장' 문제에서 이더리움은 항상 '확장'을 선택해왔습니다.

이더리움의 설계 철학은 Unix에서 유래되었으며, 극단적으로 간단한 범용 커널을 만들어 사용자의 요구를 애플리케이션 계층에서 개발자가 구현할 수 있도록 합니다. 이더리움이 이를 실현하는 데 필요한 핵심 기술은 EVM입니다. 튜링 완전한 스마트 계약 언어는 개발자가 애플리케이션 계층에서 각자의 애플리케이션을 사용자 정의할 수 있게 합니다.

이 모델은 합리적으로 보이지만, '탈중앙화된 Unix'에서는 그렇게 잘 작동하지 않습니다. 중요한 이유 중 하나는 EVM의 이른바 튜링 완전성이 실제 사용에서는 그렇게 '완전'하지 않기 때문입니다. 가스 메커니즘과 제한된 opcode 하에서, 프로그램은 제한된 단계 내에서 제한된 opcode를 사용하여 작업을 완료해야 하며, 이로 인해 애플리케이션이 Web2 프로그램처럼 Unix의 사용자 계층에서 무소불위로 작동하기 어렵습니다. 많은 고급 dApp이 필요로 하는 기능을 EVM이 충족하지 못합니다. Rollup이나 AA 지갑 모두 L1을 수정하지 않고도 작동할 수 있지만, 여전히 MVP 제품에 불과하며, 효율성과 경험은 그들의 목표와는 거리가 멉니다.

개발자 앞에 놓인 선택은 EIP입니다. 이더리움 핵심 팀이 의존하는 중요한 기능을 하위 시스템에 '포장'하여 애플리케이션 계층에서 사용할 수 있도록 하는 것입니다.

EVM 기반의 '확장'은 애플리케이션 발전 요구를 충족하지 못하고 있으며, 이제 그들은 '포장'을 어떻게 할 것인지 고민해야 합니다.

하지만 탈중앙화된 인프라에서 상위 애플리케이션 기능을 포장하는 것은 그렇게 간단하지 않습니다. 단순히 코드 조각을 통합하는 것이 아니라, 그 뒤에는 탈중앙화 시스템의 가장 큰 문제인 거버넌스가 있습니다. '포장'은 핵심 팀이 개발 및 유지 관리 외에도 이러한 기능의 거버넌스 작업을 수행해야 함을 의미하며, 이는 이더리움 신뢰 모델을 약화시킬 위험이 있으며, 지속 가능성에 잠재적인 영향을 미칠 수 있습니다.

따라서 최종 결과는 쉽게 볼 수 있습니다: 핵심 팀이 '포장'할 수 있는 기능의 수는 제한적이며, 이 기능의 중요성은 커뮤니티의 광범위한 합의를 얻어야 하고, 마지막으로 그 구현 효율성은 그렇게 높지 않으며, 수년이 걸릴 수 있습니다.

동시에, 필요한 기능이 광범위한 합의가 필요한 기본 기능이 아니라면, 이더리움은 당신을 수용할 수 없을 것이며, 심지어 당신의 시도조차도 수용하지 못할 수 있습니다. 이로 인해 당신은 자체 애플리케이션 체인을 선택해야 할 수도 있으며, 높은 개발 및 운영 비용을 감수해야 하고, 스마트 계약 세계의 조합성의 아름다움을 잃게 될 것입니다.

'포장 vs 확장' 문제에서 이더리움은 아직 명확한 해결 방안을 제시하지 않았습니다. '포장'이라는 일이 '질서 있게 진행'되도록 하는 방법, 즉 Vitalik이 언급한 바와 같이, 그들은 여전히 포장할 목표 기능과 그것들을 포장하는 방법을 결정하기 위한 프레임워크를 탐색하고 있습니다.

Unix에서 무엇을 더 배울 수 있을까? 네이티브 확장!

'포장 vs 확장' 문제에서 이더리움은 주로 EVM의 확장 능력이 부족하여 핵심 팀이 포장하는 일을 해야 하는 상황입니다. 다른 각도에서 생각해보면, 애플리케이션 계층의 확장성을 높이면 상당 부분 문제를 해결할 수 있을까요? 예를 들어, 애플리케이션 개발자가 자신의 생각에 따라 필요한 하위 기능을 사용자 정의할 수 있다면, 하위 팀이 포장하기를 기다릴 필요가 없습니다.

우리는 이더리움이 Unix에서 많은 설계 철학을 흡수했다는 것을 알고 있습니다. 그러니 Unix 시스템에서 아이디어를 찾아봅시다.

Unix 기반의 상용 운영 체제는 PC 시장을 대상으로 하며, 애플리케이션 계층의 다양한 요구와 기업 사용 시나리오의 확장 요구에 직면해 있습니다. 그러나 이러한 상용 운영 체제는 핵심 팀이 '포장'해야 할 부담이 크지 않으며, 애플리케이션에 제공하는 확장성이 충분히 높아 대부분의 기능을 사용자가 스스로 해결할 수 있습니다.

Mac OS X를 예로 들면, 일반 운영 체제는 커널 모드와 사용자 모드를 구분하며, 사용자 애플리케이션은 일반적으로 사용자 모드에서 실행되고 커널 모드 프로그램이 제공하는 기능을 사용합니다. 간단한(하지만 완전하지 않은) 비교는 EVM 위의 스마트 계약이 사용자 모드 애플리케이션에 해당하고, 이더리움 프로토콜 계층이 커널 모드에 해당한다는 것입니다.

그러나 Mac OS X는 애플리케이션 개발자가 프로그램을 커널 모드에 배포하여 커널 모드의 기능을 확장할 수 있도록 허용하며, Mac OS X의 핵심 팀이 개별적으로 포장할 필요가 없습니다. Mac OS X가 제공하는 핵심 메커니즘은 '커널 확장'과 '시스템 확장'이며, 이 두 가지 확장은 개발자가 특정 보안 모드에서 커널 확장을 개발할 수 있도록 하여 더 높은 권한의 기능을 사용할 수 있게 합니다. 이는 순수 사용자 모드 애플리케이션이 완료할 수 없는 기능을 개발하는 데 사용됩니다.

우리가 얻은 영감은 '커널 확장' 모델이 '탈중앙화된 Unix'에서 가능한가 하는 것입니다. 그 모델은 아래 그림과 같습니다.

블록체인 프로토콜에서는 '스마트 계약' 외에도 '네이티브 확장'이라는 또 다른 프로그램을 지원합니다. 이 프로그램은

1) 스마트 계약보다 더 많은 하위 프로토콜 API 접근 권한을 가집니다.

2) 실행 환경의 효율성이 EVM보다 수치적으로 향상됩니다.

3) 하위 프로토콜과 격리되어 하위 프로토콜의 안정성에 영향을 미치지 않습니다.

4) 따라서 거버넌스 측면에서 하위 팀이 유지 관리할 필요가 없으며, 애플리케이션 팀이 유지 관리 및 배포를 담당합니다.

이 모델이 기술적으로 위의 네 가지 조건을 충족할 수 있다면, 상당한 문제를 해결할 수 있을 것으로 보입니다: 애플리케이션 개발자가 자신의 생각에 따라 필요한 하위 기능을 사용자 정의할 수 있으며, 하위 팀이 포장하기를 기다릴 필요가 없습니다.

우리는 이 패러다임을 '네이티브 확장' 패러다임으로 요약하고, 현재 Web3 인프라에서 그 그림자가 있는지 살펴보겠습니다.

훅, 훅, 훅…

소프트웨어 세계에서 위대한 바퀴는 종종 위대한 장면에 의해 만들어집니다. DeFi 인프라로서 Uniswap은 '플랫폼'으로 나아가는 중요한 단계에 있으며, '포장 vs 확장'의 특성에서 놀라운 설계를 제시했습니다: 훅(Hook). 이는 개발자가 허가 없이 훅을 사용하여 풀에 확장을 추가하고, 핵심 팀이 계속해서 '포장'하여 기능을 업그레이드할 필요 없이 다양한 풀 경험을 실현할 수 있게 합니다.

훅의 메커니즘은 위의 네이티브 확장과 여러 조건이 유사합니다:

· 훅은 풀의 실행 생애 주기에서 개입할 수 있으며, 실행 중인 데이터에 접근할 수 있는 더 높은 접근 수준을 가집니다.

· 훅과 풀은 두 개의 독립적인 계약이며, 훅의 보안성은 풀에 영향을 미치지 않습니다.

· 거버넌스 측면에서, 훅은 제3자 개발자가 허가 없이 개발 및 배포할 수 있으며, 전역적으로 활성화되는 것이 아니라 필요에 따라 서로 다른 풀에 서로 다른 훅을 바인딩하여 사용자 정의 기능을 시작합니다.

훅은 작고 아름다운 설계로, 풀의 확장성 문제를 해결합니다. 애플리케이션 계층 인프라는 이러한 개념을 먼저 적용했으며, 이제 더 복잡한 하위 프로토콜(L1/L2)의 사고를 살펴보겠습니다.

새로운 공공 블록체인 프로젝트들의 확장 사고

Ethereum이 어려움에 처해 있는 가운데, Layer1 확장에 전념하는 Layer2 프로젝트들은 어떤 생각을 가지고 있을까요?

Arbitrum Stylus는 애플리케이션 개발자가 미리 컴파일된 계약을 스스로 포장할 수 있도록 합니다!

모두가 알다시피, EVM은 '미리 컴파일된 계약'을 통해 기능을 확장할 수 있습니다. 그 코드는 EVM 내에서 실행되지 않고, 노드에 통합되어 하위에서 실행됩니다. 예를 들어, 새로운 암호화 알고리즘을 추가해야 할 경우, 계산이 너무 복잡하고 비쌀 수 있으므로 미리 컴파일된 계약으로 구현할 수 있으며, 애플리케이션 계약은 이를 호출하여 새로운 암호화 알고리즘을 사용할 수 있습니다. 그러나 미리 컴파일된 계약의 추가 권한은 애플리케이션 개발자에게 개방되지 않으며, EIP를 통해 이더리움 개발 팀이 '포장'해야 추가할 수 있습니다.

Arbitrum Stylus는 'EVM+' 패러다임을 제안하며, Layer2는 EVM의 동등성/호환성을 추구하는 동시에 개발자가 EVM의 한계를 넘어 허가 없이 더 높은 성능의 미리 컴파일된 계약을 배포할 수 있도록 합니다. 그 구현 원리는 실행 계층에 WASM 실행 환경을 추가하여 동적으로 WASM 계약을 로드하여 실행하는 것입니다. WASM은 EVM보다 한 단계 높은 효율성을 제공하며, 여러 프로그래밍 언어를 지원합니다.

이는 이더리움의 '포장' 문제를 최적화할 수 있는 구현 중 하나가 될 수 있으며, EVM의 확장 요구는 더 이상 하위 팀의 포장을 기다리지 않게 되며, 하위 팀은 해당 실행 계층 확장 환경의 유지 관리에 집중하고, 새로운 기능의 도입, 개발 및 거버넌스는 애플리케이션 계층에서 발전하도록 맡길 수 있습니다.

하지만 Stylus는 아직 초기 단계에 있으며, 이 모델은 더 많은 도전 과제가 드러나지 않았고, 해결할 수 있는 문제도 제한적입니다. 현재는 동적으로 미리 컴파일된 계약을 포장하는 것만 지원하며, 이더리움은 미리 컴파일된 계약 외에도 더 많은 포장 문제에 직면해 있습니다. 그러나 기쁜 것은, 이는 우리가 볼 수 있는 네이티브 확장 패러다임 구현 중 하나에 가깝다는 것입니다. 새로운 세대의 인프라를 대표하여, 이는 확장성 설계를 도입하여 그들의 생태계가 미래에 대규모화될 때 직면할 '포장' 문제를 해결하고, 장기적인 생태계 발전을 고려하고 있습니다.

네이티브 확장: '모듈화 포장' 사고!

Web2와 Web3의 이러한 인프라 프로젝트를 정리한 후, '포장 vs 확장' 문제를 돌아보면, 우리는 명확한 사고를 볼 수 있습니다: 확장 능력을 높여 개발자가 모듈화된 방식으로 원하는 기능을 포장할 수 있도록 하는 것입니다.

이것이 네이티브 확장 패러다임이 인프라에서 중요한 역할을 하는 이유입니다. 인프라의 확장 능력을 높여 개발자에게 선택권을 돌려주어, 핵심 프로토콜의 안정성에 영향을 미치지 않는 전제 하에 개발자가 자유롭게 모듈화된 방식으로 원하는 기능을 포장하고 확장할 수 있도록 합니다.

이더리움은 '포장'의 효율성을 높이려 하고 있으며, Arbitrum Stylus는 미리 컴파일된 계약을 해방시키고 있습니다. 더 나아가 공공 블록체인은 네이티브 확장 패러다임을 통해 애플리케이션 계층의 창의성을 완전히 해방할 수 있습니다. 이는 Uniswap V4가 모두에게 가져다 준 느낌과 같습니다.

네이티브 확장 패러다임을 기반으로 한 새로운 L1 공공 블록체인: Artela

여기서 시각을 전환하여, '우리'는 제가 CTO로 있는 팀인 Artela를 지칭합니다. 우리는 이 문제에 대한 우리의 생각과 행동을 공유하고자 합니다.

Artela 블록체인에서는 EVM 외에도 WASM 실행 환경을 배치했습니다. 한편으로는 상태를 가진 프로그램을 실행할 수 있으며, 이는 상태를 가진 미리 컴파일된 계약과 유사합니다. 또한 이 위에서 훅과 유사한 메커니즘을 지원하여 블록 및 거래 처리의 여러 생애 주기 노드에서 실행을 트리거할 수 있습니다. 즉, 이는 단순히 Arbitrum Stylus처럼 미리 컴파일된 계약을 포장하는 것이 아니라, 거래 및 블록의 실행 흐름을 사용자 정의하여 더 넓은 기능 포장을 실현할 수 있습니다. 예를 들어, 거래 검증 단계에서 WASM의 네이티브 확장을 트리거하여 새로운 알고리즘을 사용하여 거래를 식별하고 검증할 수 있습니다. 이러한 훅은 Artela에서 Join Point라고 불리며, 이러한 네이티브 확장은 스마트 계약이 아니라 Aspect(측면)라고 불리며, 이는 AoP(Aspect-oriented Programming) 개념과 유사합니다. 실행 중인 블록체인 시스템에서 동적으로 각 Join Point에 새로운 기능을 삽입할 수 있습니다!

구체적인 예로, 우리는 투자자 및 Web2 기관과 대화하면서 대규모 자산을 Web3로 유입하는 데 가장 큰 저항이 무엇인지 논의했습니다. 가장 많이 논의된 것은 보안 문제였습니다! Web2 수준의 리스크 관리 기술이 수십억 자산의 안전을 보장하지만, 이는 Web3 기술 스택에 들어가기 어렵습니다. NASA 항공 분야의 Carl도 같은 목소리를 냈습니다: 왜 우리는 런타임 보호 및 Aspect가 필요한가.

런타임 보호는 안전 리스크 관리의 핵심 수단입니다. 현재 Web3에서는 강력한 보안 회사들이 존재하며, 정적 감사와 형식적 검증, 실시간 모니터링 및 거래를 방지하는 방법이 있지만, 이는 Web2 수준의 실시간 리스크 관리와는 거리가 멉니다. 핵심적인 근본 문제는, mempool을 둘러싼 보안 수단이 제한적이라는 것입니다. 거래가 Mempool을 넘어가면 더 이상 아무런 힘을 쓸 수 없습니다. Mempool 이후의 거래 실행 단계에서 확장 능력이 있다면, 보안 전문가가 런타임 수준의 보안 전략을 배포할 수 있게 되어 보안 수준이 한 단계 높아질 것입니다. Aspect는 개발자가 실행 계층에 깊이 있는 보안 확장 능력을 제공하는 것입니다!

개발자는 자신의 프로젝트에만 서비스를 제공하는 Aspect를 배포하여 원하는 프로토콜 계층 기능을 사용자 정의할 수 있습니다. 예를 들어, 런타임 보안을 추가하여 거래가 대규모 자금 도난을 초래할 가능성이 있는 경우, Aspect에서 차단될 수 있습니다.

개발자는 또한 여러 프로젝트에서 재사용할 수 있는 기본 기능을 포장하는 공용 Aspect를 배포할 수 있습니다. 예를 들어, 특정 알고리즘과 거래 유형을 구현한 Aspect가 AA 지갑을 더 프로그래밍 가능하고 조합 가능하게 만들며, 다른 개발자도 이 Aspect를 활성화하여 자신의 프로젝트에서 이 기본 특성을 사용할 수 있습니다.

Artela에 대해 우리는 점점 더 확고한 생각을 가지고 있습니다:

· 개발자가 애플리케이션 계층에서 네이티브 확장을 통해 허가 없이 문제를 해결할 수 있도록 하여 하위 공공 블록체인 팀의 포장을 기다리지 않게 합니다.

· Web2 배경의 대규모 기관과 자본이 블록체인에 스테이킹할 수 있도록 합니다(웹2 수준의 런타임 리스크 관리를 도입하여).

· 개발자가 좋은 생태 환경에서 혁신적인 일을 할 수 있도록 합니다(EVM은 곧 한계에 도달할 수 있으며, EVM+네이티브 확장은 더 많은 잠재력을 가질 수 있습니다).

· 전체 체인 게임, RWA 등 더 많은 비즈니스 로직을 블록체인으로 옮기고자 하는 dApp에 이상적인 환경을 제공합니다.

우리는 이더리움이 애플리케이션 특성을 '포장'하는 방법을 모색하고 있으며, 그들의 '포장' 압박을 해방하여 창의성을 다시 개발자에게 돌려줄 계획이 보이지 않는 상황을 보고 있습니다. 탈중앙화 애플리케이션의 혁신을 탐구하는 잠재적인 다음 세대 혁신자들에게 이 상황은 매우 제한적입니다. 한편으로는 그들이 강력한 탈중앙화 네트워크를 필요로 하고, 다른 한편으로는 그들이 마음껏 펼칠 수 없습니다. 이것이 우리가 네이티브 확장 패러다임을 기반으로 새로운 L1 공공 블록체인을 구축하는 데 전념하는 핵심 이유입니다. 인프라가 혁신의 발걸음을 거부하지 않도록 하기 위해서입니다.