Giải thích về hard fork sắp tới của Ethereum - Nâng cấp Pectra

Giới thiệu

Trong bài viết trước, chúng tôi đã xem xét chi tiết vòng đời trình xác thực Ethereum, thảo luận về nhiều khía cạnh liên quan đến hard fork Electra sắp tới. Bây giờ là lúc tập trung vào những thay đổi trong bản nâng cấp Electra và Prague sắp tới và giải thích chi tiết về chúng.

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

Hiện tại, hard fork Prague/Electra (hay còn gọi là Pectra) giới thiệu những nâng cấp quan trọng cho các lớp thực thi và đồng thuận. Với tư cách là đơn vị kiểm toán của dự án Lido, chúng tôi chủ yếu tập trung vào những thay đổi liên quan đến sự đồng thuận và đặt cược trong đợt hard fork này. Tuy nhiên, chúng ta không thể bỏ qua những thay đổi ở lớp thực thi tại Prague vì chúng bao gồm các tính năng quan trọng ảnh hưởng đến mạng Ethereum và trình xác thực. Chúng ta hãy cùng tìm hiểu chi tiết về những thay đổi này.

Tổng quan cấp cao về Electra

Electra giới thiệu một số tính năng cho lớp đèn hiệu. Các bản cập nhật chính bao gồm:

• Cho phép số dư thực tế của trình xác thực thay đổi trong khoảng từ 32 đến 2048 ETH (thay vì cố định là 32 ETH).

• Cho phép người xác thực bắt đầu thoát thông qua thông tin xác thực “rút lui” thứ cấp (không còn yêu cầu khóa xác thực đang hoạt động).

• Đã thay đổi cách lớp beacon xử lý các khoản tiền gửi Eth1 (không còn phân tích các sự kiện từ hợp đồng tiền gửi nữa).

• Thêm một khuôn khổ chung mới để xử lý các 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ý tiền gửi trước Electra).

Cùng lúc đó, Prague đã giới thiệu những thay đổi sau đây cho lớp thực thi:

• Một hợp đồng được biên dịch trước mới có 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 để lưu trữ và truy cập tới 8192 băm khối lịch sử (rất hữu ích cho các máy khách không có trạng thái).

• Tăng chi phí gas calldata để giảm kích thước khối và khuyến khích các dự án di chuyển các hoạt động sử dụng nhiều calldata (như rollup) sang các blob được giới thiệu trong Dencun.

• Hỗ trợ số lượng blob lớn hơn trên mỗi khối Eth1 và cung cấp API để đọc những con số này.

• Cho phép EOA (tài khoản do bên ngoài sở hữu) có mã tài khoản riêng sẽ mở rộng đáng kể các hoạt động mà EOA có thể thực hiện, chẳng hạn như thực hiện nhiều cuộc gọi hoặc ủy quyền thực hiện cho các địa chỉ khác.

EIP-7002: Layer thực thi đã được kích hoạt "> EIP-7685: Yêu cầu của lớp thực thi chung

Một số EIP này chủ yếu liên quan đến lớp đồng thuận (đèn hiệu), trong khi những EIP khác liên quan đến lớp thực thi. Một số trải dài cả hai lớp, vì một số hoạt động nhất định (như gửi tiền và rút tiền) yêu cầu những thay đổi được đồng bộ hóa giữa lớp đồng thuận và lớp thực hiện. 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ẽ xem xét từng EIP, chỉ rõ thành phần Ethereum bị ảnh hưởng trong từng trường hợp.

EIP-7251: Tăng SỐ_CÂN_ĐỐI_HỢP_TỐI_ĐA

Tham khảo: EIP-7251

Kể từ đợt hard fork Giai đoạn 0 đầu tiên, để chuẩn bị cho Proof of Stake của Ethereum, 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 cần có ít nhất spec.min_activation_balance (32 ETH). Khi kích hoạt, trình xác thực sẽ 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ị đẩy ra khi đạt đến ngưỡng đó. Logic "tối thiểu" này vẫn không thay đổi trong Electra, nhưng hiện tại spec.max_effective_balance đã được tăng lên 2048 ETH. Do đó, người xác thực có thể gửi từ 32 đến 2048 ETH để kích hoạt, tất cả đều sẽ đóng góp vào số dư thực tế của họ. Sự thay đổi này đánh dấu bước chuyển từ "32ETH - Proof of Stake" sang "Proof of Stake" :)

