Radix 엔진: "Enshrinement"를 위한 더 나은 모델

내 이전 기사 , Radix Engine이 Sui MoveVM의 일부 결함을 어떻게 방지했는지 살펴보았습니다. 요약:

• Sui의 MoveVM은 너무 낮은 수준이고 일반적이어서 번거로운 DeFi 프로그래밍 환경을 만듭니다.
• Radix 엔진은 높은 수준의 자산 + 비즈니스 로직 지향적이므로 개발자는 낮은 수준의 세부 사항보다는 DeFi 로직에 집중할 수 있습니다.

Sui의 MoveVM은 원본을 따릅니다. 이더리움 철학 모든 것을 애플리케이션 계층에 위임하는 "깨끗하고 단순하며 아름다운" 프로토콜입니다. 이를 통해 개발자는 당시 알려지지 않은 도메인을 포함하여 모든 도메인을 자유롭게 탐색할 수 있습니다.

하지만 너무 단순하고 구조화되지 않은 프로토콜은 심각한 손상을 초래합니다. 예를 들어 인증과 같은 일반적인 시스템 기능은 애플리케이션 공간에서 복잡한 구현을 요구하고 표준 인터페이스는 더욱 단편화될 수 있으며 성능 최적화는 더욱 어려워집니다.

반면에 Radix 엔진은 다음을 수행할 수 있도록 하기 때문에 비일반 시스템 전체 로직을 핵심 기술 목표로 실행하도록 설계되었습니다.

• 시스템 전반에 걸친 표준/구현을 시행합니다 . API가 단편화되지 않고(예: ERC-20 대 ERC-721 대 ERC-404) 동작을 이해하는 데 바이트코드 해석이 필요하지 않기 때문에 독선적인 표준을 사용하면 스택 전체에서 개발/유지 관리/도구 사용이 더 쉬워집니다. ERC-20 러그 풀). 이를 통해 개발자와 최종 사용자에게 더욱 안전하고 일관된 DeFi 경험을 제공합니다.
• 하드웨어에 더 가까운 로직을 실행합니다 . 시스템 로직은 정확성을 위해 인터프리터에 의해 실행될 필요가 없으므로 해당 로직의 실행은 가능한 한 하드웨어에 가깝게 실행될 수 있습니다.
• 실행을 병렬화합니다. 특정 개체의 동작에 대한 직접적인 지식을 가지면 실행 전에 정적 분석 결정을 내리기가 더 쉬워지고 병렬 실행이 가능해집니다.

Vitalik은 최근 "라는 용어로 이 아이디어를 언급했습니다. 안치 ” 또는 프로토콜 적용 논리의 이점을 얻기 위해 선택적으로 추상화에서 벗어나는 아이디어입니다. 그는 자신의 이미지 중 하나를 훔쳐 문제를 추상화와 성치 사이의 균형으로 구성합니다.

성능/보안/유용성(예: 암호화)을 유지하면서 추상화(예: 미래/다양한 사용자 요구) 지원의 균형은 실제로 매우 오래된 컴퓨터 과학 문제입니다. 특히 운영 체제 설계는 지난 수십 년 동안 유사한 문제를 해결하려고 노력해 왔습니다. 빠르고 안전하며 사용 가능한 시스템을 유지하면서 다양한 추상 애플리케이션을 어떻게 지원합니까?

이 기사에서는 Radix Engine이 운영 체제 모델을 사용하여 Vitalik이 두려워하는 프로토콜 복잡성이나 유연성 손실에 대한 부담 없이 모든 유형의 "수립"이 가능한 프레임워크를 생성하는 방법을 살펴보겠습니다.

현재 업계 표준인 Ethereum Virtual Machine(“EVM”)을 살펴보는 것부터 시작하겠습니다.

VM으로서의 EVM

EVM은 다음 opcode를 사용하여 가상 머신("VM")으로 모델링할 수 있을 만큼 충분히 기본적입니다.

