Đánh giá hội nghị nhà phát triển Ethereum: Nâng cấp Cancun, Hard Fork và Praha

Tác giả: Christine Kim, Phó Chủ tịch Nghiên cứu của Galaxy;Tổng hợp: Giá trị chuỗi carbon Qin Jin

Vào ngày 4 tháng 1 năm 2024, các nhà phát triển Ethereum đã tập trung tại Zoom for All Core Developers Execution ( ACDE ) theo Cuộc gọi số 178. Cuộc gọi ACDE, thường được tổ chức bởi người đứng đầu giao thức Ethereum Foundation, Tim Beiko, là một chuỗi cuộc họp hai tuần một lần, 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 thực thi Ethereum (EL). Cuộc họp tuần này được tổ chức bởi một nhà phát triển Geth EL ẩn danh, người có tên trên màn hình là “Lightclient”. Các nhà phát triển đã xác nhận lại ba ngày kích hoạt testnet công khai tiếp theo cho bản nâng cấp Cancun/Deneb (Dencun). Họ cũng thảo luận về các ưu tiên cho việc thay đổi mã (EIP) ở Praha/Electra, bản nâng cấp hard fork tiếp theo sau Dencun.

Cập nhật Dencun

Sẽ không có nâng cấp Dencun trong thời gian này những ngày nghỉ Cập nhật cụ thể. Kể từ cuộc gọi hội nghị ACDE gần đây nhất vào ngày 21 tháng 12, nhóm khách hàng đã chuẩn bị một phiên bản mới cho mạng thử nghiệm Goerli. Do sự chậm trễ trước đó trong quá trình thử nghiệm nâng cấp do Prysm, nhà phát triển Geth Marius van der Wijden đã yêu cầu nhóm khách hàng Prysm cung cấp thông tin cập nhật về tiến trình cắt giảm phiên bản mới của họ. Nhà phát triển Prysm Terence Tsao xác nhận rằng nhóm Prysm sẽ chuẩn bị một phiên bản mới của 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 "tiền phát hành", có nghĩa là nó sẽ không phải là phiên bản Prysm được khuyến nghị sử dụng trên mạng chính Ethereum. Sau hard fork Goerli, nhóm Prysm có kế hoạch phát hành một phiên bản khác với một số thay đổi và cập nhật nhất định, người dùng được khuyến nghị chạy trên mạng chính và thử nghiệm trên mạng thử nghiệm Sepolia hoặc Holesky.

Trong khi Tsao tuyên bố rằng nhóm Prysm cảm thấy thoải mái với ngày kích hoạt hard fork Goerli là ngày 17 tháng 1, như đã thảo luận trên ACDE #177, anh ấy gợi ý rằng Ngày kích hoạt đối với hard fork Sepolia và Holesky sẽ được xác định sau hard fork Goerli. Kể từ ACDE #177, Tim Beiko, người đứng đầu bộ phận hỗ trợ giao thức tại Ethereum Foundation, đã đề xuất thời gian phân tách mạng thử nghiệm công khai cho ba mạng thử nghiệm công khai Ethereum: Goerli, Sepolia và Holesky. Thời gian kích hoạt fork được đề xuất như sau:

Goerli--17 tháng 1 năm 2024--Kỷ nguyên 231680--Dấu thời gian 1705473120

Sepolia--30 tháng 1 năm 2024--Kỷ nguyên 132608--Dấu thời gian 1706655072

Holesky--Ngày 7 tháng 2 năm 2024--Kỷ nguyên 29696—Dấu thời gian 1707305664

Lightclient đã hỏi các nhóm khách hàng khác ngoài Prysm nếu họ đồng ý với thời gian kích hoạt đề xuất của Beiko cho hard fork Goerli. Tất cả các nhóm khách hàng tham gia cuộc gọi (bao gồm Geth, Lodestar, Lighthouse, Teku và Besu) đều xác nhận rằng họ cảm thấy đây là thời điểm thích hợp để có bản phát hành cho các nhà khai thác nút Goerli muộn nhất vào tuần tới. Nhóm khách hàng của Lighthouse lưu ý rằng họ vẫn đang thử nghiệm một số tính năng mạng của khách hàng nên phiên bản họ phát hành có thể là phiên bản tiền phát hành như Prysm.

