Vitalik: Các mục tiêu chính cho giai đoạn The Verge của Ethereum

Tác giả: Vitalik, người sáng lập Ethereum; Người biên soạn: Deng Tong, Golden Finance

Lưu ý: Bài viết này là bài thứ tư trong chuỗi bài viết về "Sự phát triển trong tương lai của Giao thức Ethereum" được xuất bản gần đây bởi Vitalik, người sáng lập Ethereum Phần "Tương lai có thể có của giao thức Ethereum, phần 4: The Verge". Đối với phần thứ ba, hãy xem "Vitalik: Mục tiêu chính của giai đoạn Tai họa của Ethereum", phần thứ hai Xem phần "Vitalik: Giao thức Ethereum nên phát triển như thế nào trong giai đoạn The Surge" và xem phần đầu tiên "< a href= "https://www.jinse.cn/blockchain/3699549.html">Những gì khác có thể được cải thiện trong Ethereum PoS". Sau đây là toàn văn Phần 4:

---

Đặc biệt cảm ơn Justin Drake, Hsiao-wei Wang, Guillaume Ballet, Ignacio, Josh Rudolf, Lev Soukhanov, Ryan Sean Adams và Uma Roy vì 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 rằng chuỗi đó là chính xác. Ngay cả khi 95% nút chạy đồng thuận trên chuỗi (PoW, PoS...) 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 chuỗi. Các bên liên quan không thuộc nhóm như vậy sẽ tự động hội tụ và tiếp tục xây dựng chuỗi tiếp tục tuân theo các quy tắc cũ và người dùng được xác minh đầy đủ sẽ tuân theo chuỗi.