Số dư hiệu quả biến đổi này hiện sẽ được sử dụng để:

• 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 của Ủy ban đồng bộ, tỷ lệ thuận với số dư hiệu quả

• Là cơ sở để tính toán số tiền phạt cắt giảm và không hoạt động tương đối

Hai hoạt động đầu tiên là những hoạt động có nhiều phần thưởng nhất đối với người xác thực. Do đó, sau Electra, những người xác thực có cổ phần lớn sẽ tham gia vào cá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ư thực tế của họ.

Một tác động khác liên quan đến việc cắt giảm. Tất cả các hình phạt cắt giảm đều tỷ lệ thuận với số dư thực tế của người xác thực:

• Hình phạt cắt giảm ngay lập tức và chậm trễ sẽ lớn hơn đối với những người xác thực có tiền cược cao.

• Hình phạt cắt giảm "trì hoãn" đối với những người xác thực bị cắt giảm với số tiền cược cao cũng lớn hơn vì phần "bị cắt giảm" của tổng số tiền cược trở nên lớn hơn.

• Những người tố giác báo cáo những người xác thực có số dư thực tế cao hơn sẽ nhận được phần lớn hơn trong số tiền cược bị cắt giảm.

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

Tiếp theo là tác động của sự kém hiệu quả. Khi trình xác thực ngoại tuyến trong khi đang hoạt động (chứng thực hoặc đề xuất), điểm không hợp lệ sẽ tích lũy, dẫn đến hình phạt không hợp lệ được áp dụng ở mỗi thời điểm. Các hình phạt này cũng tỷ lệ thuận với số dư thực tế của người xác thực.

Do số dư thực tế tăng lên nê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ó cùng số dư hiệu quả và giới hạn thay thế khi thoát được định nghĩa là “tối đa 1/65536 (spec.churn_limit_quotient) tổng số cổ phần có thể thoát trong một chu kỳ”. Điều này tạo ra một số lượng “cố định” các trình xác thực có cùng cổ phần có thể thoát. Tuy nhiên, “sau Electra”, có thể chỉ có một số ít “cá voi” thoát ra vì họ chiếm một phần đáng kể trong tổng số cổ phần.

Một cân nhắc khác là việc luân phiên nhiều khóa xác thực trên một phiên bản xác thực duy nhất. Các trình xác thực lớn hiện đang buộc phải chạy hàng nghìn khóa xác thực trên một phiên bản duy nhất để chứa số tiền cược lớn, được chia thành 32 phần 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 có tác động nhỏ vì phần thưởng và xác suất tăng theo tỷ lệ thuận với số tiền đặt cược. Do đó, 100 trình xác thực với 32 ETH mỗi trình tương đương với một trình xác thực với 3200 ETH. Ngoài ra, nhiều khóa xác thực đang hoạt động có thể có cùng thông tin xác thực rút tiền Eth1, cho phép rút tất cả phần thưởng 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ý số lượng lớn khóa sẽ phát sinh thêm chi phí hành chính.

Khả năng tổng hợp số dư của người xác thực sẽ thêm một loại yêu cầu lớp thực thi mới. Trước đây, chúng tôi có thể 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ó kết hợp hai trình xác thực thành một. Yêu cầu hoạt động sẽ bao gồm khóa công khai của bên 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. Các đơn vị tổng hợp cũng sẽ có các yêu cầu đang chờ xử lý và giới hạn thay đổi số dư, giống như việc gửi tiền và rút tiền.

Tóm lại:

• Đối với các trình xác thực độc lập nhỏ, Electra giới thiệu khả năng tự động tăng số dư thực tế (và phần thưởng) của họ. Trước đây, bất kỳ khoản thặng dư nào vượt quá 32 ETH chỉ có thể được rút ra, nhưng sau Electra, khoản thặng dư này cuối cùng sẽ đóng góp vào số dư thực tế của nó. Tuy nhiên, số dư thực tế chỉ có thể tăng theo bội số của spec.effective_balance_increment(1 ETH), nghĩa là số dư chỉ tăng sau khi đạt đến "ranh giới 1 ETH" tiếp theo.

