Vitalik: Triết lý đa khách hàng của Ethereum sẽ tương tác với ZK-EVM như thế nào?

Tiêu đề gốc: "Triết lý đa khách hàng của Ethereum sẽ tương tác với ZK-EVM như thế nào? 》

Tác giả gốc: Vitalik

Bản tổng hợp gốc: Marsbit

Một điều chưa được thảo luận nhiều nhưng rất quan trọng Cách thức Ethereum duy trì tính bảo mật và phân cấp là triết lý đa khách hàng của nó. Ethereum cố tình không có "máy khách tham chiếu" mà mọi người chạy theo mặc định: thay vào đó, có một đặc tả được quản lý cộng tác (hiện được viết bằng Python rất dễ đọc nhưng rất chậm) và nhiều nhóm đang làm việc trên nó. được gọi là "máy khách") là những gì người dùng thực sự chạy.

Mỗi nút Ethereum Chạy một khách hàng đồng thuận và khách hàng thực thi. Tính đến thời điểm hiện tại, không có khách hàng đồng thuận hoặc thực thi nào chiếm hơn 2/3 mạng lưới. Nếu thị phần của khách hàng trong danh mục của nó nhỏ hơn 1/3, mạng sẽ tiếp tục hoạt động bình thường. Nếu khách hàng có 1/3 đến 2/3 thị phần trong danh mục của nó (chẳng hạn như Prysm, Lighthouse hoặc Geth) gặp lỗi, chuỗi sẽ tiếp tục thêm các khối nhưng sẽ ngừng hoàn thành chúng, giúp các nhà phát triển có thời gian can thiệp.

Một sự thay đổi lớn sắp tới chưa được thảo luận nhưng vẫn rất quan trọng trong cách xác minh chuỗi Ethereum là sự nổi lên của ZK-EVM. SNARK chứng minh khả năng thực thi EVM đã được phát triển trong nhiều năm và công nghệ này được giao thức L2 có tên là ZK rollup sử dụng tích cực. Một số bản tổng hợp ZK này hiện đang hoạt động trên mạng chính và nhiều bản tổng hợp khác sẽ sớm được ra mắt. Nhưng về lâu dài, ZK-EVM sẽ không chỉ được sử dụng cho các bản tổng hợp mà chúng tôi còn muốn sử dụng chúng để xác minh việc thực thi L1 (Tham khảo: the Verge).

Một khi điều này xảy ra, ZK-EVM sẽ trở thành loại máy khách Ethereum thứ ba một cách hiệu quả, quan trọng đối với an ninh mạng như ngày nay. Máy khách thực thi cũng quan trọng như khách hàng đồng thuận. Điều này đương nhiên đặt ra câu hỏi: ZK-EVM sẽ tương tác với nhiều khách hàng như thế nào?

Một trong những phần khó khăn đã hoàn thành: chúng tôi đã có nhiều triển khai ZK-EVM đang được phát triển tích cực. Nhưng những khó khăn khác vẫn còn đó: Làm cách nào để tạo ra một hệ sinh thái “nhiều khách hàng” cho ZK để chứng minh tính đúng đắn của các khối Ethereum? Vấn đề này đặt ra một số thách thức kỹ thuật thú vị – và tất nhiên là câu hỏi đặt ra là liệu sự đánh đổi này có xứng đáng hay không.

Động lực ban đầu cho ý tưởng đa khách hàng Ethereum là gì?

Khái niệm đa khách hàng của Ethereum là một loại phân cấp. Cũng giống như phân cấp chung, mọi người có thể chú ý đến lợi ích kỹ thuật của phân cấp kiến trúc. , bạn cũng có thể tập trung về lợi ích xã hội của việc phân cấp chính trị. Cuối cùng, ý tưởng về nhiều khách hàng được thúc đẩy và dành cho cả hai.

Lý do phân cấp công nghệ

Lợi ích chính của phân cấp công nghệ rất đơn giản: Nó làm giảm sự nguy cơ xảy ra lỗi trong một phần mềm gây ra sự sụp đổ thảm khốc của toàn bộ mạng. Lỗ hổng tràn Bitcoin năm 2010 là một ví dụ điển hình cho rủi ro này. Vào thời điểm đó, mã máy khách Bitcoin không kiểm tra xem tổng đầu ra giao dịch có bị tràn hay không (bằng cách tính tổng số nguyên tối đa 264-1, đưa nó về 0), vì vậy ai đó đã thực hiện một giao dịch và tự kiếm cho mình hàng tỷ Bitcoin.