Đây là điểm khác biệt chính giữa blockchain và hệ thống tập trung. Tuy nhiên, để duy trì thuộc tính này, việc chạy một nút đã được xác minh đầy đủ cần phải khả thi trên thực tế đối với một lượng lớn người dùng. Điều này áp dụng cho cả người đặt cược (như thể người đặt cược không xác thực chuỗi, họ không thực sự 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 của người tiêu dùng (bao gồm cả máy tính được sử dụng để viết bài này), nhưng thực hiện điều đó rất khó khăn. The Verge nhằm mục đích thay đổi điều này, làm cho các chuỗi được xác minh đầy đủ trở nên rẻ về mặt tính toán đến mức mọi ví di động, ví thiết bị trình duyệt và thậm chí cả đồng hồ thông minh đều thực hiện điều này theo mặc định .

The Verge, Lộ trình năm 2023.

Ban đầu, "Verge" đề cập đến việc chuyển bộ lưu trữ trạng thái Ethereum sang Ý tưởng cây Verkle - Cấu trúc cây này cho phép các bằng chứng nhỏ gọn hơn, cho phép xác minh các khối Ethereum không trạng thái. Các nút có thể xác minh các khối Ethereum mà không cần bất kỳ trạng thái Ethereum nào (số dư tài khoản, mã hợp đồng, bộ nhớ...) trên ổ cứng của chúng, nhưng với chi phí hàng trăm kilobyte dữ liệu bằng chứng và vài trăm mili giây thêm thời gian để xác minh bằng chứng. Ngày nay, Verge thể hiện tầm nhìn lớn hơn, tập trung vào việc đạt được xác minh hiệu quả tài nguyên tối đa cho chuỗi Ethereum, không chỉ bao gồm công nghệ xác minh không trạng thái mà còn bao gồm việc sử dụng SNARK để xác minh tất cả các lần thực thi Ethereum.

Ngoài việc tập trung lâu dài vào xác minh SNARK của toàn bộ chuỗi, một vấn đề 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 rất dễ bị tấn công bởi máy tính lượng tử, vì vậy nếu thay thế 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 thế những cây này một lần nữa. Giải pháp thay thế tự nhiên cho cây Merkle là chuyển trực tiếp sang sử dụng nhánh STARK Merkle trong cây nhị phân. Trong lịch sử, điều này không được coi là 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 1,7 triệu hàm băm Poseidon mỗi giây trên máy tính xách tay có Circle STARK và thời gian chứng minh cho các hàm băm "truyền thống" hơn cũng đang giảm nhanh chóng nhờ các công nghệ như GKR.

Kết quả là, Verge đã trở nên cởi mở hơn trong năm qua và có rất nhiều cơ hội.

The Verge: Mục tiêu chính

• Ứng dụng khách không trạng thái: Việc xác thực đầy đủ các ứng dụng khách và nút đặt cược yêu cầu không quá vài GB dung lượng lưu trữ.

• (Dài hạn) Xác minh đầy đủ chuỗi (đồ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 bài viết này, chúng tôi tập trung vào những điều sau:

• Xác minh không trạng thái: Verkle hoặc STARK

• Bằng chứng hợp lệ về việc thực thi EVM

< li>

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 minh các khối và số lượng này tiếp tục 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à khách hàng cá nhân phải lưu trữ một số dữ liệu bổ sung ngoài khả năng cập nhật bản thử nghiệm một cách hiệu quả.

Điều này làm giảm Số lượng số người dùng chạy các nút Ethereum đã được xác thực đầy đủ: Mặc dù ổ cứng đủ lớn để lưu trữ tất cả trạng thái Ethereum và thậm chí cả số năm lịch sử, 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 vấn đề đau đầu khi thiết lập một 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ụ: điều này khiến người đặt cược gặp khó khăn hơn trong việc nâng cấp cài đặt đặt cược của họ. Về mặt kỹ thuật, việc này có thể được thực hiện mà không có thời gian ngừng hoạt động - khởi động ứng dụng khách mới, đợi nó đồng bộ hóa, sau đó tắt ứng dụng khách cũ và chuyển khóa - nhưng trên thực tế, việc này phức tạp về mặt kỹ thuật.

Nó là gì và 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 sở hữu trạng thái hoàn chỉnh. Thay vào đó, mỗi khối đi kèm với một nhân chứng bao gồm (i) một giá trị tại một vị trí cụ thể trong trạng thái (ví dụ: mã, số dư, bộ nhớ) mà khối sẽ truy cập và (ii) ) bằng chứng mật mã của các giá trị này là chính xác.

Trên thực tế, việc triển khai 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 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 cả các nhánh Merkle "gốc" và khả năng "gói" các nhánh Merkle trong STARK. Những khó khăn chính nảy sinh từ hai điểm yếu của MPT:

• Đó là một Một hexatree (nghĩa là mỗi nút có 16 nút con). Điều này có nghĩa là trung bình, một bằng chứng trong cây có kích thước N có 32*(16-1)*log16(N) = 120*log2(N) byte hoặc khoảng 3840 byte. Đối với cây nhị phân, chỉ cần 32*(2-1)*log2(N) = 32*log2(N) byte, tức là khoảng 1024 byte.

• Mã này không được Merkel hóa. Điều này có nghĩa là việc cung cấp bất kỳ quyền truy cập nào vào mã tài khoản đều yêu cầu cung cấp mã hoàn chỉnh, với độ dài tối đa là 24.000 byte.

Chúng ta có thể tính toán trường hợp xấu nhất như sau:

30.000.000 Gas / 2.400 chi phí đọc tài khoản ("lạnh") * (5 * 480 + 24.000) = 330.000.000 byte

< p >Chi phí nhánh giảm một chút (5*480 thay vì 8*480) vì khi số lượng nhánh lớn, phần trên của nhánh được lặp lại. Nhưng ngay cả khi đó, lượng dữ liệu được tải xuống trong một khe 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 không thân thiện với STARK lắm, (ii) 330 MB dữ liệu có nghĩa là chúng tôi phải đảm bảo 5 triệu lệnh gọi đến hàm vòng KECCAK, mặc dù chúng tôi có thể làm cho STARK proof KECCAK hiệu quả hơn, có rất nhiều điều không thể chứng minh được trên tất cả ngoại trừ phần cứng tiêu dùng mạnh mẽ nhất.

Nếu chúng ta chỉ thay cây hex bằng cây nhị phân và thêm mã Merkelize thì trường hợp xấu nhất sẽ là khoảng 30.000.000 / 2.400 * 32 * (32 - 14 + 8) = 10.400.000 byte~ 214 nhánh , 8 trong số đó là bằng chứng về chiều dài đi vào lá). 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 vào từng khối mã riêng lẻ; EIP-4762 thực hiện việc này. 10,4 MB tốt hơn nhiều nhưng vẫn có quá nhiều dữ liệu để tải xuống trong một khe cho nhiều nút. Vì vậy, chúng tôi cần giới thiệu một số công nghệ mạnh mẽ hơn. Có hai giải pháp chính cho việc này: Cây Verkle và cây băm nhị phân Starked.

Cây Verkle

Cây Verkle sử dụng các cam kết vectơ dựa trên đường cong elip để tạo ra các bằng chứng ngắn hơn. Điều quan trọng là, bất kể chiều rộng của cây, đoạn chứng minh cho mỗi mối quan hệ cha-con chỉ có 32 byte. Hạn chế duy nhất về độ rộng của cây là nếu cây quá rộng thì việc chứng minh sẽ kém hiệu quả về mặt tính toán. Độ rộng triển khai được đề xuất cho Ethereum là 256.

Do đó, bằng chứng đang được tiến hành Kích thước của một nhánh đơn lẻ trở thành 32*log256(N) = 4*log2(N) byte. Kích thước chứng minh tối đa về mặt lý thuyết trở thành xấp xỉ 30.000.000/2.400*32*(32-14+8)/8 = 1.300.000 byte (toán học hơi khác trong thực tế do sự phân bố không đồng đều của các khối trạng thái, nhưng điều này đóng vai trò là lần đầu tiên rất tốt ).

Như một cảnh báo bổ sung, xin lưu ý rằng 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 sẽ là kẻ tấn công cố tình "khai thác" cả hai địa chỉ để Có một tiền tố chung dài trong cây và đọc từ một trong số chúng, có thể kéo dài độ dài nhánh trong trường hợp xấu nhất thêm khoảng 2 lần nữa. Nhưng ngay cả với cảnh báo này, cây Verkle vẫn mang lại cho chúng ta bằng chứng trong trường hợp xấu nhất là khoảng 2,6 MB, gần khớp với dữ liệu cuộc gọi trong trường hợp xấu nhất hiện nay.

