Vitalik의 블로그 게시물 해석: Web3 인프라 캡슐화 또는 확장의 다음 단계는 무엇입니까?

星球君的朋友们

Odaily资深作者

2023-10-27 02:21

이 기사는 약 4306자로, 전체를 읽는 데 약 7분이 소요됩니다

이 기사에서는 Web3 인프라의 캡슐화 대 확장의 설계 선택과 퍼블릭 체인 인프라 문제에 대한 개인적인 생각에 대해 논의할 것입니다.

AI 요약

펼치기

이 기사에서는 Web3 인프라의 캡슐화 대 확장의 설계 선택과 퍼블릭 체인 인프라 문제에 대한 개인적인 생각에 대해 논의할 것입니다.

원래 제목: 캡슐화인가 확장인가? Web3 인프라에 대한 다음 논의 - Vitalik Enshrinement 블로그 해석

원저자: CP, Artela CTO 및 공동 창립자

Vitalik은 지난주 이더리움이 프로토콜에 더 많은 것을 담는 것이 괜찮을까요?라는 블로그를 게시하여 이더리움의 암호 상위 계층 애플리케이션에 필요한 기본 기능에 대한 생각을 공유하고 더 많은 기본 기능을 캡슐화하는 프레임워크를 추천하는 방법에 대해 논의했습니다. 상위 계층 애플리케이션에 필요한 기능.

이는 일반적인 플랫폼 시스템이 직면한 주요 문제입니다. 팀이 주요 상위 계층 애플리케이션 기능을 하위 계층으로 캡슐화해야 하는지, 아니면 애플리케이션 개발자가 이러한 기능을 애플리케이션 계층에서 확장해야 하는지 말입니다. 인프라가 대규모 확장으로 발전할 때 캡슐화 vs. 확장의 설계는 매우 중요하며 대규모 적용 여부에 영향을 미치는 핵심 설계 중 하나가 될 것입니다.

지난 6개월 동안 여러 주요 인프라에서 중요한 기술 업데이트가 시작되었습니다. Uniswap은 사용자 정의 기능을 확장하는 풀을 지원하는 Hook 메커니즘을 출시했습니다. MetaMask 지갑은 개발자가 사용자 확장을 추가할 수 있도록 Snaps를 출시했습니다. Ethereum도 이제 캡슐화 대 확장에 직면해 있습니다. 어려운 문제.

이 기사에서는 Web3 인프라의 캡슐화 대 확장의 설계 선택과 퍼블릭 체인 인프라 문제에 대한 개인적인 생각에 대해 논의할 것입니다.

이더리움은 어떤 문제에 직면해 있나요? 캡슐화 또는 확장

캡슐화 대 확장 문제에서 이더리움은 항상 확장을 선택했습니다.

Ethereum의 디자인 철학은 Unix에서 유래하여 애플리케이션 계층에서 개발자가 사용자 요구를 실현할 수 있도록 최소한의 범용 커널을 만듭니다. 이를 달성하기 위해 Ethereum을 지원하는 핵심 기술은 EVM입니다. Turing-complete 스마트 계약 언어를 통해 개발자는 애플리케이션 계층에서 애플리케이션을 맞춤 설정할 수 있습니다.

이 모델은 합리적으로 보이지만 분산형 Unix에서는 그다지 잘 작동하지 않습니다. 중요한 이유 중 하나는 EVM의 소위 Turing 완전성이 실제 사용에서는 그다지 완전하지 않다는 것입니다. 가스 메커니즘과 제한된 opcode 하에서는 프로그램이 작업을 완료하기 위해 제한된 단계에서 제한된 opcode를 사용해야 하므로 애플리케이션이 크게 제한되고 Unix의 사용자 계층에서 Web2 프로그램처럼 전능하기가 어렵습니다. 애플리케이션 높은 수준의 dApp에 필요한 기능은 EVM으로 충족될 수 없습니다. Rollup이든 AA 지갑이든 L1을 수정하지 않고도 원활하게 실행될 수 있지만 여전히 MVP 제품이며 효율성과 경험은 여전히 목표와 거리가 멀습니다.

개발자 앞의 선택은 EIP입니다. 이더리움 핵심 팀이 의존하는 중요한 기능을 하위 계층에 캡슐화하여 애플리케이션 계층에서 사용할 수 있도록 제공합니다.

EVM 기반 확장은 애플리케이션 개발 요구 사항을 충족할 수 없으며 이제 이를 캡슐화하는 방법을 신중하게 고려해야 합니다.

