Chuyển tiếp Tiêu đề Gốc: Giải thích về Prague/Electra (Pectra) Hardfork

giới thiệu

Trong bài viết trước đó, chúng tôi đã đánh giá một cách toàn diện về vòng đời của các nhà xác thực Ethereum, thảo luận về một số khía cạnh liên quan đến bản nâng cấp Electra sắp tới. Bây giờ, đã đến lúc tập trung vào những thay đổi sắp tới trong cả hai bản nâng cấp Electra và Prague và giải thích chúng một cách chi tiết.

Lịch sử của Ethereum 2.0 "chứng minh cổ phần" là phức tạp. Nó bắt đầu với việc thêm lớp ngọn đèn vào lớp thực hiện hiện tại, khởi chạy sự công nhận chứng minh cổ phần trên lớp ngọn đèn trong khi vẫn duy trì chứng minh công việc trên lớp thực hiện (các hardfork Phase0 và Altair). PoS sau đó được kích hoạt hoàn toàn tại hardfork Bellatrix (mặc dù rút tiền chưa được kích hoạt). Sau đó, hardfork Capella cho phép rút tiền, hoàn tất chu kỳ xác nhận viên. Hardfork gần đây nhất, Deneb (thuộc bản nâng cấp Dencun (Deneb/Cancun)), mang lại sự sửa đổi nhỏ về thông số ngọn đèn, như cửa sổ thời gian để bao gồm chứng thực, xử lý thoát tự nguyện, và giới hạn chu trình xác nhận viên. Những thay đổi chính trong Dencun nằm ở lớp thực hiện, giới thiệu những đổi mới như giao dịch blob, khí gas blob, cam kết KZG cho các blob, và việc loại bỏ hoạt động SELFDESTRUCT.

Bây giờ, hardfork Prague/Electra giới thiệu nâng cấp đáng kể cho cả lớp thực thi và lớp đồng thuận. Là những người kiểm toán cho dự án Lido, trọng tâm chúng tôi chủ yếu là những thay đổi liên quan đến đồng thuận và sự thay đổi liên quan đến việc đặt cược trong hardfork này. Tuy nhiên, chúng ta không thể bỏ qua những thay đổi liên quan đến lớp thực thi ở Prague, vì chúng bao gồm các tính năng quan trọng ảnh hưởng đến mạng lưới Ethereum và các bộ xác thực. Hãy đi vào chi tiết về những thay đổi này.

Tổng quan cấp cao về Pectra

Electra giới thiệu nhiều tính năng cho tầng beacon. Các cập nhật chính bao gồm:

• Cho phép những người xác minh có số dư hiệu quả từ 32 đến 2048 ETH (thay vì cố định 32 ETH).
• Cho phép người xác minh khởi động quá trình rút lui với thông tin đăng nhập "rút lui" phụ (không cần khóa xác minh hoạt động).
• Thay đổi cách tiền gửi Eth1 được xử lý bởi lớp beacon (di chuyển khỏi phân tích sự kiện từ hợp đồng gửi tiền).
• Thêm một framework mới, đa dụng để xử lý yêu cầu từ các hợp đồng Eth1 thông thường trên lớp beacon (tương tự như cách gửi tiền được quản lý trước Electra).

Trong khi đó, Prague giới thiệu các thay đổi vào lớp thực thi, như:

• Một hợp đồng được biên soạn mới hỗ trợ đường cong BLS12-381 để xác minh chứng minh zkSNARK (ngoài đường cong BN254 phổ biến).
• Một hợp đồng hệ thống mới để lưu trữ và truy cập đến 8192 mã băm khối lịch sử (hữu ích cho các máy khách không lưu trạng thái).
• Chi phí gas calldata tăng để giảm kích thước khối và khuyến khích các dự án chuyển các hoạt động tập trung vào calldata (như rollups) sang blobs, được giới thiệu trong Dencun.
• Hỗ trợ cho một số lượng lớn hơn các blob trên mỗi khối Eth1, cùng với một API để đọc các con số này.
• Cho phép các EOA (Tài khoản Sở hữu Bên ngoài) có mã tài khoản riêng, mở rộng đáng kể những gì các EOA có thể thực hiện, như thực hiện các cuộc gọi đa chức năng hoặc ủy quyền thực thi cho các địa chỉ khác.

Hãy tham khảo các Đề xuất Cải thiện Ethereum (EIPs) liên quan để tạo điều kiện cho cuộc thảo luận tiếp theo:

• EIP-7251: Tăng MAX_EFFECTIVE_BALANCE
• EIP-7002: Các kích hoạt thoát tầng thực thi
• EIP-6110: Nạp tiền đặt cọc của người xác minh trên chuỗi
• EIP-7549: Di chuyển chỉ số ủy ban ra khỏi Xác nhận
• EIP-7685: Yêu cầu lớp thực thi mục đích chung
• EIP-2537: Precompile cho các phép toán đường cong BLS12-381
• EIP-2935: Lưu lịch sử mã hash khối trong trạng thái
• EIP-7623: Tăng chi phí calldata
• EIP-7691: tốc độ thông qua blob tăng lên
• EIP-7840: Thêm lịch blob vào tệp cấu hình EL
• EIP-7702: Thiết lập mã tài khoản EOA

Một số EIP này chủ yếu đề cập đến lớp đồng thuận (beacon), trong khi những cái khác liên quan đến lớp thực thi. Một số bao gồm cả hai lớp, vì một số hoạt động như gửi và rút tiền yêu cầu các thay đổi đồng bộ qua cả hai lớp đồng thuận và thực thi. Do sự phụ thuộc này, việc tách Electra và Prague là không thực tế, vì vậy chúng ta sẽ xem xét từng EIP theo trình tự và chỉ định thành phần Ethereum bị ảnh hưởng trong mỗi trường hợp.

