Radix Engine: Một mô hình tốt hơn cho “Bảo quản

trong tôi bài báo trước , Tôi đã tìm hiểu cách Radix Engine tránh một số sai sót trong MoveVM của Sui. Để tóm tắt:

• MoveVM của Sui quá cấp thấp và chung chung, tạo nên một môi trường lập trình DeFi cồng kềnh.
• Radix Engine có định hướng cấp cao và tài sản + kinh doanh, cho phép các nhà phát triển tập trung vào logic DeFi thay vì các chi tiết cấp thấp.

MoveVM của Sui tuân theo bản gốc Triết lý Ethereum về một giao thức “sạch, đơn giản, đẹp mắt”, ủy quyền mọi thứ cho lớp ứng dụng. Điều này cho phép các nhà phát triển tự do khám phá bất kỳ miền nào, kể cả những miền chưa biết vào thời điểm đó.

Tuy nhiên, một giao thức quá đơn giản và không có cấu trúc sẽ tạo ra những tổn hại đáng kể. Ví dụ: các tính năng phổ biến của hệ thống như ủy quyền sẽ yêu cầu triển khai phức tạp trong không gian ứng dụng, các giao diện tiêu chuẩn có thể trở nên phân mảnh hơn và việc tối ưu hóa hiệu suất trở nên khó khăn hơn.

Mặt khác, Radix Engine được thiết kế để thực thi logic không chung chung, trên toàn hệ thống như một mục tiêu kỹ thuật cốt lõi, vì nó cho phép chúng tôi thực hiện những điều sau:

• Thực thi các tiêu chuẩn/triển khai trên toàn hệ thống . Một tiêu chuẩn có ý kiến cho phép việc phát triển/bảo trì/công cụ trở nên dễ dàng hơn trong toàn bộ ngăn xếp vì các API không bị phân mảnh (ví dụ: ERC-20 so với ERC-721 so với ERC-404) và việc hiểu hành vi không yêu cầu diễn giải mã byte (không còn nữa) Kéo thảm ERC-20). Điều này mang lại cho các nhà phát triển và người dùng cuối trải nghiệm DeFi an toàn hơn, nhất quán hơn.
• Thực thi logic gần hơn với phần cứng . Vì logic hệ thống không cần phải được chạy bởi trình thông dịch để đảm bảo tính chính xác nên việc thực thi logic đó có thể được chạy gần với phần cứng nhất có thể.
• Thực hiện song song. Bằng cách có sẵn kiến thức về hành vi của một số đối tượng nhất định, việc đưa ra quyết định phân tích tĩnh trước khi thực hiện sẽ dễ dàng hơn, cho phép thực hiện song song.

Vitalik gần đây đã đề cập đến ý tưởng này bằng thuật ngữ “ sự cất giữ ”, hoặc ý tưởng thoát khỏi sự trừu tượng một cách có chọn lọc để đạt được những lợi ích của logic được thực thi theo giao thức. Đánh cắp một trong những hình ảnh của anh ấy, anh ấy coi vấn đề là sự cân bằng giữa sự trừu tượng và sự cất giữ:

Sự cân bằng giữa việc hỗ trợ tính trừu tượng (tức là nhu cầu trong tương lai/nhu cầu đa dạng của người dùng) trong khi vẫn duy trì hiệu suất/bảo mật/khả năng sử dụng (tức là lưu trữ) thực sự là một vấn đề khoa học máy tính rất cũ. Đặc biệt, thiết kế của Hệ điều hành đã cố gắng giải quyết một vấn đề tương tự trong nhiều thập kỷ qua: Làm cách nào để chúng tôi hỗ trợ một loạt các ứng dụng trừu tượng trong khi vẫn duy trì một hệ thống nhanh, an toàn, có thể sử dụng được?

Trong bài viết này, tôi sẽ tìm hiểu cách Radix Engine sử dụng mô hình Hệ điều hành để tạo ra một khung có khả năng đáp ứng tất cả các loại “lưu trữ” mà không phải chịu tải về độ phức tạp của giao thức hoặc mất tính linh hoạt mà Vitalik lo ngại.

Hãy bắt đầu bằng cách xem xét tiêu chuẩn ngành hiện tại, Máy ảo Ethereum (“EVM”).

EVM dưới dạng VM

