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

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

Tác giả gốc: Vitalik Buterin

Biên soạn: Thiện Vân, ChainCatcher

Ethereum duy trì an ninh và phi tập trung với triết lý đa khách hàng, điều này rất quan trọng nhưng chưa được thảo luận sâu. Ethereum không thiết kế một "khách hàng tham khảo" mà mọi người đều có thể chạy mặc định, mà thay vào đó thiết lập một tiêu chuẩn do người dùng hợp tác quản lý (gần đây được viết bằng Python có tính khả thi cao nhưng tốc độ chậm), và có nhiều nhóm thực hiện tiêu chuẩn đó (tức là "khách hàng"), đó chính 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à một khách hàng thực thi. Đến nay, 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 một khách hàng có thị phần dưới 1/3 trong loại của nó gặp sự cố, mạng sẽ tiếp tục vận hành bình thường. Nếu một khách hàng có thị phần từ 1/3 đến 2/3 (ví dụ, Prysm, Lighthouse hoặc Geth) gặp *sự cố, chuỗi sẽ tiếp tục thêm khối, nhưng nó sẽ ngừng xác nhận khối, *cho phép* các nhà phát triển có thời gian để can thiệp.

Trong cách xác thực chứng chỉ Ethereum, một sự chuyển biến lớn chưa được thảo luận đầy đủ nhưng sắp tới là sự trỗi dậy của ZK-EVM. Chứng minh việc thực thi EVM bằng SNARK đã được phát triển trong nhiều năm, công nghệ này đang được áp dụng tích cực trong giao thức L2 được gọi là ZK rollup. Một số ZK rollup đang hoạt động trên mạng chính, nhiều hơnsẽ đến. Nhưng về lâu dài, ZK-EVM sẽ không chỉ được sử dụng cho rollup, chúng tôi còn muốn sử dụng nó để xác thực tình trạng thực thi của lớp một.

Như vậy, ZK-EVM sẽ trở thành khách hàng thứ ba của Ethereum, cũng quan trọng đối với an ninh mạng như các khách hàng thực thi và đồng thuận hiện tại. Điều này tự nhiên sẽ đặt ra một câu hỏi: ZK-EVM sẽ tương tác với triết lý đa khách hàng như thế nào? Một trong những khó khăn đã được giải quyết: chúng tôi đã có nhiều triển khai ZK-EVM và đang phát triển tích cực. Nhưng những phần khó khăn khác vẫn còn tồn tại: chúng tôi sẽ thực sự làm thế nào để sử dụng hệ sinh thái "đa khách hàng" cho việc chứng minh tính chính xác của các khối Ethereum? Câu hỏi này mang đến một số thách thức kỹ thuật thú vị - tất nhiên còn có một câu hỏi cần giải quyết, đó là liệu những đánh đổi này có xứng đáng hay không.

Động lực ban đầu của 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 hình thức phi tập trung, giống như phi tập trung nói chung, mọi người có thể quan tâm đến lợi ích kỹ thuật của việc kiến trúc phi tập trung cũng như lợi ích xã hội của việc phi tập trung 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ụ cho cả hai.

Phi tập trung kỹ thuật

Lợi ích chính của phi tập trung kỹ thuật rất đơn giản: nó giảm thiểu rủi ro mà một lỗi trong phần mềm có thể dẫn đến sự sụp đổ hoàn toàn của toàn bộ mạng. Tình huống lịch sử thể hiện rủi ro này là lỗi tràn trong Bitcoin năm 2010. Vào thời điểm đó, mã khách hàng Bitcoin không kiểm tra tổng số đầu ra giao dịch có bị tràn hay không (bằng cách cộng tổng vượt quá số nguyên lớn nhất 264-1 và quay lại về 0), do đó có người thực hiện giao dịch tràn, mang lại cho mình hàng tỷ Bitcoin. Lỗi này đã được phát hiện trong vài giờ và bản sửa lỗi đã được triển khai vội vàng trên toàn mạng, nếu lúc đó có một hệ sinh thái trưởng thành, những mã thông báo này sẽ được các sàn giao dịch, cầu nối và các tổ chức khác chấp nhận, kẻ tấn công sẽ có thể rút tiền. Nhưng nếu lúc đó có năm khách hàng Bitcoin khác nhau, khả năng tất cả đều gặp lỗi tương tự là rất nhỏ, thì sẽ xảy ra phân tách ngay lập tức, và bên gặp lỗi trong phân tách có thể thua.

