Tổng kết cuộc họp mới nhất của ETH Workshop Core Developers: Kích hoạt nâng cấp Cancun trên testnet vào đầu tháng 1/2024

Tiêu đề gốc: Ethereum All Core Developers ution Call #176 Writeup

Bài viết gốc của Christine Kim

Biên dịch gốc: Luccy, BlockBeats

Ghi chú của biên tập viên:

Hội thảo ETH Tất cả các cuộc gọi đồng thuận của nhà phát triển cốt lõi (ACDE) được tổ chức hai tuần một lần để thảo luận và điều phối các thay đổi đối với Lớp thực thi hội thảo ETH (EL). Đây là cuộc gọi hội nghị thứ 176 của ACDE và nó sẽ bao gồm các cuộc thảo luận với việc nâng cấp Cancun / Deneb, tiến trình thử nghiệm Devnet # 12 và kế hoạch nâng cấp Prague / Electra.

Các nhà phát triển đã thảo luận về cách nâng cấp Cancun / Deneb đã được thử nghiệm trên Devnet # 12, bao gồm tiến độ và một số vấn đề được tìm thấy bởi các nhóm khách hàng khác nhau, cũng như các thách thức kỹ thuật trong việc lan truyền blob, MEV (Giá trị trích xuất tối đa) và hơn thế nữa. Đối với việc nâng cấp Prague / Electra sắp tới, các nhà phát triển đã đề xuất một loạt các thay đổi kỹ thuật có thể xảy ra.

Christine Kim, VP nghiên cứu tại Galaxy Digital, đã đưa ra một lưu ý chi tiết về những điểm nổi bật của cuộc họp, mà BlockBeasts biên soạn như sau:

Vào ngày 7 tháng 12 năm 2023, ETH nhà phát triển đã tập trung tại Zoom for All Core Developers ution (ACDE) gọi # 176. Cuộc gọi hội nghị ACDC là một chuỗi các cuộc họp hai tuần một lần do Tim Beiko, Trưởng phòng Hỗ trợ Giao thức tại ETH Foundation dẫn đầu, nơi các nhà phát triển thảo luận và điều phối các thay đổi đối với Lớp điều hành (EL) của ETH Place. Tuần này, các nhà phát triển đã thảo luận về việc thử nghiệm bản nâng cấp Cancun / Deneb trên Devnet # 12. Họ đã đồng ý phối hợp ngày kích hoạt nâng cấp trên mạng thử nghiệm Goerli vào ETH đầu tháng Giêng sau khi kỳ nghỉ kết thúc. Ngoài ra, họ có kế hoạch bắt đầu thảo luận vào đầu tháng Giêng về những thay đổi mã nào nên được đưa vào ETH nâng cấp hội thảo tiếp theo, Prague / Electra.

Cập nhật Devnet #12

Thử nghiệm nâng cấp Cancun / Deneb trên Devnet # 12 đang diễn ra tốt đẹp. Parithosh Jayanthi, một kỹ sư DevOps tại Foundation, tiết lộ rằng một số lỗi đã được tìm thấy ở hai khách hàng, Reth và Lighthouse, và hai nhóm khách hàng đang làm việc để sửa chữa khẩn cấp. Để kiểm tra quy trình làm việc MEV kỹ lưỡng hơn, các nhóm DevOps đang tập trung nhiều hơn vào việc kích hoạt phần mềm MEV-Boost trên nhiều trình xác thực hơn trên Devnet # 12. Theo Jayanthi, nhóm của ông đã tìm thấy ít nhất một lỗi trong việc triển khai chuyển tiếp MEV của Flashbots. Danny Ryan, một nhà nghiên cứu tại ETH Foundation, nhấn mạnh rằng để đảm bảo rằng các trình xác thực có thể chuyển sang xây dựng khối cục bộ trong trường hợp xảy ra lỗi chuyển tiếp, cần phải kiểm tra thêm để kiểm tra các cơ chế thay thế.