• Đối với các trình xác thực độc lập lớn, Electra cung cấp khả năng quản lý đơn giản đáng kể bằng cách cho phép hợp nhất nhiều khóa trình xác thực đang hoạt động thành một. Mặc dù đây không phải là bước đột phá, nhưng việc quản lý tiền cược 1x2048 chắc chắn đơn giản hơn nhiều so với việc quản lý tiền cược 64x32.

• Đối với các nhà cung cấp cổ phần thanh khoản, những người thu thập các cổ phần nhỏ từ người dùng và phân phối chúng cho những người xác thực, Electra bổ sung thêm tính linh hoạt cho chương trình phân phối cổ phần, nhưng cũng yêu cầu phải tái cấu trúc nghiêm túc kế toán của người xác thực dựa trên số dư hiệu dụng 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 người xác thực, điều này đặc biệt liên quan đến những người tham gia mới đang cố gắng đánh giá rủi ro và phần thưởng. Trước Electra (tính đến thời điểm viết bài này), mức giới hạn 32 ETH (thực ra là tối thiểu hoặc tối đa) đã tạo ra sự thống nhất trong dữ liệu lịch sử. Tất cả trình xác thực đều có cùng số dư hiệu quả, phần thưởng, hình phạt cắt giảm riêng lẻ, tần suất đề xuất khối và các số liệu khác. Tính đồng nhất này cho phép Ethereum kiểm tra cơ chế đồng thuận của mình mà không có giá trị thống kê bất thường, do đó thu thập dữ liệu có giá trị về hành vi của mạng.

Sau Electra, việc phân bổ staking sẽ thay đổi đáng kể. Các trình xác thực lớn sẽ tham gia thường xuyên hơn vào các đề xuất khối và ủy ban đồng bộ hóa, phải chịu hình phạt nặng hơn trong các sự kiện cắt giảm và có tác động lớn hơn đến việc cắt giảm bị 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, nhưng sự đồng thuận của Ethereum đảm bảo rằng các phép tính phi tuyến tính là tối thiểu. Thành phần phi tuyến tính duy nhất sử dụng sqrt(total_effective_balance) để tính phần thưởng cơ sở, áp dụng cho tất cả trình xác thực. Điều này có nghĩa là phần thưởng của trình xác thực và việc cắt giảm vẫn có thể được ước tính trên cơ sở "trên 1 ETH" (hay chính xác hơn là dựa trên spec.effective_balance_increment, có thể thay đổi trong tương lai).

Để biết thêm chi tiết, hãy xem bài viết trước của chúng tôi về hành vi của trình xác thực.

EIP-7002: Lớp thực thi có thể kích hoạt thoát

Tham chiếu: EIP-7002

Mỗi trình xác thực trong Ethereum có hai cặp khóa: khóa hoạt động và khóa rút tiền. Khóa BLS công khai đang hoạt động đóng vai trò là danh tính chính của người xác thực trong chuỗi beacon và cặp khóa này được sử dụng để ký khối, xác thực, cắt, tổng hợp ủy ban đồng bộ hóa và (trước EIP này) thoát tự nguyện (để bắt đầu thoát theo sự đồng thuận của người xác thực sau khi trì hoãn). Cặp khóa thứ hai (“thông tin xác thực rút tiền”) có thể là một cặp khóa BLS khác hoặc tài khoản Eth1 thông thường (khóa riêng và địa chỉ). Hiện tại, việc rút tiền về địa chỉ ETH yêu cầu phải có thông báo rút tiền được ký bằng khóa riêng BLS đang hoạt động. EIP này thực hiện những thay đổi.

