Trước khi đọc: "Vitalik về tương lai có thể của Ethereum (phần 1): The Merge", "Vitalik về tương lai có thể của Ethereum (phần 2): The Surge", "Vitalik về tương lai có thể của Ethereum (phần 3): The Scourge"
Đặc biệt cảm ơn Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams và Uma Roy đã đóng góp ý kiến và xem xét.
Một trong những tính năng mạnh mẽ nhất của Khối chuỗi là bất kỳ ai cũng có thể chạy một Nút trên máy tính của họ và xác minh tính chính xác của Khối chuỗi. Ngay cả khi 9596 Nút chạy Nhận thức chung chuỗi (PoW, PoS) đồng ý ngay lập tức thay đổi quy tắc và bắt đầu sản xuất Khối theo quy tắc mới, mọi người chạy Nút xác minh đầy đủ sẽ từ chối chấp nhận chuỗi. Người tạo ra tiền không phải là một phần của nhóm âm mưu này sẽ tự động tập hợp vào một chuỗi on-chain tiếp tục tuân theo quy tắc cũ và tiếp tục xây dựng chuỗi này, trong khi người dùng xác minh đầy đủ sẽ tuân theo chuỗi này.
Điều này là sự khác biệt chính giữa blockchain và hệ thống tập trung. Tuy nhiên, để điều này trở thành sự thật, việc vận hành một Nút được xác minh đầy đủ cần phải khả thi đối với đủ số người. Điều này áp dụng cho cả người tạo ra sự lan truyền (vì nếu họ không xác minh chuỗi, họ sẽ không đóng góp vào việc thực hiện các quy tắc giao thức), cũng như người dùng thông thường. Hiện nay, việc vận hành Nút được xác minh đầy đủ trên các laptop tiêu dùng (bao gồm cả laptop được sử dụng khi viết bài này) là khả thi, nhưng thực hiện điều này là rất khó khăn. The Verge muốn thay đổi tình hình này bằng cách giảm chi phí tính toán của chuỗi được xác minh đầy đủ, và mặc định mỗi điện thoại di động Ví tiền, trình duyệt Ví tiền và thậm chí cả đồng hồ thông minh đều sẽ thực hiện xác minh.
Bản đồ đường 2023 của The Verge
Ban đầu, "Verge" đề cập đến việc chuyển trạng thái lưu trữ ETH từ cây Verkle - một cấu trúc cây cho phép chứng minh nhỏ gọn hơn, để xác minh trạng thái không cần thiết lưu trữ bất kỳ trạng thái ETH nào (số dư tài khoản, mã hợp đồng, không gian lưu trữ...) trên đĩa cứng. Nút có thể xác minh một khối ETH mà không cần lưu trữ bất kỳ trạng thái ETH nào trên đĩa cứng (số dư tài khoản, mã hợp đồng, không gian lưu trữ...), điều đó có giá là mất vài trăm KB dữ liệu chứng minh và thời gian bổ sung vài trăm mili giây để xác minh một chứng minh. Ngày nay, Verge đại diện cho một tầm nhìn lớn hơn, tập trung vào việc thực hiện xác minh tài nguyên tối đa trên chuỗi ETH, bao gồm không chỉ công nghệ xác minh trạng thái không cần thiết mà còn bao gồm việc sử dụng SNARK xác minh tất cả các giao dịch ETH.
Ngoài việc xác minh sự theo dõi lâu dài của toàn bộ chuỗi chống lại SNARK, một câu hỏi mới khác liên quan đến việc liệu cây Verkle có phải là kỹ thuật tốt nhất hay không. Cây Verkle dễ bị tổn thương bởi Máy tính lượng tử, vì vậy nếu chúng ta lấy cây Verkle trong cây KECCAK Merkle Patricia hiện tại, chúng ta sẽ phải thay thế cây một lần nữa trong tương lai. Một cách tự thay thế cho cây Merkle là chỉ cần bỏ qua STARK sử dụng nhánh Merkle và đặt nó vào một 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 chi phí và sự phức tạp về kỹ thuật. Tuy nhiên, gần đây, chúng ta đã thấy Starkware chứng minh 1,7 triệu Poseidon Hàm băm mỗi giây bằng cách sử dụng ckcle STARKs trên một máy tính xách tay duy nhất và nhờ các công nghệ như GKB, thời gian chứng minh cho các giá trị Hàm băm "truyền thống" hơn cũng đang giảm nhanh chóng. 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: Không cần nhiều hơn một vài gigabyte dung lượng lưu trữ để xác thực đầy đủ máy khách và nút thẻ.
· (Long-term) hoàn toàn xác minh chuỗi trên đồng hồ thông minh (Nhận thức chung và thực hiện). Tải xuống một số dữ liệu, xác minh SNARK, hoàn thành.
Trong chương này
· Máy khách không trạng thái: Verkle hay STARKs
· EVM 执行的bằng chứng hợp lệ
· Nhận thức chung的bằng chứng hợp lệ
Xác minh không trạng thái: Verkle hay STARKs
Chúng ta đang giải quyết vấn đề gì?
Ngày nay, khách hàng ETH cần lưu trữ hàng trăm tỷ byte dữ liệu trạng thái để xác minh Khối, và số lượng này tăng lên hàng năm. Dữ liệu trạng thái gốc tăng khoảng 30GB mỗi năm, một khách hàng duy nhất phải lưu trữ một số dữ liệu bổ sung trên đó để cập nhật bộ ba một cách hiệu quả.
Điều này giới hạn số lượng người dùng có thể chạy Nút Ethereum đầy đủ xác minh: mặc dù có thể lưu trữ toàn bộ trạng thái Ethereum và lịch sử nhiều năm trên ổ cứng lớn, nhưng máy tính mà mọi người thường mua chỉ có vài trăm đến vài nghìn gigabyte dung lượng lưu trữ. Kích thước trạng thái cũng gây ra rất nhiều sự cản trở trong quá trình thiết lập Nút lần đầu: Nút cần tải xuống toàn bộ trạng thái, điều này có thể mất từ vài giờ đến vài ngày. Điều này dẫn đến nhiều tác động lan truyền. Ví dụ, nó làm tăng đáng kể độ khó khi người tạo Nút nâng cấp cấu hình Nút của họ. Về mặt kỹ thuật, nâng cấp có thể được hoàn thành mà không cần tắt máy - khởi động một phiên bản mới của khách hàng, chờ đồng bộ hóa sau đó đóng phiên bản cũ và chuyển giao Chìa khoá bảo mật - nhưng trong thực tế, việc 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à một công nghệ cho phép Nút xác minh Khối mà không cần kiểm soát toàn bộ trạng thái. Thay vào đó, mỗi Khối được đính kèm với một bằng chứng bao gồm: (i) giá trị, mã, số dư và lưu trữ của vị trí cụ thể trong trạng thái mà Khối sẽ truy cập; (ii) chứng minh rằng các giá trị này đã được mã hóa đúng.
Trong thực tế, việc thực hiện xác minh không trạng thái đòi hỏi thay đổi cấu trúc cây trạng thái của Ethereum. Điều này bởi vì cây Merkle Patricia hiện tại rất không thân thiện với bất kỳ hệ thống chứng minh mã hóa nào, đặc biệt là trong trường hợp xấu nhất. Cả 'nhánh' Merkle ban đầu lẫn khả năng 'đóng gói' thành STARK đều vậy. Khó khăn chính đến từ một số điểm yếu của MPT:
Đây là một cây sáu nhánh (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 chứng minh trung bình cần khoảng 32*(16-1)log16(N) = 120 log2(N) byte, hoặc khoảng 3840 byte trong một cây với 2^32 mục. Đối với cây nhị phân, chỉ cần 32*(2-1)log2(N) = 32 log2(N) byte, hoặc khoảng 1024 byte.
Mã không được Merkle hóa. Điều này có nghĩa là để chứng minh quyền truy cập vào mã tài khoản, bạn cần cung cấp toàn bộ mã, tối đa là 24000 byte.
Chúng ta có thể tính toán trường hợp tồi nhất như sau:
30000000 gas / 2400 (tài khoản lạnh đọc chi phí) *（5 * 488 + 24000) = 330000000 byte
Chi phí nhánh nhỏ hơn một chút (sử dụng 5480 thay vì 8480) do phần đầu của nó được lặp lại khi có nhiều nhánh hơn. Tuy nhiên, thậm chí trong một khe thời gian, lượng dữ liệu cần tải xuống cũng là không thể thực hiện được. Nếu chúng ta cố gắng sử dụng STARK để đóng gói nó, chúng ta sẽ gặp hai vấn đề: (i) KECCAK không thân thiện với STARK; (ii) Dữ liệu 330MB có nghĩa là chúng ta phải chứng minh 5 triệu lần gọi hàm round của KECCAK, điều này có thể không thể chứng minh được đối với tất cả các phần cứng trừ các phần cứng tiêu dùng mạnh nhất, ngay cả khi chúng ta có thể làm cho việc chứng minh KECCAK trở nên hiệu quả hơn bằng STARK.
Nếu chúng ta thay thế cây nhị phân bằng cây thập lục phân trực tiếp và xử lý mã bằng cách thêm Merkle, thì trong trường hợp xấu nhất sẽ trở thành khoảng 30000000/240032(32-14+8) = 10400000 byte (14 là phép trừ cho các bit dư thừa của 2^14 nhánh và 8 là độ dài chứng minh cho các lá trong khối mã). Cần lưu ý rằng điều này sẽ thay đổi chi phí gas, tính phí cho việc truy cập vào mỗi khối mã riêng lẻ; EIP-4762 đã thực hiện điều này. Dung lượng 10,4 MB tốt hơn nhiều, nhưng đối với nhiều Nút, dữ liệu tải xuống trong một khe thời gian vẫn quá nhiều. Do đó, chúng ta cần giới thiệu các công nghệ mạnh mẽ hơn. Trong lĩnh vực này, có hai giải pháp hàng đầu: cây Verkle và cây băm nhị phân STARKed.
Cây Verkle
Verkle 树 sử dụng cam kết vector dựa trên đường cong elip để tạo ra chứng minh ngắn hơn. Chìa khóa được mở ra ở chỗ, bất kể chiều rộng của cây như thế nào, mỗi phần chứng minh tương ứng với mối quan hệ cha con chỉ có 32 byte. Giới hạn duy nhất của chiều rộng cây chứng minh là nếu cây chứng minh quá rộng, hiệu suất tính toán của chứng minh sẽ bị ảnh hưởng. Giải pháp triển khai cho Ethereum có chiều rộng là 256.
Do đó, kích thước của một nhánh trong bằng 32 - 1og256(N) = 4* log2(N) byte. Do đó, kích thước chứng minh tối đa 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ế có thể khác nhau một chút do phân phối khối trạng thái không đồng đều, nhưng là xấp xỉ đầu tiên).
Ngoài ra, điều cần lưu ý 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 tồi tệ hơn là kẻ tấn công cố ý 'đào' hai địa chỉ Địa chỉ và làm cho chúng có tiền tố chung dài hơn trong cây và đọc dữ liệu từ một địa chỉ Địa chỉ, điều này có thể kéo dài chiều dài của nhánh xấu nhất thêm gấp đôi. Tuy nhiên, ngay cả khi có trường hợp như vậy, độ dài chứng minh xấu nhất của cây Verkle là 2,6MB, tương tự như dữ liệu xác minh xấu nhất hiện tại.
Chúng tôi cũng đã sử dụng lưu ý này để thực hiện một điều khác: chúng tôi đã làm cho chi phí truy cập không gian lưu trữ "liền kề" trở nên rất thấp: hoặc là nhiều khối mã của cùng một hợp đồng, hoặc là các khe lưu trữ kế cận. EIP-4762 cung cấp định nghĩa về liền kề, chỉ thu 200 gas cho việc truy cập liền kề. Trong trường hợp truy cập liền kề, kích thước chứng minh trong trường hợp xấu nhất trở thành 30000000 / 200*32 - 4800800 byte, điều này vẫn nằm trong khoảng sai số. Nếu vì lý do an toàn mà chúng ta muốn giảm giá trị này, chúng ta có thể tăng giá trị truy cập liền kề một chút.
Cây băm nhị phân STARKed
Nguyên tắc của công nghệ này rất rõ ràng: Bạn chỉ cần tạo một cây nhị phân, lấy chứng chỉ tối đa 10,4 MB, chứng minh giá trị trong khối, sau đó thay thế chứng chỉ bằng STARK đã được chứng minh. Như vậy, chứng chỉ chính nó chỉ chứa dữ liệu được chứng minh, cộng thêm chi phí cố định từ STARK thực tế là 100-300kB.
Thách thức chính ở đây là xác minh thời gian. Chúng ta có thể thực hiện các tính toán tương tự như trên, chỉ khác ở chỗ chúng ta không tính số byte mà là giá trị băm. Một Khối có kích thước 10,4 MB có nghĩa là 330.000 giá trị băm. Nếu nhìn vào khả năng "đào" các Địa chỉ cây có tiềm năng có tiền tố công cộng dài hơn, thì số lượng giá trị băm trong trường hợp xấu nhất sẽ khoảng 660.000 giá trị băm. Vì vậy, nếu chúng ta có thể chứng minh rằng mỗi giây có 200.000 giá trị băm, thì không có vấn đề gì.
Trên các laptop tiêu dùng sử dụng Hàm băm Poseidon, các con số này đã đạt được 01928374656574839201, trong khi Hàm băm Poseidon được thiết kế đặc biệt cho tính thân thiện với STARK. Tuy nhiên, hệ thống Poseidon vẫn chưa hoàn thiện, vì vậy nhiều người vẫn không tin tưởng vào tính an toàn của nó. Do đó, có hai con đường thực tế để tiến lên:
Nhanh chóng phân tích an ninh lượng lớn cho Poseidon và làm quen đủ để triển khai trên L1
Sử dụng hàm băm "bảo thủ" hơn, như SHA256 hoặc BLAKE
Để chứng minh hàm băm bảo mật, vòng STARK của Starkware chỉ có thể chứng minh từ 10-30k giá trị băm mỗi giây trên các máy tính xách tay tiêu dùng khi viết bài này. Tuy nhiên, công nghệ STARK đang được cải tiến nhanh chóng. Ngay cả ngày nay, công nghệ dựa trên GKR cũng cho thấy có thể nâng tốc độ này lên trong khoảng từ 100-2O0k.
Trường hợp sử dụng chứng thực ngoại trừ khối
Ngoài việc xác minh Khối, còn ba trường hợp sử dụng chính cần xác minh không trạng thái hiệu quả hơn:
· Bể nhớ: Khi giao dịch được phổ biến, Nút trong mạng P2P cần xác minh tính hợp lệ của giao dịch trước khi phát lại. Hiện nay, việc xác minh bao gồm việc xác minh chữ ký, cũng như 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 trừu tượng hóa tài khoản nguyên bản, như EIP-7701), điều này có thể liên quan đến việc chạy một số mã EVM, những mã này sẽ thực hiện một số truy cập trạng thái. Nếu Nút không có trạng thái, thì giao dịch cần đi kèm với chứng minh của đối tượng trạng thái.
· Danh sách bao gồm: Đây là một tính năng đề xuất, cho phép (có thể là quy mô nhỏ và không phức tạp) Bằng chứng về cổ phầnNgười xác thực buộcKhối tiếp theo chứa các giao dịch mà không quan tâm đến ý định củaKhối xây dựng (có thể là quy mô lớn và phức tạp). Điều này sẽ làm suy yếu khả năng của những người có quyền lực thao tácKhối chuỗi bằng cách tạoTrễ giao dịch. Tuy nhiên, điều này đòi hỏiNgười xác thực phải có cách để xác minh tính hợp lệ của các giao dịch trong danh sách bao gồm.
· khách hàng ánh sáng: Nếu chúng ta muốn người dùng truy cập chuỗi thông qua ví (như Metamask, Rainbow, Rabby, v.v.), để làm được điều này, họ cần chạy một khách hàng ánh sáng (như Helios). Helios cung cấp cho người dùng một gốc trạng thái đã được xác minh. Để có trải nghiệm hoàn toàn không tin cậy, người dùng cần cung cấp chứng minh cho mỗi cuộc gọi RPC mà họ thực hiện (ví dụ, cho yêu cầu gọi mạng ETH (người dùng cần chứng minh tất cả các trạng thái được truy cập trong quá trình gọi)).
Tất cả các trường hợp sử dụng này đều có một điểm chung, đó là chúng đều yêu cầu rất nhiều bằng chứng, nhưng mỗi bằng chứng đều rất nhỏ. Do đó, chứng minh STARK không có ý nghĩa thực tế cho chúng; thay vào đó, cách tiếp cận thực tế nhất là sử dụng nhánh Merkle trực tiếp. Một lợi ích khác của nhánh Merkle là có thể cập nhật: với bằng chứng của một đối tượng trạng thái X có gốc là Khối B, nếu nhận được một Khối con B2 và chứng cứ tương ứng của nó, bằng chứng có thể được cập nhật để có gốc là Khối B2. Chứng minh Verkle cũng có thể cập nhật tự nhiên.
Có liên hệ nào với nghiên cứu hiện có:
· cây Verkle
· Bản gốc của bài báo về cây Verkle do John Kuszmaul viết
· Starkware
· Bài báo Poseidon2
· Ajtai (Hàm băm nhanh thay thế dựa trên độ cứng của lưới tinh thể)
· Verkle.info
Còn gì khác mà có thể làm?
Công việc chính còn lại là
Phân tích thêm về hậu quả của EIP-4762 (Thay đổi chi phí gas không có trạng thái)
Hoàn thành và thử nghiệm nhiều công việc chuyển tiếp, đây là phần chính của sự phức tạp của bất kỳ giải pháp triển khai không quốc gia nào.
Phân tích an ninh thêm về các hàm băm Poseidon, Ajtai và các hàm băm "STARK-friendly" khác
Ngoài ra, chúng tôi sẽ nhanh chóng quyết định chọn một trong ba lựa 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ác đặc điểm của chúng có thể tóm tắt như sau:
Ngoài những "số tiêu đề" này, còn có một số yếu tố quan trọng khác cần xem xét:
· Hiện nay, mã cây Verkle đã khá thành thục. Ngoài Verkle, việc sử dụng bất kỳ mã nào khác sẽ gây trì hoãn triển khai và có thể gây trì hoãn một fork cứng. Điều này cũng không quan trọng, đặc biệt là nếu chúng ta cần thêm thời gian để phân tích hàm băm hoặc triển khai bộ xác minh, hoặc chúng ta có các tính năng quan trọng khác mà chúng ta muốn sớm hơn để tích hợp vào Ethereum.
· Cập nhật gốc trạng thái bằng giá trị băm nhanh hơn sử dụng cây Verkle. Điều này có nghĩa là phương pháp dựa trên giá trị băm có thể giảm thời gian đồng bộ hóa Toàn bộ nút.
· Cây Verkle có thuộc tính cập nhật chứng minh thú vị - Chứng minh thú của cây Verkle có thể được cập nhật. Thuộc tính này hữu ích cho mempool, danh sách chứa và các trường hợp sử dụng khác, và cũng có thể giúp cải thiện hiệu suất triển khai: nếu trạng thái đối tượng được cập nhật, có thể cập nhật chứng minh của lớp thứ hai từ dưới lên mà không cần đọc nội dung của lớp cuối cùng.
· Việc chứng minh SNARK trở nên khó khăn hơn với cây Verkle. Nếu chúng ta muốn giữ kích thước chứng minh luôn giảm xuống đến vài nghìn byte, thì chứng minh Verkle sẽ gặp một số khó khăn. Điều này là do quá trình xác minh chứng minh Verkle đưa vào rất nhiều hoạt động 256 bit, điều này đòi hỏi hệ thống chứng minh phải có chi phí lớn hoặc có cấu trúc nội bộ được tùy chỉnh, bao gồm phần chứng minh Verkle 256 bit. Điều này không phải là vấn đề đối với trạng thái không có vấn đề, nhưng sẽ mang lại nhiều khó khăn hơn.
Nếu chúng ta muốn có một cách để có được tính tương thích với Verkle một cách an toàn với lượng lớn và hiệu quả một cách hợp lý, một cách khác có thể là dựa trên cây Merkle dựa trên lattice.
Nếu trong trường hợp xấu nhất, chứng minh hiệu suất của hệ thống không đủ cao, chúng ta có thể sử dụng công cụ gas đa chiều bất ngờ này để bù đắp cho điều đó: đặt giới hạn gas riêng cho (i) calldata; (ii) tính toán; (iii) truy cập trạng thái và có thể là các tài nguyên khác khác nhau. Gas đa chiều tăng thêm sự phức tạp, nhưng như một sự trao đổi, nó giới hạn chặt chẽ tỷ lệ giữa trường hợp trung bình và trường hợp xấu nhất. Với gas đa chiều, số lượng nhánh cần chứng minh lý thuyết tối đa có thể giảm từ 12500 xuống 3000 chẳng hạn. Điều này sẽ khiến cho BLAKE3 (vào lúc này) đủ sức để sử dụng dù chỉ là sức ép.
Đa chiều gas cho phép giới hạn tài nguyên của Khối gần với giới hạn tài nguyên của phần cứng cấp dưới hơn
Một công cụ không ngờ khác là tính toán trạng thái gốc Trễ vào thời khóa sau Khối. Điều này nghĩa là chúng ta có 12 giây để tính toán trạng thái gốc, có nghĩa là ngay cả trong trường hợp cực đoan, thời gian chứng minh với 60000 lần băm mỗi giây cũng đủ, điều này một lần nữa khiến chúng ta nghĩ rằng BLAKE3 chỉ đáng giá đủ.
Phương pháp này có nhược điểm là nó sẽ tăng thêm một khung thời gian Trễ cho khách hàng ánh sáng, nhưng cũng có các kỹ thuật tinh vi hơn có thể giảm Trễ này xuống chỉ còn đối với việc tạo ra chứng minh. Ví dụ, chứng minh có thể được phát sóng trên mạng ngay sau khi được tạo ra tại bất kỳ nút nào, thay vì chờ đến khối tiếp theo.
Nó tương tác với các phần khác của bản đồ đường đi như thế nào?
Giải quyết vấn đề không trạng thái đã tăng đáng kể độ khó của việc điểm đặt đơn lẻ. Nếu có công nghệ để giảm thiểu cân bằng tối thiểu đơn lẻ như Orbit SSF hoặc chiến lược Lớp ứng dụng như điểm đặt nhóm nhỏ, điều này sẽ trở nên khả thi hơn.
Nếu đồng thời giới thiệu EOF, phân tích gas đa chiều sẽ trở nên dễ dàng hơn. Điều này bởi vì độ phức tạp thực hiện chính của gas đa chiều đến từ việc xử lý các cuộc gọi con không chuyển toàn bộ gas của cuộc gọi cha, trong khi EOF chỉ cần đánh dấu các cuộc gọi con này là không hợp lệ, vấn đề này sẽ trở nên không đáng kể (và cung cấp một phương án thay thế giao thức bên trong cho một phần sử dụng gas chính hiện tại của tài khoản cục bộ).
Giữa việc xác minh không trạng thái và lịch sử hết hạn, còn có một tác động cộng tác quan trọng. Hiện nay, các máy khách phải lưu trữ gần 1TB dữ liệu lịch sử; dữ liệu này nhiều lần so với dữ liệu trạng thái. Ngay cả khi máy khách là không trạng thái, nếu chúng ta không thể giải phóng trách nhiệm lưu trữ dữ liệu lịch sử của máy khách, thì gần như không thể thực hiện được ước mơ không lưu trữ của máy khách. Bước đầu tiên trong việc này là EIP-4444, điều này cũng có nghĩa là lưu trữ dữ liệu lịch sử trên torrents hoặc Portal Network.
EVM 执行的bằng chứng hợp lệ
Chúng ta đang giải quyết vấn đề gì?
Ether Khối xác minh có mục tiêu dài hạn rất rõ ràng - nên có thể xác minh Ether Khối theo cách sau: (i) Tải xuống Khối, hoặc thậm chí chỉ tải xuống một phần nhỏ của dữ liệu có sẵn trong Khối; (ii) Xác minh một chứng cứ nhỏ hợp lệ của Khối. Điều này sẽ là một hoạt động tài nguyên rất thấp, có thể thực hiện trên thiết bị di động, trình duyệt Ví tiền, thậm chí có thể hoàn thành trên một chuỗi khác (không có phần dữ liệu có sẵn).
Để đạt được điều này, cần phải chứng minh SNARK hoặc STARK cho (i) lớp đồng thuận (tức là chứng khoán chứng minh) và (ii) lớp thực hiện (tức là EVM). Việc đầu tiên đã là một thách thức và nên được giải quyết trong quá trình cải thiện liên tục lớp đồng thuận (ví dụ, đối với tính kết thúc của một khe). Lớp thứ hai cần chứng minh thực hiện của EVM.
Nó là gì và hoạt động như thế nào?
Từ mặt hình thức, trong chuẩn ETH, EVM được xác định là một hàm chuyển trạng thái: bạn có một trạng thái trước S, một Khối B, bạn đang tính toán một trạng thái sau S' = STF(S, B). Nếu người dùng sử dụng khách hàng ánh sáng, họ không hoàn toàn sở hữu S và S', thậm chí là E; thay vào đó, họ sở hữu một gốc trạng thái trước R, một gốc trạng thái sau R' và một giá trị băm Khối H.
· 公共输入：前状态根 R, 后状态根 R' , 块Hàm băm H
· Nhập riêng tư: Đối tượng trong trạng thái mà khối chương trình B và khối chương trình Q truy cập, cùng đối tượng sau khi thực hiện khối chương trình Q', chứng minh trạng thái (như nhánh Merkle) P
· Luận điểm 1: P là một bằng chứng hiệu quả, chứng minh rằng Q chứa một số phần của trạng thái mà R đại diện
· Đề xuất 2: Nếu chạy STF trên Q, (i) quá trình thực hiện chỉ truy cập các đối tượng trong Q, (ii) các khối dữ liệu là hợp lệ, (iii) kết quả là Q'
· Chủ đề 3: Nếu tính toán lại nguồn trạng thái bằng thông tin Q 'và P, chúng ta sẽ có R'
Nếu có trường hợp như vậy, bạn có thể có một người dùng nhẹ hoàn toàn xác minh được thực hiện bởi EVM của Ethereum. Điều này làm cho tài nguyên của người dùng đã rất thấp. Để thực hiện một người dùng nhẹ hoàn toàn xác minh đích thực của Ethereum, cần phải làm việc tương tự trong việc nhận thức chung.
Các bằng chứng hợp lệ để tính toán EVM đã tồn tại và được sử dụng rộng rãi trên L2. Tuy nhiên, còn rất nhiều công việc phải được thực hiện để làm cho bằng chứng hợp lệ EVM trên L1 khả thi.
Có những liên hệ nào với nghiên cứu hiện có?
· EFPSE ZK-EVM (đã ngừng sử dụng do có sự lựa chọn tốt hơn)
· Zeth, cách hoạt động của nó là biên dịch EVM vào RISC-0 ZK-VM
· ZK-EVM Xác minh chính thức项目
Còn gì khác mà có thể làm?
如今，电子记账系统的bằng chứng hợp lệ在两个方面存在不足：安全性和验证时间。
Một bằng chứng hợp lệ an toàn cần đảm bảo rằng SNARK thực sự xác minh được tính toán của EVM và không có lỗ hổng. Hai công nghệ chính để nâng cao tính bảo mật là đa xác thực và xác thực hình thức. Đa xác thực đề cập đến việc có nhiều bằng chứng hợp lệ độc lập được triển khai, tương tự như có nhiều khách hàng, nếu một khối được chứng minh bởi một tập con đủ lớn trong số các triển khai này, khách hàng sẽ chấp nhận khối đó. Xác thực hình thức liên quan đến 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, như Lean4, để chứng minh rằng bằng chứng hợp lệ chỉ chấp nhận việc thực thi đúng theo quy ước EVM cơ bản (ví dụ như ý nghĩa ngôn ngữ K của EVM hoặc quy ước thực thi tầng Ethereum được viết bằng Python (EELS)).
Thời gian xác minh đủ nhanh có nghĩa là bất kỳ khối ETH nào cũng có thể được xác minh trong thời gian ít hơn 4 giây. Hiện tại, chúng ta vẫn còn rất xa khỏi mục tiêu này, mặc dù chúng ta đã tiến gần hơn nhiều so với hai năm trước. Để đạt được mục tiêu này, chúng ta cần tiến bộ trong ba hướng:
· Đa luồng - Hiện tại, trình xác minh EVM nhanh nhất có thể chứng minh một Khối Ethereum trong vòng 15 giây. Điều này được thực hiện thông qua việc đa luồng trên hàng trăm GPU, sau đó tổng hợp công việc của họ lại để đạt được điều này. Lý thuyết cho thấy, chúng ta hoàn toàn biết cách tạo ra một trình xác minh EVM có thể chứng minh tính toán trong thời gian O(log(N)): làm cho mỗi bước được thực hiện bởi một GPU, sau đó tạo ra một "cây tổng hợp" sau mỗi bước:
Thực hiện điều này đối mặt với những thách thức. 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 tách tính toán không thể được thực hiện theo thứ tự, mà phải theo các mã hoạt động (mã hoạt động của máy ảo EVM hoặc RISC-V). Đảm bảo "bộ nhớ" của máy ảo duy trì nhất quán giữa các phần chứng minh khác nhau là một thách thức quan trọng trong quá trình triển khai. Tuy nhiên, nếu chúng ta có thể thực hiện được chứng minh đệ quy như vậy, chúng ta biết rằng, ngay cả khi không có bất kỳ cải tiến nào khác, ít nhất là vấn đề trễ của người chứng minh đã được giải quyết.
· Tối ưu hóa hệ thống chứng minh - Hệ thống chứng minh mới như Orion, Binius, GRK và nhiều thông tin khác có thể dẫn đến việc rút ngắn thời gian xác minh tính toán chung một lần nữa.
· Các thay đổi khác về chi phí gas của EVM - Có nhiều điều trong EVM có thể được tối ưu hóa để có lợi cho người chứng minh, đặc biệt là trong trường hợp xấu nhất. Nếu kẻ tấn công có thể xây dựng một khối chặn người chứng minh trong mười phút, thì chỉ cần chứng minh một khối ETH thông thường trong 4 giây là chưa đủ. Những thay đổi cần thiết cho EVM có thể được chia thành các loại sau đây:
Thay đổi chi phí gas - Nếu một hoạt động mất thời gian để chứng minh, thì dù tốc độ tính toán của nó có nhanh so với các mục khác, nó cũng nên có chi phí gas cao. EIP-7667 là một EIP được đề xuất để giải quyết vấn đề nghiêm trọng nhất trong việc xử lý này: nó tăng đáng kể chi phí gas của các hàm băm (truyền thống) vì các mã hoạt động và tiền xử lý của chúng rẻ hơn. Để bù đắp cho sự tăng chi phí gas này, chúng ta có thể giảm chi phí gas của các mã hoạt động EVM có chi phí chứng minh tương đối thấp, từ đó giữ nguyên lưu lượng thông qua trung bình.
Thay thế cấu trúc dữ liệu - Ngoài việc thay thế cây trạng thái bằng phương pháp thân thiện với STARK, chúng tôi 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 chứng minh chi phí cao khác. Việc chuyển cấu trúc giao dịch và biên nhận sang SSZ của Etan Kissling là một bước tiến trong hướng đó.
Ngoài ra, hai công cụ được đề cập trong phần trước (gas đa chiều và gốc trạng thái Trễ) cũng có thể hỗ trợ trong việc này. Tuy nhiên, đáng chú ý là, khác với việc xác minh vô trạng thái, việc sử dụng hai công cụ này có nghĩa là chúng ta đã có đủ công nghệ để hoàn thành công việc hiện tại, và ngay cả khi sử dụng công nghệ này, việc xác minh ZK-EVM hoàn chỉnh cũng cần phải làm thêm nhiều công việc hơn - chỉ là ít hơn thôi.
Một điểm không được đề cập trong bài viết trước là phần cứng chứng minh: sử dụng GPU, FPGA và ASIC để tạo ra chứng minh nhanh hơn. Fabric Cryptography, Cysic và Accseal là ba công ty đã tiến bộ trong lĩnh vực này. Điều này rất đáng giá đối với L2, nhưng có thể không phải là yếu tố quyết định cho L1, vì mọi người muốn L1 duy trì tính phi tập trung cao, điều này có nghĩa là việc tạo ra chứng minh phải nằm trong phạm vi hợp lý của người dùng ETH và không bị hạn chế bởi phần cứng của một công ty duy nhất. L2 có thể đưa ra các quyết định tích cực hơn.
Trong những lĩnh vực này, còn nhiều công việc phải làm:
· Đồng thời chứng minh yêu cầu hệ thống chứng minh các phần khác nhau của hệ thống có thể "chia sẻ bộ nhớ" (ví dụ như bảng tra cứu). Chúng ta biết về công nghệ này, nhưng cần được thực hiện.
· Chúng ta cần phân tích thêm để tìm ra tập hợp thay đổi 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 làm nhiều công việc hơn trong hệ thống chứng minh
Có thể chi phí là:
· Độ an toàn và thời gian xác thực của bộ xác thực: Nếu chọn hàm băm cấp độ cao hơn, hệ thống chứng minh phức tạp hơn hoặc giả thiết an toàn cấp độ cao hơn hoặc các kế hoạch thiết kế khác, thì có thể rút ngắn thời gian xác thực của bộ xác thực.
· Phi tập trung và Proof of Time: Cộng đồng cần thống nhất về 'cấu hình' của phần cứng Proof of Time mà họ đang xem xét. Có thể yêu cầu người chứng minh là một thực thể quy mô lớn? Chúng tôi có hy vọng rằng một chiếc laptop tiêu dùng cao cấp có thể chứng minh một khối ETH trong 4 giây? Hay có nằm giữa hai cái?
· Mức độ phá vỡ tính tương thích ngược: Những thiếu sót khác có thể được bù đắp bằng chi phí gas tích cực hơn, nhưng điều này có thể tăng chi phí không cân đối cho một số ứng dụng cụ thể, buộc các nhà phát triển phải viết lại và triển khai lại mã để giữ cho kinh tế. tính khả thi. Tương tự, hai công cụ này cũng có độ phức tạp và hạn chế riêng của chúng.
Nó tương tác với các phần khác của bản đồ đường đi như thế nào?
để thực hiện L1 EVM, công nghệ lõi cần thiết để bằng chứng hợp lệ lớn mức độ chia sẻ với hai lĩnh vực khác:
· L2 的bằng chứng hợp lệ（即「ZK rollup」）
· Phương pháp chứng minh nhị phân Hàm băm 'STARK' không trạng thái
Ngoài ra, bằng chứng hợp lệ của EVM của L1 có thể tăng đáng kể giới hạn gas của L1.
Nhận thức chung的bằng chứng hợp lệ
Chúng ta đang giải quyết vấn đề gì?
Nếu chúng ta muốn sử dụng SNARK để hoàn toàn xác minh một khối ETH trong mạng lưới, thì việc thực thi EVM không phải là phần duy nhất mà chúng ta cần chứng minh. Chúng ta cũng cần chứng minh Nhận thức chung, tức là một phần khác của hệ thống xử lý gửi tiền, rút tiền, ký, cập nhật số dư của người xác minh và một số yếu tố khác liên quan đến Bằng chứng về cổ phần của khối ETH.
Nhận thức chung比 EVM đơn giản nhiều, nhưng thách thức mà nó đối mặt là chúng ta không có L2 EVM tích chập, vì vậy, hầu hết công việc phải được hoàn thành bằng cách nào đó. Do đó, bất kỳ việc triển khai Nhận thức chung của ETH đều cần phải "bắt đầu từ đầu", mặc dù hệ thống chứng minh chính nó có thể được xây dựng dựa trên công việc chia sẻ.
Nó là gì và hoạt động như thế nào?
Chuỗi đèn hiệu được định nghĩa là một chức năng chuyển đổi trạng thái, giống như EVM. Chức năng chuyển đổi trạng thái bao gồm ba phần chính:
· ECADD（dùng để xác minh chữ ký BLS）
· Cặp (được sử dụng để xác minh chữ ký BLS)
· Hàm băm SHA256 (để đọc và cập nhật trạng thái)
Trong mỗi khối, chúng ta cần chứng minh 1-16 BLS12-381 ECADD cho mỗi trình xác thực (có thể có nhiều hơn một, vì chữ ký có thể được chứa trong nhiều bộ sưu tập). Đ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 ta có thể nói rằng mỗi Người xác thực chỉ cần chứng minh một ECADD BLS12-381. Hiện tại, có 30.000 chữ ký xác thực cho mỗi vị trí. Trong tương lai, điều này có thể thay đổi theo hai hướng khi đạt được tính cuối cùng của một vị trí: nếu chúng ta đi theo con đường "vũ phu", số lượng Người xác thực 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 trình xác nhận sẽ vẫn ở mức 32.768 hoặc thậm chí giảm xuống còn 8.192.
Công việc tổng hợp của BLS hoạt động như thế nào: Chỉ cần một ECADD của mỗi người tham gia để xác minh chữ ký tổng, thay vì một ECMUL. Tuy nhiên, 30000 ECADD vẫn là một lượng chứng cứ lớn.
Về việc kết hợp, hiện tại mỗi khe chỉ chứa tối đa 128 chứng minh, điều này có nghĩa là cần xác minh 128 cặp. Thông qua ElP-7549 và các sửa đổi tiếp theo, mỗi khe có thể giảm xuống còn 16 cặp. Số lượng cặp ít nhưng chi phí rất cao: thời gian chạy (hoặc chứng minh) của mỗi cặp dài hơn nhiều lần so với ECADD.
Một trong những thách thức chính của việc thực hiện phép toán BLS12-381 là không có đường cong thuận tiện có bậc bằng kích thước trường BLS12-381, điều này làm tăng 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 ETH được xây dựng bằng đường cong Bandersnatch, điều này khiến BLS12-381 trở thành đường cong tự xây dựng trong hệ thống SNARK được sử dụng để chứng minh các nhánh Verkle. Một triển khai đơn giản có thể chứng minh 100 phép cộng G1 mỗi giây; để làm cho tốc độ chứng minh đủ nhanh, hầu như chắc chắn cần sử dụng các kỹ thuật tinh vi như GKR.
Đối với giá trị băm SHA256, trường hợp tồi tệ nhất hiện tại là khối chuyển đổi thời đại, cả cây cân bằng ngắn của người xác thực và cây cân bằng lượng lớn của người xác thực sẽ được cập nhật. Cây cân bằng ngắn của mỗi người xác thực chỉ có một byte, vì vậy có 1 MB dữ liệu sẽ được băm lại. Điều này tương đương với 32768 lần gọi SHA256. Nếu có 1000 người xác thực có số dư cao hơn hoặc thấp hơn một ngưỡng, cần cập nhật số dư hiệu lực trong hồ sơ người xác thực, điều này tương đương với 1000 nhánh Merkle, do đó có thể cần 10000 lần giá trị băm. Cơ chế xáo trộn yêu cầu 90 Bit cho mỗi người xác thực (do đó cần 11 MB dữ liệu), nhưng điều này có thể tính toán bất kỳ lúc nào trong một thời đại. Trong trường hợp kết thúc một khe đơn, các số này có thể thay đổi tùy theo tình huống cụ thể. Xáo trộn trở nên không cần thiết, mặc dù Orbit có thể phục hồi một phần nhu cầu này.
Một thách thức khác là cần phải lấy lại tất cả trạng thái của người xác minh, bao gồm Khóa công khai, mới có thể xác minh một Khối. Đối với 1 triệu người xác minh, chỉ việc đọc Khóa công khai cũng cần 48 triệu byte, cộng thêm các nhánh Merkle. Điều này đòi hỏi mỗi kỷ nguyên hàng triệu giá trị băm. Nếu chúng ta phải chứng minh tính hiệu quả của PoS, một cách thực tế là một loại tính toán có thể xác minh tăng dần nào đó: lưu trữ một cấu trúc dữ liệu độc lập trong bộ nhớ của hệ thống chứng minh, cấu trúc dữ liệu này được tối ưu hóa để tìm kiếm hiệu quả và chứng minh cập nhật cho cấu trúc đó.
Tóm lại, có rất nhiều thách thức. Để đối phó hiệu quả nhất với những thách thức này, có thể cần phải thiết kế lại beacon chain một cách sâu sắc, và điều này có thể được thực hiện đồng thời với việc chuyển sang kết thúc một khoảng thời gian đơn. Những đặc điểm của việc thiết kế lại này có thể bao gồm:
· Thay đổi hàm băm: Bây giờ chúng tôi sử dụng hàm băm SHA256 "đầy đủ", vì vậy mỗi lần gọi đều phải tương ứng với hai lần gọi hàm nén dưới cùng vì lý do đệm. Nếu chúng ta chuyển sang hàm nén SHA256, chúng tôi ít nhất có thể đạt được gấp đôi lợi nhuận. Nếu chúng ta chuyển sang Poseidon, chúng tôi có thể đạt được lợi nhuận gấp 100 lần, giải quyết hoàn toàn tất cả vấn đề của chúng tôi (ít nhất là trong việc hàm băm): Có thể "đọc" 1,7 triệu giá trị hàm băm mỗi giây (54MB), thậm chí một triệu bản ghi xác minh cũng có thể được "đọc" trong vài giây.
· Nếu là Orbit, sau đó lưu trữ trực tiếp bản ghi xác thực đã được trộn: Nếu chọn một số lượng cố định của các xác thực viên (như 8192 hoặc 32768) làm ủy ban cho một khe cụ thể, chúng sẽ được đặt trực tiếp vào trạng thái bên cạnh nhau, chỉ cần ít nhất một Hàm băm để có thể đọc tất cả các Khóa công khai của xác thực viên vào chứng minh. Điều này cũng giúp hoàn thành tất cả các cập nhật cân đối một cách hiệu quả.
· Tổng 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, với các Nút khác nhau trong mạng thực hiện các bằng chứng trung gian của một tập hợp con chữ ký. Điều này tự nhiên phân chia công việc chứng minh giữa nhiều Nút trong mạng, giảm đáng kể khối lượng công việc của "câu tục ngữ cuối cùng".
· Các phương án chữ ký khác: Đối với chữ ký Lamport+ Merkle, chúng ta cần 256 + 32 giá trị hash để xác minh chữ ký; Nhân với 32768 người ký, ta có 9437184 giá trị hash. Sau khi tối ưu hóa phương án chữ ký, kết quả có thể được cải thiện thêm bằng một hằng số nhỏ. Nếu chúng ta sử dụng Poseidon, điều này có thể được chứng minh trong một khe cắm duy nhất. Nhưng thực tế, việc sử dụng phương án tổng hợp đệ quy sẽ nhanh hơn.
Có những liên hệ nào với nghiên cứu hiện có?
· Chứng chỉ Nhận thức chung ETH đơn giản (chỉ dành cho Hội đồng đồng bộ hóa)
· Helios trong SP1 đơn giản
· BLS12-381 được biên dịch trước một cách ngắn gọn
· Xác minh chữ ký tập hợp BLS dựa trên Halo2
Còn công việc nào cần làm, cách chọn lựa như thế nào:
Trên thực tế, chúng ta sẽ mất nhiều năm để có được bằng chứng hợp lệ của bình phương ETH Nhận thức chung. Đó là khoảng thời gian tương đương với khoảng thời gian chúng ta cần để thực hiện tính cuối cùng của một khe cắm, Quỹ đạo, sửa đổi Thuật toán chữ ký và phân tích bảo mật, đòi hỏi đủ tự tin để sử dụng hàm băm "tích cực" như Poseidon. Do đó, sẽ là khôn ngoan nhất khi giải quyết những vấn đề khác này và tính đến sự thân thiện của STARK trong khi giải quyết chúng.
Sự cân nhắc chính có thể nằm ở thứ tự thao tác, giữa cách tiếp cận tiến bộ hơn và cách tiếp cận "một lần thay đổi nhiều" hơn khi cải cách lớp đồng thuận Ethereum. Với EVM, cách tiếp cận tiến bộ là hợp lý vì nó giảm thiểu sự can thiệp vào tính tương thích ngược. Đối với lớp đồng thuận, tác động vào tính tương thích ngược ít hơn và việc xem xét lại các chi tiết về cách xây dựng beacon chain "toàn diện" theo cách tối ưu nhất để tăng tính thân thiện với SNARK cũng có lợi.
Làm thế nào nó tương tác với các phần khác của bản đồ con đường?
Trong quá trình thiết kế lại lâu dài cho PoS của Ethereum, tính thân thiện của STARK phải trở thành yếu tố hàng đầu, đặc biệt là tính kết thúc đơn lẻ, Orbit, thay đổi lược đồ chữ ký và việc tổng hợp chữ ký.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Vitalik关于ETH坊可能的未来（四）：The Verge
Trước khi đọc: "Vitalik về tương lai có thể của Ethereum (phần 1): The Merge", "Vitalik về tương lai có thể của Ethereum (phần 2): The Surge", "Vitalik về tương lai có thể của Ethereum (phần 3): The Scourge"
Đặc biệt cảm ơn Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams và Uma Roy đã đóng góp ý kiến và xem xét.
Một trong những tính năng mạnh mẽ nhất của Khối chuỗi là bất kỳ ai cũng có thể chạy một Nút trên máy tính của họ và xác minh tính chính xác của Khối chuỗi. Ngay cả khi 9596 Nút chạy Nhận thức chung chuỗi (PoW, PoS) đồng ý ngay lập tức thay đổi quy tắc và bắt đầu sản xuất Khối theo quy tắc mới, mọi người chạy Nút xác minh đầy đủ sẽ từ chối chấp nhận chuỗi. Người tạo ra tiền không phải là một phần của nhóm âm mưu này sẽ tự động tập hợp vào một chuỗi on-chain tiếp tục tuân theo quy tắc cũ và tiếp tục xây dựng chuỗi này, trong khi người dùng xác minh đầy đủ sẽ tuân theo chuỗi này.
Điều này là sự khác biệt chính giữa blockchain và hệ thống tập trung. Tuy nhiên, để điều này trở thành sự thật, việc vận hành một Nút được xác minh đầy đủ cần phải khả thi đối với đủ số người. Điều này áp dụng cho cả người tạo ra sự lan truyền (vì nếu họ không xác minh chuỗi, họ sẽ không đóng góp vào việc thực hiện các quy tắc giao thức), cũng như người dùng thông thường. Hiện nay, việc vận hành Nút được xác minh đầy đủ trên các laptop tiêu dùng (bao gồm cả laptop được sử dụng khi viết bài này) là khả thi, nhưng thực hiện điều này là rất khó khăn. The Verge muốn thay đổi tình hình này bằng cách giảm chi phí tính toán của chuỗi được xác minh đầy đủ, và mặc định mỗi điện thoại di động Ví tiền, trình duyệt Ví tiền và thậm chí cả đồng hồ thông minh đều sẽ thực hiện xác minh.
Ban đầu, "Verge" đề cập đến việc chuyển trạng thái lưu trữ ETH từ cây Verkle - một cấu trúc cây cho phép chứng minh nhỏ gọn hơn, để xác minh trạng thái không cần thiết lưu trữ bất kỳ trạng thái ETH nào (số dư tài khoản, mã hợp đồng, không gian lưu trữ...) trên đĩa cứng. Nút có thể xác minh một khối ETH mà không cần lưu trữ bất kỳ trạng thái ETH nào trên đĩa cứng (số dư tài khoản, mã hợp đồng, không gian lưu trữ...), điều đó có giá là mất vài trăm KB dữ liệu chứng minh và thời gian bổ sung vài trăm mili giây để xác minh một chứng minh. Ngày nay, Verge đại diện cho một tầm nhìn lớn hơn, tập trung vào việc thực hiện xác minh tài nguyên tối đa trên chuỗi ETH, bao gồm không chỉ công nghệ xác minh trạng thái không cần thiết mà còn bao gồm việc sử dụng SNARK xác minh tất cả các giao dịch ETH.
Ngoài việc xác minh sự theo dõi lâu dài của toàn bộ chuỗi chống lại SNARK, một câu hỏi mới khác liên quan đến việc liệu cây Verkle có phải là kỹ thuật tốt nhất hay không. Cây Verkle dễ bị tổn thương bởi Máy tính lượng tử, vì vậy nếu chúng ta lấy cây Verkle trong cây KECCAK Merkle Patricia hiện tại, chúng ta sẽ phải thay thế cây một lần nữa trong tương lai. Một cách tự thay thế cho cây Merkle là chỉ cần bỏ qua STARK sử dụng nhánh Merkle và đặt nó vào một 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 chi phí và sự phức tạp về kỹ thuật. Tuy nhiên, gần đây, chúng ta đã thấy Starkware chứng minh 1,7 triệu Poseidon Hàm băm mỗi giây bằng cách sử dụng ckcle STARKs trên một máy tính xách tay duy nhất và nhờ các công nghệ như GKB, thời gian chứng minh cho các giá trị Hàm băm "truyền thống" hơn cũng đang giảm nhanh chóng. 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: Không cần nhiều hơn một vài gigabyte dung lượng lưu trữ để xác thực đầy đủ máy khách và nút thẻ.
· (Long-term) hoàn toàn xác minh chuỗi trên đồng hồ thông minh (Nhận thức chung và thực hiện). Tải xuống một số dữ liệu, xác minh SNARK, hoàn thành.
Trong chương này
· Máy khách không trạng thái: Verkle hay STARKs
· EVM 执行的bằng chứng hợp lệ
· Nhận thức chung的bằng chứng hợp lệ
Xác minh không trạng thái: Verkle hay STARKs
Chúng ta đang giải quyết vấn đề gì?
Ngày nay, khách hàng ETH cần lưu trữ hàng trăm tỷ byte dữ liệu trạng thái để xác minh Khối, và số lượng này tăng lên hàng năm. Dữ liệu trạng thái gốc tăng khoảng 30GB mỗi năm, một khách hàng duy nhất phải lưu trữ một số dữ liệu bổ sung trên đó để cập nhật bộ ba một cách hiệu quả.
Điều này giới hạn số lượng người dùng có thể chạy Nút Ethereum đầy đủ xác minh: mặc dù có thể lưu trữ toàn bộ trạng thái Ethereum và lịch sử nhiều năm trên ổ cứng lớn, nhưng máy tính mà mọi người thường mua chỉ có vài trăm đến vài nghìn gigabyte dung lượng lưu trữ. Kích thước trạng thái cũng gây ra rất nhiều sự cản trở trong quá trình thiết lập Nút lần đầu: Nút cần tải xuống toàn bộ trạng thái, điều này có thể mất từ vài giờ đến vài ngày. Điều này dẫn đến nhiều tác động lan truyền. Ví dụ, nó làm tăng đáng kể độ khó khi người tạo Nút nâng cấp cấu hình Nút của họ. Về mặt kỹ thuật, nâng cấp có thể được hoàn thành mà không cần tắt máy - khởi động một phiên bản mới của khách hàng, chờ đồng bộ hóa sau đó đóng phiên bản cũ và chuyển giao Chìa khoá bảo mật - nhưng trong thực tế, việc 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à một công nghệ cho phép Nút xác minh Khối mà không cần kiểm soát toàn bộ trạng thái. Thay vào đó, mỗi Khối được đính kèm với một bằng chứng bao gồm: (i) giá trị, mã, số dư và lưu trữ của vị trí cụ thể trong trạng thái mà Khối sẽ truy cập; (ii) chứng minh rằng các giá trị này đã được mã hóa đúng.
Trong thực tế, việc thực hiện xác minh không trạng thái đòi hỏi thay đổi cấu trúc cây trạng thái của Ethereum. Điều này bởi vì cây Merkle Patricia hiện tại rất không thân thiện với bất kỳ hệ thống chứng minh mã hóa nào, đặc biệt là trong trường hợp xấu nhất. Cả 'nhánh' Merkle ban đầu lẫn khả năng 'đóng gói' thành STARK đều vậy. Khó khăn chính đến từ một số điểm yếu của MPT:
Đây là một cây sáu nhánh (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 chứng minh trung bình cần khoảng 32*(16-1)log16(N) = 120 log2(N) byte, hoặc khoảng 3840 byte trong một cây với 2^32 mục. Đối với cây nhị phân, chỉ cần 32*(2-1)log2(N) = 32 log2(N) byte, hoặc khoảng 1024 byte.
Mã không được Merkle hóa. Điều này có nghĩa là để chứng minh quyền truy cập vào mã tài khoản, bạn cần cung cấp toàn bộ mã, tối đa là 24000 byte.
Chúng ta có thể tính toán trường hợp tồi nhất như sau:
30000000 gas / 2400 (tài khoản lạnh đọc chi phí) *（5 * 488 + 24000) = 330000000 byte
Chi phí nhánh nhỏ hơn một chút (sử dụng 5480 thay vì 8480) do phần đầu của nó được lặp lại khi có nhiều nhánh hơn. Tuy nhiên, thậm chí trong một khe thời gian, lượng dữ liệu cần tải xuống cũng là không thể thực hiện được. Nếu chúng ta cố gắng sử dụng STARK để đóng gói nó, chúng ta sẽ gặp hai vấn đề: (i) KECCAK không thân thiện với STARK; (ii) Dữ liệu 330MB có nghĩa là chúng ta phải chứng minh 5 triệu lần gọi hàm round của KECCAK, điều này có thể không thể chứng minh được đối với tất cả các phần cứng trừ các phần cứng tiêu dùng mạnh nhất, ngay cả khi chúng ta có thể làm cho việc chứng minh KECCAK trở nên hiệu quả hơn bằng STARK.
Nếu chúng ta thay thế cây nhị phân bằng cây thập lục phân trực tiếp và xử lý mã bằng cách thêm Merkle, thì trong trường hợp xấu nhất sẽ trở thành khoảng 30000000/240032(32-14+8) = 10400000 byte (14 là phép trừ cho các bit dư thừa của 2^14 nhánh và 8 là độ dài chứng minh cho các lá trong khối mã). Cần lưu ý rằng điều này sẽ thay đổi chi phí gas, tính phí cho việc truy cập vào mỗi khối mã riêng lẻ; EIP-4762 đã thực hiện điều này. Dung lượng 10,4 MB tốt hơn nhiều, nhưng đối với nhiều Nút, dữ liệu tải xuống trong một khe thời gian vẫn quá nhiều. Do đó, chúng ta cần giới thiệu các công nghệ mạnh mẽ hơn. Trong lĩnh vực này, có hai giải pháp hàng đầu: cây Verkle và cây băm nhị phân STARKed.
Cây Verkle
Verkle 树 sử dụng cam kết vector dựa trên đường cong elip để tạo ra chứng minh ngắn hơn. Chìa khóa được mở ra ở chỗ, bất kể chiều rộng của cây như thế nào, mỗi phần chứng minh tương ứng với mối quan hệ cha con chỉ có 32 byte. Giới hạn duy nhất của chiều rộng cây chứng minh là nếu cây chứng minh quá rộng, hiệu suất tính toán của chứng minh sẽ bị ảnh hưởng. Giải pháp triển khai cho Ethereum có chiều rộng là 256.
Do đó, kích thước của một nhánh trong bằng 32 - 1og256(N) = 4* log2(N) byte. Do đó, kích thước chứng minh tối đa 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ế có thể khác nhau một chút do phân phối khối trạng thái không đồng đều, nhưng là xấp xỉ đầu tiên).
Ngoài ra, điều cần lưu ý 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 tồi tệ hơn là kẻ tấn công cố ý 'đào' hai địa chỉ Địa chỉ và làm cho chúng có tiền tố chung dài hơn trong cây và đọc dữ liệu từ một địa chỉ Địa chỉ, điều này có thể kéo dài chiều dài của nhánh xấu nhất thêm gấp đôi. Tuy nhiên, ngay cả khi có trường hợp như vậy, độ dài chứng minh xấu nhất của cây Verkle là 2,6MB, tương tự như dữ liệu xác minh xấu nhất hiện tại.
Chúng tôi cũng đã sử dụng lưu ý này để thực hiện một điều khác: chúng tôi đã làm cho chi phí truy cập không gian lưu trữ "liền kề" trở nên rất thấp: hoặc là nhiều khối mã của cùng một hợp đồng, hoặc là các khe lưu trữ kế cận. EIP-4762 cung cấp định nghĩa về liền kề, chỉ thu 200 gas cho việc truy cập liền kề. Trong trường hợp truy cập liền kề, kích thước chứng minh trong trường hợp xấu nhất trở thành 30000000 / 200*32 - 4800800 byte, điều này vẫn nằm trong khoảng sai số. Nếu vì lý do an toàn mà chúng ta muốn giảm giá trị này, chúng ta có thể tăng giá trị truy cập liền kề một chút.
Cây băm nhị phân STARKed
Nguyên tắc của công nghệ này rất rõ ràng: Bạn chỉ cần tạo một cây nhị phân, lấy chứng chỉ tối đa 10,4 MB, chứng minh giá trị trong khối, sau đó thay thế chứng chỉ bằng STARK đã được chứng minh. Như vậy, chứng chỉ chính nó chỉ chứa dữ liệu được chứng minh, cộng thêm chi phí cố định từ STARK thực tế là 100-300kB.
Thách thức chính ở đây là xác minh thời gian. Chúng ta có thể thực hiện các tính toán tương tự như trên, chỉ khác ở chỗ chúng ta không tính số byte mà là giá trị băm. Một Khối có kích thước 10,4 MB có nghĩa là 330.000 giá trị băm. Nếu nhìn vào khả năng "đào" các Địa chỉ cây có tiềm năng có tiền tố công cộng dài hơn, thì số lượng giá trị băm trong trường hợp xấu nhất sẽ khoảng 660.000 giá trị băm. Vì vậy, nếu chúng ta có thể chứng minh rằng mỗi giây có 200.000 giá trị băm, thì không có vấn đề gì.
Trên các laptop tiêu dùng sử dụng Hàm băm Poseidon, các con số này đã đạt được 01928374656574839201, trong khi Hàm băm Poseidon được thiết kế đặc biệt cho tính thân thiện với STARK. Tuy nhiên, hệ thống Poseidon vẫn chưa hoàn thiện, vì vậy nhiều người vẫn không tin tưởng vào tính an toàn của nó. Do đó, có hai con đường thực tế để tiến lên:
Nhanh chóng phân tích an ninh lượng lớn cho Poseidon và làm quen đủ để triển khai trên L1
Sử dụng hàm băm "bảo thủ" hơn, như SHA256 hoặc BLAKE
Để chứng minh hàm băm bảo mật, vòng STARK của Starkware chỉ có thể chứng minh từ 10-30k giá trị băm mỗi giây trên các máy tính xách tay tiêu dùng khi viết bài này. Tuy nhiên, công nghệ STARK đang được cải tiến nhanh chóng. Ngay cả ngày nay, công nghệ dựa trên GKR cũng cho thấy có thể nâng tốc độ này lên trong khoảng từ 100-2O0k.
Trường hợp sử dụng chứng thực ngoại trừ khối
Ngoài việc xác minh Khối, còn ba trường hợp sử dụng chính cần xác minh không trạng thái hiệu quả hơn:
· Bể nhớ: Khi giao dịch được phổ biến, Nút trong mạng P2P cần xác minh tính hợp lệ của giao dịch trước khi phát lại. Hiện nay, việc xác minh bao gồm việc xác minh chữ ký, cũng như 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 trừu tượng hóa tài khoản nguyên bản, như EIP-7701), điều này có thể liên quan đến việc chạy một số mã EVM, những mã này sẽ thực hiện một số truy cập trạng thái. Nếu Nút không có trạng thái, thì giao dịch cần đi kèm với chứng minh của đối tượng trạng thái.
· Danh sách bao gồm: Đây là một tính năng đề xuất, cho phép (có thể là quy mô nhỏ và không phức tạp) Bằng chứng về cổ phầnNgười xác thực buộcKhối tiếp theo chứa các giao dịch mà không quan tâm đến ý định củaKhối xây dựng (có thể là quy mô lớn và phức tạp). Điều này sẽ làm suy yếu khả năng của những người có quyền lực thao tácKhối chuỗi bằng cách tạoTrễ giao dịch. Tuy nhiên, điều này đòi hỏiNgười xác thực phải có cách để xác minh tính hợp lệ của các giao dịch trong danh sách bao gồm.
· khách hàng ánh sáng: Nếu chúng ta muốn người dùng truy cập chuỗi thông qua ví (như Metamask, Rainbow, Rabby, v.v.), để làm được điều này, họ cần chạy một khách hàng ánh sáng (như Helios). Helios cung cấp cho người dùng một gốc trạng thái đã được xác minh. Để có trải nghiệm hoàn toàn không tin cậy, người dùng cần cung cấp chứng minh cho mỗi cuộc gọi RPC mà họ thực hiện (ví dụ, cho yêu cầu gọi mạng ETH (người dùng cần chứng minh tất cả các trạng thái được truy cập trong quá trình gọi)).
Tất cả các trường hợp sử dụng này đều có một điểm chung, đó là chúng đều yêu cầu rất nhiều bằng chứng, nhưng mỗi bằng chứng đều rất nhỏ. Do đó, chứng minh STARK không có ý nghĩa thực tế cho chúng; thay vào đó, cách tiếp cận thực tế nhất là sử dụng nhánh Merkle trực tiếp. Một lợi ích khác của nhánh Merkle là có thể cập nhật: với bằng chứng của một đối tượng trạng thái X có gốc là Khối B, nếu nhận được một Khối con B2 và chứng cứ tương ứng của nó, bằng chứng có thể được cập nhật để có gốc là Khối B2. Chứng minh Verkle cũng có thể cập nhật tự nhiên.
Có liên hệ nào với nghiên cứu hiện có:
· cây Verkle
· Bản gốc của bài báo về cây Verkle do John Kuszmaul viết
· Starkware
· Bài báo Poseidon2
· Ajtai (Hàm băm nhanh thay thế dựa trên độ cứng của lưới tinh thể)
· Verkle.info
Còn gì khác mà có thể làm?
Công việc chính còn lại là
Phân tích thêm về hậu quả của EIP-4762 (Thay đổi chi phí gas không có trạng thái)
Hoàn thành và thử nghiệm nhiều công việc chuyển tiếp, đây là phần chính của sự phức tạp của bất kỳ giải pháp triển khai không quốc gia nào.
Phân tích an ninh thêm về các hàm băm Poseidon, Ajtai và các hàm băm "STARK-friendly" khác
为 "保守"（或 "传统"）Hàm băm进一步开发超高效 STARK giao thức功能，例如基于 Binius 或 GKR 的观点。
Ngoài ra, chúng tôi sẽ nhanh chóng quyết định chọn một trong ba lựa 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ác đặc điểm của chúng có thể tóm tắt như sau:
Ngoài những "số tiêu đề" này, còn có một số yếu tố quan trọng khác cần xem xét:
· Hiện nay, mã cây Verkle đã khá thành thục. Ngoài Verkle, việc sử dụng bất kỳ mã nào khác sẽ gây trì hoãn triển khai và có thể gây trì hoãn một fork cứng. Điều này cũng không quan trọng, đặc biệt là nếu chúng ta cần thêm thời gian để phân tích hàm băm hoặc triển khai bộ xác minh, hoặc chúng ta có các tính năng quan trọng khác mà chúng ta muốn sớm hơn để tích hợp vào Ethereum.
· Cập nhật gốc trạng thái bằng giá trị băm nhanh hơn sử dụng cây Verkle. Điều này có nghĩa là phương pháp dựa trên giá trị băm có thể giảm thời gian đồng bộ hóa Toàn bộ nút.
· Cây Verkle có thuộc tính cập nhật chứng minh thú vị - Chứng minh thú của cây Verkle có thể được cập nhật. Thuộc tính này hữu ích cho mempool, danh sách chứa và các trường hợp sử dụng khác, và cũng có thể giúp cải thiện hiệu suất triển khai: nếu trạng thái đối tượng được cập nhật, có thể cập nhật chứng minh của lớp thứ hai từ dưới lên mà không cần đọc nội dung của lớp cuối cùng.
· Việc chứng minh SNARK trở nên khó khăn hơn với cây Verkle. Nếu chúng ta muốn giữ kích thước chứng minh luôn giảm xuống đến vài nghìn byte, thì chứng minh Verkle sẽ gặp một số khó khăn. Điều này là do quá trình xác minh chứng minh Verkle đưa vào rất nhiều hoạt động 256 bit, điều này đòi hỏi hệ thống chứng minh phải có chi phí lớn hoặc có cấu trúc nội bộ được tùy chỉnh, bao gồm phần chứng minh Verkle 256 bit. Điều này không phải là vấn đề đối với trạng thái không có vấn đề, nhưng sẽ mang lại nhiều khó khăn hơn.
Nếu chúng ta muốn có một cách để có được tính tương thích với Verkle một cách an toàn với lượng lớn và hiệu quả một cách hợp lý, một cách khác có thể là dựa trên cây Merkle dựa trên lattice.
Nếu trong trường hợp xấu nhất, chứng minh hiệu suất của hệ thống không đủ cao, chúng ta có thể sử dụng công cụ gas đa chiều bất ngờ này để bù đắp cho điều đó: đặt giới hạn gas riêng cho (i) calldata; (ii) tính toán; (iii) truy cập trạng thái và có thể là các tài nguyên khác khác nhau. Gas đa chiều tăng thêm sự phức tạp, nhưng như một sự trao đổi, nó giới hạn chặt chẽ tỷ lệ giữa trường hợp trung bình và trường hợp xấu nhất. Với gas đa chiều, số lượng nhánh cần chứng minh lý thuyết tối đa có thể giảm từ 12500 xuống 3000 chẳng hạn. Điều này sẽ khiến cho BLAKE3 (vào lúc này) đủ sức để sử dụng dù chỉ là sức ép.
Đa chiều gas cho phép giới hạn tài nguyên của Khối gần với giới hạn tài nguyên của phần cứng cấp dưới hơn
Một công cụ không ngờ khác là tính toán trạng thái gốc Trễ vào thời khóa sau Khối. Điều này nghĩa là chúng ta có 12 giây để tính toán trạng thái gốc, có nghĩa là ngay cả trong trường hợp cực đoan, thời gian chứng minh với 60000 lần băm mỗi giây cũng đủ, điều này một lần nữa khiến chúng ta nghĩ rằng BLAKE3 chỉ đáng giá đủ.
Phương pháp này có nhược điểm là nó sẽ tăng thêm một khung thời gian Trễ cho khách hàng ánh sáng, nhưng cũng có các kỹ thuật tinh vi hơn có thể giảm Trễ này xuống chỉ còn đối với việc tạo ra chứng minh. Ví dụ, chứng minh có thể được phát sóng trên mạng ngay sau khi được tạo ra tại bất kỳ nút nào, thay vì chờ đến khối tiếp theo.
Nó tương tác với các phần khác của bản đồ đường đi như thế nào?
Giải quyết vấn đề không trạng thái đã tăng đáng kể độ khó của việc điểm đặt đơn lẻ. Nếu có công nghệ để giảm thiểu cân bằng tối thiểu đơn lẻ như Orbit SSF hoặc chiến lược Lớp ứng dụng như điểm đặt nhóm nhỏ, điều này sẽ trở nên khả thi hơn.
Nếu đồng thời giới thiệu EOF, phân tích gas đa chiều sẽ trở nên dễ dàng hơn. Điều này bởi vì độ phức tạp thực hiện chính của gas đa chiều đến từ việc xử lý các cuộc gọi con không chuyển toàn bộ gas của cuộc gọi cha, trong khi EOF chỉ cần đánh dấu các cuộc gọi con này là không hợp lệ, vấn đề này sẽ trở nên không đáng kể (và cung cấp một phương án thay thế giao thức bên trong cho một phần sử dụng gas chính hiện tại của tài khoản cục bộ).
Giữa việc xác minh không trạng thái và lịch sử hết hạn, còn có một tác động cộng tác quan trọng. Hiện nay, các máy khách phải lưu trữ gần 1TB dữ liệu lịch sử; dữ liệu này nhiều lần so với dữ liệu trạng thái. Ngay cả khi máy khách là không trạng thái, nếu chúng ta không thể giải phóng trách nhiệm lưu trữ dữ liệu lịch sử của máy khách, thì gần như không thể thực hiện được ước mơ không lưu trữ của máy khách. Bước đầu tiên trong việc này là EIP-4444, điều này cũng có nghĩa là lưu trữ dữ liệu lịch sử trên torrents hoặc Portal Network.
EVM 执行的bằng chứng hợp lệ
Chúng ta đang giải quyết vấn đề gì?
Ether Khối xác minh có mục tiêu dài hạn rất rõ ràng - nên có thể xác minh Ether Khối theo cách sau: (i) Tải xuống Khối, hoặc thậm chí chỉ tải xuống một phần nhỏ của dữ liệu có sẵn trong Khối; (ii) Xác minh một chứng cứ nhỏ hợp lệ của Khối. Điều này sẽ là một hoạt động tài nguyên rất thấp, có thể thực hiện trên thiết bị di động, trình duyệt Ví tiền, thậm chí có thể hoàn thành trên một chuỗi khác (không có phần dữ liệu có sẵn).
Để đạt được điều này, cần phải chứng minh SNARK hoặc STARK cho (i) lớp đồng thuận (tức là chứng khoán chứng minh) và (ii) lớp thực hiện (tức là EVM). Việc đầu tiên đã là một thách thức và nên được giải quyết trong quá trình cải thiện liên tục lớp đồng thuận (ví dụ, đối với tính kết thúc của một khe). Lớp thứ hai cần chứng minh thực hiện của EVM.
Nó là gì và hoạt động như thế nào?
Từ mặt hình thức, trong chuẩn ETH, EVM được xác định là một hàm chuyển trạng thái: bạn có một trạng thái trước S, một Khối B, bạn đang tính toán một trạng thái sau S' = STF(S, B). Nếu người dùng sử dụng khách hàng ánh sáng, họ không hoàn toàn sở hữu S và S', thậm chí là E; thay vào đó, họ sở hữu một gốc trạng thái trước R, một gốc trạng thái sau R' và một giá trị băm Khối H.
· 公共输入：前状态根 R, 后状态根 R' , 块Hàm băm H
· Nhập riêng tư: Đối tượng trong trạng thái mà khối chương trình B và khối chương trình Q truy cập, cùng đối tượng sau khi thực hiện khối chương trình Q', chứng minh trạng thái (như nhánh Merkle) P
· Luận điểm 1: P là một bằng chứng hiệu quả, chứng minh rằng Q chứa một số phần của trạng thái mà R đại diện
· Đề xuất 2: Nếu chạy STF trên Q, (i) quá trình thực hiện chỉ truy cập các đối tượng trong Q, (ii) các khối dữ liệu là hợp lệ, (iii) kết quả là Q'
· Chủ đề 3: Nếu tính toán lại nguồn trạng thái bằng thông tin Q 'và P, chúng ta sẽ có R'
Nếu có trường hợp như vậy, bạn có thể có một người dùng nhẹ hoàn toàn xác minh được thực hiện bởi EVM của Ethereum. Điều này làm cho tài nguyên của người dùng đã rất thấp. Để thực hiện một người dùng nhẹ hoàn toàn xác minh đích thực của Ethereum, cần phải làm việc tương tự trong việc nhận thức chung.
Các bằng chứng hợp lệ để tính toán EVM đã tồn tại và được sử dụng rộng rãi trên L2. Tuy nhiên, còn rất nhiều công việc phải được thực hiện để làm cho bằng chứng hợp lệ EVM trên L1 khả thi.
Có những liên hệ nào với nghiên cứu hiện có?
· EFPSE ZK-EVM (đã ngừng sử dụng do có sự lựa chọn tốt hơn)
· Zeth, cách hoạt động của nó là biên dịch EVM vào RISC-0 ZK-VM
· ZK-EVM Xác minh chính thức项目
Còn gì khác mà có thể làm?
如今，电子记账系统的bằng chứng hợp lệ在两个方面存在不足：安全性和验证时间。
Một bằng chứng hợp lệ an toàn cần đảm bảo rằng SNARK thực sự xác minh được tính toán của EVM và không có lỗ hổng. Hai công nghệ chính để nâng cao tính bảo mật là đa xác thực và xác thực hình thức. Đa xác thực đề cập đến việc có nhiều bằng chứng hợp lệ độc lập được triển khai, tương tự như có nhiều khách hàng, nếu một khối được chứng minh bởi một tập con đủ lớn trong số các triển khai này, khách hàng sẽ chấp nhận khối đó. Xác thực hình thức liên quan đến 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, như Lean4, để chứng minh rằng bằng chứng hợp lệ chỉ chấp nhận việc thực thi đúng theo quy ước EVM cơ bản (ví dụ như ý nghĩa ngôn ngữ K của EVM hoặc quy ước thực thi tầng Ethereum được viết bằng Python (EELS)).
Thời gian xác minh đủ nhanh có nghĩa là bất kỳ khối ETH nào cũng có thể được xác minh trong thời gian ít hơn 4 giây. Hiện tại, chúng ta vẫn còn rất xa khỏi mục tiêu này, mặc dù chúng ta đã tiến gần hơn nhiều so với hai năm trước. Để đạt được mục tiêu này, chúng ta cần tiến bộ trong ba hướng:
· Đa luồng - Hiện tại, trình xác minh EVM nhanh nhất có thể chứng minh một Khối Ethereum trong vòng 15 giây. Điều này được thực hiện thông qua việc đa luồng trên hàng trăm GPU, sau đó tổng hợp công việc của họ lại để đạt được điều này. Lý thuyết cho thấy, chúng ta hoàn toàn biết cách tạo ra một trình xác minh EVM có thể chứng minh tính toán trong thời gian O(log(N)): làm cho mỗi bước được thực hiện bởi một GPU, sau đó tạo ra một "cây tổng hợp" sau mỗi bước:
Thực hiện điều này đối mặt với những thách thức. 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 tách tính toán không thể được thực hiện theo thứ tự, mà phải theo các mã hoạt động (mã hoạt động của máy ảo EVM hoặc RISC-V). Đảm bảo "bộ nhớ" của máy ảo duy trì nhất quán giữa các phần chứng minh khác nhau là một thách thức quan trọng trong quá trình triển khai. Tuy nhiên, nếu chúng ta có thể thực hiện được chứng minh đệ quy như vậy, chúng ta biết rằng, ngay cả khi không có bất kỳ cải tiến nào khác, ít nhất là vấn đề trễ của người chứng minh đã được giải quyết.
· Tối ưu hóa hệ thống chứng minh - Hệ thống chứng minh mới như Orion, Binius, GRK và nhiều thông tin khác có thể dẫn đến việc rút ngắn thời gian xác minh tính toán chung một lần nữa.
· Các thay đổi khác về chi phí gas của EVM - Có nhiều điều trong EVM có thể được tối ưu hóa để có lợi cho người chứng minh, đặc biệt là trong trường hợp xấu nhất. Nếu kẻ tấn công có thể xây dựng một khối chặn người chứng minh trong mười phút, thì chỉ cần chứng minh một khối ETH thông thường trong 4 giây là chưa đủ. Những thay đổi cần thiết cho EVM có thể được chia thành các loại sau đây:
Thay đổi chi phí gas - Nếu một hoạt động mất thời gian để chứng minh, thì dù tốc độ tính toán của nó có nhanh so với các mục khác, nó cũng nên có chi phí gas cao. EIP-7667 là một EIP được đề xuất để giải quyết vấn đề nghiêm trọng nhất trong việc xử lý này: nó tăng đáng kể chi phí gas của các hàm băm (truyền thống) vì các mã hoạt động và tiền xử lý của chúng rẻ hơn. Để bù đắp cho sự tăng chi phí gas này, chúng ta có thể giảm chi phí gas của các mã hoạt động EVM có chi phí chứng minh tương đối thấp, từ đó giữ nguyên lưu lượng thông qua trung bình.
Thay thế cấu trúc dữ liệu - Ngoài việc thay thế cây trạng thái bằng phương pháp thân thiện với STARK, chúng tôi 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 chứng minh chi phí cao khác. Việc chuyển cấu trúc giao dịch và biên nhận sang SSZ của Etan Kissling là một bước tiến trong hướng đó.
Ngoài ra, hai công cụ được đề cập trong phần trước (gas đa chiều và gốc trạng thái Trễ) cũng có thể hỗ trợ trong việc này. Tuy nhiên, đáng chú ý là, khác với việc xác minh vô trạng thái, việc sử dụng hai công cụ này có nghĩa là chúng ta đã có đủ công nghệ để hoàn thành công việc hiện tại, và ngay cả khi sử dụng công nghệ này, việc xác minh ZK-EVM hoàn chỉnh cũng cần phải làm thêm nhiều công việc hơn - chỉ là ít hơn thôi.
Một điểm không được đề cập trong bài viết trước là phần cứng chứng minh: sử dụng GPU, FPGA và ASIC để tạo ra chứng minh nhanh hơn. Fabric Cryptography, Cysic và Accseal là ba công ty đã tiến bộ trong lĩnh vực này. Điều này rất đáng giá đối với L2, nhưng có thể không phải là yếu tố quyết định cho L1, vì mọi người muốn L1 duy trì tính phi tập trung cao, điều này có nghĩa là việc tạo ra chứng minh phải nằm trong phạm vi hợp lý của người dùng ETH và không bị hạn chế bởi phần cứng của một công ty duy nhất. L2 có thể đưa ra các quyết định tích cực hơn.
Trong những lĩnh vực này, còn nhiều công việc phải làm:
· Đồng thời chứng minh yêu cầu hệ thống chứng minh các phần khác nhau của hệ thống có thể "chia sẻ bộ nhớ" (ví dụ như bảng tra cứu). Chúng ta biết về công nghệ này, nhưng cần được thực hiện.
· Chúng ta cần phân tích thêm để tìm ra tập hợp thay đổi 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 làm nhiều công việc hơn trong hệ thống chứng minh
Có thể chi phí là:
· Độ an toàn và thời gian xác thực của bộ xác thực: Nếu chọn hàm băm cấp độ cao hơn, hệ thống chứng minh phức tạp hơn hoặc giả thiết an toàn cấp độ cao hơn hoặc các kế hoạch thiết kế khác, thì có thể rút ngắn thời gian xác thực của bộ xác thực.
· Phi tập trung và Proof of Time: Cộng đồng cần thống nhất về 'cấu hình' của phần cứng Proof of Time mà họ đang xem xét. Có thể yêu cầu người chứng minh là một thực thể quy mô lớn? Chúng tôi có hy vọng rằng một chiếc laptop tiêu dùng cao cấp có thể chứng minh một khối ETH trong 4 giây? Hay có nằm giữa hai cái?
· Mức độ phá vỡ tính tương thích ngược: Những thiếu sót khác có thể được bù đắp bằng chi phí gas tích cực hơn, nhưng điều này có thể tăng chi phí không cân đối cho một số ứng dụng cụ thể, buộc các nhà phát triển phải viết lại và triển khai lại mã để giữ cho kinh tế. tính khả thi. Tương tự, hai công cụ này cũng có độ phức tạp và hạn chế riêng của chúng.
Nó tương tác với các phần khác của bản đồ đường đi như thế nào?
để thực hiện L1 EVM, công nghệ lõi cần thiết để bằng chứng hợp lệ lớn mức độ chia sẻ với hai lĩnh vực khác:
· L2 的bằng chứng hợp lệ（即「ZK rollup」）
· Phương pháp chứng minh nhị phân Hàm băm 'STARK' không trạng thái
在 L1 成功实现bằng chứng hợp lệ，就能最终实现轻松的单人thế chấp：即使是最弱的计算机（包括手 机或智能手表）也能thế chấp。这进一步提高了解决单人thế chấp的其他限制（如 32ETH 最低限额）的价值。
Ngoài ra, bằng chứng hợp lệ của EVM của L1 có thể tăng đáng kể giới hạn gas của L1.
Nhận thức chung的bằng chứng hợp lệ
Chúng ta đang giải quyết vấn đề gì?
Nếu chúng ta muốn sử dụng SNARK để hoàn toàn xác minh một khối ETH trong mạng lưới, thì việc thực thi EVM không phải là phần duy nhất mà chúng ta cần chứng minh. Chúng ta cũng cần chứng minh Nhận thức chung, tức là một phần khác của hệ thống xử lý gửi tiền, rút tiền, ký, cập nhật số dư của người xác minh và một số yếu tố khác liên quan đến Bằng chứng về cổ phần của khối ETH.
Nhận thức chung比 EVM đơn giản nhiều, nhưng thách thức mà nó đối mặt là chúng ta không có L2 EVM tích chập, vì vậy, hầu hết công việc phải được hoàn thành bằng cách nào đó. Do đó, bất kỳ việc triển khai Nhận thức chung của ETH đều cần phải "bắt đầu từ đầu", mặc dù hệ thống chứng minh chính nó có thể được xây dựng dựa trên công việc chia sẻ.
Nó là gì và hoạt động như thế nào?
Chuỗi đèn hiệu được định nghĩa là một chức năng chuyển đổi trạng thái, giống như EVM. Chức năng chuyển đổi trạng thái bao gồm ba phần chính:
· ECADD（dùng để xác minh chữ ký BLS）
· Cặp (được sử dụng để xác minh chữ ký BLS)
· Hàm băm SHA256 (để đọc và cập nhật trạng thái)
Trong mỗi khối, chúng ta cần chứng minh 1-16 BLS12-381 ECADD cho mỗi trình xác thực (có thể có nhiều hơn một, vì chữ ký có thể được chứa trong nhiều bộ sưu tập). Đ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 ta có thể nói rằng mỗi Người xác thực chỉ cần chứng minh một ECADD BLS12-381. Hiện tại, có 30.000 chữ ký xác thực cho mỗi vị trí. Trong tương lai, điều này có thể thay đổi theo hai hướng khi đạt được tính cuối cùng của một vị trí: nếu chúng ta đi theo con đường "vũ phu", số lượng Người xác thực 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 trình xác nhận sẽ vẫn ở mức 32.768 hoặc thậm chí giảm xuống còn 8.192.
Công việc tổng hợp của BLS hoạt động như thế nào: Chỉ cần một ECADD của mỗi người tham gia để xác minh chữ ký tổng, thay vì một ECMUL. Tuy nhiên, 30000 ECADD vẫn là một lượng chứng cứ lớn.
Về việc kết hợp, hiện tại mỗi khe chỉ chứa tối đa 128 chứng minh, điều này có nghĩa là cần xác minh 128 cặp. Thông qua ElP-7549 và các sửa đổi tiếp theo, mỗi khe có thể giảm xuống còn 16 cặp. Số lượng cặp ít nhưng chi phí rất cao: thời gian chạy (hoặc chứng minh) của mỗi cặp dài hơn nhiều lần so với ECADD.
Một trong những thách thức chính của việc thực hiện phép toán BLS12-381 là không có đường cong thuận tiện có bậc bằng kích thước trường BLS12-381, điều này làm tăng 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 ETH được xây dựng bằng đường cong Bandersnatch, điều này khiến BLS12-381 trở thành đường cong tự xây dựng trong hệ thống SNARK được sử dụng để chứng minh các nhánh Verkle. Một triển khai đơn giản có thể chứng minh 100 phép cộng G1 mỗi giây; để làm cho tốc độ chứng minh đủ nhanh, hầu như chắc chắn cần sử dụng các kỹ thuật tinh vi như GKR.
Đối với giá trị băm SHA256, trường hợp tồi tệ nhất hiện tại là khối chuyển đổi thời đại, cả cây cân bằng ngắn của người xác thực và cây cân bằng lượng lớn của người xác thực sẽ được cập nhật. Cây cân bằng ngắn của mỗi người xác thực chỉ có một byte, vì vậy có 1 MB dữ liệu sẽ được băm lại. Điều này tương đương với 32768 lần gọi SHA256. Nếu có 1000 người xác thực có số dư cao hơn hoặc thấp hơn một ngưỡng, cần cập nhật số dư hiệu lực trong hồ sơ người xác thực, điều này tương đương với 1000 nhánh Merkle, do đó có thể cần 10000 lần giá trị băm. Cơ chế xáo trộn yêu cầu 90 Bit cho mỗi người xác thực (do đó cần 11 MB dữ liệu), nhưng điều này có thể tính toán bất kỳ lúc nào trong một thời đại. Trong trường hợp kết thúc một khe đơn, các số này có thể thay đổi tùy theo tình huống cụ thể. Xáo trộn trở nên không cần thiết, mặc dù Orbit có thể phục hồi một phần nhu cầu này.
Một thách thức khác là cần phải lấy lại tất cả trạng thái của người xác minh, bao gồm Khóa công khai, mới có thể xác minh một Khối. Đối với 1 triệu người xác minh, chỉ việc đọc Khóa công khai cũng cần 48 triệu byte, cộng thêm các nhánh Merkle. Điều này đòi hỏi mỗi kỷ nguyên hàng triệu giá trị băm. Nếu chúng ta phải chứng minh tính hiệu quả của PoS, một cách thực tế là một loại tính toán có thể xác minh tăng dần nào đó: lưu trữ một cấu trúc dữ liệu độc lập trong bộ nhớ của hệ thống chứng minh, cấu trúc dữ liệu này được tối ưu hóa để tìm kiếm hiệu quả và chứng minh cập nhật cho cấu trúc đó.
Tóm lại, có rất nhiều thách thức. Để đối phó hiệu quả nhất với những thách thức này, có thể cần phải thiết kế lại beacon chain một cách sâu sắc, và điều này có thể được thực hiện đồng thời với việc chuyển sang kết thúc một khoảng thời gian đơn. Những đặc điểm của việc thiết kế lại này có thể bao gồm:
· Thay đổi hàm băm: Bây giờ chúng tôi sử dụng hàm băm SHA256 "đầy đủ", vì vậy mỗi lần gọi đều phải tương ứng với hai lần gọi hàm nén dưới cùng vì lý do đệm. Nếu chúng ta chuyển sang hàm nén SHA256, chúng tôi ít nhất có thể đạt được gấp đôi lợi nhuận. Nếu chúng ta chuyển sang Poseidon, chúng tôi có thể đạt được lợi nhuận gấp 100 lần, giải quyết hoàn toàn tất cả vấn đề của chúng tôi (ít nhất là trong việc hàm băm): Có thể "đọc" 1,7 triệu giá trị hàm băm mỗi giây (54MB), thậm chí một triệu bản ghi xác minh cũng có thể được "đọc" trong vài giây.
· Nếu là Orbit, sau đó lưu trữ trực tiếp bản ghi xác thực đã được trộn: Nếu chọn một số lượng cố định của các xác thực viên (như 8192 hoặc 32768) làm ủy ban cho một khe cụ thể, chúng sẽ được đặt trực tiếp vào trạng thái bên cạnh nhau, chỉ cần ít nhất một Hàm băm để có thể đọc tất cả các Khóa công khai của xác thực viên vào chứng minh. Điều này cũng giúp hoàn thành tất cả các cập nhật cân đối một cách hiệu quả.
· Tổng 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, với các Nút khác nhau trong mạng thực hiện các bằng chứng trung gian của một tập hợp con chữ ký. Điều này tự nhiên phân chia công việc chứng minh giữa nhiều Nút trong mạng, giảm đáng kể khối lượng công việc của "câu tục ngữ cuối cùng".
· Các phương án chữ ký khác: Đối với chữ ký Lamport+ Merkle, chúng ta cần 256 + 32 giá trị hash để xác minh chữ ký; Nhân với 32768 người ký, ta có 9437184 giá trị hash. Sau khi tối ưu hóa phương án chữ ký, kết quả có thể được cải thiện thêm bằng một hằng số nhỏ. Nếu chúng ta sử dụng Poseidon, điều này có thể được chứng minh trong một khe cắm duy nhất. Nhưng thực tế, việc sử dụng phương án tổng hợp đệ quy sẽ nhanh hơn.
Có những liên hệ nào với nghiên cứu hiện có?
· Chứng chỉ Nhận thức chung ETH đơn giản (chỉ dành cho Hội đồng đồng bộ hóa)
· Helios trong SP1 đơn giản
· BLS12-381 được biên dịch trước một cách ngắn gọn
· Xác minh chữ ký tập hợp BLS dựa trên Halo2
Còn công việc nào cần làm, cách chọn lựa như thế nào:
Trên thực tế, chúng ta sẽ mất nhiều năm để có được bằng chứng hợp lệ của bình phương ETH Nhận thức chung. Đó là khoảng thời gian tương đương với khoảng thời gian chúng ta cần để thực hiện tính cuối cùng của một khe cắm, Quỹ đạo, sửa đổi Thuật toán chữ ký và phân tích bảo mật, đòi hỏi đủ tự tin để sử dụng hàm băm "tích cực" như Poseidon. Do đó, sẽ là khôn ngoan nhất khi giải quyết những vấn đề khác này và tính đến sự thân thiện của STARK trong khi giải quyết chúng.
Sự cân nhắc chính có thể nằm ở thứ tự thao tác, giữa cách tiếp cận tiến bộ hơn và cách tiếp cận "một lần thay đổi nhiều" hơn khi cải cách lớp đồng thuận Ethereum. Với EVM, cách tiếp cận tiến bộ là hợp lý vì nó giảm thiểu sự can thiệp vào tính tương thích ngược. Đối với lớp đồng thuận, tác động vào tính tương thích ngược ít hơn và việc xem xét lại các chi tiết về cách xây dựng beacon chain "toàn diện" theo cách tối ưu nhất để tăng tính thân thiện với SNARK cũng có lợi.
Làm thế nào nó tương tác với các phần khác của bản đồ con đường?
Trong quá trình thiết kế lại lâu dài cho PoS của Ethereum, tính thân thiện của STARK phải trở thành yếu tố hàng đầu, đặc biệt là tính kết thúc đơn lẻ, Orbit, thay đổi lược đồ chữ ký và việc tổng hợp chữ ký.
Liên kết gốc