Tiêu đề gốc: "Đóng gói hay mở rộng?" Điểm dừng tiếp theo để khám phá cơ sở hạ tầng Web3 - Giải thích blog Vitalik Enshrinement"

Tác giả gốc: CP, CTO & amp; đồng sáng lập, Artela

Vitalik đã xuất bản một blog vào tuần trước "Ethereum có ổn không lưu giữ nhiều thứ hơn trong giao thức?》, đã chia sẻ suy nghĩ của mình về các chức năng cơ bản mà Ethereum yêu cầu để "lưu trữ" các ứng dụng lớp trên và thảo luận cách đề xuất một khung để đóng gói nhiều chức năng hơn mà các ứng dụng lớp trên yêu cầu. chức năng cơ bản.

Đây là vấn đề chính mà các hệ thống dựa trên nền tảng điển hình phải đối mặt: nhóm nên "đóng gói" các chức năng chính của ứng dụng lớp trên vào lớp dưới cùng hay nên Các nhà phát triển ứng dụng thực hiện nhiệm vụ ở lớp ứng dụng để “mở rộng” các chức năng này. Khi cơ sở hạ tầng phát triển theo hướng mở rộng quy mô lớn, việc thiết kế “đóng gói so với mở rộng” là rất quan trọng và sẽ là một trong những thiết kế then chốt ảnh hưởng đến việc liệu nó có thể được áp dụng trên quy mô lớn hay không.

Trong sáu tháng qua, một số cơ sở hạ tầng lớn đã tung ra các bản cập nhật kỹ thuật quan trọng của họ: Uniswap đã triển khai cơ chế Hook để hỗ trợ các nhóm mở rộng chức năng tùy chỉnh; Ví MetaMask đã ra mắt Snaps cho phép các nhà phát triển thêm tiện ích mở rộng cho người dùng; Ethereum hiện cũng đang phải đối mặt với vấn đề "đóng gói và mở rộng".

Bài viết này sẽ thảo luận về các lựa chọn thiết kế "đóng gói và mở rộng" cơ sở hạ tầng Web3, cũng như một số suy nghĩ cá nhân về vấn đề cơ sở hạ tầng chuỗi công cộng này.

Ethereum gặp phải những vấn đề gì? Đóng gói hay mở rộng

Về vấn đề "đóng gói và mở rộng", Ethereum luôn chọn "mở rộng".

Triết lý thiết kế của Ethereum bắt nguồn từ Unix, tạo ra một hạt nhân tối giản và phổ quát để cho phép các nhà phát triển ở lớp ứng dụng nhận ra nhu cầu của người dùng. Công nghệ chính hỗ trợ Ethereum đạt được điều này là: EVM. Ngôn ngữ hợp đồng thông minh hoàn chỉnh Turing cho phép các nhà phát triển tùy chỉnh ứng dụng của họ ở lớp ứng dụng.

Mô hình này có vẻ hợp lý nhưng lại không hoạt động tốt trên "Unix phi tập trung". Một trong những lý do quan trọng là: cái gọi là EVM The Turing đầy đủ sử dụng thực tế chưa được "hoàn thiện" cho lắm. Theo cơ chế gas và opcode giới hạn, nó yêu cầu chương trình sử dụng opcode giới hạn trong các bước giới hạn để hoàn thành nhiệm vụ của mình, điều này hạn chế rất nhiều cho ứng dụng và gây khó khăn cho việc trở nên toàn năng như các chương trình Web2 trong lớp người dùng của Unix. ứng dụng Các khả năng được yêu cầu bởi dApps cấp cao EVM không thể đáp ứng được. Cho dù đó là ví Rollup hay AA, mặc dù chúng có thể chạy trơn tru mà không cần sửa đổi L1 nhưng chúng luôn là sản phẩm MVP, hiệu quả và trải nghiệm vẫn còn kém xa mục tiêu của chúng.