Đối với việc nâng cấp nhóm dành riêng cho khách hàng, Terence Tsao, nhà phát triển ứng dụng khách Prysm, cho biết nhóm của ông đang làm việc trên một thiết kế cập nhật để lan truyền đốm màu #122中讨论的 ACDC. Tsao xác nhận rằng khách hàng Prysm sẽ sẵn sàng tham gia Devnet # 12 để thử nghiệm vào tuần tới, có thể là tuần tới. Justin Florentine, nhà phát triển của khách hàng Besu, nói rằng Besu đã sẵn sàng chuyển từ Devnet # 12. Đại diện từ các nhóm khách hàng của Nethermind, Erigon, Lodestar và Teku cũng cho biết họ đã sẵn sàng tiếp tục thử nghiệm nâng cấp trên testnet ETH công khai.

Dựa trên sự sẵn sàng của khách hàng, Beiko khuyên bạn nên điều phối một ngày hard fork ngay khi các nhà phát triển hết kỳ nghỉ. Giả sử không có lỗi lớn nào được tìm thấy trên Devnet # 12 trong vài tuần tới sau khi máy khách Prysm tham gia, Beiko nói rằng kích hoạt Cancun / Deneb trên Goerli có thể xảy ra vào khoảng giữa tháng Giêng. Ben Edgington từ nhóm Teku đã hỏi các nhà phát triển liệu họ có tự tin trong việc thay đổi số lượng đốm màu trên mỗi khối từ hai thành ba hay không. Ryan đề nghị thử nghiệm bổ sung các mục tiêu blob tăng lên trong quá trình shadow fork lớn và kích hoạt Cancun / Deneb trên Goerli. Beiko xác nhận rằng việc kích hoạt nâng cấp trên Goerli sẽ là “thử nghiệm quan trọng cuối cùng” của ba mục tiêu blob trên mỗi khối. Giả sử không có vấn đề nào được tìm thấy, các nhà phát triển sẽ tiếp tục sử dụng số lượng blob tăng lên để kích hoạt mainnet.

Nhìn chung, Beiko nói rằng các nhà phát triển sẽ tiếp tục thử nghiệm nâng cấp trên Devnet # 12 từ nay đến cuối kỳ nghỉ. Nhóm DevOps có kế hoạch tung ra ít nhất một Goerli shadow fork vào cuối tháng Mười Hai để chuẩn bị cho một hard fork Goerli thực sự vào tháng Giêng. Nếu các nhà phát triển lắp ráp cho năm mới, họ sẽ thảo luận về ngày kích hoạt hard fork Goerli.

Cờ ghi đè của trình tạo

Tiếp theo, Tsao hỏi nhóm khách hàng về tiến trình của họ trong việc triển khai cờ ghi đè Builder. Cờ ghi đè Builder là một trường Boolean mới trong bản nâng cấp Cancun mà máy khách lớp thực thi có thể sử dụng để chỉ ra cho máy khách lớp đồng thuận rằng khi Trình tạo phát hiện hoạt động kiểm duyệt, trình xác thực sẽ quay trở lại thế hệ khối cục bộ thay vì sử dụng Trình tạo của bên thứ ba. Như Tsao nhấn mạnh, các chi tiết triển khai về cách phát hiện các hoạt động đánh giá của Builder là chủ quan và cố tình để lại cho nhóm khách hàng thiết kế. Để biết thêm thông tin về cờ ghi đè Builder, vui lòng tham khảo biên bản ACDC#112 và ACDE#165.

Nhà phát triển của nhóm khách hàng Geth, người có tên màn hình là “Lightclient”, nói rằng nhóm của ông đã triển khai cờ, nhưng sẽ không hợp nhất nó trong bản phát hành chính thức “trong tương lai gần”. Đại diện từ các nhóm Besu và Nethermind tuyên bố rằng cờ tùy chọn này vẫn chưa được triển khai trong khách hàng của họ. Tsao nhấn mạnh rằng cờ có thể là một công cụ hữu ích và tốt nhất là triển khai nó càng sớm càng tốt để ngăn cản và ngăn cản các nhóm đặt cọc hoặc các nhà khai thác nút xác thực lớn tham gia vào một số “trò chơi thời gian” nhất định. Tsao giải thích rằng các trình xác thực có thể kiếm được nhiều MEV hơn (Giá trị có thể trích xuất tối đa) bằng cách trì hoãn việc lan truyền khối và sau khi giới thiệu các đốm màu sau khi nâng cấp Cancun, sẽ có sự chậm trễ trong việc lan truyền khối. Trong những lần trì hoãn này, người xác thực có thể chọn bao gồm các giao dịch MEV có lợi hơn trong khối, điều này không tối ưu để lan truyền blob kịp thời.

