Được viết bởi Sergey Boogerwooger, Dmitry Zakharov, MixBytes
Biên soạn bởi: Người dịch AI, cộng đồng Chuỗi
giới thiệu
Trong bài viết trước, chúng tôi đã xem xét chi tiết vòng đời của 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ờ, đã đến lúc tập trung vào những thay đổi sắp tới trong nâng cấp Electra và Prague và giải thích chi tiết về chúng.
Lịch sử của hard fork “ Bằng chứng cổ phần ” Ethereum 2.0 rất 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 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(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ù 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ố Beacon Chain, chẳng hạn như bao gồm các khung thời gian để 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, giới thiệu các giao dịch blob, gas blob, cam kết KZG cho blob và 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 nâng cấp quan trọng cho lớp thực thi và lớp đồng thuận . Với tư cách là 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 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ề Pectra
Electra giới thiệu nhiều tính năng mới cho lớp đèn hiệu. Các cập nhật chính bao gồm:
- Cho phép người xác thực có số dư thực tế trong phạm vi từ 32 đến 2048 ETH (thay vì 32 ETH cố định).
- 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).
- Thêm một khuôn khổ chung mới để xử lý các yêu cầu từ 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).
Đồng thời, Prague đã đưa ra những thay đổi sau đây cho lớp thực thi:
- Một hợp đồng biên dịch trước 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 để lưu trữ và truy cập tới 8192 khối băm lịch sử(hữu ích cho máy trạm 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 cao hơn trên mỗi khối Eth1 và cung cấp API để đọc các blob đó.
- Việc 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 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.
Hãy tham khảo Đề án cải tiến Ethereum (EIP) có liên quan để thảo luận thêm:
- EIP-7251: Tăng MAX_EFFECTIVE_BALANCE
- EIP-7002: Thoát có thể kích hoạt ở lớp thực thi
- EIP-6110: Tiền gửi trên Chuỗi cho người xác thực
- EIP-7549: Di chuyển chỉ số ủy ban ra khỏi bản chứng minh
- EIP-7685: Yêu cầu lớp thực thi chung
- EIP-2537: Biên dịch trước các hoạt động đường cong BLS12-381
- EIP-2935: Lưu các khối băm lịch sử trong trạng thái
- EIP-7623: Tăng chi phí dữ liệu cuộc gọi
- EIP-7691: tăng thông lượng blob
- EIP-7840: Thêm lịch trình blob vào tệp cấu hình EL
- EIP-7702: Đặt mã tài khoản EOA
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 MAX_EFFECTIVE_BALANCE
Tham khảo : EIP-7251
Kể từ đợt hard fork Giai đoạn 0 lần , để chuẩn bị cho Bằng chứng cổ phần của Ethereum , cho đến Electra, số dư hiệu quả tối đa của người 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- Bằng chứng cổ phần” sang “Bằng chứng cổ phần” :)
Số dư hiệu dụng 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ộ hóa, tỷ lệ thuận với số dư hiệu quả
- Là cơ sở để tính toán số tiền phạt giảm tương đối và không hoạt động
Hai hoạt động đầu tiên là những hoạt động có nhiều phần thưởng nhất cho 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ương ứng với số dư thực tế của người xác thực:
- Cá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ễ" đối với những trình xác thực bị cắt giảm có tiền cược cao cũng lớn hơn vì phần "bị cắt giảm" trong tổng tiền cược trở nên lớn hơn.
- Người tố giác báo cáo những người xác thực có số dư hiệu quả cao hơn sẽ nhận được phần trăm cổ phần bị cắt giảm lớn hơn.
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 sẽ nhận được.
Tiếp theo là hiệu ứng 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à “Trong một chu kỳ, tối đa 1/65536 (spec.churn_limit_quotient) tổng số cổ phần có thể thoát”. Đ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 số 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ý 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 những người 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ể rút, 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 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 staking 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ử của trình xác thực và ước tính lợi nhuận, đặ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 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ả cá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à chỉ báo 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 tính toán 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).
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 để biết thêm chi tiết.
EIP-7002: Thoát khỏi lớp thực thi có thể kích hoạt
Tham khảo: EIP-7002
Mỗi trình xác thực trong Ethereum đều 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 Beacon Chain và đượ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 (private key và địa chỉ). Hiện tại, rút về địa chỉ ETH yêu cầu phải có thông báo rút tiền được ký bằng private key 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 (khóa chủ động và khóa 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, 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 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 phương pháp này không lý tưởng. Ngoài ra, cả rút 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ối ưu 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”). Quá trình rút(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 “vào”) đế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 sẽ 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 để trình xác thực thoát và tạo các yêu cầu rút "ra".
- Các yêu cầu rút tiền “ra” đượ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 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 "quyết toán" 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ô- Staking cộng đồng.
Do đó, EIP này "hoàn thiện" các hoạt động staking bằng cách di chuyển hoàn toàn chúng 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 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 xác thực trên Chuỗi
Tham khảo: 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 và phát ra các sự kiện "Deposit()", sau đó được phân tích cú pháp và chuyển đổi thành các 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 Beacon Chain, đ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 phương pháp đơn giản hơn, không cần phải giải quyết nhiều vấn đề trong số này, là đưa yêu cầu gửi tiền trực tiếp 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 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 khảo : EIP-7685
EIP này đáng lẽ phải được đề xuất trước ba EIP đầu tiên liên quan đến tiền gửi/rút tiền/sáp nhập vì nó đặt nền tảng cho các EIP đó. Tuy nhiên, nó được đưa vào đây để làm nổi bật nhu cầu tăng trưở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 Chuỗi Eth1 (thực thi) và Beacon (đồng thuận). EIP này tác động đến cả 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:
- 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 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 hoạt động này chứng minh sự 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 beacon. 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ý cổ phần, 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à hiện tại 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 khảo: 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ụ: yêu cầu băm và 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, bạn có thể coi biên dịch trước BLS12-381 như một hoạt động "băm"crypto 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 hoạt động đặ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ó 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 bằng chứng zkSNARK, trong đó các cặp được sử dụng để xác minh bằng chứng. Ngoài ra, 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 ghép nối để 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 ghé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 cho rằng 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 đòi hỏi lượng lớn tính toán 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 các 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 blockchain. 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 được lượng lớn ứng dụng. 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 các khối băm 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ờ) băm khối lịch sử trong trạng thái blockchain , cung cấp lịch sử mở rộng cho máy trạm không trạng thái (chẳng hạn như rollup) 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 pháp 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 Chuỗi(cần chứng minh dữ liệu từ các khối trước đó) và máy trạm không trạng thái cần truy cập vào các hàm băm khối sớm đị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í dữ liệu cuộc gọi
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 và có thể lớn trong một số trường hợp (ví dụ: khi truyền các mảng lớn hoặc bộ đệm nhị phân làm đối số). Việc sử dụng calldata đáng kể chủ yếu là do rollup, gửi dữ liệu 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 blockchain là rất quan trọng đối với việc tổng hợp. 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 crypto 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à cây 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
Blobs đã đượ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 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 này 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 khích lệ 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. 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 mục tiêu và số lượng blob 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 máy trạm truy xuất các giá trị này thông qua Nút API. Tính năng này đặc biệt hữu ích cho nhiệm vụ như ước tính phí gas 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 đáng kể 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 ta đã có các giao dịch 0x1 cũ, các giao dịch 0x02 mới từ 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ã" của đị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 được EIP này đề xuất chứa một mảng:
danh sách ủy quyền = [[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ỉ đã chỉ định (từ mục nhập ủ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, || nghĩa là kết nối và 0xef0100 nghĩa là 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 bạn 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” cho một EOA là khái niệm về 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 lập trình liên quan đến EOA mở ra nhiều khả năng, chẳng hạn như triển khai các hạn chế bảo mật, đặt giới hạn chi tiêu, thực thi các yêu cầu KYC, v.v.
Tất nhiên, sự thay đổi này cũng làm 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 phương pháp 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.
Điều đáng chú ý là 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à phương pháp đáng tin cậy nhất để đảm bảo rằng msg.sender là EOA chứ không phải là hợp đồng. Phương pháp 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à Khoản vay nhanh, nhưng không lý tưởng vì chúng còn cản trở 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 đó về cơ bản, mọi tài khoản đều 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
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 được lên 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 tổng hợp 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 , đồng thời đơ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 và thoát, đẩy nhanh các quá trình này và đặt nền tảng cho tương tác sâu hơn giữa lớp đồng thuận và lớp thực hiện.
- 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 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
- Khiến EOA hoạt động như một tài khoản có thể lập trình, cung cấp cho nó 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 ở 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.