Sự lựa chọn trước mắt các nhà phát triển là: EIP. Hãy để nhóm cốt lõi Ethereum “đóng gói” các chức năng quan trọng mà nó phụ thuộc vào lớp dưới cùng, từ đó cung cấp chúng để lớp ứng dụng sử dụng.

Các "tiện ích mở rộng" dựa trên EVM không thể đáp ứng nhu cầu phát triển ứng dụng và lúc này họ cần phải cân nhắc kỹ lưỡng về cách "đóng gói" chúng.

Nhưng với cơ sở hạ tầng phi tập trung, việc đóng gói các chức năng ứng dụng lớp trên không phải là điều đơn giản. Nó không chỉ là việc tích hợp một đoạn mã mà đằng sau nó là phần lớn nhất của hệ thống phi tập trung. Vấn đề: quản trị. "Đóng gói" có nghĩa là ngoài việc phát triển và bảo trì, nhóm cốt lõi cũng phải chịu trách nhiệm quản lý các chức năng này, đồng thời có nguy cơ làm suy yếu mô hình niềm tin của Ethereum và đưa ra các vấn đề có thể ảnh hưởng đến tính bền vững phát triển.

Như vậy có thể dễ dàng nhận thấy hiệu quả cuối cùng: số lượng chức năng mà nhóm nòng cốt có thể “gói gọn” là có hạn, và thứ hai, tầm quan trọng của chức năng này phải được cộng đồng nói chung công nhận, đồng thuận, cuối cùng hiệu quả thực hiện sẽ không cao, phải mất vài năm.

Đồng thời, điều này cũng có nghĩa là nếu chức năng bạn cần không phải là chức năng cơ bản cần có để đạt được sự đồng thuận rộng rãi thì Ethereum có thể không bao giờ có thể đáp ứng được. bạn, hoặc thậm chí là bạn. Nếu cố gắng, bạn có thể chọn xây dựng chuỗi ứng dụng của riêng mình, chịu chi phí vận hành và phát triển cao, đồng thời đánh mất vẻ đẹp về khả năng kết hợp của thế giới hợp đồng thông minh.

Về vấn đề "đóng gói và mở rộng", Ethereum vẫn chưa có giải pháp rõ ràng. Làm thế nào để việc "đóng gói" diễn ra "một cách có trật tự" là những gì Vitalik đã đề cập. Họ vẫn đang khám phá một khuôn khổ, cách xác định các hàm mục tiêu cần được đóng gói và cách đóng gói chúng.

Có thể học được điều gì khác từ Unix? Tiện ích mở rộng gốc!

Về vấn đề "đóng gói và mở rộng", Ethereum chủ yếu cần nhóm nòng cốt thực hiện việc đóng gói để bù đắp cho việc thiếu khả năng mở rộng của EVM. Hãy suy nghĩ về nó từ một góc độ khác: Nếu chúng ta cải thiện khả năng mở rộng của lớp ứng dụng, liệu chúng ta có thể giải quyết được phần lớn vấn đề không? Ví dụ: các nhà phát triển ứng dụng có thể tùy chỉnh các chức năng cơ bản cần thiết cho ứng dụng của họ theo ý tưởng của riêng họ mà không cần đợi nhóm cơ bản gói gọn chúng.

Chúng ta cũng biết rằng Ethereum đã học được rất nhiều triết lý thiết kế từ Unix, vì vậy chúng ta hãy tiếp tục tìm kiếm những ý tưởng trong hệ thống Unix.

Một hệ điều hành thương mại dựa trên Unix, hướng đến thị trường PC và phải đối mặt với nhu cầu đa dạng hơn về lớp ứng dụng và thậm chí cả nhu cầu mở rộng từ các kịch bản sử dụng của doanh nghiệp . . Nhưng đối với các hệ điều hành thương mại này, nhóm nòng cốt không có gánh nặng "đóng gói" cao, khả năng mở rộng mà họ cung cấp cho các ứng dụng đủ cao để người dùng có thể tự mình giải quyết hầu hết các chức năng.

