1. Tổng quan về nội dung
Bài viết này sẽ phân tích sự hiểu biết của nhóm Paradigm Reth về EIP (Giao thức cải tiến mạng Ethereum) quan trọng có trong hard fork Praha (Prague) (hard fork lớp thực thi tiếp theo sau khi nâng cấp Cancun) và sự hiểu biết của họ về 2024 “EL Core Dev “Xem kế hoạch.
Hard fork Praha có thể diễn ra trên mạng thử nghiệm Ethereum vào quý 3 năm 2024 và được triển khai trên mạng chính trước cuối năm nay. Nội dung nâng cấp của nó bao gồm :
1. Nên bao gồm các EIP liên quan đến đặt cược, chẳng hạn như EIP-7002, để kích hoạt các nhóm đặt cược lại và đặt cược không yêu cầu sự tin cậy từ bên ngoài;
2. Thay đổi EVM độc lập;
Ngoài ra, Paradigm sẵn sàng làm việc với bất kỳ nhóm nào muốn điều tra sâu hơn các vấn đề khó khăn trong hard fork EL như Praha và sẵn lòng cung cấp hướng dẫn bao gồm sửa đổi cơ sở mã Reth.
Các hướng được Paradigm công nhận:
1. Paradigm tin rằng các EIP sau nên được ưu tiên: 7002, 6110, 2537.
2. Paradigm hỗ trợ Định dạng đối tượng Ethereum (EOF) được mô tả trong thông số kỹ thuật, nhưng hy vọng xác định phạm vi càng sớm càng tốt và tạo một meta-EIP dành riêng cho phạm vi này.
3. Paradigm sẵn sàng bổ sung EIP-4844 Max Blob Gas, sẽ không bình luận quá nhiều về con số chính xác nhưng sẽ mời các nhà khoa học dữ liệu hợp tác điều tra EIP.
4. Mô hình sẵn sàng phát hành phiên bản EIP-7547: Inclusion Lists, phiên bản này có thể giúp chống lại sự kiểm duyệt của lớp cơ sở.
Các hướng mà Paradigm không đồng ý:
1. Paradigm không hỗ trợ cấu trúc dữ liệu Verkle Tries được sử dụng trong hard fork Praha, 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à hứa hẹn sẽ nâng cấp và phát hành nó ở Osaka vào giữa/cuối năm 2025.
2. Paradigm tin rằng không nên tăng giới hạn gas thực thi L1 hoặc quy mô hợp đồng, nhưng sẽ mời nhân viên dữ liệu hợp tác điều tra tác động của phương pháp này trên mạng Ethereum. Đồng thời, Paradigm sẵn sàng giảm bớt quan điểm của mình vì thử nghiệm trước đây cho thấy các nút Reth có thể xử lý tải tăng lên mà không gặp vấn đề gì.
3. Paradigm tin rằng EIP trừu tượng hóa ví/tài khoản cần phải được kiểm tra lẫn nhau để hiểu rõ hơn về sự đánh đổi trong không gian mạng. Nếu việc trừu tượng hóa ví/tài khoản không loại trừ lẫn nhau thì sẽ sẵn sàng triển khai nhiều EIP liên quan đến việc trừu tượng hóa tài khoản trong tương lai.
4. Nếu cộng đồng đồng ý với tin đồn về cửa hậu của NSA, Paradigm tin rằng ranh giới của EIP-7212 (secp 256 r 1) có thể bị vượt qua.
5. Các chủ đề lộ trình khác: Mô hình không có hiểu biết thực tế về sự ghép nối ngã ba của lớp đồng thuận EIP hoặc CL/EL (lớp đồng thuận/lớp thực thi), nhưng hai đề xuất EIP 7549 và EIP 7251 có vẻ đầy hứa hẹn. Paradigm cũng muốn đóng góp nhiều nhất có thể cho nỗ lực PeerDAS từ phía EL và hiện muốn tránh đưa ra các gốc SSZ (EIP 6404, 6465, 6466). Cuối cùng, Paradigm tin rằng cần có một 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, vì cả EIP-4844 và EIP-4444 đều không chỉ định điều này, nhưng liệu Ethereum có sẵn sàng cung cấp giải pháp như vậy hay không vẫn chưa được xác định .
Đây là những thông tin chi tiết:
Hướng mô hình nhận dạng
Nói một cách trừu tượng, Paradigm chủ yếu hỗ trợ hai khía cạnh sau:
1) Thu hẹp hơn nữa khoảng cách giữa lớp đồng thuận và lớp thực thi;
2) Các sửa đổi EVM có thể được thực hiện dưới dạng công việc của một người và được kiểm tra độc lập hoặc 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 đáng tin cậy bằng cách cho phép các hợp đồng thông minh ở phía lớp thực thi kiểm soát một hoặc nhiều trình xác thực ở phía lớp đồng thuận. Từ quan điểm của Paradigm, EIP này có ý nghĩa nào đó và ít nhất 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 cho phép rút tiền.
Ngoài ra, việc đưa tính năng biên dịch trước có trạng thái vào EVM cũng là một tính năng mà Paradigm đồng ý cần phải đáp ứng khi triển khai EVM, nhưng ngoài ra, Paradigm tin rằng đây là một EIP có thể được triển khai trực tiếp.
EIP-6110
EIP này giới thiệu chức năng ký gửi ở trạng thái lớp thực thi, đơn giản hóa việc quản lý trạng thái cần được thực hiện trên lớp đồng thuận. Về mặt triển khai, điều này tương tự như theo dõi việc rút tiền của lớp đồng thuận, vì vậy về tổng thể, Paradigm cảm thấy đây cũng là một EIP độc lập và dễ thực hiện.
EIP-2537
Hiện tại, BLS 12-381 có nhiều cách triển khai và là đường cong được sử dụng phổ biến trong nhiều SNARK, thuật toán chữ ký BLS và EIP-4844. Paradigm tin rằng độ phức tạp triển khai BLS 12-381 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, do đó cũng có thể cần phải có hàm băm được biên dịch trước của đường cong BLS 12-381.
Định dạng đối tượng Ethereum (EOF)
Nói một cách đơn giản, EOF sẽ hỗ trợ cả Solidity và Vyper. Với phạm vi phát hành rộng hơn, định dạng mã và các chỉnh sửa xác minh để giúp phân tích dễ dàng hơn cũng là hợp lý. Paradigm khuyên bạn nên xem xét cẩn thận mọi điều ngoài điều này và đề xuất điều đó bên dưới. Một số EIP cũng sẵn sàng thực hiện những điều chỉnh tiếp theo.
Khía cạnh tốt:
● 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.
● Những thay đổi EVM mà Vyper và Solidity mong muốn.
● Giúp cải thiện hiệu suất và tăng giới hạn quy mô hợp đồng.
● Loại bỏ nhu cầu EVM thực hiện phân tích mã byte trong thời gian chạy, việc này có thể mất tới 50% thời gian mà không cần lưu vào bộ nhớ đệm và tăng lên khi kích thước hợp đồng tăng lên.
● Cho phép tải mã một phần, Chiết Giang giúp thực hiện các hợp đồng thông minh lớn.
● Devex: Sẽ cho phép khắc phục các sự cố “xếp chồng quá sâu” với dupN/swapN và các cải tiến công cụ khác.
● Các tính năng có thể áp dụng trong tương lai: Các tính năng cross-L2 an toàn mới có thể được giới thiệu và công cụ sẽ biết tính năng nào tương thích.
Mặt xấu:
● Tầm bắn và mục tiêu di chuyển.
● Không có sự hỗ trợ nào cho nỗ lực lớn để đưa nó vào.
● Mã kế thừa vẫn cần được hỗ trợ.
● Trước khi áp dụng, đã có sự khác biệt tạm thời giữa mạng chính Ethereum và các chuỗi EVM khác.
Paradigm tin rằng các khả năng EOF sau đây sẽ được triển khai vào năm 2024 và khuyến nghị xác định phạm vi cũng như cam kết thực hiện càng sớm càng tốt. Các vấn đề bổ sung cần được xem xét cho các lần triển khai tiếp theo. Vì vậy, Paradigm khuyến nghị:
● EIP-3540 (EOF – Định dạng đối tượng EVM 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 cho mã byte Ethereum.
● EIP-3670 (EOF – Xác minh mã) : Bất kỳ hợp đồng nào không tuân theo định dạng EOF khi triển khai đều bị từ chối, chỉ mã có cấu trúc hơn mới có thể được thực thi và các hướng dẫn không hợp lệ và không xác định sẽ bị vô hiệu hóa.
● EIP-663 (Hướng dẫn SWAP và DUP không giới hạn) : EIP này giải quyết vấn đề “xếp quá sâu” trong Solidity trong đó việc sử dụng phân tích JUMPDEST làm giá trị tức thời có thể có tác dụng phụ nhưng là một tính năng rất được mong muốn để EVM trở thành một ngôn ngữ.
● EIP-4200 (EOF – Bước nhảy tương đối tĩnh) : Phân tích tĩnh tốt hơn, không có bước nhảy không xác định. Việc biên dịch aot tốt hơn và các bước nhảy tương đối có lợi hơn cho khả năng sử dụng lại mã.
● EIP-4750 (EOF – Chức năng) : Cần giải các chương trình con có thể sử dụng bước nhảy động nhưng không thể nhảy tĩnh, đồng thời cũng cho phép tải mã một phần, có thể hoạt động tốt với cấu trúc dữ liệu 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) : 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 mã byte.
● EIP-7069 (Lệnh CALL được cải tiến) loại bỏ khả năng quan sát Gas khỏi CALL, giúp việc định giá lại Gas trong tương lai trở nên dễ dàng hơn. Mặc dù EIP này độc lập với EOF nhưng Paradigm tin rằng đợt hard fork này là cơ hội tốt để giới thiệu EIP này.
Paradigm ít chắc chắn hơn về EIP-6206 (EOF-JUMPF và các hàm không quay trở lại) , trong khi EIP này cho phép tối ưu hóa lệnh gọi tail trong các hàm EOF, Paradigm vẫn cần xem phân tích ngôn ngữ để biết tính hữu dụng của nó. Nếu không, Paradigm cho rằng việc loại bỏ nó khỏi phạm vi và đưa nó vào các bản cập nhật EOF tiếp theo là phù hợp.
Mô hình ước tính khối lượng công việc trên là khoảng 1-2 tháng người trên cơ sở toàn thời gian và sẵn sàng thu hẹp phạm vi trên hơn nữa nếu khối lượng công việc được đánh giá lớn hơn.
Một lưu ý về mã byte kế thừa:
● Mặc dù mã byte kế thừa/không phải EOF mới có thể bị chặn, nhưng mã byte kế thừa hiện tại không thể bị ngừng sử dụng vì nó hoạt động hiệu quả như EOF “v 0”. Mã byte kế thừa vẫn yêu cầu phân tích JUMPDEST sau EOF và vẫn cần phải xử lý mã đặc biệt để phân đoạn mã thành các đoạn trong Verkle Tries.
● Theo hiểu biết tốt nhất của Paradigm, không thể xác minh việc 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 Paradigm sẵn sàng điều tra 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, Paradigm 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
Mô hình mở cho sự thay đổi này và theo đó, sẽ thêm “MAX_BLOB_GAS_PER_BLOCK và TARGET_BLOB_GAS_PER_BLOCK”
Chọn các giá trị cho TARGET_BLOB_GAS_PER_BLOCK và MAX_BLOB_GAS_PER_BLOCK để tương ứng với mục tiêu 3 đốm màu (0,375 MB) trên mỗi khối (tối đa 6 đốm màu, khoảng 0,75 MB). Các giới hạn ban đầu này không lớn nhưng sẽ giảm thiểu căng thẳng mà EIP này gây ra cho mạng và có thể tăng lên trong các lần nâng cấp tiếp theo khi mạng thể hiện độ tin cậy với các khối lớn hơn.
Trong thực tế, những thay đổi mã liên quan sẽ không quá lớn, nhưng Paradigm cần điều tra tác động thực tế của những thay đổi cao hơn này trong txpool để cơ sở hạ tầng kiểm tra sức chịu đựng EIP-4844 có thể được sử dụng lại. 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, vì vậy Paradigm cũng tôn trọng ý kiến của nhóm lớp đồng thuận.
Mô hình không đồng ý với hướng đi
Verkle thử
Nói một cách đơn giản, việc hoàn thành triển khai Verkle vào cuối năm 2024/đầu năm 2025 dường như khó xảy ra, với việc Paradigm 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 thực hiện hard fork Osaka vào quý 2-quý 3 năm 2025 Triển khai.
Khía cạnh tốt:
● Máy khách nhẹ có chi phí thấp hơn thông qua bằng chứng lưu trữ nhỏ hơn.
● Thực thi không trạng thái bằng cách đưa trạng thái trước đọ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ột phần mã.
● Việc hết hạn trạng thái trở nên dễ chấp nhận hơn do chi phí cho trạng thái “khôi phục” thấp hơn.
Mặt xấu:
● Tác động của những thay đổi và nỗ lực tích hợp được triển khai và thử nghiệm.
● Thay đổi về kế toán khí đốt: Verkle Tries đưa quy mô nhân chứng vào chức năng tính toán khí đốt và Paradigm 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 một người tiêu dùng khí đốt 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ủ đang chạy? eth_getProof nên hoạt động như thế nào?
Mặc dù Verkle Tries có những lợi thế nhất định, nhưng Paradigm tin rằng cần phải cân nhắc nhiều hơn về cách các công cụ/hợp đồng của bên thứ ba cần thích ứng và tác động của quá trình chuyển đổi đối với các giải pháp cấp hai, v.v. Ban đầu, Paradigm tỏ ra thận trọng với chính sách di chuyển vì nó quy định rằng Verkle Tries phải được cập nhật khi trạng thái được đọc từ MPT có sẵn, nhưng điều này dường như không còn đúng nữa. Do đó, Paradigm hỗ trợ các phương thức lớp phủ như một đường dẫn di chuyển khả thi.
Tài liệu về chiến lược di chuyển của Verkle thường 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 đọc trạng thái từ MPT, mặc dù thực tế không phải vậy. Paradigm muốn xem các tài liệu chuyển đổi quan trọng được cập nhật theo phương pháp mới nhất và có thể tham khảo tài liệu này . Mô hình cũng muốn xem dự thảo kế hoạch đầu tư sinh thái về chiến lược chuyển đổi.
Do đó, Paradigm vẫn hỗ trợ ra mắt vào năm 2025 và không được triển khai trong đợt hard fork này.
Giới hạn khí L1
Paradigm tin rằng có thể có một số “gây hiểu lầm” về phía cầu và trên thực tế, việc tăng giới hạn L1 Gas sẽ không có nhiều tác động trong thực tế. Paradigm 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 Paradigm muốn cảnh giác với các tình huống xấu nhất và do đó hiện không khuyến nghị tăng giới hạn L1 Gas. Paradigm 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.
Paradigm muốn mời cộng đồng hợp tác nghiên cứu theo các hướng liên quan, thường xoay quanh việc phá vỡ việc đo lường tài nguyên trong EVM. Bài báo do Broken Meter xuất bản này sẽ là điểm khởi đầu tốt cho lĩnh vực nghiên cứu này.
Trừu tượng hóa tài khoản
Mô hình sẵn sàng bao gồm 1 hoặc nhiều EIP (hoặc kết hợp ERC) trong hard fork, nhưng lý tưởng nhất là muốn thấy nhiều so sánh trải nghiệm người dùng và trải nghiệm nhà phát triển hơn giữa mỗi đề xuất, điều này sẽ tốt hơn. Hiểu được không gian đánh đổi và nỗ lực của công cụ hội nhập. Paradigm đang tập trung vào các EIP/ERC sau và cộng đồng có thể đưa ra đề xuất cho Paradigm bất kỳ lúc nào:
● EIP-3074: mã hoạt động AUTH và AUTHCALL
● ERC-4337: Trừu tượng hóa tài khoản bằng Alt Mempool
● EIP-5806: Giao dịch ủy quyền
● EIP-5920: Mã thanh toán THANH TOÁN
● EIP-6913: Lệnh SETCODE
● EIP-7377: Di chuyển giao dịch
● RIP-7560: Trừu tượng hóa tài khoản gốc – EIP cốt lõi – Học bổng của các nhà ảo thuật Ethereum
Lời nhắc cuối cùng là “trừu tượng hóa tài khoản” chỉ áp dụng cho EIP-4337 và EIP-7560 nêu trên, trong khi các đề xuất khác chủ yếu bao gồm hai lĩnh vực: Tài trợ khí đốt và vận hành hàng loạt. (“Tóm tắt tài khoản” giống như trừu tượng hóa chức năng xác minh, mục tiêu chính là cho phép xoay vòng khóa, biến đa chữ ký thành thành phần chính và cung cấp cho chúng tôi đường dẫn tự động đến kháng lượng tử.)