Sự phân kỳ dòng thời gian của Dencun

Sau đó, Lightclient thảo luận về Sepolia Thảo luận thời gian kích hoạt được đề xuất cho mạng thử nghiệm Holesky. Một nhà phát triển Prysm (bút danh) có tên trực tuyến "Potuz" đã đề xuất trì hoãn việc xác định ngày nâng cấp cho hai mạng thử nghiệm cuối cùng trước mạng chính. "Chúng ta nên cố gắng không cam kết về một ngày nào đó ngay bây giờ vì mọi thứ có thể không suôn sẻ với Goerli và việc quay trở lại từ đó sẽ có vấn đề. Sẽ rất dễ dàng để thêm một phiên bản mới với đúng thời đại và không thực hiện thay đổi nào. Sẽ dễ dàng hơn." để xóa một phiên bản và sửa lỗi. Đó là một vấn đề. Nó kéo dài hơn một vài tuần", Potuz nói.

Lightclient nhấn mạnh rằng nhóm khách hàng không cần phải phát hành phiên bản mới cho đến một tuần sau đợt hard fork Goerli, vì vậy trừ khi nó diễn ra trên Goerli vào ngày 24 tháng 1 hoặc sau này các vấn đề nâng cấp được tìm thấy, nếu không phiên bản mới sẽ không nhất thiết bị xóa. Nhà phát triển Geth, Marius van der Wijden, nói rằng ông thấy không có hại gì trong việc ấn định ngày cho các mạng thử nghiệm Sepolia và Holesky, vì các nhà phát triển có thể thay đổi ngày bất kỳ lúc nào nếu có vấn đề phát sinh trên Goerli.

Barnabas Busa, kỹ sư DevOps tại Ethereum Foundation, đã viết trong phòng trò chuyện Zoom rằng theo quan điểm của ông, chỉ sau khi xác nhận Sau khi phiên bản của Goerli chạy bình thường thì mới có thể cần thiết để phát hành phiên bản mới để nâng cấp Sepolia và Holesky. Một nhà phát triển của Lighthouse có tên trực tuyến là "Sean" đã đồng ý, nói rằng các nhà phát triển có thể ấn định ngày "dự kiến" cho hard fork Sepolia, nhưng trước tiên phải xem tiến trình của Goerli trước ngày 30 tháng 1. Điều kiện.

Potuz khuyên bạn nên thêm một tuần thử nghiệm giữa các lần kích hoạt hard fork Goerli và Sepolia, về cơ bản là sử dụng hai tuần để phân tích thay vì ba tuần. Ông cho biết việc thêm một tuần thời gian thử nghiệm sẽ cho phép bản phát hành của khách hàng "ngâm" trong vài ngày trước khi nhóm khách hàng cần cắt lại phiên bản mới cho lần nâng cấp testnet tiếp theo. "Hai tuần là quá gần. Đó là những gì tôi đang chỉ ra." Potuz nói thêm rằng nếu bản phân phối máy khách Goerli được phân tích và kiểm tra đầy đủ, có thể không mất đến ba ngày kể từ khi kích hoạt hard fork Sepolia và Holesky.

Quan điểm của Potuz đã gây ra tranh cãi. Ansgar Dietrichs của Ethereum Foundation cho biết khoảng thời gian từ khi kích hoạt testnet công khai đầu tiên của bản nâng cấp đến khi kích hoạt mainnet được nâng cấp thường là “thời hạn” để các nhà phát triển cần được gia hạn. Tuy nhiên, Dietrichs cũng chỉ ra rằng các nhà phát triển nên thảo luận về mong muốn kéo dài khoảng thời gian giữa các lần nâng cấp testnet một cách nghiêm túc hơn trong bối cảnh hard fork, không chỉ riêng bản nâng cấp Dencun. Dietrichs nói: "Nếu ai đó muốn một quá trình dài hơn thì chúng ta nên thảo luận vấn đề này khi có thời gian, không phải trước khi hard fork."

Lightclient đồng ý với Dietrichs và tin rằng nếu các cuộc thảo luận được tổ chức sớm nhất là vào tháng 10, các nhà phát triển có thể sẽ khoan dung hơn trong việc kéo dài lịch trình mạng thử nghiệm của Dencun. Lightclient cho biết: Tôi nghĩ một phần là do chúng tôi muốn hoàn thành nâng cấp vào mùa thu năm ngoái, vì vậy bây giờ chúng tôi đang thực sự cố gắng đạt được mục tiêu đó, tôi nghĩ dòng thời gian của chúng tôi nên tích cực hơn một chút.

Tuân thủ lịch trình tích cực

Theo ý kiến ​​của nhà phát triển Theo quan điểm được chia sẻ trong cuộc gọi hội nghị, kỹ sư Parithosh Jayanthi của Ethereum Foundation đã đề xuất trì hoãn việc nâng cấp hard fork Sepolia khoảng một tuần và ấn định ngày diễn ra hard fork Sepolia tại cuộc gọi hội nghị ACDE vào ngày 25 tháng 1 sau khi nâng cấp Goerli. Marius van der Wijden phản đối việc dựa hoàn toàn vào lệnh gọi ACDE để đàm phán lại ngày kích hoạt nâng cấp testnet. “Điều tôi thực sự muốn tránh là chúng tôi phải thực hiện một cuộc gọi khác cho All Core Devs để xác nhận ngày,” anh ấy nói và nói thêm: Tôi ghét phải thực hiện một cuộc gọi khác cho All Core Devs chỉ để nói, 'OK, Sepolia hiện đã sẵn sàng. Mọi chuyện đã bắt đầu.” Bây giờ chúng tôi phải đợi hai tuần trước khi có thể thực sự bắt đầu triển khai Sepolia.

Để xoa dịu cảm xúc của tất cả các bên, nhà phát triển Guillaume Ballet của Geth đã đề xuất tạo hai nhóm ngày dự kiến ​​cho hard fork Sepolia, nếu kết quả của hard fork Goerli be Nếu kết quả của hard fork Goerli là âm, các nhà phát triển có thể giữ nguyên một nhóm ngày; nếu kết quả của hard fork Goerli là âm, các nhà phát triển có thể giữ một nhóm ngày khác. Tuy nhiên, cả Lightclient và Dietrichs đều phản đối ý tưởng này vì bản chất của các lỗi và vấn đề trên Goerli phải được đánh giá trước khi các nhà phát triển có thể đặt ra mốc thời gian mới cho hard fork Sepolia.

Nhân tiện, một nhà phát triển có bút danh "Danceratopz" trong nhóm thử nghiệm Ethereum Foundation đã hỏi liệu nhà phát triển có muốn đợi cho đến khi Goerli được đánh giá hay không. các vấn đề trên mạng trước khi nâng cấp Sepolia. Về cơ bản, 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.

Sean từ Lighthouse và Justin Florentine từ nhóm Besu đều ưu tiên đánh giá thời gian hết hạn của blob trên một trong ba mạng thử nghiệm trước khi kích hoạt Dencun trên mạng chính. Florentine nhấn mạnh rằng việc chờ đợi blob hết hạn trên testnet cũng sẽ giúp nhóm giao thức Rollup lớp thứ hai và các nhà phát triển ứng dụng chuẩn bị cho bản nâng cấp Dencun. Sean từ Lighthouse cho biết rằng mặc dù việc quan sát thời gian hết hạn của blob trên Goerli là không cần thiết nhưng đó có thể là lý do để kéo dài thời gian thử nghiệm giữa Sepolia và Holesky để các nhà phát triển và nhóm cấp hai có thể trải qua toàn bộ vòng đời của blob trên Sepolia. Các nhà phát triển khác trong cuộc gọi không đồng ý 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 hội nghị rằng liệu họ có tuân thủ lịch trình nâng cấp Sepolia do Beiko đề xuất vào ngày 30 tháng 1 hay không, sau đó một tuần là Nâng cấp Holesky vào ngày 7 tháng 2 trên cơ sở hàng ngày. Vì không còn bất đồng nào giữa các nhà phát triển, Lightclient cho biết các nhà phát triển sẽ bám sát lịch trình ban đầu. Potuz đã viết trong một cuộc trò chuyện trên Zoom rằng anh ấy hy vọng sẽ nâng cấp cả mạng thử nghiệm Sepolia và Holesky vào ngày 7 tháng 2, thay vì nâng cấp mạng trước đó 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 testnet của Dencun vẫn không thay đổi trong thời điểm hiện tại.

Prague/Electra

Tiếp theo, các nhà phát triển thảo luận về EIP nào nên ưu tiên nâng cấp tiếp theo (Prague/Electra) sau khi cài đặt Dencun. Marius van der Wijden cho biết các nhà phát triển nên tập trung vào việc hoàn thành nâng cấp cây Merkle của Praha/Electra thay vì các EIP khác. Ông bổ sung thêm hai lưu ý cho quan điểm này, đầu tiên là sự sẵn sàng của cây Merkel. Như đã thảo luận trên ACDE #177, các nhà phát triển đang lên kế hoạch cho một cuộc gọi ACDE chuyên dụng để đi sâu vào chi tiết triển khai của cây Merkle và mức độ sẵn sàng của nó để nâng cấp hard fork.

Sự cân nhắc thứ hai được Van der Wijden đề cập là khả năng tách các bản nâng cấp trên EL khỏi lớp đồng thuận (CL). Van der Wijden đã đề cập rằng có một số EIP "có mức độ ưu tiên cao, siêu khẩn cấp" trên CL có thể cần được triển khai nhanh hơn bản nâng cấp cây Merkle trên EL. “Tôi nghĩ điều quan trọng là mọi người trong lớp đồng thuận phải thảo luận xem liệu họ có cần hard fork những thay đổi [khẩn cấp] này hay không, liệu nó có thể được thực hiện mà không cần sự tham gia của EL hay không, hay liệu có cần sự tham gia của EL hay không, dù sao thì chúng ta cũng cần thực hiện một hard fork chung và sau đó Tôi có thể sống với một chiếc hard fork nhỏ hơn.” van der Wijden cho biết: “Vì vậy, cây Merkle chắc chắn là ưu tiên hàng đầu và chúng ta nên thúc đẩy nó dựa trên hai điểm này”.

Nhà nghiên cứu Ansgar của Ethereum Foundation Dietrichs đã viết trong phòng trò chuyện Zoom rằng ông "phản đối mạnh mẽ" việc tập trung nâng cấp Praha/Electra vào cây Merkel vì lo ngại về cây Merkle. Sự phức tạp của những thay đổi mã cần thiết cho cây Kerr có thể có nghĩa là việc nâng cấp sẽ bị trì hoãn đến năm 2025. Nhà phát triển khách hàng Nethermind Lukasz Rozmej đồng ý với Dietrichs. Rozmej nói: “Kinh nghiệm của tôi cho tôi biết rằng việc thiết kế lại nhà nước là rất khó khăn và mất nhiều thời gian. Trong khi tôi nghĩ cây Merkle rất tốt và đang đạt được tiến bộ lớn, tôi nghĩ nếu chúng ta chỉ tập trung vào Merkel, hard fork tiếp theo sẽ còn ít nhất một năm nữa, nếu không muốn nói là lâu hơn. Vì vậy, gợi ý của tôi là có thể tập trung vào một số hard fork nhỏ hơn trong khi mỗi nhóm làm việc với Merkel và phân bổ các nguồn lực, khối lượng công việc, trí tuệ phù hợp, bất kể bạn muốn gọi nó là gì, về chủ đề này."

Tập trung vào Merkel

Các nhà phát triển không đồng tình về việc Praha/Electra nên tập trung vào Merkel hay ưu tiên những thay đổi quy tắc nhỏ hơn có thể được ban hành nhanh hơn thay đổi của Merkel. Ballet nhấn mạnh rằng theo quan điểm của ông, “không có phân nhánh nhỏ” và các nhà phát triển càng chờ đợi lâu trước khi triển khai Merkle thì việc triển khai các bản cập nhật trạng thái Ethereum càng khó khăn hơn. Tomasz K. Stańczak, cũng là nhà phát triển ứng dụng khách Nethermind, đã đề xuất một cách tiếp cận đầy tham vọng, cam kết với nhiều EIP hơn mức mà Praha/Electra có thể đưa vào. [Hãy] tận dụng khả năng của nhóm chúng tôi và trong năm nay, chúng tôi phải chứng minh rằng chúng tôi có thể giải quyết những thách thức lớn nhất của mình. Nếu cuối cùng bà Merkel ra hiệu cho nhóm rằng ngày càng có nhiều khó khăn chồng chất vào tháng 3, thì mọi người có thể lại đặt câu hỏi và nói "Được rồi, bà Merkel đã ra ngoài". Nhưng chúng tôi sẽ tiếp tục sử dụng một bộ EIP khá tốt khác mà chúng tôi sẽ đưa vào, Stańczak nói, đồng thời chỉ rõ rằng ngoài Merkel, một số EIP quan trọng khác mà Praha/Electr có thể bao gồm, chẳng hạn như những EIP liên quan đến đặt cược, đặt cược lại và EIP liên quan đến việc trừu tượng hóa tài khoản.

Trả lời câu hỏi của Stańczak, Lightclien nói rằng sau khi các nhà phát triển đã cam kết với một bộ EIP, có thể khó tiếp tục thảo luận về những EIP nào nên được đưa vào Praha /Electra.Một trong những EIP (ám chỉ Merkel) là "một dự án sẽ mất từ ​​​​18 đến 24 tháng". Andrew Ashikhmin, nhà phát triển ứng dụng khách Erigon, đã ưu tiên phát hành EIP nhỏ hơn trong nhánh Praha/Electra trong khi phát triển Merkle để sử dụng trong các nhánh tiếp theo. Ballet tán thành đề xuất của Stańczak là tập trung phát triển Merkel ở Praha/Electra và loại bỏ nó khỏi quá trình nâng cấp nếu phát hiện thấy các vấn đề lớn trong quá trình thực hiện cần thêm thời gian để giải quyết.

Tập trung vào nâng cấp CL

Giới thiệu về EL (lớp thực thi ) và vấn đề tách rời nâng cấp CL (lớp đồng thuận), Potuz đã đề cập rằng Praha/Electra chỉ có một đề xuất EIP chỉ yêu cầu thay đổi CL. "Thay đổi duy nhất là việc loại bỏ Hội đồng Chỉ số Chứng nhận...và tất cả những thay đổi khác, ngay cả những thay đổi dường như chỉ liên quan đến CL, như Max EB, đều phụ thuộc vào những thay đổi khác trong EL. Vì vậy, tôi nghĩ thuần túy là một nhánh CL là sẽ không xảy ra. Ít nhất, tôi không nghĩ điều đó sẽ xảy ra trong năm nay chứ không phải năm sau. Chúng tôi không có đủ đề xuất CL thuần túy,” Potuz nói.

Mặc dù vậy, Ansgar Dietrichs cho biết một số EIP chủ yếu là các bản nâng cấp tập trung vào CL chỉ yêu cầu những thay đổi nhỏ đối với EL và nhóm khách hàng EL có thể thực hiện dễ dàng. Các EIP này vẫn yêu cầu EL và CL để phối hợp hard fork. Dietrichs sau đó nói thêm rằng ông tin rằng Lấy mẫu sẵn có dữ liệu (DAS) là thay đổi mã quan trọng nhất sau EIP 4844 từ góc độ CL. Dietrichs và Lightclient có một số bất đồng về việc liệu DAS có yêu cầu triển khai hard fork hay không.