• 튜링 완전 연산 코드 세트
• 다른 스마트 계약 호출을 위한 Opcode
• 현재 스마트 계약이 소유한 영구 저장소에 대한 읽기/쓰기를 위한 Opcode

그런 다음 EVM 바이트코드로 컴파일된 스마트 계약을 해당 VM 위에서 실행할 수 있습니다.

이 모델에서는 모든 형태의 "안치"를 위해서는 EVM 또는 VM 하드웨어를 변경해야 합니다. 예를 들어 BLS 서명 지원을 보호하려면 새 사전 컴파일을 추가해야 합니다. 구현 EIP-2938 새로운 opcode를 추가해야 합니다. 내재된 것을 확장하면 필연적으로 VM이 더 크고 복잡해지며 프로토콜 설계자는 Vitalik이 설명하는 둘 중 하나의 결정을 내리게 됩니다.

이 모델의 일반적인 문제는 추상화/계속 이분법이 소프트웨어/하드웨어 이분법과 너무 결합되어 있다는 것입니다. 즉, 모든 로직을 프로토콜에 포함시키면 해당 로직이 VM에 내장됩니다. "내재된 소프트웨어"나 시스템의 일부인 소프트웨어를 표현할 방법은 없습니다.

운영 체제는 "시스템 소프트웨어"라는 개념으로 이러한 이분법을 해결했습니다. 좀 더 자세히 살펴보겠습니다.

운영 체제 모델

운영 체제의 주요 목표 중 하나는 소프트웨어/하드웨어 이분법, 더 구체적으로 말하면 애플리케이션/하드웨어 이분법을 관리하는 것입니다. 모든 운영 체제의 핵심 부분은 사용자 공간 응용 프로그램과 하드웨어에 대한 액세스를 관리하는 소프트웨어인 커널입니다. 커널 모듈 및 드라이버는 지원되는 하드웨어 세트를 확장하거나 커널 기능을 확장하는 추가 시스템 소프트웨어입니다.

\"안치" 관점에서 볼 때 커널과 해당 모듈은 시스템의 일부로 안치되지만 소프트웨어의 유연성을 갖습니다. 커널 모듈, 가상 머신("VM") 및 사용자 공간 시스템 프로세스는 커널 자체에서 추상화되므로 훨씬 더 "소프트"합니다.

이 모델에서는 애플리케이션과 하드웨어 간의 간접 계층을 통해 소프트웨어/하드웨어 이분법을 추상화/수신 이분법에서 분리할 수 있습니다. "시스템 소프트웨어"는 하드웨어에 과도한 부담을 주지 않고 탑재할 수 있습니다.

운영 체제로서의 Radix 엔진

이 운영 체제 모델을 영감으로 사용하여 Radix 엔진에는 각각 특정 책임과 추상화가 있는 여러 계층이 포함되어 시스템 모듈성과 플러그성을 허용합니다.

이러한 모듈식 설계를 통해 시스템 논리를 적용하는 동시에 다음을 허용할 수 있습니다.

• 해당 레이어의 격리 속성을 상속합니다 . 예를 들어, enshrined 패키지는 enshrined이지만 임의의 상태에 액세스할 수 없으며 애플리케이션 계층 경계를 따라야 합니다. 이는 사용자 공간 드라이버나 마이크로커널 디자인에서 볼 수 있는 유사한 유형의 보안입니다. 즉, 시스템의 업데이트(수립)로 인해 전체 시스템이 위험에 노출되지 않도록 시스템의 각 부분을 격리하여 위험을 완화합니다.
• 해당 레이어의 기능에 액세스하세요. 예를 들어, 포함된 패키지는 시스템에서 제공하는 인증 및/또는 업그레이드 가능성 기능을 상속할 수 있습니다.
• 거버넌스를 분리합니다. 이 모듈식 설계를 통해 각 모듈의 혁신이 동시에 서로 다른 속도로 발생할 수 있습니다.