Lỗ hổng được phát hiện trong vòng vài giờ và bản sửa lỗi nhanh chóng được hoàn thành và nhanh chóng triển khai trên toàn bộ mạng, nhưng nếu có hệ sinh thái Trưởng thành, những đồng tiền này sẽ được chấp nhận bởi các sàn giao dịch, cây cầu và các công trình kiến trúc khác, và những kẻ tấn công có thể đã bỏ đi với rất nhiều tiền. Nếu có năm ứng dụng khách Bitcoin khác nhau, không chắc tất cả chúng đều có cùng một lỗi và do đó sẽ phân tách ngay lập tức, và phía phân nhánh có lỗi có khả năng sẽ thất bại.

Việc sử dụng phương pháp tiếp cận nhiều khách hàng để giảm thiểu rủi ro xảy ra lỗi nghiêm trọng sẽ phải trả giá: thay vào đó, bạn sẽ gặp phải lỗi không đồng thuận. Điều đó nói lên rằng, nếu bạn có hai khách hàng, có nguy cơ là các khách hàng sẽ có những cách hiểu khác nhau một cách tinh vi về các quy tắc giao thức nhất định và mặc dù cả hai cách giải thích đều hợp lý và không cho phép ăn cắp tiền, nhưng sự bất đồng sẽ khiến chuỗi bị chia đôi . Kiểu phân nhánh nghiêm trọng này đã xảy ra một lần trong lịch sử của Ethereum (đã có những đợt phân chia nhỏ hơn khác trong đó một phần rất nhỏ của mạng chạy phiên bản mã cũ hơn đã được phân nhánh).

Những người bảo vệ cách tiếp cận một khách hàng cho rằng sự thất bại trong sự đồng thuận là lý do không nên sử dụng triển khai nhiều khách hàng: nếu chỉ có một khách hàng thì khách hàng này sẽ có không được bất đồng. Mô hình của họ về cách số lượng khách hàng chuyển thành rủi ro có thể trông như thế này:

Tất nhiên, tôi không đồng ý với phân tích này. Điều quan trọng mà tôi không đồng ý là (i) vấn đề nghiêm trọng về các lỗi nghiêm trọng kiểu năm 2010 và (ii) bạn thực sự không bao giờ chỉ có một khách hàng. Điểm thứ hai được thể hiện rõ nhất trong đợt fork Bitcoin năm 2013: sự phân chia chuỗi do sự bất đồng giữa hai phiên bản khác nhau của ứng dụng khách Bitcoin, một trong số đó bất ngờ hạn chế quyền truy cập vào một khối duy nhất.

Do đó, một khách hàng lý thuyết thường thực sự là hai khách hàng, và năm khách hàng lý thuyết thực tế có thể là sáu hoặc bảy khách hàng. về phía bên phải của đường cong rủi ro, với ít nhất một vài khách hàng khác nhau.

Lý do chính trị cho việc phân cấp

Các nhà phát triển khách hàng độc quyền đang ở vị trí quyền lực chính trị to lớn. Nếu nhà phát triển ứng dụng khách đề xuất thay đổi và người dùng không đồng ý, về mặt lý thuyết, họ có thể từ chối tải xuống phiên bản cập nhật hoặc tạo một nhánh mà không có phiên bản cập nhật đó, nhưng trên thực tế, người dùng thường khó thực hiện điều này. Điều gì sẽ xảy ra nếu một thay đổi giao thức không đạt yêu cầu đi kèm với bản cập nhật bảo mật cần thiết? Điều gì sẽ xảy ra nếu đội ngũ chính đe dọa sẽ nghỉ việc nếu mọi việc không như ý muốn?

Hoặc đơn giản hơn, nếu nhóm khách hàng độc quyền trở thành nhóm duy nhất có kiến thức chuyên môn về giao thức tốt nhất, hãy để phần còn lại của hệ sinh thái đánh giá khách hàng Điều gì sẽ xảy ra nếu các lập luận kỹ thuật mà nhóm đưa ra đang gặp bất lợi, khiến nhóm khách hàng mất nhiều thời gian để thúc đẩy các mục tiêu và giá trị cụ thể của riêng họ có thể không phù hợp với cộng đồng rộng lớn hơn?