Chúng tôi cũng sử dụng cảnh báo này để thực hiện một việc khác: 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à quyền truy cập vùng lân cận chỉ tính phí 200 Gas. Đối với các 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à 30.000.000/200*32 = 4.800.800 byte, vẫn nằm trong khoảng cho phép. Nếu chúng ta muốn giảm giá trị này vì lý do bảo mật, chúng ta có thể tăng nhẹ chi phí truy cập liền kề.

Cây băm nhị phân có gắn dấu sao

Kỹ thuật ở đây khá dễ hiểu: bạn tạo một cây nhị phân, lấy tối đa 10,4- mà bạn cần chứng minh giá trị trong khối MB bằng chứng và thay thế bằng chứng bằng STARK của bằng chứng. Điều này khiến chúng tôi nhận thấy rằng 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 của STARK thực tế.

Thách thức chính ở đây là thời gian chứng 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 tính toán giá trị băm. Khối 10,4 MB có nghĩa là 330.000 băm. Nếu chúng ta thêm khả năng kẻ tấn công "khai thác" cây cho các địa chỉ có tiền tố công khai dài, thì trường hợp xấu nhất thực sự sẽ là khoảng 660.000 hàm băm. Vì vậy, nếu chúng ta có thể chứng minh khoảng 200.000 băm mỗi giây thì tốt.

Những con số này đã đạt được trên máy tính xách tay tiêu dùng có chức năng băm Poseidon, được thiết kế đặc biệt để thân thiện với STARK. Tuy nhiên, Poseidon còn khá non nớt nên nhiều người vẫn chưa tin tưởng vào độ an toàn của nó. Do đó, có hai con đường thực tế phía trước:

• An ninh hàng loạt trên Poseidon nhanh chóng Phân tích nó , và làm quen với nó để triển khai nó trong L1

• Sử dụng hàm băm "bảo thủ" hơn như SHA256 hoặc BLAKE

Tính đến thời điểm viết bài này, trình chứng minh STARK của Starkware chỉ có thể chứng minh khoảng 10-30 nghìn hàm băm mỗi giây trên máy tính xách tay tiêu dùng nếu muốn chứng minh các hàm băm thận trọng. Tuy nhiên, công nghệ STARK đang phát triển nhanh chóng. Ngay cả ngày nay, công nghệ dựa trên GKR vẫn hứa hẹn sẽ đưa mức này lên khoảng 100-200 nghìn.

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 cho phép xác minh không trạng thái hiệu quả hơn:

• Nhóm bộ nhớ: Khi một giao dịch được phát sóng, các Nút cần xác minh rằng giao dịch đó hợp lệ trước khi phát sóng lại nó. Ngày nay, việc xác minh không chỉ bao gồm việc xác minh chữ ký mà còn kiểm tra xem số dư có đủ hay không và số nonce có chính xác hay không. Trong tương lai (ví dụ: sử dụng tính năng tóm tắt 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, các giao dịch sẽ cần phải kèm theo bằng chứng chứng minh đối tượng trạng thái.

• Danh sách bao gồm: Đây là tính năng được đề xuất cho phép trình xác thực bằng chứng cổ phần (có thể nhỏ và không phức tạp) buộc các Giao dịch khối tiếp theo được bao gồm bất kể mong muốn của người xây dựng khối (có thể lớn và phức tạp). Điều này sẽ làm giảm khả năng các tác nhân mạnh mẽ 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 thực 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.

• Khách hàng nhẹ: Nếu chúng tôi muốn người dùng truy cập chuỗi thông qua ví (ví dụ: Metamask, Rainbow, Rabby...) mà không tin tưởng vào sự tham gia tập trung , họ cần chạy một ứng dụng khách nhẹ (chẳng hạn như Helios). Mô-đun Helios cốt lõi cung cấp cho người dùng trạng thái gốc được xác thực. Tuy nhiên, để có trải nghiệm hoàn toàn không tin cậy, người dùng cần cung cấp bằng chứng cho từng lệnh gọi RPC riêng lẻ mà họ thực hiện (ví dụ: đối với yêu cầu eth_call, người dùng cần bằng chứng về tất cả trạng thái được truy cập trong cuộc gọi);

Một đ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 số lượng bằng chứng khá lớn, nhưng mỗi bằng chứng đều nhỏ. Do đó, bằng chứng STARK thực sự không có ý nghĩa gì đối với họ; thay vào đó, việc sử dụng trực tiếp nhánh Merkle là thực tế nhất. Một ưu điểm khác của các nhánh Merkle là chúng có thể cập nhật: được cung cấp bằng chứng về đối tượng trạng thái X bắt nguồn từ khối B, bạn có thể cập nhật bằng chứng nếu bạn nhận được khối con B2 với các nhân chứng của nó để nó được bắt nguồn từ khối B2. Bản thân các bằng chứng Verkle cũng có thể cập nhật được.

Mối liên hệ với nghiên cứu hiện tại là gì?

Cây Verkle: https://vitalik.eth.limo/general/2021/06/18/verkle.html

John Bài viết gốc về cây Verkle của Kuszmaul: https://math.mit. /research/highschool/primes/materials/2018/Kuszmaul.pdf

Dữ liệu chứng nhận Starkware: https://x.com/StarkWareLtd/status/1807776563188162562

Giấy Poseidon2 : https://eprint.iacr.org/2023/323

Ajtai (hàm băm nhanh thay thế dựa trên độ cứng của mạng): https://www.wisdom.weizmann.ac.il/~oded/COL/cfh. /a>

Verkle.info: https:// verkle. info/

Cần phải làm gì nữa, cần phải đánh đổi những gì?

Công việc chính còn lại cần làm là:

• Thêm phân tích hậu quả của EIP-4762 (thay đổi chi phí gas không trạng thái)

• Còn nhiều việc phải làm để hoàn thiện và thử nghiệm quy trình chuyển đổi, đây là một bước tiến lớn về mức độ phức tạp của bất kỳ EIP không trạng thái nào Phần

• Phân tích bảo mật sâu hơn về Poseidon, Ajtai và các hàm băm "thân thiện với STARK" khác

• Để phát triển hơn nữa Một siêu- giao thức STARK hiệu quả dựa trên các hàm băm "bảo thủ" (hoặc "truyền thống"), chẳng hạn như các ý tưởng dựa trên Binius hoặc GKR.

Chúng ta sẽ sớm đi đến điểm quyết định nên chọn phương án nào trong ba phương án sau: (i) Cây Verkle, (ii) hàm băm thân thiện STARK và (iii) hàm băm bảo thủ. Các thuộc tính của chúng có thể được tóm tắt đại khái trong bảng sau:

Ngoài những "số tiêu đề" này, còn có một số điều quan trọng khác cần cân nhắc:

Ngày nay, Mã cây Verkle đã khá trưởng thành. Việc sử dụng bất kỳ thứ gì khác ngoài Verkle thực sự sẽ làm trì hoãn việc triển khai, rất có thể là thông qua một đợt phân nhánh cứng. Điều này có thể ổn, đặ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 bộ chứng minh và nếu chúng tôi có các tính năng quan trọng khác, chúng tôi muốn đưa vào Ethereum càng sớm càng tốt.

• Sử dụng hàm băm để cập nhật các gốc trạng thái nhanh hơn so với sử dụng cây Verkle. Điều này có nghĩa là phương pháp dựa trên hàm băm có thể rút ngắn thời gian đồng bộ hóa của nút đầy đủ.

• Vcây erkle 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 nhóm bộ nhớ, danh sách bao gồm và các trường hợp sử dụng khác, đồng thời nó cũng có thể giúp việc triển khai của bạn hiệu quả hơn: nếu bạn cập nhật đối tượng trạng thái, bạn có thể cập nhật nhân chứng của cấp áp chót mà không cần đọc cấp cuối cùng.

• Cây Verkle khó chứng minh hơn thông qua SNARK. Bằng chứng Verkle gây 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ó chi phí hoạt động đáng kể hoặc bản thân nó có các phần bên trong tùy chỉnh chứa phần 256-bit cho bằng chứng Verkle.

Nếu chúng ta muốn khả năng cập nhật của các nhân chứng Verkle được thực hiện theo cách an toàn lượng tử và khá hiệu quả, thì một cách tiếp cận khả thi khác là cây Merkle dựa trên lưới.

Nếu hệ thống không đủ hiệu quả trong trường hợp xấu nhất, chúng ta có thể sử dụng một "con thỏ đội mũ" khác để bù đắp cho sự thiếu hụt này, và đó là Khí đa chiều: for (i) calldata, (ii) Có các giới hạn Gas riêng để tính toán, (iii) quyền truy cập trạng thái và có thể có các tài nguyên khác nhau. 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. Đối với Khí đa chiều, số nhánh tối đa của lý thuyết cần chứng minh có thể giảm từ 30.000.000/2400 = 12.500 xuống còn 3000. Điều này sẽ làm cho BLAKE3 (hầu như không) phù hợp cho đến tận ngày nay mà không cần phải cải tiến thêm nữa.

Khí đa chiều cho phép các giới hạn tài nguyên của một khối sao chép chặt chẽ hơn các giới hạn tài nguyên của phần cứng cơ bản.

Một "con thỏ bật lên" khác là đề xuất trì hoãn việc tính toán nghiệm trạng thái cho đến khi có các khe sau khối. Điều này sẽ cho chúng ta đủ 12 giây để tính toán gốc trạng thái, điều đó có nghĩa là ngay cả trong trường hợp cực đoan nhất, chỉ khoảng 60.000 băm/giây thời gian chứng minh là đủ, điều này một lần nữa khiến chúng ta rơi vào BLAKE3 hầu như không đủ trong phạm vi sử dụng .

Nhược điểm của phương pháp này là nó làm tăng độ trễ của máy khách hạng nhẹ trong một khoảng thời gian, mặc dù có những phiên bản thông minh hơn của kỹ thuật này có thể giảm độ trễ này xuống chỉ còn độ trễ xây dựng hợp lý. Ví dụ: ngay khi bất kỳ nút nào tạo ra bằng chứng, nó có thể phát bằng chứng đó trên mạ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 trạng thái làm tăng đáng kể sự thuận tiện của việc đặt cược cá nhân. Điều này sẽ càng trở nên có giá trị hơn nếu công nghệ giúp giảm số dư tối thiểu cho việc đặt cược riêng lẻ (chẳng hạn như Orbit SSF hoặc chiến lược lớp ứng dụng (chẳng hạn như đặt cược theo đội)) trở nên khả dụng.

Khí đa chiều sẽ trở nên dễ dàng hơn nếu EOF được giới thiệu cùng lúc. Điều này là do độ phức tạp chính của Gas đa chiều để thực thi là xử lý các lệnh gọi con không chuyển toàn bộ Gas của lệnh gọi gốc và EOF loại bỏ điều này bằng cách đơn giản biến các lệnh gọi con đó thành bất hợp pháp (và về cơ bản là Sự trừu tượng hóa tài khoản sẽ cung cấp một giải pháp thay thế trong giao thức cho trường hợp sử dụng chính của lệnh gọi phụ Gas một phần hiện tại).

Một sức mạnh tổng hợp quan trọng khác là 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 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 quốc gia. Ngay cả khi khách hàng không có trạng thái, ước mơ gần như không có bộ nhớ nào ở phía khách hàng là không thể thực hiện được trừ khi chúng tôi cũng có thể giảm bớt trách nhiệm lưu trữ lịch sử của 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 mạng torrent hoặc cổng thông tin.

Bằng chứng về tính hiệu quả của việc thực thi EVM

Chúng ta muốn 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: bạn có thể xác minh khối Ethereum bằng cách (i) tải xuống khối, thậm chí có thể chỉ là một phần nhỏ của khối và Thực hiện tính khả dụng của dữ liệu lấy mẫu và (ii) xác minh một tập hợp con nhỏ các bằng chứng cho thấy khối đó hợp lệ. Đây sẽ là một hoạt động sử dụng ít tài nguyên có thể được thực hiện trên máy khách di động, trong ví trình duyệt hoặc thậm chí (không có phần sẵn có của dữ liệu) trong một chuỗi khác.

Để đạt được điều này, người ta cần có bằng chứng SNARK hoặc STARK về (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 trong quá trình cải tiến hơn nữa đối với lớp đồng thuận (ví dụ: tính hữu hạn 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à 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 tiền trạng thái, một khối B và bạn đang tính toán một trạng thái hậu S' = STF(S, B). Nếu người dùng đang sử dụng máy khách nhẹ, thay vào đó, họ không có S và S' hoặc thậm chí là B đầy đủ, 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. Phát biểu đầy đủ cần được chứng minh có giá trị xấp xỉ:

• Ý kiến ​​công khai :

  strong>Gốc trạng thái trước R, gốc trạng thái sau R' và hàm băm khối H.

• Đầu vào riêng tư: Khối B, các đối tượng ở trạng thái được khối Q truy cập, 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ụ: Merkle nhánh) P

• Khẳng định 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) quá trình thực thi chỉ truy cập các đối tượng bên trong Q, (ii) khối hợp lệ, và (iii) kết quả là Q' .

• Yêu cầu 3: Nếu bạn tính toán lại trạng thái gốc mới bằng cách sử dụng thông tin trong Q' và P, bạn sẽ nhận được R' .

Nếu nó tồn tại, bạn có thể có một ứng dụng khách nhẹ có thể xác minh đầy đủ 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. Để có được một ứng dụng khách Ethereum thực sự được xác minh đầy đủ, bạn cũng cần phải làm điều tương tự đối với bên đồng thuận.

Việc triển khai bằng chứng hợp lệ của các phép tính EVM đã tồn tại và được L2 sử dụng nhiều. Tuy nhiên, vẫn còn nhiều việc phải làm trước khi có thể áp dụng bằng chứng hiệu quả của EVM cho L1.

Mối liên hệ với nghiên cứu hiện tại là gì?

EC PSE ZK-EVM (hiện không được dùng nữa vì có các tùy chọn tốt hơn): https://github.com/privacy-scaling-explorations/zkevm- Circuits

Zeth, hoạt động bằng cách biên dịch EVM thành RISC-0 ZK-VM: https://github.com /risc0/zeth

Dự án xác minh chính thức ZK-EVM: https:/ /verified-zkevm.org/

Cần phải làm gì nữa, cần phải đánh đổi những gì?

Ngày nay, Bằng chứng về tính hiệu quả của EVM là chưa đủ ở hai khía cạnh: bảo mật và thời gian chứng minh.

Bằng chứng về tính hợp lệ của bảo mật yêu cầu đảm bảo rằng SNARK thực sự xác minh tính toán EVM và không có lỗi nào trong đó. Hai kỹ thuật chính để cải thiện tính bảo mật là nhiều người chứng minh và xác minh chính thức. Nhiều nhà cung cấp có nghĩa là có nhiều triển khai bằng chứng hợp lệ được viết độc lập, giống như có nhiều khách hàng và yêu cầu khách hàng chấp nhận một khối nếu một tập hợp con đủ lớn trong số các triển khai đó chứng minh khối đó. Xác minh chính thức bao gồm việc chứng minh tính hợp lệ bằng cách 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ư Lean4. Bằng chứng chỉ chấp nhận làm đầu vào triển khai chính xác đặc tả EVM cơ bản được viết bằng Python.

Thời gian chứng minh đủ nhanh có nghĩa là bất kỳ khối Ethereum nào cũng có thể được chứng 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 tôi cần phát triển trong ba lĩnh vực:

• Song song – Trình chứng minh EVM nhanh nhất hiện nay có thể chứng minh khối Ethereum trung bình trong khoảng 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à sau đó tổng hợp công việc của chúng lại với nhau. Về lý thuyết, chúng tôi biết chính xác cách tạo một bộ chứng minh EVM có thể chứng minh các tính toán trong thời gian O(log(N)): để GPU thực hiện từng bước, sau đó thực hiện một "cây tổng hợp":

Thực hiện điều này Có những thách thức. Để hoạt động ngay cả trong trường hợp xấu nhất (tức là các giao dịch rất lớn chiếm toàn bộ khối), việc phân chia tính toán không thể thực hiện trên mỗi giao dịch; nó phải theo mỗi mã opcode (EVM hoặc VM cơ bản như RISC-V). Một thách thức triển khai quan trọng khiến điều này không hoàn toàn tầm thường là cần phải đảm bảo rằng "bộ nhớ" của VM nhất quán giữa các phần khác nhau của bằng chứng. Tuy nhiên, nếu chúng ta có thể thực hiện 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 bộ chứng minh đã được giải quyết, ngay cả khi không có sự cải thiện nào ở bất kỳ trục nào khác.

• Chứng minh sự tối ưu hóa hệ thống—— Orion, Các hệ thống chứng minh mới như Binius và GKR có thể giúp giảm đáng kể thời gian chứng minh cho máy tính có mục đích chung.

• Những thay đổi khác về mức tiêu thụ khí của EVM - Nhiều thứ trong EVM có thể được tối ưu hóa để thân thiện hơn với người thử nghiệm, đặc biệt là trong Trường hợp xấu nhất. Việc chứng minh một khối Ethereum trung bình trong 4 giây là không đủ nếu kẻ tấn công có thể xây dựng một khối mất 10 phút thời gian của người chứng minh. Những thay đổi EVM bắt buộc có thể được chia thành hai loại chính:

• Biến động 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 việc tính toán tương đối nhanh. EIP-7667 là EIP được đề xuất nhằm 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) được hiển thị dưới dạng mã opcode tương đối rẻ và được biên dịch trước. Để 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 chứng minh là tương đối rẻ, do đó giữ nguyên thông lượng 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 một giải pháp thay thế thân thiện hơn với STARK, chúng ta cũng cần thay thế danh sách giao dịch, biên lai cây và các cấu trúc khác 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 Ethan Kissling sang SSZ ([1] [2] [3]) là một bước đi theo hướng này.

Ngoài ra, hai "thỏ ra khỏi mũ" được đề cập ở phần trước (Khí đa chiều và trạng thái trạng thái trì hoãn) cũng có thể được cung cấp trợ giúp tại đây. Tuy nhiên, cần lưu ý rằng không giống như xác minh không trạng thái, điều đó 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 ngày nay, ngay cả với những công nghệ này, việc xác minh ZK-EVM đầy đủ sẽ yêu cầu nhiều công việc hơn — chỉ yêu cầu ít việc phải làm hơn.

Một điều không được đề cập ở trên là phần cứng chứng minh: sử dụng GPU, FPGA và ASIC để tạo ra bằng chứng nhanh hơn. Fabric Cryptology, Cysic và Accseal là những động lực thúc đẩy ba công ty này. Điều này rất có giá trị đối với Lớp 2, nhưng nó khó có thể được cân nhắc mang tính quyết định đối với Lớp 1 vì có mong muốn mạnh mẽ là giữ cho Lớp 1 được phân cấp cao, điều đó có nghĩa là việc tạo bằng chứng phải nằm trên một tập hợp con khá lớn trong phạm vi khả năng. Người dùng Ethereum sẽ không gặp phải tình trạng tắc nghẽn phần cứng của một công ty nào. Lớp 2 có thể thực hiện sự đánh đổi triệt để hơn.

Còn nhiều việc phải làm trong các lĩnh vực này:

• Bằng chứng song song yêu cầu hệ thống chứng minh trong đó các phần khác nhau của bằng chứng có thể "chia sẻ bộ nhớ" (ví dụ: bảng tra cứu). Chúng tôi biết các kỹ thuật để thực hiện việc này nhưng chúng cần được triển khai.

• Chúng tôi cần phân tích nhiều hơn để tìm ra các thay đổi lý tưởng về chi phí gas nhằm giảm thiểu thời gian kiểm chứng 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 về hệ thống bằng chứng

Những sự đánh đổi có thể xảy ra ở đây bao gồm:

• Bảo mật và thời gian chứng minh: Ưu điểm của việc sử dụng hàm băm Choice, a hệ thống chứng minh có các giả định bảo mật phức tạp hơn hoặc tích cực hơn hoặc các lựa chọn thiết kế khác có thể làm giảm thời gian chứng minh.

• Sự phân cấp và thời gian của nhà cung cấp: Cộng đồng cần thống nhất về "thông số kỹ thuật" cho phần cứng của nhà cung cấp dịch vụ 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 dành cho người tiêu dùng cao cấp có thể chứng minh các khối Ethereum trong 4 giây không? Một cái gì đó ở giữa?

• Khả năng tương thích ngược bị phá vỡ ở mức độ nào: Những thiếu sót ở các lĩnh vực khác có thể được bù đắp bằng cách thực hiện những thay đổi mạnh mẽ hơn về chi phí khí đốt, nhưng điều này còn quan trọng hơn có khả năng làm tăng chi phí của một số ứng dụng một cách không tương xứng và 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, “con thỏ đội mũ” cũng có những phức tạp và khuyết điểm 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 EVM ở lớp 1 được chia sẻ nhiều với hai lĩnh vực còn lại:

• Bằng chứng hợp lệ lớp 2 (tức là "bản tổng hợp ZK")

• "Bằng chứng băm nhị phân STARK" Phương pháp không trạng thái

  < /li>

Việc triển khai thành công bằng chứng xác thực ở lớp 1 cho phép đặt cược đơn lẻ một cách dễ dàng nhất: ngay cả những máy tính yếu nhất (bao gồm cả điện thoại 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 (ví dụ: tối thiểu 32 ETH).

Hơn nữa, hiệu quả EVM của L1 chứng tỏ cải thiện đáng kể giới hạn Gas của L1.

Bằng chứng về tính hợp lệ của sự đồng thuận

Chúng ta muốn giải quyết vấn đề gì?

Nếu chúng tôi muốn có thể xác minh đầy đủ các 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ó sự tổng hợp EVM lớp 2, đó là lý do tại sao 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 thực hiện "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ó.

Nó là gì và hoạt động như thế nào?

Beacon chain được định nghĩa là hàm chuyển trạng thái, giống như EVM. Hàm chuyển trạng thái được xác định bởi ba yếu tố:

• ECADD (được sử dụng để xác minh BLS signatures )

• Ghép nối (dùng để xác minh chữ ký BLS)

• Băm SHA256 (dùng để đọc và cập nhật trạng thái)

• p>

Trong mỗi khối, chúng tôi cần chứng thực 1-16 BLS12-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 tập hợp ở giữa). Đ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 trình xác thực đều là BLS12-381 ECADD. Ngày nay, mỗi kỷ nguyên được ký bởi khoảng 30.000 người xác nhận. Trong tương lai, điều này có thể thay đổi theo một trong hai hướng đối với tính hữu hạn của một vị trí (xem hướng dẫn tại đây): Nếu chúng tôi đi theo con đường "bạo lực", con số này có thể tăng lên 1 triệu người xác thực trên mỗi vị trí. Trong khi đó, với Orbit SSF sẽ duy trì ở mức 32.768 hoặc thậm chí giảm xuống còn 8,1.

Cách hoạt động của tính năng tổng hợp BLS. Việc xác minh chữ ký tổng hợp chỉ yêu cầu ECADD của mỗi người tham gia chứ không phải ECMUL. Nhưng 30.000 ECADD vẫn còn nhiều điều phải chứng minh.

Đối với các cặp, hiện có tối đa 128 chứng thực cho mỗi vị trí, nghĩa là cần phải xác minh 128 cặp. Với EIP-7549 và những thay đổi khác, con số này có thể giảm xuống còn 16 trên 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.

Thách thức lớn trong việc chứng minh hoạt động BLS12-381 là không có đường cong thuận tiện nào có bậc bằng BLS12 - Kích thước trường 381, bổ sung 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 BLS12-381 trở thành một đường cong tự nhiên để chứng minh các nhánh Verkle trong hệ thống SNARK. Việc triển khai khá đơn giản có thể cung cấp ~ 100 G1 bổ sung mỗi giây; nó gần như chắc chắn sẽ yêu cầu công nghệ thông minh như GKR để chứng minh đủ nhanh.

Đối với hàm băm SHA256, trường hợp xấu nhất hiện tại là khối chuyển tiếp kỷ nguyên, trong đó toàn bộ cây cân bằng ngắn của trình xác thực và một 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 của trình xác thực chỉ có một byte cho mỗi trình xác thực, do đó ~ 1 MB dữ liệu được thử lại. Điều này tương đương với 32.768 cuộc gọi SHA256. Nếu số dư của một nghìn trình xác thực ở trên hoặc dưới ngưỡng thì số dư hợp lệ trong bản ghi của trình 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ó khả năng là 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. Đối với tính chất cuối cùng của một khe, những con số này có thể tăng hoặc giảm trở lại tùy thuộc vào chi tiết. Việc xáo trộn trở nên không cần thiết, mặc dù các bản nhạc có thể phục hồi nhu cầu xáo trộn ở một mức độ nào đó.

