Khám phá các nâng cấp của Ethereum: Hegotá

Những gì Ethlabs đang ưu tiên cho Hegotá và lý do.

Hướng đi của Ethereum rất quan trọng đối với tất cả những ai xây dựng trên nó, sử dụng nó, nắm giữ ETH, hoặc đơn giản là tin tưởng vào những gì nó có thể trở thành. Trong khi tương lai đó cuối cùng sẽ được quyết định bởi người dùng, ứng dụng và cộng đồng đang xây dựng trên Ethereum mỗi ngày, các bản nâng cấp mạng lưới là một trong những cách chính mà giao thức phát triển để đáp ứng nhu cầu của họ. Hegotá là bản nâng cấp mạng lưới Ethereum tiếp theo sau Glamsterdam, và tài liệu này chia sẻ quan điểm của Ethlabs về những gì chúng tôi tin rằng Ethereum nên ưu tiên cho nó, và lý do.

Ethlabs là một phòng thí nghiệm R&D phi lợi nhuận dành cho Ethereum và ETH mới thành lập được 8 tuần, với sứ mệnh biến Ethereum thành lớp thanh toán của nền kinh tế toàn cầu. Chúng tôi đứng giữa việc sử dụng Ethereum trong thế giới thực và sự phát triển giao thức, và chúng tôi dành thời gian lắng nghe người dùng, ví, ứng dụng, rollup, tổ chức, người nắm giữ ETH, nhà nghiên cứu và các nhóm client. Đôi khi chúng tôi thậm chí còn xây dựng onchain, bởi vì bạn không thể xây dựng một đấu trường nếu không tham gia vào nó! Chúng tôi tin rằng kỹ thuật giao thức tuyệt vời sẽ giúp tạo ra những sản phẩm tuyệt vời, và những sản phẩm tuyệt vời sẽ giúp định hướng cho giao thức trong tương lai.

Phạm vi của Hegotá hiện đang trong giai đoạn đầu được định hình thông qua quy trình kỹ thuật mở của Ethereum, và các đề xuất dưới đây phản ánh công việc của nhiều cá nhân cũng như các nhóm nghiên cứu và client. Tài liệu này là một bản tường trình minh bạch về những gì chúng tôi khuyến nghị ưu tiên và những quan điểm mà chúng tôi vẫn đang hình thành. Đây là những lập trường mà chúng tôi rất mong muốn người khác đánh giá, thách thức và giúp cải thiện, và chúng tôi sẽ tiếp tục hoàn thiện chúng khi thảo luận và tìm hiểu thêm trong những ngày và tuần tới.

Đối với bản nâng cấp Hegotá, xét tất cả các EIP được đề xuất, đây là những lĩnh vực chúng tôi coi là ưu tiên cao nhất cho Ethereum:

1. Tăng cường khả năng chống kiểm duyệt: Bất kỳ ai cũng có thể thực hiện một giao dịch, bất kể họ là ai hay sử dụng Ethereum cho mục đích gì.
2. Ethereum nhanh hơn: Các block nhanh hơn đồng nghĩa với xác nhận nhanh hơn, giá onchain mới hơn và tính cuối cùng nhanh hơn.
3. Trừu tượng hóa tài khoản gốc: Các tài khoản nên hỗ trợ passkey, giao dịch được tài trợ, thanh toán gas bằng token, xử lý theo lô và quyền riêng tư mạnh mẽ hơn, với lộ trình hướng tới các khóa hậu lượng tử.
4. Tiếp tục mở rộng L1: Các ứng dụng cần dung lượng luôn phải chăng và có thể dự đoán được, ngay cả khi nhu cầu tăng đột biến.

Làm việc một cách công khai là mục tiêu cốt lõi của Ethlabs, đó là lý do tại sao chúng tôi viết cập nhật hàng tuần và, trong những dịp như thế này, đăng những bài viết kỹ thuật rất dài để chia sẻ suy nghĩ của mình 😅. Chúng tôi cũng sẽ đăng nhiều nội dung ngắn gọn hơn trong những tuần tới dành cho những ai chỉ muốn xem những điểm chính. Phần tiếp theo sẽ dài và mang tính kỹ thuật. Đối với những ai đọc hết, chúc bạn may mắn!

Đầu tiên: Quy trình EIP thực sự hoạt động như thế nào?

Trước khi đi sâu vào các đề xuất, có một điểm quan trọng: giai đoạn thứ hai của quy trình xác định phạm vi cho Hegotá vừa mới bắt đầu. Giai đoạn đầu tiên đã chọn FOCIL làm điểm nhấn chính của Hegotá. Vào ngày 6 tháng 8, có một hạn chót để đề xuất các EIP không phải là điểm nhấn chính, và quy trình ACD hiện sẽ chuyển sang đánh giá toàn bộ bản nâng cấp Hegotá.

Tất cả các EIP dưới đây hiện đang ở giai đoạn PFI (Được đề xuất để đưa vào), ngoại trừ các EIP đã trải qua quy trình điểm nhấn chính. Việc đề xuất một EIP để đưa vào là không cần cấp phép và hầu hết không bao giờ lọt vào bản nâng cấp cuối cùng.

Cụ thể, khi công việc triển khai tiến triển, các đề xuất sẽ di chuyển qua các giai đoạn đánh giá và mức độ tin cậy ngày càng mạnh mẽ hơn về khả năng cuối cùng được phát hành:

• PFI (Được đề xuất để đưa vào): một ý tưởng đã được đề xuất cho bản nâng cấp. Giai đoạn này không cần cấp phép và không ngụ ý sự hỗ trợ của client hoặc việc cuối cùng được đưa vào.
• CFI (Được xem xét để đưa vào): các nhóm client đã xem xét đề xuất và có ý định xây dựng nguyên mẫu và thử nghiệm nó.
• SFI (Được lên lịch để đưa vào): có ý định rộng rãi để đưa nó vào, với giả định rằng việc triển khai và thử nghiệm tiếp tục diễn ra tốt đẹp.

Để tìm hiểu thêm về cách quy trình này hoạt động, chúng tôi khuyên bạn nên xem phần giải thích nhanh của Tim Beiko tại đây.

Hướng dẫn: Cách điều hướng bài viết này

Chúng tôi tuân theo phân loại theo bậc của Forkcast để thể hiện quan điểm của mình về mức độ ưu tiên của các EIP cho Hegotá. Để giảm thiểu quyết định, chúng tôi phân loại tất cả các EIP đã xem xét thành bốn bậc với các diễn giải sau:

• [Bậc S] đặc biệt khuyến nghị đưa vào.
• [Bậc A] khuyến nghị đưa vào nếu các rào cản còn lại như độ phức tạp triển khai, phân tích tác động hoặc mức độ chấp nhận được giải quyết.
• [Bậc B] đáng giá, nhưng hơi quá sức cho bản nâng cấp này.
• [Bậc D] không khuyến nghị đưa vào Hegotá ở dạng hiện tại.
• [đang hình thành quan điểm] chúng tôi vẫn đang hình thành quan điểm về EIP này.

Xin lưu ý rằng đây là các khuyến nghị của Ethlabs. Chúng tôi đánh giá từng đề xuất chủ yếu dựa trên mục đích, đặc tả kỹ thuật và hiểu biết của chúng tôi về độ phức tạp triển khai hợp lý, ngoại trừ những trường hợp chúng tôi có sự chắc chắn hơn hoặc tham gia trực tiếp (ví dụ: Frames và Quick Slots), và sẽ cập nhật quan điểm của mình dựa trên các đánh giá từ ethPandaOps, các nhóm thử nghiệm và client khi chúng tôi tiến triển trong quy trình.