Lấy Mac OS X làm ví dụ. Nói chung, các hệ điều hành phân biệt giữa chế độ kernel và chế độ người dùng Các ứng dụng người dùng Nói chung, nó chạy ở chế độ người dùng và sử dụng các chức năng được cung cấp bởi các chương trình chế độ kernel. Một so sánh đơn giản (nhưng chưa đầy đủ) là các hợp đồng thông minh trên EVM tương đương với các ứng dụng ở chế độ người dùng và lớp giao thức Ethereum tương đương với chế độ kernel.

Nhưng Mac OS phải đóng gói theo từng trường hợp. Các cơ chế cốt lõi được cung cấp bởi chức năng Mac OS.

Cảm hứng mà chúng tôi có được là liệu mô hình "Mở rộng hạt nhân" có khả thi trên "Unix phi tập trung" không? Mô hình của nó được thể hiện trong hình dưới đây.

Trên giao thức blockchain , Ngoài việc hỗ trợ "hợp đồng thông minh", nó còn hỗ trợ một chương trình khác "Tiện ích mở rộng gốc",

1) có nhiều API giao thức cơ bản hơn hợp đồng thông minh Quyền truy cập

2) Và hiệu quả môi trường thực thi của nó cao hơn nhiều so với EVM

3 ) Và nó tách biệt với giao thức cơ bản và không ảnh hưởng đến tính ổn định của giao thức cơ bản

4) Vì vậy, về mặt quản trị, nó không cần thiết được duy trì bởi nhóm bên dưới. Nhóm ứng dụng sẽ duy trì và triển khai nó

Nếu về mặt kỹ thuật, mô hình này có thể đáp ứng bốn điểm trên, có vẻ như nó có thể giải quyết được nhiều vấn đề vấn đề: các nhà phát triển ứng dụng có thể Ý tưởng là tùy chỉnh các chức năng cơ bản cần thiết cho ứng dụng của mình mà không cần đợi nhóm cơ bản đóng gói nó.

Hãy tạm thời tóm tắt mô hình này là mô hình “Mở rộng gốc”, sau đó xem liệu có bất kỳ bóng dáng nào của nó trong cơ sở hạ tầng Web3 hiện có hay không.

Móc, Móc, Móc…

Trong thế giới phần mềm, những bánh xe tuyệt vời thường được cấu tạo của việc tạo cảnh tuyệt vời. Là cơ sở hạ tầng DeFi, Uniswap đang trong giai đoạn quan trọng để trở thành một "nền tảng" và có thiết kế tuyệt vời về các đặc điểm "đóng gói và mở rộng": Hook. Nó cho phép các nhà phát triển sử dụng Hook để thêm các tiện ích mở rộng vào nhóm mà không cần được phép nhằm đạt được trải nghiệm nhóm đa dạng về chức năng mà không cần nhóm cốt lõi phải liên tục nâng cấp các chức năng thông qua "đóng gói".

Cơ chế hook tương tự như cơ chế đa điều kiện của Tiện ích gốc đã đề cập ở trên:

·Hook có thể được thực thi trong thời gian thực thi của nhóm Tham gia vào chu trình và có thể truy cập dữ liệu thời gian chạy. Đây là cấp truy cập nâng cao hơn

·Hook và nhóm là hai hợp đồng độc lập và tính bảo mật của Hook không ảnh hưởng đến pool

· Về mặt quản trị, Hook được các nhà phát triển bên thứ ba phát triển và triển khai mà không được phép và không được kích hoạt trên toàn cầu, nhưng bị ràng buộc với các nhóm khác nhau theo yêu cầu. Xác định các Móc khác nhau để kích hoạt các tính năng tùy chỉnh.