Việc sử dụng đa khách hàng để giảm thiểu rủi ro từ các lỗi thảm khốc có giá phải trả: bạn có thể gặp phải lỗi đồng thuận: nếu có hai khách hàng, và họ có những giải thích khác nhau về một số quy tắc giao thức, thì mặc dù cả hai giải thích đều hợp lý và ngăn chặn việc đánh cắp tiền, nhưng sự khác biệt này có thể dẫn đến chuỗi bị phân tách thành hai nửa. Loại phân tách nghiêm trọng này đã xảy ra một lần trong lịch sử Ethereum (cũng đã xảy ra những phân tách nhỏ hơn khác).

Những người bảo vệ phương pháp đơn khách hàng sẽ viện dẫn lỗi đồng thuận, cho rằng không cần phải thực hiện nhiều phiên bản: nếu chỉ có một khách hàng, khách hàng đó sẽ không thể mâu thuẫn với chính mình. Mô hình của họ về số lượng khách hàng sẽ gây ra rủi ro có thể như sau:

Tất nhiên, tôi không đồng ý với phân tích này, vì (1) cũng cần xem xét lỗi thảm khốc của cuối năm 2010, tình huống lúc đó cũng rất nghiêm trọng; (2) chỉ có một khách hàng trên thực tế chưa bao giờ tồn tại. Điều này thể hiện rõ nhất trong sự kiện phân tách Bitcoin năm 2013: do có sự khác biệt giữa hai phiên bản khách hàng Bitcoin khác nhau, một phiên bản đã đặt ra một giới hạn không ghi nhận về số lượng đối tượng có thể sửa đổi trong một khối đơn lẻ, dẫn đến việc chuỗi bị phân tách. Do đó, lý thuyết về "một khách hàng" trong thực tế thường là hai khách hàng, lý thuyết về năm khách hàng trong thực tế có thể là sáu hoặc bảy khách hàng - vì vậy chúng ta nên chọn phía bên phải của đường cong rủi ro (hình trên), ít nhất là có một vài khách hàng khác nhau.

Phi tập trung chính trị

Nhà phát triển khách hàng có vị trí độc quyền có quyền lực chính trị lớn. Nếu nhà phát triển khách hàng đề xuất một thay đổi mà người dùng không đồng ý, về 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 phân tách không có phiên bản đó, nhưng trên thực tế người dùng thường rất khó làm điều đó. Nếu sự thay đổi giao thức không mong muốn này được gộp chung với các bản cập nhật an ninh cần thiết thì sao? Nếu nhóm chính đe dọa sẽ rút lui thì sao? Hoặc trong trường hợp phổ biến hơn, nếu nhóm khách hàng độc quyền là nhóm duy nhất có chuyên môn về giao thức? Như vậy, các thành viên khác trong hệ sinh thái khó có thể đánh giá liệu lập luận kỹ thuật mà nhóm khách hàng đưa ra có hợp lý hay không, nhóm khách hàng có không gian lớn để thúc đẩy các mục tiêu và giá trị của riêng họ, mà những mục tiêu và giá trị này có thể không nhất quán với những gì cộng đồng rộng lớn hơn theo đuổi, thì phải làm sao?

Sự quan tâm đến chính trị giao thức, đặc biệt là từ cuộc chiến OP_RETURN của Bitcoin năm 2013-14, khi một số người tham gia công khai ủng hộ việc phân biệt một số mục đích cụ thể của chuỗi, là một yếu tố quan trọng trong việc Ethereum áp dụng triết lý đa khách hàng sớm, nhằm tránh tình huống này xảy ra lần nữa. Sự quan tâm đến hệ sinh thái Ethereum - tức là tránh tập trung quyền lực vào chính quỹ Ethereum - cũng cung cấp thêm hỗ trợ cho hướng đi này. Năm 2018, nhóm đã quyết định không để quỹ thực hiện giao thức PoS của Ethereum (tức là "khách hàng đồng thuận" hiện tại), mà hoàn toàn giao nhiệm vụ này cho các nhóm bên ngoài.

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

