Bản nâng cấp tiếp theo sau hard fork Cancun của Ethereum sẽ là gì?

Mục tiêu của bài viết này là phác thảo quan điểm ^[4] của nhóm Paradigm Reth về hard fork Praha, cái tiếp theo sau hard fork Cancun The EL fork và tổng quan về kế hoạch “Phát triển cốt lõi EL” năm 2024 của chúng tôi. Các quan điểm bên dưới đang được phát triển và thể hiện quan điểm hiện tại của nhóm Reth và không nhất thiết đại diện cho nhóm Paradigm rộng hơn.

Nó phải bao gồm:

Mọi EIP liên quan đến cam kết, chẳng hạn như EIP-7002 , Nó cho phép đặt cược lại và nhóm đặt cược không cần sự tin cậy.

Các thay đổi EVM độc lập.

Chúng tôi sẵn sàng làm việc với bất kỳ nhóm nào muốn điều tra thêm về Bragg hoặc các hard fork EL khác trong tương lai và sẵn lòng hướng dẫn hoặc cung cấp hướng dẫn về cách sửa đổi vị trí của cơ sở mã Reth.

Hỗ trợ:

Chúng tôi tin rằng EIP sau phải được ưu tiên: 7002^[5 , 6110^[6], 2537^[7].

Chúng tôi hỗ trợ EOF như được mô tả trong thông số kỹ thuật ^[8] nhưng muốn sớm mở rộng phạm vi và tạo meta-EIP cam kết Tuân thủ phạm vi này.

Chúng tôi sẵn sàng tăng phiên bản EIP-4844 Maximum Blob Gas^[9]. Chúng tôi không có ý kiến ​​​​về con số chính xác nhưng chúng tôi mời những người làm dữ liệu hợp tác với chúng tôi để điều tra vấn đề này.

Chúng tôi muốn phát hành EIP-7547: một phiên bản chứa danh sách ^[10] để giúp lớp cơ sở có khả năng chống kiểm duyệt.

Không được hỗ trợ:

Chúng tôi không hỗ trợ Verkle Tries ở Praha^{[ 11} , nhưng chúng tôi hỗ trợ nhóm khách hàng nỗ lực hướng tới mục tiêu này bắt đầu từ quý 2 năm 2024, với việc phát hành vào giữa/cuối năm 2025 tại Osaka như đã hứa.

Chúng tôi không tin rằng nên tăng giới hạn lượng gas thực thi L1 hoặc quy mô hợp đồng nhưng chúng tôi mời những người làm dữ liệu làm việc với chúng tôi để điều tra tác động trên mạng. Chúng tôi sẵn sàng xem xét lại quan điểm của mình vì thử nghiệm trước đây đã chỉ ra rằng các nút Reth có thể xử lý tải tăng lên mà không gặp vấn đề gì.

Chúng tôi tin rằng EIP trừu tượng hóa ví/tài khoản cần thử nghiệm lẫn nhau nhiều hơn để hiểu rõ hơn về không gian đánh đổi. Chúng tôi sẵn sàng triển khai nhiều EIP liên quan đến AA trong tương lai nếu chúng không loại trừ lẫn nhau.

Nếu cộng đồng lo ngại về ^[12] tin đồn về cửa hậu NSA ^{[13] [14} Được rồi, chúng tôi có thể chấp nhận EIP-7212 (secp256r1).

Các chủ đề khác về lộ trình: Chúng tôi không có quan điểm cụ thể về CL EIP hoặc việc ghép các nhánh CL/EL, ngoại trừ EIP 7549^[15] và 7251^[16] có vẻ đầy hứa hẹn. Chúng tôi cũng hy vọng có thể đóng góp nhiều nhất có thể cho công việc của PeerDAS bên phía EL. Chúng tôi muốn tránh việc giới thiệu các gốc SSZ (EIP 6404, 6465, 6466) vào lúc này. Cuối cùng, chúng tôi ghi nhận cơ hội cung cấp giải pháp lưu trữ dữ liệu dài hạn cho các đốm màu, lịch sử và trạng thái đã hết hạn, như EIP-4844^[17] và EIP-4444^[18] Không nêu rõ điều này cũng như liệu Ethereum có sẵn sàng cung cấp giải pháp như vậy hay không.

Sau đây là lý do.

Hỗ trợ

Nói một cách trừu tượng, chúng tôi hỗ trợ 1) thu hẹp hơn nữa khoảng cách giữa CL và EL khoảng cách, 2) Các sửa đổi EVM có thể được thực hiện như một công việc của một người và có thể được kiểm tra riêng biệt và song song.

EIP-7002^[19]

EIP này đã vượt qua Việc kích hoạt hợp đồng thông minh ở phía EL để kiểm soát một hoặc nhiều trình xác thực ở phía CL sẽ mở khóa các nhóm đặt cược lại và đặt cược không đáng tin cậy. Theo quan điểm của chúng tôi, đây là một EIP dễ dàng vì ít nhất nó sẽ cho phép các nhóm đặt cược hiện tại loại bỏ một lớp tập trung khỏi các hợp đồng thông minh thực hiện việc rút tiền của họ.

Giới thiệu tính năng biên dịch trước có trạng thái trong quá trình triển khai EVM là một khái niệm trừu tượng mới mà chúng tôi cần nắm bắt trong quá trình triển khai EVM, nhưng ngoài điều đó ra, chúng tôi nghĩ rằng đó là một EIP có thể được thực hiện trực tiếp.

EIP-6110^[20]

EIP này là trong Tiền gửi được giới thiệu ở trạng thái EL, đơn giản hóa việc quản lý trạng thái cần có trên CL. Về mặt triển khai, điều này tương tự như theo dõi việc rút tiền CL, vì vậy về tổng thể, chúng tôi cho rằng đây cũng là một EIP dễ thực hiện và khép kín.

EIP-2537^[21]

Hiện đã có Nhiều cách triển khai BLS12-381, một đường cong thường được sử dụng trong nhiều SNARK, thuật toán chữ ký BLS và EIP-4844. Chúng tôi coi độ phức tạp của việc triển khai là thấp vì nó chỉ hiển thị thuật toán xác minh của đường cong thông qua giao diện được biên dịch trước. Có lẽ chúng tôi cũng muốn biên dịch trước các đường cong Hash thành BLS12-381.

EOF^[22] Định dạng đối tượng Ethereum

TL ; DR: Hỗ trợ phiên bản có phạm vi phù hợp mà Solidity và Vyper sẽ áp dụng. Việc điều chỉnh định dạng và xác minh mã giúp phân tích dễ dàng hơn là điều hiển nhiên và chúng tôi khuyên bạn nên cắt bớt thêm.

Lợi ích:

Chỉ có thể thực hiện các thay đổi EVM thông qua Ethereum/thử nghiệm để thử nghiệm và triển khai bởi một người.

Thực hiện các thay đổi EVM mà Vyper và Solidity mong muốn!

Giúp cải thiện hiệu suất và cải thiện kích thước giới hạn hợp đồng.

Loại bỏ nhu cầu phân tích mã byte trong thời gian chạy thông qua EVM, việc này có thể mất tới 50% thời gian khi không có bộ đệm, tùy thuộc vào hợp đồng kích thước tăng theo mức tăng.

Mã có thể được tải một phần, giúp thực hiện các hợp đồng lớn.

Devex: Sẽ cho phép sửa lỗi "Stack Too deep" bằng cách sử dụng dupN/swapN trong Solidity, cùng với các cải tiến công cụ khác.

Dựa vào tương lai: Các tính năng mới có thể được đưa vào L2 một cách an toàn và các công cụ sẽ biết tính năng nào tương thích.

Điểm yếu:

Đã thay đổi mục tiêu.

Không có người ủng hộ nào nỗ lực đưa nó vào.

Mã cũ vẫn cần được hỗ trợ

Cho đến khi được thông qua, mạng chính Ethereum và các EVM khác ở đó sẽ là sự phân kỳ tạm thời giữa các chuỗi.

Chúng tôi tin rằng các tính năng EOF sau sẽ được triển khai vào năm 2024. Chúng tôi khuyên bạn nên xác định phạm vi càng nhanh càng tốt và cam kết thực hiện nó. Bất cứ điều gì khác cần được xem xét để triển khai tiếp theo. Đề xuất của chúng tôi:

EIP-3540: EOF - Định dạng đối tượng EVM v1^[23]: Giới thiệu các bộ chứa mã và dữ liệu, đồng thời cung cấp Ethereum mã byte thêm cấu trúc và phiên bản.

EIP-3670: EOF - Xác minh mã ^[24]: Từ chối mọi hợp đồng không tuân theo định dạng EOF khi được triển khai. Buộc mã có cấu trúc chặt chẽ hơn và vô hiệu hóa các lệnh không hợp lệ và không xác định.

EIP-663: Hướng dẫn SWAP và DUP không giới hạn ^[25]: Điều này giải quyết vấn đề "Stack Too Deep" trong Solidity , phân tích cú pháp thông qua JUMPDEST vì giá trị tức thời có thể có tác dụng phụ. Ngôn ngữ EVM rất muốn có chức năng như vậy.

EIP-4200: EOF - Bước nhảy tương đối tĩnh^[26]: phân tích tĩnh tốt hơn, không có bước nhảy không chắc chắn . Tốt hơn là biên soạn. Các bước nhảy tương đối sẽ tốt hơn cho khả năng sử dụng lại mã.

EIP-4750: EOF - Chức năng ^[27]: Cần xử lý các lớp con có thể có thói quen nhảy động nhưng không có thói quen nhảy tĩnh. Nó cũng cho phép tải mã một phần, hoạt động tốt với Verkle và tăng giới hạn kích thước hợp đồng.

EIP-5450: EOF - Xác minh ngăn xếp^[28]: Xác minh các yêu cầu về mã và ngăn xếp. Kiểm tra tràn và tràn ngăn xếp trong thời gian chạy đã bị xóa đối với tất cả các hướng dẫn ngoại trừ CALLF (EIP-4750).

EIP-7480: EOF - Hướng dẫn truy cập phân đoạn dữ liệu ^[29]: Cho phép truy cập vào phân đoạn dữ liệu của bytecode.

EIP-7069: Hướng dẫn CALL được cải tiến ^[30]: Làm cho khả năng quan sát khí biến mất trong CALL, giúp việc này trở nên dễ dàng hơn trong tương lai Thực hiện khí định giá lại. Mặc dù độc lập với EOF nhưng chúng tôi nghĩ đây là cơ hội tốt để giới thiệu nó.

Chúng tôi ít chắc chắn hơn về EIP-6206: EOF - JUMPF và các hàm không trả về^[31]. Mặc dù nó cho phép tối ưu hóa lệnh gọi đuôi trong các hàm EOF, nhưng chúng ta vẫn cần xem phân tích ngôn ngữ để biết tính hữu ích của nó. Nếu chúng tôi không có điều này, chúng tôi nghĩ rằng nó có thể được đưa ra ngoài phạm vi và được đưa vào các bản cập nhật EOF tiếp theo.

Chúng tôi dự kiến ​​công việc trên sẽ kéo dài 1-2 tháng và được hoàn thành bởi một người toàn thời gian. Chúng tôi sẵn sàng giảm thêm phạm vi được đề cập ở trên nếu điều đó có nghĩa là duy trì đà tăng.

Lưu ý về mã byte truyền thống:

Mặc dù chúng tôi có thể cấm mã byte truyền thống/không phải EOF mới mã byte, nhưng mã byte kế thừa hiện có không thể được dùng nữa, nó hoạt động hiệu quả như EOF "v0". Mã byte truyền thống vẫn yêu cầu phân tích JUMPDEST sau EOF và vẫn cần xử lý mã đặc biệt để phân đoạn nó thành Verkle Tries.

Theo những gì chúng tôi biết, không có chuyển đổi có thể kiểm chứng nào từ mã byte không phải EOF sang EOF mà không yêu cầu quyền truy cập vào các tạo phẩm nguồn, nhưng chúng tôi sẵn sàng nghiên cứu các cách để tạo điều kiện thuận lợi cho cơ chế chuyển đổi này.

Ngoài ra, chúng tôi sẵn sàng khám phá các phương pháp hết hạn buộc di chuyển trạng thái sang EOF.

Tăng số lượng đốm màu EIP-4844

Chúng tôi sẵn sàng chấp nhận thay đổi này, sẽ MAX_BLOB_GAS_PER_BLOCK và TARGET_BLOB_GAS_PER_BLOCK được tăng lên, để biết ngữ cảnh, hãy xem EIP-4844^[32]:

Các giá trị cho TARGET_BLOB_GAS_PER_BLOCK và MAX_BLOB_GAS_PER_BLOCK đã được chọn để nhắm mục tiêu 3 đốm màu (0,375 MB) trên mỗi khối, với tối đa 6 đốm màu (0,75 MB). Các giới hạn ban đầu nhỏ hơn này nhằm mục đích giảm thiểu căng thẳng mà EIP này đặt lên mạng và dự kiến ​​sẽ tăng lên trong các bản nâng cấp trong tương lai để mạng có thể chứng minh độ tin cậy ở các khối lớn hơn. *

Trên thực tế, đây là một thay đổi nhỏ về mã và chúng tôi cần điều tra tác động thực sự của nó trong txpool, nhưng chúng tôi nghĩ mình có thể sử dụng lại cơ sở hạ tầng kiểm tra Stress cho EIP-4844. Lớp đồng thuận có thể gặp khó khăn trong việc truyền bá nhiều đốm màu hơn; chúng tôi đang lắng nghe nhóm CL.

Không được hỗ trợ

Verkle Thử^[33]

TL;DR: Chúng tôi thấy không có cách nào để triển khai các thử nghiệm của Verkle vào cuối năm 2024/đầu năm 2025. Chúng tôi khuyến nghị nhóm phân bổ nguồn lực vào quý 2 năm 2024 và cam kết triển khai hard fork Osaka vào quý 2-quý 3 năm 2025.

Lợi ích:

Đạt được nhờ bằng chứng lưu trữ nhỏ hơn Ánh sáng rẻ hơn khách hàng.

Cho phép thực thi không trạng thái bằng cách đưa trạng thái đọc trước vào tiêu đề khối, điều này cũng có thể dẫn đến cải thiện hiệu suất do truy cập trạng thái tĩnh.

Tăng giới hạn kích thước hợp đồng bằng cách chia nhỏ mã byte và cho phép tải mã một phần.

Do chi phí "hồi sinh" một trạng thái thấp hơn nên việc hết hạn trạng thái trở nên hấp dẫn hơn.

Điểm yếu:

Khối lượng công việc cao: tác động của những thay đổi, thực hiện và thử nghiệm công việc tích hợp.

Thay đổi về hóa đơn gas: Verkle Tries đưa kích thước nhân chứng vào chức năng tính toán gas. Chúng tôi lo ngại về những thay đổi về giá lưu trữ vẫn chưa được khám phá (ví dụ: chi phí đối với những người tiêu dùng gas hàng đầu sau Verkle) sẽ là bao nhiêu?

Tích hợp ứng dụng: Ứng dụng có trình xác thực Merkle Patricia Trie nên làm gì khi quá trình chuyển đổi Lớp phủ đang chạy? eth_getProof nên hoạt động như thế nào?

Mặc dù chúng tôi hiểu lợi ích của Verkle Tries nhưng chúng tôi tin rằng cần phải suy nghĩ nhiều hơn để hiểu các công cụ/hợp đồng của bên thứ ba cần phải thích ứng như thế nào và các ví dụ chuyển tiếp như Tác động của giải pháp 2 tầng. Ban đầu, chúng tôi nghi ngờ về chính sách di chuyển vì nó quy định rằng bộ ba Verkle phải được cập nhật khi trạng thái được đọc từ MPT hiện có, nhưng hiện tại điều này dường như không còn đúng nữa. Do đó, chúng tôi ủng hộ cách tiếp cận cây lớp phủ như một lộ trình di chuyển khả thi.

Tài liệu về chiến lược di chuyển của Verkle nhìn chung có vẻ đã lỗi thời, vì hầu hết các tài nguyên vẫn nêu rõ rằng bộ ba Verkle cần được cập nhật khi trạng thái được đọc từ MPT, mặc dù Đây không phải là trường hợp. Chúng tôi muốn thấy các tài liệu chuyển đổi quan trọng được cập nhật theo các phương pháp mới nhất, chẳng hạn như tài liệu tuyệt vời này ^[34] . Chúng tôi cũng muốn xem bản dự thảo EIP về chiến lược chuyển đổi.

Do đó, chúng tôi vẫn ủng hộ việc ra mắt Verkle vào năm 2025, nhưng không thấy lộ trình triển khai cho bản nâng cấp Praha.

Giới hạn khí L1

Chúng tôi tin rằng từ góc độ kích thích nhu cầu, sẽ tăng L1 giới hạn gas là Nó sẽ không có tác dụng nhiều trong thực tế. Chúng tôi cũng tin rằng hầu hết khách hàng có thể xử lý mức tăng tải trung bình, nhưng chúng tôi vẫn muốn cảnh giác với các tình huống xấu nhất, vì vậy chúng tôi không khuyến nghị tăng giới hạn gas L1 vào lúc này. Chúng tôi tin rằng việc tăng giới hạn khí blob là một giải pháp hứa hẹn hơn trong ngắn hạn.

Chúng tôi mời mọi người cộng tác với chúng tôi trong bất kỳ nghiên cứu nào theo hướng này và xung quanh việc đột phá trong việc đo lường tài nguyên trong EVM. Bài viết Broken Meter^[35] là điểm khởi đầu tốt cho hướng nghiên cứu này.

Tóm tắt tài khoản

Chúng tôi sẵn sàng bao gồm 1 hoặc nhiều EIP (hoặc giao thức) này triển khai ERC), nhưng lý tưởng nhất là chúng tôi muốn thấy nhiều so sánh trải nghiệm người dùng và trải nghiệm phát triển hơn để hiểu rõ hơn về không gian cân bằng và nỗ lực tích hợp công cụ của các đề xuất riêng lẻ. Chúng tôi đang tuân theo các EIP/ERC sau, nhưng vui lòng đề xuất thêm cho chúng tôi:

EIP-3074: mã hoạt động AUTH và AUTHCALL^[36]

ERC-4337: Trừu tượng hóa tài khoản bằng Alt Mempool^[37]

EIP-5806: Giao dịch ủy quyền^[38]

EIP-5920: Mã hoạt động THANH TOÁN^{[ 39]}

EIP-6913: Hướng dẫn SETCODE^[40]

EIP-7377: Giao dịch di chuyển^[41]

RIP-7560: Trừu tượng hóa tài khoản gốc - EIP cốt lõi - Hiệp hội các nhà ảo thuật Ethereum^[42]

Chúng tôi muốn làm rõ rằng trong nội dung trên, "tài khoản trừu tượng" có nghĩa là "trừu tượng chức năng xác minh, mục tiêu chính là cho phép xoay khóa, biến đa chữ ký thành tính năng hạng nhất và cung cấp cho chúng tôi đường dẫn tự động đến kháng lượng tử" (h/t VB), chỉ áp dụng cho 4337 và 7560, trong khi các đề xuất khác là được chia thành hai loại, tức là tài trợ khí và xử lý hàng loạt hoạt động.

Tác giả:

Georgios Konstantopoulos^[43]

Georgios Konstantopoulos là Giám đốc Công nghệ và Đối tác Nghiên cứu của Paradigm, tập trung vào các công ty trong danh mục đầu tư của Paradigm và các giao thức nguồn mở. Trước đây, Georgios làm việc với tư cách là nhà tư vấn và nghiên cứu độc lập.