Hook là một thiết kế nhỏ nhưng đẹp giúp giải quyết vấn đề về khả năng mở rộng của pool. Cơ sở hạ tầng lớp ứng dụng dẫn đầu trong việc áp dụng các khái niệm này. Hãy tiếp tục xem xét ý tưởng của các giao thức cơ bản phức tạp hơn (L1/L2).

Ý tưởng mở rộng các dự án chuỗi công cộng mới

Ethereum đang gặp khó khăn, hãy cùng xem xét Chúng ta hãy xem dự án Layer2 được dành riêng cho việc mở rộng Layer1 và nó có những ý tưởng gì.

Arbitrum Stylus cho phép các nhà phát triển ứng dụng tự đóng gói các hợp đồng biên soạn sẵn!

Mọi người nên biết rằng EVM có thể mở rộng chức năng của mình thông qua "các hợp đồng được biên dịch trước". Mã của nó không chạy trong EVM mà được tích hợp trong nút. Hoạt động cơ bản . Ví dụ: nếu bạn muốn thêm các thuật toán mã hóa mới, vì chúng quá phức tạp và tốn kém để tính toán, bạn có thể triển khai nó dưới dạng hợp đồng được biên dịch trước và hợp đồng ứng dụng có thể gọi nó và sử dụng thuật toán mã hóa mới. Tuy nhiên, các quyền bổ sung của hợp đồng biên dịch trước không được mở cho các nhà phát triển ứng dụng và chúng cần được nhóm phát triển Ethereum "đóng gói" thông qua EIP trước khi có thể thêm vào.

Arbitrum Stylus đã đề xuất mô hình "EVM+". Trong khi theo đuổi sự tương đương/tương thích của EVM, Lớp 2 cho phép các nhà phát triển vượt qua những hạn chế của EVM và triển khai mà không cần được phép. Cao hơn thực hiện hợp đồng biên soạn trước. Nguyên tắc triển khai của nó là thêm môi trường thực thi WASM vào lớp thực thi để tải và chạy các hợp đồng WASM một cách linh hoạt. WASM cung cấp hiệu suất cao hơn nhiều so với EVM và cũng hỗ trợ nhiều ngôn ngữ lập trình.

Đây là một trong những cách triển khai có thể tối ưu hóa vấn đề "đóng gói" của Ethereum. Các yêu cầu mở rộng của EVM không còn chờ đội ngũ phía dưới đóng gói nữa, và nhóm dưới cùng tập trung vào việc triển khai, lớp bảo trì mở rộng môi trường, trong khi việc giới thiệu, phát triển và quản lý các chức năng mới được giao cho lớp ứng dụng.

Tuy nhiên, Stylus vẫn đang ở giai đoạn đầu, nhiều thách thức hơn của mẫu máy này vẫn chưa được bộc lộ và những vấn đề mà nó có thể giải quyết còn hạn chế. chỉ hỗ trợ đóng gói động các hợp đồng được biên dịch trước và Ethereum cũng phải đối mặt với nhiều vấn đề về đóng gói hơn bên cạnh các hợp đồng được biên dịch trước. Nhưng thật may mắn, đây là một trong những cách triển khai mà chúng ta có thể thấy gần với mô hình Native Extension. Với tư cách là đại diện cho thế hệ cơ sở hạ tầng mới, nó giới thiệu thiết kế khả năng mở rộng để giải quyết các vấn đề "đóng gói" mà hệ sinh thái của họ sẽ gặp phải trong tương lai quy mô.” vấn đề, có tính đến sự phát triển sinh thái lâu dài.

Tiện ích mở rộng gốc: ý tưởng "đóng gói mô-đun"!

Sau khi xem xét các dự án cơ sở hạ tầng như Web2 và Web3, nhìn lại vấn đề "đóng gói và mở rộng", chúng ta có thể thấy một ý tưởng rõ ràng: thông qua Cải thiện khả năng mở rộng và cho phép các nhà phát triển sử dụng các phương pháp mô-đun để đóng gói các chức năng mà họ muốn.

