Đặc biệt cảm ơn Justin Drake vì phản hồi và đánh giá của anh ấy
Một cách chưa được thảo luận nhưng rất quan trọng để Ethereum duy trì tính bảo mật và phân cấp của nó là triết lý đa khách hàng của nó. Ethereum cố tình không có "ứng dụng khách tham chiếu" mà mọi người chạy theo mặc định: thay vào đó, có một đặc điểm kỹ thuậ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 để triển khai đặc tả (còn được gọi là "máy khách"), đây là những gì người dùng thực sự chạy.
Mỗi nút Ethereum chạy một máy khách đồng thuận và một máy khách 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. Nếu chia sẻ của khách hàng trong lớp của nó ít hơn 1/3, thì mạng sẽ tiếp tục hoạt động bình thường. Nếu có một lỗi trong ứng dụng khách có 1/3 đến 2/3 cổ phần trong lớp của nó (ví dụ: Prysm, Lighthouse hoặc Geth), chuỗi sẽ tiếp tục thêm các khối, nhưng dừng hoàn thành các khối, 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ự gia tăng 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à kỹ thuật này đang được sử dụng tích cực bởi các giao thức L2 được gọi là ZK Rollup . Một số Rollup ZK này hiện đang hoạt động trên mạng chính, với nhiều bản cập nhật khác sẽ sớm ra mắt. 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 chúng để xác minh việc thực thi L1 (tham khảo: the Verge ).
Khi điều này xảy ra, ZK-EVM sẽ thực sự trở thành loại ứng dụng khách Ethereum thứ ba, điều quan trọng đối với an ninh mạng như ứng dụng khách thực thi và ứng dụng khách đồng thuận ngày nay. Điều này tự nhiên đặt ra một 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 đã được 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 vẫn còn những khó khăn khác: Làm cách nào để chúng tôi tạo ra một hệ sinh thái "đa khách hàng" để 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, câu hỏi lờ mờ là liệu sự đánh đổi như vậ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, 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 và lợi ích xã hội của 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à phục vụ cả hai.
Trường hợp phi tập trung hóa công nghệ
Lợi ích chính của phân cấp kỹ thuật rất đơn giản: nó giảm rủi ro rằng một lỗi đơn lẻ trong một phần mềm sẽ gây ra sự cố nghiêm trọng cho toàn bộ mạng. Lỗ hổng tràn Bitcoin năm 2010 là một ví dụ điển hình về 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 của giao dịch có bị tràn không (bằng cách tính tổng trên một số nguyên tối đa là 264-1, làm cho nó bằng 0), vì vậy ai đó đã thực hiện giao dịch và tự cho mình hàng tỷ đô la bitcoin. Lỗi được phát hiện trong vòng vài giờ, bản sửa lỗi nhanh chóng được triển khai và triển khai nhanh chóng trên toàn mạng, nhưng nếu có một hệ sinh thái trưởng thành vào thời điểm đó, thì các đồng tiền sẽ bị chặn bởi các sàn giao dịch, cầu nối và các cấu trúc khác. có thể đã lấy rất nhiều tiền. Nếu có năm khách hàng bitcoin khác nhau, không chắc là tất cả họ đều có cùng một lỗi, vì vậy họ sẽ phân nhánh ngay lập tức và phía sai của phân nhánh có thể bị lỗi.
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 các lỗi nghiêm trọng sẽ phải trả giá: thay vào đó, bạn sẽ nhận được các lỗi không đồng thuận. Nghĩa là, nếu bạn có hai khách hàng, sẽ có rủi ro là các khách hàng có cách hiểu khác nhau một cách tinh vi 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 tiền bị đánh cắp, nhưng sự khác biệt sẽ khiến chuỗi ngã ba làm đôi. Một đợt phân tách nghiêm trọng kiểu này đã xảy ra một lần trong lịch sử của Ethereum (đã có những lần phân tách 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 tách). Những người bảo vệ phương pháp tiếp cận một khách hàng lập luận rằng các lỗi đồng thuận là lý do không triển khai triển khai nhiều khách hàng: nếu chỉ có một khách hàng, thì khách hàng đó không thể không đồ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ể giống như thế này:
Tất nhiên, tôi không đồng ý với phân tích này. Những điểm chính mà tôi không đồng ý là (i) loại lỗi nghiêm trọng của năm 2010 cũng quan trọng và (ii) bạn sẽ không bao giờ thực sự chỉ có một khách hàng . Điểm thứ hai thể hiện rõ nhất trong đợt fork Bitcoin năm 2013 : một đợt fork theo 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ố đó đã vô tình hạn chế quyền truy cập vào dữ liệu trong một khối. Do đó, một khách hàng trên lý thuyết thường thực sự là hai khách hàng, và năm khách hàng trên lý thuyết có thể thực sự là sáu hoặc bảy khách hàng—vì vậy chúng ta nên chấp nhận rủi ro, đi bên phải của đường cong rủi ro và ít nhất là một vài khách hàng khác nhau.
Trường hợp phân cấp chính trị
Các nhà phát triển khách hàng độc quyền đang ở một vị trí có quyền lực chính trị lớn. Nếu nhà phát triển ứng dụng khách đề xuất mộ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 rẽ mà không có 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 đạt yêu cầu đi kèm với một 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 rời bỏ nếu nó không theo cách của họ? Hay nói một cách đơn giản hơn, nếu nhóm khách hàng độc quyền cuối cùng trở thành nhóm duy nhất 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 gặp bất lợi trong việc đánh giá các lập luận kỹ thuật do nhóm khách hàng đưa ra, thì nhóm khách hàng sẽ có lợi thế rất lớn . Thế còn việc tạo không 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 mục tiêu và giá trị của cộng đồng rộng lớn hơn thì sao?
Những lo ngại về chính trị giao thức, đặc biệt là trong bối cảnh cuộc chiến Bitcoin OP_RETURN năm 2013-2014 , trong đó một số người tham gia công khai phản đối việc sử dụng chuỗi khối cụ thể, là một yếu tố quan trọng trong việc Ethereum sớm áp dụng ý tưởng đa khách hàng, với mục đích là đưa ra những quyết định như vậy khó khăn hơn đối với một nhóm nhỏ người. Những lo ngại cụ thể đối với hệ sinh thái Ethereum — cụ thể là tránh tập trung quyền lực vào chính Ethereum Foundation — cung cấp hỗ trợ thêm cho hướng 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 (tức là giao thức hiện được gọi là "ứng dụng khách đồng thuận"), giao nhiệm vụ này hoàn toàn cho các nhóm bên ngoài.
ZK-EVM sẽ tiến 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 thực thi EVM đắt tiền chỉ xảy ra ngoài chuỗi một vài lần, trong khi những người khác chỉ cần xác minh SNARK được phát hành trên chuỗi để chứng minh tính chính xác của tính toán thực thi EVM. Nó cũng cho phép một số dữ liệu (đặc biệt là chữ ký) nằm ngoài 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à việc kết hợp tính toán có thể mở rộng với ZK-EVM và dữ liệu có thể mở rộng với 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ó quy mô Lớp 2 nào có thể tự giải quyết: Lớp 1 rất khó xác minh rằng không có 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ỉ cần tin tưởng các nhà cung cấp bên thứ ba. Các ứng dụng 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 ứng dụng khách nhẹ không phải là một nút xác thực đầy đủ: ứng dụng 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, chứ không phải chuỗi. thực sự tuân theo các quy tắc giao thức. Để người dùng có thể 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.
Tùy chọ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ể giảm mục tiêu gas Lớp 1 trên mỗi khối 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 số khoản tiền gửi và rút tiền, nhưng không nhiều, buộc hầu hết tất cả hoạt động của người dùng được chuyển sang Lớp 2 giao thức. Thiết kế như vậy vẫn có thể hỗ trợ gửi nhiều Rollup 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 một thế giới như vậy, chức năng duy nhất của Lớp 1 là trở thành trung tâm 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 chuyển tiền quy mô lớn giữa chúng.
Cách tiếp cận này hoạt động, nhưng nó 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ế. Hàng trăm hoặc hàng nghìn đô la trong quỹ của người dùng có thể bị mắc kẹt do các khoản phí trở nên quá cao, vượt quá chi phí để làm trống các tài khoản này. Vấn đề này có thể được giải quyết bằng cách yêu cầu người dùng ký một thông báo để chọn tham gia di chuyển hàng loạt trong giao thức sang L2 mà họ chọn (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ó trở nên thực sự rẻ. đủ để yêu cầu một số loại SNARK ở Lớp 1. Tôi thường thích 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ẻ ít thuận lợi hơn.
• Việc xác minh có thể vẫn chưa đủ 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, tiện ích mở rộng trình duyệt và thậm chí trong các chuỗi khác. Cũng nên dễ dàng đồ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. Nút máy tính xách tay có thể xác minh 1 triệu gas trong khoảng 20 ms, nhưng thậm chí điều đó có nghĩa là phải mất 54 giây để đồng bộ hóa sau khi ngoại tuyến trong một ngày (giả sử kết quả cuối cùng của một vị trí duy nhất sẽ tăng thời gian của vị trí lên 32 giây), trong khi đối với Trên điện thoại hoặc tiện ích mở rộng của trình duyệt, mỗi đoạn mất vài trăm mili giây 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 không lý tưởng.
• Ngay cả trong các hệ sinh thái ưu tiên L2, L1 ít nhất cũng phải chăng. Validiums có thể được hưởng lợi từ một mô hình bảo mật mạnh hơn nếu người dùng có thể rút tiền của họ khi nhận thấy rằng dữ liệu trạng thái mới không còn nữa. Nếu quy mô tối thiểu của chuyển khoản trực tiếp khả thi về mặt kinh tế qua L2 nhỏ hơn, thì chênh lệch giá sẽ trở nên 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, 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 – 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 các khối Ethereum (Lớp 1). 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ả đáng kể 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óa nhiều 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 hy vọng điều đó sẽ xảy ra, ngay cả khi phải mất nhiều năm.
Ở đây, chúng ta thấy một giao điểm 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, chúng ta sẽ sử dụng ZK-EVM nào?
Tôi có ba lựa chọn:
1. ZK-EVM đơn: Bỏ mô hình nhiều máy khách và chọn một ZK-EVM duy nhất để xác minh các khối.
2. Nhiều ZK-EVM đã đóng: Đạt được sự đồng thuận về một nhóm nhiều ZK-EVM cụ thể và niêm phong chúng trong các quy tắc giao thức của lớp đồng thuận, nghĩa là, một khối cần được chứng minh bởi hơn một nửa số ZK-EVM trong bộ được chấp nhận coi là hợp lệ.
3. Mở nhiều ZK-EVM: Các máy khách khác nhau có các triển khai ZK-EVM khác nhau và mỗi máy khách chờ bằng chứng về tính tương thích với triển khai của chính nó trước khi chấp nhận một khối hợp lệ.
Đố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ả các triển khai ZK-EVM đều tương đương với nhau, để chúng tôi có thể chọn cách hiệu quả nhất. (1) sẽ hy sinh lợi ích của mô hình đa khách hàng, (2) sẽ đóng khả năng phát triển khách hàng mới và hướng đế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 đó dường như ít khó khăn hơn so với hai lựa chọn còn lại, ít nhất là vào lúc này.
Việc triển khai (3) sẽ không quá khó: mỗi loại bằng chứng có một mạng con p2p và khách hàng sử dụng một loại bằng chứng sẽ lắng nghe và đợi trên mạng con tương ứng cho đến khi họ nhận được bằng chứng mà người xác minh cho là hợp lệ.
Hai thách thức chính của (3) có thể là như sau:
• Trì hoãn các thách thức : Những 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 về tính hợp lệ cho khách hàng. Tạo bằng chứng hợp lệ cho các khách hàng khác thực sự mất nhiều thời gian (thậm chí trong 15 giây chẳng hạn). Khoảng thời gian này đủ dài để có thể tạo một đợt fork tạm thời và phá vỡ chuỗi ở một số vị trí.
• Dữ liệu không hiệu quả : Một lợi ích của ZK-SNARK là chỉ dữ liệu liên quan đến xác minh (đôi khi được gọi là "dữ liệu nhân chứng") mới có thể bị xóa khỏi một khối. Ví dụ: khi chữ ký được xác minh, không cần lưu chữ ký trong một khối, chỉ cần lưu trữ một bit cho biết chữ ký hợp lệ và lưu trữ bằng chứng trong khối rằng tất cả các chữ ký hợp lệ đều có mặt. Tuy nhiên, nếu chúng tôi muốn có thể tạo 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 thực sự.
Các 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 kết thúc một khe. Giao thức cuối cùng một vị trí có thể yêu cầu nhiều hơn hai vòng đồng thuận cho mỗi vị trí và do đó có thể yêu cầu vòng đầu tiên 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 cho các khối xuất bản và thời điểm dự kiến sẽ 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 tổng hợp dữ liệu liên quan đến xác minh bằng một giao thức riêng. Đối với chữ ký, chúng tôi có thể sử dụng tập hợp BLS đã được 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 dành cho quyền riêng tư . May mắn thay, các giao thức này thường có các giao thức tổng hợp của riêng chúng .
Điều đáng nói là có một lợi ích quan trọng khác của xác minh SNARK Lớp 1: Việc thực thi EVM trên chuỗi không còn yêu cầu mỗi nút thực hiện xác minh, điều này làm tăng đáng kể số lượng thực thi EVM. Điều này có thể đạt được bằng cách tăng đáng kể nắp khí 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.
Tóm lại là
Phải mất rất nhiều công sức để làm cho một hệ sinh thái ZK-EVM đa khách hàng mở hoạt động tốt. Nhưng tin thực sự tốt là hầu hết công việc đang hoặc sắp diễn 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 di chuyển theo hướng này.
• Hoạt động trên các ứng dụng khách nhẹ như Helios và Succinct cuối cùng có thể chuyển thành xác minh SNARK hoàn chỉnh hơn trên khía cạnh đồng thuận PoS của chuỗi Ethereum.
• Khách hàng có thể bắt đầu thử nghiệm ZK-EVM để chứng minh khả năng thực thi của các khối Ethereum, đặc biệt là khi chúng tôi có các máy khách không trạng thái mà về mặt kỹ thuật không cần phải thực thi lại trực tiếp từng khối để duy trì trạng thái. Chúng tôi có thể chuyển từ khách hàng xác minh khối Ethereum bằng cách thực hiện lại 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, đây sẽ là 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 đã bắt đầu trên tổng hợp BLS.
Với những công nghệ này, tương lai có vẻ rất tốt. Các khối Ethereum sẽ nhỏ hơn hiện nay và bất kỳ ai cũng có thể chạy một nút xác thực đầ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 của trình duyệt, tất cả trong khi vẫn duy trì triết lý đa máy khách Ethereum diễn ra đồng thời.
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 bất kỳ lỗi nào 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 cái gì đó để làm việc 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 thi giao thức được phân cấp chính trị liên tục. Có lẽ đến lúc đó, giao thức sẽ được coi là "hoàn chỉnh" và đặc tả về tính bất biến sẽ mạnh hơn. Nhưng ngay cả khi đây là tương lai lâu dài hơn, thì thế giới mở của ZK-EVM đa khách hàng dường như là một bước đệm tự nhiên có thể xảy ra.
Trước mắt, đó vẫn là một hành trình dài. ZK-EVM đã có ở đây, nhưng để ZK-EVM thực sự khả thi ở Lớp 1, chúng cần phải là 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 đó nói rằng, các bước đầu tiên của quá trình chuyển đổi có thể xảy ra sớm hơn chúng tôi mong đợi: một khi chúng tôi chuyển sang cây Verkle và máy khách phi trạng thái, khách hàng có thể bắt đầu sử dụng ZK-EVM dần dần, hướng tới quá trình chuyển đổi thế giới "đa ZK-EVM mở" có thể tự bắt đầu.
