Giải mã bài viết trên blog của Vitalik: Khám phá khả năng tích hợp ZK-EVM vào Ethereum
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã bài viết trên blog của Vitalik: Khám phá khả năng tích hợp ZK-EVM vào Ethereum
Ethereum có thể sau này sẽ không chỉ xem ZK-EVM như một thành phần bổ sung.
Chuyên sâu báo cáo Web3Bài viết: TechFlow
Hôm qua, Vitalik đã đăng một bài viết mới trên blog cá nhân mang tên “What might an ‘enshrined ZK-EVM’ look like?”, trong đó trình bày toàn diện về khả năng tích hợp ZK-EVM vào Ethereum, các phương pháp thực hiện và những hiệu ứng kỳ vọng.
Tương lai phát triển của EVM thường liên quan đến nhiều câu chuyện hoặc định hướng thay đổi liên quan đến hạ tầng, điều đáng để chúng ta tìm hiểu và nghiên cứu.
Tuy nhiên, do bài viết đề cập quá nhiều chi tiết kỹ thuật, phần lớn tài liệu tiếng Trung và cộng đồng chỉ đơn thuần dịch lại một cách sơ sài, khiến người đọc khó nắm bắt được mạch suy luận và quan điểm chính.
Vì vậy, TechFlow đã phân tích bài viết này nhằm khôi phục lại dòng suy nghĩ và quan điểm của Vitalik theo cách dễ hiểu hơn, cung cấp tài liệu tham khảo cho độc giả.
Từ khóa trong tiêu đề ám chỉ: "Phong thánh" ZK-EVM
Nếu chỉ đọc bản dịch trực tiếp, bạn sẽ khó cảm nhận được sắc thái ẩn ý hay cách diễn đạt tự nhiên trong ngữ cảnh tiếng Anh.
Trong tiêu đề bài viết của Vitalik, xuất hiện một từ tiếng Anh ít dùng: “enshrined”.
Chỉ cần tra nhanh GPT hoặc từ điển tiếng Anh, bạn sẽ thấy:
Từ "Enshrined" trong tiếng Anh nguyên nghĩa là “phong làm thiêng liêng”, thường dùng để mô tả việc nâng cao vị thế, tầm quan trọng hoặc giá trị của một vật hoặc một người lên mức cực kỳ cao, như thể đặt nó vào một vị trí linh thiêng hoặc được bảo vệ.
Trong văn bản pháp lý hoặc tôn giáo, "enshrine" thường chỉ việc ghi chép hoặc lưu giữ chính thức và trang trọng một số nguyên tắc, quyền lợi hoặc niềm tin nhất định.
Trong lĩnh vực công nghệ hoặc phần mềm, "enshrined" thường có nghĩa là tích hợp chính thức và trọng tâm một công nghệ, chức năng hoặc nguyên tắc nào đó vào hệ thống, nền tảng hoặc giao thức. Điều này thường ngụ ý rằng công nghệ hoặc chức năng đó được coi là cơ bản, cốt lõi hoặc then chốt, do đó được đưa vào hệ thống một cách chính thức và lâu dài.
Do đó, chúng ta có thể nhanh chóng hiểu được ý định của bài viết từ tiêu đề:
Khám phá khả năng tích hợp phiên bản Máy ảo Ethereum (EVM) sử dụng Chứng minh không kiến thức (ZK) như một thành phần cốt lõi hoặc chính thức vào giao thức Ethereum.
Nói cách khác, tương lai Ethereum có thể sẽ không còn xem ZK-EVM chỉ là một thành phần bổ sung.
Quá khứ của ZK-EVM: Thành phần “bổ trợ” dưới dạng L2, không phải bản địa
Với những độc giả chưa quen thuộc với EVM của Ethereum và các giải pháp L2 liên quan, khi Vitalik thảo luận về việc đưa ZK-EVM trở thành phần chính thức của mạng chính Ethereum, điều này dễ gợi lên một câu hỏi khác:
Trước đây, mối quan hệ giữa ZK-EVM và Ethereum là gì? Trước kia ZK-EVM không phải là “phần chính thức” của Ethereum sao?
Chúng ta hãy cùng tìm hiểu nhanh và nhẹ:
-
Máy ảo Ethereum (EVM): Lõi của mạng Ethereum, chịu trách nhiệm thực thi mã hợp đồng thông minh. Tất cả các hợp đồng thông minh chạy trên Ethereum đều được thực thi thông qua EVM.
-
Chứng minh không kiến thức (ZK): Một công nghệ mã hóa, cho phép một bên (người chứng minh) chứng minh với bên kia (người xác minh) rằng một tuyên bố nào đó là đúng mà không cần tiết lộ bất kỳ thông tin nào ngoài tuyên bố đó. Công nghệ này trong lĩnh vực tiền mã hóa và blockchain được dùng để tăng cường tính riêng tư và bảo mật giao dịch.
-
Vai trò của ZK-EVM: Kết hợp chức năng của EVM và đặc tính bảo vệ riêng tư của chứng minh không kiến thức. Nó cho phép xác minh tính hợp lệ của giao dịch trong khi vẫn giữ dữ liệu giao dịch bí mật. Điều này có nghĩa là có thể chứng minh giao dịch tuân thủ quy tắc hợp đồng thông minh và blockchain mà không tiết lộ nội dung cụ thể của giao dịch.
-
Mối quan hệ giữa ZK-EVM và mạng chính Ethereum: ZK-EVM có thể là một giải pháp, duy trì khả năng tương thích với Máy ảo Ethereum trong khi giới thiệu chứng minh không kiến thức, giúp các giao dịch được thực thi giữ được tính riêng tư. Trong giai đoạn đầu, ZK-EVM chủ yếu xuất hiện dưới dạng giải pháp lớp hai (Layer 2), tức là xây dựng trên mạng chính Ethereum, cung cấp thêm chức năng bảo vệ riêng tư và mở rộng cho mạng chính.
Do đó, hiện tại ZK-EVM chủ yếu tồn tại dưới dạng L2 chứ không nằm trong thiết kế gốc của Ethereum L1. Nói một cách通俗, nó là một thành phần bổ trợ.
Các giải pháp ZK-EVM nổi bật thì ai cũng biết rồi, ví dụ như Starknet, zkSync, Polygon Hermez và Scroll.
Sau khi có những kiến thức nền tảng trên, việc hiểu blog của Vitalik sẽ dễ dàng hơn rất nhiều.
Tại sao cần tích hợp ZK-EVM bản địa vào Ethereum?
Theo logic ở trên, bạn có thể đặt câu hỏi: Các giải pháp L2 của ZK-EVM đang hoạt động tốt, tại sao Vitalik lại muốn thảo luận về việc đưa ZK-EVM trực tiếp vào thiết kế cốt lõi của Ethereum?
Vitalik đã trả lời ngắn gọn và rõ ràng:
-
Phụ thuộc vào kho mã lớn: Các giải pháp Layer 2 hiện tại, như Optimistic Rollups và ZK Rollups, phụ thuộc vào việc xác minh EVM. Điều này có nghĩa là chúng phải tin tưởng vào một kho mã khổng lồ. Nếu kho mã này có lỗi, các máy ảo (VMs) có thể bị tấn công.
-
Vấn đề quản trị: Ngay cả các ZK-EVM mong muốn hoàn toàn tương đương với L1 EVM, cũng cần một cơ chế quản trị nào đó để sao chép các thay đổi từ L1 EVM sang triển khai EVM của chính họ. Điều này làm tăng độ phức tạp và rủi ro mất nhất quán tiềm tàng.
-
Chức năng trùng lặp: Các dự án Layer 2 sao chép các chức năng vốn đã tồn tại trong giao thức Ethereum. Quản trị Ethereum đã chịu trách nhiệm nâng cấp và sửa lỗi. Về bản chất, công việc mà ZK-EVM thực hiện giống hệt với việc xác minh khối L1 Ethereum.
-
Phát triển khách hàng nhẹ trong tương lai: Khi các khách hàng nhẹ ngày càng mạnh mẽ hơn và sớm có thể sử dụng ZK-SNARKs để xác minh hoàn toàn việc thực thi L1 EVM, mạng Ethereum về cơ bản sẽ sở hữu một ZK-EVM tích hợp sẵn. Điều này đặt ra câu hỏi: Tại sao không cung cấp ZK-EVM bản địa này cho cả rollup?
Thông qua việc thảo luận các vấn đề này, Vitalik làm rõ động lực đưa ZK-EVM vào thiết kế cốt lõi của Ethereum — chủ yếu nhằm giải quyết rủi ro phụ thuộc vào mã nguồn bên ngoài, đơn giản hóa quy trình quản trị, giảm sự trùng lặp chức năng và tận dụng khả năng vốn có của mạng Ethereum.
ZK-EVM tích hợp sẵn nên trông như thế nào?
Vậy nếu Ethereum muốn tích hợp ZK-EVM, thì nó nên có những chức năng và đặc điểm gì? Vitalik tiếp tục đưa ra định hướng:
-
Chức năng cơ bản: Chức năng cốt lõi của ZK-EVM là xác minh khối Ethereum. Nghĩa là nó phải có thể nhận gốc trạng thái trước (pre-state root), một khối và gốc trạng thái sau (post-state root) làm đầu vào, và xác minh rằng gốc trạng thái sau thực sự là kết quả sau khi thực thi khối đó.
-
Tương thích với triết lý đa khách hàng của Ethereum: ZK-EVM nên tránh áp dụng duy nhất một hệ thống chứng minh, mà cho phép các khách hàng khác nhau sử dụng các hệ thống chứng minh khác nhau. Điều này liên quan đến yêu cầu về khả năng truy cập dữ liệu, và bằng chứng nên độc lập với cấu trúc dữ liệu EVM và khối.
-
Khả năng kiểm toán: Nếu bất kỳ hành động thực thi nào được chứng minh, dữ liệu nền tảng phải có sẵn để người dùng và nhà phát triển có thể kiểm tra khi xảy ra sự cố.
-
Khả năng nâng cấp: Nếu phát hiện một lỗ hổng trong ZK-EVM cụ thể, nên có thể sửa chữa nhanh chóng mà không cần hard fork.
-
Hỗ trợ almost-EVMs: ZK-EVM nên hỗ trợ đổi mới ở tầng thực thi và mở rộng EVM. Nếu máy ảo L2 chỉ hơi khác biệt so với EVM, nó vẫn có thể sử dụng ZK-EVM bản địa tích hợp trong giao thức để xử lý phần giống EVM, và chỉ dựa vào mã riêng của mình cho phần khác biệt.
Lưu ý, một số độc giả có thể chưa hiểu rõ khái niệm almost-EVMs. Thực tế, Vitalik từng đề cập quan điểm tương tự, ông cho rằng một số giải pháp ZK-EVM trong quá trình thực thi không cần phải cứng nhắc giống hệt EVM, mà có thể “gần giống” EVM gốc.
Trong khung ZK-EVM mà Vitalik đề xuất, việc hỗ trợ almost-EVMs có nghĩa là ZK-EVM có thể linh hoạt thích nghi với nhiều nhu cầu và tình huống khác nhau. Điều này cho phép ZK-EVM không chỉ phục vụ các ứng dụng tuân thủ nghiêm ngặt chuẩn EVM, mà còn hỗ trợ các hệ thống muốn điều chỉnh nhẹ.
ZK-EVM tích hợp sẵn sẽ chạy như thế nào trên các client Ethereum khác nhau?
Tiếp tục theo dõi bài viết gốc của Vitalik, ở đây dễ bị nhầm lẫn: Sao lại đột ngột chuyển sang chuyện client?
Nhìn lại phần trước, bạn sẽ thấy logic trình bày của Vitalik rất rõ ràng:
“Tôi muốn biến ZK-EVM thành thành phần tích hợp của Ethereum --- Tại sao nên làm vậy? --- Làm vậy cần đáp ứng những chức năng gì?”
Do đó, điểm thảo luận tiếp theo thực chất là: Làm vậy, cụ thể triển khai sẽ vận hành ra sao trên các client khác nhau?
Vitalik đưa ra hai hướng, tức là chạy trên hệ thống đa client mở hoặc hệ thống đa client đóng.
-
Hệ thống mở: Phù hợp hơn với tinh thần phi tập trung và đổi mới của Ethereum, cho phép cộng đồng phát triển và áp dụng công nghệ chứng minh mới theo nhu cầu.
-
Hệ thống đóng: Có thể dễ quản lý và bảo trì hơn, nhưng có thể hạn chế khả năng thích nghi và tiềm năng đổi mới lâu dài của hệ thống.
Hơn nữa, ở phần sau Vitalik cũng nói đến tầm quan trọng của tốc độ trong việc làm ZK-EVM. Nếu ZK-EVM có thể tạo bằng chứng nhanh chóng, nó sẽ phù hợp hơn để tích hợp vào giao thức chính Ethereum, vì có thể đáp ứng tốt hơn nhu cầu hiệu suất mạng và kỳ vọng trải nghiệm người dùng.
Tuy nhiên, đạt được mục tiêu này cần vượt qua những thách thức kỹ thuật và kỹ sư lớn. Vitalik trong phần này đã làm rõ những thách thức đó và đề xuất các giải pháp và phương pháp khả thi.
ZK-EVM cụ thể sẽ được triển khai trên Ethereum như thế nào?
Vitalik cũng đưa ra các cách triển khai khả thi cho ZK-EVM.
Ông đề xuất một loại giao dịch mới — giao dịch tuyên bố ZK-EVM (ZKEVMClaimTransaction), cùng cách xử lý và xác minh các giao dịch này trong mạng Ethereum.
Do phần này quá kỹ thuật, người đọc không có nền tảng nên bỏ qua chi tiết. Chúng ta đi thẳng vào định hướng thiết kế và ý chính:
-
Giới thiệu loại container dùng để truyền tải các tuyên bố liên quan đến ZK-EVM trong mạng.
-
Ở tầng đồng thuận, đề xuất một quy tắc mới: Chỉ chấp nhận khối khi client nhìn thấy bằng chứng hợp lệ cho mỗi tuyên bố.
-
Người dùng trong bằng chứng ZK-EVM có thể thay thế client thực thi của họ, nhưng client thực thi vẫn được dùng để tạo bằng chứng, xây dựng khối, cũng như lưu trữ và đánh chỉ mục dữ liệu trên nút.
-
Các triển khai ZK-EVM khác nhau có thể có phương pháp chứng minh khác nhau, nhưng tất cả đều có thể xác minh và chấp nhận bằng chứng của nhau.
Ngoài ra, Vitalik trong phần này thảo luận về việc hỗ trợ “almost-EVMs” (các hệ thống gần giống với Máy ảo Ethereum), đây là một mục tiêu chức năng mong muốn của ZK-EVM.
Các hệ thống này tích hợp thêm các tính năng, có thể bao gồm hợp đồng tiền biên dịch mới, mã vận hành, tùy chọn viết hợp đồng (ví dụ như lựa chọn viết trên EVM chuẩn hoặc máy ảo hoàn toàn khác như Arbitrum Stylus), thậm chí hỗ trợ nhiều EVM song song với giao tiếp chéo đồng bộ.
Đồng thời, Vitalik Buterin thảo luận về việc hỗ trợ xác minh viên có trạng thái (stateful) bên trong ZK-EVM, và tại sao điều này có lợi:
Tại sao nên hỗ trợ xác minh viên có trạng thái?
-
Hiệu quả dữ liệu: Xác minh viên có trạng thái có thể cải thiện hiệu suất nén dữ liệu. Một hệ thống hoàn toàn vô trạng thái cần tất cả dữ liệu sẵn sàng trong mỗi giao dịch, dẫn đến dư thừa và lãng phí dữ liệu. Xác minh viên có trạng thái có thể lưu trữ thông tin trạng thái trước đó, giảm lượng dữ liệu phải truyền và xử lý.
-
Giảm dư thừa dữ liệu: Nếu một mảnh dữ liệu đã được cung cấp bởi khối hoặc giao dịch trước, thì trong các bằng chứng sau không cần cung cấp lại, vì nó đã là “đã biết”.
-
Hiệu suất hệ thống: Hệ thống có trạng thái cho phép tính toán và xác minh hiệu quả hơn, vì có thể tận dụng thông tin đã biết thay vì luôn bắt đầu từ đầu.
Còn về cách hỗ trợ, phần gốc chứa quá nhiều chi tiết kỹ thuật, khó phân tích sâu ở đây, chúng ta chỉ cần hiểu:
"Hỗ trợ xác minh viên có trạng thái" có nghĩa là giới thiệu một cơ chế vào ZK-EVM, cho phép hệ thống ghi nhớ và tận dụng trạng thái trước đó, thay vì hoàn toàn vô trạng thái trong mỗi thao tác. Điều này có thể nâng cao hiệu suất tổng thể, giảm lượng dữ liệu truyền tải, đồng thời cho phép tính toán hiệu quả hơn. Đây là một mở rộng trong thiết kế ZK-EVM, nhằm nâng cao tính khả thi và hiệu quả trong ứng dụng thực tế.
Khi đã tích hợp ZK-EVM, các L2 làm việc tương tự sẽ ra sao?
Cuối bài viết, Vitalik tạm rời khỏi cuộc thảo luận kỹ thuật nghiêm túc, chuyển sang suy nghĩ một vấn đề khác: Nếu ZK-EVM trở thành chức năng tích hợp sẵn ở Ethereum L1, vai trò của các L2 làm ZK sẽ thay đổi thế nào?
Theo hình dung của Vitalik, nếu thực sự làm vậy, L2 trong tương lai nhiều khả năng sẽ đảm nhận vai trò “phụ trợ”, phát huy vai trò bổ sung ở các khía cạnh sau:
-
Xác nhận nhanh: Tính dứt khoát trong một khe thời gian (single-slot finality) có thể làm chậm tốc độ xử lý ở Layer 1, trong khi các dự án Layer 2 có thể cung cấp dịch vụ xác nhận nhanh, được hỗ trợ bởi cơ chế bảo mật riêng của Layer 2, với độ trễ thấp hơn nhiều so với một khe thời gian. Đây sẽ tiếp tục là trách nhiệm riêng của Layer 2.
-
Chiến lược giảm thiểu Giá trị Khai thác Tối thiểu (MEV): Bao gồm mempool mã hóa, bộ sắp xếp dựa trên uy tín và các chức năng khác mà Layer 1 không muốn triển khai. Layer 2 có thể thực hiện các chiến lược này để giảm ảnh hưởng của MEV đến giao dịch người dùng.
-
Mở rộng EVM: Các dự án Layer 2 có thể giới thiệu những mở rộng lớn cho EVM, mang lại giá trị đáng kể cho người dùng. Bao gồm hỗ trợ các phiên bản “gần giống EVM” (almost-EVMs), hoặc phương pháp hoàn toàn khác như hỗ trợ WASM của Arbitrum Stylus và ngôn ngữ thân thiện với SNARK là Cairo.
-
Thuận tiện cho người dùng và nhà phát triển: Các đội ngũ Layer 2 thực hiện nhiều công việc thu hút người dùng và dự án tham gia hệ sinh thái của họ và tạo cảm giác chào đón; họ được thưởng bằng cách thu thập MEV và phí tắc nghẽn trong mạng. Ngay cả khi ZK-EVM được tích hợp vào giao thức Ethereum, mô hình này vẫn sẽ tiếp tục tồn tại.
Lưu ý, hiện tại đây chỉ là ý tưởng cá nhân của Vitalik, chưa được thực hiện chính thức.
Tuy nhiên, qua bài blog này, có thể thấy Vitalik đã suy nghĩ rất rõ ràng về mục đích, phương pháp, chức năng và tác động phụ của việc Ethereum tự làm ZK-EVM, rõ ràng không phải ý tưởng nhất thời.
Từ EVM, đến EVM hiệu suất cao hơn, rồi đến EVM tích hợp ZK, Vitalik với tư cách là nhà thiết kế Ethereum, đang làm cho tác phẩm của mình hoàn thiện theo từng bước tiến;
Dĩ nhiên, trong quá trình này ông chưa bao giờ loại trừ các ý tưởng từ các giải pháp L2 khác, nhưng dường như cũng chưa bao giờ từ bỏ việc cải thiện Ethereum theo cách bản địa.
Việc liệu ý tưởng bản địa ZK-EVM này có thực sự được thông qua hay không, còn phải đợi khi những suy nghĩ trong blog này trở thành đề xuất cụ thể mới biết được.
Tuy nhiên, điều chắc chắn là, khi đổi mới công nghệ đến gần, toàn bộ hệ sinh thái chắc chắn sẽ dậy sóng.
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
深潮TechFlow
