BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Trang chủ
AI AI
Tin nhanh
Bài viết
Sự kiện
BlockBeats Pro
Thêm
Thông tin tài chính
Chuyên đề
Hệ sinh thái chuỗi khối
Mục nhập
Podcast
Data
OPRR
Partnered With:

Tóm tắt cuộc họp mới nhất của các nhà phát triển cốt lõi Ethereum: Đồng ý loại bỏ EIP 3074, bao gồm EIP 7702

Đọc bài viết này mất 20 phút
Vào ngày 23 tháng 5, tất cả các nhà phát triển cốt lõi của Ethereum đã tham gia cuộc gọi hội nghị All Core Developers Execution (ACDE) lần thứ 188.
Tiêu đề gốc: "Cuộc gọi thực thi tất cả các nhà phát triển cốt lõi #188 Writeup"
Tác giả gốc: Christine Kim
Biên soạn gốc: Luccy, BlockBeats

Ghi chú của biên tập viên:
Cuộc gọi đồng thuận dành cho các nhà phát triển Ethereum toàn diện (ACDE) được tổ chức hai tuần một lần để thảo luận và điều phối các thay đổi đối với Lớp thực thi Ethereum (EL). Đây là cuộc gọi hội nghị lần thứ 188 của ACDE. Tại cuộc họp này, các nhà phát triển đã thảo luận và điều phối các thay đổi trong lớp thực thi Ethereum.

Cuộc họp đề cập đến nhiều chủ đề quan trọng, bao gồm các tính năng API thực thi mới, các yêu cầu về mẹo ưu tiên tối thiểu của Geth, các cuộc thảo luận về mạng phát triển Pectra 0 và 1, phạm vi phân nhánh Pectra và hết hạn lịch sử. Các nhà phát triển đã thảo luận và trao đổi chuyên sâu về những vấn đề này và đạt được một số đồng thuận về phạm vi, tiến độ và chi tiết triển khai cụ thể của bản nâng cấp Pectra.

Christine Kim, Phó Chủ tịch Nghiên cứu của Galaxy Digital, đã ghi lại chi tiết những điểm chính của cuộc họp này. BlockBeasts đã biên soạn văn bản gốc như sau:


<. p>Tháng 5 năm 2024 Vào ngày 23, các nhà phát triển Ethereum đã tập trung trên Zoom để tham gia cuộc họp số 188 của All Core Developers Execution (ACDE). Cuộc gọi hội nghị ACDE là chuỗi cuộc họp hai tuần một lần do Tim Beiko, Trưởng bộ phận Hỗ trợ Giao thức tại Ethereum Foundation tổ chức, 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). Tuần này, các nhà phát triển đã thảo luận về vấn đề sau:


· Thêm chức năng mới vào API thực thi để cho phép người dùng truy cập "dữ liệu trả về" của giao dịch

· Yêu cầu giới hạn mức độ ưu tiên tối thiểu cho Geth

· Pectra Devnet 0 và 1

· Phạm vi của các nhánh Pectra

· Tích hợp hết hạn dữ liệu Lịch sử của Portal Network.

· Họ đã đồng ý xóa EIP 3074 khỏi Pectra Devnet 0 và đưa EIP 7702 vào Pectra Devnet 1, mạng thử nghiệm nâng cấp Pectra tập trung vào nhà phát triển tiếp theo.


Thêm dữ liệu trả lại vào biên lai giao dịch


