Vitalik đã xuất bản một blog ” Ethereum có ổn khi đưa nhiều thứ hơn vào giao thức không?” vào tuần trước , chia sẻ suy nghĩ của mình về các chức năng cơ bản cần thiết cho các ứng dụng lớp trên “lưu trữ” của Ethereum và thảo luận cách đề xuất một khung để đóng gói cơ bản hơn các chức năng được yêu cầu bởi các ứng dụng lớp trên.
Đây là vấn đề chính mà các hệ thống 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 ứng dụng chính của lớp trên vào lớp dưới cùng hay các nhà phát triển ứng dụng nên “mở rộng” các chức năng này ở lớp ứng dụng. 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 đã đưa ra 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 để hỗ trợ 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 tình trạng “đóng gói so với đóng gói”. phần mở rộng” vấn đề khó khăn.
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ủa 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 phải đối mặt với những vấn đề gì? Đóng gói hoặc 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 nó hoạt động khô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à tính hoàn chỉnh Turing của EVM không quá “hoàn chỉnh” trong sử dụng thực tế. 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 vẫ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 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 được 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.
Tuy nhiên, để cơ sở hạ tầng phi tập trung có thể gói gọn các chức năng ứng dụng lớp trên không phải là điều đơn giản, không chỉ là việc tích hợp một đoạn mã mà đằng sau đó là vấn đề lớn nhất của các hệ thống phi tập trung: 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.
Vì vậy, có thể dễ dàng nhận thấy hiệu quả cuối cùng: có một số chức năng hạn chế mà nhóm nòng cốt có thể “đóng gói”, thứ hai, tầm quan trọng của chức năng này cần được cộng đồng thừa nhận rộng rãi. Cuối cùng, hiệu quả thực hiện của nó sẽ không như vậy cao, và phải mất vài năm. .
Đồng thời, điều này cũng có nghĩa là nếu các chức năng bạn cần không phải là các chức năng cơ bản được công nhận rộng rãi thì Ethereum có thể không bao giờ đáp ứng được cho bạn, dù có cố gắng, bạn cũng có thể phải lựa chọn xây dựng chuỗi ứng dụng của riêng mình và chịu chi phí phát triển và vận hành cao, đồng thời làm mất đi vẻ đẹp của khả năng kết hợp trong 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.
Bạn có thể học được gì khác từ Unix? Tiện ích mở rộng gốc !
Về vấn đề “đóng gói so với 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 đã tiếp thu nhiều triết lý thiết kế từ Unix nên chúng ta hãy tiếp tục tìm kiếm những ý tưởng trong hệ thống Unix.
Là một hệ điều hành thương mại dựa trên Unix, nó hướng đến thị trường PC và phải đối mặt với những 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 tình huống 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ụ, các hệ điều hành nói chung phân biệt giữa chế độ kernel và chế độ người dùng. Các ứng dụng người dùng thường chạy ở chế độ người dùng và sử dụng các chức năng do các chương trình chế độ kernel cung cấp. 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.
Tuy nhiên, Mac OS X cho phép các nhà phát triển ứng dụng triển khai độc lập các chương trình ở trạng thái kernel để mở rộng các chức năng của trạng thái kernel mà không yêu cầu Mac OS Các cơ chế cốt lõi được cung cấp bởi chức năng Mac OS.
Nguồn cảm hứng mà chúng tôi có được là 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.
Ngoài việc hỗ trợ “hợp đồng thông minh”, giao thức blockchain còn hỗ trợ một chương trình khác là “Native Extension”.
1) Có nhiều quyền truy cập API giao thức cơ bản hơn hợp đồng thông minh
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ó được tách biệt khỏ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 được duy trì bởi nhóm cơ bản mà được duy trì và triển khai bởi nhóm ứng dụng.
Nếu mô hình này có thể đáp ứng được bốn điểm trên về mặt kỹ thuật thì có vẻ như nó có thể giải quyết được nhiều vấn đề: 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 mình theo ý tưởng riêng mà không cần đợi nhóm bên dưới gói gọn nó.
Hiện tại, hãy tóm tắt mô hình này là mô hình “Tiện ích mở rộng gốc” và 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 tạo ra bởi những tình huống 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ế của Hook tương tự như cơ chế đa điều kiện của Native Extension đã đề cập ở trên:
· Hook có thể cắt vào vòng đời thực thi của nhóm 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à pool 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 phát triển và triển khai bởi các nhà phát triển bên thứ ba mà không được phép và không được kích hoạt trên toàn cầu. Thay vào đó, các nhóm khác nhau liên kết các Hook khác nhau nếu cần để 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ủa các dự án chuỗi công cộng mới
Ethereum đang gặp khó khăn, hãy cùng xem ý tưởng của các dự án Lớp 2 dành riêng cho việc mở rộng Lớp 1.
Arbitrum Stylus cho phép các nhà phát triển ứng dụng tự đóng gói các hợp đồng được biên dịch 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 “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 và chạy ở phía dưới. 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+”. Lớp 2, trong khi theo đuổi sự tương đương/tương thích của EVM, cho phép các nhà phát triển vượt qua các hạn chế của EVM và triển khai các hợp đồng biên dịch trước hiệu suất cao hơn mà không cần được phép. 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 nhóm dưới cùng đóng gói. Nhóm dưới cùng tập trung vào việc duy trì môi trường mở rộng lớp thực thi, trong khi phần giới thiệu, việc phát triển và quản trị các chức năng mới được trao đổi, được phát triển bởi 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ô hình này vẫn chưa được bộc lộ và các vấn đề mà nó có thể giải quyết còn hạn chế. Hiện tại, nó chỉ hỗ trợ đóng gói động các hợp đồng được biên dịch trước và Ethereum cũng gặp phải nhiều vấn đề về đóng gói hơn ngoài việc biên dịch trước. hợp đồng. 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 câu hỏi “đóng gói và mở rộng”, chúng ta có thể thấy một ý tưởng rõ ràng: bằng cách cải thiện khả năng mở rộng, các nhà phát triển có thể sử dụng các phương pháp mô-đun để đóng gói những gì 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, để các nhà phát triển có thể tự do sử dụng nó mà không ảnh hưởng đến tính ổn định của giao thức cốt lõi. mở rộng các chức năng mong muốn của họ.
Ethereum đang cố gắng nâng cao 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 sẵn. Nhìn xa hơn về phía trước, các chuỗi công khai cũng có thể giải phóng hoàn toàn khả năng sáng tạo của lớp ứng dụng thông qua mô hình Native Extension, giống như những gì Uniswap V4 mang lại với mọi người. Hãy cảm nhận như vậy.
Chuỗi công khai L1 mới dựa trên mô hình Tiện ích mở rộng gốc: Artela
Hãy thay đổi quan điểm ở đây nhé. “Chúng tôi” ám chỉ nhóm 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é.
Trên chuỗi khối Artela, ngoà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 trong 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à được gọi là Các 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 thay đổi linh hoạt theo nhiều cách khác nhau. các khía cạnh. Các tính năng mới được thêm vào Điểm tham gia!
Để đư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, người đế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à Aspect.
Runtime Protection là phương pháp 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 rấ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à giao dịch chạy trước. Đây dường như là tất cả các phương pháp , như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 một giao dịch vượt qua Mempool, nó sẽ không thể làm được gì. 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 các 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!
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 có thể được nhiều dự án 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 dễ lập trình và kết hợp 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, suy nghĩ của chúng tôi ngày càng trở nên quyết tâm hơn trong suốt chặng đường:
· Cho phép các nhà phát triển giải quyết vấn đề mà không cần được phép thông qua Tiện ích mở rộng gốc ở trạng thái ứng dụng, thay vì chờ nhóm chuỗi công cộng cơ bản đóng gói nó
· Cho phép các tổ chức lớn có nền Web2 dám cam kết số tiền lớn trên blockchain (được tăng cường 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 và 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 vào 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 của ứng dụng và không có kế hoạch giải phóng áp lực “đóng gói” của chúng và để sự sáng tạo trở lại tay các nhà phát triển một lần nữa. Đố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 cản trở tốc độ đổi mới.
Nhập 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 phi tập trung 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 về triết lý thiết kế và lịch sử phát triển.