Hiện tại, ZK-EVM được sử dụng trên rollup: cho phép việc thực thi EVM tốn kém diễn ra ngoài chuỗi vài lần, trong khi những người khác chỉ cần xác thực chứng minh rằng việc thực thi EVM là chính xác trên chuỗi SNARK, từ đó mở rộng quy mô. Nó cũng cho phép một số dữ liệu (đặc biệt là chữ ký) không được bao gồm trên chuỗi để tiết kiệm phí giao dịch. Điều này mang lại cho chúng tôi nhiều lợi ích về mở rộng quy mô, và kết hợp tính toán có thể mở rộng với ZK-EVM và mẫu khả dụng dữ liệu có thể mang lại mức độ mở rộng lớn.

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

Giải pháp 1: Thu hẹp lớp 1, buộc hầu hết mọi hoạt động chuyển sang lớp 2

Chúng tôi có thể dần dần giảm mục tiêu gas của lớp 1 cho mỗi khối từ 15 triệu xuống 1 triệu, đủ để cho một khối chứa một SNARK và một số hoạt động gửi và rút tiền, nhưng không thể thực hiện quá nhiều hoạt động khác, từ đó 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ợ việc gửi nhiều rollup trong 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 các nhà phát triển tùy chỉnh chạy, để tổng hợp và hợp nhất SNARK từ nhiều giao thức lớp 2. Như vậy, chức năng duy nhất của lớp 1 là trở thành trung tâm trao đổi cho các giao thức lớp 2, xác thực các chứng minh của lớp 2, thỉnh thoảng thúc đẩy việc chuyển tiền lớn giữa chúng.**

Phương pháp này có thể hoạt động, nhưng nó có một số điểm yếu quan trọng:

1. Nó thực sự không thể tương thích ngược. Điều này có nghĩa là, nhiều ứng dụng hiện tại dựa trên L1 sẽ trở nên không khả thi về mặt kinh tế. Do phí trở nên cao, thậm chí vượt quá chi phí để thanh lý các tài khoản này, tiền của người dùng có thể bị đóng băng, lên đến hàng trăm hoặc hàng nghìn đô la. Việc yêu cầu người dùng ký thông tin để tham gia vào việc chuyển giao quy mô lớn sang L2 có thể giải quyết vấn đề này, nhưng điều này làm tăng độ phức tạp của quá trình chuyển đổi. Và nếu muốn đạt được chi phí thực sự thấp, cần phải thực hiện một số SNARK trên lớp 1. Khi nói đến những thứ như SELFDESTRU, tôi thường đồng ý với việc phá vỡ tính tương thích ngược, nhưng trong trường hợp này, tôi không khuyên nên từ bỏ tính tương thích ngược.