Trên thực tế, chủ sở hữu của hai cặp khóa này (hoạt động và rút tiền) có thể khác nhau. Khóa hoạt động của trình xác thực chịu trách nhiệm về các nhiệm vụ xác minh: vận hành máy chủ, duy trì hoạt động, v.v., trong khi chứng từ rút tiền thường do chủ sở hữu cổ phần 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ỉ có chủ sở hữu cổ phần kiểm soát chứng chỉ rút tiền mới có thể khởi tạo lệnh thoát của trình xác thực, chỉ có 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 có thể giữ số dư của trình xác thực làm con tin. Người xác thực có thể “ký trước” vào tin nhắn thoát và gửi cho chủ sở hữu cổ phần, nhưng giải pháp này không lý tưởng. Ngoài ra, cả thao tác rút tiền và thoát tiền hiện đề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 cổ phần thực hiện cả hoạt động thoát và rút tiền thông qua các lệnh gọi hợp đồng thông minh thường xuyên. Đ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 đáng kể các hoạt động.

EIP này cho phép chủ sở hữu cổ phần kích hoạt lệnh rút tiền và thoát bằng cách gửi các 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 thoát khi đã rút đủ tiền cược) như sau:

• Người đặt cược 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 một khoản phí cụ thể (bằng ETH) để giảm thiểu các cuộc tấn công độc hại tiềm ẩn và tương tự như EIP-1559, khoản phí sẽ tăng khi hàng đợi yêu cầu bận.

• Hợp đồng lưu yêu cầu rút/thoát "vào" vào bộ nhớ của nó.

• Khi một khối được đề xuất tới lớp beacon, các yêu cầu rút/thoát "vào" trong hàng đợi sẽ được lấy từ bộ lưu trữ.

• Lớp beacon xử lý các yêu cầu "vào", tương tác với số dư của các trình xác thực đang hoạt động, sắp xếp để các trình xác thực thoát ra và tạo các yêu cầu rút "ra".

• 「out」Yêu cầu rút tiền được xử lý tại lớp thực hiện và người đặt cược sẽ nhận được ETH của họ.

Trong khi tiền gửi là hành động được kích hoạt trong các khối Eth1 và sau đó được "di chuyển" đến lớp beacon thông qua hàng đợi tiền gửi "đang chờ xử lý", thì việc rút tiền lại tuân theo một sơ đồ khác. Chúng được kích hoạt ở lớp beacon (thông qua CLI) và sau đó được “di chuyển” đến các khối Eth1. Bây giờ, cả hai kịch bản sẽ hoạt động thông qua cùng một khuôn khổ chung (được mô tả bên dưới): tạo yêu cầu ở lớp Eth1, xử lý hàng đợi gửi/rút/hợp nhất "đang chờ xử lý" và xử lý chúng ở 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 sẽ được xử lý và kết quả sẽ được "giải quyết" trong khối Eth1.

Với EIP này, người đặt cược có thể rút và thoát khỏi trình xác thực của mình bằng các 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 CLI của trình xác thực hoặc truy cập vào cơ sở hạ tầng của trình xác thực. Điều này giúp đơn giản hóa đáng kể các hoạt động staking, đặc biệt là đối với những người staking lớn. Cơ sở hạ tầng xác thực hiện nay có thể được cô lập gần như hoàn toàn, 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 hoạt động đặt cược có thể được xử lý ở nơi khác. Nó loại bỏ nhu cầu những người đặt cược độc lập phải chờ đợi hành động từ những người xác thực đang hoạt động và đơn giản hóa đáng kể các phần ngoài chuỗi của dịch vụ Lido như Mô-đun đặt cược cộng đồng.

Do đó, EIP này "hoàn tất" hoạt động staking, di chuyển hoàn toàn sang lớp Eth1, giảm đáng kể rủi ro bảo mật cơ sở hạ tầng và tăng cường tính phi tập trung của các sáng kiến ​​staking độ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 chiếu: EIP-6110

Hiện tại, tiền gửi được thực hiện thông qua các sự kiện trong hợp đồng "tiền gửi" của hệ thống (đã được thảo luận chi tiết trong bài đăng trước). Hợp đồng chấp nhận ETH và thông tin xác thực, phát ra sự kiện "Deposit()", sau đó được phân tích cú pháp 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ó một số nhược điểm: nó yêu cầu bỏ phiếu trên eth1data ở cấp chuỗi beacon, điều này làm tăng đáng kể độ trễ. Ngoài ra, lớp beacon cần phải 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 cách tiếp cận đơn giản hơn, không cần phải giải quyết nhiều vấn đề trong số này, là chỉ cần đưa yêu cầu gửi tiền vào khối Eth1 tại vị trí được chỉ định. Cơ chế này tương tự như quá trình rút lui được mô tả trong EIP trước đó.