Đây là vai trò quan trọng của mô hình Tiện ích mở rộng gốc trong cơ sở hạ tầng. Bằng cách cải thiện khả năng mở rộng của cơ sở hạ tầng, sự lựa chọn được trả lại cho các nhà phát triển, làm cho Không ảnh hưởng đến Với sự ổn định của giao thức cốt lõi, các nhà phát triển có thể tự do đóng gói và mở rộng các chức năng họ muốn theo cách mô-đun.

Ethereum đang cố gắng cải thiện hiệu quả của việc "đóng gói" và Arbitrum Stylus đang giải phóng các hợp đồng được biên dịch trước. Nhìn xa hơn, chuỗi công khai cũng có thể sử dụng Mô hình Native Extension Để giải phóng hoàn toàn khả năng sáng tạo của lớp ứng dụng, giống như những gì Uniswap V4 mang lại cho mọi người.

Chuỗi công khai L1 mới dựa trên mô hình Tiện ích mở rộng gốc: Artela

Chuyển đổi góc nhìn tại đây, "Chúng tôi" ám chỉ nhóm tôi làm việc với tư cách là CTO: Artela. Hãy cùng chúng tôi chia sẻ suy nghĩ và hành động của mình về vấn đề này nhé.

Ngoài ra, trong Artela Blockchain với EVM, chúng tôi cũng đã cài đặt môi trường thực thi WASM. Một mặt, nó có thể chạy một chương trình có trạng thái, tương tự như một hợp đồng được biên dịch trước có trạng thái; mặt khác, nó hỗ trợ cơ chế giống như Hook, cho phép nó được kích hoạt tại nhiều nút vòng đời của quá trình xử lý khối và giao dịch. Nói cách khác, nó không chỉ được sử dụng để đóng gói các hợp đồng được biên dịch trước như Arbitrum Stylus mà còn có thể tùy chỉnh quy trình thực hiện các giao dịch và khối để đạt được khả năng đóng gói chức năng rộng hơn. Ví dụ: Tiện ích mở rộng gốc của WASM được kích hoạt trong giai đoạn xác minh giao dịch và các thuật toán mới được sử dụng để xác định và xác minh giao dịch. Các Hook này được gọi là Điểm tham gia trong Artela và các Tiện ích mở rộng gốc này không được gọi là Hợp đồng thông minh mà là Khía cạnh. Chúng tương tự như khái niệm AoP (Lập trình hướng theo khía cạnh). Trong hệ thống blockchain đang chạy, chúng được thêm vào một cách linh hoạt. Các tính năng mới được thêm vào để tham gia điểm!

Để đưa ra một ví dụ cụ thể, chúng tôi đã trao đổi với các nhà đầu tư và tổ chức Web2 để tìm hiểu đâu là trở ngại lớn nhất khi nhập tài sản quy mô lớn vào Web3. Vấn đề được thảo luận nhiều nhất là bảo mật ! Mặc dù công nghệ kiểm soát rủi ro cấp độ Web2 đảm bảo an toàn cho hàng tỷ tài sản nhưng rất khó để xâm nhập vào ngăn xếp công nghệ Web3. Carl đến từ lĩnh vực hàng không vũ trụ của NASA cũng bày tỏ quan điểm tương tự: Tại sao chúng ta cần Runtime Proctection và Khía cạnh.

Bảo vệ thời gian chạy là phương tiện cốt lõi để kiểm soát rủi ro bảo mật. Trong Web3 ngày nay, chúng ta có thể thấy rằng một nhóm các công ty bảo mật mạnh có cả kiểm tra tĩnh và xác minh chính thức, giám sát thời gian thực và các giao dịch chạy trước dường như đều là các phương pháp, nhưng chúng vẫn còn cách xa khả năng kiểm soát rủi ro thời gian thực ở cấp độ Web2. Vấn đề gốc cốt lõi là chỉ có rất nhiều phương pháp bảo mật xung quanh mempool, bởi vì Một khi giao dịch vượt qua Mempool, không thể làm gì được. Trong giai đoạn thực hiện giao dịch sau Mempool, nếu có khả năng mở rộng và các chuyên gia bảo mật có thể triển khai các chính sách bảo mật ở cấp độ thời gian chạy thì mức độ bảo mật sẽ được nâng lên mức cao hơn. Aspect cung cấp cho nhà phát triển khả năng mở rộng bảo mật đi sâu vào lớp thực thi!

