Hướng tới tương lai của Ethereum L1, lộ trình đa bằng chứng của Taiko
Tuyển chọn TechFlowTuyển chọn TechFlow
Hướng tới tương lai của Ethereum L1, lộ trình đa bằng chứng của Taiko
Taiko cho rằng bằng chứng đa tầng trong ZK có thể đặt nền móng cho sự đa dạng của các nút SNARKed trong Ethereum L1 tương lai.
Chuyên sâu báo cáo Web3Tác giả: Taiko
Biên dịch: Frank, Foresight News
Gần đây, chúng tôi đã chia sẻ một bài viết chi tiết nhan đề Tại sao multi-prover lại quan trọng, giải thích tầm quan trọng của đa chứng minh (Multi-Proofs) và đưa ra SGX như một trong những lựa chọn cho đa chứng minh.
Cảm hứng cho bài viết này đến từ buổi trò chuyện trên X Space giữa chúng tôi với Vitalik và bài viết tiếp theo của ông trên blog, trong đó phác thảo lộ trình tổng thể của Taiko về đa chứng minh: mối liên hệ với "cuối cùng của Ethereum", tầm nhìn của chúng tôi là gì và cách thức hiện thực hóa nó.
Chúng tôi cho rằng, đa chứng minh (multi-proof) trong ZK có thể được chuyển đổi thành sử dụng đa-SNARKs + đa-client, nghĩa là dùng nhiều loại chứng minh ZK-SNARK để kiểm chứng nhiều nút Ethereum khác nhau, điều này sẽ đặt nền móng cho sự đa dạng các nút SNARKed trong tương lai của L1 Ethereum.
Để đưa ra lý do đơn giản cho việc cần thiết phải có đa chứng minh, chúng ta nên nhắc tới hai điểm:
-
Đa chứng minh giúp phòng ngừa rủi ro và lỗ hổng từ việc triển khai nút và hệ thống chứng minh, do đó ngay cả khi một chứng minh bị phá vỡ, các chứng minh khác cũng khó có thể cho phép cùng một lỗ hổng bị khai thác;
-
"Cuối cùng của Ethereum" giả định sử dụng bằng chứng kiến thức không (ZK) để xác thực L1;
Tương tự như việc triển khai đa nút trong Ethereum, phương pháp này đã nhiều lần cứu mạng lưới khỏi sụp đổ, chứng minh rằng các khối L1 cần áp dụng phương pháp xác thực đa tầng. Đối với cả trường hợp ZK và không ZK, điều này đồng nghĩa với việc cần sử dụng nhiều nút và các hệ thống chứng minh khác nhau.
Hệ thống Multi-Client và Tương lai của L1
Như Vitalik mô tả trong bài viết What might an「enshrined ZK-EVM」look like?, có hai cách tiếp cận cho hệ thống Multi-Client: "mở" và "đóng".
-
Trong hệ thống Multi-Client đóng, một nhóm cố định các bằng chứng đã được biết trước trong giao thức và được đưa vào "danh sách trắng" để tạo ra chứng minh. Theo phân loại của Vitalik, tất cả các L2 ZK đều thuộc loại đóng vì chúng chỉ chấp nhận các chứng minh từ chính họ;
-
Trong hệ thống Multi-Client mở, các chứng minh được đặt "ngoài khối", từng nút riêng biệt sẽ xác minh chúng, và bất kỳ người dùng nào cũng có thể dùng bất kỳ nút nào họ muốn để xác thực khối;
Khi người dùng cần xác minh một khối cụ thể, cách đơn giản nhất là chạy lại nút tương ứng để thực thi lại khối đó, hoặc yêu cầu một Prover đáng tin cậy cấp bằng chứng hợp lệ. Nếu nhận được đủ số lượng bằng chứng phù hợp tiêu chuẩn "danh sách trắng", khối đó được coi là hợp lệ. Nhưng nếu không có bằng chứng ZKP nào đạt tiêu chuẩn "danh sách trắng", và chúng ta muốn tránh việc thực thi lại, thì nên dùng bằng chứng ZK nào?
Theo tầm nhìn của Vitalik, vấn đề này sẽ được giải quyết bên ngoài giao thức thông qua sự đồng thuận xã hội (hoặc kinh tế mật mã):
Ở tầng đồng thuận, chúng ta thêm một quy tắc xác minh: chỉ chấp nhận khối khi các nút thấy bằng chứng hợp lệ cho mọi thay đổi trạng thái trong khối. Bằng chứng này phải là một bằng chứng ZK-SNARK, chứng minh chuỗi transaction_and_witness_blobs là dãy tuần tự các cặp (Block, Witness), và việc thực thi khối dựa trên pre_state_root và Witness là hợp lệ (i), đồng thời đầu ra post_state_root đúng (ii). Về tiềm năng, các nút có thể chọn chờ đợi M-trong-N loại bằng chứng khác nhau.
Hãy tưởng tượng một Builder trung thực sở hữu một khối type-1 và muốn cung cấp tính hợp lệ; các lựa chọn ở lớp L2 đã bao gồm ví dụ như Polygon, ZkSync và Scroll.
Giả sử các ZK-EVM của họ đã phát triển đến mức type-1, uy tín tốt và đã được kiểm chứng thực tế, sau đó Builder sẽ chọn từ các hệ thống chứng minh sẵn có, còn những người xác minh khối của anh ta sẽ chạy phần mềm xác minh tương ứng, tốt nhất là tạo ra nhiều loại chứng minh khác nhau và tiến hành xác minh nhiều lần. Với cùng đặc tả L1, nếu có bất kỳ verifier nào không đồng ý, việc xác minh khối trở thành vấn đề đồng thuận, và hệ thống mở sẽ đạt được sự nhất trí thông qua đồng thuận.
Các hệ thống chứng minh sẽ giành được ảnh hưởng bằng cách thuyết phục người dùng tin tưởng chúng, chứ không phải bằng cách thuyết phục quá trình quản trị giao thức.
Theo lời Vitalik, điều này có nghĩa hệ sinh thái ZKP đang mở cửa để thị trường hóa trực tiếp. Nếu có động lực, các triển khai L2 hiện tại có thể tham gia cạnh tranh trong thị trường chứng minh L1.
Khả thi của Taiko trong Đa Chứng Minh
Trong giao thức Taiko, Proposer phải tìm một Prover để đề xuất khối, và Prover được chỉ định sẽ ký quỹ TKO như một khoản đảm bảo để đảm bảo bằng chứng họ cung cấp là hợp lệ. Giao thức Taiko không quy định cách Proposer tìm kiếm hay bồi thường cho Prover, do đó họ thậm chí có thể gặp mặt trực tiếp và thanh toán bằng tiền mặt.
Do đó, chuỗi cung ứng của chúng tôi vận hành như một thị trường tự do, nơi Proposer có thể chọn bất kỳ Prover nào họ muốn.
Ngoài lợi thế kinh tế, còn có một số đặc điểm kỹ thuật khiến Taiko trở thành lựa chọn lý tưởng cho hệ thống Multi-Client:
-
Taiko là một ZK-EVM type-1, mang lại hai lợi ích: thứ nhất, về đa dạng thực thi, các triển khai EVM hiện có (như Geth, Besu, Reth, v.v.) có thể được áp dụng trực tiếp lên L2; thứ hai, để kiểm nghiệm khả thi của thiết kế dựa trên L1, chúng ta cần một ZK-EVM chuẩn hóa để xác minh đa client mở, bởi vì các verifier cần đạt đồng thuận và xác minh kết quả dựa trên cùng một phép biến đổi. Trong trường hợp này, ZK-EVM type-1 sẽ là lựa chọn phù hợp nhất vì nó tuân thủ rõ ràng các đặc tả Ethereum. Về phần logic riêng của Rollup, Vitalik cũng đề cập cách hỗ trợ sửa đổi ZK-EVM thông qua các chức năng dựng sẵn (precompiles), và việc tận dụng các precompiles này là đủ để hỗ trợ thiết kế BBR (Based Booster Rollup) của Taiko;
-
Taiko công bố tính sẵn có dữ liệu (data availability) trên Ethereum, không giống một số L2 đang khám phá các tùy chọn DA thay thế. Miễn là dữ liệu được đăng lên L1, Taiko có thể dễ dàng thích nghi với đề xuất triển khai của Vitalik, trong đó giới thiệu ZKEVMClaimTransaction để bao gồm chuyển đổi trạng thái, bằng chứng và tính sẵn có dữ liệu;
Taiko hoạt động trên nhiều hệ thống chứng minh, mạng thử nghiệm hiện tại đã hỗ trợ ZK-EVM của PSE, SGX và Reth. Cơ sở hạ tầng được cấu hình để thích nghi với nhiều nút thực thi và hệ thống chứng minh, điều này sẽ được thảo luận trong phần cuối. Trên nền tảng cơ sở hạ tầng này, Taiko sẽ tập trung vào biên dịch mô-đun trong lĩnh vực bằng chứng kiến thức không.
Một Lộ Trình Mô-đun và Mở
Mô-đun
Trong bối cảnh bằng chứng kiến thức không (ZKP), xét đến Multi-Client, Taiko tận dụng bộ biên dịch hiện đại để có được các thành phần phổ quát như Risc-V hoặc WASM. Sau đó, các lệnh này được chuyển đổi thành biểu diễn số học cho nhiều hệ thống chứng minh khác nhau (AIR hoặc PIL), và cuối cùng sử dụng các SNARK khác nhau để mã hóa quỹ đạo thực thi số học.
Tóm lại, quy trình này là phương pháp khả thi nhất trong hệ thống đa chứng minh, vì nó tận dụng tối đa ưu thế từ cả hai phía. Trong quá trình biên dịch nút, bộ biên dịch hiện đại mang lại những lợi ích sau:
-
Việc nâng cấp nút độc lập với việc chứng minh, vì không cần triển khai mạch cho các EIP mới nhất hay hard fork, chỉ cần cập nhật mã nguồn;
-
Miễn phí nhận được các tối ưu hóa mã từ các công cụ như LLVM;
-
Biên dịch chéo tạo ra sự đa dạng hơn; lấy ví dụ trên, Taiko có Geth hoặc Reth được biên dịch sang tập lệnh RISC-V hoặc WASM, đã có sẵn bốn hệ thống chứng minh;
Biên dịch SNARKs là trọng tâm phát triển tương lai của Taiko. Lưu ý rằng, khi chuyển đổi từ các phương pháp số học như PLONK và R1CS sang mã hóa ở backend như Halo2, eSTARK hay Supernova, không bị giới hạn ở một giao thức ZK duy nhất; trong khi các ZK-VM/EVM nguyên khối lại được triển khai backend cho ZKP cụ thể. Khi ngày càng nhiều dự án sử dụng thành phần của nhau để cải thiện hiệu suất, toàn bộ stack có thể trở nên mô-đun.
Do lĩnh vực nghiên cứu ZKP phát triển rất nhanh, tính linh hoạt quan trọng hơn nhiều so với việc triển khai trực tiếp các kết quả mới nhất. Để duy trì tính linh hoạt, Taiko đang hợp tác với các dự án như Powdr Labs và Risc Zero để xây dựng đường ống biên dịch chéo và hướng tới mô-đun hóa tối đa.
Đối với độc giả am hiểu kỹ thuật, xin tham khảo các lợi ích cụ thể sau:
-
Chúng tôi có thể tối ưu bộ biên dịch nhằm hướng tới các mục tiêu backend khác nhau, ví dụ như ưu tiên cổng bậc cao (high-degree gates) hoặc sử dụng nhiều tham số tra cứu hơn;
-
Các mạch tăng tốc như hàm băm Keccak và Poseidon có thể được triển khai như thư viện;
-
Chúng tôi có thể từng bước thêm các chức năng ZK (như LogUp) vào ngôn ngữ và kích hoạt hỗ trợ backend tương ứng;
-
Tích hợp các framework backend ZK mới để tăng tốc độ; trong một số dự án ZK định hướng nghiên cứu, chỉ có bản chứng minh khái niệm được phát triển dưới dạng mã, khiến chúng khó sử dụng trong môi trường sản xuất. Bằng cách để bộ biên dịch đảm nhiệm phần việc nặng, chúng tôi có thể dễ dàng áp dụng các framework ở giai đoạn sớm;
-
Các mạch backend hiện có, ví dụ như các thành phần PSE ZK-EVM viết bằng Halo2, vẫn có thể được tái sử dụng bằng cách gọi trực tiếp;
Thông qua nỗ lực hợp tác, Taiko đã tích hợp zeth và ZK-VM của Risc Zero trong quá trình phát triển, đồng thời phát triển thêm backend SGX. Các kỹ sư Taiko cũng sẽ tích hợp Powdr vào hệ thống đa chứng minh, phát triển ngôn ngữ và thư viện PIL, tối ưu biên dịch, bổ sung nhiều backend hơn và xử lý các tăng tốc cấp thấp nói chung. Ở tầng phần cứng, tầng tăng tốc kiến thức không (ZAL) của Taiko nhằm chuẩn hóa mối quan hệ cộng tác giữa các hệ thống chứng minh (Halo2, Arkworks, Risc Zero, Polygon, v.v.) và các thư viện tăng tốc (CPU, GPU, FPGA, v.v.).
Tính Mở
Càng nhiều nút, hệ thống chứng minh và backend được tích hợp, tính mở càng cao. Vì vậy, Taiko nỗ lực tập hợp toàn bộ cộng đồng lại với nhau. Đội ngũ Taiko có lịch sử hợp tác lâu dài với các dự án khác, ví dụ như hợp tác với PSE trong các dự án ZK-EVM và Risc Zero.
Bây giờ, bằng cách xây dựng một stack ZK mô-đun hơn, Taiko có thể hiệu quả trừu tượng hóa API để phổ biến và tích hợp tốt hơn. Taiko sẽ hoạt động như một nền tảng, vận chuyển các hệ thống chứng minh vào sản xuất và kiểm tra thực tế trên chuỗi. Taiko chân thành mời tất cả các dự án tham gia cùng chúng tôi xây dựng công nghệ kiến thức không tốt hơn.
Taiko Stack
Một cơ sở hạ tầng linh hoạt và có thể mở rộng là cực kỳ quan trọng đối với mô hình đa chứng minh của Taiko.
Nguồn gốc của bằng chứng hợp lệ ZK là nhật ký trạng thái (Execution Trace) từ các nút và bằng chứng lưu trữ (Storage Proofs), dùng để xây dựng dữ liệu chứng cứ (witnesses) và đầu vào công khai. Cần lưu ý rằng, witnesses phụ thuộc vào từng loại chứng minh, trong khi đầu vào công khai liên quan đến giao thức. Việc sở hữu cơ sở hạ tầng mạnh để xử lý việc tạo witnesses là rất quan trọng. Do đó, chúng tôi sử dụng một máy chủ nhẹ để thu thập nhật ký trạng thái từ Multi-Client và chuyển đổi thành nhiều loại witness cung cấp cho các hệ thống chứng minh tương ứng.
Ở phía chứng minh, thiết kế này hỗ trợ cả stack mô-đun và stack nguyên khối, đồng thời chúng tôi trích xuất đầu vào công khai giống nhau từ nút mục tiêu (hiện tại là Geth).
Trong tương lai, nếu định dạng nhật ký trạng thái tương thích, Geth với tư cách nút Taiko có thể được thay thế bằng nút khác. Ngoài ra, nút nhẹ chạy trên hệ thống chứng minh (hiện tại là Reth) cũng có thể được thay thế bằng bất kỳ triển khai nào có thể biên dịch sang ngôn ngữ assembly.
Các điểm chính
-
Taiko tin rằng đa chứng minh = Multi-Client + đa SNARKs (và các TEE như SGX);
-
Giao thức Taiko rất phù hợp với hệ thống Multi-Client nhờ chuỗi cung ứng đa chứng minh mở, thực thi type-1 và công bố tính sẵn có dữ liệu trên L1;
-
Taiko hình dung một kiến trúc đa chứng minh mô-đun và mở, hợp tác với Powdr Labs để tận dụng biên dịch chéo giữa nút và ZKP, hợp tác với Risc Zero để triển khai thực thi Taiko trên ZK-VM và TEE của họ, đồng thời tiếp tục nỗ lực cùng PSE cải tiến dự án ZK-EVM;
-
Cơ sở hạ tầng linh hoạt của Taiko bao gồm cả stack ZKP mô-đun và nguyên khối;
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
@taikoxyz