[CL] có nghĩa là một EIP ảnh hưởng đến các client lớp đồng thuận và [EL] có nghĩa là nó ảnh hưởng đến các client lớp thực thi.

Lưu ý rằng chúng tôi là đồng tác giả và tham gia vào một số EIP (bao gồm FOCIL, Frame Transactions và Quick Slots). Mặc dù chúng tôi cố gắng đánh giá tất cả các EIP một cách độc lập với sự tham gia hay không của mình, nhưng hãy cân nhắc điều này khi đánh giá lập trường của chúng tôi.

Tóm tắt

Xếp hạng CL

Bạn có thể thử nghiệm với [CL] xếp hạng cụ thể này trên Forkcaster tại đây.

Xếp hạng EL

Bạn có thể thử nghiệm với [EL] xếp hạng cụ thể này trên Forkcaster tại đây.

Bây giờ, không dài dòng nữa, đây là quan điểm của chúng tôi về bản nâng cấp Hegotá như hiện tại, một cách toàn diện:

Các chủ đề cho Hegotá

0. FOCIL: Tăng cường khả năng chống kiểm duyệt

EIP-7805: FOCIL đã được SFI và xác nhận là điểm nhấn chính của Hegotá. Ba thành viên của nhóm Ethlabs (Francesco, Barnabé và Julian) nằm trong số các đồng tác giả của nó, và chúng tôi hoàn toàn ủng hộ việc đưa nó vào. Vì quyết định đã được chốt, chúng tôi sẽ giữ phần này ngắn gọn. Chỉ có một chuỗi trung lập với tất cả mọi người mới có thể trở thành gốc rễ của sự tin cậy cho tất cả mọi người. Đây là điều cho phép Ethereum mở rộng quy mô để trở thành lớp thanh toán thực sự cho nền kinh tế toàn cầu và cho mọi cá nhân trong đó.

1. Quick Slots: Ethereum nhanh hơn

Slot 12 giây của Ethereum là một chi phí về độ trễ làm giảm giá trị của người dùng. Do đó, chúng tôi đặc biệt khuyến nghị đưa [CL] EIP-8198: Quick Slots [Bậc S] vào Hegotá, vì bốn lý do:

1. Cải thiện trải nghiệm người dùng trên L1 với xác nhận giao dịch nhanh hơn.
2. Các thị trường onchain trên L1 hoạt động với giá mới hơn, cải thiện chênh lệch giá và kinh tế học của nhà cung cấp thanh khoản.
3. Tính cuối cùng và quy tắc xác nhận nhanh kế thừa thời gian slot, do đó cả hai đều nhanh hơn với các block nhanh hơn, cải thiện khả năng tương tác với Ethereum.
4. Nhiều người đề xuất block hơn mỗi giây đồng nghĩa với khả năng chống kiểm duyệt tăng lên, bao gồm cả khả năng chống kiểm duyệt về mặt kinh tế: số tiền bạn cần trả để giữ cho các block trống trong một khoảng thời gian nhất định.

Việc tăng tốc trong khi vẫn duy trì tính phi tập trung độc đáo của Ethereum làm cho không gian block của Ethereum trở nên có giá trị hơn và giá trị đó sẽ dồn về mạng lưới và ETH. Mỗi lần giảm thời gian là giá trị được chuyển trực tiếp đến người dùng của chúng tôi. Cuối cùng, các block nhanh hơn là một trong những thay đổi được các nhà phát triển ứng dụng yêu cầu nhiều nhất.

Lý do để bắt đầu ngay bây giờ là việc giảm thời gian slot sẽ không bao giờ là một thay đổi một lần và xong. Cũng như với việc mở rộng quy mô, những lần giảm đã được thực hiện mang lại cho các ứng dụng sự chắc chắn hơn so với các cam kết trên lộ trình. Con đường dẫn đến các slot dưới 6 giây bắt đầu bằng việc làm cho thời gian slot có thể thay đổi được, sau đó thay đổi nó một cách lặp đi lặp lại. EIP-8198 chia công việc thành hai phần:

• Một lần tái cấu trúc để giúp việc cập nhật thời gian slot trong các đặc tả kỹ thuật và mã client trở nên dễ dàng hơn.
• Lần giảm đầu tiên trong Hegotá, tiếp theo là nhiều lần giảm hơn trong các fork tiếp theo, khi lộ trình tiến triển và có được bằng chứng thực nghiệm về sự an toàn.

Hegotá là fork phù hợp để trả chi phí một lần đó. ePBS trong Glamsterdam đã tái cấu trúc slot. Hegotá sau đó là một fork tương đối nhẹ cho lớp đồng thuận, một cánh cửa sẽ đóng lại với sự đồng thuận tách rời trong I*, do đó băng thông CL cho việc tái cấu trúc một lần hiện có sẵn theo cách mà nó sẽ không có lại trong vài fork tới.

Điều này có nghĩa là: Chúng ta hoặc cam kết duy trì ở mức 12 giây trong ít nhất hai năm tới, hoặc đạt được 10 giây trong khoảng một năm trong Hegotá, và có thể dưới 10 giây vào năm sau đó. Hai lần giảm này không phải là những cải tiến lý thuyết. Chúng trực tiếp mang lại giá trị gia tăng cho người dùng và cải thiện kinh tế học mạng lưới. Chúng tôi nghĩ đã đến lúc bắt đầu.

Những phản biện phổ biến nhất

Chúng tôi thảo luận ở đây 4 điểm quan trọng đã được nêu ra trong các cuộc thảo luận sơ bộ với các nhà phát triển client và EF Protocol:

1. Độ phức tạp triển khai: Định thời gian slot chính xác đến mili giây đã được hợp nhất vào các đặc tả đồng thuận thông qua công việc ePBS, và các đặc tả CL và EL dự thảo cho EIP-8198 đã tồn tại, với phí cơ bản, giới hạn gas và lịch trình blob được điều chỉnh lại để bảo toàn hành vi mỗi giây. Chi phí còn lại là một loạt các trường hợp ngoại lệ trong các client và công cụ giả định thời gian slot cố định, cộng với việc thử nghiệm. Việc tái cấu trúc một lần sẽ tập trung chính xác vào công việc này. Sau đó, mỗi lần giảm chỉ là một thay đổi tham số.

2. Chứng minh zkEVM: Hai vấn đề chính là thời gian chứng minh tương đối và chi phí chứng minh cố định.

2.1 Thời gian chứng minh tương đối đo lường tỷ lệ thời gian slot dành cho việc chứng minh và tỷ lệ này thay đổi như thế nào khi thời gian slot thay đổi. Dưới đây là mô tả ngắn gọn về các thời điểm quan trọng trong slot. Các builder hiện tại quan sát việc phát hành payload trước đó và có thể bắt đầu xây dựng ngay lập tức. Beacon block hiện tại sau đó cam kết với payload của slot hiện tại. Payload này phải được chứng minh trước khi phát hành block của người đề xuất beacon tiếp theo.

