Bài viết phân tích của Vitalik: Trạm tiếp theo cho hạ tầng Web3 là đóng gói hay mở rộng?
Tuyển chọn TechFlowTuyển chọn TechFlow
Bài viết phân tích của Vitalik: Trạm tiếp theo cho hạ tầng Web3 là đóng gói hay mở rộng?
Bài viết này sẽ thảo luận về sự lựa chọn thiết kế giữa "đóng gói và mở rộng" của các cơ sở hạ tầng Web3, cũng như một số suy nghĩ cá nhân về vấn đề này trong cơ sở hạ tầng chuỗi công khai.
Chuyên sâu báo cáo Web3Tác giả: CP, CTO & đồng sáng lập Artela
Tuần trước, Vitalik đã đăng một bài blog có tên “Should Ethereum be okay with enshrining more things in the protocol?”, chia sẻ suy nghĩ về việc "đóng gói" (enshrine) các chức năng nền tảng cần thiết cho các ứng dụng cấp cao hơn vào giao thức Ethereum, thảo luận cách xây dựng một khuôn khổ để tích hợp nhiều chức năng nền tảng hơn mà các ứng dụng cấp cao cần.
Đây là một vấn đề then chốt điển hình mà mọi hệ thống nền tảng đều phải đối mặt: đội ngũ phát triển nên đưa các chức năng quan trọng của ứng dụng lên trên vào lớp底层 hay để các nhà phát triển ứng dụng tự "mở rộng" (extend) những chức năng này ở tầng ứng dụng. Khi cơ sở hạ tầng phát triển đến thời điểm bùng nổ quy mô lớn, quyết định giữa “đóng gói” và “mở rộng” trở nên cực kỳ quan trọng, là một trong những yếu tố then chốt ảnh hưởng đến khả năng mở rộng quy mô của hệ thống.
Trong nửa năm gần đây, nhiều nền tảng cơ sở hạ tầng lớn đã công bố các bản cập nhật kỹ thuật quan trọng: Uniswap ra mắt cơ chế Hook để hỗ trợ mở rộng pool với chức năng tùy chỉnh; ví MetaMask giới thiệu Snaps, cho phép nhà phát triển thêm tiện ích người dùng; giờ đây Ethereum cũng đang đối mặt với bài toán “đóng gói hay mở rộng”.
Bài viết này sẽ thảo luận về sự lựa chọn giữa “đóng gói” và “mở rộng” trong thiết kế các cơ sở hạ tầng Web3, cùng với một số suy nghĩ cá nhân về vấn đề này đối với cơ sở hạ tầng blockchain công cộng.
Ethereum đang đối mặt với điều gì? Đóng gói hay Mở rộng
Trong bài toán “đóng gói vs mở rộng”, Ethereum luôn chọn phương án “mở rộng”.
Triết lý thiết kế của Ethereum bắt nguồn từ Unix – xây dựng một nhân cốt lõi tối giản và phổ quát, để người dùng thỏa mãn nhu cầu thông qua các nhà phát triển tại tầng ứng dụng. Công nghệ then chốt giúp Ethereum thực hiện điều này chính là EVM. Ngôn ngữ hợp đồng thông minh Turing hoàn thiện cho phép các nhà phát triển tự do tùy biến ứng dụng riêng ở tầng ứng dụng.
Mô hình này thoạt nhìn rất hợp lý, nhưng lại không vận hành tốt trên “Unix phi tập trung”. Một lý do quan trọng là: tính “Turing hoàn thiện” mà EVM tuyên bố thực tế lại không hoàn thiện như mong đợi. Trong cơ chế gas và tập opcode giới hạn, chương trình buộc phải hoàn thành nhiệm vụ bằng số bước hữu hạn và opcode hữu hạn, điều này nghiêm trọng hạn chế khả năng ứng dụng – khiến chúng khó có thể linh hoạt vô hạn như các ứng dụng Web2 trên tầng người dùng Unix. Nhiều khả năng nâng cao mà dApp cao cấp cần thì EVM không đáp ứng được. Dù Rollup hay ví AA có thể vận hành mà không sửa đổi L1, nhưng vẫn chỉ là sản phẩm MVP, hiệu suất và trải nghiệm còn cách xa mục tiêu.
Lựa chọn đặt trước mặt các nhà phát triển là: EIP. Đề xuất chức năng quan trọng mà họ phụ thuộc, yêu cầu đội lõi Ethereum “đóng gói” nó vào tầng底层 để sử dụng tại tầng ứng dụng.
Việc “mở rộng” dựa trên EVM không còn đủ đáp ứng nhu cầu phát triển ứng dụng, nay họ cần nghiêm túc cân nhắc việc “đóng gói”.
Tuy nhiên, việc đóng gói chức năng ứng dụng cấp cao vào cơ sở hạ tầng phi tập trung không đơn giản. Nó không chỉ đơn thuần là tích hợp một đoạn mã, mà đằng sau đó là thách thức lớn nhất của hệ thống phi tập trung: quản trị (governance). “Đóng gói” nghĩa là đội lõi ngoài phát triển và bảo trì còn phải đảm nhận trách nhiệm quản trị các chức năng này, đồng thời làm tăng rủi ro làm suy yếu mô hình tin cậy của Ethereum, dẫn đến các vấn đề tiềm tàng ảnh hưởng đến tính phát triển bền vững.
Kết quả cuối cùng dễ thấy: số lượng chức năng đội lõi có thể “đóng gói” bị giới hạn; chức năng đó phải đạt được sự đồng thuận rộng rãi trong cộng đồng; hiệu quả triển khai thấp, mất hàng năm mới hoàn tất.
Đồng thời, điều này cũng có nghĩa rằng nếu chức năng bạn cần không phải là chức năng nền tảng được cộng đồng đồng thuận rộng rãi, Ethereum có thể mãi mãi không thể chứa đựng bạn – thậm chí cả những nỗ lực thử nghiệm của bạn. Bạn có thể buộc phải tự xây chuỗi ứng dụng riêng, gánh chi phí phát triển và vận hành cao, đánh mất sự tuyệt vời về khả năng kết hợp (composability) trong thế giới hợp đồng thông minh.
Trong bài toán “đóng gói vs mở rộng”, Ethereum vẫn chưa có giải pháp rõ ràng. Làm sao để việc “đóng gói” được “triển khai có trật tự”, như Vitalik nói, họ vẫn đang tìm kiếm một khuôn khổ để xác định chức năng mục tiêu cần đóng gói và cách thức thực hiện.
Từ Unix, ta còn học được gì nữa? Native Extension!
Vấn đề “đóng gói vs mở rộng” ở Ethereum chủ yếu xảy ra vì khả năng mở rộng của EVM không đủ, buộc đội lõi phải đóng gói bù đắp. Hãy đổi góc nhìn: nếu nâng cao khả năng mở rộng ở tầng ứng dụng, liệu có giải quyết phần lớn vấn đề? Ví dụ: nhà phát triển ứng dụng có thể tự do tùy chỉnh chức năng tầng底层 theo ý mình, không cần chờ đợi đội lõi đóng gói.
Chúng ta đều biết Ethereum học hỏi nhiều triết lý thiết kế từ Unix. Vậy hãy tiếp tục tìm ý tưởng trong hệ sinh thái Unix.
Các hệ điều hành thương mại dựa trên Unix hướng đến thị trường PC, đối mặt với nhu cầu đa dạng hóa mạnh mẽ từ tầng ứng dụng, thậm chí cả nhu cầu mở rộng từ các kịch bản sử dụng doanh nghiệp. Nhưng các hệ điều hành này lại không gây áp lực “đóng gói” lớn lên đội lõi – bởi họ cung cấp khả năng mở rộng cao cho ứng dụng, khiến phần lớn chức năng người dùng có thể tự giải quyết.
Lấy Mac OS X làm ví dụ, hệ điều hành thông thường phân biệt trạng thái nhân (kernel mode) và trạng thái người dùng (user mode), các ứng dụng người dùng thường chạy ở user mode, sử dụng chức năng do các chương trình kernel mode cung cấp. Một so sánh đơn giản (nhưng chưa đầy đủ): các hợp đồng thông minh trên EVM tương đương ứng dụng ở user mode, còn tầng giao thức Ethereum tương đương kernel mode.
Nhưng Mac OS X cho phép nhà phát triển tự triển khai chương trình vào kernel mode để mở rộng chức năng kernel, mà không cần đội lõi Mac OS X từng case một đi đóng gói. Cơ chế cốt lõi Mac OS X cung cấp là “Kernel Extension” và “System Extension”, cho phép nhà phát triển trong một khuôn khổ an toàn nhất định tạo ra phần mở rộng kernel, sử dụng quyền cao hơn để phát triển các chức năng mà ứng dụng thuần user mode không thể thực hiện.
Chúng ta rút ra bài học: mô hình “Kernel Extension” có khả thi trên “Unix phi tập trung” hay không? Mô hình của nó như hình dưới đây.
Trên giao thức blockchain, ngoài hỗ trợ “hợp đồng thông minh”, còn hỗ trợ một loại chương trình khác gọi là “Native Extension”, có các đặc điểm:
1) Có quyền truy cập API giao thức底层 cao hơn smart contract
2) Hiệu suất môi trường thực thi cao hơn EVM một bậc
3) Cách ly với giao thức底层, không ảnh hưởng đến độ ổn định của giao thức底层
4) Do đó, về mặt quản trị, không cần đội底层 bảo trì, mà do đội ứng dụng tự triển khai và duy trì
Nếu mô hình này thỏa mãn bốn điều kiện trên về mặt kỹ thuật, có vẻ có thể giải quyết nhiều vấn đề: nhà phát triển ứng dụng có thể tự do tùy chỉnh chức năng底层 cần thiết, không cần chờ đợi đội底层 đóng gói.
Chúng ta tạm gọi mô hình này là phạm trù “Native Extension”, rồi cùng xem trong các cơ sở hạ tầng Web3 hiện tại, có bóng dáng của nó không.
Hook, Hook, Hooks…
Trong thế giới phần mềm, những bánh xe vĩ đại thường được tạo nên bởi những bối cảnh vĩ đại. Uniswap, như một cơ sở hạ tầng DeFi, đang ở giai đoạn then chốt tiến tới trở thành một “nền tảng”, đã mang đến thiết kế ấn tượng về đặc tính “đóng gói vs mở rộng”: Hook. Nó cho phép nhà phát triển không cần xin phép, tận dụng Hook để thêm mở rộng cho pool, tạo trải nghiệm pool đa dạng chức năng, không cần đội lõi liên tục “đóng gói” để nâng cấp.
Cơ chế Hook tương tự nhiều điều kiện của Native Extension nêu trên:
· Hook có thể chèn vào vòng đời thực thi của pool và truy cập dữ liệu runtime – mức độ truy cập cao hơn
· Hook và pool là hai hợp đồng độc lập, an toàn của Hook không ảnh hưởng đến pool
· Về quản trị, Hook do nhà phát triển bên thứ ba phát triển và triển khai không cần xin phép, không kích hoạt toàn cục, mà mỗi pool có thể chọn gắn kết Hook khác nhau để kích hoạt tính năng tùy chỉnh.
Hook là thiết kế nhỏ gọn, đẹp đẽ, giải quyết vấn đề mở rộng của pool. Cơ sở hạ tầng tầng ứng dụng đi đầu áp dụng các khái niệm này. Giờ hãy tiếp tục xem xét các giao thức底层 phức tạp hơn (L1/L2).
Góc nhìn mở rộng từ các dự án blockchain mới
Ethereum đang gặp khó khăn, hãy cùng xem các dự án Layer 2 chuyên mở rộng Layer 1 đang có ý tưởng gì.
Arbitrum Stylus: cho phép nhà phát triển tự “đóng gói” hợp đồng tiền biên dịch!
Ai cũng biết EVM có thể mở rộng chức năng qua “hợp đồng tiền biên dịch” (precompiled contract). Mã của nó không chạy trong EVM mà được tích hợp trực tiếp vào node, thực thi ở tầng底层. Ví dụ, muốn thêm thuật toán mã hóa mới – vì quá phức tạp và tốn kém – có thể triển khai thành hợp đồng tiền biên dịch, rồi các hợp đồng ứng dụng có thể gọi nó để dùng thuật toán mới. Tuy nhiên, quyền thêm hợp đồng tiền biên dịch không mở cho nhà phát triển ứng dụng, mà phải qua EIP để đội phát triển Ethereum “đóng gói” mới thêm được.
Arbitrum Stylus đề xuất phạm trù “EVM+”, khi Layer 2 theo đuổi tương thích/tương đương EVM, đồng thời cho phép nhà phát triển vượt giới hạn EVM, triển khai không cần xin phép các hợp đồng tiền biên dịch hiệu suất cao hơn. Nguyên lý thực hiện là thêm môi trường thực thi WASM ở tầng thực thi, để tải động và chạy các hợp đồng WASM. WASM cung cấp hiệu suất cao hơn EVM một bậc, đồng thời hỗ trợ nhiều ngôn ngữ lập trình.
Đây là một trong những cách giải quyết vấn đề “đóng gói” của Ethereum. Nhu cầu mở rộng EVM không còn phải chờ đội底层 đóng gói; đội底层 tập trung bảo trì môi trường mở rộng ở tầng thực thi, còn việc giới thiệu, phát triển và quản trị chức năng mới được chuyển cho tầng ứng dụng tự phát triển.
Tuy nhiên Stylus vẫn ở giai đoạn sớm, các thách thức sâu hơn của mô hình này chưa lộ diện rõ, và khả năng giải quyết vẫn còn hạn chế – hiện chỉ hỗ trợ đóng gói động hợp đồng tiền biên dịch, trong khi Ethereum còn đối mặt nhiều bài toán đóng gói khác ngoài hợp đồng tiền biên dịch. Tuy vậy, đáng mừng là đây là một trong những hiện thực gần nhất với phạm trù Native Extension. Là đại diện cho thế hệ cơ sở hạ tầng mới, nó đưa vào thiết kế mở rộng để giải quyết bài toán “đóng gói” khi hệ sinh thái mở rộng quy mô, tính đến phát triển dài hạn.
Native Extension: một tư duy “đóng gói mô-đun”!
Sau khi điểm lại các dự án cơ sở hạ tầng Web2 và Web3, quay lại bài toán “đóng gói vs mở rộng”, ta thấy một mạch suy nghĩ rõ ràng: nâng cao khả năng mở rộng để nhà phát triển tự do “đóng gói” chức năng cần thiết theo kiểu mô-đun.
Đây chính là vai trò quan trọng của phạm trù Native Extension trong cơ sở hạ tầng: nâng cao khả năng mở rộng của cơ sở hạ tầng, trả lại quyền lựa chọn cho nhà phát triển, cho phép họ tự do đóng gói và mở rộng chức năng theo kiểu mô-đun, mà không ảnh hưởng đến sự ổn định của giao thức cốt lõi.
Ethereum đang cố nâng cao hiệu suất “đóng gói”, Arbitrum Stylus đang giải phóng hợp đồng tiền biên dịch. Nhìn xa hơn, blockchain công cộng còn có thể dùng phạm trù Native Extension để hoàn toàn giải phóng sức sáng tạo ở tầng ứng dụng, giống cảm giác Uniswap V4 mang lại.
Blockchain L1 mới dựa trên phạm trù Native Extension: Artela
Giờ đổi góc nhìn, “chúng tôi” ở đây là đội ngũ tôi – với tư cách CTO – đang làm việc tại Artela. Chúng tôi chia sẻ suy nghĩ và hành động của mình về vấn đề này.
Trên blockchain Artela, ngoài EVM, chúng tôi còn thiết lập thêm một môi trường thực thi WASM. Một mặt, nó có thể chạy chương trình stateful, tương tự hợp đồng tiền biên dịch có trạng thái; mặt khác, trên nền tảng này, nó hỗ trợ cơ chế tương tự Hook, cho phép kích hoạt thực thi tại nhiều điểm vòng đời xử lý khối và giao dịch. Nghĩa là, nó không chỉ dùng để đóng gói hợp đồng tiền biên dịch như Arbitrum Stylus, mà còn tùy chỉnh luồng thực thi giao dịch và khối, thực hiện đóng gói chức năng rộng hơn. Ví dụ: kích hoạt Native Extension WASM ở giai đoạn xác thực giao dịch, dùng thuật toán mới để nhận diện và xác thực giao dịch. Các Hook này trong Artela gọi là Join Point, các Native Extension này không gọi là Smart Contract mà gọi là Aspect (thiết diện), tương tự khái niệm AoP (Aspect-oriented Programming), chèn động chức năng mới vào các Join Point khác nhau trong hệ thống blockchain đang vận hành!
Lấy ví dụ cụ thể, chúng tôi từng trao đổi với các nhà đầu tư và tổ chức Web2, hỏi rào cản lớn nhất để đưa tài sản quy mô lớn vào Web3 là gì, câu trả lời phổ biến nhất là vấn đề an toàn! Các công nghệ kiểm soát rủi ro (risk control) ở cấp Web2 đã bảo vệ an toàn cho hàng tỷ tài sản, nhưng lại khó lọt vào stack công nghệ Web3. Carl, đến từ lĩnh vực hàng không vũ trụ NASA, cũng bày tỏ quan điểm tương tự: Tại sao chúng ta cần Runtime Protection và Aspect.
Runtime Protection là biện pháp cốt lõi trong kiểm soát rủi ro an toàn. Trong Web3 hiện tại, ta thấy một loạt công ty an toàn mạnh: có kiểm toán tĩnh, có xác minh hình thức, có giám sát thời gian thực, thậm chí có thể抢跑交易. Dường như đã đủ mọi phương pháp, nhưng vẫn còn cách xa kiểm soát rủi ro thời gian thực cấp Web2. Nguyên nhân gốc rễ là: các biện pháp an toàn quanh mempool chỉ dừng ở đó, vì một khi giao dịch vượt qua Mempool thì bất lực. Nếu ở giai đoạn thực thi giao dịch sau Mempool có khả năng mở rộng, để chuyên gia an toàn triển khai chiến lược an toàn cấp runtime, thì mức độ an toàn sẽ lên một tầm cao mới. Và Aspect chính là trao cho nhà phát triển khả năng mở rộng an toàn sâu vào tầng thực thi!
Nhà phát triển có thể triển khai Aspect phục vụ riêng dự án mình, tùy chỉnh chức năng tầng giao thức cần thiết. Ví dụ thêm an toàn runtime: nếu một giao dịch có nguy cơ gây mất cắp số tiền lớn, nó sẽ bị chặn lại trong Aspect.
Nhà phát triển cũng có thể triển khai Aspect công cộng, đóng gói chức năng nền tảng có thể tái sử dụng cho nhiều dự án. Ví dụ một Aspect nào đó triển khai thuật toán và kiểu giao dịch đặc biệt, giúp ví AA 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ể bật Aspect này để dùng đặc tính底层 đó cho dự án mình.
Với Artela, càng đi xa, suy nghĩ của chúng tôi càng kiên định:
· Cho phép nhà phát triển giải quyết vấn đề không cần xin phép qua Native Extension ở trạng thái ứng dụng, thay vì chờ đội lõi blockchain đóng gói
· Khiến các tổ chức lớn, dòng vốn lớn từ nền tảng Web2 dám stake trên blockchain (bằng cách đưa vào kiểm soát rủi ro runtime cấp Web2 để tăng cường)
· Tạo một môi trường tốt để nhà phát triển làm những điều phá vỡ ranh giới (EVM có thể sớm chạm trần, EVM + Native Extension có thể tiềm năng hơn)
· Mang đến một mái nhà lý tưởng cho các dApp như game toàn chuỗi, RWA – những ứng dụng muốn đưa nhiều logic nghiệp vụ hơn lên blockchain
Chúng tôi thấy rõ: Ethereum đang ở giai đoạn suy nghĩ “đóng gói” đặc tính ứng dụng, nhưng chưa thấy kế hoạch giải phóng áp lực “đóng gói” để trả lại sức sáng tạo cho nhà phát triển. Với nhóm đổi mới tiềm năng – những người tiên phong khám phá ứng dụng phi tập trung – tình trạng này quá gò bó: họ vừa cần một mạng lưới phi tập trung vững chắc, vừa không thể tung cánh. Đây chính là lý do cốt lõi chúng tôi cam kết xây dựng một blockchain L1 mới dựa trên phạm trù Native Extension: để cơ sở hạ tầng không ngăn bước đổi mới.
Import Web2
Cuối cùng, kết thúc bài viết bằng hai từ này. Dù về mặt viết code, stack Web3 phi tập trung và stack Web2 hoàn toàn là hai tư duy khác nhau, nhưng không ngăn cản chúng ta tì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. Keep building!
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@Artela_Network