이제 각 계층을 살펴보고 해당 계층의 책임이 무엇인지 살펴보겠습니다.

애플리케이션 계층

애플리케이션 계층은 상위 수준 논리를 정의하는 역할을 담당합니다. 이 논리를 설명하는 바이트코드는 기타 정적 정보와 함께 패키지라는 실행 가능한 형식으로 묶입니다. 그런 다음 패키지는 원장에 저장되어 실행할 수 있습니다.

DeFi 개발을 위해 구축한 Rust 기반 언어인 Scrypto로 작성된 애플리케이션이 이 계층에 있습니다. Scrypto 프로그램은 프로그램이 시스템/커널 서비스에 액세스할 수 있도록 하는 일련의 함수 내보내기에 액세스하여 WASM 프로그램으로 컴파일됩니다. 이것 시스템 호출 API 리눅스와 비슷하다 시스템 호출 , 공유 I/O에 대한 액세스를 제공합니다.

VM 계층

다음 계층으로 이동하면 VM 계층은 애플리케이션 계층에 컴퓨팅 환경을 제공하는 역할을 담당합니다. 여기에는 Turing-complete VM과 시스템 계층에 액세스하기 위한 인터페이스가 포함됩니다.

Radix Engine은 현재 Scrypto 애플리케이션을 실행하는 데 사용되는 Scrypto WASM VM과 호스트 환경에 컴파일된 기본 패키지를 실행하는 기본 VM이라는 두 가지 VM을 지원합니다.

Scrypto WASM VM을 구체적으로 살펴보면 다음과 같습니다.

이는 본질적으로 EVM 모델과 동일해 보이지만 두 가지 중요한 차이점이 있습니다.

• 스토리지에 대한 직접 액세스를 제거합니다. 각 스마트 계약이 자신이 소유한 저장소에만 액세스할 수 있는 대신 모든 상태 읽기/쓰기가 시스템 호출을 통해 수행됩니다. 이 간접 계층을 사용하면 애플리케이션 간 상태 공유, 상태 가상화 등과 같은 많은 흥미로운 작업을 시스템에서 구현할 수 있습니다. 이 간접 계층은 다음에서 제공하는 간접 참조와 유사합니다. 가상 메모리 아니면 리눅스의 파일 설명자 .

  
  

• 시스템 호출 추가 . 시스템 호출은 애플리케이션 계층이 다른 애플리케이션을 호출하거나 객체에 데이터를 쓰는 등 시스템 계층의 서비스에 액세스할 수 있는 메커니즘입니다. 이러한 시스템 호출은 실제 CPU의 소프트웨어 인터럽트 명령과 유사합니다(예: 정수 x86의 명령).

시스템 계층

시스템 계층은 시스템 기능을 확장할 수 있는 시스템 모듈 또는 플러그형 소프트웨어 세트를 유지 관리하는 역할을 담당합니다. 이는 Linux와 유사합니다. 커널 모듈 .

모든 시스템 호출에서 각 시스템 모듈은 시스템 계층이 제어권을 커널 계층으로 전달하기 전에 호출됩니다. 호출되면 각 시스템 모듈은 일부 특정 상태(예: 업데이트 비용 지출)를 업데이트하거나 패닉 상태에 빠져 트랜잭션을 종료할 수 있습니다(예: 유형 검사기가 실패하는 경우).

이 패턴을 사용하면 시스템은 애플리케이션 및 커널 계층 모두에서 분리되는 동시에 권한 부여, 로열티 또는 유형 검사와 같은 기능을 구현할 수 있습니다.

커널 레이어

커널 계층은 Radix Engine의 두 가지 핵심 기능인 스토리지 액세스와 애플리케이션 간 통신을 담당합니다. 이는 디스크 및 네트워크 액세스에 대한 기존 운영 체제의 책임과 다소 유사합니다.

