Một cách chưa được thảo luận nhiều nhưng vẫn rất quan trọng để 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ố ý 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 (ngày nay được viết bằng Python rất dễ đọc nhưng rất chậm) và có nhiều nhóm đang triển khai thông số kỹ thuật đó (cũng được gọi là “khách hàng”), đó là những gì người dùng thực sự chạy.

Mỗi nút Ethereum chạy một ứng dụng khách đồng thuận và một ứng dụng khách thực thi. Tính đến hôm nay, không có ứng dụng khách đồng thuận hoặc thực thi nào chiếm hơn 2/3 mạng lưới. Nếu một khách hàng có ít hơn 1/3 thị phần trong danh mục của nó gặp lỗi, mạng sẽ tiếp tục hoạt động bình thường. Nếu một khách hàng có từ 1/3 đến 2/3 chia sẻ trong danh mục của 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 nó sẽ ngừng hoàn thiện các khối, dành thời gian cho các nhà phát triển can thiệp.

Một bước chuyển đổi quan trọng sắp tới chưa được thảo luận nhưng vẫn rất quan trọng trong cách chuỗi Ethereum được xác thực 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 đang được sử dụng tích cực bởi các giao thức lớp 2 có tên là ZK rollups. 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à sẽ sớm có thêm nhiều bản khác . Nhưng về lâu dài, ZK-EVM không chỉ dành cho các bản tổng hợp; chúng tôi cũng muốn sử dụng chúng để xác minh việc thực thi trên lớp 1 (xem thêm: Verge).

Khi điều đó xảy ra, trên thực tế, ZK-EVM sẽ trở thành loại máy khách Ethereum thứ ba, cũng quan trọng đối với tính bảo mật của mạng như các máy khách thực thi và máy khách đồng thuận ngày nay. Và điều này đương nhiên đặt ra một câu hỏi: ZK-EVM sẽ tương tác như thế nào với triết lý đa khách hàng? Một trong những phần khó khăn đã được hoàn thành: chúng tôi đã có nhiều triển khai ZK-EVM đang được tích cực phát triển. Nhưng những phần khó khăn khác vẫn còn đó: làm thế nào chúng ta thực sự có thể tạo ra một hệ sinh thái “nhiều khách hàng” để chứng minh tính đúng đắn của các khối Ethereum trong việc chứng minh ZK? Câu hỏi này mở ra một số thách thức kỹ thuật thú vị - và tất nhiên là câu hỏi lờ mờ là liệu sự đánh đổi có xứng đáng hay không.

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

Triết lý đa khách hàng của Ethereum là một kiểu phân cấp và giống như <a href="https://medium.com/@VitalikButerin/the-mean-of-decentralization-a0c92b76a274"> phân cấp nói chung, người ta có thể tập trung vào một trong hai lợi ích kỹ thuật của việc phân cấp kiến trúc hoặc lợi ích xã hội của việc phân cấp chính trị. Cuối cùng, triết lý đa khách hàng được thúc đẩy bởi cả hai và phục vụ cả hai.

Các lập luận cho sự phân cấp kỹ thuật

Lợi ích chính của phân cấp kỹ thuật rất đơn giản: nó làm giảm nguy cơ một lỗi trong một phần mềm dẫn đến sự cố nghiêm trọng trên toàn bộ mạng. Một tình huống lịch sử minh họa cho rủi ro này là lỗi tràn Bitcoin năm 2010. Vào thời điểm đó, mã máy khách Bitcoin đã không kiểm tra xem tổng kết quả đầu ra của một giao dịch có bị tràn hay không (quấn quanh 0 bằng cách tính tổng trên số nguyên tối đa là 2⁶⁴−1) và do đó ai đó đã thực hiện một giao dịch đã làm như vậy. chính xác là như vậy, mang lại cho mình hàng tỷ bitcoin. Lỗi được phát hiện trong vòng vài giờ và bản sửa lỗi đã được thực hiện nhanh chóng và triển khai nhanh chóng trên mạng, nhưng nếu có một hệ sinh thái trưởng thành vào thời điểm đó, những đồng tiền đó sẽ được các sàn giao dịch, cầu nối và các cấu trúc khác chấp nhận và những kẻ tấn công có thể có được đã trốn thoát với rất nhiều tiền. Nếu có năm ứng dụng khách Bitcoin khác nhau, rất khó có khả năng tất cả chúng đều có cùng một lỗi và do đó sẽ có sự phân chia ngay lập tức và bên phân chia có lỗi có thể sẽ bị thua.

Có một sự cân bằng trong việc sử dụng phương pháp tiếp cận nhiều khách hàng để giảm thiểu nguy cơ xảy ra các lỗi nghiêm trọng: thay vào đó, bạn sẽ gặp phải các lỗi không đồng thuận. Nghĩa là, nếu bạn có hai khách hàng, có nguy cơ là các khách hàng có những cách hiểu khác nhau về một số quy tắc giao thức 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 làm đôi. Một sự phân chia nghiêm trọng kiểu đó đã xảy ra một lần trong lịch sử của Ethereum (từng có những sự phân chia khác nhỏ hơn nhiều trong đó các phần rất nhỏ của mạng chạy các phiên bản mã cũ bị phân tách). Những người bảo vệ cách tiếp cận một khách hàng coi sự thất bại trong sự đồng thuận là lý do để không triển khai nhiều lần: nếu chỉ có một khách hàng, thì khách hàng đó sẽ không đồng ý với chính nó. Mô hình của họ về số lượng khách hàng chuyển thành rủi ro có thể trông giống như thế này:

Tất nhiên là tôi không đồng ý với phân tích này. Điểm mấu chốt của sự bất đồng của tôi là (i) các lỗi thảm khốc kiểu năm 2010 cũng quan trọng 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õ ràng nhất qua đợt fork Bitcoin năm 2013: sự phân chia chuỗi xảy ra 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ố đó hóa ra có giới hạn ngẫu nhiên và không có giấy tờ về số lượng đối tượng có thể được sửa đổi trong một khối duy nhất. Do đó, về mặt lý thuyết, một khách hàng thường là hai khách hàng trong thực tế và năm khách hàng trên lý thuyết có thể là sáu hoặc bảy khách hàng trong thực tế - vì vậy chúng ta chỉ nên lao vào và đi về phía bên phải của đường cong rủi ro và có ít nhất một vài khách hàng khác nhau.

Các lập luận cho sự phân cấp chính trị

Các nhà phát triển khách hàng độc quyền đang ở vị trí có nhiều quyền lực chính trị. 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 đó, nhưng trên thực tế, người dùng thường khó làm điều đó. Điều gì sẽ xảy ra nếu một thay đổi giao thức không được chấp nhận được đ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 nhóm chính đe dọa bỏ cuộc nếu họ không đạt được mục tiêu? Hoặc thuần hóa hơn, điều gì sẽ xảy ra 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, khiến phần còn lại của hệ sinh thái rơi vào tình thế kém cỏi trong việc đánh giá các lập luận kỹ thuật mà nhóm khách hàng đưa ra, khiến nhóm khách hàng gặp khó khăn. có nhiều chỗ để thúc đẩy các mục tiêu và giá trị cụ thể của riêng họ, điều này có thể không phù hợp với cộng đồng rộng lớn hơn?

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

ZK-EVM sẽ xuất hiện trên lớp 1 như thế nào trong tương lai?