Mối quan ngại về chính trị giao thức, đặc biệt là trong bối cảnh cuộc chiến OP_RETURN Bitcoin năm 2013-2014, trong đó một số người tham gia công khai phản đối việc sử dụng cụ thể của chuỗi khối, Đây là một yếu tố quan trọng trong việc Ethereum sớm áp dụng triết lý đa khách hàng, nhằm mục đích khiến những quyết định như vậy trở nên khó khăn hơn đối với một nhóm nhỏ người. Những mối quan tâm cụ thể đối với hệ sinh thái Ethereum—cụ thể là tránh sự tập trung quyền lực trong chính Ethereum Foundation—cung cấp thêm sự hỗ trợ cho hướng đi này. Vào năm 2018, tổ chức đã đưa ra quyết định cố tình không triển khai giao thức Ethereum PoS (hiện được gọi là “ứng dụng khách đồng thuận”), giao nhiệm vụ hoàn toàn cho một nhóm bên ngoài.

ZK-EVM sẽ bước vào Lớp 1 trong tương lai như thế nào?

Ngày nay, ZK-EVM được sử dụng cho Rollup. Điều này làm tăng khả năng mở rộng bằng cách cho phép các lần thực thi EVM đắt tiền chỉ diễn ra ngoài chuỗi một vài lần, trong khi những người khác có thể chứng minh tính chính xác của các tính toán do EVM thực hiện bằng cách chỉ cần xác minh SNARK được phát hành trên chuỗi. Nó cũng cho phép một số dữ liệu (đặc biệt là chữ ký) không được đưa vào chuỗi, do đó tiết kiệm chi phí gas. Điều này mang lại cho chúng tôi rất nhiều lợi ích về khả năng mở rộng và việc kết hợp khả năng điện toán có thể mở rộng với ZK-EVM cũng như dữ liệu có thể mở rộng với việc lấy mẫu tính khả dụng của dữ liệu cho phép chúng tôi mở rộng quy mô hơn nữa.

Tuy nhiên, mạng Ethereum ngày nay cũng có một vấn đề khác, một vấn đề mà không có sự mở rộng Lớp 2 nào có thể tự giải quyết: Lớp 1 rất khó xác minh, để không có bao nhiêu người dùng chạy các nút của riêng họ. Thay vào đó, hầu hết người dùng chỉ tin tưởng các nhà cung cấp bên thứ ba. Các máy khách nhẹ như Helios và Succinct đang thực hiện các bước để giải quyết vấn đề này, nhưng máy khách nhẹ còn lâu mới có được nút xác thực đầy đủ: máy khách nhẹ chỉ cần xác minh chữ ký của một tập hợp con ngẫu nhiên các trình xác thực được gọi là ủy ban đồng bộ hóa mà không cần xác thực xem chuỗi có thực sự hay không tuân theo các quy tắc giao thức. Để người dùng thực sự xác minh rằng chuỗi tuân theo các quy tắc, chúng tôi phải làm điều gì đó khác biệt.

Phương án 1: Nén Lớp 1, buộc hầu hết mọi hoạt động chuyển sang Lớp 2

Theo thời gian, chúng tôi có thể hạ mục tiêu gas Lớp 1 trên mỗi khối từ 15 triệu xuống 1 triệu, đủ để một khối chứa một SNARK duy nhất và một số hoạt động gửi và rút tiền, nhưng không nhiều hoạt động khác. Điều này buộc hầu hết mọi hoạt động của người dùng để chuyển sang giao thức Lớp 2. Thiết kế như vậy vẫn có thể hỗ trợ gửi nhiều bản cuộn cho mỗi khối: chúng tôi có thể sử dụng giao thức tổng hợp ngoài chuỗi do trình tạo tùy chỉnh điều hành để thu thập SNARK từ nhiều giao thức Lớp 2 và kết hợp chúng thành một SNARK duy nhất. Trong thế giới như vậy, chức năng duy nhất của Lớp 1 là trở thành cơ quan thanh toán bù trừ cho các giao thức Lớp 2, xác thực bằng chứng của chúng và đôi khi tạo điều kiện thuận lợi cho việc chuyển tiền quy mô lớn giữa chúng.

Cách tiếp cận này khả thi nhưng có một số điểm yếu quan trọng:

• Nó thực sự không tương thích ngược vì nhiều ứng dụng dựa trên L1 hiện có đã trở nên không khả thi về mặt kinh tế. Số tiền của người dùng lên tới hàng trăm hoặc hàng nghìn đô la có thể bị mắc kẹt do phí trở nên quá cao, vượt quá chi phí để xóa các tài khoản này. Vấn đề này có thể được giải quyết bằng cách cho phép người dùng ký một thông báo để chọn tham gia di chuyển hàng loạt sang L2 mà họ lựa chọn trong giao thức (xem một số ý tưởng triển khai ban đầu tại đây), nhưng điều này làm tăng thêm độ phức tạp cho quá trình chuyển đổi và khiến nó thực sự đủ rẻ dù sao thì cũng cần phải có một số loại SNARK ở Lớp 1. Tôi thường muốn phá vỡ khả năng tương thích ngược khi nói đến những thứ như opcode SELFDESTRUCT, nhưng trong trường hợp này sự đánh đổi có vẻ kém thuận lợi hơn.

→Nó có thể vẫn chưa khiến việc xác minh trở nên đủ rẻ. Lý tưởng nhất là giao thức Ethereum phải dễ xác minh, không chỉ trên máy tính xách tay mà còn trên điện thoại di động, tiện ích mở rộng trình duyệt và thậm chí trong các chuỗi khác. Việc đồng bộ hóa chuỗi lần đầu tiên hoặc sau khi ngoại tuyến trong một thời gian dài cũng sẽ dễ dàng. Nút máy tính xách tay có thể xác thực 1 triệu gas trong khoảng 20 mili giây, nhưng ngay cả điều đó cũng có nghĩa là sẽ mất 54 giây để đồng bộ hóa sau một ngày ngoại tuyến (giả sử kết quả cuối cùng cho một khe duy nhất sẽ tăng thời gian của khe lên 32 giây) và đối với một điện thoại hoặc trình duyệt, mỗi khối mất vài trăm mili giây và có lẽ vẫn gây hao pin không đáng kể. Những con số này có thể quản lý được, nhưng không lý tưởng.

Ngay cả trong hệ sinh thái L2 đầu tiên, L1 ít nhất cũng có giá cả phải chăng. Validium có thể được hưởng lợi từ mô hình bảo mật mạnh mẽ hơn nếu người dùng có thể rút tiền khi họ nhận thấy rằng dữ liệu trạng thái mới không còn nữa. Nếu kích thước tối thiểu cho một giao dịch chuyển tiền trực tiếp khả thi về mặt kinh tế trên L2 nhỏ hơn thì hoạt động chênh lệch giá sẽ trở nên hiệu quả hơn, đặc biệt đối với các token nhỏ hơn.

Vì vậy, có vẻ hợp lý hơn khi cố gắng tìm cách sử dụng ZK-SNARK để xác minh chính Lớp 1.

Tùy chọn 2: SNARK – Lớp xác minh 1

Loại 1 (hoàn toàn tương đương với Ethereum) ZK-EVM có thể được sử dụng để xác minh việc thực thi EVM (Lớp 1) của các khối Ethereum. Chúng ta có thể viết thêm mã SNARK để xác minh mặt đồng thuận của khối. Đây sẽ là một vấn đề kỹ thuật đầy thách thức: ngày nay, ZK-EVM mất vài phút đến hàng giờ để xác minh các khối Ethereum và việc tạo bằng chứng trong thời gian thực sẽ yêu cầu một hoặc nhiều (i) cải tiến đối với chính Ethereum để loại bỏ các thành phần không thân thiện với SNARK, (ii) đạt được hiệu quả lớn thông qua phần cứng chuyên dụng và (iii) cải tiến kiến trúc với khả năng song song hơn. Tuy nhiên, không có lý do kỹ thuật cơ bản nào khiến điều này không thể thực hiện được - vì vậy tôi kỳ vọng rằng điều đó sẽ xảy ra, ngay cả khi phải mất nhiều năm.

Ở đây chúng ta thấy điểm giao nhau với mô hình nhiều khách hàng: nếu chúng ta sử dụng ZK-EVM để xác thực Lớp 1 thì chúng ta sẽ sử dụng ZK-EVM nào?

Tôi có ba lựa chọn:

1. ZK-EVM đơn: từ bỏ nhiều khách hàng Ví dụ: chọn một ZK-EVM duy nhất để xác minh khối.

