Vào ngày 30 tháng 11 năm 2023, các nhà phát triển Ethereum đã tập trung trên Zoom cho cuộc họp cuộc gọi # 122 của All Core Developers Consensus (ACDC). 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 được kiểm duyệt bởi nhà nghiên cứu Danny Ryan của Ethereum Foundation, nơi các nhà phát triển thảo luận và phối hợp các thay đổi đối với lớp đồng thuận của Ethereum (CL). Tuần này, các nhà phát triển tập trung vào những phát triển mới nhất trong thử nghiệm Cancun / Deneb, bao gồm:
· Ra mắt Devnet # 12: Thử nghiệm phần mềm máy khách Teku, Lodestar và Lighthouse trên Devnet # 12, cũng như tất cả phần mềm máy khách lớp thực thi (EL), đang được tiến hành. Nhóm Prysm hy vọng phần mềm của họ sẽ sẵn sàng để thử nghiệm trong vòng hai đến ba tuần trên Devnet mới nhất.
· Vấn đề thoát trình xác thực trên Devnet # 11: Tại Devnet # 11, các nhà phát triển đã xác định được một vấn đề liên quan đến thoát trình xác thực, hiện đang được nhóm khách hàng Nimbus giải quyết. Devnet #11 sẽ tiếp tục hoạt động bình thường cho đến khi sự cố được giải quyết.
· Làm rõ đặc tả mạng: Các nhà phát triển đã thảo luận về việc làm rõ đặc tả cho các yêu cầu "BlockByRoot" và "BlobSidecarsByRoot", làm rõ liệu các nút lớp đồng thuận (CL) có nên đáp ứng các yêu cầu này theo một thứ tự cụ thể hay không.
Ngoài bản cập nhật Cancun / Deneb, các nhà phát triển đã thảo luận về một số vấn đề quy trình được đưa ra bởi Tim Beiko, Trưởng phòng Hỗ trợ Giao thức của Ethereum Foundation, để cải thiện sự phối hợp nâng cấp Ethereum.
Devnet # 12
Vào thứ Tư, ngày 30 tháng 11 năm 2023, bản nâng cấp Cancun / Deneb đã chính thức ra mắt trên Devnet # 12. Mario Vega của nhóm thử nghiệm Ethereum Foundation nói rằng "không có vấn đề lớn nào được xác định cho đến nay" trong ba máy khách CL hiện đang chạy trên testnet. Barnabas Busa, một kỹ sư DevOps tại Foundation, đã đề cập rằng có tổng cộng 225 trình xác thực trải rộng trên ba nút giữa Lighthouse, Teku và Lodestar. Do sự ổn định của Devnet # 12, Parithosh Jayanthi, một kỹ sư DevOps tại Foundation, đã hỏi các nhà phát triển liệu họ có nên bắt đầu lên kế hoạch cho một ngã ba bóng Goerli để thử nghiệm thêm Cancun / Deneb hay không. Tuy nhiên, xem xét rằng Prysm, ứng dụng khách CL phổ biến nhất hiện tại, vẫn chưa tham gia Devnet # 12, các nhà phát triển đã quyết định tạm dừng kế hoạch cho một ngã ba bóng Goerli cho đến khi phần mềm máy khách Prysm sẵn sàng để thử nghiệm. Beiko đề nghị di chuyển trên ngã ba bóng Goerli vào khoảng thời gian trước cuối năm nay. Do sự ổn định của Devnet # 12, các kế hoạch bị tạm dừng cho đến khi phần mềm máy khách Prysm sẵn sàng để thử nghiệm.
Devnet # 11
Nhà phát triển Nimbus, người có tên màn hình là "Dustin", chia sẻ chi tiết về vấn đề Devnet # 11 mà nhóm của ông đang làm việc. Những vấn đề này lần đầu tiên được phát hiện khi một nhà phát triển thoát khỏi một phần ba trình xác thực của Devnet # 11 để sử dụng trên Devnet # 12. Ryan hỏi Dustin liệu anh ta có thể phát hiện ra những vấn đề này bằng thử nghiệm bổ sung hay không. Dustin trả lời rằng, theo ý kiến của ông, bản chất của những lỗi này là do các chi tiết thực hiện nằm ngoài phạm vi của đặc tả đồng thuận. Tuy nhiên, ông cũng thừa nhận rằng có một "sự căng thẳng rõ ràng" giữa việc viết phần mềm máy khách nghiêm ngặt theo đặc tả CL để kiểm tra lợi ích của vùng phủ sóng và lội vào các vùng xám của đặc tả để đạt được hiệu suất nút tốt hơn.
"Ý tôi là thử nghiệm nhiều hơn luôn tốt, nhưng tìm ra một cách có hệ thống hơn cách kết hợp nhiều chức năng phía máy khách hơn vào việc chạy thử nghiệm có thể tự động hơn, cho dù đó là sử dụng Hive hay Kurtosis hay bất cứ điều gì. Tôi nghĩ chắc chắn sẽ hữu ích nếu những vấn đề này có thể được giải quyết hoặc mọi thứ có thể được chia nhỏ đủ độc đáo để có thể kết hợp nhiều nhiệm vụ hơn, "Dustin nói thêm, thêm rằng một thách thức khác mà các nhà phát triển CL nên xem xét giải quyết là tìm ra mức độ chi tiết mà đặc tả CL nên ra lệnh và chuẩn hóa hành vi của nút. "Thách thức khác ở đây là mức độ tiêu chuẩn hóa, thực sự không chỉ là vấn đề kỹ thuật phần mềm, hành vi nên được chuẩn hóa như thế nào?" Dustin hỏi. Tất cả các khách hàng CL đều vượt qua các bài kiểm tra kiểm tra hành vi cơ bản, nhưng hành vi nằm ngoài phạm vi của các bài kiểm tra này là mơ hồ. "Đây là cố ý mơ hồ sao? Điều gì nên thực sự rõ ràng theo quy tắc và những gì nên cố tình che khuất?" Dustin hỏi.
Ít nhất, các nhà phát triển đã đồng ý thêm nhiều thử nghiệm hơn vào các Devnet và testnet trong tương lai cho một số lượng lớn các lối thoát trình xác thực trong Cancun / Deneb. Ryan cũng thừa nhận rằng có chỗ cho phạm vi kiểm tra nghiêm ngặt và toàn diện hơn khi nói đến khách hàng CL và thực hiện đặc tả CL. Vega đề nghị Dustin tạo một bài đăng trên HackMD nêu chi tiết mối quan tâm của mình và thảo luận về chủ đề này trong cuộc gọi thử nghiệm Cancun / Deneb tiếp theo. Jayanthi nói thêm rằng dựa trên một số vấn đề được xác định gần đây trên Cancun / Deneb Devnets, rõ ràng các nhà phát triển cần phải có các công cụ có thể thực hiện một cách có hệ thống một số hành vi liên quan đến tích hợp trên chuỗi, chẳng hạn như rút ETH đặt cọc, rút tiền trình xác thực, v.v. Để làm điều này, Jayanthi khuyên bạn nên xây dựng một công cụ như vậy bằng cách sử dụng kết hợp các bộ thử nghiệm Hive và Kurtosis.
Nói về công cụ thử nghiệm mới cho bản nâng cấp Cancun / Deneb, Jayanthi lưu ý rằng các nhà phát triển đang làm việc trên một công cụ để kích hoạt đáng tin cậy các cuộc đoàn tụ chuỗi trên Devnets và testnet. Để đảm bảo rằng công cụ này hoạt động, Jayanthi đã yêu cầu các nhà phát triển chia sẻ chi tiết về các lỗi đã biết đã kích hoạt các chuỗi reorgs trên Ethereum. Jayanthi giải thích rằng ông sẽ sử dụng những lỗi này để kiểm tra công cụ và đảm bảo rằng nó có thể xác định một cách đáng tin cậy khi nào việc tổ chức lại xảy ra và khi nào nó được giải quyết.
Làm rõ các thông số kỹ thuật mạng
Các nhà phát triển đã thảo luận ngắn gọn về một yêu cầu kéo mở được đề xuất bởi nhà nghiên cứu Justin Traglia của Ethereum Foundation về thứ tự phản hồi mà khách hàng CL nên trả lại khi nhận được yêu cầu "BlockbyRoot" hoặc "BlobSidecarsByRoot". Ryan hỏi làm thế nào các nhóm khách hàng CL khác nhau đã triển khai tính năng này. Không ai trong số các nhà phát triển trong cuộc gọi trả lời câu hỏi này. Ryan đề nghị hồi sinh cuộc thảo luận trên kênh Discord Nghiên cứu &; Phát triển Ethereum để liên quan đến nhiều nhà phát triển khách hàng hơn. Ryan thừa nhận rằng có sự mơ hồ trong các thông số kỹ thuật của hai yêu cầu, "có thể là nguyên nhân của các vấn đề và các trường hợp cạnh kỳ lạ" và "xứng đáng được làm rõ và sắp xếp", Ryan khẳng định.
Ryan cũng đề cập rằng anh ấy sẽ phát hành một phiên bản mới của đặc tả CL trong vài ngày tới. Phiên bản mới nhất bổ sung đáng kể các thông số kỹ thuật về thời điểm máy khách CL có thể cung cấp các khối và khối thông qua yêu cầu RPC "byRoot". Để biết thêm thông tin cơ bản về thảo luận về việc truy xuất các khối và khối bị thiếu thông qua các yêu cầu RPC "byRoot", vui lòng tham khảo nhật ký cuộc gọi trước đó. Ryan nhấn mạnh rằng các bổ sung mới cho đặc tả CL có trong phiên bản mới nhất sẽ không có bất kỳ thay đổi đột phá nào đối với mã ảnh hưởng đến mã cho các trình xác thực đã chạy trên Devnet # 11 hoặc # 12.
Quy trình lập kế hoạch nâng cấp
Tiếp theo, các nhà phát triển thảo luận về các hạng mục quy trình khác nhau do Beiko đề xuất. Beiko nói rằng một bài đăng trên blog cảnh báo người dùng Goerli testnet về việc ngừng hoạt động sắp xảy ra trong vòng 3 tháng kể từ khi bản nâng cấp Cancun / Deneb được kích hoạt trên Goerli hoặc 1 tháng sau khi nâng cấp được kích hoạt trên mạng chính Ethereum, tùy theo thời điểm nào muộn hơn, sẽ được công bố trên blog Ethereum Foundation vào ngày 30 tháng 11. Kể từ khi kết thúc cuộc gọi, bài đăng trên blog trên đã được xuất bản và có thể được đọc tại đây.
Beiko đề nghị tạo một thư mục dành riêng cho việc nâng cấp trong kho lưu trữ Ethereum "pm" để sắp xếp các tệp khác nhau liên quan đến một bản nâng cấp cụ thể vào một thư mục duy nhất để sử dụng sau này. Các nhà phát triển trong cuộc gọi đã đồng ý với đề xuất của Beiko.
Mục quy trình thứ hai do Beiko đề xuất là về việc tạo tài liệu "Meta EIP" để theo dõi toàn bộ phạm vi nâng cấp mạng đã được hoàn thành trên Ethereum. "Không có nơi nào tốt để theo dõi toàn bộ phạm vi nâng cấp mạng trước khi triển khai và công bố nó trong một bài đăng trên blog", Beiko viết trong một bài đăng về đề xuất Meta EIP của mình. "Đối với Dencun, chúng tôi có EL EIP trong tệp đánh dấu 7 khó tìm và CL EIP là một phần của Đặc điểm kỹ thuật chuỗi Beacon 3. Điều này không tuyệt vời, vì cả hai đều hơi khó tìm, chúng sử dụng các 'định dạng' khác nhau và chúng dẫn đến trùng lặp. Vì ERC và EIP hiện đã tách biệt, tôi khuyên bạn nên (quay trở lại) sử dụng Meta EIP để theo dõi các EIP có trong bản nâng cấp mạng. Các nhà phát triển đã ủng hộ việc tạo ra các tài liệu này. Beiko cho biết ông sẽ soạn thảo một tài liệu để xem xét nâng cấp Cancun / Deneb trong tuần này.
Cuối cùng, Beiko đưa ra một câu hỏi về tính hữu ích của việc đánh dấu các thay đổi mã được đề xuất, Đề xuất cải tiến Ethereum (EIP), là "Xem xét đưa vào" (CFI). Theo Beiko, CFI là một trạng thái mà các nhà phát triển trong lịch sử đã sử dụng như một "tín hiệu mềm", chỉ ra rằng các tác giả của EIP nên tiếp tục làm việc với các đề xuất có thể được đưa vào các hard fork trong tương lai. Nó chỉ được sử dụng để thay đổi và nâng cấp mã tập trung vào EL. 「[CFI] cao hơn những ý tưởng ngẫu nhiên từ những người ngẫu nhiên, nhưng trước khi chúng được chấp nhận trong fork", Beiko nói.
Trong quá khứ, việc dán nhãn CFI đã thực hiện rất ít hoặc không có nỗ lực trong việc chỉ ra EIP nào trên EL sẽ được triển khai trong việc nâng cấp hoặc khi nào. Nó đã được áp dụng cho một loạt các EIP với mức độ sẵn sàng mã khác nhau và hỗ trợ từ các nhóm khách hàng. Trong trường hợp đề xuất Định dạng đối tượng EVM (EOF), các nhà phát triển sử dụng thẻ này để thể hiện cam kết triển khai EOF trong bản nâng cấp sắp tới, Cancun / Deneb. Tuy nhiên, EOF, cũng như một số đề xuất khác cũng được gắn cờ là CFI, đã bị Cancun / Deneb từ chối và không rõ tình trạng của các EIP này được gắn cờ là CFI trong lần nâng cấp tiếp theo Prague / Electra.
Beiko nói rằng nếu trạng thái này không có ích, các nhà phát triển nên loại bỏ nó, nhưng nếu họ có ý định giữ nó, các nhà phát triển CL cũng nên sử dụng cùng một nhãn cho các thay đổi mã mà họ xem xét thực hiện trong nâng cấp CL. Không rõ quy trình đánh giá CL EIP phản ánh quy trình đánh giá EL EIP ở mức độ nào và liệu chúng có nên phát triển theo cùng một cách trong tương lai hay không. Thông thường, các thay đổi mã được đề xuất đối với đặc tả CL được thảo luận trong cuộc gọi hội nghị ACDC, trong khi các EIP được đề xuất đối với đặc tả EL được thảo luận trong cuộc gọi hội nghị ACDE.
Danno Ferrin của Swirlds Labs cũng đưa ra ý tưởng tạo ra một trường giữ chỗ cho tất cả các EIP, cho dù liên quan đến CL hay EL, xác định trạng thái của chúng trong quá trình xem xét, bao gồm cả trạng thái CFI. Trong cuộc gọi này, không có quyết định rõ ràng về chủ đề tình trạng KCN sinh thái và ghi nhãn CFI.
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.
Tổng hợp cuộc họp mới nhất của các nhà phát triển cốt lõi Ethereum: Devnet #12启动, quy trình lập kế hoạch nâng cấp
Vào ngày 30 tháng 11 năm 2023, các nhà phát triển Ethereum đã tập trung trên Zoom cho cuộc họp cuộc gọi # 122 của All Core Developers Consensus (ACDC). 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 được kiểm duyệt bởi nhà nghiên cứu Danny Ryan của Ethereum Foundation, nơi các nhà phát triển thảo luận và phối hợp các thay đổi đối với lớp đồng thuận của Ethereum (CL). Tuần này, các nhà phát triển tập trung vào những phát triển mới nhất trong thử nghiệm Cancun / Deneb, bao gồm:
· Ra mắt Devnet # 12: Thử nghiệm phần mềm máy khách Teku, Lodestar và Lighthouse trên Devnet # 12, cũng như tất cả phần mềm máy khách lớp thực thi (EL), đang được tiến hành. Nhóm Prysm hy vọng phần mềm của họ sẽ sẵn sàng để thử nghiệm trong vòng hai đến ba tuần trên Devnet mới nhất.
· Vấn đề thoát trình xác thực trên Devnet # 11: Tại Devnet # 11, các nhà phát triển đã xác định được một vấn đề liên quan đến thoát trình xác thực, hiện đang được nhóm khách hàng Nimbus giải quyết. Devnet #11 sẽ tiếp tục hoạt động bình thường cho đến khi sự cố được giải quyết.
· Làm rõ đặc tả mạng: Các nhà phát triển đã thảo luận về việc làm rõ đặc tả cho các yêu cầu "BlockByRoot" và "BlobSidecarsByRoot", làm rõ liệu các nút lớp đồng thuận (CL) có nên đáp ứng các yêu cầu này theo một thứ tự cụ thể hay không.
Ngoài bản cập nhật Cancun / Deneb, các nhà phát triển đã thảo luận về một số vấn đề quy trình được đưa ra bởi Tim Beiko, Trưởng phòng Hỗ trợ Giao thức của Ethereum Foundation, để cải thiện sự phối hợp nâng cấp Ethereum.
Devnet # 12
Vào thứ Tư, ngày 30 tháng 11 năm 2023, bản nâng cấp Cancun / Deneb đã chính thức ra mắt trên Devnet # 12. Mario Vega của nhóm thử nghiệm Ethereum Foundation nói rằng "không có vấn đề lớn nào được xác định cho đến nay" trong ba máy khách CL hiện đang chạy trên testnet. Barnabas Busa, một kỹ sư DevOps tại Foundation, đã đề cập rằng có tổng cộng 225 trình xác thực trải rộng trên ba nút giữa Lighthouse, Teku và Lodestar. Do sự ổn định của Devnet # 12, Parithosh Jayanthi, một kỹ sư DevOps tại Foundation, đã hỏi các nhà phát triển liệu họ có nên bắt đầu lên kế hoạch cho một ngã ba bóng Goerli để thử nghiệm thêm Cancun / Deneb hay không. Tuy nhiên, xem xét rằng Prysm, ứng dụng khách CL phổ biến nhất hiện tại, vẫn chưa tham gia Devnet # 12, các nhà phát triển đã quyết định tạm dừng kế hoạch cho một ngã ba bóng Goerli cho đến khi phần mềm máy khách Prysm sẵn sàng để thử nghiệm. Beiko đề nghị di chuyển trên ngã ba bóng Goerli vào khoảng thời gian trước cuối năm nay. Do sự ổn định của Devnet # 12, các kế hoạch bị tạm dừng cho đến khi phần mềm máy khách Prysm sẵn sàng để thử nghiệm.
Devnet # 11
Nhà phát triển Nimbus, người có tên màn hình là "Dustin", chia sẻ chi tiết về vấn đề Devnet # 11 mà nhóm của ông đang làm việc. Những vấn đề này lần đầu tiên được phát hiện khi một nhà phát triển thoát khỏi một phần ba trình xác thực của Devnet # 11 để sử dụng trên Devnet # 12. Ryan hỏi Dustin liệu anh ta có thể phát hiện ra những vấn đề này bằng thử nghiệm bổ sung hay không. Dustin trả lời rằng, theo ý kiến của ông, bản chất của những lỗi này là do các chi tiết thực hiện nằm ngoài phạm vi của đặc tả đồng thuận. Tuy nhiên, ông cũng thừa nhận rằng có một "sự căng thẳng rõ ràng" giữa việc viết phần mềm máy khách nghiêm ngặt theo đặc tả CL để kiểm tra lợi ích của vùng phủ sóng và lội vào các vùng xám của đặc tả để đạt được hiệu suất nút tốt hơn.
"Ý tôi là thử nghiệm nhiều hơn luôn tốt, nhưng tìm ra một cách có hệ thống hơn cách kết hợp nhiều chức năng phía máy khách hơn vào việc chạy thử nghiệm có thể tự động hơn, cho dù đó là sử dụng Hive hay Kurtosis hay bất cứ điều gì. Tôi nghĩ chắc chắn sẽ hữu ích nếu những vấn đề này có thể được giải quyết hoặc mọi thứ có thể được chia nhỏ đủ độc đáo để có thể kết hợp nhiều nhiệm vụ hơn, "Dustin nói thêm, thêm rằng một thách thức khác mà các nhà phát triển CL nên xem xét giải quyết là tìm ra mức độ chi tiết mà đặc tả CL nên ra lệnh và chuẩn hóa hành vi của nút. "Thách thức khác ở đây là mức độ tiêu chuẩn hóa, thực sự không chỉ là vấn đề kỹ thuật phần mềm, hành vi nên được chuẩn hóa như thế nào?" Dustin hỏi. Tất cả các khách hàng CL đều vượt qua các bài kiểm tra kiểm tra hành vi cơ bản, nhưng hành vi nằm ngoài phạm vi của các bài kiểm tra này là mơ hồ. "Đây là cố ý mơ hồ sao? Điều gì nên thực sự rõ ràng theo quy tắc và những gì nên cố tình che khuất?" Dustin hỏi.
Ít nhất, các nhà phát triển đã đồng ý thêm nhiều thử nghiệm hơn vào các Devnet và testnet trong tương lai cho một số lượng lớn các lối thoát trình xác thực trong Cancun / Deneb. Ryan cũng thừa nhận rằng có chỗ cho phạm vi kiểm tra nghiêm ngặt và toàn diện hơn khi nói đến khách hàng CL và thực hiện đặc tả CL. Vega đề nghị Dustin tạo một bài đăng trên HackMD nêu chi tiết mối quan tâm của mình và thảo luận về chủ đề này trong cuộc gọi thử nghiệm Cancun / Deneb tiếp theo. Jayanthi nói thêm rằng dựa trên một số vấn đề được xác định gần đây trên Cancun / Deneb Devnets, rõ ràng các nhà phát triển cần phải có các công cụ có thể thực hiện một cách có hệ thống một số hành vi liên quan đến tích hợp trên chuỗi, chẳng hạn như rút ETH đặt cọc, rút tiền trình xác thực, v.v. Để làm điều này, Jayanthi khuyên bạn nên xây dựng một công cụ như vậy bằng cách sử dụng kết hợp các bộ thử nghiệm Hive và Kurtosis.
Nói về công cụ thử nghiệm mới cho bản nâng cấp Cancun / Deneb, Jayanthi lưu ý rằng các nhà phát triển đang làm việc trên một công cụ để kích hoạt đáng tin cậy các cuộc đoàn tụ chuỗi trên Devnets và testnet. Để đảm bảo rằng công cụ này hoạt động, Jayanthi đã yêu cầu các nhà phát triển chia sẻ chi tiết về các lỗi đã biết đã kích hoạt các chuỗi reorgs trên Ethereum. Jayanthi giải thích rằng ông sẽ sử dụng những lỗi này để kiểm tra công cụ và đảm bảo rằng nó có thể xác định một cách đáng tin cậy khi nào việc tổ chức lại xảy ra và khi nào nó được giải quyết.
Làm rõ các thông số kỹ thuật mạng
Các nhà phát triển đã thảo luận ngắn gọn về một yêu cầu kéo mở được đề xuất bởi nhà nghiên cứu Justin Traglia của Ethereum Foundation về thứ tự phản hồi mà khách hàng CL nên trả lại khi nhận được yêu cầu "BlockbyRoot" hoặc "BlobSidecarsByRoot". Ryan hỏi làm thế nào các nhóm khách hàng CL khác nhau đã triển khai tính năng này. Không ai trong số các nhà phát triển trong cuộc gọi trả lời câu hỏi này. Ryan đề nghị hồi sinh cuộc thảo luận trên kênh Discord Nghiên cứu &; Phát triển Ethereum để liên quan đến nhiều nhà phát triển khách hàng hơn. Ryan thừa nhận rằng có sự mơ hồ trong các thông số kỹ thuật của hai yêu cầu, "có thể là nguyên nhân của các vấn đề và các trường hợp cạnh kỳ lạ" và "xứng đáng được làm rõ và sắp xếp", Ryan khẳng định.
Ryan cũng đề cập rằng anh ấy sẽ phát hành một phiên bản mới của đặc tả CL trong vài ngày tới. Phiên bản mới nhất bổ sung đáng kể các thông số kỹ thuật về thời điểm máy khách CL có thể cung cấp các khối và khối thông qua yêu cầu RPC "byRoot". Để biết thêm thông tin cơ bản về thảo luận về việc truy xuất các khối và khối bị thiếu thông qua các yêu cầu RPC "byRoot", vui lòng tham khảo nhật ký cuộc gọi trước đó. Ryan nhấn mạnh rằng các bổ sung mới cho đặc tả CL có trong phiên bản mới nhất sẽ không có bất kỳ thay đổi đột phá nào đối với mã ảnh hưởng đến mã cho các trình xác thực đã chạy trên Devnet # 11 hoặc # 12.
Quy trình lập kế hoạch nâng cấp
Tiếp theo, các nhà phát triển thảo luận về các hạng mục quy trình khác nhau do Beiko đề xuất. Beiko nói rằng một bài đăng trên blog cảnh báo người dùng Goerli testnet về việc ngừng hoạt động sắp xảy ra trong vòng 3 tháng kể từ khi bản nâng cấp Cancun / Deneb được kích hoạt trên Goerli hoặc 1 tháng sau khi nâng cấp được kích hoạt trên mạng chính Ethereum, tùy theo thời điểm nào muộn hơn, sẽ được công bố trên blog Ethereum Foundation vào ngày 30 tháng 11. Kể từ khi kết thúc cuộc gọi, bài đăng trên blog trên đã được xuất bản và có thể được đọc tại đây.
Beiko đề nghị tạo một thư mục dành riêng cho việc nâng cấp trong kho lưu trữ Ethereum "pm" để sắp xếp các tệp khác nhau liên quan đến một bản nâng cấp cụ thể vào một thư mục duy nhất để sử dụng sau này. Các nhà phát triển trong cuộc gọi đã đồng ý với đề xuất của Beiko.
Mục quy trình thứ hai do Beiko đề xuất là về việc tạo tài liệu "Meta EIP" để theo dõi toàn bộ phạm vi nâng cấp mạng đã được hoàn thành trên Ethereum. "Không có nơi nào tốt để theo dõi toàn bộ phạm vi nâng cấp mạng trước khi triển khai và công bố nó trong một bài đăng trên blog", Beiko viết trong một bài đăng về đề xuất Meta EIP của mình. "Đối với Dencun, chúng tôi có EL EIP trong tệp đánh dấu 7 khó tìm và CL EIP là một phần của Đặc điểm kỹ thuật chuỗi Beacon 3. Điều này không tuyệt vời, vì cả hai đều hơi khó tìm, chúng sử dụng các 'định dạng' khác nhau và chúng dẫn đến trùng lặp. Vì ERC và EIP hiện đã tách biệt, tôi khuyên bạn nên (quay trở lại) sử dụng Meta EIP để theo dõi các EIP có trong bản nâng cấp mạng. Các nhà phát triển đã ủng hộ việc tạo ra các tài liệu này. Beiko cho biết ông sẽ soạn thảo một tài liệu để xem xét nâng cấp Cancun / Deneb trong tuần này.
Cuối cùng, Beiko đưa ra một câu hỏi về tính hữu ích của việc đánh dấu các thay đổi mã được đề xuất, Đề xuất cải tiến Ethereum (EIP), là "Xem xét đưa vào" (CFI). Theo Beiko, CFI là một trạng thái mà các nhà phát triển trong lịch sử đã sử dụng như một "tín hiệu mềm", chỉ ra rằng các tác giả của EIP nên tiếp tục làm việc với các đề xuất có thể được đưa vào các hard fork trong tương lai. Nó chỉ được sử dụng để thay đổi và nâng cấp mã tập trung vào EL. 「[CFI] cao hơn những ý tưởng ngẫu nhiên từ những người ngẫu nhiên, nhưng trước khi chúng được chấp nhận trong fork", Beiko nói.
Trong quá khứ, việc dán nhãn CFI đã thực hiện rất ít hoặc không có nỗ lực trong việc chỉ ra EIP nào trên EL sẽ được triển khai trong việc nâng cấp hoặc khi nào. Nó đã được áp dụng cho một loạt các EIP với mức độ sẵn sàng mã khác nhau và hỗ trợ từ các nhóm khách hàng. Trong trường hợp đề xuất Định dạng đối tượng EVM (EOF), các nhà phát triển sử dụng thẻ này để thể hiện cam kết triển khai EOF trong bản nâng cấp sắp tới, Cancun / Deneb. Tuy nhiên, EOF, cũng như một số đề xuất khác cũng được gắn cờ là CFI, đã bị Cancun / Deneb từ chối và không rõ tình trạng của các EIP này được gắn cờ là CFI trong lần nâng cấp tiếp theo Prague / Electra.
Beiko nói rằng nếu trạng thái này không có ích, các nhà phát triển nên loại bỏ nó, nhưng nếu họ có ý định giữ nó, các nhà phát triển CL cũng nên sử dụng cùng một nhãn cho các thay đổi mã mà họ xem xét thực hiện trong nâng cấp CL. Không rõ quy trình đánh giá CL EIP phản ánh quy trình đánh giá EL EIP ở mức độ nào và liệu chúng có nên phát triển theo cùng một cách trong tương lai hay không. Thông thường, các thay đổi mã được đề xuất đối với đặc tả CL được thảo luận trong cuộc gọi hội nghị ACDC, trong khi các EIP được đề xuất đối với đặc tả EL được thảo luận trong cuộc gọi hội nghị ACDE.
Danno Ferrin của Swirlds Labs cũng đưa ra ý tưởng tạo ra một trường giữ chỗ cho tất cả các EIP, cho dù liên quan đến CL hay EL, xác định trạng thái của chúng trong quá trình xem xét, bao gồm cả trạng thái CFI. Trong cuộc gọi này, không có quyết định rõ ràng về chủ đề tình trạng KCN sinh thái và ghi nhãn CFI.