EVM đủ cơ bản để có thể được mô hình hóa như một máy ảo (“VM”) với các mã hoạt động sau:

• Bộ opcode hoàn chỉnh Turing
• Opcodes cho các cuộc gọi đến các hợp đồng thông minh khác
• Opcodes để đọc/ghi vào bộ lưu trữ liên tục thuộc sở hữu của hợp đồng thông minh hiện tại

Sau đó, các hợp đồng thông minh được biên dịch thành mã byte EVM có thể được thực thi trên máy ảo đó.

Trong mô hình này, bất kỳ hình thức “lưu trữ” nào cũng yêu cầu thay đổi phần cứng EVM hoặc VM. Ví dụ: việc lưu giữ hỗ trợ chữ ký BLS sẽ yêu cầu thêm một bản biên dịch trước mới. Thực thi EIP-2938 sẽ yêu cầu bổ sung các opcode mới. Việc mở rộng những gì được lưu giữ chắc chắn sẽ dẫn đến một VM lớn hơn, phức tạp hơn và buộc người thiết kế giao thức phải đưa ra quyết định này hay quyết định khác mà Vitalik mô tả.

Vấn đề chung với mô hình này là sự phân đôi Trừu tượng/Lưu trữ quá gắn liền với sự phân đôi Phần mềm/Phần cứng. Nghĩa là, việc đưa bất kỳ logic nào vào giao thức buộc nó phải được nhúng vào VM. Không có cách nào để diễn tả “phần mềm được lưu giữ” hoặc phần mềm là một phần của hệ thống.

Hệ điều hành đã giải quyết sự phân đôi này bằng khái niệm “phần mềm hệ thống”. Chúng ta hãy xem xét kỹ hơn.

Mô hình hệ điều hành

Một trong những mục tiêu chính của Hệ điều hành là quản lý sự phân đôi phần mềm/phần cứng - hay cụ thể hơn là sự phân đôi ứng dụng/phần cứng. Phần cốt lõi của bất kỳ Hệ điều hành nào là kernel, phần mềm quản lý các ứng dụng trong không gian người dùng và quyền truy cập của chúng vào phần cứng. Các mô-đun và trình điều khiển hạt nhân là các phần mềm hệ thống bổ sung giúp mở rộng bộ phần cứng được hỗ trợ hoặc mở rộng chức năng hạt nhân.

\Từ góc độ "bảo quản", hạt nhân và các mô-đun của nó là các bộ phận được lưu giữ trong hệ thống nhưng có tính linh hoạt của phần mềm. Các mô-đun hạt nhân, máy ảo (“VM”) và các quy trình hệ thống trong không gian người dùng thậm chí còn “mềm” hơn vì chúng được trừu tượng hóa từ chính hạt nhân.

Trong mô hình này, lớp gián tiếp giữa các ứng dụng và phần cứng cho phép tách rời sự phân đôi phần mềm/phần cứng khỏi sự phân đôi trừu tượng/lưu trữ. “Phần mềm hệ thống” cho phép lưu trữ mà không làm phần cứng bị quá tải.

Radix Engine như một hệ điều hành

Sử dụng mô hình hệ điều hành này làm nguồn cảm hứng, Radix Engine bao gồm nhiều lớp, mỗi lớp có trách nhiệm và tính trừu tượng cụ thể, cho phép hệ thống có tính mô-đun và khả năng cắm.

Thiết kế mô-đun như vậy cho phép thực thi logic hệ thống đồng thời cho phép những điều sau:

• Kế thừa các thuộc tính cách ly của lớp chứa nó . Ví dụ: một gói được lưu trữ, mặc dù được lưu trữ, không thể truy cập trạng thái tùy ý mà phải tuân theo giới hạn lớp ứng dụng. Đây là loại bảo mật tương tự được thấy trong trình điều khiển không gian người dùng hoặc thiết kế vi nhân. Nghĩa là, rủi ro được giảm thiểu bằng cách cách ly từng bộ phận của hệ thống để mọi cập nhật trong hệ thống (bảo vệ) không khiến toàn bộ hệ thống gặp rủi ro.
• Truy cập các tính năng của lớp chứa nó. Ví dụ: một gói được lưu trữ có thể kế thừa các tính năng xác thực và/hoặc khả năng nâng cấp do hệ thống cung cấp.
• Quản lý tách rời. Thiết kế mô-đun này cho phép sự đổi mới trong từng mô-đun này diễn ra song song và ở các bước khác nhau.