EIP-7251: Tăng MAX_EFFECTIVE_BALANCE

Tham khảo: EIP-7251

Kể từ hardfork Giai đoạn 0 đầu tiên, được triển khai để chuẩn bị Ethereum cho Proof-of-Stake và cho đến Electra, số dư hiệu quả tối đa của trình xác thực đã được cố định ở mức 32 ETH. Kích hoạt trình xác thực yêu cầu ít nhất spec.min_activation_balance (32 ETH). Sau khi kích hoạt, trình xác thực bắt đầu với số dư hiệu quả tối đa này nhưng có thể giảm số dư hiệu quả của nó xuống mức spec.ejection_balance (16 ETH) và bị đẩy ra khi đạt đến ngưỡng đó. Logic "tối thiểu" này vẫn không thay đổi trong Electra, nhưng bây giờ spec.max_effective_balance đã tăng lên 2048 ETH. Do đó, trình xác thực có thể gửi bất kỳ khoản tiền nào từ 32 đến 2048 ETH để kích hoạt, với tất cả số tiền trong phạm vi này góp phần vào số dư hiệu quả của chúng. Sự thay đổi này đánh dấu một bước chuyển từ "bằng chứng cổ phần 32ETH" sang "bằng chứng cổ phần" :)

Số dư hiệu quả của biến này sẽ được sử dụng bây giờ:

• để tăng khả năng trở thành người đề xuất khối, tỷ lệ thuận với số dư hiệu quả
• để tăng khả năng trở thành thành viên ủy ban đồng bộ, cân đối với số dư hiệu quả
• như một cơ sở để tính toán số tiền phạt cắt giảm tương đối và không hoạt động

Hai hoạt động đầu tiên là những hành động đáng giá nhất đối với các máy chủ xác thực. Do đó, sau Electra, các máy chủ xác thực có số cổ phần lớn hơn sẽ tham gia thường xuyên hơn trong việc đề xuất khối và đồng bộ hóa ủy ban, tỷ lệ với số dư hiệu quả của họ.

Một hiệu ứng khác liên quan đến việc cắt giảm. Tất cả các khoản phạt cắt giảm đều tỷ lệ với số dư hiệu quả của máy chủ xác thực:

• “Ngay lập tức” và “hoãn” phạt cắt giảm lớn hơn đối với các người xác minh có cổ phần cao hơn.
• Hình phạt cắt giảm "hoãn lại" đối với người xác thực bị cắt giảm cùng với người xác thực cổ phần lớn cũng lớn hơn, vì phần "bị cắt" trong tổng số cổ phần trở nên lớn hơn.
• Một người tiết lộ thông tin báo cáo một người xác minh có số dư hiệu quả cao hơn sẽ nhận được một phần lớn hơn của số cược bị cắt.

Electra cũng đề xuất thay đổi trong tỷ lệ cắt giảm, xác định một phần nhỏ của số dư của các nhà xác thực bị cắt giảm và nhận được bởi người tố cáo.

Tác động của sự không hoạt động là tiếp theo. Khi một người xác nhận không hoạt động trong khi hoạt động (chứng minh hoặc đề xuất), một điểm số không hoạt động tích lũy, dẫn đến áp đặt các khoản phạt không hoạt động mỗi kỷ nguyên. Những khoản phạt này cũng tỷ lệ với số dư hiệu quả của người xác nhận.

Validator “churn limits” cũng trải qua các thay đổi do tăng số dư hiệu quả. Trong Ethereum “trước Electra”, các nhà xác thực thông thường có cùng số dư hiệu quả, và giới hạn thoát churn được xác định là “không quá 1/65536 (churn_limit_quotient spec) tổng số cược có thể thoát trong một kỷ nguyên.” Điều này tạo ra một số lượng nhà xác thực thoát cố định với cùng số cược. Tuy nhiên, trong “sau Electra,” một tình huống có thể xảy ra là chỉ có một vài “cá voi” thoát, vì họ đại diện cho một phần đáng kể của tổng số cược.

Một yếu tố khác cần xem xét là việc quay vòng của nhiều khóa xác nhận trên một phiên bản xác nhận duy nhất. Các nhà xác nhận lớn hiện đang bị ép phải chạy hàng ngàn khóa xác nhận trên một phiên bản duy nhất để đáp ứng các cược lớn, chia chúng thành các phần 32 ETH. Với Electra, hành vi này không còn bắt buộc nữa. Về mặt tài chính, sự thay đổi này không tạo ra sự khác biệt nhiều vì phần thưởng và xác suất tăng tuyến tính theo số tiền đặt cược. Do đó, 100 nhà xác nhận với mỗi nhà xác nhận 32 ETH tương đương với một nhà xác nhận có 3200 ETH. Ngoài ra, nhiều khóa xác nhận hoạt động có thể có cùng thông tin rút tiền Eth1, cho phép tất cả phần thưởng được rút về một địa chỉ ETH duy nhất và tránh chi phí gas liên quan đến việc kết hợp phần thưởng. Tuy nhiên, quản lý một số lượng lớn khóa mang lại chi phí quản trị bổ sung.

Khả năng tổng hợp số dư của các validator thêm một loại yêu cầu lớp thực thi khác. Trước đây, chúng ta đã có tiền gửi và rút tiền. Bây giờ, sẽ có một loại khác: yêu cầu tổng hợp. Nó sẽ sáp nhập hai validator thành một. Yêu cầu hoạt động này sẽ bao gồm pubkey của validator nguồn và pubkey mục tiêu, và sẽ được xử lý tương tự như tiền gửi và rút tiền. Các tổng hợp cũng sẽ có yêu cầu đang chờ và giới hạn biến động số dư, giống như tiền gửi và rút tiền.