Những thay đổi được đề xuất trong EIP này rất hứa hẹn. Quá trình xử lý eth1data hiện có thể được loại bỏ hoàn toàn, không còn yêu cầu thăm dò hoặc độ trễ dài (hiện tại là khoảng 12 giờ) giữa các sự kiện ở phía Eth1 và việc đưa các khoản tiền gửi vào lớp beacon. Nó cũng loại bỏ logic chụp ảnh nhanh hợp đồng ký quỹ. EIP này đơn giản hóa quá trình xử lý tiền gửi và phù hợp với chương trình xử lý rút tiền được mô tả ở trên.

Đối với người đặt cược và người xác thực, những thay đổi này làm giảm đáng kể độ trễ giữa thời điểm gửi tiền và thời điểm kích hoạt người xác thực. Khi số lượng trình xác thực bị cắt giảm, quá trình bổ sung cần thiết cũng diễn ra nhanh hơn.

Không có nhiều điều để nói về EIP này, ngoại trừ 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ả mọi người liên quan.

EIP-7685: Yêu cầu lớp thực thi chung

Tham chiếu: EIP-7685

EIP này đáng lẽ phải được đề xuất trước ba EIP đầu tiên liên quan đến việc gửi tiền/rút tiền/sáp nhập, vì nó đặt nền tảng cho các EIP đó. Tuy nhiên, nó được trình bày ở đây để làm nổi bật 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 chuỗi (lớp) Eth1 (thực thi) và Beacon (đồng thuận). EIP này tác động đến hai lớp, giúp xử lý yêu cầu được kích hoạt bởi các giao dịch ETH thông thường hiệu quả hơn. Hiện tại, chúng tôi quan sát thấy rằng:

• Các sự kiện gửi tiền trong khối Eth1 được "di chuyển" đến khối beacon để xử lý.

• Các 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 phải xử lý việc hợp nhất trình xác thực, đây cũng là yêu cầu Eth1->beacon.

Ba thao tác này chứng minh tính cần thiết của việc 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 đèn hiệu. Ngoài ra, chúng ta cần có khả năng kích hoạt các hành động này chỉ bằng cách sử dụng lớp Eth1, vì điều này sẽ cho phép chúng ta cô lập cơ sở hạ tầng xác thực khỏi cơ sở hạ tầng quản lý đặt cược, qua đó cải thiện tính bảo mật. Do đó, một giải pháp chung để quản lý những yêu cầu như vậy vừa thiết thực vừa cần thiết.

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

Mặc dù thông tin chi tiết về việc triển khai khuôn khổ này vẫn chưa có, 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à yêu cầu merklizing), cũng như xử lý hàng đợi đang chờ xử lý và giới hạn tốc độ.

EIP này có ý nghĩa về mặt kiến ​​trúc, cho phép Eth1 kích hoạt các hoạt động chính 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 chuyển giao và xử lý hiệu quả hơn ở lớp beacon.

EIP-2537: Biên dịch trước các hoạt động đườ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, hãy coi biên dịch trước BLS12-381 như một hoạt động "băm" mật mã phức tạp hiện có thể được sử dụng trong các hợp đồng thông minh. Đối với những ai quan tâm, chúng ta hãy cùng khám phá thêm.

Các phép toán trên đường cong elip như BLS12-381 (và phép tương tự 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à "ghép nối" được sử dụng để xác minh các chữ ký này. Chữ ký BLS được nhiều trình xác thực sử dụng rộng rãi vì chúng tổng hợp nhiều chữ ký thành một. 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ể được triển khai bằng bất kỳ đường cong nào hỗ trợ ghép nối, chẳng hạn như BN254).