Xác nhận rằng các giao dịch blob sẽ phải cạnh tranh với các giao dịch thông thường, một nhà phát triển ẩn danh trong nhóm Prysm, người có tên màn hình là Potuz, nói thêm: "Blobs cần phải cạnh tranh không chỉ với phí, mà còn với độ trễ và tất cả MEV đạt được bằng cách trì hoãn các khối. Khi thiết kế cơ chế phí cho blobs, tôi nghĩ đó là một thị trường chưa bị chặn hoặc tính đến. Tsao cho biết ông sẽ đưa vấn đề này lên một lần nữa trong Ethereum Research Discord để thảo luận thêm. Ngoài ra, Ryan nhấn mạnh các nhà nghiên cứu của Ethereum Foundation Caspar Schwarz-Schilling và bài đăng mới nhất của Mike Neuder về “trò chơi thời gian” trên trang web Ethresearch.

Tiến độ dự án

Tiếp theo, Beiko chia sẻ ba cập nhật liên quan đến quy trình lập kế hoạch nâng cấp ETH Workshop. Đầu tiên, như trong #123上讨论的那样 ACDC, Beiko đã tạo một tài liệu Meta EIP cho bản nâng cấp Cancun / Deneb, trong đó liệt kê tất cả các Đề xuất Cải tiến (EIP) ETH đã được đưa vào Cancun / Deneb. Nó đã được tạo trên GitHub với số EIP 7569. Ngoài ra, Beiko đã tạo EIP 7568 làm tài liệu Meta EIP cho tất cả các bản nâng cấp trước đó và các nhà phát triển đã không tạo tài liệu chuyên dụng để theo dõi danh sách các EIP có trong bản nâng cấp. EIP 7568 được liên kết với đặc tả mã nâng cấp.

Thứ hai, Beiko thông báo rằng ông đã tạo một chủ đề thảo luận mới trên trang web Ethereum Magicians để xác định bản nâng cấp mạng tiếp theo, Prague / Electra. Ông yêu cầu các nhà phát triển suy nghĩ nghiêm túc về việc có nên kết hợp các nâng cấp Lớp thực thi (EL) và Lớp đồng thuận (CL) với nhau như hai hard fork trước đây đã thực hiện hay không. Việc kích hoạt một số thay đổi mã nhất định, chẳng hạn như EIP 7002, sẽ yêu cầu thay đổi cả EL và CL, vì vậy cả nâng cấp Prague và Electra sẽ cần phải được phối hợp. Tuy nhiên, đối với các thay đổi mã khác, chẳng hạn như cây Verkle, có một cách để thiết kế lại việc triển khai và chỉ cần nâng cấp CL.

Ryan lưu ý rằng các nhà phát triển lớp đồng thuận (CL) làm việc song song với cây Verkle cũng đang thực hiện các thay đổi mã để hỗ trợ lấy mẫu tính khả dụng của dữ liệu. Beiko khuyên các nhà phát triển không nên đi sâu vào chi tiết về tất cả các EIP mà họ muốn thấy trong bản nâng cấp Prague / Electra, mà nên xem xét tất cả các thay đổi mã ứng cử viên trong kỳ nghỉ lễ và sẵn sàng thảo luận nghiêm túc vào tháng Giêng. Potuz đồng ý, nói thêm rằng một EIP được thiết kế để giải quyết vấn đề ngày càng tăng về kích thước bộ xác thực ETH sẽ là một thay đổi mã quan trọng ở Prague / Electra. Dựa trên sự phức tạp của các thay đổi mã, Beiko khuyến nghị rằng đối với một số EIP nhất định, chẳng hạn như Verkle hoặc lấy mẫu tính khả dụng của dữ liệu, các nhà phát triển nên tổ chức các cuộc họp chuyên dụng sau kỳ nghỉ để thảo luận chi tiết về những thay đổi giao thức lớn hơn này.