2. Đóng nhiều ZK-EVM: Đạt được sự đồng thuận về một tập hợp nhiều ZK-EVM cụ thể và niêm phong chúng trong quy tắc giao thức lớp đồng thuận, một khối yêu cầu bằng chứng của hơn một nửa số ZK-EVM trong bộ này mới được coi là hợp lệ.

3. Mở cho nhiều ZK-EVM: Các máy khách khác nhau có cách triển khai ZK-EVM khác nhau. Mỗi máy khách chờ đợi với Bằng chứng cho thấy việc triển khai của riêng bạn tương thích.

Đối với tôi, (3) có vẻ lý tưởng, ít nhất là cho đến khi công nghệ của chúng tôi tiến bộ đến mức chúng tôi có thể chính thức chứng minh rằng tất cả việc triển khai ZK-EVM đều tương đương với từng khác Trước đây, chúng ta có thể chọn cái hiệu quả nhất. (1) sẽ hy sinh lợi ích của mô hình nhiều khách hàng, (2) sẽ đóng khả năng phát triển khách hàng mới và dẫn đến một hệ sinh thái tập trung hơn. (3) Có những thách thức, nhưng chúng có vẻ ít thách thức hơn hai lựa chọn còn lại, ít nhất là ở thời điểm hiện tại.

Việc thực hiện (3) không quá khó: mỗi loại bằng chứng đều có mạng con p2p, khách hàng sử dụng một loại bằng chứng sẽ ở trong The tương ứng. mạng con lắng nghe và đợi cho đến khi họ nhận được bằng chứng mà người xác thực cho là hợp lệ.

Hai thách thức chính của (3) có thể như sau:

***Thách thức về độ trễ: Kẻ tấn công độc hại có thể trì hoãn việc xuất bản các khối và bằng chứng hợp lệ cho khách hàng. Việc tạo bằng chứng hợp lệ cho các ứng dụng khách khác thực sự mất nhiều thời gian (ngay cả khi chẳng hạn là 15 giây). Khoảng thời gian này đủ dài để có khả năng tạo ra một nhánh tạm thời và phá vỡ chuỗi cho một số vị trí.

Dữ liệu kém hiệu quả: Một lợi ích của ZK-SNARK là chỉ có dữ liệu liên quan đến việc xác minh (đôi khi được gọi là "dữ liệu nhân chứng" ”) có thể được loại bỏ khỏi khối. Ví dụ: khi chữ ký được xác minh, không cần lưu trữ chữ ký trong khối, chỉ cần lưu trữ một bit chỉ ra rằng chữ ký hợp lệ và lưu trữ bằng chứng trong khối để xác nhận rằng tất cả các chữ ký hợp lệ đều có mặt. Tuy nhiên, nếu chúng ta muốn tạo ra nhiều loại bằng chứng cho một khối thì chữ ký gốc cần phải được xuất bản trên thực tế.

Vấn đề về độ trễ có thể được giải quyết bằng cách xử lý cẩn thận khi thiết kế các giao thức đầu cuối một khe. Giao thức cuối cùng một khe có thể yêu cầu nhiều hơn hai vòng đồng thuận cho mỗi khe, do đó, vòng đầu tiên có thể được yêu cầu bao gồm các khối và chỉ yêu cầu các nút xác minh bằng chứng trước khi đăng nhập vào vòng thứ ba (hoặc cuối cùng). Điều này đảm bảo rằng luôn có một khoảng thời gian đáng kể giữa thời hạn xuất bản một khối và thời điểm dự kiến có bằng chứng.

Các vấn đề về hiệu quả dữ liệu phải được giải quyết bằng cách sử dụng các giao thức riêng biệt cho dữ liệu liên quan đến tổng hợp và xác thực. Đối với chữ ký, chúng tôi có thể sử dụng tính năng tổng hợp BLS đã được ERC-4337 hỗ trợ. Một loại dữ liệu chính khác liên quan đến xác minh là ZK-SNARK dành cho quyền riêng tư. May mắn thay, các giao thức này thường có giao thức tổng hợp riêng.

Điều đáng nói là Lớp 1 xác minh SNARK cũng có một lợi ích quan trọng: việc thực thi EVM trên chuỗi không còn yêu cầu xác minh bởi từng nút, điều này khiến EVM trở thành số số vụ hành quyết có thể tăng lên rất nhiều. Điều này có thể đạt được bằng cách tăng đáng kể giới hạn gas Lớp 1 hoặc giới thiệu các bản tổng hợp được lưu giữ hoặc cả hai.

Kết luận

Để hệ sinh thái ZK-EVM mở nhiều khách hàng hoạt động tốt, điều này đòi hỏi rất nhiều công việc. Nhưng tin thực sự tốt là phần lớn công việc đang được tiến hành hoặc sắp bắt đầu:

Chúng tôi đã có nhiều triển khai ZK-EVM mạnh mẽ. Những triển khai này chưa phải là Loại 1 (hoàn toàn tương đương với Ethereum), nhưng nhiều trong số chúng đang tích cực đi theo hướng này.

rent Hoạt động trên các ứng dụng khách nhẹ như Helios và Succinct cuối cùng có thể trở thành xác minh SNARK hoàn chỉnh hơn về mặt đồng thuận PoS của chuỗi Ethereum.

• Khách hàng có thể bắt đầu dùng thử ZK-EVM để chứng minh khả năng thực thi của các khối Ethereum, đặc biệt khi chúng tôi có các máy khách không trạng thái không cần thiết về mặt kỹ thuật. Trực tiếp thực thi lại từng khối để duy trì trạng thái. Chúng tôi có thể sẽ chuyển từ khách hàng xác thực khối Ethereum bằng cách thực thi lại sang phần lớn khách hàng xác thực khối Ethereum bằng cách kiểm tra bằng chứng SNARK, đây sẽ là một quá trình chuyển đổi chậm và dần dần.

• Hệ sinh thái ERC-4337 và PBS có thể sớm bắt đầu sử dụng các kỹ thuật tổng hợp như BLS và tổng hợp bằng chứng để tiết kiệm chi phí gas. Công việc tổng hợp BLS đã bắt đầu.

Với những công nghệ này, tương lai sẽ rất tươi sáng. Các khối Ethereum sẽ nhỏ hơn ngày nay và bất kỳ ai cũng có thể chạy một nút được xác minh đầy đủ trên máy tính xách tay hoặc thậm chí là điện thoại của họ hoặc trong tiện ích mở rộng trình duyệt, tất cả đều đồng thời duy trì triết lý đa khách hàng của Ethereum.

Về lâu dài, tất nhiên điều gì cũng có thể xảy ra. Có lẽ AI sẽ tăng cường xác minh chính thức để có thể dễ dàng chứng minh rằng việc triển khai ZK-EVM là tương đương và xác định tất cả các lỗi dẫn đến sự khác biệt giữa chúng. Một dự án như vậy thậm chí có thể là điều gì đó để bắt đầu thực hiện ngay bây giờ. Nếu cách tiếp cận dựa trên xác minh chính thức này thành công, các cơ chế khác nhau sẽ cần được áp dụng để đảm bảo việc thực hiện Nghị định thư được phân cấp liên tục về mặt chính trị. Có lẽ đến lúc đó, giao thức sẽ được coi là “hoàn thiện” và chuẩn mực bất biến sẽ mạnh mẽ hơn. Nhưng ngay cả khi đây là tương lai lâu dài, thế giới ZK-EVM đa khách hàng mở dường như là một bước đệm tự nhiên có thể xảy ra.

Trước mắt, đây vẫn là một chặng đường dài. ZK-EVM đã có mặt ở đây, nhưng để ZK-EVM thực sự khả thi ở Lớp 1, chúng cần trở thành Loại 1 và chứng minh đủ nhanh rằng điều đó có thể xảy ra trong thời gian thực. Với đủ khả năng song song hóa, điều này là khả thi, nhưng vẫn cần rất nhiều công sức để đạt được điều đó. Những thay đổi đồng thuận như tăng chi phí gas biên dịch trước của KECCAK, SHA256 và các hàm băm khác cũng sẽ là một phần quan trọng của bức tranh.

Điều đó nói lên rằng, bước đầu tiên của quá trình chuyển đổi có thể diễn ra nhanh hơn chúng ta mong đợi: một khi chúng ta chuyển sang cây Verkle và các máy khách không trạng thái, các máy khách có thể bắt đầu sử dụng dần dần ZK-EVM và quá trình chuyển đổi sang thế giới "đa ZK-EVM mở" có thể tự bắt đầu.

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