• Xác minh các bằng chứng zkSNARK, trong đó các cặp được sử dụng để xác minh bằng chứng. Ngoài ra, các cam kết của KZG đối với các khối lớn được giới thiệu bởi hard fork Dencun cũng sử dụng các cặp để xác minh các 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 "cặp" này, việc này rất tốn kém về mặt tính toán. Ethereum đã có hợp đồng được biên dịch sẵn cho các hoạt động đườ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) vẫn chưa được triển khai dưới dạng biên dịch trước. Nếu không có biên dịch trước như vậy, việc triển khai ghép nối và các hoạt động đường cong khác trong hợp đồng thông minh sẽ đòi hỏi rất nhiều phép tính như được hiển thị ở đây và tiêu tốn rất nhiều gas (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à trong việc xác minh chữ ký BLS giá rẻ dựa trên đường cong BLS12-381. Điều này giúp có thể triển khai các chương trình ngưỡng cho nhiều 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ể 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 bằng chứng đồng thuận và kết nối tài sản trên các mạng lưới, vì chữ ký BLS được sử dụng rộng rãi trong chuỗi khối. Bản thân các chữ ký ngưỡng BLS cho phép xây dựng nhiều lược đồ ngưỡng hiệu quả để bỏ phiếu, tạo số ngẫu nhiên phi tập trung, nhiều chữ ký, v.v.

Xác minh bằng chứng zkSNARK rẻ hơn sẽ mở khóa nhiều ứng dụng khác nhau. Nhiều giải pháp dựa trên zkSNARK hiện đang 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ư không thực tế. Dự án EIP này có tiềm năng thay đổi điều đó.

EIP-2935: Lưu trữ các băm 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ờ) các băm khối lịch sử trong trạng thái chuỗi khối, cung cấp lịch sử mở rộng cho các máy khách không trạng thái (chẳng hạn như các bản tổng hợp) và hợp đồng thông minh. Đề xuất này đề xuất giữ nguyên hành vi hiện tại của mã lệnh BLOCKHASH, duy trì giới hạn 256 khối, đồng thời giới thiệu hợp đồng hệ thống mới được thiết kế riêng để lưu trữ và truy xuất các giá trị băm lịch sử. Hợp đồng này thực hiện thao tác set() khi lớp thực thi xử lý một khối. Phương thức get() của nó có thể được bất kỳ ai truy cập và lấy khối băm mong muốn từ bộ đệm vòng.

Hiện tại, có thể tham chiếu các khối băm lịch sử trong EVM, nhưng quyền truy cập bị giới hạn ở 256 khối gần đây nhất (khoảng 50 phút). Tuy nhiên, có những trường hợp mà việc truy cập vào dữ liệu khối cũ hơn lại rất quan trọng, đặc biệt là đối với các ứng dụng chuỗi chéo (cần chứng minh dữ liệu từ các khối trước đó) và các máy khách không trạng thái cần truy cập vào các hàm băm khối sớm theo định kỳ.

EIP này mở rộng phạm vi thời gian có sẵn cho các ứng dụng tổng hợp và chuỗi chéo, 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 phải thu thập dữ liệu bên ngoài. Kết quả là, các 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 khả dụng của tải trọng giao dịch, có thể lớn trong một số trường hợp (ví dụ: khi các mảng lớn hoặc bộ đệm nhị phân được truyền dưới dạng tham số). Việc sử dụng calldata đáng kể chủ yếu là do rollup, gửi tải trọ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 được vào chuỗi khối là rất quan trọng đối với việc tổng hợp. Bản nâng cấp Dencun (Deneb-Cancun) giới thiệu một cải tiến quan trọng cho những 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" riêng và trong khi nội dung của chúng được lưu trữ tạm thời, bằng chứng mật mã của chúng (cam kết KZG) được tích hợp vào lớp đồng thuận cùng với hàm băm của chúng. Do đó, blob cung cấp giải pháp tốt hơn cho việc cuộn dữ liệu so với việc sử dụng calldata để lưu trữ dữ liệu.