Tóm lại:

• Đối với các nhà xác thực solo nhỏ, Electra giới thiệu khả năng tăng tự động số dư hiệu quả của họ (và phần thưởng). Trước đây, bất kỳ dư thừa nào vượt qua 32 ETH chỉ có thể được rút ra, nhưng sau Electra, dư thừa này sẽ cuối cùng đóng góp vào số dư hiệu quả của họ. Tuy nhiên, số dư hiệu quả chỉ có thể tăng lên theo bội số của spec.effective_balance_increment (1 ETH), có nghĩa là sự tăng chỉ xảy ra sau khi đạt đến ngưỡng “1 ETH” tiếp theo.
• Đối với các nhà xác minh lớn độc lập, Electra cung cấp việc quản lý đơn giản đáng kể bằng cách cho phép gộp nhiều khóa xác minh hoạt động thành một. Mặc dù không phải là một trò chơi thay đổi, vận hành một lượng cược duy nhất 1x2048 không thể phủ nhận là đơn giản hơn việc quản lý 64x32 lượng cược.
• Đối với các nhà cung cấp cọc lỏng, họ thu thập cọc nhỏ từ người dùng và phân phối chúng cho các người xác nhận, Electra tạo thêm tính linh hoạt trong kế hoạch phân phối cọc nhưng đồng thời yêu cầu sửa đổi nghiêm túc trong việc tính toán người xác nhận, hiện tại dựa trên số dư hiệu quả cố định là 32 ETH.

Một chủ đề quan trọng khác là dữ liệu lịch sử và ước tính lợi nhuận cho các validator, điều này đặc biệt quan trọng đối với những người mới tham gia cố gắng đánh giá rủi ro và lợi tức. Giới hạn 32 ETH (cả tối thiểu và tối đa, trong thực tế) trước Electra (tính đến thời điểm viết bài này) tạo ra tính đồng nhất trong dữ liệu lịch sử. Tất cả các validator đều có số dư hiệu quả, phần thưởng, mức phạt cắt giảm cá nhân, tần suất đề xuất khối và các chỉ số khác nhau. Tính đồng nhất này cho phép Ethereum thử nghiệm cơ chế đồng thuận của mình với một số lượng lớn các validator mà không có các giá trị ngoại lai thống kê, thu thập dữ liệu về hành vi mạng có giá trị.

Sau Electra, phân phối cổ phần sẽ thay đổi đáng kể. Những người xác thực lớn sẽ tham gia thường xuyên hơn trong việc đề xuất khối và ủy ban đồng bộ hóa, nhận những khoản phạt lớn hơn trong các sự kiện cắt giảm, và có ảnh hưởng lớn hơn đối với việc cắt giảm trì hoãn, hàng đợi kích hoạt và hàng đợi thoát. Mặc dù điều này có thể tạo ra thách thức trong việc tổng hợp dữ liệu, sự đồng thuận của Ethereum đảm bảo rằng các tính toán phi tuyến tính là tối thiểu. Thành phần phi tuyến duy nhất sử dụng sqrt(total_effective_balance) để tính toán phần thưởng cơ bản, áp dụng đồng đều cho tất cả các người xác thực. Điều này có nghĩa là phần thưởng và các khoản cắt giảm của người xác thực vẫn có thể được ước lượng trên cơ sở “mỗi 1 ETH” (hoặc, chính xác hơn, trên cơ sở spec.effective_balance_increment, có thể thay đổi trong tương lai).

Để biết thêm chi tiết, vui lòng tham khảo bài viết trước đó của chúng tôi về hành vi của máy chủ xác thực.

EIP-7002: Execution layer triggerable exits

Tham khảo: EIP-7002

Mỗi người xác thực trong Ethereum đều có hai cặp khóa: một khóa hoạt động và một khóa rút tiền. Khóa công cộng BLS hoạt động đóng vai trò là danh tính chính của người xác thực trong chuỗi màu sắc, và cặp khóa này được sử dụng để ký các khối, chứng nhận, đốt cháy, tổng hợp ủy ban đồng bộ, và (cho đến EIP này) thoát tự nguyện (để bắt đầu quá trình thoát của người xác thực khỏi sự đồng thuận sau một khoảng thời gian chờ). Cặp khóa thứ hai (“chứng chỉ rút tiền”) có thể là một cặp khóa BLS khác hoặc một tài khoản Eth1 thông thường (khóa riêng và địa chỉ). Bây giờ, việc rút tiền đến một địa chỉ ETH đòi hỏi một tin nhắn rút tiền được ký bởi khóa riêng BLS hoạt động.

Trong thực tế, chủ sở hữu của hai cặp khóa (hoạt động và rút tiền) này có thể khác nhau. Khóa hoạt động của trình xác thực chịu trách nhiệm xác thực: chạy máy chủ, giữ cho chúng hoạt động, v.v., trong khi thông tin rút tiền thường được kiểm soát bởi chủ sở hữu cổ phần, người nhận phần thưởng và chịu trách nhiệm về tiền. Hiện tại, chủ sở hữu cổ phần chỉ kiểm soát thông tin rút tiền không thể bắt đầu thoát của trình xác thực và chỉ có thể rút phần thưởng. Tình huống này cho phép chủ sở hữu khóa hoạt động của trình xác thực giữ hiệu quả số dư của trình xác thực là "con tin". Người xác thực có thể "ký trước" các thông báo thoát và đưa chúng cho chủ sở hữu cổ phần, nhưng cách giải quyết này không lý tưởng. Hơn nữa, cả rút tiền và thoát hiện đều yêu cầu tương tác với trình xác thực lớp đèn hiệu bằng các API chuyên dụng.

Giải pháp tối ưu là cho phép chủ sở hữu cổ phần thực hiện cả thao tác thoát ra và rút tiền bằng cách gọi hợp đồng thông thường thông qua smart contract. Điều này liên quan đến việc kiểm tra chữ ký Eth1 tiêu chuẩn, giúp đơn giản hóa các hoạt động.

EIP này cho phép chủ sở hữu cổ phần kích hoạt việc rút tiền và thoát khỏi thông qua giao dịch tiêu chuẩn từ địa chỉ ETH của họ đến một hợp đồng thông minh cụ thể (tương tự quy trình gửi tiền hiện tại sử dụng hợp đồng “Deposit”). Quy trình rút tiền (hoặc thoát nếu cổ phần đủ được rút) hoạt động như sau:

• Người sở hữu cổ phần gửi yêu cầu rút tiền (yêu cầu “in”) đến hợp đồng “Rút tiền” của hệ thống.
• Hợp đồng tính phí cụ thể (trong ETH) để giảm thiểu các cuộc tấn công gây phiền toái tiềm ẩn và hoạt động tương tự như EIP-1559, với việc phí tăng khi hàng đợi yêu cầu đang bận rộn.
• Hợp đồng lưu trữ yêu cầu rút/ra “in” vào bộ nhớ của mình.
• Khi một block được đề xuất đến tầng beacon, các yêu cầu rút/giao dịch "in" trong hàng đợi được lấy từ bộ nhớ.
• Layer beacon xử lý các yêu cầu "trong", tương tác với số dư của người xác minh hoạt động, lên lịch cho người xác minh ra khỏi, và tạo ra các yêu cầu rút "ra".
• Các yêu cầu rút "out" được xử lý trên lớp thực thi, và chủ sở hữu cổ phần nhận ETH của họ.

Trong khi tiền gửi được thực hiện trong các giao dịch Eth1 và sau đó “di chuyển” sang lớp Beacon bằng cách sử dụng hàng đợi tiền gửi “đang chờ xử lý”, rút tiền tuân theo một cách thức khác. Chúng được kích hoạt tại lớp Beacon (qua CLI) và sau đó “di chuyển” sang các giao dịch Eth1. Bây giờ, cả hai cách thức đều sẽ hoạt động bằng cách sử dụng cùng một khung cơ bản (được mô tả dưới đây): tạo yêu cầu tại lớp Eth1, xử lý hàng đợi tiền gửi/rút tiền/tái tập kết “đang chờ xử lý”, và xử lý tại lớp Beacon. Đối với các hoạt động “đầu ra” như rút tiền, hàng đợi đầu ra cũng được xử lý, và kết quả được “giải quyết” trong các giao dịch Eth1.

Với EIP này, chủ sở hữu cổ phần có thể rút và thoát khỏi các validator của họ bằng cách sử dụng giao dịch ETH thông thường mà không cần phải tương tác trực tiếp với validator CLI hoặc truy cập cơ sở hạ tầng của các validator. Điều này giúp đơn giản hóa hoạt động cọc tiền, đặc biệt là đối với các nhà cung cấp cọc tiền lớn. Cơ sở hạ tầng của các validator hiện có thể được gần như hoàn toàn cách ly, vì chỉ có các khóa validator hoạt động cần được duy trì, trong khi tất cả hoạt động cọc tiền có thể được xử lý ở nơi khác. Nó loại bỏ nhu cầu cho các người cọc đơn độc phải chờ đợi các hành động của các validator hoạt động và đơn giản hóa đáng kể các phần ngoại chuỗi cho các dịch vụ như Mô-đun Cọc Cộng Đồng từ Lido.

Kết quả, EIP này 'hoàn thành' các hoạt động đặt cọc bằng cách di chuyển hoàn toàn chúng đến lớp Eth1, giảm đáng kể các rủi ro an ninh cơ sở hạ tầng, và tăng cường sự phi tập trung của các sáng kiến đặt cọc độc lập.

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

Tham khảo: EIP-6110

Hiện tại, các khoản tiền gửi được thực hiện thông qua sự kiện trong hợp đồng “Tiền gửi” trong hệ thống (như đã thảo luận chi tiết trong một bài viết trước đó). Hợp đồng chấp nhận ETH và thông tin xác thực của người xác thực, phát ra sự kiện “Deposit()”, và những sự kiện này sau đó được phân tích và chuyển đổi thành yêu cầu gửi tiền trên tầng beacon. Hệ thống này có nhiều hạn chế: nó yêu cầu bỏ phiếu cho eth1data trên tầng beacon chain, điều này làm tăng đáng kể thời gian chờ đợi. Ngoài ra, tầng beacon cần truy vấn tầng thực thi, đưa vào sự phức tạp thêm. Những vấn đề này được thảo luận chi tiết trong EIP. Một phương pháp đơn giản hơn, loại bỏ nhiều trong số những vấn đề này, bao gồm việc trực tiếp bao gồm yêu cầu gửi tiền trong các khối Eth1 tại một vị trí được chỉ định. Cơ chế này tương tự như quá trình xử lý rút tiền mà đã được mô tả trong EIP trước đó.

Các thay đổi được đề xuất trong EIP này là hứa hẹn. Việc xử lý eth1data hiện có thể được loại bỏ hoàn toàn, loại bỏ nhu cầu bỏ phiếu hoặc trì hoãn lâu giữa các sự kiện trên bên Eth1 và việc bao gồm tiền gửi trên lớp beacon (hiện khoảng 12 giờ). Nó cũng loại bỏ logic cho các bản chụp hợp đồng gửi tiền. EIP này tối ưu hóa việc xử lý tiền gửi và điều chỉnh nó với hệ thống xử lý rút tiền đã được mô tả ở trên.

Đối với cả chủ sở hữu cổ phần và người xác minh, những thay đổi này giảm đáng kể thời gian chờ đợi giữa khoản tiền gửi và kích hoạt người xác minh. Việc nạp tiền, cần thiết khi một người xác minh bị cắt giảm, cũng sẽ nhanh hơn.

Không có nhiều điều để nói về EIP này ngoài việc loại bỏ logic lỗi thời, đơn giản hóa quy trình và tạo ra kết quả tốt hơn cho tất cả mọi người liên quan.

EIP-7685: Yêu cầu lớp thực thi mục đích chung

Tham khảo: EIP-7685

EIP này có lẽ nên được trình bày trước ba EIP liên quan đến việc gửi/rút/ghi chép trước đó, vì nó là nền tảng cho chúng. Tuy nhiên, nó được giới thiệu ở đây để nhấn mạnh nhu cầu ngày càng tăng về cơ chế tổng quát để di chuyển dữ liệu chuyên biệt một cách nhất quán giữa các khối (lớp) Eth1 (thực thi) và Beacon (đồng thuận). EIP này ảnh hưởng đến cả hai lớp, làm cho việc xử lý các yêu cầu được kích hoạt bởi giao dịch ETH thông thường trở nên hiệu quả hơn. Hiện tại, chúng tôi quan sát:

• Các sự kiện nạp tiền trong các khối Eth1 đang được “di chuyển” từ Eth1 sang các khối Beacon để xử lý.
• Yêu cầu rút tiền trong các khối Beacon (sử dụng CLI) đang được “di chuyển” đến các khối Eth1 để xử lý.
• Sự cần thiết phải xử lý hợp nhất trình xác thực, đó cũng là các yêu cầu Eth1->Beacon.

Ba hoạt động này cho thấy sự cần thiết của việc xử lý nhất quán cho các loại yêu cầu khác nhau khi chuyển đổi giữa các lớp thực thi và beacon. Ngoài ra, chúng tôi cần khả năng kích hoạt các hoạt động này chỉ bằng Eth1 layer, vì điều này sẽ cho phép chúng tôi cô lập cơ sở hạ tầng của các nhà xác nhận từ cơ sở hạ tầng quản lý cổ phần, tăng cường bảo mật. Do đó, một giải pháp chung cho việc quản lý các yêu cầu như vậy là cả thực tế và cần thiết.