Bây giờ chúng ta hãy đi qua từng lớp này và xem trách nhiệm của chúng là gì.

Lớp ứng dụng

Lớp ứng dụng chịu trách nhiệm xác định logic cấp cao. Mã byte mô tả logic này, cùng với thông tin tĩnh khác, được gói lại ở định dạng thực thi được gọi là Gói. Các gói sau đó được lưu trữ trên sổ cái và có sẵn để thực hiện.

Các ứng dụng được viết bằng Scrypto, ngôn ngữ dựa trên Rust mà chúng tôi đã xây dựng để phát triển DeFi, nằm trong lớp này. Các chương trình Scrypto được biên dịch thành các chương trình WASM với quyền truy cập vào một tập hợp xuất hàm cho phép chương trình truy cập các dịch vụ hệ thống/hạt nhân. Cái này API cuộc gọi hệ thống tương tự như Linux cuộc gọi hệ thống , cung cấp quyền truy cập vào I/O được chia sẻ.

Lớp VM

Chuyển sang lớp tiếp theo, lớp VM chịu trách nhiệm cung cấp môi trường tính toán cho lớp ứng dụng. Điều này bao gồm một máy ảo hoàn chỉnh Turing cũng như giao diện để truy cập lớp hệ thống.

Radix Engine hiện hỗ trợ hai máy ảo: một máy ảo WASM Scrypto được sử dụng để thực thi các ứng dụng Scrypto và một máy ảo gốc thực thi các gói gốc được biên dịch sang môi trường của máy chủ.

Nếu chúng ta xem xét cụ thể Scrypto WASM VM, nó sẽ trông như thế này:

Về cơ bản, mô hình này có thể trông giống với mô hình EVM nhưng có hai điểm khác biệt quan trọng:

• Loại bỏ quyền truy cập trực tiếp vào bộ lưu trữ. Thay vì mỗi hợp đồng thông minh chỉ có thể truy cập vào bộ lưu trữ thuộc sở hữu của nó, mọi trạng thái đọc/ghi đều được thực hiện thông qua các lệnh gọi hệ thống. Lớp gián tiếp này cho phép triển khai nhiều điều thú vị trong hệ thống, chẳng hạn như chia sẻ trạng thái giữa các ứng dụng, ảo hóa trạng thái, v.v. Lớp gián tiếp này tương tự như lớp gián tiếp được cung cấp bởi bộ nhớ ảo hoặc của Linux mô tả tập tin .

  
  

• Bổ sung các cuộc gọi hệ thống . Cuộc gọi hệ thống là cơ chế mà lớp ứng dụng có thể truy cập các dịch vụ của lớp Hệ thống, chẳng hạn như thực hiện lệnh gọi đến các ứng dụng khác hoặc ghi dữ liệu vào một đối tượng. Các cuộc gọi hệ thống này tương tự như các lệnh ngắt phần mềm trong CPU thực (ví dụ: INT hướng dẫn trong x86).

Lớp hệ thống

Lớp hệ thống chịu trách nhiệm duy trì một bộ Mô-đun hệ thống hoặc phần mềm có thể cắm được để có thể mở rộng chức năng của hệ thống. Những cái này tương tự như của Linux mô-đun hạt nhân .

Trong mỗi lệnh gọi hệ thống, mỗi mô-đun hệ thống sẽ được gọi trước khi lớp hệ thống chuyển quyền điều khiển cho lớp hạt nhân. Khi được gọi, mỗi mô-đun hệ thống có thể cập nhật một số trạng thái cụ thể (ví dụ: cập nhật phí đã chi tiêu) hoặc kết thúc giao dịch (ví dụ: nếu trình kiểm tra loại không thành công).

Mẫu này cho phép hệ thống triển khai các chức năng như ủy quyền, tiền bản quyền hoặc kiểm tra loại trong khi được tách rời khỏi cả lớp ứng dụng và lớp nhân.

Lớp hạt nhân

Lớp kernel chịu trách nhiệm về hai chức năng cốt lõi của Radix Engine: truy cập lưu trữ và liên lạc giữa các ứng dụng. Điều này hơi giống với trách nhiệm của Hệ điều hành truyền thống đối với việc truy cập đĩa và mạng.