그러나 분산형 인프라가 상위 계층 응용 프로그램 기능을 캡슐화하는 것은 그렇게 간단하지 않으며 단지 코드 조각을 통합하는 것이 아닙니다. 그 이면에는 분산형 시스템의 가장 큰 문제인 거버넌스가 있습니다. 캡슐화는 개발 및 유지 관리 외에도 핵심 팀이 이러한 기능의 거버넌스도 책임져야 함을 의미합니다. 동시에 이더리움의 신뢰 모델을 약화시키고 지속 가능성에 잠재적으로 영향을 미칠 수 있는 문제를 야기할 위험이 있습니다. 개발.

따라서 최종 효과는 쉽게 볼 수 있습니다. 핵심 팀이 캡슐화할 수 있는 기능의 수는 제한되어 있습니다. 둘째, 이 기능의 중요성은 커뮤니티에서 널리 인식되어야 합니다. 마지막으로 구현 효율성은 그리 높지 않습니다. 높아서 몇년 걸릴듯..

동시에 이는 필요한 기능이 널리 인식되는 기본 기능이 아닌 경우 Ethereum이 결코 귀하를 수용하지 못할 수도 있음을 의미합니다. 심지어 노력하더라도 자체 애플리케이션 체인을 구축하고 높은 비용, 개발 및 운영 비용을 부담하고 스마트 계약 세계에서 결합성의 아름다움을 잃습니다.

캡슐화 대 확장 문제에 대해 이더리움은 아직 명확한 해결책을 갖고 있지 않습니다. 캡슐화를 순서대로 수행하는 방법은 Vitalik이 언급한 것입니다. 그들은 여전히 프레임워크, 캡슐화할 대상 기능을 결정하는 방법 및 이를 캡슐화하는 방법을 탐색하고 있습니다.

Unix에서 또 무엇을 배울 수 있나요? 네이티브 확장!

캡슐화 대 확장 문제에서 Ethereum은 주로 EVM의 확장 기능 부족을 보완하기 위해 캡슐화를 수행할 핵심 팀이 필요합니다. 다른 관점에서 생각해 보면, 애플리케이션 레이어의 확장성을 높이면 문제의 큰 부분을 해결할 수 있을까요? 예를 들어, 애플리케이션 개발자는 기본 팀이 캡슐화할 때까지 기다리지 않고 자신의 아이디어에 따라 애플리케이션에 필요한 기본 기능을 사용자 정의할 수 있습니다.

우리는 또한 이더리움이 Unix의 많은 디자인 철학을 흡수했다는 것을 알고 있으므로 계속해서 Unix 시스템에서 아이디어를 찾아보겠습니다.

Unix 기반의 상용 운영 체제인 이 운영 체제는 PC 시장을 지향하며 애플리케이션 계층에서 더욱 다양한 요구에 직면하고 있으며 기업 사용 시나리오의 확장 요구에도 직면하고 있습니다. 그러나 이러한 상용 운영 체제의 경우 핵심 팀은 캡슐화에 대한 부담이 크지 않으며 애플리케이션에 제공하는 확장성은 사용자가 대부분의 기능을 스스로 해결할 수 있을 만큼 충분히 높습니다.

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

그러나 Mac OS X에서는 응용프로그램 개발자가 독립적으로 프로그램을 커널 상태에 배포하여 Mac OS 없이도 커널 상태의 기능을 확장할 수 있습니다. Mac OS 기능이 제공하는 핵심 메커니즘입니다.

우리가 얻은 영감은 분산형 Unix에서 커널 확장 모델이 실현 가능한가입니다. 그 패턴은 아래 그림에 나와 있습니다.

블록체인 프로토콜은 스마트 계약을 지원하는 것 외에도 또 다른 프로그램인 Native Extension을 지원합니다.

1) 스마트 계약보다 더 많은 기본 프로토콜 API 액세스 권한을 가집니다.

2) 그리고 실행 환경 효율성은 EVM보다 훨씬 높습니다.

3) 그리고 기본 프로토콜로부터 격리되어 기본 프로토콜의 안정성에 영향을 미치지 않습니다.

4) 따라서 거버넌스 측면에서는 기본 팀에서 유지 관리할 필요가 없고 애플리케이션 팀에서 유지 관리하고 배포합니다.

이 모델이 기술적으로 위의 네 가지 사항을 충족할 수 있다면 많은 문제를 해결할 수 있는 것 같습니다. 애플리케이션 개발자는 기본 팀이 캡슐화할 때까지 기다리지 않고 자신의 아이디어에 따라 애플리케이션에 필요한 기본 기능을 사용자 정의할 수 있습니다.

이 패러다임을 당분간 Native Extension 패러다임으로 요약하고, 기존 Web3 인프라에 그림자가 있는지 살펴보겠습니다.

Hook, Hook, Hooks…