Đối với việc chứng minh, thời gian tương đối tối thiểu là một slot đầy đủ, trừ đi độ trễ của việc phát hành beacon block. Độ trễ của việc phát hành beacon block là không thể nén được, nhưng về bản chất là ngắn, do đó không giới hạn chúng ta về cơ bản ở giai đoạn này. Cũng có khả năng các builder được tối ưu hóa đồng thời chứng minh payload trong khi nó đang được xây dựng, cho phép họ bắt đầu chứng minh trước khi payload chiến thắng được cam kết bởi người đề xuất beacon block.

2.2 Việc chứng minh zkEVM chủ yếu mở rộng tuyến tính với kích thước block, ngoại trừ một số chi phí cố định. Các slot nhanh hơn có nghĩa là chi phí cố định được trả thường xuyên hơn, điều này làm tăng thêm độ trễ cho cùng một lượng thông lượng. Với ngân sách độ trễ cố định, người ta phải đảm bảo rằng thông lượng tốt vẫn có thể đạt được. Ở đây chúng tôi thấy hai cơ hội: Thứ nhất, tiến bộ kỹ thuật sẽ tiếp tục giảm độ trễ của các hoạt động cố định này. Thứ hai, trì hoãn việc tính toán state root, như được mô tả bởi EIP-7862, sẽ chuyển nhiều phần việc chứng minh ra khỏi đường dẫn tới hạn, nghĩa là chúng ta có thể tăng ngân sách độ trễ cho các hoạt động không thể nén. Sự hội tụ của hai cơ hội này cho chúng ta thấy rằng các slot nhanh hơn sẽ không cản trở việc tăng thông lượng đáng kể trong tương lai.

3. Chuyển đổi hậu lượng tử: Cách tiếp cận đồng thuận tách rời đã nhận được đủ sự ủng hộ để được coi là ổn định liên quan đến kiến trúc đồng thuận trong tương lai. Tách rời có nghĩa là di chuyển việc bỏ phiếu tính cuối cùng ra khỏi đường dẫn tới hạn của quá trình sản xuất block. Đặc biệt, việc tổng hợp quy mô lớn các chữ ký PQ và tất cả các máy móc STARK đệ quy liên quan sẽ nằm ngoài đường dẫn tới hạn. Những gì còn lại để sản xuất block và có được quy tắc lựa chọn fork để theo dõi đầu của chuỗi kết quả là một tiểu ban hiện dự kiến bao gồm 512 validator và có thể là 256. Kích thước chữ ký hậu lượng tử lớn hơn, nhưng thoải mái để truyền bá trong thời gian slot được đề xuất là 10 giây và có thể ít hơn trong tương lai.

4. Hợp đồng thông minh và cơ sở hạ tầng: Sự phụ thuộc vào thời gian slot trong các hợp đồng thông minh và cơ sở hạ tầng hiện đang được khảo sát. Đối với các hợp đồng thông minh, chúng tôi đã hợp tác với Sourcify để chạy phân tích trên tất cả các hợp đồng đã được xác minh. Chúng tôi đang nghiên cứu tác động của việc cập nhật thời gian slot đối với các gốc beacon block trong lịch sử, được lưu trữ theo EIP-4788: Gốc Beacon Block trong EVM. Về cơ sở hạ tầng, như một dữ liệu giai thoại, Etherscan đã đề cập rằng việc thay đổi thời gian slot có khả năng dẫn đến tải nhiều hơn, nhưng cơ sở hạ tầng đã được xây dựng vào thời điểm có thời gian slot thay đổi trong Proof-of-Work, do đó không yêu cầu nhiều thay đổi.

2. Trừu tượng hóa tài khoản: Cải thiện trải nghiệm người dùng, bảo mật và quyền riêng tư

Ethereum và hệ sinh thái rộng lớn hơn của nó đã quá hạn cho AA gốc, điều này sẽ mang lại những lợi ích về trải nghiệm người dùng như ví passkey, giao dịch được tài trợ, thanh toán gas bằng ERC20, xử lý giao dịch theo lô, v.v.

Tuy nhiên, con đường đến với AA gốc đã đặc biệt gập ghềnh vì AA chạm đến mọi phần của ngăn xếp Ethereum, bao gồm client, L2, ví, RPC, công cụ phát triển, v.v., do đó nó đòi hỏi sự đồng thuận từ rất nhiều bên liên quan khác nhau. Điều này khiến cho bất kỳ EIP AA nào cũng khó có thể vượt qua quy trình phát triển dựa trên sự đồng thuận của Ethereum, nhưng cũng khó đạt được sự chấp nhận thực tế sau khi EIP được phát hành.

Do đó, chúng tôi xếp đề xuất AA gốc của Hegotá, Frame Transactions, vào bậc A, không phải vì nó không đủ tốt cho bậc S về mặt kỹ thuật, mà vì chúng tôi muốn tính đến các rủi ro chấp nhận thực tế sẽ đòi hỏi một lượng phối hợp khổng lồ để giải quyết. Với nền tảng của nhóm chúng tôi trong lĩnh vực AA, Ethlabs có ý định đóng một vai trò quan trọng trong việc đưa Frame Transactions ra thị trường, bằng cách làm việc với các bên liên quan như L2 và ví để mang lại một đợt triển khai thành công cho AA gốc.

Bây giờ chúng ta hãy xem xét các đề xuất AA cụ thể cho Hegotá.

[EL] EIP-8141: Frame Transactions [Bậc A]

Chúng tôi tin rằng EIP-8141: Frame Transactions là ứng cử viên tốt nhất cho hệ thống AA gốc của Ethereum. So với các đề xuất AA gốc khác, Frames có một số đặc tính mong muốn khiến nó phù hợp duy nhất với nhiệm vụ CROPS của Ethereum:

• Đổi mới tài khoản không cần cấp phép: logic xác thực được xử lý bởi mã EVM, do đó các nhà phát triển có thể tự do phát triển bất kỳ logic xác thực nào họ muốn, trái ngược với một số cách tiếp cận AA khác yêu cầu một danh sách trắng các logic xác thực.
• Hỗ trợ hạng nhất cho các giao thức quyền riêng tư: như một hệ quả của điểm đầu tiên, một giao thức quyền riêng tư như Railgun có thể xử lý logic xác thực của các giao dịch frame, cho phép người dùng gửi các giao dịch riêng tư mà không cần dựa vào bất kỳ relay tập trung nào như hiện tại. Điều này làm cho các giao thức quyền riêng tư trở nên riêng tư hơn đáng kể và không thể kiểm duyệt.
• An toàn hậu lượng tử: các giao dịch frame đã được phát triển với lộ trình PQ rộng hơn của Ethereum. Ví dụ, các giao dịch frame được thiết kế rõ ràng để các chữ ký có thể được tổng hợp, cho phép Ethereum cuối cùng tính phí gas thấp cho các chữ ký PQ mặc dù mỗi chữ ký riêng lẻ có thể rất tốn kém để xác thực.

Điểm yếu chính của Frame Transactions cũng bắt nguồn từ điểm mạnh lớn nhất của nó: bởi vì việc xác thực được xử lý bởi mã EVM, việc xác thực hiện tạo ra một chi phí động thay vì chi phí cố định, điều này có thể đặt ra thách thức cho các chuỗi có TPS cao như L2. Chúng tôi lạc quan rằng vấn đề này có thể được giải quyết thông qua các EIP hoặc ERC tiếp theo dựa trên các giao dịch frame như EIP-7819, nơi các giao dịch có thể chỉ ra tĩnh logic xác thực của chúng để các sequencer có thể "tắt" việc xác thực bằng mã gốc nếu cần. Chúng tôi cũng có ý định làm việc với các L2 và EF để tiến hành các điểm chuẩn trên các giao dịch frame để chúng tôi có thể xác định và giải quyết mọi nút thắt cổ chai về hiệu suất.