Có thể khuyến khích các rollup di chuyển dữ liệu của họ sang blob thông qua phương pháp “củ cà rốt và roi”. Phí gas blob giảm đóng vai trò như một "củ cà rốt", và EIP này đóng vai trò như một "đòn bẩy" bằng cách tăng chi phí dữ liệu cuộc gọi, do đó ngăn chặn việc lưu trữ dữ liệu quá mức trong các giao dịch. EIP này bổ sung cho EIP-7691 tiếp theo (Tăng thông lượng Blob), giúp tăng số lượng blob tối đa được phép trên 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à các giá trị ban đầu cho số lượng blob tối đa và mục tiêu "trên mỗi khối" chỉ 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ý việc truyền các đối tượng nhị phân lớn giữa các nút xác thực. Cấu hình trước đó đã chứng minh là tốt, do đó đây là thời điểm thích 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 trên mỗi khối được đặt là 3/6. Những giới hạn đó hiện đã được nâng lên lần lượt là 6/9.

Kết hợp với EIP-7623 trước đó (tăng chi phí dữ liệu cuộc gọi), điều chỉnh này càng khuyến khích các đơn vị tổng hợp di chuyển dữ liệu của họ từ dữ liệu cuộc gọi sang blob. Công việc tìm kiếm các thông số blob tối ưu vẫn đang được tiến hành.

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 số lượng blob mục tiêu và tối đa "trên mỗi khối" (đã thảo luận trước đó), cũng như giá trị baseFeeUpdateFraction, vào tệp cấu hình Ethereum Execution Layer (EL). Nó cũng cho phép khách hàng truy xuất các giá trị này thông qua API của 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: Đặt mã tài khoản EOA

Tham chiếu: 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 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, hợp đồng thông minh có mã bytecode nhưng không thể chủ động yêu cầu chữ ký trực tiếp từ “nó”. Hiện tại, bất kỳ tương tác nào của người dùng yêu cầu logic bổ sung, tự động và có thể xác minh đều chỉ có thể thực hiện được bằng cách gọi hợp đồng bên ngoài để thực hiện hành động mong muốn. Tuy nhiên, trong trường hợp này, hợp đồng bên ngoài trở thành người gửi tin nhắn của hợp đồng tiếp theo, khiến cuộc gọi trở thành "cuộc gọi từ hợp đồng, không phải từ người dùng".

EIP này giới thiệu loại giao dịch SET_CODE_TX_TYPE=0x04 mới (trước đây chúng tôi đã có các giao dịch 0x1 cũ, các giao dịch 0x02 mới từ 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. Trên thực tế, nó cho phép EOA thực thi mã bên ngoài "trong bối cảnh tài khoản EOA của chính nó". Theo 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 mã đó. Về mặt kỹ thuật, điều này đạt được bằng cách thêm một bộ dữ liệu ủy quyền đặc biệt vào bộ lưu trữ "mã" tại địa chỉ EOA (trước EIP này, bộ lưu trữ "mã" này luôn trống đối với EOA).

Hiện tại, loại giao dịch 0x04 mới do EIP này đề xuất chứa một mảng:

authorization_list=[[chain_id,address,nonce,y_parity,r,s],...]

Mỗi phần tử cho phép một tài khoản sử dụng mã từ một địa chỉ đã 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 đã cho sẽ được đặt thành giá trị địa chỉ đặc biệt 0xef0100 || (23 byte), trong đó địa chỉ trỏ đến hợp đồng có mã yêu cầu, || biểu thị kết nối và 0xef0100 biểu thị giá trị ma thuật đặc biệt mà các hợp đồng thông minh thông thường không thể chứa (theo EIP-3541). Giá trị kỳ diệu này đảm bảo rằng EOA này không thể được coi là một 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 sử dụng để gọi mã tương ứng trong bối cảnh của EOA này. Mặc dù thông tin chi tiết về việc triển khai đầy đủ EIP này vẫn chưa được biết, nhưng chắc chắn nó sẽ mang lại những thay đổi đáng kể.

Một tác động lớn là khả năng thực hiện nhiều cuộc gọi trực tiếp từ EOA. Multicall là xu hướng đang diễn ra 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ụ: Uniswap V4, Balancer V3 hoặc Euler V2). Với EIP này, giờ đây có thể thực hiện nhiều cuộc gọi 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ự kém hiệu quả của approve() + anything() đòi hỏi hai giao dịch riêng biệt. EIP này cho phép sử dụng logic “ủy quyền trước” chung để những việc như phê duyệt(X) + gửi tiền(X) có thể được thực hiện trong một giao dịch duy nhất.