EIP này thiết lập một framework cho ít nhất ba trường hợp chính: tiền gửi, rút tiền và hợp nhất. Đó là lý do tại sao các EIP trước đã giới thiệu các trường như WITHDRAWAL_REQUEST_TYPE và DEPOSIT_REQUEST_TYPE, và bây giờ hợp nhất sẽ thêm một trường khác, CONSOLIDATION_REQUEST_TYPE. Ngoài ra, EIP này có thể bao gồm cơ chế chung để xử lý giới hạn cho các yêu cầu như (các hằng số tham chiếu: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Mặc dù chi tiết về việc triển khai framework này vẫn chưa được công bố, nhưng chắc chắn nó sẽ bao gồm các loại yêu cầu chính, cơ chế tích hợp (ví dụ, hashing và Merkle-izing yêu cầu), và xử lý hàng đợi đang chờ với giới hạn tốc độ.

EIP này mang ý nghĩa kiến trúc, cho phép Eth1 kích hoạt các hành động quan trọng trong tầng Beacon thông qua một khung làm việc thống nhất. Đối với người dùng cuối và dự án, điều này có nghĩa là tất cả các yêu cầu được kích hoạt tại tầng Eth1 sẽ được gửi và xử lý trên tầng Beacon một cách hiệu quả hơn nhiều.

EIP-2537: Precompile cho các hoạt động trên đường cong BLS12-381

Tham khảo: EIP-2537

Nếu bạn không muốn đào sâu, bạn có thể coi BLS12-381 precompile như một phép toán mã hóa phức tạp "hashing" có thể được sử dụng trong hợp đồng thông minh. Đối với những người quan tâm, hãy khám phá thêm về điều này.

Các phép toán toán học trên đường cong elip như BLS12-381 (và đối tác của nó: BN-254) hiện đang được sử dụng cho hai mục đích chính:

• Chữ ký BLS, trong đó một phép toán đặc biệt gọi là “pairing” được sử dụng để xác minh những chữ ký này. Chữ ký BLS được sử dụng rộng rãi bởi các thợ đào vì chúng cho phép tổng hợp nhiều chữ ký thành một. Các thợ đào tin tưởng vào chữ ký BLS dựa trên đường cong BLS12-381 (mặc dù chúng cũng có thể được triển khai bằng bất kỳ đường cong nào hỗ trợ pairings, chẳng hạn như BN254).
• Xác minh chứng minh zkSNARK, nơi cặp được sử dụng để xác minh chứng minh. Ngoài ra, các cam kết KZG tới các khối (giới thiệu bởi cặp không gian Dencun) cũng sử dụng cặp để xác minh cam kết khối.

Nếu bạn muốn xác minh chữ ký BLS hoặc chứng minh zkSNARK trong một hợp đồng thông minh, bạn phải tính toán những "cặp" này mà tính toán rất tốn kém. Ethereum đã có một hợp đồng được biên soạn trước cho các hoạt động đường cong BN254 (EIP-196 và EIP-197). Tuy nhiên, đường cong BLS12-381 (được công nhận là an toàn hơn và được sử dụng rộng rãi hơn ngày nay) chưa được triển khai như một biên soạn trước. Mà không có biên soạn như vậy, triển khai cặp và các hoạt động đường cong khác trong hợp đồng thông minh đòi hỏi tính toán nặng nề, như được thể hiện ở đây, và tiêu tốn lượng khí khổng lồ (~10^5 đến 10^6 khí).

EIP này mở ra cánh cửa cho nhiều ứng dụng tiềm năng, đặc biệt là trong việc cho phép xác minh chữ ký BLS giá rẻ dựa trên đường cong BLS12-381. Điều này làm cho nó có thể thực hiện các sơ đồ ngưỡng cho các mục đích khác nhau. Như đã đề cập trước đó, trình xác thực Ethereum đã sử dụng chữ ký dựa trên BLS12-381. Với EIP này, các hợp đồng thông minh tiêu chuẩn hiện có thể thực hiện xác minh hiệu quả các chữ ký xác thực tổng hợp. Điều này có thể đơn giản hóa các bằng chứng đồng thuận và cầu nối tài sản giữa các mạng, vì chữ ký BLS được sử dụng rộng rãi trên các blockchain. Bản thân chữ ký BLS ngưỡng cho phép xây dựng nhiều sơ đồ ngưỡng hiệu quả để bỏ phiếu, tạo số ngẫu nhiên phi tập trung, multisigs, v.v.

Việc xác minh bằng chứng zkSNARK rẻ hơn sẽ mở ra nhiều ứng dụng mới. Nhiều giải pháp dựa trên zkSNARK hiện đang bị hạn chế bởi chi phí cao của việc xác minh bằng chứng, khiến cho một số dự án gần như không thực tế. EIP này có tiềm năng thay đổi điều đó.

EIP-2935: Lưu các mã hash khối lịch sử trong trạng thái

Tham khảo: EIP-2935

Đề xuất EIP này lưu trữ 8192 (~27.3 giờ) mã hash khối lịch sử trong trạng thái blockchain, cung cấp một lịch sử mở rộng cho các khách hàng không trạng thái (như rollups) và hợp đồng thông minh. Nó đề xuất giữ nguyên hành vi hiện tại của mã opcode BLOCKHASH, duy trì hạn chế đến 256 khối, trong khi giới thiệu một hợp đồng hệ thống mới được thiết kế đặc biệt để lưu trữ và truy xuất các mã hash lịch sử. Hợp đồng này thực hiện một hoạt động set() khi lớp thực thi xử lý một khối. Phương thức get() của nó, có thể truy cập bởi bất kỳ ai, truy xuất mã hash khối cần thiết từ bộ đệm vòng.

Hiện tại, trong EVM, có thể tham chiếu đến các hash khối lịch sử, nhưng quyền truy cập bị hạn chế trong 256 khối gần nhất (khoảng 50 phút). Tuy nhiên, có những trường hợp cần truy cập dữ liệu khối cũ quan trọng, như cho các ứng dụng cross-chain (yêu cầu chứng minh dữ liệu từ các khối trước) và stateless clients, mà định kỳ cần truy cập đến các hash khối trước đó.

EIP này mở rộng khung thời gian có sẵn cho rollups và ứng dụng cross-chain, cho phép họ truy cập dữ liệu lịch sử trực tiếp trong EVM mà không cần phải thu thập nó từ bên ngoài. Kết quả là, những giải pháp này trở nên mạnh mẽ và bền vững hơn.

EIP-7623: Tăng chi phí calldata

Tham khảo: EIP-7623

Chi phí calldata điều chỉnh kích thước có sẵn của các gói giao dịch, trong một số trường hợp có thể khá lớn (ví dụ, khi truyền mảng lớn hoặc bộ đệm nhị phân như là tham số). Việc sử dụng calldata đáng kể chủ yếu được gán cho rollups, gửi các gói dữ liệu qua calldata chứa trạng thái rollup hiện tại.

Khả năng giới thiệu dữ liệu nhị phân lớn, có thể chứng minh được vào blockchain là điều cần thiết cho các bản tổng hợp. Bản nâng cấp Dencun (Deneb-Cancun) đã giới thiệu một sự đổi mới lớn cho các trường hợp sử dụng như vậy - giao dịch blob (EIP-4844). Các giao dịch blob có phí gas "blob" chuyên dụng của riêng chúng và trong khi cơ thể của chúng được lưu trữ tạm thời, các bằng chứng mật mã của chúng (cam kết KZG), cùng với hàm băm của chúng, được tích hợp vào lớp đồng thuận. Do đó, Blobs cung cấp một giải pháp ưu việt cho các bản tổng hợp so với việc sử dụng calldata để lưu trữ dữ liệu.

Khuyến khích rollups chuyển dữ liệu của họ sang các blog có thể được đạt được bằng cách sử dụng một cách tiếp cận "cây gậy và cà rốt". Phí gas blog giảm được xem như "cà rốt," trong khi EIP này hoạt động như "cây gậy" bằng cách tăng chi phí calldata, từ đó ngăn chặn việc lưu trữ dữ liệu quá mức trong giao dịch. EIP này bổ sung cho EIP tiếp theo-7691 (Tăng thông lượng Blob), nâng số lượng blob tối đa được phép mỗi khối.

EIP-7691: Tăng tốc độ thông qua dữ liệu lớn

Tham khảo: EIP-7691

Blobs đã được giới thiệu trong hard fork Dencun trước đó, và các giá trị ban đầu cho số lượng tối đa và mục tiêu của "mỗi khối" blobs là ước tính thận trọng. Điều này là do sự phức tạp trong việc dự đoán cách mạng p2p sẽ xử lý sự lan truyền của các đối tượng nhị phân lớn giữa các nút xác minh. Cấu hình ban đầu đã được chứng minh là hoạt động tốt, điều này là thời gian thích hợp để thử nghiệm các giá trị mới. Trước đó, số lượng mục tiêu/tối đa của blobs mỗi khối đã được đặt ở mức 3/6. Giới hạn này hiện đang được nâng lên thành 6/9, tương ứng.

Khi kết hợp với EIP-7623 trước đó (Tăng chi phí calldata), điều chỉnh này thúc đẩy rollups chuyển dữ liệu của họ từ calldata sang blobs. Việc tìm kiếm các thông số blob tối ưu tiếp tục.

EIP-7840: Thêm lịch trình blob vào tệp cấu hình EL

Tham khảo: EIP-7840

EIP này đề xuất thêm các giá trị mục tiêu và tối đa của các blob “mỗi khối” (đã thảo luận trước đó) và các giá trị baseFeeUpdateFraction vào các tệp cấu hình Ethereum Execution Layer (EL). Nó cũng cho phép các client truy xuất các giá trị này thông qua API của node. Tính năng này đặc biệt hữu ích cho các công việc như ước lượng phí gas của blob.

EIP-7702: Đặt mã tài khoản EOA

Tham khảo: EIP-7702

Đây là một EIP rất quan trọng sẽ mang lại những thay đổi lớn cho người dùng Ethereum. Như chúng ta đã biết, EOA (Tài khoản thuộc sở hữu bên ngoài) không thể có bất kỳ mã nào nhưng có thể cung cấp chữ ký giao dịch (tx.origin). Ngược lại, một hợp đồng thông minh có bytecode nhưng không thể đưa ra chữ ký trực tiếp "của nó". Bất kỳ tương tác nào từ người dùng yêu cầu logic bổ sung, tự động và có thể xác minh hiện chỉ có thể đạt được bằng cách gọi hợp đồng bên ngoài để thực hiện các hành động cần thiết. Tuy nhiên, trong những trường hợp như vậy, hợp đồng bên ngoài trở thành msg.sender cho các hợp đồng tiếp theo, thực hiện cuộc gọi "một cuộc gọi từ hợp đồng, không phải người dùng".

EIP này giới thiệu một loại giao dịch mới SET_CODE_TX_TYPE=0x04 (trước đó chúng ta đã có các giao dịch cũ 0x1, các giao dịch mới hơn 0x02 từ các bản nâng cấp Berlin và EIP-1559, và các giao dịch blob 0x03 được giới thiệu trong Dencun). Loại giao dịch mới này cho phép thiết lập mã cho tài khoản EOA. Điều này cho phép tài khoản EOA thực thi mã ngoại vi “trong ngữ cảnh của tài khoản EOA của chính nó”. Từ một góc độ bên ngoài, trong quá trình giao dịch, tài khoản EOA “mượn” mã từ một hợp đồng bên ngoài và thực thi nó. Kỹ thuật, điều này được thực hiện bằng cách thêm các bộ dữ liệu ủy quyền đặc biệt vào kho mã của địa chỉ EOA (trước EIP này, kho mã này luôn trống cho các tài khoản EOA).

Hiện tại, EIP này đề xuất rằng loại giao dịch mới 0x04 bao gồm một mảng:

authorization_list = [[chain_id, địa chỉ, nonce, y_parity, r, s], …]

mỗi phần tử cho phép tài khoản sử dụng mã từ địa chỉ cụ thể (từ mục ủy quyền hợp lệ cuối cùng). Xử lý giao dịch như vậy đặt mã của EOA đã cho thành giá trị đặc biệt 0xef0100 || địa chỉ (23 byte), trong đó địa chỉ trỏ đến một hợp đồng với mã mong muốn được thực thi, || biểu thị nối, và 0xef0100 đại diện cho một giá trị đặc biệt ma thuật mà hợp đồng thông minh thông thường không thể chứa (theo EIP-3541). Giá trị ma thuật này đảm bảo rằng EOA này không thể được xử lý như một hợp đồng thông thường hoặc có cuộc gọi được thực hiện đến nó như vậy.

Khi EOA này khởi tạo một giao dịch, địa chỉ cụ thể sẽ được sử dụng để gọi mã tương ứng trong ngữ cảnh của EOA đó. Mặc dù chi tiết triển khai đầy đủ của EIP này vẫn chưa biết, nhưng chắc chắn rằng nó sẽ mang lại những thay đổi đáng kể.

Một tác động quan trọng khác là khả năng thực hiện các cuộc gọi đa bằng cách trực tiếp từ một EOA. Cuộc gọi đa là một xu hướng liên tục trong DeFi, với nhiều giao thức cung cấp tính năng này như một công cụ mạnh mẽ (ví dụ như Uniswap V4, Balancer V3 hoặc Euler V2). Với EIP này, cuộc gọi đa hiện có thể được thực hiện trực tiếp từ các EOA.

Ví dụ: tính năng mới này giải quyết một vấn đề phổ biến trong DeFi: sự kém hiệu quả của approve() + anything() yêu cầu hai giao dịch riêng biệt. EIP này cho phép logic "phê duyệt trước" chung, cho phép các hành động như phê duyệt (X) + tiền gửi (X) được hoàn thành trong một giao dịch duy nhất.

Một lợi ích khác được giới thiệu bởi khả năng ủy quyền thực thi giao dịch "thay mặt" cho một EOA là khái niệm về bảo trợ. Việc bảo trợ thường được thảo luận và là tính năng được mong đợi cao cho việc đưa người dùng mới vào Ethereum.

Logic có thể lập trình liên quan đến EOA mở ra nhiều khả năng, chẳng hạn như thực hiện các hạn chế bảo mật, đặt giới hạn chi tiêu, áp dụng yêu cầu KYC và nhiều hơn nữa.

Tự nhiên, sự chuyển đổi này cũng đặt ra nhiều câu hỏi về thiết kế. Một vấn đề là việc sử dụng chain_id, quyết định xem chữ ký cùng có thể hoặc không thể hợp lệ trên nhiều mạng dựa trên việc bao gồm hoặc loại trừ nó trong chữ ký. Một vấn đề phức tạp khác là việc sử dụng địa chỉ của mã mục tiêu so với việc nhúng bytecode thực tế. Cả hai phương pháp đều có những đặc điểm và hạn chế riêng. Ngoài ra, việc sử dụng nonce đóng vai trò quan trọng trong việc xác định xem quyền hạn có phải là “đa sử dụng” hay “đơn sử dụng.” Những yếu tố này ảnh hưởng đến các tính năng và mối quan tâm về bảo mật, bao gồm các khía cạnh như việc vô hiệu hóa hàng loạt chữ ký và tính dễ sử dụng. Vitalik đã đặt ra những câu hỏi này trong một cuộc thảo luận (tại đây), đáng để khám phá thêm.

Chú ý rằng thay đổi này sẽ ảnh hưởng đến một trong các cơ chế bảo mật của Ethereum, tx.origin. Thông tin chi tiết hơn về việc triển khai của EIP này là cần thiết, nhưng có vẻ như hành vi của require(tx.origin == msg.sender) sẽ thay đổi. Kiểm tra này đã là cách đáng tin cậy nhất để đảm bảo rằng msg.sender là một EOA và KHÔNG phải là một hợp đồng. Các phương pháp khác, như kiểm tra EXTCODESIZE (để kiểm tra xem đó có phải là một hợp đồng), thường thất bại và có thể được bypass (ví dụ, bằng cách gọi từ constructor hoặc bằng cách triển khai mã tại một địa chỉ đã được xác định trước sau giao dịch). Những kiểm tra này đã được sử dụng để ngăn chặn tấn công reentrancy và flashloan nhưng xa lìa khá xa khá lý tưởng vì chúng cũng ngăn chặn tích hợp với các giao thức bên ngoài. Sau EIP này, thậm chí kiểm tra đáng tin cậy require(tx.origin == msg.sender) cũng có vẻ trở nên lỗi thời. Giao thức phải thích nghi bằng cách loại bỏ các kiểm tra như vậy, vì sự phân biệt giữa “EOA” và “hợp đồng” sẽ không còn áp dụng nữa — bây giờ mọi địa chỉ đều có thể tiềm ẩn mã liên quan.

Sự phân biệt truyền thống giữa EOA và hợp đồng thông minh tiếp tục mờ nhạt. EIP này đưa Ethereum gần hơn với các thiết kế như TON, nơi mỗi tài khoản về cơ bản là mã thực thi. Sự tiến hóa này là tự nhiên khi tương tác với giao thức trở nên ngày càng phức tạp, làm cho việc sử dụng logic có thể lập trình cần thiết để cải thiện trải nghiệm người dùng cuối.

Kết luận

Nâng cấp Prague/Electra (Pectra) được lên lịch vào tháng 3 năm 2025. Những thay đổi quan trọng nhất được dự định bao gồm:

• Biến thể của cổ đông hiệu quả, lên đến 2048 ETH, sẽ thay đổi đáng kể phân phối cổ phần, lịch trình cổ đông, và đơn giản hóa quản lý cho các nhà cung cấp cổ phần lớn bằng cách tập trung cổ phần nhỏ hơn
• tương tác cải thiện giữa lớp thực thi-thống nhất, tối ưu hóa việc trao đổi dữ liệu giữa các khối thực thi Eth1 và các khối Beacon chain. Điều này sẽ đơn giản hóa đáng kể việc gửi tiền, kích hoạt, rút tiền và thoát ra, tăng tốc các quy trình này và đặt nền móng cho các tương tác tiếp theo giữa các lớp thống nhất và thực thi
• hỗ trợ cho việc xác thực chữ ký BLS và zkSNARK rẻ hơn trực tiếp trong hợp đồng thông minh thông qua việc tiền xử lý "thân thiện với cặp" BLS12-381 mới
• tiếp tục khuyến khích rollups chuyển sang giao dịch blob thay vì calldata bằng cách tăng ngưỡng giao dịch blob và tăng chi phí calldata
• cho phép EOAs hoạt động như các tài khoản có thể lập trình, trao cho chúng các tính năng như multicalls, sponsorships và các chức năng nâng cao khác

Như bạn có thể thấy, Pectra sẽ ảnh hưởng đáng kể đến cả hai lớp staking và consensus, cũng như trải nghiệm của người dùng cuối ở lớp thực thi. Mặc dù chúng tôi không thể phân tích tất cả những thay đổi này chi tiết thông qua mã code ở giai đoạn này, khi phát triển đang diễn ra, chúng tôi sẽ bao gồm những cập nhật này trong các bài viết tương lai.

Tuyên bố miễn trừ:

1. Bài viết này được sao chép từ [ TechFlow]. Chuyển tiếp Tiêu đề gốc: Giải thích sự cố Hardfork Prague/Electra (Pectra). Bản quyền thuộc về tác giả gốc [MixBytes]. Nếu bạn có bất kỳ sự phản đối nào về việc tái bản, vui lòng liên hệ Đội ngũ Học viện Gatevà nhóm sẽ xử lý ngay khi có thể theo các quy trình liên quan.
2. 免责声明：本文中表达的观点仅代表作者个人观点，不构成任何投资建议。
3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Học của gate. Trừ khi có quy định khác, bài viết dịch có thể không được sao chép, phân phối hoặc đạo văn.