[CL][EL] Các tiện ích bổ sung của Frame Transactions

Có một số EIP có thể được xem như phần mở rộng của Frame txs, xây dựng dựa trên các khả năng của nó.

[EL] EIP-8250: Nonce Khóa cho Frame Transactions [Bậc A]

• Chúng tôi coi EIP này về mặt khái niệm là một phần của EIP-8141: Frame Transactions và tin rằng nó nên được phát hành cùng với nó.
• EIP này giới thiệu nonce 2D cho các giao dịch Frame. Nonce 2D cho phép các tài khoản gửi các giao dịch song song đến mempool, cũng như cho phép các giao thức quyền riêng tư lưu trữ các nullifier dưới dạng nonce 2D. Điều này rất quan trọng vì nonce 2D là bộ nhớ đặc biệt có chi phí đọc và lưu trữ rất thấp, do đó các giao dịch quyền riêng tư có thể tiết kiệm đáng kể gas so với việc lưu trữ nullifier trong bộ nhớ động thông thường như hiện tại. Điều này đặc biệt quan trọng trong bối cảnh định giá lại bộ nhớ của Glamsterdam (EIP-8037: Tăng Chi phí Gas Tạo Trạng thái).

[EL] EIP-8272: Gốc Gần đây cho Frame Transactions [Bậc B]

• Đây là một EIP khác giúp nâng cao trải nghiệm sử dụng các giao thức quyền riêng tư với các giao dịch Frame. Các giao thức quyền riêng tư cần truy cập vào các gốc cam kết gần đây trong quá trình xác thực, nếu được lưu trữ trong bộ nhớ thông thường, điều này không chỉ tốn kém mà còn có thể xung đột với các quy tắc mempool công khai của Frames. EIP-8272 giải quyết những vấn đề này bằng cách hiển thị một hợp đồng hệ thống để lưu trữ các gốc này trong một bộ đệm vòng tự động xóa các gốc cũ.
• Chúng tôi xếp nó vào bậc B vì EIP này thêm độ phức tạp đáng kể vào frames cho một trường hợp sử dụng cụ thể và chúng tôi không chắc liệu có thể có một cách tổng quát/thanh lịch hơn để đạt được cùng một mục tiêu hay không.

[CL] EIP-8369: Hồ sơ VOPS cho Tính đủ điều kiện FOCIL [Bậc B]

• EIP này giải quyết sự tương tác giữa Frames và VOPS (tính không trạng thái một phần chỉ hợp lệ), một đề xuất cho phép các nút mempool lưu trữ vừa đủ trạng thái để xác thực các giao dịch, để ngay cả trong một thế giới không trạng thái (do zkEVM), mempool vẫn có thể chống kiểm duyệt.
• Chúng tôi xếp nó vào bậc B vì EIP này gắn chặt với một tầm nhìn cụ thể về tính không trạng thái mà cộng đồng vẫn chưa hoàn toàn thống nhất.

[EL] EIP-7906: Xác nhận Giao dịch qua Opcode Chênh lệch Trạng thái [Bậc B]

• EIP này cải thiện khả năng kiểm toán tĩnh của kết quả giao dịch. Người dùng đã có thể xác nhận điều gì sẽ xảy ra, nhưng không thể xác nhận rằng không có điều gì khác đã xảy ra. Việc chứng minh sự vắng mặt của các thay đổi trạng thái đòi hỏi một opcode mới. Kết hợp các xác nhận tích cực (ví dụ: số dư WETH tăng ít nhất 1.5) với một xác nhận tiêu cực (không có trạng thái nào khác thay đổi) cho phép người dùng giới hạn toàn bộ tác động của một giao dịch một cách cấu trúc, mà không cần mô phỏng, với ví phần cứng là một bên hưởng lợi rõ ràng.
• Với độ phức tạp, việc đưa nó vào hard fork sẽ là một lựa chọn rất cam kết. Chúng tôi đề nghị chỉ thực hiện điều này nếu (a) các nhóm client thực sự hiểu các sắc thái và tác động của EIP cụ thể này, và (b) bề mặt thử nghiệm và sự phức tạp được hiểu rất rõ.

[EL] Di chuyển EOA [Bậc B]

[EL] EIP-7851: Ủy quyền EOA do Mã điều khiển [Bậc B] và [EL] EIP-8151: ecRecover Hạn chế Mã Tài khoản [Bậc B] được xem tốt nhất là các tiêu chuẩn đi kèm cùng nhau trình bày một câu chuyện về cách các EOA có thể chuyển đổi sang tài khoản thông minh. Trong câu chuyện này, một EOA trước tiên sẽ ủy quyền cho một tài khoản thông minh thông qua EIP-7702. Sau đó, opcode mà EIP-7851 giới thiệu sẽ làm cho việc ủy quyền 7702 trở nên vĩnh viễn, vô hiệu hóa khóa ECDSA gốc. Mặt khác, EIP-8151 sẽ làm cho ecrecover nhận biết được việc hủy kích hoạt, do đó khóa cũ không thể rút tiền thông qua các luồng kiểu Permit.

Chúng tôi xếp cặp này vào bậc B vì nó chỉ là một trong nhiều cách tiếp cận để di chuyển EOA sang tài khoản thông minh và cách tiếp cận cụ thể này chưa nhận được sự đánh giá hoặc đồng thuận rộng rãi. Đặc biệt, chúng tôi lo ngại rằng cách tiếp cận này không trả lời được câu hỏi đa chuỗi: cùng một EOA di chuyển trên các L2 như thế nào? Người dùng sẽ phải thực hiện cùng một hành động trên TẤT CẢ các chuỗi, bao gồm cả các chuỗi chưa tồn tại, điều này sẽ dẫn đến trải nghiệm người dùng tồi tệ. Chúng tôi nghi ngờ rằng có thể có một cách tiếp cận tốt hơn, nơi các L2 có thể tận dụng L1 như "gốc rễ của sự tin cậy" cho việc di chuyển EOA, vì vậy chúng tôi dành các bậc A/S cho các cách tiếp cận cho phép người dùng di chuyển một lần cho tất cả các chuỗi EVM.

[EL] Lược đồ chữ ký PQ [Bậc A]

Hegotá nên thiết lập một lộ trình đáng tin cậy cho các chữ ký hậu lượng tử, nhưng chúng ta nên xác nhận cơ chế phù hợp trước khi cam kết.

• EIP-8355: Thêm xác minh ML-DSA precompile, làm cho bảo mật tài khoản hậu lượng tử trở nên cụ thể cùng với Frame Transactions.
• Thay thế: Đăng ký trước hỗ trợ PQ mà không kích hoạt nó, hoặc xác định một định dạng dẫn xuất có thể chứa các khóa PQ sau này.

[EL] EIP-7819: Lệnh SETDELEGATE [Bậc A]

• Với AA gốc có khả năng sẽ có mặt trong Hegota, điều quan trọng là chi phí triển khai các tài khoản thông minh mới phải thấp, nhưng việc triển khai tài khoản thực sự sẽ trở nên đắt đỏ hơn trong Glamsterdam do EIP-8037. Với EIP-7819, các tài khoản mới sẽ sử dụng các con trỏ ủy quyền đơn giản thay vì các hợp đồng proxy, giảm đáng kể lượng trạng thái mới cần được tạo ra, do đó giảm chi phí triển khai.
• Chúng tôi xếp EIP này vào bậc A vì chúng tôi tin rằng chi phí triển khai tài khoản thấp hơn sẽ làm giảm đáng kể rào cản trong việc áp dụng AA.