Charles Cooper, một nhà phát triển duy trì ngôn ngữ lập trình hợp đồng thông minh Vyper, đã đề xuất rằng nên điều chỉnh điểm cuối trong API thực thi để người dùng cũng có thể nhận được dữ liệu trả về của giao dịch khi nhận được biên nhận giao dịch. Cooper giải thích rằng các phương pháp phổ biến hiện được các nhà phát triển sử dụng để lấy dữ liệu trả về, chẳng hạn như sử dụng theo dõi giao dịch, không được chuẩn hóa hoặc hỗ trợ phổ biến trên tất cả các khách hàng. Dựa trên phản hồi từ các nhóm khách hàng như Reth về ý tưởng của mình, Cooper cho biết một giải pháp khác là tạo điểm cuối mới trong API thực thi để lấy dữ liệu trả về của giao dịch. Các nhà phát triển đã không thể đạt được sự đồng thuận về đề xuất trong cuộc gọi hội nghị. Beiko khuyên các nhà phát triển nên tiếp tục thảo luận trên GitHub và thử không đồng bộ bên ngoài cuộc họp. Giải quyết vấn đề này .


Yêu cầu mẹo khai thác tối thiểu


Sau đó, nhà phát triển Geth, Péter Szilágyi, đã đề xuất trong những tuần gần đây. về cài đặt mặc định của máy khách Geth. Kể từ khi triển khai EIP 1559 , Máy khách Geth luôn thực thi yêu cầu tiền boa có mức độ ưu tiên tối thiểu mặc định cho các giao dịch. Sau khi hợp nhất, tiền boa ưu tiên 1 gwei mặc định không hoạt động bình thường và chỉ mới được nhóm của Szilágyi phát hiện và sửa gần đây. Sau khi khôi phục cài đặt mặc định này, người dùngđã tìm thấy bằng ứng dụng khách Geth Các khối được xây dựng bên cạnh trống hơn đáng kể so với các khối khác vì chúng loại trừ các giao dịch có ít mẹo ưu tiên. Điều này làm dấy lên mối lo ngại rằng cài đặt mặc định có thể có tác động tiêu cực đến động lực của người đề xuất khối và người xây dựng a>, vì nó có thể dẫn đến việc xử lý các giao dịch hợp lệ mà không có phí ưu tiên bị trì hoãn.


Nhà phát triển Nethermind Tomasz K. Stańczak cho biết yêu cầu về mức độ ưu tiên tối thiểu mặc định của Geth là một vấn đề không liên quan mà các nhà phát triển giao thức không nên cố gắng chuẩn hóa hoặc thực thi. Nhà nghiên cứu Ansgar Dietrichs của EF đề xuất giảm mức ưu tiên tối thiểu mặc định vì phí cơ sở giao dịch của Ethereum hiện rất thấp. Các nhà phát triển khác đã đề xuất đặt mẹo ưu tiên tối thiểu mặc định trong Geth dưới dạng phần trăm của phí cơ bản, thay vì số tiền cố định. Tuy nhiên, Beiko phản đối điều này, cho rằng các mẹo ưu tiên không phải là phí nhằm đưa vào các khối dưới dạng giao dịch. Nó chỉ nên được sử dụng để ưu tiên đảm bảo các giao dịch được đưa vào khối tiếp theo, việc sử dụng mẹo ưu tiên tối thiểu mặc định dựa trên biến động phí cơ sở có thể làm sai lệch các thay đổi về phí cơ sở vì một phần giá trị sẽ được phản ánh trong mẹo ưu tiên của giao dịch.


Beiko nói thêm rằng một góc thảo luận khác là làm thế nào để khuyến khích những người xây dựng tạo ra các khối không có tiền boa và cung cấp các khoản thanh toán ngoài phạm vi cho những người đề xuất như một khoản đền bù. Điều này có thể xảy ra khi có hoặc không có yêu cầu về mức độ ưu tiên tối thiểu mặc định, nhưng việc đặt mặc định có thể tạo ra một tiêu chuẩn khuyến khích người xây dựng không tạo các khối không có tiền boa. Szilágyi nói rằng, theo một nghĩa nào đó, đó là một câu hỏi triết học liệu các nhà xây dựng có nên đưa các giao dịch không có tiền boa vào các khối hay không. Từ góc độ mạng, các giao dịch này hợp lệ và do đó nên được đưa vào khối. Tuy nhiên, từ quan điểm của người đề xuất có động cơ tài chính, việc bao gồm giao dịch không có tiền boa không có lợi ích tài chính trong khối và do đó không nên được đưa vào.


Các nhà phát triển thường đồng ý rằng nhóm Geth nên đặt các giá trị mặc định mà họ cho là tốt nhất. Người vận hành nút xác thực có thể tự do thay đổi giá trị mặc định này nếu họ muốn hoặc sử dụng các máy khách lớp thực thi khác.


Pectra Devnet-0


Parithosh, Kỹ sư vận hành nhà phát triển, Ethereum Foundation (EF) Jayanthi đã cung cấp thông tin cập nhật về mạng phát triển Pectra. Mạng phát triển đầu tiên đã được ra mắt tại Kenya vào tuần trước có tên là Nyota Interop Ra mắt tại một cuộc họp ngoại tuyến của các nhà phát triển giao thức Ethereum. Jayanthi cho biết mạng phát triển bao gồm tất cả các máy khách lớp thực thi và đồng thuận. Tuy nhiên, EIP 3074 chưa được thử nghiệm chuyên sâu và có những lỗi cần khắc phục. Nhóm khách hàng đang chuẩn bị ra mắt mạng phát triển thứ hai, Pectra Devnet 1, sẽ bao gồm hỗ trợ cho EIP 2935 Các thay đổi được thực hiện.


Thay đổi phạm vi Pectra


Sau đó, các nhà phát triển đã thảo luận về những thay đổi đối với phạm vi nâng cấp Pectra. Nhà phát triển giao thức Ethereum độc lập Danno Ferrin, nhà phát triển Reth Georgios Konstantopoulos và đại diện của nhóm Solidity đều ủng hộ việc đưa EOF vào Pectra. Nhà phát triển Geth Marius van der Wijden cho biết ông đang triển khai đặc tả EOF. Tuy nhiên, ông nhấn mạnh rằng việc đưa vào EOF chắc chắn sẽ trì hoãn việc kích hoạt bản nâng cấp Pectra do tính phức tạp của nó. Nhà phát triển Lodestar và EthereumJS Gajinder Singh đã đề cập trong một cuộc trò chuyện trên Zoom rằng các nhà phát triển nên tập trung vào việc phát hành phiên bản hiện tại của Pectra thay vì mở rộng phạm vi nâng cấp. Các nhà nghiên cứu của EF Alex Stokes và Piper Merriam đồng ý với Singh.


Sau khi thảo luận về EOF, các nhà phát triển đã thảo luận về tiến trình của EIP 7702. EIP 7702 được cung cấp bởi Ethernet Vitalik Buterin, người đồng sáng lập Fangfang, đã đề xuất nó như một giải pháp thay thế cho EIP 3074. Các chi tiết quan trọng về EIP 7702, chẳng hạn như thiết kế có thể hủy bỏ của nó, vẫn chưa được giải quyết. Một nhà phát triển có tên "dror" đã viết trong cuộc trò chuyện Zoom: "EIP 7002 là phiên bản của EIP 3074. Trước đây, chỉ những phiên bản có nonce và ID chuỗi (chainID) mới được chấp nhận. Bây giờ những phiên bản này đã bị xóa, chúng tôi cần phải xem lại lý do -discused. Tôi khuyên bạn nên mở lại cuộc thảo luận về những hạn chế này, nhà phát triển Besu, Daniel Lehrner, đã đề xuất nhận thêm ý kiến đóng góp từ các nhà phát triển ví về thiết kế của EIP 7702. Nhà phát triển Erigon Andrew Ashikhmin nhấn mạnh rằng cần phải có cách để người dùng tự thu hồi ủy quyền, bỏ qua ví.


Beiko đề nghị tiếp tục thảo luận về chi tiết triển khai EIP 7002 trong một cuộc họp nhóm riêng. Đồng thời, các nhà phát triển đã đồng ý loại bỏ EIP 3074 khỏi Devnet 0 và thêm EIP 7702 vào Devnet 1.


Hai EIP khác dự kiến được thêm vào Pectra là EIP 7623 (tăng chi phí dữ liệu cuộc gọi) và EIP 7212 (biên dịch trước để hỗ trợ các đường cong secp256r1). Nhà nghiên cứu Toni Wahrstätter của EF đã chia sẻ những phát triển mới nhất về EIP 7623 và nhà phát triển ví hợp đồng thông minh Ulaş Erdoğan đã chia sẻ những phát triển mới nhất về EIP 7212. Các nhà phát triển không đồng ý về việc có nên đưa hai EIP này vào Pectra hay không.


Kỳ vọng về dòng thời gian của Pectra


Konstantopoulos đã đề cập đến thời điểm các nhà phát triển nên kích hoạt bản nâng cấp Pectra trên mạng chính Ethereum. Trong một tài liệu được chia sẻ trước cuộc gọi, nhóm khách hàng Reth đã viết rằng có "rất ít giá trị" khi cố gắng phát hành bản nâng cấp trước cuối năm 2024 và các nhà phát triển nên chuẩn bị phát hành bản nâng cấp vào đầu năm 2025. Nhóm EF Panda Ops (một nhóm nhỏ của nhóm EF Developer Ops) cũng đã chia sẻ trước cuộc gọi Một tài liệu bày tỏ quan điểm của họ về tiến trình và phạm vi của Pectra. Họ đề xuất chia Pectra thành hai nhánh, một nhánh sẽ được kích hoạt trong năm nay và một nhánh khác bao gồm MaxEB, EOF và có thể là ngang hàng, sẽ được kích hoạt vào đầu năm tới. Jayanthi nói rằng nhóm EF Panda Ops không thống nhất về quan điểm của họ, nhưng cá nhân anh ấy tin rằng phạm vi của Pectra nên được chia thành hai nhánh. Ông lưu ý rằng các trường hợp biên và tương tác EIP để nâng cấp Pectra vẫn chưa được thử nghiệm.


Nhà phát triển Alex Beregszaszi của EF Solidity bày tỏ lo ngại rằng nếu EOF không được đưa vào Pectra thì những thay đổi mã này sẽ không bao giờ được đưa vào các bản nâng cấp Ethereum. Các nhà phát triển Geth Marius van der Wijden và Guillaume Ballet phản đối điều này, cho rằng lợi ích của EOF đủ đáng kể để tính hữu dụng của nó vẫn tồn tại ngay cả khi nó bị trì hoãn thêm một vài nhánh nữa.


Beiko khuyên bạn nên đạt được sự đồng thuận trước tiên về cách ưu tiên tăng kích thước ngang hàng và kích thước blob trước khi xác định phạm vi phần còn lại của bản nâng cấp. Ông khuyến nghị các nhà phát triển tham dự hội nghị Đồng thuận tất cả các nhà phát triển cốt lõi (ACDC) vào tuần tới hãy tập trung vào chủ đề này. Ông hy vọng các nhà phát triển sẽ sẵn sàng hoàn thiện phạm vi của Pectra tại cuộc họp ACDE tiếp theo.


Mạng cổng thông tin và lịch sử hết hạn


Cuối cùng, Merriam lưu ý rằng nhóm Portal Network đã sẵn sàng làm việc với các nhà phát triển Giao thức cộng tác để phát hành một phiên bản đã hết hạn trước đó song song với Pectra. Bạn có thể tìm thêm thông tin về Mạng Cổng thông tin tại đây Đã tìm thấy.


「Liên kết gốc‖


Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

Chọn thư viện
Thêm mới thư viện
Hủy
Hoàn thành
Thêm mới thư viện
Chỉ mình tôi có thể nhìn thấy
Công khai
Lưu
Báo lỗi/Báo cáo
Gửi