Radix Engine의 경우 여기에는 다음과 같은 하위 수준 관리가 포함됩니다.

• 모든 호출이나 데이터 쓰기 시 이동/대여 의미 체계가 유지되는지 확인하세요. 단일 소유자 규칙과 차용 규칙은 커널에 의해 시행됩니다. 이러한 규칙 중 하나라도 실패하면 트랜잭션이 패닉 상태가 됩니다.
• 임시 개체와 영구 개체를 관리합니다. 객체는 어느 시점에서든 전역 공간에 있을 수도 있고 호출 프레임이 소유할 수도 있습니다. 커널은 이러한 개체에 대한 참조가 전달되므로 런타임 중에 이러한 개체에 대한 올바른 포인터를 유지합니다.
• 트랜잭션 상태 업데이트를 관리합니다. 커널은 트랜잭션 중에 발생하고 이후 트랜잭션이 끝날 때 데이터베이스에 커밋될 상태 업데이트를 추적합니다.

안치된 소프트웨어

이러한 레이어는 DLT 프로토콜의 enshrinement와 어떤 관련이 있습니까? 운영 체제의 커널 계층과 유사하게 Radix 엔진의 이러한 중간 계층은 추상화/포함 이분법을 소프트웨어/하드웨어 이분법에서 분리하고 "포함된 소프트웨어"라는 개념을 생성하는 데 필요한 간접적인 기능을 제공합니다.

Enshrined 소프트웨어는 시스템 전체의 논리를 적용하는 기능을 유지하면서 소프트웨어의 유연성과 보안 속성을 갖습니다.

현재 Radix 네트워크에서 실행되고 있는 몇 가지 안치 사례를 살펴보고 어떻게 구현되는지 살펴보겠습니다.

안치된 자원

Radix DeFi/Web3 플랫폼의 핵심 차별화 요소는 리소스(예: 자산)가 비즈니스 로직과 별도로 이해되어야 하는 기본 요소라는 아이디어입니다. 이 개념을 적용하면 모든 dApp, 지갑 및 도구가 자산의 인터페이스 및 동작이 어떻게 생겼는지에 대한 공통된 이해를 가질 수 있어 구성성이 훨씬 쉬워집니다.

리소스는 시스템의 가장 뿌리깊은 부분 중 하나이지만 이를 구현하려면 다음 두 가지 모듈식 소프트웨어만 필요합니다.

• Buckets, Vault, Proof와 같은 리소스 개체의 논리를 처리하는 기본 패키지

• 이러한 개체의 수명 불변성(예: 리소스의 이동성 및 연소성)을 적용하는 시스템 모듈

  
  

Radix 엔진이 시스템/커널에서 추상화되면서 표준화되고 이동 가능한 리소스라는 깊은 개념을 표현할 수 있다는 사실은 모듈식 시스템 소프트웨어 프레임워크의 강력함을 보여줍니다.

명시된 승인 및 로열티

Radix Engine은 이 논리를 비즈니스 논리에서 분리하고 이를 시스템 기능으로 구현하여 승인 및 로열티를 표준화합니다. 이를 통해 사용자와 개발자는 원장의 모든 기능에 액세스하기 위한 요구 사항을 이해할 수 있는 내장된 공통 방법을 가질 수 있습니다.

시스템 로직에서 비즈니스 로직을 분리하는 모듈성은 일반적인 인증 확인 없이 거래를 미리 볼 수 있는 기능과 같은 편리한 개발/디버깅 옵션도 허용합니다. (1,000만 USDC를 어딘가로 보낸 결과를 시뮬레이션하고 싶으십니까? 인증이 비활성화되면 미리 보기 거래가 가능해집니다.) 주조를 하세요!).

인증 및 로열티를 보호하려면 네 가지 모듈식 소프트웨어가 필요합니다.