Ngày nay, ZK-EVM được sử dụng trong các bản tổng hợp. Điều này làm tăng quy mô bằng cách cho phép việc thực thi EVM đắt tiền chỉ diễn ra một vài lần ngoài chuỗi, trong khi những người khác chỉ cần xác minh SNARK được đăng trên chuỗi để chứng minh rằng việc thực thi EVM đã được tính toán chính xác. 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, 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à sự kết hợp giữa tính toán có thể mở rộng với ZK-EVM và dữ liệu có thể mở rộng với <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> việc lấy mẫu tính sẵn có của dữ liệu có thể cho phép chúng tôi mở rộng quy mô rất xa.

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ó quy mô lớp 2 nào có thể tự giải quyết được: lớp 1 rất khó xác minh, đến mức không có nhiều người dùng chạy nút riêng của 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 đề, nhưng máy khách nhẹ còn lâu mới là nút xác minh đầy đủ: máy khách nhẹ chỉ 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 và không xác minh rằng chuỗi thực sự tuân theo các quy tắc giao thức. Để đưa chúng ta đến một thế giới nơi người dùng thực sự có thể xác minh rằng chuỗi tuân theo các quy tắc, chúng ta sẽ phải làm điều gì đó khác biệt.

Tùy chọn 1: hạn chế 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ể giảm mục tiêu gas mỗi khối của lớp 1 xuống từ 15 triệu xuống còn 1 triệu, đủ để một khối chứa một SNARK duy nhất và một vài hoạt động gửi và rút tiền nhưng không nhiều hoạt động khác, và do đó 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ợ nhiều lần tổng hợp cam kết trong mỗi khối: chúng tôi có thể sử dụng các giao thức tổng hợp ngoài chuỗi do các nhà xây dựng tùy chỉnh điều hành để tập hợp các SNARK lại với nhau 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 sẽ là cơ quan thanh toán bù trừ cho các giao thức lớp 2, xác minh 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 số tiền lớn giữa chúng.

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

• Trên thực tế, nó không tương thích ngược, theo nghĩa là nhiều ứng dụng dựa trên L1 hiện tại 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ị kẹt do phí trở nên cao đến mức vượt quá chi phí để xóa các tài khoản đó. Điều này có thể được giải quyết bằng cách cho phép người dùng ký thông báo để chọn tham gia di chuyển hàng loạt trong giao thức sang L2 mà họ lựa chọn (xem một số ý tưởng triển khai ban đầu tại đây), nhưng điều này sẽ làm tăng thêm sự phức tạp cho quá trình chuyển đổi và khiến nó thực sự đủ rẻ. Dù sao thì một số loại SNARK ở lớp 1. Nói chung, tôi là người thích phá vỡ khả năng tương thích ngược khi nói đến <a href="https://hackmd.io/@vbuterin/selfstruct"> 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 nhiều.
• Nó có thể vẫn không làm cho việc xác minh đủ rẻ. Lý tưởng nhất là giao thức Ethereum phải dễ dàng xác minh không chỉ trên máy tính xách tay mà còn bên trong điện thoại, tiện ích mở rộng trình duyệt và thậm chí bên trong các chuỗi khác. Việc đồng bộ hóa chuỗi lần đầu tiên hoặc sau một thời gian dài ngoại tuyến cũng sẽ dễ dàng. Một nút máy tính xách tay có thể xác minh 1 triệu gas trong ~20 mili giây, nhưng ngay cả điều đó cũng có nghĩa là phải mất 54 giây để đồng bộ hóa sau một ngày ngoại tuyến (giả sử<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality">một nút tính hữu hạn của khe tăng thời gian khe lên 32 giây) và đối với điện thoại hoặc tiện ích mở rộng trình duyệt, sẽ mất vài trăm mili giây mỗi khối và vẫn có thể gây hao pin không đáng kể. Những con số này có thể quản lý được, nhưng chúng không lý tưởng.
• Ngay cả trong hệ sinh thái L2 đầu tiên, L1 ít nhất cũng có những lợi ích với 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 nếu họ nhận thấy rằng dữ liệu trạng thái mới không còn được cung cấp nữa. Trọng tài trở nên hiệu quả hơn, đặc biệt đối với các token nhỏ hơn, nếu kích thước tối thiểu của chuyển khoản trực tiếp chéo L2 khả thi về mặt kinh tế nhỏ hơn.

Do đó, có vẻ hợp lý hơn nếu 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-xác minh lớp 1

ZK-EVM loại 1 (hoàn toàn tương đương với Ethereum) có thể được sử dụng để xác minh việc thực thi EVM của khối Ethereum (lớp 1). Chúng tôi có thể viết thêm mã SNARK để xác minh mặt đồng thuận của một 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 ) hoặc đạt được hiệu quả lớn nhờ 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óa cao hơn nhiều. Tuy nhiên, không có lý do công nghệ cơ bản nào khiến điều đó không thể thực hiện được - và vì vậy tôi hy vọng rằng, ngay cả khi phải mất nhiều năm, nó cũng sẽ thực hiện được.