3. Kỹ thuật hiệu suất: Tiếp tục mở rộng L1

Glamsterdam đã đánh dấu một sự thay đổi trong cách Ethereum tiếp cận R&D, với hiệu suất được coi là một ràng buộc R&D hạng nhất, cả trong thiết kế giao thức và công việc client. Thực thi trì hoãn, định giá lại tài nguyên và rất nhiều công việc tối ưu hóa client cho phép mở rộng quy mô từ 30M lên (ít nhất) 200M trong hai năm qua. Nhìn chung, công việc hiệu suất mang lại cho chúng ta sự linh hoạt: khoảng trống mà chúng ta có được có thể được sử dụng để mở rộng quy mô, rút ngắn slot, giảm yêu cầu về nút hoặc tất cả những điều trên.

Ngày nay, chúng tôi vẫn coi việc tiếp tục mở rộng quy mô là một điều cần thiết. Các ứng dụng quyết định nơi xây dựng không chỉ dựa trên giá cả hiện tại, mà còn dựa trên việc liệu Ethereum có thể mở rộng nguồn cung không gian block một cách có thể dự đoán theo thời gian hay không. Việc liên tục cung cấp các mức tăng mang lại sự chắc chắn hơn so với các cam kết trên lộ trình. Dung lượng mainnet hiện tại vẫn còn khá xa so với khả năng xử lý các đợt tăng đột biến nhu cầu: vào sinh nhật thứ mười một của Ethereum, phí cơ bản trung bình hàng ngày chỉ khoảng 0.1 gwei, nhưng một đợt mint NFT đã đẩy nó lên trên 10 gwei trong một thời gian, với chi phí giao dịch trung bình đạt khoảng 1 đô la và phân vị thứ 90 là hơn 5 đô la. Do đó, nỗ lực mở rộng quy mô của Glamsterdam nên tiếp tục sang Hegotá.

Tổng hợp lại, các EIP sau đây tiếp tục đà mở rộng quy mô của Glamsterdam đồng thời củng cố nguyên tắc rộng hơn đằng sau nó: hiệu suất nên vẫn là mối quan tâm hạng nhất trong cả công việc client và thiết kế giao thức.

[EL] EIP-8131 & EIP-8279 [Bậc S]: Gói định giá lại dữ liệu

Sau Glamsterdam, ràng buộc tiếp theo là sự lan truyền tải trọng (payload propagation), một phần vì các nguồn byte tải trọng khác nhau được phản ánh không nhất quán, hoặc hoàn toàn không được phản ánh, trong hạch toán gas. EIP-8131: Unified Transaction Content Floor mở rộng mức sàn giao dịch hiện tại cho nội dung đã biết trước khi thực thi, trong khi EIP-8279: Block Access List Byte Floor bao gồm các byte BAL được tạo động trong quá trình thực thi.

Việc đo lường động này khiến EIP-8279 rõ ràng là phức tạp hơn trong hai EIP. Tuy nhiên, chúng tôi đề xuất xem chúng như một gói. Cùng nhau, chúng thiết lập hạch toán nhất quán cho các byte liên quan đến một giao dịch, giới hạn tải trọng trong trường hợp xấu nhất trong khi hầu như không ảnh hưởng đến các giao dịch thông thường, không nặng về dữ liệu. Điều này khắc phục khoảng trống hạch toán tài nguyên cơ bản và dọn đường cho các đợt tăng giới hạn gas tiếp theo.

[CL][EL] EIP-8146: Block Access List Sidecars [Hạng A]

EIP-8146 bổ sung cho việc định giá lại bằng cách cải thiện chính đường dẫn quan trọng, bằng cách lan truyền BAL riêng biệt khỏi tải trọng, giúp cải thiện khả năng lan truyền và giúp các execution client có khởi đầu thuận lợi trong việc tìm nạp trước trạng thái (state prefetching) và tính toán gốc trạng thái sau (post-state-root). Chúng tôi coi đây là loại tối ưu hóa dễ dàng mà chúng ta không nên bỏ qua. Công việc triển khai chủ yếu là cơ chế gossip CL quen thuộc, khiến đây trở thành một EIP ít tốn công sức, giá trị cao, đặc biệt là trong một hard fork có vẻ sẽ khá nặng về EL.

Các EIP liên quan khác

[EL] CPSB Recalibration [Hạng A]

• Các thay đổi rất đơn giản, chúng tôi khuyên bạn nên giữ chúng trong quy trình và bao gồm một trong hai nếu thấy cần thiết dựa trên mức tăng giới hạn gas đã lên kế hoạch và mức sử dụng gas trạng thái và thực thi đã quan sát được.
• EIP-8368: CPSB Recalibration for New Gas Limit: Bước tiếp theo đã được lên kế hoạch cho EIP-8037, bù đắp cho thực tế là chi phí cho mỗi byte trạng thái (CSPB) đã được làm tĩnh thay vì là một hàm của giới hạn gas, chỉ đơn thuần là một sự đơn giản hóa trong triển khai và thử nghiệm. Ý tưởng là thay thế việc điều chỉnh theo từng khối bằng các điều chỉnh một lần tại các fork, khi cần thiết để giữ cho sự tăng trưởng trạng thái đi đúng hướng khi giới hạn gas tăng lên. Vì CPSB hiện tại được hiệu chỉnh trên giới hạn gas 150M, nên có khả năng việc điều chỉnh trong Hegotá là cần thiết.
• EIP-8372: Normalized state gas limit: Vẫn là một tập hợp siêu nhỏ khá tối thiểu của EIP-8368, cho phép điều chỉnh chi tiết hơn so với chỉ CPSB, bù đắp cho việc mục tiêu tăng trưởng trạng thái hoặc mục tiêu gas thông thường bị thiếu hụt do định giá tương đối sai.

[EL] EIP-7862: Delayed State Root [Hạng B]

• Dễ dàng để đặc tả, nhưng độ phức tạp của việc triển khai client không được hiểu rõ lắm theo những gì chúng tôi biết. State root hiện diện khắp nơi trong các codebase.
• Mặc dù có một số lợi ích trong việc hạ thấp rào cản tiếp cận để xây dựng cạnh tranh (tính toán state root nhanh), nhưng theo chúng tôi, lợi ích đáng kể nhất của EIP là trong tương lai (có nhiều thời gian hơn để chứng minh việc tính toán state root).
• EL vốn đã là mặt nặng của Hegotá.

[CL] EIP-8341: Partial Execution Payload Commitments [Hạng D]

• Chúng tôi khuyên bạn nên từ chối: lợi ích nhỏ (trì hoãn nhẹ việc tính toán state root), không khẩn cấp và đã bị thay thế bởi EIP-7862: Delayed State Root (cung cấp nhiều thời gian hơn cho việc đó).

Các EIP khác

Bây giờ chúng tôi sẽ đề cập đến phần còn lại của các EIP, được phân nhóm lỏng lẻo theo chủ đề. Đối với một số EIP, chúng tôi vẫn đang hình thành quan điểm của mình. Chúng tôi sẽ cập nhật tài liệu này khi chúng tôi tìm hiểu thêm từ các nhóm client và tác giả EIP trong những ngày và tuần tới.

