CTO mô hình: Diễn giải Prague Hard Fork sau khi nâng cấp Ethereum Cancun

Từ: Georgios Konstantopoulos, CTO, Paradigm

Trình biên soạn: Luffy, Foresight News

Mục đích của bài viết này là cung cấp cái nhìn tổng quan về quan điểm của nhóm Paradigm Reth về những EIP nào nên được đưa vào Prague Hard Fork (bản nâng cấp lớn tiếp theo cho Ethereum đồng thuận sau Cancun Hard Fork) và kế hoạch tổng thể của chúng tôi cho “EL Core Dev” vào năm 2024. Các quan điểm sau đây không ngừng phát triển và đại diện cho quan điểm hiện tại của nhóm Reth và không nhất thiết phải đại diện cho toàn bộ nhóm Paradigm.

Chúng tôi nghĩ rằng Prague Hard Fork có khả năng thành hiện thực trên EthereumTestnet vào quý 3 năm 2024 và trên Mainnet vào cuối năm nay. Nó nên bao gồm:

• EIP liên quan đến staking, chẳng hạn như EIP-7002 hỗ trợ re-staking và staking pool không tin cậy.
• Các biến thể EVM riêng biệt.
• Chúng tôi sẵn sàng làm việc với bất kỳ nhóm nào muốn tìm hiểu sâu hơn về Prague hoặc EL Hard Fork khác trong tương lai và sẵn lòng cung cấp hướng dẫn và hỗ trợ nơi sửa đổi cơ sở mã Reth.

Phải làm gì:

• Chúng tôi tin rằng các EIP sau đây phải được ưu tiên: 7002, 6110, 2537.
• Chúng tôi hỗ trợ EOF được mô tả trong đặc tả và hy vọng sẽ hoàn thiện phạm vi và tạo meta EIP càng sớm càng tốt.
• Chúng tôi sẵn sàng thêm EIP-4844 Max Blob Gas. Chúng tôi không có ý kiến về những con số cụ thể, nhưng chúng tôi mời những người làm việc với chúng tôi về chủ đề này.
• Chúng tôi rất vui mừng được phát hành một phiên bản của EIP-7547: nó chứa một danh sách để giúp lớp cơ sở chống lại kiểm duyệt.

Những việc không nên làm:

• Chúng tôi không hỗ trợ việc đưa Verkle Tries vào Prague Hard Fork, nhưng hỗ trợ nhóm khách hàng bắt đầu làm việc này vào quý 2 năm 2024 với cam kết phát hành trong bản nâng cấp Osaka vào năm 2025.
• Chúng tôi không nghĩ rằng chúng tôi nên tăng giới hạn khí thực hiện L1 hoặc quy mô hợp đồng, nhưng chúng tôi mời những người dữ liệu làm việc với chúng tôi để điều tra tác động của nó đối với mạng. Chúng tôi sẵn sàng thay đổi nhận thức của mình vì các thử nghiệm trước đây đã chỉ ra rằng Reth Node có thể xử lý tải tăng lên mà không gặp bất kỳ vấn đề gì.
• Chúng tôi tin rằng các EIP trừu tượng hóa ví / tài khoản cần được kiểm tra đối đầu hơn với nhau để hiểu rõ hơn về không gian đánh đổi. Nếu chúng không loại trừ lẫn nhau, thì chúng tôi sẽ sẵn sàng triển khai nhiều EIP liên quan đến AA trong tương lai.
• Nếu cộng đồng đồng ý với backdoor được đồn đại của NSA, chúng ta có thể vượt qua ranh giới trên EIP-7212 (secp256r1).
• Các chủ đề lộ trình khác: Chúng tôi không có hiểu biết thực tế về sự kết hợp của các nhánh CL EIP hoặc CL / EL, nhưng EIP 7549 và 7251 có vẻ đầy hứa hẹn. Chúng tôi cũng muốn đóng góp vào công việc của PeerDAS từ phía EL càng nhiều càng tốt. Hiện tại, chúng tôi muốn tránh giới thiệu gốc SSZ (EIP 6404, 6465, 6466). Cuối cùng, chúng tôi thấy cơ hội cung cấp giải pháp lưu trữ dữ liệu dài hạn cho các blob, lịch sử và trạng thái đã hết hạn, vì cả EIP-4844 và EIP-4444 đều làm rõ điều này và vẫn còn phải xác định liệu Ethereum có sẵn sàng cung cấp giải pháp như vậy hay không.

