Tác giả: Christine Kim, galaxy; Bản dịch: Huohuo/Blockchain bằng tiếng bản ngữ
Vào ngày 31 tháng 8, các nhà phát triển Ethereum đã tập trung trên Zoom để tham gia cuộc gọi hội nghị dành cho Nhà phát triển cốt lõi (ACDE). Được tổ chức bởi Tim Beiko của Ethereum Foundation, cuộc gọi ACDE là một chuỗi cuộc họp hai tuần một lần trong đó nhóm khách hàng Ethereum thảo luận và điều phối các thay đổi đối với Lớp thực thi Ethereum (EL). Tuần này, các nhà phát triển đã thảo luận về tiến trình phát triển và thử nghiệm trên:
Nâng cấp Cancun/Deneb (Dencun)
Chuyển đổi Verkle Trie
Cập nhật tuần tự hóa SSZ
1. Nâng cấp Cancun
Devnet #8 ra mắt hai tuần trước vào ngày 16 tháng 8. Barnabas Busa, một kỹ sư DevOps tại Ethereum Foundation, cho biết mạng thử nghiệm nâng cấp Cancun tập trung vào nhà phát triển dường như đang hoạt động tốt. Busa đã đề cập rằng dường như có một số vấn đề với các nút chạy phần mềm máy khách Nethermind (EL). Lukasz Rozmej, nhà phát triển ứng dụng khách Nethermind, giải thích rằng bản chất của vấn đề là do cấu hình sai trong quá trình triển khai nhóm giao dịch Blob. **(Lưu ý của người dịch: Devnet 8 là mạng thử nghiệm chuyên dụng đầu tiên chứa tất cả các EIP cuối cùng của bản nâng cấp Cancun/Deneb)
Về EIP 4788**, các nhà phát triển đã tái khẳng định ngắn gọn chính sách triển khai mới đối với các thay đổi về mã**. Các hợp đồng tiết lộ dữ liệu chuỗi đèn hiệu trên EL sẽ được triển khai giống như các hợp đồng thông minh thông thường, yêu cầu ai đó cấp vốn cho địa chỉ hợp đồng trước khi kích hoạt nâng cấp. Devnet #9, mạng thử nghiệm tiếp theo cho bản nâng cấp Cancun, sẽ áp dụng quy trình làm việc này và đảm bảo các nhà phát triển đã quen với nó.
Thay vì trì hoãn ngày phát hành Devnet #9, các nhà phát triển đã đồng ý tiếp tục thử nghiệm trên Devnet #8 cho đến khi mọi vấn đề trong quá trình triển khai ứng dụng khách được giải quyết. "Tôi thà tin tưởng vào Devnet #9 hơn là nói rằng chúng tôi muốn những thứ này hoạt động. ... Tôi thà khắc phục những vấn đề mà chúng tôi biết. Mặt khác, nếu chúng tôi gặp vấn đề khó khăn với Devnet #9 thì chắc chắn chúng tôi sẽ giải quyết có lại Devnet #10, tôi không nói rằng chúng ta không nên có Devnet #10. Chúng ta nên có một số lượng devnet đáng kể. Tôi nghĩ bây giờ chúng ta có thể cố gắng làm cho Devnet #9 thực sự đáng tin cậy." Ether nói, Danny Ryan, đồng nghiệp tại Fang Foundation và chủ trì cuộc gọi hội nghị ACDC.
*Những người khác trong cuộc gọi, bao gồm Tim Beiko, Marius Van Der Wijden và Justin Florentine, ủng hộ việc dành nhiều thời gian hơn để thử nghiệm trên Devnet #8 và sau đó thử nghiệm những thay đổi trong EIP 4788 trên Devnet #9 *. Beiko đề xuất thời gian để các nhà phát triển triệu tập lại Devnet #9 trong cuộc gọi hội nghị ACDE tiếp theo. Về chiến lược triển khai testnet, Beiko khuyến nghị trình tự sau:
Devnet #9: Một Devnet khác có thông số kỹ thuật Dencun bị đóng băng. Kiểm tra mạng một cách căng thẳng và cho rằng các nhà phát triển hài lòng với nó, sau đó chuyển sang mạng thử nghiệm công khai. Nếu không, hãy khởi động Devnet #10.
Holesky: Phân nhánh mạng thử nghiệm Holeksy mới ra mắt và triển khai bản nâng cấp Dencun trên đó.
Goerli: Sau đó triển khai Dencun trên Goerli. Vì mạng thử nghiệm áp chót ra mắt trước mạng chính, nên các thông số nâng cấp tại thời điểm này sẽ là thông số cuối cùng và cung cấp cho người dùng cũng như ứng dụng đủ thời gian để kiểm tra phần mềm của họ trước khi kích hoạt nâng cấp mạng chính. Dencun có thể sẽ là nhánh cuối cùng của Goerli trước khi nó không được dùng nữa và được thay thế bởi Holesky. (Chú ý của Người dịch: Từ Dencun là từ ghép được tạo thành từ Cancun (Cancun) và Deneb. Cancun là tên của bản nâng cấp lớp thực thi Ethereum này, và Deneb là tên của bản nâng cấp lớp giao thức. Do đó, nâng cấp Cancun Kết hợp với bản nâng cấp Deneb được gọi là bản nâng cấp Dencun.)
Sepolia: Cuối cùng, Dencun đã được triển khai trên Sepolia để đạt được kết quả tốt.
Không ai phản đối đề xuất của Beiko về việc phát hành testnet sau Devnet #9. Beiko đã đề cập rằng dòng thời gian trên sẽ được chia sẻ với cộng đồng Ethereum rộng lớn hơn trong một bài đăng trên blog sau khi mạng thử nghiệm Holesky chính thức ra mắt vào ngày 15 tháng 9. Ngoài ra, Beiko cho biết cũng có một testnet mang tên Ephemery đang được phát triển. Ehemery là một mạng thử nghiệm Ethereum dành cho các nhà khai thác trình xác thực sẽ đặt lại về trạng thái ban đầu sau một hoặc hai tuần. Để biết thêm thông tin về Ephemery Network, hãy đọc trang GitHub của dự án tại đây.
Trước khi chuyển sang thảo luận về Verkle Tries, Busa đã nhấn mạnh yêu cầu kéo mở (PR) trên GitHub cho mạng thử nghiệm Holesky. Theo yêu cầu của nhóm Erigon (EL), PR đề xuất bỏ thời gian kích hoạt cụ thể cho bản nâng cấp Dencun trên Holesky. Sau đó, nhà phát triển sẽ đặt giá trị kích hoạt Dencun trên Holesky thay vì ghi đè giá trị hiện có. Busa cũng hỏi về việc thử nghiệm mục tiêu/tối đa blob 3/6 thay vì giới hạn 2/4. **Về chủ đề này, Beiko đề xuất nêu lại vấn đề trong cuộc gọi ACDC vào tuần tới, Ryan đề cập rằng các thử nghiệm gần đây với kích thước khối lớn sẽ mang lại những hiểu biết mới. **
2. Chuyển đổi Verkle Trie
Tiếp theo, các nhà phát triển đã thảo luận về đề xuất của Vitalik Buterin về việc kết hợp lộ trình Verkle Trie và State Expiry để giảm bớt sự phức tạp trong việc triển khai Verkle Trie và tăng tốc lợi ích của State Expiry trên Ethereum. Về cơ bản, Verkle Trie hoặc Verkle Tree là cấu trúc dữ liệu cho phép người dùng dễ dàng xác minh lượng lớn dữ liệu dựa trên một bằng chứng mật mã duy nhất. **Chúng không khác gì Merkle Patricia Trie (MPT), một cấu trúc dữ liệu được sử dụng để lưu trữ trạng thái Ethereum. Tuy nhiên, hiệu quả chứng minh của cây Verkle tương đối cao hơn MPT, đó là lý do tại sao các nhà phát triển đang nỗ lực chuyển đổi MPT sang Verkle.
**Hết hạn trạng thái là một chương trình riêng biệt được thiết kế để giải quyết vấn đề tăng trưởng trạng thái không giới hạn. **Mục tiêu của việc hết hạn trạng thái là giảm kích thước trạng thái từ trên 100 GB xuống dưới 50 GB bằng cách xóa các phần của trạng thái Ethereum mà người dùng không truy cập trong một khoảng thời gian nhất định (ví dụ: 365 ngày). Andrew Ashikhmin từ nhóm tài khoản Erigon (EL) ủng hộ việc kết hợp hai bản nâng cấp, cho rằng chuyển đổi Verkle Trie sẽ được đơn giản hóa rất nhiều nếu kết hợp với State Expiry. Guillaume Ballet từ nhóm khách hàng Geth (EL), người đang dẫn đầu dự án Verkle Trie, lo ngại rằng việc kết hợp sẽ trì hoãn Verkle Tries kể từ khi trạng thái hết hạn vì một chủ đề nghiên cứu đã bị "bỏ rơi" trong hai năm qua.
Buterin đưa ra nhiều thông tin cơ bản hơn về động cơ cho đề xuất của mình, nói: “Với [Verkle] Quá trình chuyển đổi, vấn đề về cơ bản là chuyển đổi hơn 50 GB Merkle Patricia Trie thành... Verkle Trie trong mạng trực tiếp khá phức tạp. Đây quả thực là điều mà nhóm nghiên cứu đã trăn trở hơn một năm qua. Tôi nhớ năm ngoái tại Devconnect, về cơ bản nó là chủ đề của hoạt động nghiên cứu, về cơ bản là nhiều công việc R&D được tập hợp lại như toàn bộ phần còn lại của lộ trình Verkle, quá trình chuyển đổi cuối cùng đang diễn ra như thế nào. Ở một khía cạnh nào đó, độ phức tạp của nó sánh ngang với sự sáp nhập. "
Buterin tiếp tục giải thích cách State Expiry giảm đáng kể sự phức tạp của quá trình chuyển đổi sang Verkle. Tuy nhiên, ông cũng đề cập rằng có những điều kiện tiên quyết phức tạp đối với việc hết hạn trạng thái, chẳng hạn như nhu cầu bổ sung thêm không gian địa chỉ để hỗ trợ các "giai đoạn địa chỉ" mới hàng năm. Vì vậy, mặc dù độ phức tạp của việc triển khai Verkle sẽ giảm đi, nhưng các nhà phát triển vẫn cần để giải câu đố để thực hiện cả hai. Ngoài ra, nếu Verkle Tries được triển khai trước State Expiry, State Expiry sẽ ít khẩn cấp hơn, vì vậy các nhà phát triển nên cân nhắc sử dụng Verkle để thực hiện chuyển đổi hoặc đợi vài năm trước khi Verkle Then State Expiry được giới thiệu. Các nhà phát triển không rõ về giá trị bổ sung có được từ việc kết hợp hai bản nâng cấp lại với nhau và đồng ý tiếp tục thảo luận về chủ đề một cách không đồng bộ trên Discord và Lời kêu gọi của những người triển khai Verkle Trie.
3. Tuần tự hóa SSZ
Sau đó, Etan Kissling, nhà phát triển ứng dụng khách Nimbus (CL), đã trình bày bản cập nhật về tiến trình nâng cấp cấu trúc dữ liệu Ethereum lên định dạng tuần tự hóa SSZ. Để biết thêm thông tin cơ bản về vấn đề này, hãy đọc bản ghi cuộc gọi của nhà phát triển Ethereum trước đó tại đây. **Kissling đã nêu bật một cách tiếp cận mới để cập nhật tuần tự hóa dữ liệu Ethereum bằng định dạng dựa trên SSZ "PartialContainer". Kissling đã viết trong phần bình luận trong chương trình nghị sự cho cuộc gọi hội nghị tuần này, "[định dạng] này về cơ bản kết hợp tất cả các ưu điểm của [định dạng trước đó] và cũng có thể được sử dụng lại cho các mục đích khác, do đó làm cho Liên minh SSZ hiện không được sử dụng trở nên lỗi thời và các loại tùy chọn SSZ." **(Lưu ý của người dịch: Tuần tự hóa đơn giản (SSZ) là phương thức tuần tự hóa được sử dụng trên Beacon Chain. Phương pháp này thay thế tất cả các lớp đồng thuận ngoại trừ giao thức khám phá ngang hàng. Tuần tự hóa tiền tố độ dài đệ quy được sử dụng ở lớp thực thi. Tuần tự hóa đơn giản được xác định theo thiết kế và cũng có thể được Merkleized một cách hiệu quả.)
Sau khi cập nhật, Beiko đã nhanh chóng khen ngợi cách triển khai tham chiếu EL mới được tạo bằng Python (được gọi là EELS). Trong một bài đăng trên blog Ethereum Foundation gần đây, biên tập viên EIP và nhà nghiên cứu Ethereum Foundation, Sam Wilson đã viết: “EELS là triển khai tham chiếu Python của các thành phần cốt lõi của ứng dụng thực thi Ethereum, tập trung vào khả năng đọc và rõ ràng. EELS đặt mục tiêu trở thành người kế thừa tinh thần sang Yellow Paper, thân thiện với lập trình viên hơn và đồng bộ hóa với các nhánh sau hợp nhất, EELS có thể điền và thực hiện các thử nghiệm trạng thái, theo dõi mạng chính và là nơi tuyệt vời để tạo nguyên mẫu cho các EIP mới."
Một số nhà phát triển đã sử dụng EELS để triển khai lại EIP của họ và Ethereum Foundation đang cung cấp một khoản trợ cấp cho bất kỳ ai quan tâm đến việc cập nhật Sách vàng để bao gồm các nâng cấp mạng được hợp nhất trước còn thiếu như London và Paris để bổ sung cho EELS.
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óm tắt cuộc họp điều hành nhà phát triển cốt lõi mới nhất của Ethereum
Tác giả: Christine Kim, galaxy; Bản dịch: Huohuo/Blockchain bằng tiếng bản ngữ
Vào ngày 31 tháng 8, các nhà phát triển Ethereum đã tập trung trên Zoom để tham gia cuộc gọi hội nghị dành cho Nhà phát triển cốt lõi (ACDE). Được tổ chức bởi Tim Beiko của Ethereum Foundation, cuộc gọi ACDE là một chuỗi cuộc họp hai tuần một lần trong đó nhóm khách hàng Ethereum thảo luận và điều phối các thay đổi đối với Lớp thực thi Ethereum (EL). Tuần này, các nhà phát triển đã thảo luận về tiến trình phát triển và thử nghiệm trên:
Nâng cấp Cancun/Deneb (Dencun)
Chuyển đổi Verkle Trie
Cập nhật tuần tự hóa SSZ
1. Nâng cấp Cancun
Devnet #8 ra mắt hai tuần trước vào ngày 16 tháng 8. Barnabas Busa, một kỹ sư DevOps tại Ethereum Foundation, cho biết mạng thử nghiệm nâng cấp Cancun tập trung vào nhà phát triển dường như đang hoạt động tốt. Busa đã đề cập rằng dường như có một số vấn đề với các nút chạy phần mềm máy khách Nethermind (EL). Lukasz Rozmej, nhà phát triển ứng dụng khách Nethermind, giải thích rằng bản chất của vấn đề là do cấu hình sai trong quá trình triển khai nhóm giao dịch Blob. **(Lưu ý của người dịch: Devnet 8 là mạng thử nghiệm chuyên dụng đầu tiên chứa tất cả các EIP cuối cùng của bản nâng cấp Cancun/Deneb)
Về EIP 4788**, các nhà phát triển đã tái khẳng định ngắn gọn chính sách triển khai mới đối với các thay đổi về mã**. Các hợp đồng tiết lộ dữ liệu chuỗi đèn hiệu trên EL sẽ được triển khai giống như các hợp đồng thông minh thông thường, yêu cầu ai đó cấp vốn cho địa chỉ hợp đồng trước khi kích hoạt nâng cấp. Devnet #9, mạng thử nghiệm tiếp theo cho bản nâng cấp Cancun, sẽ áp dụng quy trình làm việc này và đảm bảo các nhà phát triển đã quen với nó.
Thay vì trì hoãn ngày phát hành Devnet #9, các nhà phát triển đã đồng ý tiếp tục thử nghiệm trên Devnet #8 cho đến khi mọi vấn đề trong quá trình triển khai ứng dụng khách được giải quyết. "Tôi thà tin tưởng vào Devnet #9 hơn là nói rằng chúng tôi muốn những thứ này hoạt động. ... Tôi thà khắc phục những vấn đề mà chúng tôi biết. Mặt khác, nếu chúng tôi gặp vấn đề khó khăn với Devnet #9 thì chắc chắn chúng tôi sẽ giải quyết có lại Devnet #10, tôi không nói rằng chúng ta không nên có Devnet #10. Chúng ta nên có một số lượng devnet đáng kể. Tôi nghĩ bây giờ chúng ta có thể cố gắng làm cho Devnet #9 thực sự đáng tin cậy." Ether nói, Danny Ryan, đồng nghiệp tại Fang Foundation và chủ trì cuộc gọi hội nghị ACDC.
*Những người khác trong cuộc gọi, bao gồm Tim Beiko, Marius Van Der Wijden và Justin Florentine, ủng hộ việc dành nhiều thời gian hơn để thử nghiệm trên Devnet #8 và sau đó thử nghiệm những thay đổi trong EIP 4788 trên Devnet #9 *. Beiko đề xuất thời gian để các nhà phát triển triệu tập lại Devnet #9 trong cuộc gọi hội nghị ACDE tiếp theo. Về chiến lược triển khai testnet, Beiko khuyến nghị trình tự sau:
Devnet #9: Một Devnet khác có thông số kỹ thuật Dencun bị đóng băng. Kiểm tra mạng một cách căng thẳng và cho rằng các nhà phát triển hài lòng với nó, sau đó chuyển sang mạng thử nghiệm công khai. Nếu không, hãy khởi động Devnet #10.
Holesky: Phân nhánh mạng thử nghiệm Holeksy mới ra mắt và triển khai bản nâng cấp Dencun trên đó.
Goerli: Sau đó triển khai Dencun trên Goerli. Vì mạng thử nghiệm áp chót ra mắt trước mạng chính, nên các thông số nâng cấp tại thời điểm này sẽ là thông số cuối cùng và cung cấp cho người dùng cũng như ứng dụng đủ thời gian để kiểm tra phần mềm của họ trước khi kích hoạt nâng cấp mạng chính. Dencun có thể sẽ là nhánh cuối cùng của Goerli trước khi nó không được dùng nữa và được thay thế bởi Holesky. (Chú ý của Người dịch: Từ Dencun là từ ghép được tạo thành từ Cancun (Cancun) và Deneb. Cancun là tên của bản nâng cấp lớp thực thi Ethereum này, và Deneb là tên của bản nâng cấp lớp giao thức. Do đó, nâng cấp Cancun Kết hợp với bản nâng cấp Deneb được gọi là bản nâng cấp Dencun.)
Sepolia: Cuối cùng, Dencun đã được triển khai trên Sepolia để đạt được kết quả tốt.
Không ai phản đối đề xuất của Beiko về việc phát hành testnet sau Devnet #9. Beiko đã đề cập rằng dòng thời gian trên sẽ được chia sẻ với cộng đồng Ethereum rộng lớn hơn trong một bài đăng trên blog sau khi mạng thử nghiệm Holesky chính thức ra mắt vào ngày 15 tháng 9. Ngoài ra, Beiko cho biết cũng có một testnet mang tên Ephemery đang được phát triển. Ehemery là một mạng thử nghiệm Ethereum dành cho các nhà khai thác trình xác thực sẽ đặt lại về trạng thái ban đầu sau một hoặc hai tuần. Để biết thêm thông tin về Ephemery Network, hãy đọc trang GitHub của dự án tại đây.
Trước khi chuyển sang thảo luận về Verkle Tries, Busa đã nhấn mạnh yêu cầu kéo mở (PR) trên GitHub cho mạng thử nghiệm Holesky. Theo yêu cầu của nhóm Erigon (EL), PR đề xuất bỏ thời gian kích hoạt cụ thể cho bản nâng cấp Dencun trên Holesky. Sau đó, nhà phát triển sẽ đặt giá trị kích hoạt Dencun trên Holesky thay vì ghi đè giá trị hiện có. Busa cũng hỏi về việc thử nghiệm mục tiêu/tối đa blob 3/6 thay vì giới hạn 2/4. **Về chủ đề này, Beiko đề xuất nêu lại vấn đề trong cuộc gọi ACDC vào tuần tới, Ryan đề cập rằng các thử nghiệm gần đây với kích thước khối lớn sẽ mang lại những hiểu biết mới. **
2. Chuyển đổi Verkle Trie
Tiếp theo, các nhà phát triển đã thảo luận về đề xuất của Vitalik Buterin về việc kết hợp lộ trình Verkle Trie và State Expiry để giảm bớt sự phức tạp trong việc triển khai Verkle Trie và tăng tốc lợi ích của State Expiry trên Ethereum. Về cơ bản, Verkle Trie hoặc Verkle Tree là cấu trúc dữ liệu cho phép người dùng dễ dàng xác minh lượng lớn dữ liệu dựa trên một bằng chứng mật mã duy nhất. **Chúng không khác gì Merkle Patricia Trie (MPT), một cấu trúc dữ liệu được sử dụng để lưu trữ trạng thái Ethereum. Tuy nhiên, hiệu quả chứng minh của cây Verkle tương đối cao hơn MPT, đó là lý do tại sao các nhà phát triển đang nỗ lực chuyển đổi MPT sang Verkle.
**Hết hạn trạng thái là một chương trình riêng biệt được thiết kế để giải quyết vấn đề tăng trưởng trạng thái không giới hạn. **Mục tiêu của việc hết hạn trạng thái là giảm kích thước trạng thái từ trên 100 GB xuống dưới 50 GB bằng cách xóa các phần của trạng thái Ethereum mà người dùng không truy cập trong một khoảng thời gian nhất định (ví dụ: 365 ngày). Andrew Ashikhmin từ nhóm tài khoản Erigon (EL) ủng hộ việc kết hợp hai bản nâng cấp, cho rằng chuyển đổi Verkle Trie sẽ được đơn giản hóa rất nhiều nếu kết hợp với State Expiry. Guillaume Ballet từ nhóm khách hàng Geth (EL), người đang dẫn đầu dự án Verkle Trie, lo ngại rằng việc kết hợp sẽ trì hoãn Verkle Tries kể từ khi trạng thái hết hạn vì một chủ đề nghiên cứu đã bị "bỏ rơi" trong hai năm qua.
Buterin đưa ra nhiều thông tin cơ bản hơn về động cơ cho đề xuất của mình, nói: “Với [Verkle] Quá trình chuyển đổi, vấn đề về cơ bản là chuyển đổi hơn 50 GB Merkle Patricia Trie thành... Verkle Trie trong mạng trực tiếp khá phức tạp. Đây quả thực là điều mà nhóm nghiên cứu đã trăn trở hơn một năm qua. Tôi nhớ năm ngoái tại Devconnect, về cơ bản nó là chủ đề của hoạt động nghiên cứu, về cơ bản là nhiều công việc R&D được tập hợp lại như toàn bộ phần còn lại của lộ trình Verkle, quá trình chuyển đổi cuối cùng đang diễn ra như thế nào. Ở một khía cạnh nào đó, độ phức tạp của nó sánh ngang với sự sáp nhập. "
Buterin tiếp tục giải thích cách State Expiry giảm đáng kể sự phức tạp của quá trình chuyển đổi sang Verkle. Tuy nhiên, ông cũng đề cập rằng có những điều kiện tiên quyết phức tạp đối với việc hết hạn trạng thái, chẳng hạn như nhu cầu bổ sung thêm không gian địa chỉ để hỗ trợ các "giai đoạn địa chỉ" mới hàng năm. Vì vậy, mặc dù độ phức tạp của việc triển khai Verkle sẽ giảm đi, nhưng các nhà phát triển vẫn cần để giải câu đố để thực hiện cả hai. Ngoài ra, nếu Verkle Tries được triển khai trước State Expiry, State Expiry sẽ ít khẩn cấp hơn, vì vậy các nhà phát triển nên cân nhắc sử dụng Verkle để thực hiện chuyển đổi hoặc đợi vài năm trước khi Verkle Then State Expiry được giới thiệu. Các nhà phát triển không rõ về giá trị bổ sung có được từ việc kết hợp hai bản nâng cấp lại với nhau và đồng ý tiếp tục thảo luận về chủ đề một cách không đồng bộ trên Discord và Lời kêu gọi của những người triển khai Verkle Trie.
3. Tuần tự hóa SSZ
Sau đó, Etan Kissling, nhà phát triển ứng dụng khách Nimbus (CL), đã trình bày bản cập nhật về tiến trình nâng cấp cấu trúc dữ liệu Ethereum lên định dạng tuần tự hóa SSZ. Để biết thêm thông tin cơ bản về vấn đề này, hãy đọc bản ghi cuộc gọi của nhà phát triển Ethereum trước đó tại đây. **Kissling đã nêu bật một cách tiếp cận mới để cập nhật tuần tự hóa dữ liệu Ethereum bằng định dạng dựa trên SSZ "PartialContainer". Kissling đã viết trong phần bình luận trong chương trình nghị sự cho cuộc gọi hội nghị tuần này, "[định dạng] này về cơ bản kết hợp tất cả các ưu điểm của [định dạng trước đó] và cũng có thể được sử dụng lại cho các mục đích khác, do đó làm cho Liên minh SSZ hiện không được sử dụng trở nên lỗi thời và các loại tùy chọn SSZ." **(Lưu ý của người dịch: Tuần tự hóa đơn giản (SSZ) là phương thức tuần tự hóa được sử dụng trên Beacon Chain. Phương pháp này thay thế tất cả các lớp đồng thuận ngoại trừ giao thức khám phá ngang hàng. Tuần tự hóa tiền tố độ dài đệ quy được sử dụng ở lớp thực thi. Tuần tự hóa đơn giản được xác định theo thiết kế và cũng có thể được Merkleized một cách hiệu quả.)
Sau khi cập nhật, Beiko đã nhanh chóng khen ngợi cách triển khai tham chiếu EL mới được tạo bằng Python (được gọi là EELS). Trong một bài đăng trên blog Ethereum Foundation gần đây, biên tập viên EIP và nhà nghiên cứu Ethereum Foundation, Sam Wilson đã viết: “EELS là triển khai tham chiếu Python của các thành phần cốt lõi của ứng dụng thực thi Ethereum, tập trung vào khả năng đọc và rõ ràng. EELS đặt mục tiêu trở thành người kế thừa tinh thần sang Yellow Paper, thân thiện với lập trình viên hơn và đồng bộ hóa với các nhánh sau hợp nhất, EELS có thể điền và thực hiện các thử nghiệm trạng thái, theo dõi mạng chính và là nơi tuyệt vời để tạo nguyên mẫu cho các EIP mới."
Một số nhà phát triển đã sử dụng EELS để triển khai lại EIP của họ và Ethereum Foundation đang cung cấp một khoản trợ cấp cho bất kỳ ai quan tâm đến việc cập nhật Sách vàng để bao gồm các nâng cấp mạng được hợp nhất trước còn thiếu như London và Paris để bổ sung cho EELS.