Các nhà phát triển có thể triển khai các khía cạnh chỉ phục vụ dự án của riêng họ để tùy chỉnh các chức năng của lớp giao thức mà họ muốn. Ví dụ: để tăng tính bảo mật trong thời gian chạy, nếu một giao dịch có khả năng dẫn đến việc đánh cắp số tiền lớn thì giao dịch đó sẽ bị chặn trong Aspect.

Các nhà phát triển cũng có thể triển khai các khía cạnh công khai để gói gọn các chức năng cơ bản mà nhiều dự án có thể sử dụng lại. Ví dụ: một Khía cạnh triển khai các thuật toán và loại giao dịch cụ thể, làm cho ví AA có khả năng lập trình và kết hợp tốt hơn. Các nhà phát triển khác cũng có thể kích hoạt Khía cạnh này và sử dụng tính năng cơ bản này cho các dự án của riêng họ.

Đối với Artela, chúng tôi ngày càng quyết tâm hơn trong suốt chặng đường:

· Hãy để các nhà phát triển chuyển ứng dụng state Native Extension giải quyết vấn đề mà không cần sự cho phép, thay vì đợi nhóm chuỗi công cộng cơ bản đóng gói

· Hãy để các tổ chức lớn có nền tảng Web2 dám cam kết số tiền lớn trên blockchain (Được cải tiến bằng cách giới thiệu kiểm soát rủi ro thời gian chạy ở cấp độ Web2)

· Cho phép các nhà phát triển có môi trường sinh thái tốt để thực hiện những việc phá vỡ vòng tròn (EVM có thể sớm đạt mức trần, EVM+Native Extension có thể có nhiều tiềm năng hơn)

· Hãy để các trò chơi toàn chuỗi, RWA và các dApp khác muốn chuyển nhiều logic kinh doanh hơn sang chuỗi có một ngôi nhà lý tưởng

Chúng ta có thể thấy rằng Ethereum đang ở giai đoạn làm thế nào để "đóng gói" các tính năng ứng dụng và không có kế hoạch giải phóng " đóng gói" gây áp lực và cho phép sự sáng tạo một lần nữa quay trở lại với các nhà phát triển. Đối với nhóm các nhà đổi mới tiềm năng thế hệ tiếp theo, những người đủ dũng cảm để khám phá những đổi mới đột phá trong các ứng dụng phi tập trung, tình huống này rất hạn chế. Một mặt, họ cần một mạng lưới phi tập trung mạnh mẽ như vậy, nhưng mặt khác, họ không thể sử dụng bàn tay và bàn chân. Đây là lý do cốt lõi tại sao chúng tôi cam kết xây dựng chuỗi công khai L1 mới dựa trên mô hình Tiện ích mở rộng gốc, để cơ sở hạ tầng không từ chối tốc độ đổi mới.

Import Web2

Cuối cùng, kết thúc bài viết này bằng hai từ này. Mặc dù ở cấp độ viết mã, ngăn xếp Web3 dựa trên sự phân cấp và ngăn xếp Web2 là hai ý tưởng hoàn toàn khác nhau, nhưng điều đó không ngăn cản chúng ta tìm kiếm kho báu trong thư viện Web2 ở cấp độ triết lý thiết kế và lịch sử phát triển.

Bài viết này là từ một bài gửi và không thể hiện quan điểm của BlockBeats.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia