Tiêu đề gốc: Tương lai có thể có của giao thức Ethereum, phần 4: The Verge
Tác giả gốc: Vitalik Buterin
Biên soạn gốc: Mensh, ChainCatcher
Đặc biệt cảm ơn Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams và Uma Roy vì những phản hồi và đánh giá của họ.
Một trong những tính năng mạnh mẽ nhất của blockchain là bất kỳ ai cũng có thể chạy một nút trên máy tính của mình và xác minh tính chính xác của blockchain. Ngay cả khi 9596 nút chạy đồng thuận chuỗi (PoW, PoS) đều ngay lập tức đồng ý thay đổi quy tắc và bắt đầu tạo khối theo quy tắc mới, thì mọi người chạy nút xác thực đầy đủ sẽ từ chối chấp nhận chuỗi. Những người khai thác không thuộc nhóm như vậy sẽ tự động hội tụ vào một chuỗi tiếp tục tuân theo các quy tắc cũ và tiếp tục xây dựng chuỗi này, trong khi những người dùng đã được xác minh đầy đủ sẽ tuân theo chuỗi này.
Đây là điểm khác biệt chính giữa blockchain và hệ thống tập trung. Tuy nhiên, để tính năng này hoạt động đúng, việc chạy một nút được xác thực đầy đủ cần phải thực sự khả thi đối với đủ người. Điều này áp dụng cho cả những người vận động (vì nếu những người vận động không xác thực chuỗi, họ sẽ không góp phần thực thi các quy tắc giao thức) và cho người dùng thông thường. Ngày nay, có thể chạy các nút trên máy tính xách tay tiêu dùng (bao gồm cả máy tính xách tay mà tôi đang viết bài này), nhưng làm như vậy rất khó. The Verge nhằm mục đích thay đổi tình trạng này, làm cho chi phí tính toán để xác minh đầy đủ chuỗi thấp đến mức mọi ví di động, ví trình duyệt và thậm chí cả đồng hồ thông minh sẽ xác minh nó theo mặc định.
Lộ trình của The Verge 2023
Ban đầu, “Verge” đề cập đến việc chuyển bộ lưu trữ trạng thái Ethereum sang cây Verkle - một cấu trúc cây cho phép chứng minh nhỏ gọn hơn, cho phép xác minh các khối Ethereum không trạng thái. Một nút có thể xác minh khối Ethereum mà không lưu trữ bất kỳ trạng thái Ethereum nào (số dư tài khoản, mã hợp đồng, dung lượng lưu trữ...) trên ổ cứng của nó với chi phí hàng trăm KB dữ liệu bằng chứng và hàng trăm mili giây bổ sung để xác minh bằng chứng. . Ngày nay, Verge thể hiện một tầm nhìn lớn hơn, tập trung vào việc cho phép xác minh hiệu quả tài nguyên tối đa của chuỗi Ethereum, không chỉ bao gồm công nghệ xác minh không trạng thái mà còn sử dụng SNARK để xác minh tất cả các lần thực thi Ethereum.
Ngoài trọng tâm dài hạn vào việc xác minh SNARK của toàn bộ chuỗi, một câu hỏi mới nổi khác liên quan đến việc liệu cây Verkle có phải là công nghệ tốt nhất hay không. Cây Verkle rất dễ bị máy tính lượng tử tấn công nên nếu thay cây KECCAK Merkle Patricia hiện tại bằng cây Verkle thì sau này chúng ta sẽ phải thay cây lần nữa. Một cách thay thế cho cây Merkle là chỉ cần bỏ qua STARK bằng nhánh Merkle và đặt nó vào cây nhị phân. Trong lịch sử, cách tiếp cận này được coi là không khả thi do sự phức tạp về mặt kỹ thuật và chi phí. Tuy nhiên, gần đây, chúng tôi đã thấy Starkware chứng minh được 1,7 triệu hàm băm Poseidon mỗi giây bằng cách sử dụng ckcle STARK trên máy tính xách tay và nhờ các công nghệ như GKB, thời gian chứng minh cho các hàm băm truyền thống hơn cũng đang nhanh chóng bị thu hẹp lại. Vì vậy, trong năm qua, Verge đã trở nên cởi mở hơn, nó có một số khả năng.
The Verge: Mục tiêu chính
Máy khách không trạng thái: Dung lượng lưu trữ cần thiết để xác thực hoàn toàn máy khách và đánh dấu nút không được vượt quá vài GB.
(Dài hạn) Chuỗi được xác minh đầy đủ (đồng thuận và thực thi) trên đồng hồ thông minh. Tải xuống một số dữ liệu, xác minh SNARK và hoàn tất.
trong chương này
Khách hàng không quốc tịch: Verkle hoặc STARKs
Bằng chứng về tính hiệu quả của việc thực thi EVM
Bằng chứng về tính hợp lệ của sự đồng thuận
Xác minh không quốc tịch: Verkle hoặc STARKs
Chúng ta đang cố gắng giải quyết vấn đề gì?
Ngày nay, khách hàng Ethereum cần lưu trữ hàng trăm gigabyte dữ liệu trạng thái để xác thực các khối và số lượng này đang tăng lên hàng năm. Dữ liệu trạng thái thô tăng khoảng 30 GB mỗi năm và một khách hàng phải lưu trữ một số dữ liệu bổ sung trên đó để cập nhật gấp ba lần một cách hiệu quả.
Điều này làm giảm số lượng người dùng có thể chạy các nút Ethereum xác thực đầy đủ: trong khi các ổ cứng đủ lớn để lưu trữ tất cả trạng thái Ethereum và thậm chí nhiều năm lịch sử được phổ biến rộng rãi, mọi người có xu hướng mua máy tính theo mặc định chỉ có vài trăm gigabyte dung lượng lưu trữ. Kích thước của trạng thái cũng gây ra trở ngại đáng kể trong quá trình thiết lập nút lần đầu tiên: nút đó cần tải xuống toàn bộ trạng thái, việc này có thể mất hàng giờ hoặc hàng ngày. Điều này có tất cả các loại hiệu ứng kích thích. Ví dụ: nó làm tăng đáng kể khó khăn cho các nhà sản xuất nút trong việc nâng cấp cài đặt nút của họ. Về mặt kỹ thuật, có thể hoàn tất quá trình nâng cấp mà không có thời gian ngừng hoạt động - khởi động một ứng dụng khách mới, đợi nó đồng bộ hóa, sau đó đóng ứng dụng khách cũ và chuyển khóa - nhưng trên thực tế, điều này rất phức tạp về mặt kỹ thuật.
Nó hoạt động như thế nào?
Xác minh không trạng thái là công nghệ cho phép các nút xác minh các khối mà không cần nắm vững toàn bộ trạng thái. Thay vào đó, mỗi khối đi kèm với một bằng chứng bao gồm: (i) giá trị, mã, số dư, lưu trữ tại một vị trí cụ thể ở trạng thái mà khối sẽ truy cập (ii) bằng chứng mật mã cho thấy các giá trị này là chính xác;
Trên thực tế, việc thực hiện xác minh không trạng thái đòi hỏi phải thay đổi cấu trúc cây trạng thái của Ethereum. Điều này là do cây Merkle Patricia hiện tại cực kỳ không thân thiện với việc thực hiện bất kỳ sơ đồ chứng minh mật mã nào, đặc biệt là trong trường hợp xấu nhất. Điều này đúng cho dù đó là fork Merblk nguyên bản hay khả năng được bọc vào STARK. Những khó khăn chính phát sinh từ một số điểm yếu của MPT:
1. Đây là hexatree (tức là mỗi nút có 16 nút con). Điều này có nghĩa là trong một cây có kích thước N, một bằng chứng yêu cầu trung bình 32*(16-1)*log 16(N) = 120* log 2(N) byte hoặc khoảng Yêu cầu 3840 byte. Đối với cây nhị phân, chỉ cần 32*(2-1)*log 2(N) = 32* log 2(N) byte hoặc khoảng 1024 byte.
2. Mã không được Merkleized. Điều này có nghĩa là việc chứng minh mọi quyền truy cập vào mã tài khoản đều yêu cầu cung cấp toàn bộ mã, có thể lên tới 24.000 byte.
Chúng ta có thể tính toán trường hợp xấu nhất như sau:
30000000 gas / 2400 (chi phí đọc tài khoản nguội) * (5 * 488 + 24000) = 330000000 byte
Chi phí nhánh đã giảm một chút (5*480 thay vì 8*480) vì khi có nhiều nhánh hơn, các phần trên cùng của chúng sẽ được lặp lại. Nhưng ngay cả như vậy, lượng dữ liệu cần tải xuống trong một khe thời gian là hoàn toàn không thực tế. Nếu chúng tôi cố gắng gói nó trong STARK, chúng tôi sẽ gặp phải hai vấn đề: (i) KECCAK tương đối không thân thiện với STARK; (ii) 330 MB dữ liệu có nghĩa là chúng tôi phải thực hiện 5 triệu lệnh gọi đến hàm vòng của KECCAK, điều này có thể không xảy ra. đã được chứng minh cho tất cả trừ phần cứng tiêu dùng mạnh mẽ nhất, ngay cả khi chúng tôi có thể nhờ STARK chứng minh rằng KECCAK hiệu quả hơn.
Nếu chúng ta thay thế trực tiếp cây thập lục phân bằng cây nhị phân và thực hiện Merkleization bổ sung cho mã thì trường hợp xấu nhất sẽ là khoảng 30000000/2400* 32*(32-14+ 8) = 10400000 byte (14 là phép trừ các bit dư thừa cho 2^14 nhánh và 8 là độ dài của bằng chứng đi vào lá trong khối mã). Lưu ý rằng điều này yêu cầu thay đổi chi phí gas để tính phí cho việc truy cập từng khối mã riêng lẻ; EIP-4762 thực hiện việc này. Dung lượng 10,4 MB tốt hơn nhiều nhưng vẫn còn quá nhiều dữ liệu để tải xuống trong một khe thời gian cho nhiều nút. Vì vậy, chúng ta cần giới thiệu công nghệ mạnh mẽ hơn. Có hai giải pháp hàng đầu về vấn đề này: Cây Verkle và cây băm nhị phân STARKed.
Cây roi
Cây Verkle sử dụng các cam kết vectơ dựa trên đường cong elip để chứng minh ngắn hơn. Chìa khóa để mở khóa điều này là phần chứng minh cho mỗi mối quan hệ cha-con chỉ có 32 byte, bất kể chiều rộng của cây. Giới hạn duy nhất về độ rộng của cây chứng minh là nếu cây chứng minh quá rộng thì việc chứng minh sẽ kém hiệu quả về mặt tính toán. Việc triển khai được đề xuất cho Ethereum có chiều rộng là 256.
Do đó, kích thước của một nhánh trong bằng chứng trở thành 32 - 1 og 256(N) = 4* log 2(N) byte. Do đó, kích thước chứng minh tối đa theo lý thuyết là khoảng 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 byte (kết quả tính toán thực tế hơi khác do sự phân bố không đồng đều của các khối trạng thái, nhưng ước tính đầu tiên là Được rồi).
Một điều cần lưu ý nữa là trong tất cả các ví dụ trên, trường hợp xấu nhất này không phải là trường hợp xấu nhất: trường hợp xấu hơn là kẻ tấn công cố tình khai thác hai địa chỉ để chúng có vị trí chung dài hơn trong tiền tố cây và đọc từ một trong các địa chỉ, có thể kéo dài độ dài nhánh trong trường hợp xấu nhất thêm 2 lần nữa. Nhưng ngay cả trong trường hợp này, độ dài chứng minh trường hợp xấu nhất của cây Verkle là 2,6 MB, về cơ bản phù hợp với dữ liệu xác minh trường hợp xấu nhất hiện tại.
Chúng tôi cũng đã làm điều gì đó khác với cảnh báo này: chúng tôi đã làm cho việc truy cập vào bộ lưu trữ liền kề trở nên rất rẻ: nhiều khối mã của cùng một hợp đồng hoặc các khe lưu trữ liền kề. EIP-4762 cung cấp định nghĩa về vùng lân cận và chỉ tính phí 200 gas cho quyền truy cập vùng lân cận. Trong trường hợp truy cập liền kề, kích thước bằng chứng trong trường hợp xấu nhất sẽ là 30000000/200* 32 - 4800800 byte, vẫn nằm trong phạm vi dung sai cho phép. Nếu vì lý do bảo mật, chúng tôi muốn giảm giá trị này, chúng tôi có thể tăng nhẹ chi phí truy cập liền kề.
Cây băm nhị phân STARKed
Nguyên tắc của kỹ thuật này rất dễ hiểu: bạn chỉ cần tạo một cây nhị phân, lấy bằng chứng có dung lượng lên tới 10,4 MB, chứng minh giá trị trong khối và sau đó thay thế bằng chứng bằng STARK của bằng chứng. Bằng cách này, bản thân bằng chứng chỉ bao gồm dữ liệu được chứng minh, cộng với chi phí cố định 100-300 kB từ STARK thực tế.
Thách thức chính ở đây là thời gian xác minh. Về cơ bản, chúng ta có thể thực hiện phép tính tương tự như trên, ngoại trừ thay vì đếm byte, chúng ta đang đếm số băm. Khối 10,4 MB có nghĩa là 330.000 băm. Nếu bạn thêm vào khả năng kẻ tấn công khai thác cây địa chỉ có tiền tố công khai dài hơn, giá trị băm trong trường hợp xấu nhất sẽ lên tới khoảng 660.000 giá trị băm. Vì vậy, nếu chúng ta có thể chứng minh được 200.000 hàm băm mỗi giây thì tốt thôi.
Những con số này đã đạt được trên máy tính xách tay tiêu dùng sử dụng hàm băm Poseidon , được thiết kế đặc biệt để thân thiện với STARK. Tuy nhiên, hệ thống Poseidon vẫn còn tương đối non nớt nên nhiều người vẫn chưa tin tưởng vào tính bảo mật của nó. Vì vậy, có hai con đường thực tế phía trước:
Nhanh chóng thực hiện phân tích bảo mật sâu rộng trên Poseidon và làm quen với nó để triển khai tại L1
Sử dụng hàm băm bảo thủ hơn như SHA 256 hoặc BLAKE
Nếu bạn muốn chứng minh các hàm băm thận trọng, vòng tròn STARK của Starkware chỉ có thể chứng minh 10-30 k hàm băm mỗi giây trên máy tính xách tay tiêu dùng tại thời điểm viết bài. Tuy nhiên, công nghệ STARK đang được cải thiện nhanh chóng. Thậm chí ngày nay, các công nghệ dựa trên GKR đã được chứng minh là có thể tăng tốc độ này lên phạm vi 100-2 O 0 k.
Chứng kiến các trường hợp sử dụng ngoài việc xác thực các khối
Ngoài việc xác thực các khối, còn có ba trường hợp sử dụng chính khác yêu cầu xác thực không trạng thái hiệu quả hơn:
Mempool: Khi một giao dịch được phát sóng, các nút trong mạng P2P cần xác minh rằng giao dịch đó hợp lệ trước khi phát lại nó. Việc xác minh ngày nay bao gồm xác minh chữ ký nhưng cũng kiểm tra xem số dư có đủ và tiền tố có chính xác hay không. Trong tương lai (ví dụ: sử dụng tính năng trừu tượng hóa tài khoản gốc như EIP-7701), điều này có thể liên quan đến việc chạy một số mã EVM thực hiện một số quyền truy cập trạng thái. Nếu nút không có trạng thái thì giao dịch cần phải kèm theo bằng chứng về đối tượng trạng thái.
Danh sách bao gồm: Đây là một tính năng được đề xuất cho phép người xác nhận bằng chứng cổ phần (có thể nhỏ hơn và ít phức tạp hơn) buộc khối tiếp theo bao gồm các giao dịch bất kể mong muốn của người xây dựng khối (có thể lớn hơn và phức tạp hơn). Điều này sẽ làm suy yếu khả năng của những người có quyền lực trong việc thao túng blockchain bằng cách trì hoãn các giao dịch. Tuy nhiên, điều này đòi hỏi người xác nhận phải có cách xác minh tính hợp lệ của các giao dịch có trong danh sách.
Ứng dụng khách nhẹ: Nếu chúng tôi muốn người dùng truy cập vào một chuỗi (như Metamask, Rainbow, Rabby, v.v.) thông qua ví, để thực hiện việc này, họ cần chạy một ứng dụng khách nhẹ (như Helios). Mô-đun lõi Helios cung cấp cho người dùng một ứng dụng khách đã được xác minh. gốc trạng thái. Để có trải nghiệm hoàn toàn không cần tin cậy, người dùng cần cung cấp bằng chứng cho mọi cuộc gọi RPC mà họ thực hiện (ví dụ: đối với các yêu cầu cuộc gọi Ethernet (người dùng cần chứng minh tất cả trạng thái được truy cập trong cuộc gọi).
Điểm chung của tất cả các trường hợp sử dụng này là chúng yêu cầu khá nhiều bằng chứng, nhưng mỗi bằng chứng đều nhỏ. Do đó, bằng chứng STARK không có ý nghĩa thực tế đối với chúng; thay vào đó, cách tiếp cận thực tế nhất là sử dụng trực tiếp nhánh Merkle. Một ưu điểm khác của nhánh Merkle là nó có thể cập nhật được: đưa ra bằng chứng về đối tượng trạng thái 2 là gốc. Bằng chứng Verkle cũng có thể cập nhật được.
Các kết nối với nghiên cứu hiện tại là gì:
Những gì khác có thể được thực hiện?
Công việc chính còn lại là
1. Phân tích thêm về hậu quả của EIP-4762 (thay đổi chi phí gas không quốc tịch)
2. Cần nhiều nỗ lực hơn nữa để hoàn thiện và thử nghiệm các thủ tục chuyển tiếp, đây là một phần chính tạo nên sự phức tạp của bất kỳ kế hoạch triển khai nào đối với môi trường không quốc tịch
3. Phân tích bảo mật hơn về Poseidon, Ajtai và các hàm băm thân thiện với STARK khác
4. Phát triển hơn nữa các tính năng giao thức STARK cực kỳ hiệu quả cho việc băm bảo thủ (hoặc truyền thống), ví dụ: dựa trên quan điểm Binius hoặc GKR.
Hơn nữa, chúng tôi sẽ sớm quyết định chọn một trong ba tùy chọn sau: (i) Cây Verkle, (ii) hàm băm thân thiện với STARK và (iii) hàm băm bảo thủ. Đặc điểm của chúng có thể được tóm tắt đại khái trong bảng sau:
Ngoài những con số tiêu đề này, còn có một số điều quan trọng cần cân nhắc khác:
Ngày nay, mã cây Verkle đã khá trưởng thành. Việc sử dụng bất kỳ mã nào ngoài Verkle sẽ làm chậm quá trình triển khai và rất có thể là hard fork. Điều đó cũng không sao, đặc biệt nếu chúng tôi cần thêm thời gian để phân tích hàm băm hoặc triển khai trình xác thực hoặc nếu chúng tôi có các tính năng quan trọng khác mà chúng tôi muốn kết hợp vào Ethereum sớm hơn.
Sử dụng hàm băm để cập nhật trạng thái gốc nhanh hơn sử dụng cây Verkle. Điều này có nghĩa là cách tiếp cận dựa trên hàm băm có thể giảm thời gian đồng bộ hóa của nút đầy đủ.
Cây Verkle có thuộc tính cập nhật nhân chứng thú vị - Nhân chứng cây Verkle có thể cập nhật được. Thuộc tính này hữu ích cho mempool, bao gồm danh sách và các trường hợp sử dụng khác, đồng thời cũng có thể giúp triển khai hiệu quả hơn: nếu đối tượng trạng thái được cập nhật, nhân chứng của lớp áp chót có thể được cập nhật mà không cần đọc nội dung của lớp cuối cùng.
Cây Verkle khó chứng minh SNARK hơn. Bằng chứng Verkle đặt ra một số khó khăn nếu chúng ta muốn giảm kích thước bằng chứng xuống còn vài kilobyte. Điều này là do việc xác minh bằng chứng Verkle đưa ra một số lượng lớn các hoạt động 256-bit, yêu cầu hệ thống bằng chứng phải có tổng chi phí lớn hoặc bản thân nó có cấu trúc bên trong tùy chỉnh chứa phần bằng chứng Verkle 256-bit. Đây không phải là vấn đề với tình trạng không quốc tịch, nhưng nó tạo ra nhiều khó khăn hơn.
Nếu chúng ta muốn có được khả năng cập nhật nhân chứng Verkle theo cách an toàn lượng tử và hiệu quả hợp lý, thì một cách tiếp cận khả thi khác là cây Merkle dựa trên mạng tinh thể.
Nếu trong trường hợp xấu nhất, hệ thống không đủ hiệu quả thì chúng ta cũng có thể sử dụng công cụ không ngờ tới là khí đa chiều để bù đắp cho thiếu sót này: để (i) tính toán calldata; ) quyền truy cập trạng thái và có thể các tài nguyên khác nhau đặt ra các giới hạn gas riêng biệt. Khí đa chiều làm tăng thêm độ phức tạp, nhưng đổi lại nó hạn chế chặt chẽ hơn tỷ lệ giữa trường hợp trung bình và trường hợp xấu nhất. Với khí đa chiều, số nhánh tối đa cần chứng minh về mặt lý thuyết có thể giảm từ 12500 xuống, chẳng hạn như 3000. Điều này sẽ làm cho BLAKE 3 (hầu như không) đủ dùng cho đến ngày nay.
Khí đa chiều cho phép giới hạn tài nguyên của khối khớp chặt chẽ hơn với giới hạn tài nguyên của phần cứng cơ bản
Một công cụ không mong đợi khác là trì hoãn việc tính toán trạng thái gốc cho đến khe thời gian sau khối. Điều này cho chúng tôi đủ 12 giây để tính toán các gốc trạng thái, có nghĩa là ngay cả trong trường hợp cực đoan nhất, chỉ 60.000 băm mỗi giây là đủ thời gian chứng minh, điều này một lần nữa khiến chúng tôi nghĩ rằng BLAKE 3 chỉ có thể đáp ứng vừa đủ yêu cầu.
Nhược điểm của phương pháp này là nó bổ sung thêm một khoảng thời gian chờ cho máy khách hạng nhẹ, nhưng có những kỹ thuật thông minh hơn có thể giảm độ trễ này xuống chỉ còn độ trễ tạo bằng chứng. Ví dụ: bằng chứng có thể được phát trên mạng ngay khi bất kỳ nút nào tạo ra chúng, thay vì chờ khối tiếp theo.
Nó tương tác với các phần khác của lộ trình như thế nào?
Việc giải quyết vấn đề không quốc tịch làm tăng đáng kể độ khó của điểm cố định một người. Điều này sẽ trở nên khả thi hơn nếu có những công nghệ giúp giảm số dư tối thiểu cho việc nhắm mục tiêu một người chơi, chẳng hạn như Orbit SSF hoặc các chiến lược lớp ứng dụng như nhắm mục tiêu theo đội.
Việc phân tích khí đa chiều trở nên dễ dàng hơn nếu EOF cũng được đưa vào. Điều này là do độ phức tạp thực thi chính của khí đa chiều xuất phát từ việc xử lý các lệnh gọi con không vượt qua tất cả khí của lệnh gọi gốc và EOF có thể khiến vấn đề này trở nên tầm thường (và nguyên gốc) bằng cách đơn giản biến các lệnh gọi con đó thành bất hợp pháp. giải pháp thay thế trong giao thức cho một số trường hợp sử dụng gas chính hiện nay.
Ngoài ra còn có một sức mạnh tổng hợp quan trọng giữa xác thực không trạng thái và hết hạn lịch sử. Ngày nay, khách hàng phải lưu trữ gần một terabyte dữ liệu lịch sử; dữ liệu này lớn hơn nhiều lần so với dữ liệu trạng thái. Ngay cả khi khách hàng không có trạng thái, giấc mơ về một khách hàng gần như không có bộ nhớ sẽ không thành hiện thực trừ khi chúng tôi có thể giảm bớt trách nhiệm lưu trữ dữ liệu lịch sử cho khách hàng. Bước đầu tiên trong vấn đề này là EIP-4444, cũng có nghĩa là lưu trữ dữ liệu lịch sử trong torrent hoặc cổng trong Mạng Cổng thông tin.
Bằng chứng về tính hiệu quả của việc thực hiện EVM
Chúng ta đang cố gắng giải quyết vấn đề gì?
Mục tiêu dài hạn của việc xác minh khối Ethereum rất rõ ràng - có thể xác minh các khối Ethereum bằng cách: (i) tải xuống khối hoặc thậm chí chỉ tải xuống một mẫu nhỏ dữ liệu có sẵn trong khối; (ii) xác minh khu vực; Một bằng chứng nhỏ cho thấy khối hoạt động. Đây sẽ là một hoạt động sử dụng nguồn lực cực kỳ thấp có thể được thực hiện trong ứng dụng khách di động, ví trình duyệt hoặc thậm chí trong một chuỗi khác (không có phần sẵn có của dữ liệu).
Để đạt được điều này, cần có bằng chứng SNARK hoặc STARK cho (i) lớp đồng thuận (tức là Bằng chứng cổ phần) và (ii) lớp thực thi (tức là EVM). Bản thân vấn đề trước đây đã là một thách thức và cần được giải quyết bằng những cải tiến liên tục hơn nữa đối với lớp đồng thuận (ví dụ: đối với tính chính xác của một vị trí). Cái sau yêu cầu bằng chứng thực thi EVM.
Nó là gì và nó hoạt động như thế nào?
Về mặt hình thức, trong đặc tả Ethereum, EVM được định nghĩa là hàm chuyển đổi trạng thái: bạn có một số S ở trạng thái trước, một khối B và bạn đang tính toán trạng thái sau S = STF(S, B). Nếu người dùng đang sử dụng máy khách nhẹ, họ không sở hữu hoàn toàn S và S hoặc thậm chí E; thay vào đó, họ có gốc R trước trạng thái, gốc R sau trạng thái và hàm băm khối H.
Đầu vào công khai: gốc R trước trạng thái, gốc R sau trạng thái, hàm băm khối H
Đầu vào riêng: thân khối B, các đối tượng ở trạng thái được truy cập bởi khối Q, các đối tượng tương tự sau khi thực hiện khối Q, bằng chứng trạng thái (ví dụ: nhánh Merkle) P
Yêu cầu 1: P là bằng chứng hợp lệ cho thấy Q chứa một phần trạng thái được đại diện bởi R
Yêu cầu 2: Nếu bạn chạy STF trên Q, (i) việc thực thi chỉ truy cập các đối tượng bên trong Q, (ii) khối dữ liệu hợp lệ, (iii) kết quả là Q
Yêu cầu 3: Nếu sử dụng thông tin của Q và P để tính lại nghiệm trạng thái mới sẽ thu được R
Nếu đúng như vậy, có thể có một ứng dụng khách nhẹ xác thực hoàn toàn việc thực thi Ethereum EVM. Điều này khiến tài nguyên của khách hàng đã khá thấp. Để đạt được một ứng dụng khách Ethereum thực sự được xác minh đầy đủ, công việc tương tự cần phải được thực hiện ở khía cạnh đồng thuận.
Việc triển khai bằng chứng hợp lệ cho tính toán EVM đã tồn tại và được L2 sử dụng nhiều. Vẫn còn rất nhiều việc phải làm để làm cho bằng chứng tính hợp lệ của EVM trở nên khả thi trong L1.
Các kết nối với nghiên cứu hiện tại là gì?
Những gì khác có thể được thực hiện?
Ngày nay, tính hiệu quả của hệ thống kế toán điện tử tỏ ra còn thiếu sót ở hai lĩnh vực: tính bảo mật và thời gian xác minh.
Bằng chứng hợp lệ an toàn yêu cầu đảm bảo rằng SNARK thực sự xác minh tính toán của EVM và không có lỗ hổng nào. Hai kỹ thuật chính để cải thiện bảo mật là nhiều trình xác thực và xác minh chính thức. Trình xác thực đa năng đề cập đến việc có nhiều triển khai chứng minh tính hợp lệ được viết độc lập, giống như có nhiều ứng dụng khách và nếu một khối được chứng thực bởi một tập hợp con đủ lớn của các triển khai này thì ứng dụng khách sẽ chấp nhận phần khối đó. Xác minh chính thức bao gồm việc sử dụng các công cụ thường được sử dụng để chứng minh các định lý toán học, chẳng hạn như Lean 4, để chứng minh rằng bằng chứng hợp lệ chỉ chấp nhận việc thực thi chính xác đặc tả EVM cơ bản (chẳng hạn như ngữ nghĩa EVM K hoặc Đặc tả lớp thực thi Ethereum (EELS) được viết bằng Python) .
Thời gian xác minh đủ nhanh có nghĩa là bất kỳ khối Ethereum nào cũng có thể được xác minh trong vòng chưa đầy 4 giây. Ngày nay, chúng ta vẫn còn cách xa mục tiêu đó, mặc dù chúng ta đã tiến gần hơn nhiều so với những gì chúng ta nghĩ hai năm trước. Để đạt được mục tiêu này, chúng ta cần đạt được tiến bộ theo ba hướng:
Song song hóa – Trình xác thực EVM nhanh nhất hiện tại có thể chứng minh một khối Ethereum trong trung bình 15 giây. Nó thực hiện điều này bằng cách song song hóa hàng trăm GPU và tổng hợp công việc của chúng lại với nhau ở cuối. Về mặt lý thuyết, chúng tôi biết chính xác cách tạo trình xác minh EVM có thể chứng minh tính toán trong thời gian O(log(N)): để GPU hoàn thành từng bước và cuối cùng tạo một cây tổng hợp:
Có những thách thức trong việc đạt được điều này. Ngay cả trong trường hợp xấu nhất, khi một giao dịch rất lớn chiếm toàn bộ khối, việc phân vùng tính toán không thể được thực hiện trên mỗi lượt mà phải theo mỗi opcode (mã opcode của máy ảo cơ bản như EVM hoặc RISC-V). Việc đảm bảo rằng bộ nhớ của máy ảo vẫn nhất quán giữa các phần khác nhau của chứng thực là một thách thức chính trong quá trình triển khai. Tuy nhiên, nếu chúng ta có thể triển khai loại bằng chứng đệ quy này thì chúng ta biết rằng ít nhất vấn đề về độ trễ của người chứng minh đã được giải quyết, ngay cả khi không có sự cải thiện nào ở các khía cạnh khác.
Tối ưu hóa hệ thống chứng minh - Các hệ thống chứng minh mới như Orion, Binius, GRK và nhiều hệ thống khác có thể sẽ giúp giảm đáng kể thời gian xác minh cho các tính toán cho mục đích chung.
Những thay đổi khác về chi phí gas EVM - Nhiều thứ trong EVM có thể được tối ưu hóa để mang lại lợi ích nhiều hơn cho người chuẩn bị, đặc biệt là trong trường hợp xấu nhất. Chứng minh một khối Ethereum bình thường trong 4 giây là không đủ nếu kẻ tấn công có thể xây dựng một khối chặn trình chứng minh trong mười phút. Những thay đổi EVM cần thiết có thể được chia thành các loại sau:
- Thay đổi về chi phí gas - Nếu một hoạt động mất nhiều thời gian để chứng minh thì nó sẽ có chi phí gas cao ngay cả khi tính toán của nó tương đối nhanh. EIP-7667 là EIP được đề xuất để giải quyết vấn đề nghiêm trọng nhất về mặt này: nó làm tăng đáng kể chi phí gas của các hàm băm (truyền thống) vì các opcode và quá trình biên dịch trước của các hàm này tương đối rẻ. Để bù đắp cho sự gia tăng chi phí gas này, chúng tôi có thể giảm chi phí gas của các mã EVM có độ ổn định tương đối thấp, do đó giữ được thông lượng trung bình không đổi.
- Thay thế cấu trúc dữ liệu - Ngoài việc thay thế cây trạng thái bằng cách tiếp cận thân thiện hơn với STARK, chúng ta cũng cần thay thế danh sách giao dịch, cây biên nhận và các cấu trúc khác đang tỏ ra tốn kém. Việc chuyển cấu trúc giao dịch và biên nhận EIP của Etan Kissling sang SSZ là một bước đi theo hướng này.
Ngoài ra, hai công cụ được đề cập ở phần trước (khí đa chiều và rễ trạng thái bị trì hoãn) cũng có thể giúp ích trong vấn đề này. Tuy nhiên, cần lưu ý rằng không giống như xác minh không trạng thái, việc sử dụng hai công cụ này có nghĩa là chúng tôi đã có đủ công nghệ để thực hiện những gì chúng tôi cần hiện tại và ngay cả với những công nghệ này, Xác minh ZK-EVM đầy đủ cũng đòi hỏi nhiều công việc hơn—chỉ cần ít hơn công việc.
Một điều không được đề cập ở trên là phần cứng của bộ chứng minh: sử dụng GPU, FPGA và ASIC để tạo bằng chứng nhanh hơn. Fabric Cryptoography, Cysic và Accseal là ba công ty đang đạt được tiến bộ trong lĩnh vực này. Điều này rất có giá trị đối với L2, nhưng khó có thể là yếu tố quyết định đối với L1, vì L1 rất mong muốn duy trì tính phân cấp cao, điều đó có nghĩa là việc tạo bằng chứng phải nằm trong phạm vi hợp lý của người dùng Ethereum và không phải tuân theo Hạn chế tắc nghẽn của phần cứng của một công ty. L2 có thể tạo ra sự đánh đổi tích cực hơn.
Trong những lĩnh vực này, vẫn còn nhiều việc phải làm:
Bằng chứng song song hóa yêu cầu chứng minh rằng các phần khác nhau của hệ thống có thể chia sẻ bộ nhớ (chẳng hạn như bảng tra cứu). Chúng tôi biết công nghệ có thể làm được điều này nhưng nó cần phải được triển khai.
Chúng tôi cần phân tích nhiều hơn để tìm ra tập hợp các biến thể chi phí gas lý tưởng nhằm giảm thiểu thời gian xác minh trong trường hợp xấu nhất.
Chúng ta cần phải làm nhiều việc hơn nữa để chứng minh các hệ thống
Các chi phí có thể là:
Bảo mật so với thời gian của trình xác thực: Có thể giảm thời gian của trình xác thực nếu bạn chọn hàm băm linh hoạt hơn, hệ thống chứng minh phức tạp hơn hoặc các giả định bảo mật linh hoạt hơn hoặc các giải pháp thiết kế khác.
Phân cấp và thời gian chứng minh: Cộng đồng cần thống nhất về thông số kỹ thuật của phần cứng chứng thực đang được nhắm mục tiêu. Có được yêu cầu người chứng nhận phải là đơn vị có quy mô lớn không? Chúng ta có mong đợi máy tính xách tay tiêu dùng cao cấp sẽ chứng minh được khối Ethereum trong 4 giây không? Đâu đó ở giữa?
Mức độ mà khả năng tương thích ngược bị phá vỡ: Những thiếu sót khác có thể được bù đắp bằng những thay đổi mạnh mẽ hơn về chi phí gas, nhưng điều này có nhiều khả năng làm tăng chi phí cho một số ứng dụng một cách không tương xứng, buộc các nhà phát triển phải viết lại và triển khai lại mã để duy trì hiệu quả kinh tế. Tương tự như vậy, cả hai công cụ đều có sự phức tạp và hạn chế riêng.
Nó tương tác với các phần khác của lộ trình như thế nào?
Công nghệ cốt lõi cần thiết để triển khai bằng chứng xác thực L1 EVM phần lớn được chia sẻ với hai lĩnh vực còn lại:
Bằng chứng về tính hợp lệ của L2 (tức là tổng hợp ZK)
Phương pháp Bằng chứng băm nhị phân STARK không quốc tịch
Việc triển khai thành công bằng chứng xác thực trong L1 cuối cùng sẽ cho phép một người đặt cược dễ dàng: ngay cả máy tính yếu nhất (bao gồm điện thoại di động hoặc đồng hồ thông minh) cũng có thể đặt cược. Điều này càng làm tăng giá trị của việc giải quyết các hạn chế khác của việc đặt cược đơn lẻ, chẳng hạn như mức tối thiểu 32 ETH.
Ngoài ra, hiệu lực EVM của L1 chứng tỏ rằng giới hạn gas của L1 có thể được cải thiện đáng kể.
Bằng chứng về tính hợp lệ của sự đồng thuận
Chúng ta đang cố gắng giải quyết vấn đề gì?
Nếu chúng tôi muốn xác minh đầy đủ một khối Ethereum bằng SNARK, thì việc thực thi EVM không phải là phần duy nhất chúng tôi cần chứng minh. Chúng tôi cũng cần bằng chứng về sự đồng thuận, một phần của hệ thống xử lý tiền gửi, rút tiền, chữ ký, cập nhật số dư của người xác thực và các yếu tố khác của phần bằng chứng cổ phần của Ethereum.
Sự đồng thuận đơn giản hơn nhiều so với EVM, nhưng thách thức là chúng ta không có các cấu trúc L2 EVM, vì vậy hầu hết công việc vẫn phải được thực hiện. Do đó, bất kỳ việc triển khai sự đồng thuận bằng chứng nào của Ethereum sẽ cần phải được bắt đầu lại từ đầu, mặc dù bản thân hệ thống bằng chứng là một nỗ lực chung có thể được xây dựng dựa trên đó.
Nó là gì và nó hoạt động như thế nào?
Chuỗi đèn hiệu được định nghĩa là chức năng chuyển trạng thái, giống như EVM. Hàm chuyển trạng thái chủ yếu bao gồm ba phần:
ECADD (để xác minh chữ ký BLS)
Ghép nối (để xác minh chữ ký BLS)
Hàm băm SHA 256 (dùng để đọc và cập nhật trạng thái)
Trong mỗi khối, chúng tôi cần chứng minh 1-16 BLS 12-381 ECADD cho mỗi trình xác thực (có thể nhiều hơn một, vì chữ ký có thể được bao gồm trong nhiều bộ). Điều này có thể được bù đắp bằng các kỹ thuật tính toán trước tập hợp con, vì vậy chúng tôi có thể nói rằng mỗi người xác minh chỉ cần chứng minh một BLS 12-381 ECADD. Hiện tại, có 30.000 chữ ký xác thực trên mỗi vị trí. Trong tương lai, khi đạt được mục đích cuối cùng của một vị trí, tình huống này có thể thay đổi theo hai hướng: nếu chúng ta đi theo con đường bạo lực, số lượng người xác nhận trên mỗi vị trí có thể tăng lên 1 triệu. Đồng thời, nếu Orbit SSF được thông qua, số lượng người xác thực sẽ vẫn ở mức 32.768 hoặc thậm chí giảm xuống còn 8.192.
Cách tổng hợp BLS hoạt động: Việc xác minh tổng số chữ ký chỉ yêu cầu một ECADD cho mỗi người tham gia, không phải ECMUL. Nhưng 30.000 ECADD vẫn là bằng chứng rất lớn.
Về mặt ghép nối, hiện có tối đa 128 bằng chứng cho mỗi vị trí, nghĩa là cần phải xác minh 128 cặp. Với ElP-7549 và các sửa đổi tiếp theo, con số này có thể giảm xuống còn 16 mỗi khe. Số lượng cặp ít nhưng chi phí cực kỳ cao: mỗi cặp mất nhiều thời gian hơn để chạy (hoặc chứng minh) hàng nghìn lần so với ECADD.
Một thách thức lớn trong việc chứng minh các hoạt động BLS 12-381 là không có đường cong thuận tiện với thứ tự đường cong bằng kích thước trường BLS 12-381, điều này làm tăng thêm chi phí đáng kể cho bất kỳ hệ thống chứng minh nào. Mặt khác, cây Verkle được đề xuất cho Ethereum được xây dựng bằng các đường cong Bandersnatch, khiến bản thân BLS 12-381 trở thành đường cong tự thân được sử dụng để chứng minh các nhánh Verkle trong hệ thống SNARK. Việc thực hiện tương đối đơn giản có thể chứng minh được 100 G 1 phép cộng mỗi giây; việc thực hiện phép chứng minh đủ nhanh gần như chắc chắn sẽ đòi hỏi những kỹ thuật thông minh như GKR.
Trường hợp xấu nhất hiện nay đối với hàm băm SHA 256 là khối chuyển tiếp kỷ nguyên trong đó toàn bộ cây số dư ngắn của trình xác thực và số lượng lớn số dư của trình xác thực được cập nhật. Cây cân bằng ngắn cho mỗi trình xác thực chỉ có một byte, do đó 1 MB dữ liệu được băm lại. Điều này tương đương với 32768 cuộc gọi SHA 256. Nếu một nghìn số dư của người xác nhận ở trên hoặc dưới ngưỡng, thì số dư hợp lệ trong bản ghi của người xác thực cần được cập nhật, tương đương với một nghìn nhánh Merkle và do đó có thể yêu cầu mười nghìn hàm băm. Cơ chế xáo trộn yêu cầu 90 bit cho mỗi trình xác nhận (và do đó là 11 MB dữ liệu), nhưng điều này có thể được tính toán bất kỳ lúc nào trong một kỷ nguyên. Trong trường hợp kết cuối một khe, những con số này có thể tăng hoặc giảm tùy theo từng trường hợp. Việc xáo trộn trở nên không cần thiết, mặc dù Orbit có thể khôi phục nhu cầu đó ở một mức độ nào đó.
Một thách thức khác là cần phải lấy lại tất cả các trạng thái của trình xác thực, bao gồm cả khóa chung, để xác thực một khối. Đối với 1 triệu trình xác thực, chỉ riêng việc đọc khóa chung sẽ cần 48 triệu byte, cộng với nhánh Merkle. Điều này đòi hỏi hàng triệu hàm băm mỗi kỷ nguyên. Nếu chúng tôi phải chứng minh tính hợp lệ của PoS, thì một cách tiếp cận thực tế sẽ là một số dạng tính toán có thể kiểm chứng tăng dần: lưu trữ một cấu trúc dữ liệu duy nhất trong hệ thống chứng minh được tối ưu hóa để tra cứu hiệu quả và chứng minh rằng Cấu trúc cập nhật.
Nói chung là có rất nhiều thử thách. Để giải quyết những thách thức này một cách hiệu quả nhất có thể sẽ cần phải thiết kế lại sâu hơn chuỗi đèn hiệu, điều này có thể trùng hợp với việc chuyển sang chấm dứt một khe. Các tính năng của thiết kế lại này có thể bao gồm:
Thay đổi hàm băm: Hàm băm SHA 256 đầy đủ hiện đã được sử dụng, do đó, có hai lệnh gọi đến hàm nén cơ bản cho mỗi lệnh gọi do có phần đệm. Thay vào đó, nếu chúng tôi sử dụng chức năng nén SHA 256, chúng tôi sẽ nhận được mức tăng ít nhất gấp 2 lần. Thay vào đó, nếu chúng tôi sử dụng Poseidon, chúng tôi có thể đạt được mức tăng gấp 100 lần, giải quyết hoàn toàn mọi vấn đề của chúng tôi (ít nhất là về mặt băm): ở mức 1,7 triệu băm mỗi giây (54 MB), thậm chí với một triệu xác minh, các bản ghi cũng có thể được đọc thành bằng chứng trong vài giây.
Trong trường hợp Orbit, lưu trữ trực tiếp các bản ghi trình xác nhận được xáo trộn: nếu một số lượng trình xác nhận nhất định (như 8192 hoặc 32768) được chọn làm ủy ban cho một vị trí nhất định, hãy đặt chúng trực tiếp vào trạng thái cạnh nhau, như thế này Chỉ cần băm tối thiểu để đọc khóa chung của tất cả các trình xác nhận vào bằng chứng. Điều này cũng cho phép tất cả các cập nhật số dư được hoàn thành một cách hiệu quả.
Tập hợp chữ ký: Bất kỳ sơ đồ tổng hợp chữ ký hiệu suất cao nào cũng sẽ liên quan đến một số loại bằng chứng đệ quy, trong đó các nút khác nhau trong mạng thực hiện bằng chứng trung gian trên một tập hợp con chữ ký. Điều này phân phối công việc chứng minh đến nhiều nút trong mạng một cách tự nhiên, do đó giảm đáng kể khối lượng công việc của người chứng minh cuối cùng.
Các lược đồ chữ ký khác: Đối với chữ ký Lamport+Merkle, chúng tôi cần 256 + 32 giá trị băm để xác minh chữ ký; nhân với 32768 người ký, chúng tôi nhận được 9437184 giá trị băm. Sau khi tối ưu hóa sơ đồ chữ ký, kết quả này có thể được cải thiện hơn nữa bằng hệ số không đổi nhỏ. Điều này được thể hiện trong một ô duy nhất nếu chúng ta sử dụng Poseidon. Nhưng trong thực tế, sử dụng sơ đồ tổng hợp đệ quy sẽ nhanh hơn.
Các kết nối với nghiên cứu hiện tại là gì?
Những công việc còn lại phải làm và cách lựa chọn:
Trên thực tế, sẽ mất nhiều năm trước khi chúng ta có được bằng chứng về tính hợp lệ của sự đồng thuận Ethereum. Đây gần bằng khoảng thời gian mà chúng tôi cần để triển khai tính chất cuối cùng của một khe, Orbit, sửa đổi thuật toán chữ ký và phân tích bảo mật đòi hỏi đủ độ tin cậy để sử dụng hàm băm tích cực như Poseidon. Do đó, điều khôn ngoan nhất cần làm là giải quyết những vấn đề khác này và làm như vậy trong khi vẫn lưu ý đến sự thân thiện với STARK.
Sự đánh đổi chính có thể nằm ở thứ tự hoạt động, giữa cách tiếp cận gia tăng hơn để cải tổ lớp đồng thuận Ethereum và cách tiếp cận thay đổi nhiều cùng một lúc triệt để hơn. Đối với EVM, cách tiếp cận gia tăng có ý nghĩa vì nó giảm thiểu sự gián đoạn đối với khả năng tương thích ngược. Sẽ có ít tác động tương thích ngược hơn đối với lớp đồng thuận và cũng sẽ có lợi khi xem xét lại toàn diện hơn về các chi tiết khác nhau về cách chuỗi đèn hiệu được xây dựng để tối ưu hóa tốt nhất tính thân thiện với SNARK.
Nó tương tác với các phần khác của lộ trình như thế nào?
Trong quá trình thiết kế lại Ethereum PoS dài hạn, tính thân thiện của STARK phải được cân nhắc hàng đầu, đặc biệt là tính hữu hạn của một khe cắm, Quỹ đạo, thay đổi sơ đồ chữ ký và tổng hợp chữ ký.