Mở rộng chi tiết về nó bên dưới.

Những việc cần làm

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

EIP-7002

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

Giới thiệu biên dịch trước trạng thái cho EVM là một sự trừu tượng mới mà chúng tôi cần có trong việc triển khai EVM của mình, nhưng ngoài ra, chúng tôi nghĩ rằng đó là một EIP đơn giản.

EIP-6110

KCN sinh thái giới thiệu tiền gửi ở trạng thái EL, đơn giản hóa việc quản lý nhà nước cần thực hiện 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 nhìn chung, chúng tôi nghĩ rằng đây cũng là một EIP đơn giản và độc lập.

EIP-2537

Hiện tại có nhiều triển khai BLS12-381, đây là 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 nó có độ phức tạp triển khai thấp vì nó chỉ hiển thị thuật toán xác thực của đường cong thông qua giao diện được biên dịch sẵn. Chúng ta cũng có thể cần hàm băm của đường cong BLS12-381 được biên dịch sẵn.

EOF

*Lưu ý của người dịch: EOF là viết tắt của Định dạng đối tượng EVM, dịch sang định dạng đối tượng Ethereum và chứa một loạt các EIP hứa hẹn sẽ giúp thực thi Ethereum hiệu quả hơn, nhất quán và có thể nâng cấp hơn. Các kế hoạch ban đầu đã được thực hiện trong Nâng cấp Thượng Hải, sau đó đã bị loại bỏ. *

EOF sẽ hỗ trợ cả Solidity và Vyper. Không có nghi ngờ rằng định dạng mã và tinh chỉnh xác minh sẽ làm cho phân tích bytecode đơn giản hơn nhiều và chúng tôi khuyên bạn nên xem xét cẩn thận bất cứ điều gì khác. Chúng tôi đã đề xuất một vài EIP bên dưới, nhưng chúng tôi sẵn sàng điều chỉnh thêm.

Về mặt tích cực:

• Những thay đổi chỉ dành cho EVM có thể được kiểm tra bằng Ethereum / Testnet và được thực hiện bởi một người duy nhất.
• EVM thay đổi mà Vyper và Solidity muốn
• Giúp cải thiện hiệu suất và tăng giới hạn kích thước hợp đồng.
• Loại bỏ sự cần thiết phải phân tích bytecode trong thời gian chạy cho EVM. Không có bộ nhớ đệm liên quan, thời gian phân tích có thể cao tới 50% và tăng lên khi quy mô hợp đồng tăng lên.
• Cho phép tải mã một phần để giúp thực hiện các Hợp đồng thông minh lớn.
• Devex: Sẽ cho phép vấn đề “ngăn xếp quá sâu” được khắc phục thông qua dupN / swapN và các cải tiến công cụ khác.
• Bằng chứng trong tương lai: Các tính năng mới có thể được giới thiệu một cách an toàn trên L2 và công cụ sẽ biết những gì tương thích.

Các khía cạnh xấu:

• Phạm vi và mục tiêu động.
• Không có sự thúc đẩy mạnh mẽ của những người đề xuất để đưa nó vào.
• Hỗ trợ cho mã kế thừa vẫn được yêu cầu
• Trước khi áp dụng, đã có một sự bất đồng tạm thời giữa EthereumMainnet và các chuỗi EVM khác.

Chúng tôi tin rằng các tính năng EOF sau đây 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 và cam kết thực hiện càng sớm càng tốt. Bất cứ điều gì khác nên được xem xét cho các triển khai tiếp theo. Khuyến nghị của chúng tôi là:

EIP-3540 (EOF - EVM Object Format v1): Giới thiệu mã và vùng chứa dữ liệu, đồng thời thêm cấu trúc và phiên bản vào mã byte Ethereum. EIP-3670 (EOF - Xác thực mã): Từ chối bất kỳ hợp đồng nào không tuân theo định dạng EOF khi triển khai. Thực thi mã có cấu trúc hơn và vô hiệu hóa các chỉ thị không hợp lệ và không xác định. EIP-663 (Hướng dẫn SWAP &; DUP vô hạn): Điều này giải quyết vấn đề “ngăn xếp quá sâu” về độ rắn và có tác dụng phụ như một giá trị tức thì thông qua phân tích JUMPDEST. Một tính năng rất mong muốn của ngôn ngữ EVM. EIP-4200 (EOF - Static Relative Jumps): Phân tích tĩnh tốt hơn mà không có bước nhảy không chắc chắn. Biên dịch AOT tốt hơn. Bước nhảy có lợi hơn cho việc tái sử dụng mã.