Vì Hegotá có vẻ sẽ là một hard fork nghiêng về EL, chúng tôi đề xuất giữ kỷ luật và duy trì một tiêu chuẩn cao cho bất kỳ EIP nào ở phía EL để vượt qua. Chúng tôi nghĩ rằng việc giữ cho Hegotá tương đối nhẹ về CL ngoài FOCIL và Quick Slots là điều mong muốn: phạm vi hẹp hơn giúp bảo toàn băng thông để các nhóm client có không gian chuẩn bị cho quá trình chuyển đổi kiến trúc lớn hơn.

[CL] Phát hành (Issuance)

Chúng tôi cố tình không xếp hạng EIP-8363: Tapered Issuance Burn. Chúng tôi cho rằng phát hành không phải là quyết định mà các nhà phát triển cốt lõi (core devs) nên tự đưa ra và danh sách xếp hạng là một đề xuất rõ ràng cho các core devs. Đối với hầu hết các EIP, quy trình ACD hoạt động tốt vì các quyết định chủ yếu mang tính kỹ thuật và cộng đồng đã ủy quyền hiệu quả cho các core devs. Phát hành khác ở chỗ nó là một câu hỏi về chính sách tiền tệ mà chính cộng đồng phải đạt được sự đồng thuận sơ bộ. Ý kiến của các core dev rất quan trọng, nhưng là đầu vào cho cuộc thảo luận công khai đó. Việc xếp hạng EIP-8363 cùng với các EIP khác sẽ coi nó như một quyết định ACD thông thường, điều mà chúng tôi cho là không nên.

Về mặt kỹ thuật, chúng tôi thấy có giá trị trong việc thay đổi phát hành theo hướng của EIP-8363. Các vấn đề nó giải quyết là có thật: độ tin cậy của việc cắt giảm (slashing) giảm dần khi nhiều ETH được stake hơn, tỷ lệ stake cao có nghĩa là phần thưởng chủ yếu bù đắp cho sự pha loãng và tính kinh tế theo quy mô tiếp tục mở rộng khoảng cách giữa các nhà điều hành lớn và những người stake đơn lẻ. Một sự thay đổi cũng có rủi ro, từ sự không chắc chắn về tác động đến phân phối stake và việc đặt lại đồng hồ hóa cứng chính sách tiền tệ. Bài viết của Ansgar trình bày cả hai mặt và phản ánh quan điểm của chúng tôi. Một số người trong chúng tôi đã từng tranh luận cho những thay đổi về phát hành trong quá khứ và tiếp tục có niềm tin vào con đường đó.

Chúng tôi khuyên bạn nên đưa ra quyết định về phát hành sau khi tất cả các quyết định về phạm vi Hegotá khác được đưa ra. Điều này giúp cuộc thảo luận cộng đồng có thời gian cần thiết và tránh gây xao nhãng khỏi chính quy trình xác định phạm vi.

[CL] Các tính năng Staking

Các cải tiến về staking có thể có giá trị, nhưng lợi ích hướng đến người dùng nên được ưu tiên hơn các thay đổi chỉ dành cho cơ sở hạ tầng, trừ khi thực sự cần thiết.

[CL] EIP-8015: Remove deposit and eth1data fields [Hạng A]

• Dọn dẹp nợ kỹ thuật rất đơn giản. Nhờ EIP-7688: Forward compatible consensus data structures, các bằng chứng Merkle của các trường không liên quan không bị ảnh hưởng, do đó không có tác động đến người tiêu dùng chuỗi.

[EL][CL] EIP-8237: Independent CL/EL Sync [Hạng B]

• Xây dựng dựa trên sự tách biệt của beacon block và payload được giới thiệu bởi ePBS, cho phép EL và CL đồng bộ hóa độc lập. Chúng tôi nghĩ điều này có tiềm năng đơn giản hóa một phần phức tạp của các client Ethereum.

[CL] EIP-8205: Withdrawal credentials preregistration [Hạng D]

• Chúng tôi khuyên bạn nên từ chối. Mặc dù EIP cung cấp một giải pháp trong giao thức cho một vấn đề thực tế trong delegated staking, chúng tôi nghĩ rằng giải pháp pre-deposit hiện tại là đầy đủ và độ phức tạp của cơ chế được thêm vào hiện không được chứng minh.

[CL] EIP-8148: Custom sweep threshold for validators [Hạng D]

• Chúng tôi khuyên bạn nên từ chối. Chúng tôi nghĩ EIP quá phức tạp (hợp đồng hệ thống mới, yêu cầu thực thi mới, cơ chế CL) so với lợi ích của nó, mà chúng tôi thấy chủ yếu là khuyến khích một số hợp nhất biên bổ sung từ nhóm người vận hành tại nhà. Chúng tôi không nghĩ điều này sẽ có nhiều ảnh hưởng đến việc hợp nhất validator tổng thể với cách phân phối stake hiện tại.