Một thách thức khác là cần phải đọc 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, cộng với nhánh Merkle, chỉ riêng việc đọc khóa chung sẽ cần 48 triệu byte. Điều này đòi hỏi hàng triệu hàm băm mỗi kỷ nguyên. Nếu hôm nay chúng tôi phải chứng minh xác minh bằng chứng cổ phần, thì cách tiếp cận thực tế sẽ là một số dạng tính toán có thể xác minh tăng dần: lưu trữ cấu trúc dữ liệu riêng biệt trong hệ thống bằng chứng được tối ưu hóa để tra cứu hiệu quả và cung cấp các bản cập nhật cho cấu trúc này.

Nói chung là có rất nhiều thách thức.

Để 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 tính năng cuối cùng 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 :Ngày nay, hàm băm SHA256 "đầy đủ" được sử dụng, do đó, do có phần đệm, mỗi lệnh gọi tương ứng với hai lệnh gọi đến hàm nén cơ bản. Ít nhất, chúng ta có thể tăng gấp đôi bằng cách chuyển sang nén SHA256. Thay vào đó, nếu chúng tôi sử dụng Poseidon, chúng tôi sẽ nhận đượ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à đối với hàm băm): 1,7 triệu hàm băm mỗi giây (54 MB) và thậm chí "đọc một triệu bản ghi trình xác thực" "Có thể chứng minh trong vài giây.

• Trong trường hợp Orbit, hãy lưu trữ trực tiếp các bản ghi trình xác thực được xáo trộn: Nếu bạn chọn một số lượng trình xác thực nhất định (ví dụ: 8.192 hoặc 32.768) dưới dạng Đã cho ủy ban của một vị trí, sau đó đặt chúng trực tiếp vào trạng thái cạnh nhau sao cho cần có số lượng băm tối thiểu để đọc tất cả các khóa công khai của trình xác thực vào bằng chứng. Điều này cũng sẽ 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ẽ thực sự liên quan đến một số loại bằng chứng đệ quy, trong đó các bằng chứng trung gian cho một tập hợp con chữ ký sẽ được thực hiện được tạo ra bằng cách thực hiện tại mỗi nút. Điều này sẽ dàn trải tải bằng chứng một cách tự nhiên trên nhiều nút trong mạng, làm cho khối lượng công việc của "người chứng minh cuối cùng" nhỏ hơn nhiều.

• Các lược đồ chữ ký khác: Đối với chữ ký Lamport+Merkle, chúng tôi cần 256+32 hàm băm để xác minh chữ ký; nhân với 32.768 người ký để có được 9.437.184 hàm băm . Việc tối ưu hóa sơ đồ chữ ký có thể cải thiện hơn nữa điều này bằng một hệ số không đổi nhỏ. Nếu chúng tôi sử dụng Poseidon, điều này nằm trong phạm vi những gì có thể được chứng minh trong một vị trí duy nhất. Nhưng thực tế điều này sẽ nhanh hơn với sơ đồ tổng hợp đệ quy.

Mối liên hệ với nghiên cứu hiện tại là gì?

Bằng chứng đồng thuận Ethereum đơn giản (chỉ ủy ban đồng bộ hóa): https://github.com/succinctlabs/eth-proof-of-consensus

Đơn giản, Helios trong SP1: https://github.com/succinctlabs/sp1-helios

Biên dịch trước BLS12-381 ngắn gọn:< a href="https ://blog.succinct.xyz/succinctshipsprecompiles/" _src="https://blog.succinct.xyz/succinctshipsprecompiles/">https://blog.succinct.xyz/succinctshipsprecompiles/

< p style="text-align: left;">Xác minh chữ ký tổng hợp BLS dựa trên Halo2: https://ethresear. ch/t/zkpos -with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671

Cần phải làm gì nữa, cần phải đánh đổi những gì?

Trên thực tế, sẽ mất vài năm trước khi chúng ta có bằng chứng về tính hợp lệ của sự đồng thuận Ethereum. Đây gần như là cùng một dòng thời gian mà chúng tôi cần để triển khai các thay đổi về thuật toán cuối cùng, quỹ đạo, chữ ký và phân tích bảo mật tiềm năng để có đủ tự tin sử dụng hàm băm "tích cực" như Poseidon. Do đó, điều hợp lý nhất là giải quyết những vấn đề khác này và làm như vậy với tâm trí 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 "nhiều thay đổi 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. Đối với lớp đồng thuận, khả năng tương thích ngược ít thành vấn đề hơn và sẽ có ích hơn nếu xem xét lại một cách "toàn diện" hơn 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?

Tính thân thiện của STARK cần phải là trọng tâm chính trong quá trình thiết kế lại lâu dài cơ chế đồng thuận bằng chứng cổ phần của Ethereum, đáng chú ý nhất là tính hữu hạn của một khe duy nhất, Quỹ đạo, thay đổi sơ đồ chữ ký và tổng hợp chữ ký.