• EIP-4750 (EOF - Chức năng): Yêu cầu độ phân giải của các chương trình con có thể sử dụng các bước nhảy động nhưng không phải nhảy tĩnh. Nó cũng cho phép tải một phần mã, hoạt động hoàn hảo với Verkle để tăng giới hạn kích thước hợp đồng.
• EIP-5450 (EOF - Stack Validation): Xác minh các yêu cầu về mã và ngăn xếp. Loại bỏ kiểm tra tràn và tràn ngăn xếp thời gian chạy cho 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 dữ liệu): Cho phép truy cập vào phần dữ liệu của bytecode.
• EIP-7069 (Chỉ thị CALL cải tiến): Khả năng loại bỏ khả năng quan sát khí khỏi CALL, giúp định giá lại gas dễ dàng hơn trong tương lai. Mặc dù độc lập với EOF, chúng tôi thấy đây là một cơ hội tốt để giới thiệu nó.

Chúng tôi không chắc chắn lắm về EIP-6206 (EOF - JUMPF và chức năng không trả về). Mặc dù nó cho phép tối ưu hóa cuộc gọi đuôi trong các chức năng EOF, chúng ta vẫn cần xem hồ sơ ngôn ngữ làm gì cho nó. Nếu không, chúng tôi nghĩ rằng chúng tôi có thể xóa nó khỏi phạm vi và đưa nó vào bản cập nhật EOF tiếp theo.

Chúng tôi ước tính khối lượng công việc trên là 1 người làm việc toàn thời gian từ 1-2 tháng. Chúng tôi sẵn sàng thu hẹp nó hơn nữa.

Một lưu ý về bytecode kế thừa:

• Mặc dù chúng tôi có thể cấm bytecode kế thừa / không phải EOF mới, chúng tôi không thể phản đối bytecode kế thừa hiện có, hoạt động hiệu quả như EOF “v0”. Legacy bytecode vẫn yêu cầu phân tích JUMPDEST sau EOF và vẫn yêu cầu xử lý mã đặc biệt để phân mảnh nó thành các đoạn trong Verkle Trys.
• Theo hiểu biết tốt nhất của chúng tôi, không thể xác minh chuyển đổi từ mã byte không phải EOF sang EOF mà không có quyền truy cập vào Mã nguồn, nhưng chúng tôi sẵn sàng xem xét các cơ chế để tạo điều kiện thuận lợi cho việc chuyển đổi này.
• Ngoài ra, chúng tôi sẵn sàng khám phá các cách để buộc di cư của tiểu bang sang EOF.

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

Chúng tôi sẵn sàng chấp nhận thay đổi này, tương ứng với sự gia tăng MAX_BLOB_GAS_PER_BLOCK và TARGET_BLOB_GAS_PER_BLOCK. EIP-4844 đọc:

Chọn các giá trị của TARGET_BLOB_GAS_PER_BLOCK và MAX_BLOB_GAS_PER_BLOCK để tương ứng với mục tiêu 3 blob (0,375 MB) trên mỗi khối (tối đa 6 blob). Các giới hạn ban đầu nhỏ này được thiết kế để giảm thiểu sự căng thẳng trên mạng do EIP gây ra và số lượng blob dự kiến sẽ tăng lên trong các lần nâng cấp trong tương lai khi mạng thể hiện độ tin cậy ở các khối lớn hơn.

Trên thực tế, đây là một thay đổi mã nhỏ và chúng tôi cần điều tra tác động thực tế của nó trong nhóm giao dịch, nhưng chúng tôi nghĩ rằng chúng tôi có thể sử dụng lại cơ sở hạ tầng kiểm tra căng thẳng EIP-4844 cho việc này. CL có thể khó lan truyền nhiều đốm màu hơn và chúng tôi tôn trọng ý kiến của nhóm CL.

Đừng làm

** Verkle thử**

Tl; TL; DR: Chúng tôi không thấy nỗ lực triển khai 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 cho việc này vào quý 2 năm 2024 và cam kết triển khai tại Osaka Hard Fork vào quý 2-quý 3 năm 2025.

Về mặt tích cực:

• Cho phép khách hàng ánh sáng rẻ hơn với bằng chứng lưu trữ nhỏ hơn.
• Thực thi không trạng thái bằng cách bao gồm trạng thái đọc trong tiêu đề khối, điều này cũng có thể dẫn đến tăng 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ỏ bytecode và cho phép tải mã một phần.
• Hết hạn trạng thái đã trở nên dễ chấp nhận hơn do chi phí trạng thái “khôi phục” thấp hơn.

Khó khăn:

• Tác động của những thay đổi và nỗ lực thực hiện và thử nghiệm.
• Thay đổi tính toán khí: Verkle Tries giới thiệu kích thước của nhân chứng vào tính năng tính toán khí. Chúng tôi lo ngại rằng những thay đổi về giá lưu trữ vẫn chưa được khám phá (ví dụ: chi phí của những người tiêu dùng khí đốt hàng đầu sau Verkle 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ủ chạy? ETH \ _getProof nên hành xử như thế nào?

Mặc dù chúng tôi hiểu lợi ích của Verkle Try, chúng tôi nghĩ rằng cần phải xem xét thêm về cách các công cụ / hợp đồng của bên thứ ba cần phù hợp và điều này sẽ có tác động gì đến Lớp 2 và những thứ tương tự trong giai đoạn chuyển tiếp. Ban đầu chúng tôi nghi ngờ về chiến lược di chuyển vì nó tuyên bố rằng Verkle trie nên được cập nhật khi tiểu bang được đọc từ MPT đã có từ trước, nhưng điều đó dường như không còn đúng nữa. Do đó, chúng tôi ủng hộ cách tiếp cận lớp phủ như một con đường di chuyển khả thi.

Tài liệu cho chiến lược di chuyển Verkle dường như đã lỗi thời, vì hầu hết các tài nguyên vẫn nói rằng bản thử Verkle nên được cập nhật khi đọc trạng thái từ MPT. Chúng tôi muốn xem tài liệu chuyển đổi với các phương pháp tiếp cận mới nhất, chẳng hạn như phương pháp tuyệt vời này. Chúng tôi cũng muốn thấy một dự thảo KCN sinh thái về chiến lược chuyển đổi.

Do đó, chúng tôi vẫn hỗ trợ triển khai vào năm 2025 thay vì triển khai trong Praha Hard Fork.

Giới hạn khí L1

Chúng tôi không nghĩ rằng việc tăng giới hạn khí L1 sẽ tạo ra nhiều khác biệt 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 muốn cảnh giác về tình huống xấu nhất, vì vậy chúng tôi không khuyên bạn nên tăng giới hạn khí L1 tại thời điểm này. Chúng tôi tin rằng việc tăng giới hạn khí đốm màu là một giải pháp hứa hẹn hơn trong ngắn hạn.

Chúng tôi mời những người khác làm việc với chúng tôi về nghiên cứu theo hướng này, thường là xung quanh việc phá vỡ việc đo lường tài nguyên trong EVM. Luận án Broken Meter là một điểm khởi đầu tốt cho nghiên cứu trong lĩnh vực này.

Trừu tượng hóa tài khoản

Chúng tôi muốn bao gồm 1 hoặc nhiều EIP, nhưng chúng tôi muốn xem so sánh thêm về trải nghiệm người dùng và trải nghiệm của nhà phát triển giữa mỗi đề xuất để hiểu rõ hơn về sự đánh đổi và nỗ lực tích hợp công cụ. Chúng tôi đang xem xét các EIP/ERC sau đây, nhưng vui lòng tư vấn cho chúng tôi:

• EIP-3074: Mã hoạt động AUTH và AUTHCALL
• ERC-4337: Sử dụng Alt Mempool để trừu tượng hóa tài khoản
• EIP-5806: Giao dịch ủy quyền
• EIP-5920: Mã hoạt động PAY
• EIP-6913: Chỉ thị SETCODE
• EIP-7377: Giao dịch di chuyển
• RIP-7560: Trừu tượng hóa tài khoản gốc - Core EIP - Học bổng của các ảo thuật gia Ethereum

Điều chúng ta cần lưu ý ở trên là “trừu tượng hóa tài khoản” giống như “chức năng xác minh trừu tượng, mục tiêu chính là thực hiện xoay khóa bí mật, tạo khóa đa chữ ký và cung cấp cho chúng ta một con đường để tự động đạt được điện trở lượng tử”.