2. Chi phí xác thực không giảm đáng kể . Lý tưởng nhất, giao thức Ethereum nên dễ xác thực, không chỉ trên máy tính xách tay mà còn trên điện thoại, tiện ích mở rộng trình duyệt, thậm chí trên các chuỗi khác. Việc đồng bộ lần đầu tiên với chuỗi, hoặc đồng bộ lại sau thời gian dài ngoại tuyến cũng nên rất dễ dàng. Một 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ả như vậy, điều đó có nghĩa là cần 54 giây để đồng bộ sau một ngày ngoại tuyến (giả sử thời gian kết thúc của một slot đơn tăng 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, mỗi khối cần vài trăm mili giây, có thể vẫn gây tiêu tốn pin không thể bỏ qua. Những con số này mặc dù có thể kiểm soát, nhưng không đáp ứng được kỳ vọng lý tưởng của chúng tôi.

3. Ngay cả trong hệ sinh thái ưu tiên L2, L1 cũng có thể hưởng lợi với chi phí không cao. Validiums có thể hưởng lợi từ mô hình bảo mật mạnh mẽ hơn, nếu người dùng phát hiện dữ liệu trạng thái mới không còn khả dụng, họ có thể rút tiền. Nếu quy mô tối thiểu cần thiết cho việc chuyển giao trực tiếp giữa các L2 có tính khả thi kinh tế nhỏ, thì việc chênh lệch giá sẽ hiệu quả hơn, đặc biệt là đối với các mã thông báo nhỏ hơn.

Vì vậy, việc sử dụng ZK-SNARK để xác thực lớp 1 có vẻ hợp lý hơn.

Giải pháp 2: SNARK-xác thực 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 thực 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 thực các bên đồng thuận của khối. Đây sẽ là một vấn đề kỹ thuật đầy thách thức: hiện tại ZK-EVM cần vài phút đến vài giờ để xác thực khối Ethereum, trong khi việc tạo chứng minh theo thời gian thực sẽ cần 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) phần cứng chuyên dụng để đạt được hiệu suất lớn hơn, và (iii) cải tiến kiến trúc với nhiều song song hơn. Hiện tại không có lý do kỹ thuật nào cho thấy điều này không thể đạt được - do đó tôi hy vọng, dù cần nhiều năm, chúng tôi cũng có thể thực hiện điều này.

Tại đây cần xem xét mô hình đa khách hàng: nếu chúng tôi muốn sử dụng ZK-EVM để xác thực lớp 1, chúng tôi nên sử dụng ZK-EVM nào? Có ba lựa chọn:

1) ZK-EVM đơn: từ bỏ mô hình đa khách hàng, chọn một ZK-EVM duy nhất để xác thực khối.

2) Đa ZK-EVM đóng: đạt được sự đồng thuận về một nhóm ZK-EVM đa dạng và quy định trong giao thức lớp đồng thuận rằng một khối cần chứng minh từ hơn một nửa ZK-EVM trong nhóm đó để được coi là hợp lệ.

3) Đa ZK-EVM mở: các khách hàng khác nhau có các triển khai ZK-EVM khác nhau, mỗi khách hàng sẽ chỉ chấp nhận một khối là hợp lệ khi nhận được chứng minh tương thích với triển khai của chính mình.

Đối với tôi, phương án 3 là lý tưởng, tình huống này sẽ không thay đổi cho đến khi công nghệ của chúng tôi cải tiến đến mức có thể chứng minh chính thức rằng tất cả các triển khai ZK-EVM là tương đương, có thể chọn lựa phương án hiệu quả nhất.

Phương án 1 sẽ hy sinh lợi ích của mô hình đa khách hàng, phương án 2 sẽ đóng cửa khả năng phát triển khách hàng mới, dẫn đến hệ sinh thái trở nên tập trung hơn. Phương án 3 có thách thức, nhưng những thách thức này dường như nhỏ hơn so với hai lựa chọn còn lại, ít nhất là hiện tại.

Việc thực hiện phương án 3 không khó: chúng tôi có thể thiết lập một mạng p2p cho mỗi loại chứng minh, khách hàng sử dụng một loại chứng minh sẽ lắng nghe trên mạng con tương ứng và chờ nhận chứng minh được xác thực là hợp lệ.

Hai thách thức chính của phương án 3 có thể là:

1) Độ trễ: kẻ tấn công độc hại có thể trì hoãn việc phát hành khối và chứng minh hợp lệ cho khách hàng, điều này có thể cần rất nhiều thời gian (tức là thậm chí là 15 giây) để tạo ra chứng minh hợp lệ cho các khách hàng khác, khoảng thời gian này đủ để tạo ra phân tách tạm thời và gây rối cho chuỗi trong vài slot thời gian.

2) Hiệu quả dữ liệu thấp: Một trong những lợi ích của ZK-SNARK là chỉ dữ liệu liên quan đến xác thực (đôi khi được gọi là "dữ liệu chứng kiến") có thể bị xóa khỏi khối. Ví dụ, một khi bạn xác thực một chữ ký, bạn không cần giữ chữ ký đó trong khối, bạn chỉ cần lưu trữ một bit cho biết chữ ký đó là hợp lệ, trong khi lưu trữ một chứng minh trong khối xác nhận sự tồn tại của tất cả các chữ ký hợp lệ. Nhưng nếu chúng tôi muốn tạo ra nhiều loại chứng minh cho một khối, thì chữ ký gốc cần phải được công bố thực sự.

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

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