Theo dõi EOF và các EIP khác

Tên mạng A nhà phát triển với bút danh "Rodiazet" làm việc trong nhóm Ipsilon của Ethereum Foundation, chuyên nghiên cứu về Máy ảo Ethereum (EVM). Về cơ bản, EOF là tên viết tắt của Định dạng đối tượng EVM, một loạt cải tiến cho EVM ban đầu được xem xét đưa vào bản nâng cấp Cancun/Deneb.

Ngoài Merkel, các nhà phát triển cũng đề xuất một số EIP khác để xem xét, chẳng hạn như EIP 5920 (PAY opcode) và EIP 2537 (hoạt động đường cong BLS12-381 được biên dịch trước ). Bạn có thể tìm thấy danh sách đầy đủ các EIP ứng cử viên Praha/Electra trong chuỗi meta nâng cấp trên trang web Ethereum Magician. Mặc dù hầu hết các nhà phát triển đều ủng hộ việc ưu tiên Merkel ở một mức độ nào đó sau Cancun/Deneb, nhưng vẫn chưa rõ ở mức độ nào thì Merkel nên được ưu tiên cho Praha/Electra so với những EIP nhỏ vào năm 2024 để có thể triển khai nhanh hơn và dễ dàng hơn. Lightclient nhấn mạnh rằng các nhà phát triển không cần đưa ra quyết định cuối cùng về nội dung Praha/Electra trong cuộc gọi hội nghị tuần này. Ông đề nghị tiếp tục thảo luận về chủ đề này trong cuộc gọi hội nghị ACDE sắp tới.

Sau đó, các nhà phát triển đã nhanh chóng nói về các EIP trong chủ đề Praha/Electra vẫn chưa được thảo luận trong cuộc gọi, bao gồm nhưng không giới hạn ở các EIP sau:< /p>< p style="text-align: left;">EIP-7002: Lớp thực thi có thể kích hoạt thoát

< strong>EIP- 7549: Di chuyển chỉ mục ủy ban ra ngoài chứng nhận

EIP-3074: mã hoạt động AUTH và AUTHCALL

EIP-6110: Cung cấp tiền gửi cho người xác thực trên chuỗi

< strong>EIP-6913: Hướng dẫn SETCODE

EIP-7377: Giao dịch di chuyển

EIP-4444: Liên kết dữ liệu lịch sử trong ứng dụng thực thi

EIP -6404: Gốc giao dịch SSZ

EIP-6465: Gốc trích xuất SSZ

EIP-6466: Gốc biên nhận SSZ

EIP-7212: Biên dịch trước Hỗ trợ đường cong secp256r1

Để biết tổng quan chi tiết về số lượt xem trên EIP ở trên, vui lòng xem bản ghi cuộc gọi đầy đủ được đăng trên YouTube.

EIP 7587 chính thức được xác nhận

Cuối cùng, Ethereum Nhà nghiên cứu của Fund Society, Carl Beekhuizen đã khôi phục các cuộc thảo luận về EIP 7587, dự kiến ​​sẽ dành một tập hợp các địa chỉ được biên dịch trước để sử dụng cho các giao thức lớp 2. Beekhuizen đã hỏi các nhà phát triển cách tốt nhất để chính thức hóa EIP thành EIP thông tin nhằm tạo ra các tiêu chuẩn cho quy trình quản trị Ethereum trong tương lai. Nhà phát triển Nethermind Ahmad Bitar đã đề xuất kết hợp EIP vào tài liệu EIP 1, trong đó nêu ra các hướng dẫn cho quy trình EIP. Lightclient khuyên bạn nên thảo luận thêm về chủ đề này trên trang web Ethereum Magician và xem lại nó nếu cần trong cuộc gọi ACDE tiếp theo.