Tác giả: @TimBeiko Bản dịch: Huohuo/Blockchain bản địa
Một cuộc họp @ethereum #AllCoreDevs khác đã kết thúc vào ngày 15 tháng 9: các bản cập nhật cho mạng phát triển, các bổ sung cho Dencun và tổng quan toàn diện về Reth đã được thảo luận!
Chương trình nghị sự: Liên kết trực tiếp:
Dưới đây là bản tóm tắt cuộc họp của @TimBeiko.
1. Cập nhật trạng thái Devnet-8
Đầu tiên, cập nhật trạng thái trên devnet-8: mạng đang trong quá trình phát triển cuối cùng và nhiều khách hàng đã đẩy các bản cập nhật mới lên mạng. Trong thời gian chờ đợi, chúng tôi đã bắt đầu thử nghiệm quy trình xây dựng MEV/khối bằng cách sử dụng @KurtosisTech. @NethermindEth tuyên bố rằng nhóm giao dịch blob của họ hiện đã sẵn sàng và sau vài ngày thử nghiệm trên một nút duy nhất, họ đã triển khai nó tới tất cả các nút thử nghiệm Dencun.
Nhóm giao dịch blob của Geth cũng gần như hoàn tất. Besu đang thực hiện những cải tiến sâu rộng đối với nhóm giao dịch của mình (giới hạn tổng quy mô của các giao dịch blob và không phải blob) dự kiến sẽ được phát hành trong phiên bản tiếp theo. Erigon đang tiếp tục cải thiện nhóm giao dịch của mình và hy vọng sẽ sẵn sàng cho devnet-9. Prysm cũng lưu ý rằng có một số độ trễ trong việc nhận sidecar blob, theo họ, chúng thường đến với độ trễ khoảng 500 mili giây sau khối (trong khi khối mất khoảng 15 mili giây để xử lý).
Họ đang điều tra vấn đề này để xác định xem liệu nó có phải do tình trạng cạnh tranh giữa nhập khẩu blob và chunk hay không. Về câu hỏi liệu có cho phép hỗ trợ các giao dịch blob trong nhóm bộ nhớ trước hard fork hay không, nhóm đã nhất trí không làm như vậy.
##2,EIP-7514
Tiếp theo, chúng tôi tiếp tục thảo luận từ cuộc gọi ACDC tuần trước về việc có nên thêm giới hạn cố định vào hàng đợi kích hoạt trình xác thực hay không. Đề xuất này đã được chính thức hình thành với tên gọi EIP-7514. Nói tóm lại, điều này sẽ làm chậm tốc độ tăng trưởng phần trăm của việc đặt cược ETH trong trường hợp xấu nhất. Dankrad bày tỏ sự ủng hộ đối với đề xuất này trong cuộc gọi, nói rằng nó sẽ giúp chúng tôi có thời gian để thực hiện những thay đổi phức tạp hơn đối với phần thưởng của người xác nhận.
Tất cả các đội CL đều ủng hộ sự thay đổi này, với lưu ý rằng điều này chỉ áp dụng cho hàng gửi tiền chứ không áp dụng cho hàng rút tiền. Sau khi thảo luận thêm, chúng tôi quyết định đặt giới hạn là 8. Vì vậy, EIP-7514 sẽ là một phần trong bản nâng cấp Dencun! Dự kiến trong vài ngày tới, EIP và thông số kỹ thuật CL liên quan PR sẽ được cập nhật để phản ánh sự thay đổi này.
3. EVM và Blob
Tiếp theo, chúng tôi đã thảo luận về một đề xuất tạm thời khác: thêm opcode vào Máy ảo Ethereum (EVM) để hiển thị phí cơ sở blob. Đề xuất này được đưa ra bởi @PlasmaPower0 từ Arbitrum, người đã nói trên R&D Discord vào đầu tuần này rằng nó sẽ hữu ích cho họ (và các giải pháp Lớp 2 khác). Chúng tôi đã có một mã hoạt động tương tự hiển thị BASEFEE trong EIP-1559, được giới thiệu cùng lúc với khi EIP được kích hoạt. Điều này giúp các giải pháp Lớp 2 dễ dàng xác định giá gas chính xác hơn để tính phí cho người dùng dựa trên chi phí dữ liệu L1.
@protolambda từ Optimism cũng tham dự cuộc họp và đề xuất rằng đây không phải là cách duy nhất để nhận phí cơ sở blob cho L2, vì họ có thể xem tiêu đề khối (chứa các giá trị được sử dụng để tính phí cơ sở blob) và cung cấp Merkle chống lại những giá trị chứng minh. Tuy nhiên, anh ấy đồng ý rằng đó là một tính năng hay. Arbitrum hiện không thực hiện phân tích cú pháp tiêu đề khối và việc dựa vào điều này có thể gây khó khăn cho các giải pháp Lớp 2 bất biến, vì điều này có thể gây rắc rối nếu định dạng tiêu đề khối cuối cùng thay đổi.
Một trong những tác giả EIP-4844 @adietrichs đã đề cập rằng opcode này không được bao gồm trong đặc tả ban đầu vì có mong muốn phát triển một cách tổng quát hơn để truy cập thông tin tiêu đề khối (thay vì thêm opcode một lần). Tuy nhiên, việc áp dụng thay đổi đầy tham vọng hơn này sẽ là một nhiệm vụ tham vọng hơn việc giới thiệu opcode này.
Thông tin được hiển thị bởi opcode này đã là những gì máy khách EL cần tính toán và về mặt ngữ nghĩa, nó gần giống với opcode BASEFEE. Nhóm khách hàng nhất trí rằng chúng tôi nên thêm opcode này, nếu chỉ để nhất quán với BASEFEE. Nếu trong tương lai chúng ta nghĩ ra một cơ chế "mượt mà" hơn thì bất kỳ chức năng dư thừa nào trong opcode mới này cũng sẽ trở thành vấn đề đối với các opcode khác sử dụng thông tin tiêu đề khối. Ngoài ra, cần nhấn mạnh rằng đây là một thay đổi rất nhỏ: @vdWijden đã triển khai nó trong Geth trước khi EIP tồn tại, chỉ mất khoảng 20 phút và nhóm Reth đã cam kết thay đổi về điều này trong cuộc gọi PR của ACD.
##4,EIP-4788
Tiếp theo, chúng tôi đã thảo luận về một số cập nhật cho EIP-4788, một đề xuất lưu trữ nguồn gốc đèn hiệu trong các hợp đồng trên chuỗi chính Ethereum. Trong vài tuần qua, chúng tôi đã tiến hành nhiều cuộc kiểm tra và kiểm tra kỹ lưỡng hợp đồng, dẫn đến một số thay đổi nhỏ được mô tả trong PR này. Mặc dù không phải tất cả các cuộc kiểm tra đều đã được hoàn thành và chưa có báo cáo nhưng @lightclients đã đưa ra cái nhìn tổng quan về những thay đổi được xem xét cho đến nay. Thay đổi đầu tiên là xử lý rõ ràng các dấu thời gian 0 để chúng gây ra hiện tượng khôi phục (giống như các dấu thời gian không hợp lệ khác) thay vì trả về 0. Thay đổi thứ hai liên quan đến kích thước bộ đệm. Giả sử thời gian thay đổi, hợp đồng ban đầu sẽ dẫn đến lãng phí dung lượng lưu trữ do cách hoạt động của số học mô-đun.
5. Tối ưu hóa gas
Cuối cùng, có một tính năng tối ưu hóa gas giúp giảm số lần tải CALLDATA. Kiểm toán viên sẽ xem xét những thay đổi này và chúng tôi dự kiến sẽ có báo cáo cuối cùng trước cuộc họp ACDE tiếp theo. Để tiếp tục công việc triển khai và thử nghiệm fuzz, chúng tôi đã đồng ý hợp nhất các thay đổi được đề xuất ngay bây giờ.
@shemnon cũng đề cập rằng những thay đổi này phải được ghi lại trong EIP thực tế - chúng tôi đang nghiên cứu vấn đề đó! Tiếp theo, chúng tôi đã thảo luận về cách khách hàng nên xử lý vấn đề này nếu địa chỉ hợp đồng hệ thống là một phần của trạng thái nhưng lại trống khi kết thúc quá trình thực thi. Mặc dù điều này thực sự khó có thể xảy ra trên mạng chính (theo những gì tôi hiểu!), nhưng đây là một trường hợp đặc biệt xảy ra trong quá trình thử nghiệm bằng cách đặt địa chỉ trong khối Genesis.
Cho rằng đây là một trường hợp đặc biệt và không có hành vi kinh điển rõ ràng nên chúng tôi đồng ý dành nhiều thời gian hơn để suy nghĩ về vấn đề này và tiếp tục thảo luận tại cuộc họp thử nghiệm vào tuần tới. Đó là tất cả về những thay đổi thông số kỹ thuật! Tất cả những điều trên đều được lên kế hoạch để đưa vào devnet-9. Nhóm khách hàng đồng ý rằng mọi thứ nên được triển khai và thử nghiệm trước ACDC vào tuần tới. Theo lời kêu gọi đó, chúng tôi sẽ thống nhất ngày ra mắt cho devnet-9.
ACDE tiếp theo dự kiến sẽ được tổ chức vào ngày 28 tháng 9, 14:00 giờ UTC. Cho đến lúc đó, hãy theo dõi @terencechain để biết thông tin tóm tắt về cuộc họp thử nghiệm, @benjaminion_xyz để biết thông tin về cuộc họp ACDC và @christine_dkim để biết thông tin chi tiết hơn về toàn bộ sự kiện.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
EIP-7514 sẽ là một phần của bản nâng cấp Ethereum Dencun
Tác giả: @TimBeiko Bản dịch: Huohuo/Blockchain bản địa
Một cuộc họp @ethereum #AllCoreDevs khác đã kết thúc vào ngày 15 tháng 9: các bản cập nhật cho mạng phát triển, các bổ sung cho Dencun và tổng quan toàn diện về Reth đã được thảo luận!
Chương trình nghị sự: Liên kết trực tiếp:
Dưới đây là bản tóm tắt cuộc họp của @TimBeiko.
1. Cập nhật trạng thái Devnet-8
Đầu tiên, cập nhật trạng thái trên devnet-8: mạng đang trong quá trình phát triển cuối cùng và nhiều khách hàng đã đẩy các bản cập nhật mới lên mạng. Trong thời gian chờ đợi, chúng tôi đã bắt đầu thử nghiệm quy trình xây dựng MEV/khối bằng cách sử dụng @KurtosisTech. @NethermindEth tuyên bố rằng nhóm giao dịch blob của họ hiện đã sẵn sàng và sau vài ngày thử nghiệm trên một nút duy nhất, họ đã triển khai nó tới tất cả các nút thử nghiệm Dencun.
Nhóm giao dịch blob của Geth cũng gần như hoàn tất. Besu đang thực hiện những cải tiến sâu rộng đối với nhóm giao dịch của mình (giới hạn tổng quy mô của các giao dịch blob và không phải blob) dự kiến sẽ được phát hành trong phiên bản tiếp theo. Erigon đang tiếp tục cải thiện nhóm giao dịch của mình và hy vọng sẽ sẵn sàng cho devnet-9. Prysm cũng lưu ý rằng có một số độ trễ trong việc nhận sidecar blob, theo họ, chúng thường đến với độ trễ khoảng 500 mili giây sau khối (trong khi khối mất khoảng 15 mili giây để xử lý).
Họ đang điều tra vấn đề này để xác định xem liệu nó có phải do tình trạng cạnh tranh giữa nhập khẩu blob và chunk hay không. Về câu hỏi liệu có cho phép hỗ trợ các giao dịch blob trong nhóm bộ nhớ trước hard fork hay không, nhóm đã nhất trí không làm như vậy.
##2,EIP-7514
Tiếp theo, chúng tôi tiếp tục thảo luận từ cuộc gọi ACDC tuần trước về việc có nên thêm giới hạn cố định vào hàng đợi kích hoạt trình xác thực hay không. Đề xuất này đã được chính thức hình thành với tên gọi EIP-7514. Nói tóm lại, điều này sẽ làm chậm tốc độ tăng trưởng phần trăm của việc đặt cược ETH trong trường hợp xấu nhất. Dankrad bày tỏ sự ủng hộ đối với đề xuất này trong cuộc gọi, nói rằng nó sẽ giúp chúng tôi có thời gian để thực hiện những thay đổi phức tạp hơn đối với phần thưởng của người xác nhận.
Tất cả các đội CL đều ủng hộ sự thay đổi này, với lưu ý rằng điều này chỉ áp dụng cho hàng gửi tiền chứ không áp dụng cho hàng rút tiền. Sau khi thảo luận thêm, chúng tôi quyết định đặt giới hạn là 8. Vì vậy, EIP-7514 sẽ là một phần trong bản nâng cấp Dencun! Dự kiến trong vài ngày tới, EIP và thông số kỹ thuật CL liên quan PR sẽ được cập nhật để phản ánh sự thay đổi này.
3. EVM và Blob
Tiếp theo, chúng tôi đã thảo luận về một đề xuất tạm thời khác: thêm opcode vào Máy ảo Ethereum (EVM) để hiển thị phí cơ sở blob. Đề xuất này được đưa ra bởi @PlasmaPower0 từ Arbitrum, người đã nói trên R&D Discord vào đầu tuần này rằng nó sẽ hữu ích cho họ (và các giải pháp Lớp 2 khác). Chúng tôi đã có một mã hoạt động tương tự hiển thị BASEFEE trong EIP-1559, được giới thiệu cùng lúc với khi EIP được kích hoạt. Điều này giúp các giải pháp Lớp 2 dễ dàng xác định giá gas chính xác hơn để tính phí cho người dùng dựa trên chi phí dữ liệu L1.
@protolambda từ Optimism cũng tham dự cuộc họp và đề xuất rằng đây không phải là cách duy nhất để nhận phí cơ sở blob cho L2, vì họ có thể xem tiêu đề khối (chứa các giá trị được sử dụng để tính phí cơ sở blob) và cung cấp Merkle chống lại những giá trị chứng minh. Tuy nhiên, anh ấy đồng ý rằng đó là một tính năng hay. Arbitrum hiện không thực hiện phân tích cú pháp tiêu đề khối và việc dựa vào điều này có thể gây khó khăn cho các giải pháp Lớp 2 bất biến, vì điều này có thể gây rắc rối nếu định dạng tiêu đề khối cuối cùng thay đổi.
Một trong những tác giả EIP-4844 @adietrichs đã đề cập rằng opcode này không được bao gồm trong đặc tả ban đầu vì có mong muốn phát triển một cách tổng quát hơn để truy cập thông tin tiêu đề khối (thay vì thêm opcode một lần). Tuy nhiên, việc áp dụng thay đổi đầy tham vọng hơn này sẽ là một nhiệm vụ tham vọng hơn việc giới thiệu opcode này.
Thông tin được hiển thị bởi opcode này đã là những gì máy khách EL cần tính toán và về mặt ngữ nghĩa, nó gần giống với opcode BASEFEE. Nhóm khách hàng nhất trí rằng chúng tôi nên thêm opcode này, nếu chỉ để nhất quán với BASEFEE. Nếu trong tương lai chúng ta nghĩ ra một cơ chế "mượt mà" hơn thì bất kỳ chức năng dư thừa nào trong opcode mới này cũng sẽ trở thành vấn đề đối với các opcode khác sử dụng thông tin tiêu đề khối. Ngoài ra, cần nhấn mạnh rằng đây là một thay đổi rất nhỏ: @vdWijden đã triển khai nó trong Geth trước khi EIP tồn tại, chỉ mất khoảng 20 phút và nhóm Reth đã cam kết thay đổi về điều này trong cuộc gọi PR của ACD.
##4,EIP-4788
Tiếp theo, chúng tôi đã thảo luận về một số cập nhật cho EIP-4788, một đề xuất lưu trữ nguồn gốc đèn hiệu trong các hợp đồng trên chuỗi chính Ethereum. Trong vài tuần qua, chúng tôi đã tiến hành nhiều cuộc kiểm tra và kiểm tra kỹ lưỡng hợp đồng, dẫn đến một số thay đổi nhỏ được mô tả trong PR này. Mặc dù không phải tất cả các cuộc kiểm tra đều đã được hoàn thành và chưa có báo cáo nhưng @lightclients đã đưa ra cái nhìn tổng quan về những thay đổi được xem xét cho đến nay. Thay đổi đầu tiên là xử lý rõ ràng các dấu thời gian 0 để chúng gây ra hiện tượng khôi phục (giống như các dấu thời gian không hợp lệ khác) thay vì trả về 0. Thay đổi thứ hai liên quan đến kích thước bộ đệm. Giả sử thời gian thay đổi, hợp đồng ban đầu sẽ dẫn đến lãng phí dung lượng lưu trữ do cách hoạt động của số học mô-đun.
5. Tối ưu hóa gas
Cuối cùng, có một tính năng tối ưu hóa gas giúp giảm số lần tải CALLDATA. Kiểm toán viên sẽ xem xét những thay đổi này và chúng tôi dự kiến sẽ có báo cáo cuối cùng trước cuộc họp ACDE tiếp theo. Để tiếp tục công việc triển khai và thử nghiệm fuzz, chúng tôi đã đồng ý hợp nhất các thay đổi được đề xuất ngay bây giờ.
@shemnon cũng đề cập rằng những thay đổi này phải được ghi lại trong EIP thực tế - chúng tôi đang nghiên cứu vấn đề đó! Tiếp theo, chúng tôi đã thảo luận về cách khách hàng nên xử lý vấn đề này nếu địa chỉ hợp đồng hệ thống là một phần của trạng thái nhưng lại trống khi kết thúc quá trình thực thi. Mặc dù điều này thực sự khó có thể xảy ra trên mạng chính (theo những gì tôi hiểu!), nhưng đây là một trường hợp đặc biệt xảy ra trong quá trình thử nghiệm bằng cách đặt địa chỉ trong khối Genesis.
Cho rằng đây là một trường hợp đặc biệt và không có hành vi kinh điển rõ ràng nên chúng tôi đồng ý dành nhiều thời gian hơn để suy nghĩ về vấn đề này và tiếp tục thảo luận tại cuộc họp thử nghiệm vào tuần tới. Đó là tất cả về những thay đổi thông số kỹ thuật! Tất cả những điều trên đều được lên kế hoạch để đưa vào devnet-9. Nhóm khách hàng đồng ý rằng mọi thứ nên được triển khai và thử nghiệm trước ACDC vào tuần tới. Theo lời kêu gọi đó, chúng tôi sẽ thống nhất ngày ra mắt cho devnet-9.
ACDE tiếp theo dự kiến sẽ được tổ chức vào ngày 28 tháng 9, 14:00 giờ UTC. Cho đến lúc đó, hãy theo dõi @terencechain để biết thông tin tóm tắt về cuộc họp thử nghiệm, @benjaminion_xyz để biết thông tin về cuộc họp ACDC và @christine_dkim để biết thông tin chi tiết hơn về toàn bộ sự kiện.