• 애플리케이션 계층이 모든 객체의 인증/ 로열티에 액세스할 수 있도록 허용하는 인증 및 로열티 네이티브 패키지(예: 메소드에 액세스하거나 로열티를 청구하기 위한 인증 규칙 검색)

• 인증 및 로열티 시스템 모듈은 호출자가 호출을 하고 로열티를 징수할 수 있는 충분한 권한이 있는지 확인하기 위해 개체 메서드 호출 전에 호출됩니다.

  
  

  
  

안치된 거래

사용자와 시스템 간의 올바른 인터페이스는 모든 시스템을 사용하는 데 가장 중요합니다. 인터페이스를 사용할 수 있으려면 사용 편의성과 성능/유연성 사이에서 적절한 균형을 찾아야 합니다.

운영 체제 세계에서 가장 일반적인 인터페이스는 사용자에게 다양한 시스템 호출을 호출하고 구성할 수 있는 명령줄 도구를 제공하는 사용자 공간 프로세스인 터미널입니다.

DLT 세계에서는 이 인터페이스가 트랜잭션입니다. 트랜잭션에 대한 업계 표준은 단일 하위 수준의 일반 호출 호출을 사용하는 것입니다. 불행하게도 이는 시스템과 상호작용할 때 실제로 무엇을 하는지 이해하기 어렵게 한다는 점에서 너무 단순합니다.

반면 Radix Engine은 기존 OS 패턴을 사용하고 애플리케이션 언어(bash와 같은 터미널 스크립팅 언어와 유사)를 포함하여 단일 트랜잭션에서 시스템 호출을 호출하고 구성합니다.

트랜잭션의 진입점은 애플리케이션 계층에서 작동하므로 언어 해석기는 트랜잭션 프로세서 네이티브 패키지를 추가하여 구현됩니다.

안치된 BLS

BLS 서명은 임계값 서명의 가능성을 허용하므로 중요한 암호화 기본 요소입니다. 안타깝게도 WASM에서 이러한 논리를 실행하면 최대 비용 단위가 빠르게 소모됩니다. 최근 “Anemone” 업데이트에서는 BLS를 기본적으로 실행하여 안치했으며 WASM과 비교했을 때 성능이 500배 향상되는 것을 확인했습니다.

BLS 논리는 상태 비저장이므로 Scrypto WASM VM에 추가 사전 컴파일로 쉽게 추가할 수 있습니다.

결론

무엇을 담고, 무엇을 담지 않을지는 모든 DLT 프로토콜에 중요합니다. 불행하게도 업계의 기존 VM 모델은 모든 안치 결정을 매우 위험한 결정으로 만듭니다.

운영 체제 모델에서 영감을 얻은 Radix 엔진은 "소프트웨어"와 "하드웨어" 사이에 간접 계층을 추가하여 이 문제를 해결합니다. 이를 통해 Radix 엔진은 "내장된 소프트웨어"라는 개념을 표현할 수 있으며, 프로토콜이 고위험 타협 결정을 내리지 않고도 새로운 내장된 시스템을 쉽게 추가, 수정 및 표현할 수 있습니다.

원래 운영 체제는 여러 응용 프로그램의 공유 리소스를 관리하도록 설계된 작은 소프트웨어로 만들어졌습니다. 더 좋고, 더 빠르고, 더 안전한 플랫폼에 대한 사용자의 요구가 커짐에 따라 플랫폼은 점점 더 큰 소프트웨어 제품군에 대한 책임을 점점 더 많이 떠맡게 되었습니다.

DeFi도 다르지 않습니다. 더 빠르고, 더 안전하고, 더 사용하기 쉬운 DeFi 플랫폼에 대한 수요가 증가함에 따라 더 많은 수용이 뒤따를 것입니다. Radix Engine은 이를 염두에 두고 설계되었으며 향후 안치 확장에 필요한 확장 가능하고 안전한 프레임워크를 제공합니다.