Phân tích cuộc chia tách cứng sắp tới của Ethereum: Bản nâng cấp Pectra
Tuyển chọn TechFlowTuyển chọn TechFlow
Phân tích cuộc chia tách cứng sắp tới của Ethereum: Bản nâng cấp Pectra
Nâng cấp Prague /Electra (Pectra) dự kiến vào tháng 3 năm 2025.
Chuyên sâu báo cáo Web3Tác giả:Sergey Boogerwooger、Dmitry Zakharov，MixBytes
Biên dịch: Phóng viên AI,Cộng đồng Đăng Sách
Giới thiệu
Trong bài viết trước của chúng tôi, chúng tôi đã điểm lại chi tiết vòng đời của các trình xác thực Ethereum và thảo luận về nhiều khía cạnh liên quan đến bản nâng cấp hard fork Electra sắp tới. Bây giờ là lúc tập trung vào những thay đổi trong các bản nâng cấp Electra và Prague sắp tới và giải thích chi tiết chúng.
Lịch sử hard fork "Proof-of-Stake" của Ethereum 2.0 rất phức tạp. Nó bắt đầu bằng việc thêm lớp Beacon vào lớp thực thi hiện tại, khi lớp Beacon khởi động cơ chế đồng thuận Proof-of-Stake, thì lớp thực thi vẫn duy trì cơ chế Proof-of-Work (Giai đoạn 0 và hard fork Altair). Sau đó, PoS được kích hoạt hoàn toàn trong hard fork Bellatrix (mặc dù chức năng rút tiền chưa được bật). Tiếp theo, hard fork Capella cho phép rút tiền, hoàn tất chu kỳ sống của trình xác thực. Hard fork gần đây nhất Deneb (một phần của bản nâng cấp Dencun (Deneb/Cancun)) đã điều chỉnh nhẹ các thông số của chuỗi beacon, ví dụ như cửa sổ thời gian chứa bằng chứng, xử lý yêu cầu rút lui tự nguyện và giới hạn thay thế trình xác thực. Những thay đổi chính trong Dencun xảy ra ở lớp thực thi, bao gồm việc triển khai giao dịch blob, gas blob, cam kết KZG dành cho blob và loại bỏ lệnh SELFDESTRUCT.
Bây giờ, hard fork Prague/Electra (tức là Pectra) mang đến những nâng cấp quan trọng cho cả lớp thực thi và lớp đồng thuận. Với tư cách là nhóm kiểm toán dự án Lido, chúng tôi chủ yếu tập trung vào những thay đổi liên quan đến đồng thuận và staking trong hard fork này. Tuy nhiên, chúng tôi không thể bỏ qua những thay đổi ở lớp thực thi của Prague vì chúng bao gồm các tính năng quan trọng ảnh hưởng đến mạng Ethereum và các trình xác thực. Hãy cùng đi sâu vào chi tiết những thay đổi này.
Tổng quan cấp cao về Pectra
Electra giới thiệu nhiều chức năng mới cho lớp beacon. Các cập nhật chính bao gồm:
-
Cho phép số dư hiệu quả của trình xác thực thay đổi từ 32 đến 2048 ETH (thay vì cố định 32 ETH).
-
Cho phép trình xác thực khởi động quá trình rút lui thông qua khóa rút tiền thứ cấp (không còn cần khóa xác thực đang hoạt động).
-
Thay đổi cách lớp beacon xử lý việc gửi tiền Eth1 (không còn phân tích sự kiện từ hợp đồng gửi tiền nữa).
-
Thêm một khuôn khổ chung mới để 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 quản lý gửi tiền trước Electra).
Đồng thời, Prague mang đến những thay đổi sau cho lớp thực thi:
-
Một hợp đồng dựng sẵn mới hỗ trợ đường cong BLS12-381 để xác minh bằng chứng zkSNARK (ngoài đường cong BN254 phổ biến).
-
Một hợp đồng hệ thống mới dùng để lưu trữ và truy cập tối đa 8192 hash khối lịch sử (rất hữu ích cho các client vô trạng thái).
-
Tăng chi phí gas calldata nhằm giảm kích thước khối và khuyến khích các dự án chuyển các thao tác tốn nhiều calldata (như rollup) sang blobs được giới thiệu trong Dencun.
-
Hỗ trợ nhiều blob hơn mỗi khối Eth1 và cung cấp API để đọc số lượng này.
-
Cho phép 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ể các thao tác mà EOA có thể thực hiện, như thực hiện multicall hoặc ủy quyền thực thi cho địa chỉ khác.
Hãy cùng tham khảo các đề xuất cải tiến Ethereum (EIP) liên quan để thảo luận sâu hơn:
-
EIP-7251: Tăng MAX_EFFECTIVE_BALANCE
-
EIP-7002: Rút lui do lớp thực thi kích hoạt
-
EIP-6110: Gửi tiền trình xác thực trên chuỗi
-
EIP-7549: Di chuyển chỉ mục ủy ban khỏi bằng chứng
-
EIP-7685: Yêu cầu chung của lớp thực thi
-
EIP-2537: Dựng sẵn cho thao tác đường cong BLS12-381
-
EIP-2935: Lưu hash khối lịch sử trong trạng thái
-
EIP-7623: Tăng chi phí calldata
-
EIP-7691: Tăng thông lượng blob
-
EIP-7840: Thêm lịch trình blob vào hồ sơ EL
-
EIP-7702: Thiết lập mã tài khoản EOA
Một số EIP trong danh sách này chủ yếu liên quan đế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ố vượt qua cả hai lớp vì một số thao tác (như gửi và rút tiền) cần thay đổi đồng bộ giữa lớp đồng thuận và lớp thực thi. Do sự phụ thuộc lẫn nhau này, việc tách biệt Electra và Prague là không thực tế, vì vậy chúng tôi sẽ lần lượt xem xét từng EIP và xác định thành phần Ethereum bị ảnh hưởng trong từng trường hợp.
EIP-7251: Tăng MAX_EFFECTIVE_BALANCE
Tham khảo: EIP-7251
Kể từ hard fork Phase0 đầu tiên để chuẩn bị cho Proof-of-Stake của Ethereum, cho đến trước Electra, số dư hiệu quả tối đa của trình xác thực luôn cố định ở mức 32 ETH. Việc 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ả xuống spec.ejection_balance (16 ETH) và bị loại bỏ khi đạt ngưỡng này. Logic "tối thiểu" này vẫn giữ nguyên trong Electra, nhưng bây giờ spec.max_effective_balance đã được tăng lên 2048 ETH. Do đó, trình xác thực có thể gửi tiền từ 32 đến 2048 ETH để kích hoạt, và tất cả các số tiền này đều đóng góp vào số dư hiệu quả của họ. Sự chuyển đổi này đánh dấu bước chuyển từ "Proof-of-Stake 32ETH" sang "Proof-of-Stake" :)
Số dư hiệu quả có thể thay đổi này hiện sẽ được sử dụng để:
-
Tăng xác suất trở thành người đề xuất khối, tỷ lệ thuận với số dư hiệu quả
-
Tăng xác suất trở thành thành viên ủy ban đồng bộ, tỷ lệ thuận với số dư hiệu quả
-
Làm cơ sở tính toán số tiền phạt cắt giảm tương đối và phạt do không hoạt động
Hai hoạt động đầu tiên là những hoạt động mang lại lợi nhuận cao nhất cho trình xác thực. Do đó, sau Electra, các trình xác thực staking lớn sẽ tham gia vào việc đề xuất khối và ủy ban đồng bộ thường xuyên hơn, với tần suất tỷ lệ thuận với số dư hiệu quả của họ.
Một ảnh hưở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ệ thuận với số dư hiệu quả của trình xác thực:
-
Các khoản phạt cắt giảm "ngay lập tức" và "trì hoãn" sẽ lớn hơn đối với các trình xác thực staking lớn.
-
Các khoản phạt cắt giảm "trì hoãn" cùng với các trình xác thực bị cắt giảm có số dư lớn cũng sẽ lớn hơn, vì phần "bị cắt giảm" trong tổng số dư trở nên lớn hơn.
-
Người tố cáo báo cáo các trình xác thực có số dư hiệu quả cao hơn sẽ nhận được tỷ lệ phần trăm lớn hơn số dư bị cắt giảm.
Electra cũng đề xuất thay đổi tỷ lệ cắt giảm, định nghĩa phần số dư của trình xác thực bị cắt giảm và được người tố cáo nhận.
Tiếp theo là ảnh hưởng đến tình trạng không hiệu lực. Khi trình xác thực ngoại tuyến trong lúc đang hoạt động (chứng thực hoặc đề xuất), điểm không hiệu lực sẽ tích lũy, dẫn đến hình phạt không hiệu lực áp dụng mỗi chu kỳ. Những hình phạt này cũng có mối quan hệ tỷ lệ với số dư hiệu quả của trình xác thực.
Do số dư hiệu quả tăng lên, giới hạn thay thế của trình xác thực cũng thay đổi. Trong Ethereum "trước Electra", các trình xác thực thường có số dư hiệu quả giống nhau, giới hạn thay thế rút lui được định nghĩa là "trong một chu kỳ, tối đa không quá 1/65536 (spec.churn_limit_quotient) tổng số dư có thể rút lui". Điều này tạo ra một "số lượng cố định" các trình xác thực rút lui với số dư giống nhau. Tuy nhiên, trong Ethereum "sau Electra", có thể chỉ có một vài "cá voi" rút lui vì chúng đại diện cho một phần đáng kể trong tổng số dư.
Một điểm cần cân nhắc khác là việc luân chuyển nhiều khóa trình xác thực trên một phiên bản trình xác thực đơn lẻ. Các trình xác thực lớn hiện tại buộc phải chạy hàng nghìn khóa trình xác thực trên một phiên bản để phù hợp với số dư lớn, chia nhỏ thành các phần 32 ETH. Với Electra, hành vi này không còn bắt buộc. Về mặt tài chính, thay đổi này không ảnh hưởng nhiều vì phần thưởng và xác suất tỷ lệ tuyến tính theo số dư staking. Vì vậy, 100 trình xác thực mỗi cái 32 ETH tương đương với một trình xác thực 3200 ETH. Ngoài ra, nhiều khóa trình xác thực đang hoạt động có thể có cùng khóa rút tiền Eth1, cho phép tất cả phần thưởng rút về một địa chỉ ETH duy nhất, tránh chi phí gas liên quan đến việc hợp nhất phần thưởng. Tuy nhiên, việc quản lý nhiều khóa sẽ phát sinh thêm chi phí quản lý.
Khả năng gộp số dư của các trình xác thực thêm một loại yêu cầu mới ở lớp thực thi. Trước đây, chúng ta có gửi tiền và rút tiền. Bây giờ sẽ có thêm một loại khác: yêu cầu gộp. Nó sẽ gộp hai trình xác thực thành một. Yêu cầu thao tác này sẽ bao gồm khóa công khai của trình xác thực nguồn và khóa công khai đích và sẽ được xử lý tương tự như gửi tiền và rút tiền. Việc gộp cũng sẽ có hàng đợi yêu cầu chờ xử lý và giới hạn thay đổi số dư, giống như gửi tiền và rút tiền.
Tóm lại như sau:
-
Đối với các trình xác thực độc lập quy mô nhỏ, Electra giới thiệu khả năng tự động tăng số dư hiệu quả (và phần thưởng) của họ. Trước đây, bất kỳ phần dư nào vượt quá 32 ETH chỉ có thể rút ra, nhưng sau Electra, phần dư này cuối cùng sẽ 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 theo bội số của spec.effective_balance_increment (1 ETH), có nghĩa là việc tăng chỉ xảy ra sau khi đạt đến "ngưỡng 1 ETH tiếp theo".
-
Đối với các trình xác thực độc lập quy mô lớn, Electra cung cấp sự đơn giản hóa đáng kể trong quản lý bằng cách cho phép gộp nhiều khóa trình xác thực đang hoạt động thành một. Mặc dù điều này không làm thay đổi hoàn toàn cuộc chơi, nhưng vận hành một staking 1x2048 chắc chắn dễ dàng hơn nhiều so với quản lý 64x32 staking.
-
Đối với các nhà cung cấp staking lưu động, những người thu thập staking nhỏ từ người dùng và phân bổ giữa các trình xác thực, Electra tăng thêm tính linh hoạt trong phương án phân bổ staking, nhưng cũng đòi hỏi phải tái cấu trúc nghiêm trọng kế toán trình xác thực dựa trên số dư hiệu quả cố định 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 của trình xác thực, đặc biệt liên quan đến những người tham gia mới cố gắng đánh giá rủi ro và lợi nhuận. Trước Electra (tính đến thời điểm viết bài), giới hạn 32 ETH (dù là tối thiểu hay tối đa, thực tế) đã tạo ra sự đồng nhất trong dữ liệu lịch sử. Số dư hiệu quả, phần thưởng, hình phạt cắt giảm cá nhân, tần suất đề xuất khối và các chỉ số khác của tất cả các trình xác thực đều giống nhau. Sự đồng nhất này giúp Ethereum thử nghiệm cơ chế đồng thuận mà không có các ngoại lệ thống kê, từ đó thu thập dữ liệu hành vi mạng quý giá.
Sau Electra, sự phân bố staking sẽ thay đổi đáng kể. Các trình xác thực lớn sẽ tham gia đề xuất khối và ủy ban đồng bộ thường xuyên hơn, chịu hình phạt nặng hơn trong các sự kiện cắt giảm, và có ảnh hưởng lớn hơn đến việc cắt giảm trì hoãn, hàng đợi kích hoạt và hàng đợi rút lui. Mặc dù điều này có thể gây khó khăn trong việc tổng hợp dữ liệu, nhưng đồng thuận Ethereum đảm bảo các phép tính phi tuyến là tối thiểu. Thành phần phi tuyến duy nhất sử dụng sqrt(total_effective_balance) để tính phần thưởng cơ bản, áp dụng cho tất cả các trình xác thực. Điều này có nghĩa là phần thưởng và hình phạt của trình xác thực vẫn có thể được ước tính trên cơ sở "mỗi 1 ETH" (hoặc chính xác hơn, theo 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 đây của chúng tôi về hành vi trình xác thực.
EIP-7002: Rút lui do lớp thực thi kích hoạt
Tham khảo: EIP-7002
Mỗi trình xác thực trong Ethereum có hai cặp khóa: một cặp khóa đang hoạt động và một cặp khóa rút tiền. Khóa công khai BLS đang hoạt động đóng vai trò là danh tính chính của trình xác thực trên chuỗi beacon, cặp khóa này được dùng để ký khối, bằng chứng, cắt giảm, tập hợp ủy ban đồng bộ, và (trước EIP này) rút lui tự nguyện (để khởi động việc rút lui đồng thuận của trình xác thực sau độ trễ). 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ỉ). Hiện tại, việc rút về địa chỉ ETH cần tin nhắn rút tiền được ký bởi khóa riêng BLS đang hoạt động. EIP này thực hiện thay đổi.
Thực tế, chủ sở hữu của hai cặp khóa (đang hoạt động và rút tiền) này có thể khác nhau. Khóa đang hoạt động chịu trách nhiệm về nhiệm vụ xác thực: vận hành máy chủ, giữ nó hoạt động, v.v., trong khi chứng chỉ rút tiền thường do chủ sở hữu staking kiểm soát, người nhận phần thưởng và chịu trách nhiệm về tiền. Hiện tại, chỉ chủ sở hữu staking kiểm soát chứng chỉ rút tiền không thể khởi động việc rút lui của trình xác thực, chỉ có thể rút phần thưởng. Tình huống này cho phép chủ sở hữu khóa đang hoạt động của trình xác thực nắm giữ số dư của trình xác thực như "con tin". Trình xác thực có thể "ký trước" tin nhắn rút lui và giao cho chủ sở hữu staking, nhưng cách thức tạm thời này không lý tưởng. Hơn nữa, hiện tại cả việc rút tiền và rút lui đều yêu cầu tương tác với trình xác thực lớp beacon thông qua API chuyên dụng.
Giải pháp tốt nhất là cho phép chủ sở hữu staking thực hiện đồng thời việc rút lui và rút tiền thông qua lời gọi hợp đồng thông minh thông thường. Điều này liên quan đến việc kiểm tra chữ ký Eth1 tiêu chuẩn, đơn giản hóa đáng kể thao tác.
EIP này cho phép chủ sở hữu staking kích hoạt việc rút tiền và rút lui bằng cách gửi giao dịch tiêu chuẩn từ địa chỉ ETH của họ đến một hợp đồng thông minh chuyên dụng (tương tự như quy trình gửi tiền hiện tại sử dụng hợp đồng "gửi tiền"). Quy trình rút tiền (hoặc rút lui khi staking đủ thấp) diễn ra như sau:
-
Người staking gửi yêu cầu rút tiền (yêu cầu "in") đến hợp đồng "rút tiền" hệ thống.
-
Hợp đồng thu một khoản phí cụ thể (tính bằng ETH) để giảm thiểu các cuộc tấn công ác ý tiềm tàng và giống như EIP-1559, phí sẽ tăng khi hàng đợi yêu cầu đông đúc.
-
Hợp đồng lưu trữ yêu cầu rút tiền / rút lui "in" vào bộ nhớ của nó.
-
Khi một khối được đề xuất lên lớp beacon, các yêu cầu rút tiền / rút lui "in" trong hàng đợi được truy xuất từ bộ nhớ.
-
Lớp beacon xử lý yêu cầu "in", tương tác với số dư của trình xác thực đang hoạt động, sắp xếp việc rút lui của trình xác thực và tạo ra yêu cầu rút tiền "out".
-
Yêu cầu rút tiền "out" được xử lý ở lớp thực thi, người staking nhận được ETH của họ.
Mặc dù việc gửi tiền là thao tác được kích hoạt trong khối Eth1, sau đó "di chuyển" qua hàng đợi gửi tiền chờ xử lý đến lớp beacon, thì việc rút tiền lại tuân theo một phương án khác. Chúng được kích hoạt trên lớp beacon (thông qua CLI), sau đó "di chuyển" đến khối Eth1. Bây giờ, cả hai phương án sẽ hoạt động thông qua một khuôn khổ chung giống nhau (như mô tả bên dưới): tạo yêu cầu ở lớp Eth1, xử lý hàng đợi gửi tiền / rút tiền / gộp chờ xử lý và xử lý trên lớp beacon. Đối với các thao tác "đầu ra" như rút tiền, hàng đợi đầu ra cũng sẽ được xử lý, kết quả sẽ được "thanh toán" trong khối Eth1.
Với EIP này, người staking có thể sử dụng giao dịch ETH thông thường để rút tiền và rút lui trình xác thực của họ mà không cần tương tác trực tiếp với CLI trình xác thực hoặc truy cập cơ sở hạ tầng trình xác thực. Điều này đơn giản hóa đáng kể thao tác staking, đặc biệt đối với các nhà cung cấp staking lớn. Cơ sở hạ tầng trình xác thực hiện nay gần như hoàn toàn được cô lập, vì chỉ cần duy trì khóa của trình xác thực đang hoạt động, trong khi tất cả các thao tác staking có thể được xử lý ở nơi khác. Nó loại bỏ nhu cầu người staking độc lập chờ đợi hành động của trình xác thực đang hoạt động và đơn giản hóa đáng kể phần off-chain của các dịch vụ Lido như Community Staking Module.
Do đó, EIP này "hoàn thiện" thao tác staking, chuyển hoàn toàn sang lớp Eth1, giảm đáng kể rủi ro an ninh cơ sở hạ tầng và tăng cường tính phi tập trung cho sáng kiến staking độc lập.
EIP-6110: Cung cấp gửi tiền trình xác thực trên chuỗi
Tham khảo: EIP-6110
Hiện tại, việc gửi tiền được thực hiện thông qua sự kiện trong hợp đồng hệ thống "gửi tiền" (như đã thảo luận chi tiết trong các bài viết trước). Hợp đồng chấp nhận ETH và thông tin xác thực trình xác thực, phát ra sự kiện "Deposit()", sau đó được phân tích và chuyển đổi thành yêu cầu gửi tiền trên lớp beacon. Hệ thống này có nhiều điểm yếu: nó yêu cầu bỏ phiếu về eth1data ở lớp chuỗi beacon, gây ra độ trễ đáng kể. Ngoài ra, lớp beacon cần truy vấn lớp thực thi, làm tăng thêm độ phức tạp. 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, không cần xử lý nhiều vấn đề này, là trực tiếp đưa yêu cầu gửi tiền vào vị trí cụ thể trong khối Eth1. Cơ chế này tương tự như quy trình xử lý rút tiền được mô tả trong EIP trước.
Những thay đổi được đề xuất trong EIP này rất hứa hẹn. Xử lý eth1data hiện có thể được loại bỏ hoàn toàn, không còn cần bỏ phiếu hay độ trễ dài giữa sự kiện ở phía Eth1 và việc đưa vào gửi tiền trên lớp beacon (hiện khoảng 12 giờ). Nó cũng loại bỏ logic chụp ảnh nhanh hợp đồng gửi tiền. EIP này đơn giản hóa việc xử lý gửi tiền và làm cho nó phù hợp với phương án xử lý rút tiền được mô tả ở trên.
Đối với người staking và trình xác thực, những thay đổi này làm giảm đáng kể độ trễ giữa việc gửi tiền và kích hoạt trình xác thực. Khi trình xác thực bị cắt giảm, việc bổ sung cần thiết cũng sẽ nhanh hơn.
Không có gì nhiều để nói thêm về EIP này ngoài việc nó 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ả các bên liên quan.
EIP-7685: Yêu cầu chung của lớp thực thi
Tham khảo: EIP-7685
EIP này lẽ ra nên được giới thiệu trước ba EIP liên quan đến gửi tiền / rút tiền / gộp vì nó đặt nền tảng cho những EIP đó. Tuy nhiên, ở đây nó được giới thiệu để nhấn mạnh nhu cầu ngày càng tăng về việc di chuyển dữ liệu chuyên dụng 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ý yêu cầu được kích hoạt thông qua giao dịch ETH thông thường hiệu quả hơn. Hiện tại, chúng ta quan sát thấy:
-
Sự kiện gửi tiền trong khối Eth1 được "di chuyển" đến khối beacon để xử lý.
-
Yêu cầu rút tiền trong khối beacon (sử dụng CLI) được "di chuyển" đến khối Eth1 để xử lý.
-
Cần xử lý việc gộp trình xác thực, đây cũng là yêu cầu Eth1->beacon.
Ba thao tác này cho thấy sự cần thiết phải xử lý nhất quán các loại yêu cầu khác nhau khi chuyển đổi giữa lớp thực thi và lớp beacon. Ngoài ra, chúng ta cần khả năng kích hoạt các thao tác này chỉ bằng lớp Eth1, vì điều này sẽ cho phép chúng ta cách ly cơ sở hạ tầng trình xác thực khỏi cơ sở hạ tầng quản lý staking, từ đó tăng cường bảo mật. Do đó, một giải pháp chung để quản lý các yêu cầu như vậy vừa thực tế vừa cần thiết.
EIP này xây dựng một khuôn khổ cho ít nhất ba trường hợp chính: gửi tiền, rút tiền và gộp. Đó 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, bây giờ gộp sẽ thêm một trường khác, CONSOLIDATION_REQUEST_TYPE. Ngoài ra, EIP này cũng có thể bao gồm cơ chế chung để xử lý giới hạn cho các yêu cầu như vậy (tham khảo hằng số: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Mặc dù chi tiết triển khai cụ thể của khuôn khổ này vẫn chưa khả dụng, nhưng chắc chắn nó sẽ bao gồm các loại yêu cầu chính, cơ chế toàn vẹn (ví dụ, băm và Merklize yêu cầu) cũng như xử lý hàng đợi chờ xử lý và giới hạn tốc độ.
EIP này có ý nghĩa về kiến trúc, cho phép Eth1 kích hoạt các thao tác quan trọng trong lớp beacon thông qua một khuôn khổ thống nhất. Đối với người dùng cuối và các dự án, điều này có nghĩa là tất cả các yêu cầu được kích hoạt ở lớp Eth1 sẽ được truyền và xử lý hiệu quả hơn trên lớp beacon.
EIP-2537: Dựng sẵn cho thao tác đường cong BLS12-381
Tham khảo: EIP-2537
Nếu bạn không muốn đi sâu vào chi tiết, có thể coi việc dựng sẵn BLS12-381 như một thao tác mã hóa "băm" phức tạp, hiện có thể sử dụng trong hợp đồng thông minh. Đối với những ai quan tâm, hãy cùng tìm hiểu sâu hơn.
Các phép toán toán học trên các đường cong elliptic như BLS12-381 (và đường cong tương ứng BN-254) hiện được sử dụng chủ yếu cho hai mục đích:
-
Chữ ký BLS, trong đó sử dụng một thao tác đặc biệt gọi là "ghép nối" để xác minh các chữ ký này. Chữ ký BLS được các trình xác thực sử dụng rộng rãi vì chúng cho phép gộp nhiều chữ ký thành một. Các trình xác thực dựa vào chữ ký BLS dựa trên đường cong BLS12-381 (mặc dù chúng cũng có thể sử dụng bất kỳ đường cong nào hỗ trợ ghép nối như BN254).
-
Xác minh bằng chứng zkSNARK, trong đó ghép nối được dùng để xác minh bằng chứng. Ngoài ra, cam kết KZG cho các khối lớn được giới thiệu trong hard fork Dencun cũng sử dụng ghép nối để xác minh cam kết khối.
Nếu bạn muốn xác minh chữ ký BLS hoặc bằng chứng zkSNARK trong hợp đồng thông minh, bạn phải tính toán các "ghép nối" này, điều này rất tốn kém về mặt tính toán. Ethereum hiện đã có một hợp đồng dựng sẵn cho các thao tác đường cong BN254 (EIP-196 và EIP-197). Tuy nhiên, đường cong BLS12-381 (hiện được coi là an toàn hơn và được sử dụng rộng rãi hơn ngày nay) vẫn chưa được triển khai dưới dạng dựng sẵn. Trong trường hợp không có dựng sẵn như vậy, việc triển khai ghép nối và các thao tác đường cong khác trong hợp đồng thông minh đòi hỏi lượng tính toán lớn, như được hiển thị ở đây, và tiêu thụ lượng gas khổng lồ (khoảng ~10^5 đến 10^6 gas).
EIP này mở ra cánh cửa cho nhiều ứng dụng tiềm năng, đặc biệt là xác minh chữ ký BLS rẻ hơn dựa trên đường cong BLS12-381. Điều này làm cho việc triển khai các lược đồ ngưỡng cho nhiều mục đích trở nên khả thi. Như đã nêu, các trình xác thực Ethereum đã sử dụng chữ ký dựa trên BLS12-381. Với EIP này, hợp đồng thông minh tiêu chuẩn hiện có thể xác minh hiệu quả chữ ký gộp của trình xác thực. Điều này có thể đơn giản hóa việc chứng minh đồng thuận và cầu nối tài sản xuyên mạng, vì chữ ký BLS được sử dụng rộng rãi trong blockchain. Chữ ký BLS ngưỡng bản thân cho phép xây dựng nhiều lược đồ ngưỡng hiệu quả cho bỏ phiếu, tạo số ngẫu nhiên phi tập trung, đa chữ ký, v.v.
Việc xác minh bằng chứng zkSNARK rẻ hơn ngược lại sẽ mở khóa một lượng lớn ứng dụng. Nhiều giải pháp dựa trên zkSNARK hiện bị cản trở bởi chi phí xác minh bằng chứng cao, khiến một số dự án gần như trở nên không thực tế. EIP này có tiềm năng thay đổi điều này.
EIP-2935: Lưu hash khối lịch sử trong trạng thái
Tham khảo: EIP-2935
EIP này đề xuất lưu trữ 8192 (khoảng 27,3 giờ) hash khối lịch sử trong trạng thái blockchain, cung cấp lịch sử mở rộng cho các client vô trạng thái (như rollup) và hợp đồng thông minh. Nó đề xuất duy trì hành vi hiện tại của opcode BLOCKHASH, duy trì giới hạn 256 khối, đồng thời giới thiệu một hợp đồng hệ thống mới được thiết kế专门用于 lưu trữ và truy xuất hash lịch sử. Hợp đồng này thực hiện thao tác set() khi xử lý khối ở lớp thực thi. Phương pháp get() của nó có thể được mọi người truy cập để truy xuất hash khối cần thiết từ bộ đệm vòng.
Hiện tại, việc tham chiếu hash khối lịch sử trong EVM là có thể, nhưng việc truy cập bị giới hạn ở 256 khối gần nhất (khoảng 50 phút). Tuy nhiên, trong một số trường hợp, việc truy cập dữ liệu khối cũ hơn là cực kỳ quan trọng, đặc biệt đối với các ứng dụng xuyên chuỗi (cần chứng minh dữ liệu khối trước đó) và các client vô trạng thái, những người thường xuyên cần truy cập hash khối sớm.
EIP này mở rộng phạm vi thời gian có sẵn cho rollup và các ứng dụng xuyên chuỗi, cho phép chúng truy cập dữ liệu lịch sử trực tiếp trong EVM mà không cần thu thập từ bên ngoài. Do đó, các giải pháp này trở nên vững chắc 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 tải trọng giao dịch có sẵn, trong một số trường hợp có thể rất lớn (ví dụ, khi truyền mảng lớn hoặc bộ đệm nhị phân làm tham số). Việc sử dụng calldata đáng kể chủ yếu do rollup, chúng gửi tải trọng thông qua calldata chứa trạng thái rollup hiện tại.
Việc đưa dữ liệu nhị phân lớn, có thể chứng minh vào blockchain là rất quan trọng đối với rollup. Bản nâng cấp Dencun (Deneb-Cancun) đã giới thiệu một đổi mới quan trọng cho các trường hợp sử dụng như vậy - giao dịch blob (EIP-4844). Giao dịch blob có phí gas "blob" chuyên dụng riêng, mặc dù nội dung chính được lưu trữ tạm thời, nhưng bằng chứng mã hóa (cam kết KZG) cùng với hash của nó được tích hợp vào lớp đồng thuận. Do đó, so với việc lưu trữ dữ liệu bằng calldata, blob cung cấp giải pháp tốt hơn cho rollup.
Khuyến khích rollup chuyển dữ liệu của chúng sang blob có thể đạt được bằng cách "cà rốt và cây gậy". Phí blob gas giảm đóng vai trò là "cà rốt", trong khi EIP này tăng chi phí calldata như một "đòn bẩy", do đó 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 EIP-7691 (Tăng thông lượng blob), nâng cao số lượng blob tối đa được phép mỗi khối.
EIP-7691: Tăng thông lượng blob
Tham khảo: EIP-7691
Blob được giới thiệu trong hard fork Dencun trước đó, và giá trị ban đầu cho số lượng blob tối đa và mục tiêu "mỗi khối" là ước tính thận trọng. Điều này là do độ phức tạp trong việc dự đoán mạng p2p sẽ xử lý các đối tượng nhị phân lớn được lan truyền giữa các nút trình xác thực như thế nào. Cấu hình trước đó đã chứng minh là tốt, điều này làm cho thời điểm này phù hợp để thử nghiệm các giá trị mới. Trước đây, số lượng blob mục tiêu/tối đa mỗi khối được đặt ở mức 3/6. Những giới hạn này hiện được nâng lên 6/9 tương ứng.
Kết hợp với EIP trước đó EIP-7623 (tăng chi phí calldata), điều chỉnh này tiếp tục khuyến khích rollup chuyển dữ liệu của chúng từ calldata sang blobs. Công việc tìm kiếm các tham số blob tối ưu vẫn đang tiếp tục.
EIP-7840: Thêm lịch trình blob vào hồ sơ EL
Tham khảo: EIP-7840
EIP này đề xuất thêm số lượng blob mục tiêu và tối đa "mỗi khối" (đã thảo luận trước đó) và giá trị baseFeeUpdateFraction vào hồ sơ lớp thực thi Ethereum (EL). Nó cũng cho phép các client truy xuất các giá trị này thông qua API nút. Tính năng này đặc biệt hữu ích cho các nhiệm vụ như ước tính phí gas blob.
EIP-7702: Thiết lập 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 thay đổi lớn cho người dùng Ethereum. Như chúng ta biết, EOA (tài khoản sở hữu bên ngoài) không thể có mã nào, nhưng có thể cung cấp chữ ký giao dịch (tx.origin). Ngược lại, hợp đồng thông minh có bytecode, nhưng không thể chủ động đưa ra "chữ ký trực tiếp của nó". Mọi tương tác người dùng cần logic bổ sung, tự động và có thể xác minh hiện chỉ có thể thực hiện bằng cách gọi hợp đồng bên ngoài để thực hiện thao tác cần thiết. Tuy nhiên, trong trường hợp này, hợp đồng bên ngoài trở thành msg.sender cho các hợp đồng tiếp theo, khiến việc gọi "từ hợp đồng chứ không phải từ 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 đây chúng ta có giao dịch 0x1 cũ, giao dịch 0x02 mới từ nâng cấp Berlin và EIP-1559, và 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. Thực tế, nó cho phép EOA "thực thi mã bên ngoài trong ngữ cảnh của chính tài khoản EOA của nó". Từ góc nhìn bên ngoài, trong quá trình giao dịch, EOA dường như "mượn" mã từ hợp đồng bên ngoài và thực thi nó. Về mặt kỹ thuật, điều này được thực hiện bằng cách thêm một bộ dữ liệu ủy quyền đặc biệt vào bộ nhớ "mã" của địa chỉ EOA (bộ nhớ "mã" này luôn trống đối với EOA trước EIP này).
Hiện tại, loại giao dịch 0x04 mới được đề xuất trong EIP này chứa một mảng:
danh_sách_uỷ_quyền = [[chain_id, address, 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 chỉ định (từ mục ủy quyền hợp lệ cuối cùng). Khi xử lý giao dịch như vậy, mã của EOA được đặt thành giá trị đặc biệt 0xef0100 || địa_chỉ (23 byte), trong đó địa_chỉ trỏ đến hợp đồng có mã cần thiết, || biểu thị nối, 0xef0100 biểu thị giá trị ma thuật đặc biệ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 EOA này không thể được coi là hợp đồng thông thường và không thể được gọi như một hợp đồng thông thường.
Khi EOA này khởi tạo giao dịch, địa chỉ được chỉ định sẽ được 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 rõ ràng, nhưng có thể khẳng định nó sẽ mang lại những thay đổi lớn.
Một ảnh hưởng chính là khả năng thực hiện multicall trực tiếp từ EOA. Multicall là xu hướng liên tục trong DeFi, 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ụ Uniswap V4, Balancer V3 hoặc Euler V2). Với EIP này, multicall hiện có thể được khởi tạo trực tiếp từ 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ự thiếu hiệu quả khi approve() + anything() cần hai giao dịch độc lập. EIP này cho phép logic "ủy quyền trước" chung, khiến việc approve(X) + deposit(X) có thể hoàn thành trong một giao dịch duy nhất.
Một lợi thế khác là khái niệm tài trợ, cho phép "ủy quyền" thực thi giao dịch cho EOA. Tài trợ là tính năng thường được thảo luận và mong muốn cao để giúp người dùng mới tham gia Ethereum.
Logic lập trình được liên kết với EOA mở ra nhiều khả năng, chẳng hạn như triển khai giới hạn bảo mật, thiết lập giới hạn chi tiêu, yêu cầu KYC bắt buộc, v.v.
Tất nhiên, sự chuyển đổi này cũng đặt ra nhiều vấn đề thiết kế. Một vấn đề là việc sử dụng chain_id, nó quyết định chữ ký giống nhau có hiệu lực trên nhiều mạng hay không, tùy thuộc vào việc nó có được bao gồm trong chữ ký hay không. Một vấn đề phức tạp khác là lựa chọn giữa việc sử dụng địa chỉ mã mục tiêu và nhúng bytecode thực tế. Cả hai phương pháp đều có đặc điểm và giới hạn riêng biệt. Ngoài ra, việc sử dụng nonce đóng vai trò then chốt trong việc xác định quyền là "đa dụng" hay "đơn dụng". Những yếu tố này ảnh hưởng đến các vấn đề chức năng và bảo mật, bao gồm cả việc vô hiệu hóa hàng loạt chữ ký và tính dễ sử dụng. Vitalik đã nêu ra những vấn đề này trong một cuộc thảo luận (ở đây), đáng để khám phá sâu hơn.
Đáng chú ý, thay đổi này sẽ ảnh hưởng đến một cơ chế bảo mật của Ethereum, tx.origin. Cần thêm chi tiết về việc triển khai EIP này, nhưng có vẻ như hành vi của require(tx.origin == msg.sender) sẽ thay đổi. Kiểm tra này luôn là phương pháp đáng tin cậy nhất để đảm bảo msg.sender là EOA chứ không phải hợp đồng. Các phương pháp khác, ví dụ như kiểm tra EXTCODESIZE (để kiểm tra xem nó có phải là hợp đồng hay không), thường thất bại và có thể bị lách (ví dụ, bằng cách gọi hàm tạo hoặc triển khai mã tại địa chỉ đã định trước sau giao dịch). Các kiểm tra này được dùng để ngăn chặn các cuộc tấn công đệ quy và vay chớp nhoáng, nhưng xa mới lý tưởng, vì chúng cũng cản trở việc tích hợp với các giao thức bên ngoài. Sau EIP này, ngay cả kiểm tra require(tx.origin == msg.sender) đáng tin cậy dường như cũng trở nên lỗi thời. Các giao thức phải thích nghi bằng cách loại bỏ các kiểm tra này, vì sự phân biệt giữa "EOA" và "hợp đồng" sẽ không còn áp dụng—bây giờ mỗi địa chỉ đều có thể có mã liên quan.
Sự phân chia 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 đến thiết kế như TON, nơi mỗi tài khoản về cơ bản đều là mã thực thi được. Khi việc tương tác với các giao thức ngày càng phức tạp, việc sử dụng logic lập trình để cải thiện trải nghiệm người dùng cuối là quá trình phát triển tự nhiên.
Kết luận
Bản nâng cấp Prague/Electra (Pectra) dự kiến vào tháng 3 năm 2025. Những thay đổi đáng chú ý nhất bao gồm:
-
Số dư staking hiệu quả có thể thay đổi, tối đa lên đến 2048 ETH, sẽ thay đổi đáng kể sự phân bố staking, lịch trình trình xác thực và đơn giản hóa quản lý cho các nhà cung cấp staking lớn bằng cách hợp nhất các staking nhỏ
-
Cải thiện tương tác giữa lớp thực thi và lớp đồng thuận, đơn giản hóa việc trao đổi dữ liệu giữa khối thực thi Eth1 và khối chuỗi beacon. Đ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à rút lui, đẩy nhanh 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 lớp đồng thuận và lớp thực thi
-
Hỗ trợ xác minh chữ ký BLS và zkSNARK rẻ hơn trực tiếp trong hợp đồng thông minh thông qua việc dựng sẵn BLS12-381 mới "thân thiện với ghép nối"
-
Khuyến khích Rollups áp dụng giao dịch blob bằng cách tăng ngưỡng giao dịch blob và tăng chi phí calldata
-
Cho phép EOA hoạt động như tài khoản lập trình được, trao cho chúng chức năng multicall, tài trợ và các chức năng nâng cao khác
Như bạn có thể thấy, Pectra sẽ có tác động lớn đến staking và lớp đồng thuận, cũng như trải nghiệm 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 chi tiết tất cả những thay đổi này bằng mã ở giai đoạn này vì việc phát triển vẫn đang diễn ra, chúng tôi sẽ đề cập đến các cập nhật này trong các bài viết tương lai.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@MixBytes