소프트웨어 세계에서는 훌륭한 시나리오에 의해 훌륭한 바퀴가 만들어지는 경우가 많습니다. DeFi 인프라로서 Uniswap은 플랫폼이 되는 중요한 단계에 있으며 캡슐화 대 확장 특성인 Hook에 대한 놀라운 설계를 갖추고 있습니다. 이를 통해 개발자는 핵심 팀이 캡슐화를 통해 지속적으로 기능을 업그레이드할 필요 없이 기능적으로 다양한 풀 경험을 달성하기 위해 Hooks를 사용하여 권한 없이 풀에 확장을 추가할 수 있습니다.

Hook의 메커니즘은 위에서 언급한 Native Extension의 다중 조건과 유사합니다.

· 후크는 풀의 실행 수명 주기를 중단하고 런타임 데이터에 액세스할 수 있습니다. 이는 보다 고급 액세스 수준입니다.

· Hook과 Pool은 서로 독립적인 계약이며 Hook의 보안은 Pool에 영향을 미치지 않습니다.

· 거버넌스 측면에서 Hooks는 제3자 개발자가 허가 없이 개발 및 배포하며 전역적으로 활성화되지 않으며, 대신 사용자 정의 기능을 활성화하기 위해 필요에 따라 서로 다른 풀이 서로 다른 Hook을 바인딩합니다.

Hook는 풀의 확장성 문제를 해결한 작지만 아름다운 디자인입니다. 애플리케이션 계층 인프라는 이러한 개념을 적용하는 데 앞장섰습니다. 계속해서 더 복잡한 기본 프로토콜(L1/L2)의 아이디어를 살펴보겠습니다.

새로운 퍼블릭 체인 프로젝트의 확장 아이디어

이더리움이 곤경에 처해 있습니다. 레이어 1 확장에 전념하는 레이어 2 프로젝트의 아이디어를 살펴보겠습니다.

Arbitrum Stylus를 사용하면 애플리케이션 개발자가 미리 컴파일된 계약을 직접 패키징할 수 있습니다!

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

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

이는 이더리움의 캡슐화 문제를 최적화할 수 있는 구현 중 하나입니다. EVM의 확장 요구 사항은 더 이상 하위 팀이 캡슐화할 때까지 기다리지 않습니다. 하위 팀은 실행 계층 확장 환경의 유지 관리에 중점을 두는 반면, 도입은 새로운 기능의 개발과 거버넌스가 교환되며, 애플리케이션 계층에서 개발됩니다.

그러나 Stylus는 아직 초기 단계입니다. 이 모델의 더 많은 과제는 아직 노출되지 않았으며 해결할 수 있는 문제도 제한적입니다. 현재는 사전 컴파일된 계약의 동적 패키징만 지원하며 이더리움도 사전 컴파일된 계약 외에 더 많은 패키징 문제에 직면해 있습니다. 계약. 그러나 다행스럽게도 이는 Native Extension 패러다임에 가까운 구현 중 하나입니다. 차세대 인프라의 대표자로서 향후 생태계가 직면하게 될 캡슐화 문제를 해결하기 위한 확장성 설계를 도입합니다. 규모.” 문제는 장기적인 생태 발전을 고려합니다.

기본 확장: 모듈식 캡슐화 아이디어!

Web2 및 Web3와 같은 인프라 프로젝트를 조사한 후 캡슐화 대 확장이라는 질문을 되돌아보면 명확한 아이디어를 볼 수 있습니다. 즉, 확장 기능을 개선함으로써 개발자는 모듈식 방법을 사용하여 원하는 기능을 캡슐화할 수 있습니다.

이것이 인프라에서 Native Extension 패러다임이 하는 중요한 역할인데, 인프라의 확장성을 향상시켜 선택권을 개발자에게 돌려주므로 개발자는 핵심 프로토콜의 안정성에 영향을 주지 않고 자유롭게 사용할 수 있습니다. 원하는 기능을 확장합니다.

Ethereum은 캡슐화의 효율성을 향상시키려고 노력하고 있으며 Arbitrum Stylus는 사전 컴파일된 계약을 해방시키고 있습니다. 더 나아가서 퍼블릭 체인은 Uniswap V4가 제공하는 것과 마찬가지로 Native Extension 패러다임을 통해 애플리케이션 계층의 창의성을 완전히 해방시킬 수도 있습니다. 모두에게 그렇게 느껴보세요.

Native Extension 패러다임을 기반으로 한 새로운 L1 퍼블릭 체인: Artela

여기서 관점을 바꿔 보겠습니다. 우리는 제가 CTO로 일하는 팀인 Artela를 말합니다. 이 문제에 대한 우리의 생각과 행동을 공유해 봅시다.