Một lợi thế khác của việc có thể ủy quyền thực hiện giao dịch “thay mặt” EOA là khái niệm tài trợ. Tài trợ là một 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 có thể lập trình liên quan đến EOA mở ra nhiều khả năng, chẳng hạn như triển khai giới hạn bảo mật, đặt mức chi tiêu tối đa, thực thi các yêu cầu KYC, v.v.

Tất nhiên, sự thay đổi này cũng nảy sinh nhiều vấn đề về thiết kế. Một vấn đề là việc sử dụng chain_id, xác định xem cùng một chữ ký có thể hợp lệ trên nhiều mạng hay không, tùy thuộc vào việc nó có được đưa vào chữ ký hay không. Một sự phức tạp khác là việc lựa chọn giữa việc sử dụng địa chỉ của mã đối tượng và nhúng mã byte thực tế. Mỗi cách tiếp cận này đề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 có "đa mục đích" hay "đơn mục đích". Các yếu tố này tác động đến các vấn đề về chức năng và bảo mật, bao gồm các khía cạnh như vô hiệu hóa hàng loạt chữ ký và tính dễ sử dụng. Vitalik đã nêu ra những câu hỏi này trong một cuộc thảo luận (tại đây) và chúng đáng để khám phá thêm.

Cần lưu ý rằng thay đổi này sẽ ảnh hưởng đến cơ chế bảo mật của Ethereum, tx.origin. Cần có thêm thông tin 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à cách đáng tin cậy nhất để đảm bảo rằng msg.sender là EOA chứ không phải là hợp đồng. Các cách tiếp cận khác, chẳng hạn như kiểm tra EXTCODESIZE (để kiểm tra xem đó có phải là hợp đồng hay không), thường không thành công và có thể bị bỏ qua (ví dụ: bằng cách gọi hàm tạo hoặc triển khai mã tại một địa chỉ được xác định trước sau giao dịch). Các kiểm tra này được sử dụng để ngăn chặn các cuộc tấn công vào lại và cho vay nhanh, nhưng không lý tưởng vì chúng còn cản trở việc tích hợp với các giao thức bên ngoài. Ngay cả kiểm tra require(tx.origin == msg.sender) đáng tin cậy cũng có vẻ trở nên lỗi thời sau EIP này. Giao thức phải thích ứng bằng cách loại bỏ các kiểm tra này vì sự khác biệt giữa "EOA" và "hợp đồng" không còn áp dụng nữa - bây giờ mọi địa chỉ đều có thể có mã liên quan.

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

Kết luận

Việc nâng cấp Prague/Electra (Pectra) dự kiến ​​diễn ra vào tháng 3 năm 2025. Những thay đổi đáng chú ý nhất theo kế hoạch bao gồm:

• Cổ phần hiệu quả của trình xác thực biến đổi, lên tới 2048 ETH, điều này sẽ thay đổi đáng kể việc phân phối cổ phần, lịch trình của trình xác thực và đơn giản hóa việc quản lý các nhà cung cấp cổ phần lớn bằng cách hợp nhất các cổ phần nhỏ hơn

• 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 các khối thực thi Eth1 và các khối chuỗi beacon. Điều này sẽ đơn giản hóa đáng kể các khoản tiền gửi, kích hoạt, rút ​​tiền và thoát, đẩy nhanh các quy trình này và đặt nền tảng cho tương tác sâu hơn giữa các lớp đồng thuận và thực thi

• Hỗ trợ chữ ký BLS rẻ hơn và xác minh zkSNARK trực tiếp trong hợp đồng thông minh thông qua biên dịch trước BLS12-381 "thân thiện với ghép nối" mới

• Khuyến khích Rollup áp dụng các 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ư các tài khoản có thể lập trình, cung cấp cho chúng nhiều cuộc gọi, tài trợ và các tính năng nâng cao khác

Như bạn có thể thấy, Pectra sẽ có tác động đáng kể đến trải nghiệm của người dùng cuối đối với cả lớp staking và lớp đồng thuận, cũng như 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 thông qua mã ở giai đoạn này vì quá trình phát triển vẫn đang tiếp diễn, chúng tôi sẽ đề cập đến những cập nhật này trong các bài viết sau.