[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [Hạng D]

• Chúng tôi khuyên bạn nên từ chối. Chúng tôi nghĩ điều này rất có thể sẽ chỉ dẫn đến nhiều kênh phụ hơn. Hơn nữa, nhiều năm thảo luận về các chiến lược đốt MEV đã không dẫn đến bất kỳ đề xuất nào đạt được sự đồng thuận nghiên cứu rộng rãi.

[CL] EIP-7716: Anti-correlation attestation penalties [Hạng D]

• Chúng tôi khuyên bạn nên từ chối. Chúng tôi không nghĩ có đủ bằng chứng rõ ràng rằng một sự thay đổi khá lớn như vậy trong các ưu đãi staking là cần thiết. Hơn nữa, các ưu đãi staking có thể sẽ được thiết kế lại như một phần của decoupled consensus.

[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [Hạng D]

• Chúng tôi khuyên bạn nên từ chối. Mặc dù là một sự dọn dẹp tốt, chúng tôi nghĩ nên hoãn nó lại cho quá trình chuyển đổi decoupled consensus lớn sắp tới.

[CL] EIP-8359: Beacon Block Reporting Field [đang hình thành quan điểm]

[CL] Chuẩn bị thêm cho PQ (Further PQ-prep)

Các đề xuất này làm giảm các phụ thuộc BLS còn lại trước khi chuyển đổi sang hậu lượng tử (post-quantum) trong tương lai.

[CL] EIP-8365: BLS withdrawal credential retirement [Hạng A]

• Loại bỏ một withdrawal credential kế thừa, tạo tiền đề cho việc đơn giản hóa giao thức và đơn giản hóa quá trình chuyển đổi PQ trong tương lai.
• Vì nó rất đơn giản, chúng tôi nghĩ nên đưa vào ngay bây giờ.

[CL] EIP-8367: Balance sunset for retired BLS validators [Hạng D]

• Chúng tôi khuyên bạn nên từ chối. Chúng tôi nghĩ rất có thể hầu hết các validator 0x0 sẽ thực hiện thay đổi thông tin xác thực (BLSToExecutionChange) trước hoặc sau khi EIP-8365: BLS withdrawal credential retirement được kích hoạt, để rút tiền của họ hoặc để có thể tiếp tục staking. Chúng tôi không nghĩ có sự cấp bách lớn để giới thiệu một cơ chế xử lý phần stake 0x0 còn lại. Chúng tôi khuyên bạn chỉ nên bao gồm EIP-8365 và xem kết quả của nó trước khi quyết định các bước tiếp theo.

[CL] EIP-8321: Hash-Chain RANDAO [Hạng D]

• Chúng tôi khuyên bạn nên từ chối. Việc làm cho RANDAO an toàn hậu lượng tử một cách riêng lẻ mang lại rất ít bảo mật ở cấp độ giao thức trong khi các khóa BLS của validator vẫn dễ bị tổn thương, nhưng lại thêm khoảng 32 byte cho mỗi validator, cơ chế quản lý bí mật mới và một cơ chế phần lớn chỉ phục vụ một mục đích. Thiết kế đồng thuận PQ rộng hơn vẫn chưa được ổn định. Chúng tôi ủng hộ một quá trình chuyển đổi lặp đi lặp lại, nhưng bước đầu tiên của nó nên tuân theo một lộ trình đã được thống nhất thay vì có nguy cơ bị thay thế bởi thiết kế cuối cùng.

[EL][CL] Chuẩn bị cho zkEVM

Hầu hết việc chuẩn bị cho zkEVM đều mang lại lợi ích ngắn hạn hạn chế ngoài việc làm cho hoạt động của full node dễ dàng hơn đối với một nhóm người dùng hẹp, đồng thời tiêu tốn băng thông triển khai và có khả năng làm cho EVM đắt hơn. Chúng ta chỉ nên bao gồm những thay đổi mà giá trị lâu dài rõ ràng biện minh cho các chi phí trước mắt đó.

[CL] EIP-8025: Optional Execution Proofs [Hạng D]

• EIP không yêu cầu một hard fork. Đề xuất đưa nó vào Hegota hoàn toàn là một biểu hiện của sự ưu tiên và chúng tôi không đồng ý với lựa chọn đó. Chúng tôi nghĩ công việc nên tiếp tục với nó, nhưng Hegotá không nên bị chặn lại vì nó.
• Trước khi phát hành optional proofs, chúng ta nên làm việc để xác định trạng thái cuối cùng trước, sau đó tăng tốc hướng tới điều đó, thay vì phát hành optional proofs trước khi có một cái nhìn rõ ràng về mô hình validator/trạng thái dài hạn.
• Câu hỏi mở cốt lõi là vai trò của validator đối với trạng thái: liệu chúng có nên tiếp tục phục vụ hoặc nắm giữ một phần trạng thái, thay vì trở nên hoàn toàn không trạng thái (stateless) hay không. Bởi vì validator là một nhóm node cốt lõi với giá trị phần cứng và mạng thực tế, những thay đổi làm suy yếu vai trò đó nên vượt qua một tiêu chuẩn cao hơn.

[EL] EIP-7666: EVM-ify the identity precompile [Hạng A]

• Thay đổi hữu ích, nhỏ

[EL] EIP-8200: EVMification [Hạng B]

• EIP-8200 thay thế ba precompile gốc bằng EVM bytecode tương đương. Hai cái ít được sử dụng và có vẻ dễ dàng để di chuyển. Cái thứ ba được sử dụng rộng rãi trong xác minh SNARK, vì vậy chúng tôi muốn có một đánh giá tác động trước khi ủng hộ việc loại bỏ nó.
• Nếu phân tích tác động cho thấy chi phí di chuyển thấp cho những người dùng bị ảnh hưởng hoặc nếu precompile thứ ba bị loại khỏi phạm vi, chúng tôi sẽ chuyển EIP-8200 lên [Hạng A].

[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [Hạng D]

• Khá gây gián đoạn do chi phí gas tăng rất lớn, không khẩn cấp
• Giảm thiểu rủi ro có thể bao gồm một phân tích tác động hoặc thực hiện nó sau đó với một số hình thức làm ấm ở cấp độ khối (block level warming) (hoặc làm ấm đặc biệt các giá trị này) để giảm tác động.

[EL] EIP-8268: Storage Roots in Block Access Lists [Hạng B]

• Có thể cần phân tích tác động cụ thể đến kích thước BAL và tác động liên quan đến chi phí giao dịch (EIP-8279 đang đề xuất tính phí cho các byte BAL), vì mục nhập BAL cho mỗi tài khoản được chạm vào sẽ có thêm một storage trie root.

[EL] Các tính năng EVM

Hegotá vẫn sẽ yêu cầu một số quyết định EVM đặc biệt. Chúng tôi tin rằng sau Hegotá, Ethereum nên hướng tới một lộ trình EVM dài hạn được định hình bởi hệ sinh thái EVM rộng lớn hơn. Ethlabs sẽ đóng góp vào việc đó.

[EL] EIP-5920: PAY opcode [Hạng A]

• Rất đơn giản và chúng tôi nghĩ đó là một nguyên thủy tốt để EVM có
• Sẽ rất quan trọng để hiểu rõ hơn các trường hợp sử dụng cụ thể

[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [Hạng A]

• Rất hữu ích cho L2, không có chi phí thực sự cho L1 (chỉ mang tính thông tin)

[EL] Tái sử dụng / Khử trùng lặp mã (Code reuse / deduplication) [Hạng B]

• EIP-8058: Contract Bytecode Deduplication Discount và EIP-8298: SETCODEFROM Code Reuse Instruction đều cố gắng tận dụng thực tế là mã hợp đồng được lưu trữ riêng biệt với tài khoản tương ứng trong các client, với mã băm (code hash) làm con trỏ giữa chúng. Do đó, mã chia sẻ giống hệt nhau có thể được lưu trữ đã khử trùng lặp. Cả hai EIP đều cho phép một cách để đặt mã băm tài khoản một cách rẻ tiền thành băm của một mã tồn tại ở nơi khác.
• Chúng tôi coi đây là một ý tưởng chung hấp dẫn, nhưng sẽ rất quan trọng để hiểu các tác động và khả năng tương thích chuyển tiếp với cây nhị phân. Hiện tại không có ưu tiên nào giữa hai cái.

[EL] Cải cách định giá bộ nhớ (Memory pricing reform) [Hạng B]

• Chúng ta cần quyết định liệu chúng ta có muốn thực hiện cải cách bộ nhớ trong Hegota hay không. Chúng tôi không rõ liệu hiện tại chúng ta có đủ hiểu biết về không gian thiết kế để đưa ra đánh giá này hay không.

EIP-7686: Linear EVM memory limits

• Thay đổi nhỏ hơn, chỉ loại bỏ chi phí mở rộng bộ nhớ bậc hai.

EIP-7923: Linear, Page-Based Memory Costing

• Làm lại sâu hơn, có nguyên tắc hơn, nhưng phức tạp hơn.

[EL] EIP-8219: Checked Arithmetic Opcodes [Hạng B]

• Nhìn chung, việc thêm toán học an toàn vào EVM có vẻ hữu ích.
• Định giá sẽ cần được xác nhận với các điểm chuẩn, điều đó phức tạp đến mức nào?
• Với các điểm chuẩn và phân tích tác động (có bao nhiêu giao dịch có thể được hưởng lợi, bao nhiêu, trình biên dịch nào sẽ thêm hỗ trợ?), nó có thể là Hạng A.

[EL] EIP-8360: TCREATE Opcode [Hạng B]

• EIP giới thiệu khả năng tạo các hợp đồng tạm thời trong phạm vi giao dịch. Đây là một nguyên thủy tốt để có nói chung.
• EIP thêm độ phức tạp đáng kể. Với đánh giá độ phức tạp triển khai và thử nghiệm kỹ lưỡng hơn, nó có thể là Hạng A.

[EL] EIP-7645: Alias ORIGIN to SENDER [Hạng D]

• Chúng tôi khuyên bạn nên từ chối: Thay đổi mang tính phá vỡ, sử dụng ORIGIN không đúng cách.

[EL] EIP-8182: Private ETH and ERC-20 Transfers [Hạng D]

• Chúng tôi khuyên bạn nên từ chối: Thay đổi lớn, thêm các phụ thuộc zk. Nếu từng được giới thiệu, chúng tôi nghĩ nó nên là một tính năng chính.

[EL] EIP-2488: Deprecate the CALLCODE opcode [đang hình thành quan điểm]

[EL] EIP-4758: Deactivate SELFDESTRUCT [đang hình thành quan điểm]

[EL] EIP-7979: Call and Return Opcodes for the EVM [đang hình thành quan điểm]

[EL] EIP-8173: Foundations of EVM Control Flow [đang hình thành quan điểm]

[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [đang hình thành quan điểm]

[EL] EIP-8030: P256 algorithm support [đang hình thành quan điểm]

[EL] Định giá EVM

Glamsterdam đã tăng giá cho các hoạt động được định giá thấp làm hạn chế thông lượng tổng thể. Các đề xuất định giá EVM của Hegotá chủ yếu giải quyết mặt còn lại: giảm giá cho các hoạt động riêng lẻ mà chi phí hiện tại hạn chế việc sử dụng chúng, nhưng không phải khả năng mở rộng mạng. Do đó, đây là những thứ tốt để có với tác động thấp hơn trên mỗi EIP. Chúng tôi cởi mở với việc định giá lại có mục tiêu, nhưng các đề xuất giới thiệu cơ chế đo lường mới chỉ nên được đưa vào nếu thiết kế của chúng hợp lý và được một nhà vô địch tận tâm giảm thiểu rủi ro đầy đủ.

[EL] EIP-8358: Net Gas Metering for Account Changes [Hạng B]

• Không bị thuyết phục về tác động. Trong 900 khối mainnet được lấy mẫu, ~400k giao dịch: 2.07% tổng số giao dịch sẽ tiết kiệm gas & 1.14% gas khối sẽ được tiết kiệm

[EL] EIP-7973: Warm Account Write Metering [đang hình thành quan điểm]

[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [đang hình thành quan điểm]

[EL] EIP-7971: Hard Limits for Transient Storage [đang hình thành quan điểm]

[EL] EIP-3298: Removal of refunds [đang hình thành quan điểm]

[EL] EIP-8374: Persist Warm Access Sets Across Reverts [đang hình thành quan điểm]

[EL] EIP-8115: Batch priority fees at end of block [đang hình thành quan điểm]

[EL] EIP-8188: Last-Written Block for Accounts and Slots [đang hình thành quan điểm]

[EL][CL] Dữ liệu thực thi và lập chỉ mục

[EL][CL] EIP-7668: Remove bloom filters [đang hình thành quan điểm]

[EL][CL] EIP-7807: SSZ execution blocks [đang hình thành quan điểm]

[EL] EIP-8116: Replace cumulative receipt fields [đang hình thành quan điểm]

[EL] EIP-8304: Trustless log and transaction index [đang hình thành quan điểm]

[EL][CL] Kết nối mạng (Networking)

Lớp P2P của Ethereum có chỗ cho các cải tiến có mục tiêu, đặc biệt là trong cách các giao dịch, blob và chứng thực (attestations) được lan truyền trên mạng.

[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [Hạng A]

• Nhìn chung ngăn chặn việc tái tạo đầy đủ và hiệu suất của full custody node như một nút thắt cổ chai đối với việc mở rộng số lượng blob.
• Có giá trị, cuối cùng một số hình thức tái tạo phân tán chắc chắn nên được đưa vào giao thức. Điều này có thể cho phép chúng tôi loại bỏ validator custody
• Cần hiểu rõ hơn về độ phức tạp

[CL] EIP-8142: Block-in-Blobs (BiB) [Hạng D]

• Còn sớm, không có sự cấp bách mạnh mẽ, khá là vào phút cuối, còn nhiều câu hỏi (KZG hay không? Chủ đề gossip mới hay không?).
• Không muốn đưa KZG vào đường dẫn quan trọng của việc sản xuất khối, các lựa chọn thay thế không rõ ràng và sẽ thêm độ phức tạp hơn nữa.

[CL] EIP-8243: Batching Attestations at Source [Hạng D]

• Không rõ liệu chúng ta có thể dựa vào điều này để giảm thời gian đạt tính chung cuộc (time-to-finality) hay không, nó không đặt ra một giới hạn rõ ràng cho tải.
• Khả năng chống DoS của cơ chế chưa hoàn toàn rõ ràng.

[EL] EIP-8077: eth/XX - announce transactions with nonce [đang hình thành quan điểm]

[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [đang hình thành quan điểm]

[CL] EIP-8334: Bundled Attestation Propagation [đang hình thành quan điểm]

Nếu bằng cách nào đó bạn vẫn còn ở đây với chúng tôi, cảm ơn bạn đã đọc đến cuối. Hãy thoải mái trả lời với bất kỳ câu hỏi nào và chúng tôi sẽ cố gắng hết sức để trả lời bạn! Nếu bạn đã bỏ qua và chỉ cuộn xuống đây vì nhìn chằm chằm vào một bức tường văn bản khổng lồ không phải là cách bạn quyết định dành Chủ nhật của mình, bạn sẽ rất vui khi biết rằng phần tiếp theo này rất ngắn gọn.

Một vài (nữa) lời...

Các bản nâng cấp Ethereum rất phức tạp vì tính chất quan trọng của chúng. Hàng nghìn node trên khắp thế giới chuyển sang các quy tắc mới trong cùng một slot và mạng lưới không dừng lại dù chỉ một giây trong khi chúng làm điều đó. Sự nghiêm ngặt đó đã hỗ trợ mọi bản nâng cấp mà Ethereum đã phát hành, tạo ra một mạng lưới phi tập trung đã kỷ niệm 11 năm hoạt động 100% thời gian.

Quan điểm của chúng tôi về Hegotá là những đánh giá tốt nhất của chúng tôi tính đến hôm nay, nhưng chúng tôi sẽ cập nhật suy nghĩ của mình bất cứ khi nào bằng chứng mới từ các cuộc thảo luận hoặc công việc triển khai thay đổi quan điểm của chúng tôi.

Một số EIP này được tạo ra hoặc thúc đẩy bởi các thành viên của Ethlabs, những EIP khác đến từ các nhà nghiên cứu, nhà phát triển client và những người đóng góp cá nhân vô cùng rộng lớn, tài năng và có thiện chí trên khắp Ethereum. Tuy nhiên, tất cả chúng sẽ yêu cầu sự hợp tác giữa các nhóm client, ví, ứng dụng, L2, nhà cung cấp hạ tầng, tổ chức, người vận hành node và cuối cùng là người dùng để thành công. Ethereum là dự án chung của thế giới và sự tiến bộ có ý nghĩa của mạng lưới không bao giờ là công việc của một tổ chức duy nhất.

Chúng tôi biết ơn vì là một phần nhỏ của hệ sinh thái này và chúng tôi mong muốn được giúp Ethereum phát huy hết tiềm năng của nó.

– Ethlabs