Cũng đáng lưu ý rằng, việc xác thực lớp 1 bằng SNARK có một lợi ích quan trọng: việc thực thi EVM trên chuỗi không còn cần phải được xác thực bởi mỗi nút, điều này có thể cho phép tăng đáng kể khối lượng thực thi EVM, có thể đạt được bằng cách tăng đáng kể giới hạn gas của lớp 1, hoặc giới thiệu rollup ngầm, (enshrined rollup), hoặc cả hai đều được áp dụng.

Kết luận

Việc thực hiện một hệ sinh thái ZK-EVM đa khách hàng hoạt động tốt không phải là điều dễ dàng. Nhưng tin tốt là phần lớn công việc này đang diễn ra hoặc sẽ diễn ra:

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

• Công việc trên các khách hàng nhẹ (như Helios và Succinct) cuối cùng có thể trở thành việc xác thực SNARK toàn diện hơn cho đồng thuận PoS của chuỗi Ethereum.

• Các khách hàng có thể bắt đầu thử nghiệm việc sử dụng ZK-EVM để tự chứng minh việc thực thi các khối Ethereum, đặc biệt là khi chúng tôi có thể thực hiện khách hàng không trạng thái, về mặt kỹ thuật không cần phải thực thi lại mỗi khối để duy trì trạng thái. Chúng tôi có thể thực hiện một quá trình chuyển đổi chậm: từ việc khách hàng xác thực các khối Ethereum bằng cách thực thi lại, đến việc hầu hết các khách hàng xác thực các khối Ethereum bằng cách kiểm tra chứng minh SNARK.

• Hệ sinh thái ERC-4337 và PBS có thể sớm bắt đầu sử dụng các công nghệ tổng hợp như BLS và tổng hợp chứng minh để tiết kiệm chi phí giao dịch. Về việc tổng hợp BLS, công việc liên quan cũng đã bắt đầu.

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

Trong tương lai xa hơn, mọi thứ đều có thể xảy ra. Có thể trí tuệ nhân tạo sẽ nâng cao đáng kể hiệu suất xác thực hình thức, cho phép dễ dàng chứng minh tính tương đương của các triển khai ZK-EVM và xác định tất cả các lỗ hổng dẫn đến sự khác biệt giữa chúng. Thậm chí chúng ta nên bắt đầu dự án này ngay bây giờ. Nếu phương pháp dựa trên xác thực hình thức này thành công, sẽ cần thiết phải thiết lập các cơ chế khác nhau để đảm bảo sự phi tập trung quyền lực chính trị của giao thức; có thể đến lúc đó, giao thức sẽ được coi là "hoàn chỉnh", và tính không thể thay đổi của các tiêu chuẩn sẽ mạnh mẽ hơn. Nhưng ngay cả khi sau một thời gian dài, ZK-EVM đa khách hàng mở vẫn là một thế giới sẽ đến.

Trong ngắn hạn, mọi thứ đều khó khăn. ZK-EVM đã xuất hiện, nhưng để thực hiện ZK-EVM thực sự khả thi trên lớp 1, cần phải trở thành ZK-EVM loại 1 và thực hiện chứng minh nhanh chóng, theo thời gian thực. Với đủ song song, điều này có thể đạt được, nhưng vẫn cần rất nhiều công việc. Việc tăng chi phí giao dịch của các hàm băm KECCAK, SHA256 và các hàm băm khác cũng sẽ là một phần quan trọng trong kế hoạch tương lai. Bước đầu tiên của quá trình chuyển đổi có thể xảy ra nhanh hơn chúng ta mong đợi: một khi chúng ta chuyển sang cây Merkle và khách hàng không trạng thái, các khách hàng 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 "mở, đa ZK-EVM" có thể xảy ra một cách tự động.