Artela 블록체인에서는 EVM 외에도 WASM 실행 환경도 설치했습니다. 한편으로는 미리 컴파일된 상태 저장 계약과 유사한 상태 저장 프로그램을 실행할 수 있고, 다른 한편으로는 후크와 같은 메커니즘을 지원하여 블록 및 트랜잭션 처리의 여러 수명 주기 노드에서 트리거될 수 있습니다. 즉, Arbitrum Stylus와 같이 사전 컴파일된 계약을 캡슐화하는 데 사용될 뿐만 아니라 트랜잭션 및 블록의 실행 프로세스를 사용자 정의하여 더 넓은 기능 캡슐화를 달성할 수도 있습니다. 예를 들어 WASM의 기본 확장은 트랜잭션 확인 단계에서 트리거되며 새로운 알고리즘을 사용하여 트랜잭션을 식별하고 확인합니다. Artela에서는 이러한 Hook을 Join Point라고 하며 이러한 Native Extension은 Smart Contract가 아닌 Aspect라고 하며 AoP(Aspect-Oriented 프로그래밍)의 개념과 유사하며 실행 중인 블록체인 시스템에서 동적으로 새로운 기능이 추가됩니다. 포인트에 합류하세요!

구체적인 예를 들자면, 대규모 자산을 Web3로 가져오는 데 가장 큰 장애물이 무엇인지 알아보기 위해 투자자 및 Web2 기관과 소통해보았는데, 가장 많이 논의되는 문제는 보안입니다! Web2 수준의 위험 제어 기술은 수십억 자산의 보안을 보장하지만 Web3 기술 스택에 진입하는 것은 어렵습니다. NASA의 항공우주 분야 출신인 Carl도 런타임 보호 및 측면이 필요한 이유에 대해 동일한 견해를 표명했습니다.

Runtime Protection은 보안 위험 통제의 핵심 방법입니다. 오늘날의 Web3에서는 매우 강력한 보안 회사 그룹이 정적 감사와 공식 검증, 실시간 모니터링 및 선행 트랜잭션을 모두 갖추고 있음을 알 수 있습니다. 그러나 여전히 Web2 수준의 실시간 위험 제어와는 거리가 멀습니다. 핵심 근본 문제는 트랜잭션이 Mempool을 통과하면 할 수 있는 것이 없기 때문에 mempool 주변에 보안 방법이 너무 많다는 것입니다. Mempool 이후 트랜잭션 실행 단계에서 확장 기능이 있고 보안 전문가가 런타임 수준의 보안 정책을 배포할 수 있으면 보안 수준이 더 높은 수준으로 높아집니다. Aspect는 개발자에게 실행 계층에 깊이 들어가는 보안 확장 기능을 제공합니다!

개발자는 자신의 프로젝트에만 서비스를 제공하는 측면을 배포하여 원하는 프로토콜 계층 기능을 사용자 지정할 수 있습니다. 예를 들어, 런타임 보안을 강화하기 위해 트랜잭션이 잠재적으로 대량의 자금 도난으로 이어질 경우 Aspect에서 차단됩니다.

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

Artela에 관해 우리의 생각은 그 과정에서 점점 더 확고해졌습니다.

· 기본 퍼블릭 체인 팀이 이를 캡슐화할 때까지 기다리지 않고 개발자가 애플리케이션 상태에서 Native Extension을 통해 허가 없이 문제를 해결할 수 있도록 허용합니다.

· Web2 배경을 가진 대규모 기관이 감히 블록체인에 막대한 자금을 투입할 수 있도록 함(Web2 수준의 런타임 위험 제어 도입으로 강화)

· 개발자가 순환을 깨는 작업을 수행할 수 있는 좋은 생태학적 환경을 가질 수 있도록 허용합니다(EVM은 곧 한계점에 도달할 수 있으며 EVM+Native Extension은 더 많은 잠재력을 가질 수 있음).

· 더 많은 비즈니스 로직을 체인으로 이동하려는 풀체인 게임, RWA 및 기타 dApp에 이상적인 홈을 제공합니다.

우리는 이더리움이 애플리케이션 기능을 캡슐화하는 단계에 있으며 캡슐화 압력을 해제하고 창의력을 다시 개발자의 손에 돌려줄 계획이 없다는 것을 알 수 있습니다. 탈중앙화 애플리케이션에서 획기적인 혁신을 탐구할 만큼 용감한 잠재적인 차세대 혁신가 그룹에게 이러한 상황은 매우 제한적입니다. 한편으로는 강력한 탈중앙화 네트워크가 필요하지만 다른 한편으로는 자신의 네트워크를 사용할 수 없습니다. 손과 발. 이것이 바로 인프라가 혁신의 속도에 저항하지 않도록 Native Extension 패러다임을 기반으로 새로운 L1 퍼블릭 체인을 구축하는 데 전념하는 핵심 이유입니다.