Đây là nơi 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 minh lớp 1 thì chúng ta sẽ sử dụng ZK-EVM nào?

Tôi thấy ba lựa chọn:

1. ZK-EVM đơn: từ bỏ mô hình nhiều khách hàng và chọn một ZK-EVM duy nhất mà chúng tôi sử dụng để xác minh các khối.
2. Đa ZK-EVM đóng: đồng ý và lưu giữ đồng thuận một bộ nhiều ZK-EVM cụ thể và có quy tắc giao thức lớp đồng thuận rằng một khối cần bằng chứng từ hơn một nửa số ZK-EVM trong bộ đó để được coi là hợp lệ .
3. Mở nhiều ZK-EVM: các máy khách khác nhau có cách triển khai ZK-EVM khác nhau và mỗi máy khách chờ một bằng chứng tương thích với cách triển khai của chính nó trước khi chấp nhận một khối là hợp lệ.

Đối với tôi, (3) có vẻ lý tưởng, ít nhất là cho đến khi và trừ khi công nghệ của chúng tôi cải thiện đến mức chúng tôi có thể chính thức chứng minh rằng tất cả các triển khai ZK-EVM đều tương đương với nhau, tại thời điểm đó, chúng tôi chỉ có thể chọn cái nào phù hợp nhất có hiệu quả. (1) sẽ hy sinh lợi ích của mô hình nhiều khách hàng và (2) sẽ loại bỏ 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 những thách thức đó có vẻ nhỏ hơn những thách thức của hai lựa chọn còn lại, ít nhất là ở thời điểm hiện tại.

Việc triển khai (3) sẽ không quá khó: một người có thể có mạng con p2p cho từng loại bằng chứng và khách hàng sử dụng một loại bằng chứng sẽ lắng nghe trên mạng con tương ứng và đợi cho đến khi họ nhận được bằng chứng rằng họ người xác minh công nhận là hợp lệ.

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

• Thách thức về độ trễ: kẻ tấn công độc hại có thể xuất bản một khối muộn, cùng với bằng chứng hợp lệ cho một khách hàng. Trên thực tế, sẽ mất nhiều thời gian (ngay cả khi ví dụ như 15 giây) để tạo ra bằng chứng hợp lệ cho các khách hàng khác. Thời gian này sẽ đủ dài để có khả năng tạo ra một fork tạm thời và làm gián đoạn chuỗi trong một vài vị trí.
• Dữ liệu kém hiệu quả: một lợi ích của ZK-SNARK là dữ liệu chỉ liên quan đến việc xác minh (đôi khi được gọi là “dữ liệu nhân chứng”) có thể bị xóa khỏi một khối. Ví dụ: khi bạn đã xác minh chữ ký, bạn không cần giữ chữ ký trong một khối, bạn chỉ cần lưu trữ một bit nói rằng chữ ký đó hợp lệ, cùng với một bằng chứng duy nhất trong khối xác nhận rằng tất cả các chữ ký hợp lệ tồn tại. Tuy nhiên, nếu chúng ta muốn có thể tạo ra bằng chứng thuộc nhiều loại cho một khối thì chữ ký gốc thực sự cần phải được xuất bản.

Thách thức về độ trễ có thể được giải quyết bằng cách cẩn thận khi thiết kế giao thức cuối cùng một khe. Các giao thức cuối cùng một khe có thể sẽ yêu cầu nhiều hơn hai vòng đồng thuận cho mỗi khe và do đó, người ta có thể yêu cầu vòng đầu tiên bao gồm 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 sẽ có bằng chứng.

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

