Hội nghị tổng kết các nhà phát triển Ethereum: Nâng cấp Cancun, Phân nhánh cứng và Prague
Tuyển chọn TechFlowTuyển chọn TechFlow
Hội nghị tổng kết các nhà phát triển Ethereum: Nâng cấp Cancun, Phân nhánh cứng và Prague
Hội nghị cũng thảo luận về các ưu tiên thay đổi mã trong đợt nâng cấp hard fork tiếp theo Prague/Electra sau Dencun.
Chuyên sâu báo cáo Web3Tác giả: Christine Kim, Phó Chủ tịch Nghiên cứu tại Galaxy
Dịch: Qin Jin, Carbon Chain Value
Ngày 4 tháng 1 năm 2024, các nhà phát triển Ethereum đã tụ họp trên Zoom trong cuộc gọi All Core Developers Execution (ACDE) #178. Các cuộc gọi ACDE thường do Tim Beiko, trưởng nhóm giao thức tại Quỹ Ethereum, chủ trì và là chuỗi hội nghị hai tuần một lần 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 thực thi (EL) của Ethereum. Cuộc họp tuần này được điều hành bởi một nhà phát triển Geth EL ẩn danh với biệt danh "Lightclient". Các nhà phát triển đã xác nhận lại ba ngày kích hoạt mạng thử nghiệm công khai tiếp theo cho nâng cấp Cancun/Deneb (gọi tắt là Dencun). Họ cũng thảo luận về thứ tự ưu tiên các thay đổi mã (EIPs) cho đợt nâng cấp hard fork tiếp theo Prague/Electra sau Dencun.
Cập nhật Dencun
Trong kỳ nghỉ lễ không có cập nhật cụ thể nào về nâng cấp Dencun. Kể từ cuộc gọi ACDE #177 ngày 21 tháng 12, các đội phát triển client đã chuẩn bị phiên bản mới cho mạng thử nghiệm Goerli. Do trước đó việc kiểm thử nâng cấp bị chậm trễ vì vấn đề ở Prysm, nhà phát triển Geth Marius van der Wijden yêu cầu đội client Prysm cập nhật tiến độ phát hành phiên bản mới. Nhà phát triển Prysm Terence Tsao xác nhận rằng đội Prysm sẽ sẵn sàng phiên bản mới cho hard fork Goerli vào tuần tới. Tuy nhiên, phiên bản dành cho Goerli sẽ là phiên bản "xem trước" (pre-release), nghĩa là nó sẽ không phải là phiên bản được khuyến nghị để chạy trên mạng chính Ethereum. Sau hard fork Goerli, đội Prysm dự định phát hành thêm một phiên bản nữa bao gồm một số thay đổi và cập nhật, được khuyến nghị người dùng sử dụng trên mạng chính và kiểm thử trên Sepolia hoặc Holesky.
Mặc dù Tsao cho biết đội Prysm hài lòng với thời điểm kích hoạt hard fork Goerli là ngày 17 tháng 1 năm 2024 như đã thảo luận tại ACDE #177, ông đề xuất nên đợi sau khi hoàn tất hard fork Goerli rồi mới xác định ngày kích hoạt hard fork cho Sepolia và Holesky. Kể từ ACDE #177, Tim Beiko, trưởng nhóm hỗ trợ giao thức tại Quỹ Ethereum, đã đề xuất thời gian fork cho cả ba mạng thử nghiệm công khai của Ethereum: Goerli, Sepolia và Holesky. Thời điểm kích hoạt fork đề xuất như sau:
-
Goerli -- Ngày 17 tháng 1 năm 2024 -- Kỷ nguyên 231680 -- Mốc thời gian 1705473120
-
Sepolia -- Ngày 30 tháng 1 năm 2024 -- Kỷ nguyên 132608 -- Mốc thời gian 1706655072
-
Holesky -- Ngày 7 tháng 2 năm 2024 -- Kỷ nguyên 29696 — Mốc thời gian 1707305664
Lightclient hỏi các đội client khác ngoài Prysm có đồng ý với thời điểm kích hoạt hard fork Goerli mà Beiko đề xuất hay không. Tất cả các đội client tham gia cuộc gọi (bao gồm Geth, Lodestar, Lighthouse, Teku và Besu) đều xác nhận họ thấy thời điểm phù hợp và sẽ phát hành phiên bản cho các node operator Goerli muộn nhất vào tuần tới. Đội client Lighthouse lưu ý rằng do họ vẫn đang kiểm thử một số chức năng mạng của client, phiên bản phát hành của họ có thể cũng giống như Prysm, là phiên bản xem trước.
Bất đồng về lộ trình Dencun
Sau đó, Lightclient mở cuộc thảo luận về thời điểm kích hoạt đề xuất cho hai mạng thử nghiệm Sepolia và Holesky. Một nhà phát triển Prysm ẩn danh với biệt danh "Potuz" đề xuất tạm hoãn việc cam kết ngày nâng cấp cho hai mạng thử nghiệm cuối cùng trước mainnet. "Chúng ta nên cố gắng không cam kết ngày ngay lúc này, vì mọi chuyện ở Goerli có thể không diễn ra suôn sẻ, và việc quay lại từ đó là một vấn đề. Rất dễ dàng để thêm một phiên bản mới với kỷ nguyên đúng mà không cần thay đổi gì. Nhưng việc xóa một phiên bản và sửa lỗi thì lại là vấn đề lớn hơn nhiều so với vài tuần," Potuz nói.
Lightclient nhấn mạnh rằng các đội client chỉ cần phát hành phiên bản mới một tuần sau hard fork Goerli, do đó trừ khi gặp sự cố nâng cấp trên Goerli vào ngày 24 tháng 1 hoặc sau đó, nếu không sẽ không cần thiết phải hủy bỏ phiên bản mới. Marius van der Wijden, nhà phát triển Geth, cho rằng việc đặt ngày cho các mạng thử nghiệm Sepolia và Holesky không có hại gì, vì nếu có vấn đề xảy ra trên Goerli, các nhà phát triển luôn có thể thay đổi ngày.
Kỹ sư DevOps tại Quỹ Ethereum, Barnabas Busa, viết trong phòng chat Zoom rằng theo ông, chỉ khi nào xác nhận phiên bản Goerli hoạt động ổn định thì mới cần phát hành phiên bản mới cho nâng cấp Sepolia và Holesky. Một nhà phát triển Lighthouse với biệt danh "Sean" đồng tình với quan điểm này, nói rằng các nhà phát triển có thể đặt một ngày "tạm thời" cho hard fork Sepolia nhưng nên chờ xem tình hình Goerli trước ngày 30 tháng 1.
Potuz đề xuất tăng thêm một tuần thời gian kiểm thử giữa kích hoạt hard fork Goerli và Sepolia, cơ bản là kéo dài phân tích thành hai tuần thay vì ba tuần. Ông nói thêm rằng việc tăng một tuần kiểm thử sẽ cho phép các phiên bản client "ngâm mình" vài ngày trước khi các đội lại phải cắt phiên bản mới cho lần nâng cấp mạng thử nghiệm tiếp theo. "Hai tuần quá gần nhau. Đó là điều tôi muốn nói. Việc chờ đợi giữa Sepolia và Holesky không cần đến ba tuần nếu các bản phát hành client Goerli được phân tích và kiểm thử đầy đủ," Potuz bổ sung.
Quan điểm của Potuz gây tranh cãi. Ansgar Dietrichs thuộc Quỹ Ethereum cho rằng khoảng thời gian giữa kích hoạt mạng thử nghiệm công khai đầu tiên và kích hoạt mainnet thường là "thời hạn" cho các nhà phát triển và không cần kéo dài. Tuy nhiên, Dietrichs cũng lưu ý rằng mong muốn kéo dài khoảng cách giữa các lần nâng cấp mạng thử nghiệm nên được thảo luận nghiêm túc hơn trong bối cảnh hard fork chứ không chỉ riêng nâng cấp Dencun. Ông nói: "Nếu ai đó muốn một quá trình dài hơn, chúng ta nên thảo luận về điều đó khi có thời gian, chứ không phải ngay trước hard fork."
Lightclient đồng ý với Dietrichs rằng nếu cuộc thảo luận diễn ra sớm hơn, ví dụ từ tháng 10, các nhà phát triển có lẽ đã dễ tính hơn với việc kéo dài lịch trình mạng thử nghiệm Dencun. Lightclient nói: "Tôi nghĩ một phần cũng là vì chúng tôi muốn hoàn tất nâng cấp vào mùa thu năm ngoái, nên giờ đây chúng tôi đang nỗ lực rất nhiều để đạt được mục tiêu đó, và tôi cho rằng lịch trình của chúng ta nên tích cực hơn một chút."
Duy trì lịch trình tích cực
Dựa trên các quan điểm được chia sẻ trong cuộc gọi, kỹ sư DevOps Parithosh Jayanthi thuộc Quỹ Ethereum đề xuất lùi thời gian nâng cấp hard fork Sepolia khoảng một tuần và ấn định ngày hard fork Sepolia trong cuộc gọi ACDE ngày 25 tháng 1 sau khi nâng cấp Goerli. Marius van der Wijden phản đối việc hoàn toàn phụ thuộc vào cuộc gọi ACDE để thảo luận lại ngày kích hoạt nâng cấp mạng thử nghiệm. Ông nói: "Điều tôi thực sự muốn tránh là chúng ta phải tổ chức thêm một cuộc gọi All Core Devs nữa chỉ để xác nhận ngày," ông bổ sung: "Tôi ghét việc phải gọi thêm một cuộc gọi All Core Devs chỉ để nói 'Ừ thì, giờ Sepolia có thể bắt đầu'. Và giờ chúng ta phải đợi thêm hai tuần nữa mới thực sự bắt đầu triển khai Sepolia."
Để làm dịu căng thẳng, Guillaume Ballet, nhà phát triển Geth, đề xuất tạo hai bộ ngày tạm thời cho hard fork Sepolia: một bộ nếu kết quả hard fork Goerli tích cực, và bộ còn lại nếu tiêu cực. Tuy nhiên, cả Lightclient và Dietrichs đều phản đối ý tưởng này vì cần phải đánh giá bản chất lỗi và sự cố trên Goerli trước khi có thể thiết lập lại lịch trình cho hard fork Sepolia.
Nhân tiện, một nhà phát triển ẩn danh với biệt danh "Danceratopz" thuộc đội kiểm thử Quỹ Ethereum hỏi liệu các nhà phát triển có muốn đợi đánh giá vấn đề hết hạn blob trên mạng thử nghiệm Goerli trước khi nâng cấp Sepolia hay không. Về bối cảnh, "hết hạn blob" đề cập đến việc xóa dữ liệu blob khỏi trạng thái Ethereum sau khoảng hai tuần.
Cả Sean từ Lighthouse và Justin Florentine từ đội Besu đều ủng hộ việc đánh giá tình trạng hết hạn blob trên một trong ba mạng thử nghiệm trước khi kích hoạt Dencun trên mainnet. Florentine nhấn mạnh rằng việc chờ blob hết hạn trên mạng thử nghiệm cũng sẽ giúp ích cho các đội giao thức Rollup lớp 2 và các nhà phát triển ứng dụng chuẩn bị cho nâng cấp Dencun. Sean từ Lighthouse nói rằng mặc dù quan sát blob hết hạn trên Goerli không nhất thiết, nhưng đây có thể là lý do để kéo dài giai đoạn kiểm thử giữa Sepolia và Holesky, để các nhà phát triển và đội lớp 2 có thể trải nghiệm toàn bộ vòng đời blob trên Sepolia. Tuy nhiên, các nhà phát triển khác trong cuộc gọi không đồng thuận rõ ràng với đề xuất của Sean.
Thay vào đó, Lightclient hỏi các nhà phát triển trong cuộc gọi liệu họ có sẵn sàng duy trì lịch trình mà Beiko đề xuất: nâng cấp Sepolia vào ngày 30 tháng 1 và Holesky một tuần sau đó vào ngày 7 tháng 2 hay không. Vì không còn ý kiến trái chiều nào khác, Lightclient cho biết các nhà phát triển sẽ giữ nguyên lịch trình ban đầu. Potuz viết trong chat Zoom rằng ông hy vọng nâng cấp đồng thời cả hai mạng thử nghiệm Sepolia và Holesky vào ngày 7 tháng 2, thay vì nâng cấp Sepolia sớm hơn một tuần. Trong tin nhắn Discord sau cuộc gọi, Lightclient xác nhận lại rằng lịch trình mạng thử nghiệm Dencun tạm thời vẫn giữ nguyên.
Prague/Electra
Tiếp theo, các nhà phát triển thảo luận về việc ưu tiên EIP nào cho lần nâng cấp tiếp theo sau Dencun (Prague/Electra). Marius van der Wijden nói rằng các nhà phát triển nên tập trung hoàn tất nâng cấp Merkle Tree cho Prague/Electra thay vì các EIP khác. Ông bổ sung hai điểm lưu ý cho quan điểm này: thứ nhất là tình trạng sẵn sàng của Merkle Tree. Như đã thảo luận tại ACDE #177, các nhà phát triển dự định tổ chức một cuộc gọi ACDE chuyên sâu để thảo luận chi tiết việc triển khai Merkle Tree và sự chuẩn bị cho hard fork nâng cấp.
Điểm thứ hai mà Van der Wijden nhắc đến là khả năng tách biệt nâng cấp trên lớp thực thi (EL) khỏi lớp đồng thuận (CL). Ông nói rằng có một số EIP "ưu tiên cao, siêu khẩn cấp" trên CL có thể cần được triển khai nhanh hơn nâng cấp Merkle Tree trên EL. "Tôi nghĩ điều quan trọng là những người phụ trách CL cần thảo luận xem liệu họ có cần hard fork riêng cho những thay đổi khẩn cấp này hay không, liệu có thể hoàn tất mà không cần sự tham gia của EL, hay có cần EL tham gia, và dù sao đi nữa chúng ta cũng cần một hard fork kết hợp, khi đó tôi có thể chấp nhận một hard fork nhỏ hơn," van der Wijden nói. "Vì vậy, Merkle Tree chắc chắn là ưu tiên hàng đầu, và chúng ta nên thúc đẩy điều đó với hai điểm trên trong tâm trí."
Nhà nghiên cứu Ansgar Dietrichs thuộc Quỹ Ethereum viết trong chat Zoom rằng ông "mạnh mẽ phản đối" việc tập trung nâng cấp Prague/Electra vào Merkle Tree, vì xét đến độ phức tạp của các thay đổi mã cần thiết, điều này rất có thể khiến nâng cấp bị trì hoãn đến năm 2025. Lukasz Rozmej, nhà phát triển client Nethermind, cũng đồng tình với Dietrichs. Rozmej nói: "Kinh nghiệm của tôi cho thấy việc thiết kế lại trạng thái rất khó khăn và mất rất nhiều thời gian," ông bổ sung, "mặc dù tôi cho rằng Merkle Tree rất tuyệt vời và đang tiến triển mạnh mẽ, nhưng tôi nghĩ nếu chúng ta chỉ tập trung vào Merkle, lần hard fork tiếp theo sẽ mất ít nhất một năm hoặc lâu hơn. Vì vậy, tôi đề xuất có lẽ nên tập trung vào một số hard fork nhỏ hơn, đồng thời mỗi đội vẫn tiếp tục làm việc với Merkle và phân bổ nguồn lực, khối lượng công việc, trí tuệ thích hợp cho chủ đề này, bất kể bạn gọi nó là gì."
Tập trung vào Merkle
Các nhà phát triển bất đồng quan điểm về việc Prague/Electra nên tập trung vào Merkle hay ưu tiên các thay đổi mã nhỏ hơn có thể phát hành nhanh hơn Merkle. Ballet nhấn mạnh rằng theo ông, "không tồn tại hard fork nhỏ", và càng trì hoãn việc triển khai Merkle, thì việc cập nhật trạng thái Ethereum sẽ càng trở nên khó khăn hơn. Tomasz K. Stańczak, cũng là nhà phát triển client Nethermind, đề xuất một phương pháp tham vọng hơn, cam kết đưa vào nhiều EIP hơn so với những gì Prague/Electra có thể chứa. "[Hãy] tận dụng năng lực của các đội, trong năm nay, chúng ta phải chứng minh rằng chúng ta có thể đối mặt với thử thách lớn nhất. Nếu cuối cùng Merkle cho thấy ngày càng có nhiều khó khăn tích tụ đến tháng 3, thì có thể người ta sẽ đặt câu hỏi lại và nói 'được rồi, loại Merkle ra'. Nhưng chúng ta sẽ tiếp tục với một bộ EIP khác khá tốt mà chúng ta sẽ bao gồm," Stańczak nói, liệt kê thêm một số EIP quan trọng khác mà Prague/Electra có thể bao gồm ngoài Merkle, chẳng hạn như các EIP liên quan đến staking, restaking và abstract tài khoản.
Lightclient trả lời câu hỏi của Stańczak rằng các nhà phát triển có thể khó tiếp tục thảo luận về việc nên bao gồm EIP nào trong Prague/Electra sau khi đã cam kết với một bộ EIP, trong đó một EIP (chỉ Merkle) là "một dự án cần 18 đến 24 tháng". Andrew Ashikhmin, nhà phát triển client Erigon, ủng hộ việc phát hành các EIP nhỏ hơn trong phân nhánh Prague/Electra đồng thời phát triển Merkle để sử dụng trong các lần phân nhánh sau. Ballet ủng hộ đề xuất của Stańczak là tập trung phát triển Merkle trong Prague/Electra và nếu phát hiện có vấn đề lớn trong quá trình triển khai cần thêm thời gian, thì có thể loại nó ra khỏi nâng cấp.
Tập trung vào nâng cấp CL
Về việc tách biệt nâng cấp EL (lớp thực thi) và CL (lớp đồng thuận), Potuz nói rằng chỉ có một đề xuất EIP cho Prague/Electra yêu cầu thay đổi duy nhất trên CL. "Thay đổi duy nhất là loại bỏ ủy ban chỉ mục xác thực... và tất cả các thay đổi khác, kể cả những thay đổi dường như chỉ liên quan đến CL như Max EB, cũng đều phụ thuộc vào các thay đổi khác trên EL. Vì vậy, tôi nghĩ rằng một hard fork thuần CL sẽ không xảy ra. Ít nhất, tôi nghĩ năm nay không, năm sau cũng không. Chúng ta không có đủ đề xuất CL thuần túy," Potuz nói.
Tuy nhiên, Ansgar Dietrichs nói rằng có một số EIP chủ yếu tập trung vào nâng cấp CL và chỉ cần thay đổi nhỏ trên EL, mà các đội client EL có thể dễ dàng thực hiện. Những EIP này vẫn cần phối hợp hard fork giữa EL và CL. Sau đó, Dietrichs bổ sung rằng theo ông, từ phía CL, lấy mẫu khả năng sẵn sàng dữ liệu (DAS) là thay đổi mã quan trọng nhất sau EIP 4844. Dietrichs và Lightclient có một chút bất đồng về việc liệu DAS có cần một hard fork để triển khai hay không.
Tập trung vào EOF và các EIP khác
Một nhà phát triển ẩn danh với biệt danh "Rodiazet" làm việc trong đội Ipsilon thuộc Quỹ Ethereum, nhóm đang nghiên cứu Máy ảo Ethereum (EVM). Về bối cảnh, EOF là viết tắt của EVM Object Format, là một loạt cải tiến cho EVM, ban đầu được cân nhắc đưa vào nâng cấp Cancun/Deneb.
Ngoài Merkle, các nhà phát triển còn đề xuất một số EIP khác để xem xét, như EIP 5920 (mã vận hành PAY) và EIP 2537 (tiền biên dịch cho các thao tác đường cong BLS12-381). Danh sách đầy đủ các EIP ứng cử viên cho Prague/Electra có thể tìm thấy trong chủ đề meta trên website Ethereum Magicians. Mặc dù phần lớn các nhà phát triển đồng ý rằng nên ưu tiên Merkle ở mức độ nào đó sau hội nghị Cancun/Deneb, nhưng hiện tại chưa rõ mức độ Merkle nên được ưu tiên cho Prague/Electra thay vì các EIP nhỏ hơn có thể triển khai nhanh và dễ dàng hơn trong năm 2024. Lightclient nhấn mạnh rằng các nhà phát triển không cần phải đưa ra quyết định cuối cùng về nội dung Prague/Electra trong cuộc gọi tuần này. Ông đề xuất tiếp tục thảo luận chủ đề này trong các cuộc gọi ACDE sắp tới.
Sau đó, các nhà phát triển nhanh chóng đề cập đến các EIP trong chủ đề Prague/Electra chưa được thảo luận trong cuộc gọi, bao gồm nhưng không giới hạn ở:
-
EIP-7002: Thoát khỏi lớp thực thi có thể kích hoạt
-
EIP-7549: Di chuyển chỉ mục ủy ban ra ngoài xác thực
-
EIP-3074: Mã vận hành AUTH và AUTHCALL
-
EIP-6110: Cung cấp khoản gửi validator trên chuỗi
-
EIP-6913: Lệnh SETCODE
-
EIP-7377: Di chuyển giao dịch
-
EIP-4444: Giới hạn dữ liệu lịch sử trong client thực thi
-
EIP-6404: Gốc giao dịch SSZ
-
EIP-6465: Gốc rút tiền SSZ
-
EIP-6466: Gốc biên lai SSZ
-
EIP-7212: Hỗ trợ đường cong secp256r1 tiền biên dịch
Để xem tổng quan chi tiết về các quan điểm liên quan đến các EIP trên, vui lòng tham khảo bản ghi âm đầy đủ của cuộc gọi được đăng tải trên YouTube.
Chính thức hóa EIP 7587
Cuối cùng, nhà nghiên cứu Carl Beekhuizen thuộc Quỹ Ethereum tái khởi động cuộc thảo luận về EIP 7587, đề xuất bảo lưu một nhóm địa chỉ tiền biên dịch để các giao thức lớp 2 sử dụng. Beekhuizen hỏi các nhà phát triển cách tốt nhất để chính thức hóa EIP này thành một EIP thông tin, nhằm thiết lập quy chuẩn cho quy trình quản trị Ethereum trong tương lai. Ahmad Bitar, nhà phát triển Nethermind, đề xuất đưa EIP vào file EIP 1, tài liệu mô tả hướng dẫn quy trình EIP. Lightclient đề xuất tiếp tục thảo luận chủ đề này trên trang web Ethereum Magicians và đưa lại vấn đề này vào cuộc gọi ACDE tiếp theo nếu cần.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@galaxyhq