Đối với Radix Engine, điều này bao gồm quản lý cấp thấp sau:

• Kiểm tra xem ngữ nghĩa di chuyển/mượn có được duy trì trên bất kỳ lệnh gọi hoặc ghi dữ liệu nào không. Quy tắc một chủ sở hữu và quy tắc mượn được thực thi bởi kernel. Nếu vi phạm bất kỳ quy tắc nào trong số này, giao dịch sẽ bị hoảng loạn.
• Quản lý các đối tượng tạm thời và liên tục. Một đối tượng có thể ở trong không gian toàn cục tại bất kỳ thời điểm nào hoặc có thể được sở hữu bởi khung cuộc gọi. Hạt nhân duy trì các con trỏ chính xác tới các đối tượng này trong thời gian chạy khi các tham chiếu đến các đối tượng này được truyền đi khắp nơi.
• Quản lý cập nhật trạng thái giao dịch. Hạt nhân theo dõi các cập nhật trạng thái đã xảy ra trong quá trình giao dịch và sau đó sẽ được đưa vào cơ sở dữ liệu khi kết thúc giao dịch.

Phần mềm được lưu giữ

Các lớp này liên quan như thế nào đến việc lưu trữ trong giao thức DLT? Tương tự như lớp nhân trong Hệ điều hành, các lớp giữa này của Radix Engine cung cấp hướng cần thiết để tách rời sự phân đôi trừu tượng/lưu trữ khỏi sự phân đôi phần mềm/phần cứng và tạo ra khái niệm “phần mềm được lưu trữ”.

Phần mềm được lưu giữ có các đặc tính linh hoạt và bảo mật của phần mềm trong khi vẫn duy trì khả năng thực thi logic trên toàn hệ thống.

Chúng ta hãy xem qua một số ví dụ về lưu trữ hiện đang chạy trên mạng Radix và xem chúng được triển khai như thế nào.

Tài nguyên được lưu giữ

Điểm khác biệt cốt lõi của nền tảng Radix DeFi/Web3 là ý tưởng rằng tài nguyên (tức là tài sản) là nguyên thủy cơ bản cần được hiểu tách biệt với logic kinh doanh. Việc đưa ra khái niệm này cho phép tất cả các dApp, ví và công cụ có sự hiểu biết chung về giao diện và hành vi của nội dung trông như thế nào, giúp khả năng kết hợp dễ dàng hơn nhiều.

Mặc dù tài nguyên là một trong những phần ăn sâu nhất của hệ thống, nhưng việc triển khai việc lưu trữ nó chỉ cần hai phần mềm mô-đun:

• Gói gốc xử lý logic của các đối tượng tài nguyên như Nhóm, Kho tiền và Bằng chứng

• Một mô-đun hệ thống thực thi các bất biến trọn đời của các đối tượng này (chẳng hạn như khả năng di chuyển và khả năng đốt cháy tài nguyên)

  
  

Việc Radix Engine có thể thể hiện khái niệm sâu sắc về tài nguyên có thể di chuyển, được tiêu chuẩn hóa trong khi được trừu tượng hóa khỏi hệ thống/hạt nhân cho thấy sức mạnh của khung phần mềm hệ thống mô-đun.

Ủy quyền và tiền bản quyền được ghi nhận

Radix Engine tiêu chuẩn hóa ủy quyền và tiền bản quyền bằng cách tách logic này khỏi logic kinh doanh và triển khai chúng dưới dạng tính năng hệ thống. Điều này cho phép người dùng và nhà phát triển có cách hiểu chung được tích hợp sẵn để hiểu các yêu cầu để truy cập bất kỳ chức năng nào trên sổ cái.

Tính mô-đun của việc tách logic nghiệp vụ khỏi logic hệ thống cũng cho phép các tùy chọn phát triển/gỡ lỗi thuận tiện như khả năng xem trước giao dịch mà không cần kiểm tra xác thực thông thường (bạn muốn mô phỏng kết quả gửi 10 triệu USDC đi đâu đó? Khi ủy quyền bị vô hiệu hóa, giao dịch xem trước của bạn có thể thực hiện việc đúc tiền!).

Việc xác thực và tiền bản quyền yêu cầu bốn phần mềm mô-đun:

• Các gói gốc Xác thực và Tiền bản quyền cho phép lớp ứng dụng truy cập vào xác thực/tiền bản quyền của bất kỳ đối tượng nào (ví dụ: để truy xuất quy tắc xác thực để truy cập một phương thức hoặc yêu cầu tiền bản quyền).

• Các mô-đun hệ thống Xác thực và Tiền bản quyền được gọi trước lệnh gọi phương thức đối tượng để xác minh xem người gọi có đủ quyền để thực hiện cuộc gọi và thu tiền bản quyền hay không.

  
  

  
  

Giao dịch được bảo đảm

Giao diện chính xác giữa người dùng và hệ thống là điều tối quan trọng để bất kỳ hệ thống nào cũng có thể sử dụng được. Để có thể sử dụng được, giao diện phải tìm được sự cân bằng phù hợp giữa tính dễ sử dụng và sức mạnh/tính linh hoạt.

Trong thế giới Hệ điều hành, giao diện phổ biến nhất là thiết bị đầu cuối, một quy trình không gian người dùng cung cấp cho người dùng công cụ dòng lệnh để gọi và soạn các cuộc gọi hệ thống khác nhau.

Trong thế giới DLT, giao diện này là giao dịch. Tiêu chuẩn ngành cho một giao dịch là sử dụng một lệnh gọi chung, cấp thấp duy nhất. Thật không may, điều này quá đơn giản nên khó có thể hiểu được người ta thực sự đang làm gì khi tương tác với hệ thống.

Mặt khác, Radix Engine sử dụng mẫu hệ điều hành truyền thống và lưu giữ một ngôn ngữ ứng dụng (tương tự như ngôn ngữ kịch bản đầu cuối như bash) để gọi và soạn các cuộc gọi hệ thống trong một giao dịch.

Vì điểm vào của giao dịch hoạt động trong lớp ứng dụng nên trình thông dịch ngôn ngữ được triển khai bằng cách thêm gói gốc của Bộ xử lý giao dịch.

BLS được lưu giữ

Chữ ký BLS là một loại tiền điện tử nguyên thủy quan trọng vì chúng cho phép khả năng có chữ ký ngưỡng. Thật không may, việc chạy logic như vậy trong WASM sẽ nhanh chóng sử dụng hết đơn vị chi phí tối đa. Trong bản cập nhật “Anemone” gần đây, chúng tôi đã quy định BLS bằng cách thực thi nó nguyên bản và nhận thấy hiệu suất tăng gấp 500 lần khi so sánh với WASM.

Vì logic BLS không có trạng thái nên nó có thể dễ dàng được thêm vào dưới dạng tiền biên dịch bổ sung cho máy ảo Scrypto WASM.

Phần kết luận

Những gì cần lưu trữ và những gì không lưu trữ đều quan trọng đối với bất kỳ giao thức DLT nào. Thật không may, mô hình VM hiện tại của ngành khiến mọi quyết định bảo tồn đều trở thành một quyết định có tính rủi ro cao.

Lấy mô hình Hệ điều hành làm nguồn cảm hứng, Radix Engine giải quyết vấn đề này bằng cách thêm một lớp gián tiếp giữa “phần mềm” và “phần cứng”. Điều này cho phép Radix Engine thể hiện khái niệm “phần mềm được lưu trữ” và giúp giao thức dễ dàng thêm, sửa đổi và thể hiện các hệ thống được lưu trữ mới mà không đưa ra các quyết định gây tổn hại lớn.

Ban đầu, hệ điều hành được coi là một phần mềm nhỏ được thiết kế để quản lý các tài nguyên dùng chung cho nhiều ứng dụng. Khi nhu cầu của người dùng về một nền tảng tốt hơn, nhanh hơn, an toàn hơn ngày càng tăng, họ ngày càng phải đảm nhận nhiều trách nhiệm hơn với bộ phần mềm ngày càng lớn hơn.

DeFi sẽ không khác. Khi nhu cầu về nền tảng DeFi nhanh hơn, an toàn hơn và dễ sử dụng hơn tăng lên, khả năng lưu trữ sẽ tăng lên. Radix Engine được thiết kế với mục đích này và cung cấp khuôn khổ an toàn và có thể mở rộng cần thiết để mở rộng việc lưu giữ trong tương lai.