Điều đáng nói là việc xác minh SNARK lớp 1 có một lợi ích quan trọng: thực tế là việc thực thi EVM trên chuỗi không còn cần phải được xác minh bởi mọi nút nữa, giúp tăng đáng kể số lượng thực thi EVM đang diễn ra. Điều này có thể xảy ra bằng cách tăng đáng kể giới hạn gas của lớp 1 hoặc bằng cách 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 nhiều khách hàng mở hoạt động tốt sẽ tốn rất nhiều công sức. Nhưng tin thực sự tốt là phần lớn công việc này đang diễn ra hoặc sẽ xảy ra:

• 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 đó.
• Công việc 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 đầy đủ hơn về phía đồng thuận PoS của chuỗi Ethereum.
• Khách hàng có thể sẽ bắt đầu thử nghiệm ZK-EVM để chứng minh khả năng thực thi khối Ethereum của riêng họ, đặc biệt khi chúng tôi có khách hàng không trạng thái và không cần kỹ thuật để trực tiếp thực thi lại mọi khối để duy trì trạng thái. Chúng tôi có thể sẽ có được sự chuyển đổi chậm và dần dần từ khách hàng xác minh khối Ethereum bằng cách thực thi lại chúng sang hầu hết khách hàng xác minh khối Ethereum bằng cách kiểm tra bằng chứng SNARK.
• Hệ sinh thái ERC-4337 và PBS có thể sẽ sớm bắt đầu hoạt động với các công nghệ tổng hợp như BLS và tổng hợp bằng chứng để tiết kiệm chi phí gas. Về tổng hợp BLS, công việc đã bắt đầu.

Với những công nghệ này, tương lai sẽ rất tốt đẹp. Các khối Ethereum sẽ nhỏ hơn ngày nay, bất kỳ ai cũng có thể chạy nút xác minh đầy đủ trên máy tính xách tay, thậm chí cả điện thoại của họ hoặc bên trong tiện ích mở rộng trình duyệt và tất cả điều này sẽ xảy ra trong khi vẫn duy trì được lợi ích của 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 đến mức có thể dễ dàng chứng minh việc triển khai ZK-EVM tương đương và xác định tất cả các lỗi gây ra sự khác biệt giữa chúng. Một dự án như vậy thậm chí có thể là một dự án thiết thực để 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 như vậy thành công, các cơ chế khác nhau sẽ cần được áp dụng để đảm bảo sự phân cấp chính trị liên tục của giao thức; có lẽ tại thời điểm đó, giao thức sẽ được coi là “hoàn chỉnh” và các chuẩn mực về tính bất biến sẽ mạnh mẽ hơn. Nhưng ngay cả khi đó là tương lai lâu dài, thế giới ZK-EVM mở đa khách hàng dường như giống như một bước đệm tự nhiên có khả năng xảy ra.

Trong thời gian gần, đây vẫn là một chặng đường dài. ZK-EVM đã có mặt, nhưng ZK-EVM trở nên thực sự khả thi ở lớp 1 sẽ yêu cầu chúng phải trở thành loại 1 và chứng minh đủ nhanh để đ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 có thể thực hiện được nhưng vẫn còn rất nhiều việc phải làm để đạt được điều đó. Những thay đổi đồng thuận như tăng chi phí gas của KECCAK, SHA256 và các phần biên dịch trướ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 đó cho thấy, các bước đầu tiên của quá trình chuyển đổi có thể diễn ra sớm hơn chúng tôi mong đợi: khi chúng tôi chuyển sang cây Verkle và máy khách không trạng thái, máy khách có thể bắt đầu dần dần sử dụng ZK-EVM và quá trình chuyển đổi sang thế giới “đa ZK-EVM mở” có thể bắt đầu tự xảy ra.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Vitalik], Mọi bản quyền thuộc về tác giả gốc [Vitalik]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.