Trong bài viết trước đó của chúng tôi, chúng tôi đã điều tra một cách chi tiết về vòng đời của các nhà xác minh Ethereum và 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 hard fork Electra và nâng cấp Prague sắp tới, và giải thích chúng chi tiết.
Lịch sử của hard fork Ethereum 2.0 'Proof of Stake' là 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 có, trong khi lớp thực thi vẫn duy trì proof of work (hard fork Phase0 và Altair). Sau đó, trong hard fork Bellatrix, PoS được hoàn toàn kích hoạt (mặc dù chưa có việc rút tiền). Tiếp theo, hard fork Capella cho phép rút tiền, hoàn thành vòng đời của người xác minh. Hard fork gần đây nhất Deneb (một phần của nâng cấp Deneb/Cancun) đã điều chỉnh lại các tham số của chuỗi beacon, bao gồm cửa sổ thời gian của chứng minh, xử lý việc rút tiền tự nguyện và giới hạn thay đổi người xác minh. Các thay đổi chính trong Dencun xảy ra ở lớp thực thi, giới thiệu giao dịch blob, blob gas, cam kết KZG cho blob và loại bỏ hoạt động SELFDESTRUCT.
Hiện nay, Prague/Electra (hay còn gọi là Pectra) đã thực hiện một hard fork quan trọng để đưa ra cải tiến cho lớp thực thi và lớp đồng thuận. Là một trong những nhà kiểm toán dự án Lido, chúng tôi tập trung chủ yếu vào những thay đổi về đồng thuận và đặt cọc trong hard fork này. Tuy nhiên, chúng tôi không thể bỏ qua những thay đổi về lớp thực thi trong Prague vì chúng bao gồm những tính năng quan trọng ảnh hưởng đến mạng lưới Ethereum và các nhà xác minh. Hãy cùng đi vào chi tiết những thay đổi này.
Tổng quan cấp cao hơn về Pectra
Electra đã giới thiệu nhiều tính năng mới cho tầng beacon. Các cập nhật chính bao gồm:
Cho phép số dư hợp lệ của người xác minh thay đổi từ 32 đến 2048 ETH (thay vì cố định 32 ETH).
Cho phép người xác minh khởi tạo việc rút tiền bằng phiếu rút cấp hai (không còn cần khóa người xác minh hoạt động).
Thay đổi cách xử lý gửi tiền Eth1 ở tầng dấu hiệu (không còn phân tích sự kiện từ hợp đồng gửi tiền).
Đối với việc thêm một khung việc xử lý yêu cầu từ hợp đồng Eth1 thông thường trên tầng tín hiệu (tương tự cách quản lý tiền gửi trước của Electra).
Trong khi đó, Prague đã áp dụng những thay đổi sau đối với bộ phận thực hiện:
Một hợp đồng thông dịch mới hỗ trợ đường cong BLS12-381 để xác minh chứng cớ zkSNARK (ngoài đường cong BN254 phổ biến).
Một hợp đồng hệ thống mới, được sử dụng để lưu trữ và truy cập tới tối đa 8192 mã băm khối lịch sử (rất hữu ích đối với khách hàng không 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 chuyển đổi các hoạt động tập trung calldata (như rollup) vào các khối blobs được giới thiệu trong Dencun.
Hỗ trợ nhiều hơn số lượng blobs của mỗi khối Eth1 và cung cấp API để đọc số lượng này.
EOA (Tài khoản Ngoại vi) được phép sở hữu mã tài khoản của chính mình, mở rộng đáng kể khả năng thực hiện của EOA, chẳng hạn như thực hiện các cuộc gọi đa nguồn hoặc ủy quyền thực hiện cho địa chỉ khác.
Hãy tham khảo đề xuất cải tiến Ethereum liên quan EIP( để tiếp tục thảo luận:
EIP-7251: Thêm MAX_EFFECTIVE_BALANCE
EIP-7002: Lớp thực thi có thể kích hoạt việc thoát
EIP-6110: Cung cấp tiền gửi của người xác minh trên chuỗi
EIP-7549: Di chuyển chỉ số ủy ban khỏi chứng minh
EIP-7685: Yêu cầu Tầng Thực Hiện Chung
EIP-2537: Tiền biên dịch cho hoạt động của đường cong BLS12-381
EIP-2935: Lưu trữ băm khối lịch sử trong trạng thái
EIP-7623: Tăng chi phí calldata
EIP-7691: Tăng khả năng xử lý blob
EIP-7840: Thêm lập lịch blob vào tệp cấu hình EL
EIP-7702: Thiết lập mã tài khoản EOA
Các EIP này có một số liên quan chính đến lớp đồng thuận (cờ bản), trong khi những cái khác liên quan đến lớp thực thi. Một số đi qua hai lớp, vì một số hoạt động (như gửi và rút tiền) cần phải đồng bộ hóa thay đổi 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 Electra và Prague ra là không thực tế, vì vậy chúng ta sẽ xem xét từng EIP một cách tuần tự và chỉ định các thành phần Ethereum bị ảnh hưởng trong mỗi trường hợp.
EIP-7251: Tăng MAX_EFFECTIVE_BALANCE
Tham khảo: EIP-7251
Kể từ hard fork Phase0 đầu tiên, để chuẩn bị cho bằng chứng cổ phần của Ethereum, số dư hiệu quả tối đa của các trình xác thực đã được cố định ở mức 32 ETH cho đến Electra. Yêu cầu trình xác thực kích hoạt ít nhất là spec.min_activation_balance (32 ETH). Sau khi được kích hoạt, trình xác thực bắt đầu với số dư hiệu quả tối đa này, nhưng có thể giảm số dư hiệu quả của chúng xuống spec.ejection_balance (16 ETH) và bị loại bỏ khi đạt đến ngưỡng đó. Logic "tối thiểu" này vẫn giữ nguyên trong Electra, nhưng bây giờ spec.max _effective _balance đã 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ả số tiền này sẽ đóng góp vào số dư hiệu quả của họ. Sự thay đổi này đánh dấu sự thay đổi từ "32ETH - Proof of Stake" sang "Proof of Stake": )
Số dư hiện tại có thể thay đổi sẽ được sử dụng cho:
Tăng cơ hội trở thành người đề xuất khối, tỷ lệ thuận với số dư hợp lệ
Tăng cơ hội trở thành thành viên ủy ban đồng bộ, tỷ lệ thuận với số dư hợp lệ
Dựa trên việc tính toán số tiền bị cắt giảm tương đối và phạt không hoạt động
Hai hoạt động đầu tiên là các hoạt động mang lại lợi nhuận cao nhất cho người xác minh. Do đó, sau Electra, các người xác minh với số tiền gửi lớn sẽ tham gia vào việc đề xuất khối và hội đồng đồng bộ thường xuyên hơn, tần suất này tương ứng với số dư hiệu lực của họ.
Một yếu tố khác ảnh hưởng đến việc cắt giảm. Tất cả các khoản phạt cắt giảm tỷ lệ thuận với số dư hiệu lực của các nhà xác minh:
Việc giảm phạt 'Ngay lập tức' và 'Trì hoãn' ảnh hưởng lớn đến các nhà xác minh có số tiền gửi cọc lớn.
Phạt cắt "trễ hơn" với các nhà xác minh bị cắt giảm đặt cược cao cũng lớn hơn, vì phần bị cắt giảm trong tổng cược trở nên lớn hơn.
Người tố cáo có số dư hợp lệ cao hơn sẽ nhận tỷ lệ cắt giảm tiền đặt cược lớn hơn.
Electra cũng đề xuất thay đổi tỷ lệ cắt giảm, xác định một phần số dư của người xác minh bị cắt giảm và được nhận bởi người tố cáo.
Tiếp theo là ảnh hưởng về tính không hợp lệ. Khi người xác minh không hoạt động (chứng minh hoặc đề xuất) khi ngoại tuyến, điểm không hợp lệ sẽ tích luỹ, dẫn đến áp dụng hình phạt không hợp lệ cho mỗi chu kỳ. Những hình phạt này cũng tương quan với số dư hợp lệ của người xác minh theo tỷ lệ.
Do sự gia tăng số dư hiệu quả, "giới hạn thay thế" cho trình xác thực cũng đã thay đổi. Trong Ethereum "tiền 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ế thoát được định nghĩa là "không quá 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 trình xác thực "cố định" có cùng cổ phần để thoát. Tuy nhiên, sau "Electra", có thể chỉ có một vài "cá voi" sẽ thoát ra, vì chúng chiếm một phần đáng kể trong tổng số cổ phần.
Một trong những điều cần xem xét khác là việc xoay vòng nhiều khóa xác minh trên một trường hợp xác minh đơn lẻ. Hiện tại, các trường hợp xác minh lớn phải chạy hàng nghìn khóa xác minh để thích nghi với việc giao rất nhiều tiền đặt cược, chia nhỏ chúng thành phần 32 ETH. Với Electra, hành vi này không còn bắt buộc nữa. Về mặt tài chính, thay đổi này không ảnh hưởng nhiều vì phần thưởng và xác suất tỷ lệ thuận với số tiền đặt cược. Do đó, 100 khóa xác minh mỗi phần 32 ETH tương đương với một khóa xác minh 3200 ETH. Ngoài ra, nhiều khóa xác minh hoạt động có thể có cùng một chứng chỉ rút tiền Eth1, cho phép tất cả phần thưởng được rút về một địa chỉ ETH duy nhất, tránh chi phí gas liên quan đến việc hợp nhất phần thưởng. Tuy nhiên, quản lý một lượng lớn khóa có thể tạo ra chi phí quản lý bổ sung.
Khả năng cân đối của người xác minh đã được tăng cường với một loại yêu cầu thực thi mới. Trước đó, chúng ta có tiền gửi và rút tiền. Bây giờ, sẽ có một loại khác: yêu cầu tổng hợp. Nó sẽ hợp nhất hai người xác minh thành một. Yêu cầu thao tác sẽ bao gồm khóa công khai của người xác minh nguồn và đích, và sẽ được xử lý tương tự như tiền gửi và rút tiền. Yêu cầu tổng hợp cũng sẽ có giới hạn yêu cầu chờ xử lý và cân đối, giống như tiền gửi và rút tiền.
Tóm lại như sau:
Đối với các nhà xác minh độc lập nhỏ, Electra đã giới thiệu khả năng tự động tăng số dư hợp lệ (và phần thưởng). Trước đây, bất kỳ số dư lợi nhuận nào vượt quá 32 ETH chỉ có thể rút ra, nhưng sau Electra, số dư lợi nhuận này sẽ được đóng góp vào số dư hợp lệ. Tuy nhiên, số dư hợp lệ chỉ có thể tăng theo bội số của spec.effective_balance_increment (1 ETH), điều này có nghĩa là việc tăng chỉ xảy ra sau khi đạt đến ranh giới "1 ETH" tiếp theo.
Đối với các nhà xác minh độc lập lớn, Electra cung cấp sự đơn giản hóa quản lý đáng kể bằng cách cho phép kết hợp nhiều chìa khóa xác minh hoạt động thành một. Mặc dù điều này không thay đổi quy tắc trò chơi, nhưng quản lý một đặt cược 1x2048 chắc chắn đơn giản hơn quản lý 64x32 chắc chắn nhiều hơn.
Đối với nhà cung cấp thế chấp lưu động, họ thu thập thế chấp nhỏ từ người dùng và phân phối giữa các người xác minh, Electra đã tăng tính linh hoạt trong phân phối thế chấp trong kế hoạch, nhưng cũng đồng thời đòi hỏi một sự tái cấu trúc nghiêm trọng đối với quyết toán của người xác minh với số dư hiệu quả cố định là 32 ETH.
Một chủ đề quan trọng khác là dữ liệu lịch sử và ước lượng lợi nhuận của người xác minh, đặc biệt quan trọng đối với những người mới tham gia, họ cố gắng đánh giá rủi ro và lợi ích. Trước Electra (tính đến thời điểm viết bài này), sự đồng đều đã được tạo ra trên dữ liệu lịch sử với giới hạn 32 ETH (dù là tối thiểu hay tối đa) . Tất cả số dư hợp lệ của người xác minh, phần thưởng, trừng phạt cắt giảm cá nhân, tần suất đề xuất khối và các chỉ số khác đều tương đồng. Sự đồng đều này giúp Ethereum có thể thử nghiệm cơ chế đồng thuận mà không cần xử lý các giá trị ngoại lệ thống kê, từ đó thu thập dữ liệu hành vi mạng có giá trị.
Sau Electra, phân phối staking sẽ trải qua những thay đổi đáng kể. Các nhà xác minh lớn sẽ tham gia thường xuyên hơn trong việc đề xuất khối và ủy ban đồng bộ, và sẽ phải đối mặt với hình phạt lớn hơn trong sự kiện cắt giảm, cũng như có ảnh hưởng lớn hơn đối với việc cắt giảm trễ, hàng đợi kích hoạt và hàng đợi rút khỏi. Mặc dù điều này có thể tạo ra thách thức trong việc tập trung dữ liệu, nhưng sự đồng thuận của Ethereum đảm bảo tính toán phi tuyến tính là tối thiểu. Chỉ có thành phần phi tuyến tính duy nhất sử dụng sqrt)total_effective_balance( để tính toán phần thưởng cơ bản, áp dụng cho tất cả các nhà xác minh. Điều này có nghĩa là phần thưởng và cắt giảm của nhà xác minh vẫn có thể được ước tính dựa trên “mỗi 1 ETH” (hoặc chính xác hơn là dựa trên spec.effective_balance_increment, điều này có thể thay đổi trong tương lai).
Để biết thêm thông tin chi tiết, vui lòng xem bài viết của chúng tôi về hành vi xác minh trước đó.
EIP-7002: Lớp thực thi có thể kích hoạt để thoát
Tham khảo: EIP-7002
Mỗi người xác minh trong Ethereum đều có hai cặp khóa: một cặp khóa hoạt động và một cặp khóa rút tiền. Khóa công khai BLS hoạt động được sử dụng như là danh tính chính của người xác minh trên chuỗi cái phong, cặp khóa này được sử dụng để ký vào các khối, chứng minh, cắt giảm, tổng hợp ủy viên đồng bộ và (trước EIP này) thoát tự nguyện (để bắt đầu quá trình rút người xác minh khỏi sự đồng thuận sau một khoảng thời gian chờ). Cặp khóa thứ hai ("chứng chỉ rút tiền") có thể là một cặp khóa BLS khác hoặc một tài khoản Eth1 thông thường (bao gồm cả khóa riêng tư và địa chỉ). Bây giờ, việc rút tiền vào địa chỉ ETH yêu cầu thông điệp rút tiền được ký bởi khóa riêng tư BLS hoạt động. EIP này đã thực hiện các thay đổi.
Trên thực tế, chủ sở hữu của hai cặp khóa (hoạt động và rút tiền) này có thể khác nhau. Khóa hoạt động của trình xác thực chịu trách nhiệm xác minh: chạy máy chủ, duy trì hoạt động, v.v., trong khi thông tin rút tiền thường được kiểm soát bởi chủ sở hữu cổ phần, người nhận phần thưởng và chịu trách nhiệm về tiền. Hiện tại, chỉ chủ sở hữu cổ phần kiểm soát thông tin rút tiền mới không thể bắt đầu rút tiền của trình xác thực và chỉ có thể rút phần thưởng. Tình huống này cho phép chủ sở hữu khóa hoạt động của trình xác thực giữ số dư của trình xác thực một cách hiệu quả với tư cách là "con tin". Người xác thực có thể "ký trước" thông báo thoát và giao nó cho chủ sở hữu cổ phần, nhưng cách giải quyết này không lý tưởng. Ngoài ra, cả trích xuất và rút tiền hiện đều yêu cầu tương tác với trình xác thực lớp đèn hiệu thông qua API chuyên dụng.
Giải pháp tốt nhất là cho phép chủ sở hữu đặt cược để thực hiện rút và rút tiền cùng một lúc thông qua cuộc 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, giúp đơn giản hóa đáng kể quy trình.
EIP này cho phép chủ sở hữu cược đặt kích hoạt việc rút tiền và rút ra thông qua việc gửi giao dịch tiêu chuẩn từ địa chỉ ETH của họ đến hợp đồng thông minh riêng biệt (tương tự 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 quy trình rút ra khi đủ điều kiện đặt cược) như sau:
Người thế chấp gửi yêu cầu rút tiền đến hợp đồng rút tiền của hệ thống (yêu cầu "in").
Hợp đồng thu phí cụ thể (tính bằng ETH) để giảm thiểu các cuộc tấn công có ý đồ xấu tiềm tàng và tương tự như EIP-1559, phí sẽ tăng khi hàng đợi yêu cầu đông đúc.
Hợp đồng sẽ lưu trữ yêu cầu rút tiền/ thoát khỏi 'in' vào bộ nhớ của nó.
Khi một khối được đề xuất lên tầng dấu hiệu, yêu cầu rút tiền/ rút khỏi hàng đợi 'in' sẽ đượ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 các nhà xác thực hoạt động, sắp xếp nhà xác thực rời khỏi và tạo ra yêu cầu rút 'out'.
Yêu cầu rút tiền "out" được xử lý ở tầng thực thi, người giao dịch cầm cố nhận được ETH của họ.
Mặc dù việc gửi tiền là một hoạt động được kích hoạt trong khối Eth1 và sau đó được "di chuyển" vào tầng mốc tín hiệu thông qua hàng đợi gửi tiền "đang xử lý", nhưng việc rút tiền tuân theo một kế hoạch khác nhau. Chúng được kích hoạt trên tầng mốc tín hiệu (thông qua CLI) và sau đó được "di chuyển" vào khối Eth1. Hiện nay, hai kế hoạch sẽ hoạt động thông qua một khung chung (như mô tả dưới đây): tạo yêu cầu tại tầng Eth1, xử lý hàng đợi gửi tiền/rút tiền/gộp "đang xử lý" và xử lý tại tầng mốc tín hiệu. Đố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.
Thông qua EIP này, người thế chấp có thể rút và thoát khỏi các nhà xác minh của họ bằng giao dịch ETH thông thường mà không cần tương tác trực tiếp với CLI của nhà xác minh hoặc truy cập cơ sở hạ tầng của nhà xác minh. Điều này đáng kể đơn giản hóa quá trình thế chấp, đặc biệt đối với các nhà cung cấp thế chấp lớn. Cơ sở hạ tầng của nhà xác minh hiện nay hầu như có thể được cô lập hoàn toàn, vì chỉ cần duy trì khóa của các nhà xác minh hoạt động và tất cả quá trình thế chấp có thể được xử lý ở nơi khác. Điều này loại bỏ nhu cầu chờ đợi các hành động nhà xác minh hoạt động độc lập của các nhà thế chấp và đơn giản hóa đáng kể phần ngoại tuyến của dịch vụ Lido như Mô-đun Thế chấp Cộng đồng.
Do đó, EIP này đã "hoàn thành" quá trình giao dịch đặt cọc và hoàn toàn chuyển nó vào tầng Eth1, giảm thiểu rủi ro an ninh hạ tầng và tăng cường tính phi tập trung của đề xuất đặt cọc độc lập.
EIP-6110: Gửi khoản tiền đặt cọc cho ngườ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 sự kiện trong hợp đồng 'Tiền gửi' của hệ thống (như đã được đề cập chi tiết trong bài viết trước đó). Hợp đồng chấp nhận ETH và chứng chỉ xác thực của các nhà xác minh, phát ra sự kiện 'Deposit)(', sau đó các sự kiện này được phân tích và chuyển đổi thành yêu cầu tiền gửi trên tầng beacon. Hệ thống này có nhiều điểm hạn chế: nó yêu cầu bỏ phiếu cho eth1data trên tầng beacon, điều này làm tăng đáng kể độ trễ. Ngoài ra, tầng beacon cần truy vấn tầng 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 xử lý nhiều vấn đề này, là đưa yêu cầu tiền gửi trực tiếp vào khối Eth1 tại vị trí được chỉ định. Cơ chế này tương tự như quy trình rút tiền được mô tả trong EIP trước đó.
Những thay đổi được đề xuất trong EIP này rất triển vọng. Xử lý eth1data hiện nay có thể hoàn toàn loại bỏ, không cần phải bỏ phiếu hoặc trì hoãn trong thời gian dài giữa các gói tiền gửi trên Eth1 và lớp hiệu lực (được ước lượng khoảng 12 giờ). Nó cũng loại bỏ logic của bản chụp hợp đồng gửi tiền. EIP này đơn giản hóa việc xử lý tiền gửi và làm cho nó phù hợp với giải pháp xử lý tiền rút được đề cập ở trên.
Đối với người đặt cọc và người xác minh, những thay đổi này giảm thiểu đáng kể sự trì hoãn giữa tiền gửi và việc kích hoạ xác minh. Khi xác minh bị cắt giảm, việc bổ sung cũng sẽ nhanh hơn.
Về EIP này không có gì để nói thêm, 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ả các bên liên quan.
EIP-7685: Yêu cầu Tầng Thực thi Chung
Tham khảo: EIP-7685
EIP này nên được đề xuất trước ba EIP liên quan đến tiền gửi/rút tiền/gộp vốn, vì nó tạo nền tảng cho những EIP này. Tuy nhiên, việc giới thiệu ở đây nhằm nhấn mạnh nhu cầu ngày càng tăng về việc di chuyển dữ liệu đặc biệt giữa các khối (lớp) của Eth1 (thực thi) và beacon (đồng thuận). EIP này ảnh hưởng đến hai lớp, làm cho xử lý yêu cầu được kích hoạt bằng giao dịch ETH thông thường trở nên hiệu quả hơn. Hiện tại, chúng ta quan sát được rằng:
Sự kiện gửi tiền trong khối Eth1 được "di chuyển" sang khối đánh dấu để 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ý.
Beacon.
Ba thao tác này cho thấy sự cần thiết của việc xử lý thống nhất các loại yêu cầu khi chuyển đổi giữa tầng thực thi và tầng biểu tượng. Ngoài ra, chúng ta cần có khả năng chỉ sử dụng tầng Eth1 để kích hoạt các thao tác này, vì điều này sẽ giúp chúng ta cô lập cơ sở hạ tầng của các nhà xác minh khỏi cơ sở hạ tầng quản lý thế chấp, từ đó nâng cao tính bảo mật. Do đó, một giải pháp chung để quản lý các yêu cầu của loại này là cần thiết và thực tế.
EIP này thiết lập khung cho ít nhất ba trường hợp chính: gửi tiền, rút tiền và sáp nhập. Đó là lý do tại sao EIP ban đầu đã giới thiệu các trường như WITHDRAWAL_REQUEST_TYPE và DEPOSIT_REQUEST_TYPE, bây giờ sáp nhậ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ý các giới hạn liên quan đến các yêu cầu này (xem hằng số: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Mặc dù chi tiết cụ thể về việc triển khai của khung này vẫn chưa có sẵn, nhưng nó chắc chắn sẽ bao gồm các loại yêu cầu quan trọng, cơ chế tích hợp (ví dụ như yêu cầu băm và Merkle), cùng với hàng đợi xử lý và giới hạn tốc độ.
EIP này có ý nghĩa kiến trúc, cho phép Eth1 kích hoạt các hoạt động quan trọng trong lớp dấu hiệu thông qua một khung chung. Đối với người dùng cuối và dự án, điều này có nghĩa là tất cả các yêu cầu được kích hoạt ở tầng Eth1 sẽ được truyền và xử lý hiệu quả hơn trên tầng dấu hiệu.
EIP-2537：Sự chuẩn bị trước cho việc thao tác đường cong BLS12-381
Tham khảo: EIP-2537
Nếu bạn không muốn hiểu sâu, bạn có thể xem trước BLS12-381 như một loại phép toán băm mã hóa phức tạp, hiện đã có thể sử dụng trong hợp đồng thông minh. Đối với những người quan tâm, hãy cùng chúng tôi tìm hiểu sâu hơn.
Các phép toán toán học trên đường cong elliptic như BLS12-381 (và tương ứng BN-254) hiện đang chủ yếu được sử dụng cho hai mục đích:
Chữ ký BLS, trong đó sử dụng một thao tác đặc biệt được gọi là "cặp" để xác minh các chữ ký này. Chữ ký BLS được sử dụng rộng rãi bởi người xác minh vì chúng cho phép nhiều chữ ký được tổng hợp thành một. Người xác minh 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 hỗ trợ cặp nào, chẳng hạn như BN254).
Xác minh chứng minh zkSNARK, trong đó cặp được sử dụng để xác minh chứng minh. Ngoài ra, cam kết KZG cho các khối lớn được giới thiệu bởi bifurcation cứng Dencun cũng sử dụng cặp để xác minh cam kết khối.
Nếu bạn muốn xác minh chữ ký BLS hoặc 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, rất tốn kém về mặt tính toán. Ethereum đã có một hợp đồng được biên dịch sẵn (EIP-196 và EIP-197) cho các hoạt động đường cong BN254. 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 hiện nay) vẫn chưa được thực hiện như đã được biên dịch sẵn. Trong trường hợp không có sự biên dịch trước như vậy, việc thực hiện ghép nối và các hoạt động đường cong khác trong hợp đồng thông minh đòi hỏi rất nhiều tính toán, như được hiển thị ở đây và tiêu thụ một lượng khí 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à trong việc xác minh chữ ký BLS rẻ tiền dựa trên đường cong BLS12-381. Điều này làm cho việc thực hiện các giải pháp ngưỡng về mục đích trở nên có thể. Như đã đề cập trước đó, người xác minh Ethereum đã sử dụng chữ ký dựa trên BLS12-381. Thông qua 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ý của người xác minh được tổng hợp. Điều này có thể đơn giản hóa chứng minh đồng thuận và cầu nối tài sản qua mạng lưới, vì chữ ký BLS được sử dụng rộng rãi trong blockchain. Chính chữ ký BLS ngưỡng cho phép xây dựng nhiều giải pháp ngưỡng hiệu quả để sử dụng 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 chứng minh zkSNARK rẻ hơn sẽ mở khóa nhiều ứng dụng. Hiện nay, nhiều giải pháp dựa trên zkSNARK đều bị rào cản bởi chi phí xác minh chứng minh cao, điều này làm cho 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 lịch sử khối hash trong trạng thái
Tham khảo: EIP-2935
Đề xuất EIP này lưu trữ 8192 bản ghi lịch sử khối (khoảng 27.3 giờ) trong trạng thái blockchain, để mở rộng lịch sử cho khách hàng không 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 mã hoạt động BLOCKHASH, giữ nguyên 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ế đặc biệt để lưu trữ và truy xuất các bản ghi lịch sử. Hợp đồng này thực hiện thao tác set)( khi xử lý khối ở tầng thực thi. Phương thức get)( của nó có sẵn cho bất kỳ ai truy cập, để truy xuất các bản ghi lịch sử khối cần thiết từ bộ đệm vòng.
Hiện tại, việc tham chiếu mã hash khối lịch sử trong EVM là khả thi, nhưng truy cập chỉ giới hạn trong 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ũ là rất quan trọng, đặc biệt là đối với ứng dụng giao mạng (cần chứng minh dữ liệu các khối trước đó) và khách hàng không trạng thái, chúng thường cần truy cập mã hash khối cũ định kỳ.
EIP này mở rộng phạm vi thời gian mà rollup và ứng dụng đa chuỗi có thể sử dụng, cho phép chúng truy cập trực tiếp vào dữ liệu lịch sử trong EVM mà không cần phải thu thập từ bên ngoài. Do đó, những giải pháp này trở nên mạnh mẽ và bền vững hơn.
EIP-7623: Tăng chi phí calldata
Tham khảo: EIP-7623
calldata điều chỉnh kích thước tải trọng hiệu quả của giao dịch và trong một số trường hợp có thể rất lớn (ví dụ, khi truyền một mảng lớn hoặc bộ đệm nhị phân như một tham số). Việc sử dụng đáng kể của calldata chủ yếu được đưa ra cho rollup, chúng gửi tải trọng hiệu quả bằng cách chứa calldata trạng thái rollup hiện tại.
Việc đưa dữ liệu nhị phân lớn và có thể chứng minh vào chuỗi khối là rất quan trọng đối với rollup. Việc nâng cấp Dencun (Deneb-Cancun) cho các trường hợp sử dụng này đã đem lại một sáng tạo quan trọng - giao dịch blob (EIP-4844). Giao dịch blob có chi phí gas "blob" riêng của nó, mặc dù nó là tạm thời lưu trữ, nhưng chứng minh mật mã của nó (cam kết KZG) cùng với băm của nó đã được tích hợp vào lớp đồng thuận. Do đó, so với việc sử dụng calldata để lưu trữ dữ liệu, blob cung cấp một giải pháp tốt hơn cho rollup.
Để khuyến khích rollup chuyển dữ liệu của nó thành blob, có thể đạt được bằng cách "cà rốt và gậy củ cải". Phí gas của blob đã giảm được coi là "cà rốt", trong khi EIP này tăng chi phí calldata làm "gậy", nhằm kiềm chế việc lưu trữ dữ liệu quá mức trong giao dịch. EIP này bổ sung EIP-7691 tiếp theo (Tăng cường lưu lượng blob), EIP-7691 nâng cao số lượng blob tối đa cho mỗi khối.
EIP-7691：Tăng tốc độ xử lý blob
Tham khảo: EIP-7691
Trong cuộc chia cắt cứng trước đó của Dencun, blob đã được giới thiệu, và giá trị ban đầu của blob "mỗi khối" tối đa và mục tiêu là một ước lượng thận trọng. Điều này là do sự 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 như thế nào khi chúng lan truyền giữa các nút xác minh. Cấu hình trước đó đã được chứng minh là tốt, điều này làm cho việc kiểm tra giá trị mới là thời điểm thích hợp. Trước đó, mục tiêu/số lượng blob tối đa cho mỗi khối đã được đặt là 3/6. Các hạn chế này hiện đã được tăng lên thành 6/9 tương ứng.
Kết hợp với EIP-7623 trước đó (tăng chi phí calldata), điều chỉnh này tiếp tục thúc đẩy rollup chuyển dữ liệu của nó từ calldata sang các blobs. Công việc tìm kiếm tham số blob tốt nhất vẫn đang được tiếp tục.
EIP-7840: Thêm lịch trình blob vào tệp cấu hình EL
Tham khảo: EIP-7840
Đề xuất EIP này thêm mục tiêu và số lượng blob tối đa '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. Chức năng này đặc biệt hữu ích trong việc ướ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 thuộc sở hữu bên ngoài) không thể có bất kỳ mã nào, nhưng có thể cung cấp chữ ký giao dịch (tx.origin). Ngược lại, một hợp đồng thông minh có bytecode, nhưng không thể chủ động đề xuất chữ ký trực tiếp của "nó". Bất kỳ tương tác người dùng nào yêu cầu logic bổ sung, tự động và có thể xác minh hiện chỉ có thể thực hiện hành động mong muốn bằng cách gọi hợp đồng bên ngoài. Tuy nhiên, trong trường hợp này, hợp đồng bên ngoài trở thành người gửi msg.sender của hợp đồng tiếp theo, thực hiện cuộc gọi "từ hợp đồng, không phải người dùng".
EIP này giới thiệu loại giao dịch SET \ _CODE \ _TX \ _TYPE = 0x04 mới (chúng tôi đã có giao dịch 0x1 cũ trước đó, giao dịch 0x02 mới từ Berlin và nâng cấp EIP-1559 và giao dịch blob 0x03 được giới thiệu ở Dencun). Loại giao dịch mới này cho phép bạn 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ó". Từ góc độ bên ngoài, EOA dường như "mượn" mã từ một hợp đồng bên ngoài và thực hiện nó trong một giao dịch. 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 kho lưu trữ "mã" của địa chỉ EOA (cho đến EIP này, kho lưu trữ "mã" này luôn trống cho EOA).
Hiện tại, kiểu giao dịch mới 0x04 trong đề xuất EIP này bao gồm một mảng:
Mỗi yếu 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 loại này, mã của EOA cụ thể được thiết lập 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ị cho việc kết nối, 0xef0100 biểu thị giá trị ma thuật đặc biệt mà hợp đồng thông thường thông thường không thể chứa (theo EIP-3541). Giá trị ma thuật này đảm bảo rằng EOA này không thể được coi là hợp đồng thông thường, cũng không thể được gọi như một hợp đồng thông thường.
Khi EOA này thực hiện giao dịch, địa chỉ được chỉ định sẽ được sử dụng để gọi mã tương ứng trong ngữ cảnh của EOA đó. Mặc dù chi tiết triển khai đầy đủ của EIP này vẫn chưa rõ ràng, nhưng có thể xác định rằng nó sẽ mang lại những thay đổi đáng kể.
Một tác động chính là khả năng thực hiện cuộc gọi đa lớp trực tiếp từ EOA (multicall). Cuộc gọi đa lớp là một xu hướng tiếp 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ụ như Uniswap V4, Balancer V3 hoặc Euler V2). Với EIP này, bây giờ có thể khởi động cuộc gọi đa lớp 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)( yêu cầu hai giao dịch riêng biệt. EIP này cho phép logic "ủy quyền trước" phổ biến cho phép những việc như approve)X( + deposit)X( được thực hiện trong một giao dịch.
Một lợi thế khác của việc « đại diện » cho giao dịch được ủy quyền bởi 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à đặc biệt khao khát, để giúp người dùng mới tiếp cận Ethereum.
Kết hợp với EOA, logic có thể lập trình đã mở ra nhiều khả năng, chẳng hạn như thiết lập các ràng buộc bảo mật, đặt giới hạn chi tiêu, yêu cầu KYC bắt buộc, v.v.
Tất nhiên, sự thay đổi này cũng đặt ra một số câu hỏi 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 bao gồm trong chữ ký hay không. Một phức tạp khác là sự lựa chọn giữa việc sử dụng địa chỉ của mã đối tượng và nhúng bytecode thực tế. Cả hai phương pháp đều có những tính năng và hạn chế độc đáo riêng. Ngoài ra, việc sử dụng nonce đóng một vai trò quan trọng trong việc xác định xem quyền là "đa mục đích" hay "đơn mục đích". Các yếu tố này ảnh hưở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ư chữ ký vô hiệu hóa hàng loạt 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 (ở đây) đáng để khám phá thêm.
Điều đáng chú ý là sự thay đổi này sẽ ảnh hưởng đến một trong những cơ chế bảo mật của Ethereum, tx.origin. Thông tin chi tiết hơn về việc triển khai EIP này là cần thiết, nhưng có vẻ như hành vi của require)tx.origin == msg.sender( sẽ thay đổi. Kiểm tra này là cách chắc chắn nhất để đảm bảo rằng msg.sender là EOA chứ không phải hợp đồng. CÁC 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 THẤT BẠI VÀ CÓ THỂ BỊ PHÁ VỠ (VÍ DỤ: BẰNG CÁCH GỌI HÀM TẠO HOẶC BẰNG CÁCH TRIỂN KHAI MÃ TẠI MỘT ĐỊA CHỈ ĐƯỢC XÁC ĐỊNH TRƯỚC SAU KHI 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 tái xâm nhập và cho vay flash, nhưng không lý tưởng vì chúng cũng cản trở sự tích hợp với các giao thức bên ngoài. Ngay cả yêu cầu đáng tin cậy)tx.origin == msg.sender( kiểm tra dường như trở nên lỗi thời sau EIP này. Giao thức phải đáp ứ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" sẽ không còn áp dụng nữa - bây giờ mọi địa chỉ đều có thể có mã được liên kết với nó.
Sự phân tách giữa EOA truyền thống và hợp đồng thông minh tiếp tục mờ nhạt. EIP này khiến Ethereum gần hơn với thiết kế như TON, trong đó mỗi tài khoản về cơ bản đều là mã có thể thực thi. Khi tương tác với giao thức trở nên phức tạp hơn, việc sử dụng logic có thể lập trình để cải thiện trải nghiệm người dùng cuối cùng là quá trình tự nhiên của sự tiến hóa này.
Kết luận
Budapest / Electra (Pectra) được nâng cấp vào tháng 3 năm 2025. Các thay đổi kế hoạch đáng chú ý nhất bao gồm:
Các bên chứng thực có thể thay đổi hiệu quả với khoản đặt cọc tối đa 2048 ETH, điều này sẽ thay đổi đáng kể phân phối đặt cọc, lịch trình bên chứng thực và giảm thiểu quản lý cho những nhà cung cấp đặt cọc lớn hơn bằng cách tích hợp các khoản đặt cọc nhỏ hơn.
Cải tiến tương tác giữa lớp thực thi và lớp đồng thuận, đơn giản hóa giao tiếp dữ liệu giữa khối thực thi Eth1 và khối mốc. Điều này sẽ đơn giản hóa đáng kể quá trình gửi tiền, kích hoạt, rút tiền và thoát, tăng tốc các quy trình này và đặt nền tảng cho tương tác tiếp theo giữa lớp đồng thuận và lớp thực thi.
Hỗ trợ trực tiếp việc ký BLS và xác minh zkSNARK rẻ hơn thông qua tiền xử lý BLS12-381 mới trong hợp đồng thông minh "phù hợp với cặp"
Khuyến khích Rollups sử dụng giao dịch blob bằng cách tăng ngưỡng giao dịch blob và tăng chi phí calldata.
Biến EOA thành tài khoản có thể lập trình, cung cấp cho nó khả năng gọi nhiều lần, 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 đáng kể đến trải nghiệm người dùng cuối của các lớp đặt cọc và đồ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 diễn ra, chúng tôi sẽ đề cập đến các bản cập nhật này trong một bài viết trong tương lai.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Giải thích Hard Fork của Ethereum sắp tới - Bản nâng cấp Pectra
Giới thiệu
Trong bài viết trước đó của chúng tôi, chúng tôi đã điều tra một cách chi tiết về vòng đời của các nhà xác minh Ethereum và 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 hard fork Electra và nâng cấp Prague sắp tới, và giải thích chúng chi tiết.
Lịch sử của hard fork Ethereum 2.0 'Proof of Stake' là 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 có, trong khi lớp thực thi vẫn duy trì proof of work (hard fork Phase0 và Altair). Sau đó, trong hard fork Bellatrix, PoS được hoàn toàn kích hoạt (mặc dù chưa có việc rút tiền). Tiếp theo, hard fork Capella cho phép rút tiền, hoàn thành vòng đời của người xác minh. Hard fork gần đây nhất Deneb (một phần của nâng cấp Deneb/Cancun) đã điều chỉnh lại các tham số của chuỗi beacon, bao gồm cửa sổ thời gian của chứng minh, xử lý việc rút tiền tự nguyện và giới hạn thay đổi người xác minh. Các thay đổi chính trong Dencun xảy ra ở lớp thực thi, giới thiệu giao dịch blob, blob gas, cam kết KZG cho blob và loại bỏ hoạt động SELFDESTRUCT.
Hiện nay, Prague/Electra (hay còn gọi là Pectra) đã thực hiện một hard fork quan trọng để đưa ra cải tiến cho lớp thực thi và lớp đồng thuận. Là một trong những nhà kiểm toán dự án Lido, chúng tôi tập trung chủ yếu vào những thay đổi về đồng thuận và đặt cọc trong hard fork này. Tuy nhiên, chúng tôi không thể bỏ qua những thay đổi về lớp thực thi trong Prague vì chúng bao gồm những tính năng quan trọng ảnh hưởng đến mạng lưới Ethereum và các nhà xác minh. Hãy cùng đi vào chi tiết những thay đổi này.
Tổng quan cấp cao hơn về Pectra
Electra đã giới thiệu nhiều tính năng mới cho tầng beacon. Các cập nhật chính bao gồm:
Trong khi đó, Prague đã áp dụng những thay đổi sau đối với bộ phận thực hiện:
Hãy tham khảo đề xuất cải tiến Ethereum liên quan EIP( để tiếp tục thảo luận:
Các EIP này có một số liên quan chính đến lớp đồng thuận (cờ bản), trong khi những cái khác liên quan đến lớp thực thi. Một số đi qua hai lớp, vì một số hoạt động (như gửi và rút tiền) cần phải đồng bộ hóa thay đổi 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 Electra và Prague ra là không thực tế, vì vậy chúng ta sẽ xem xét từng EIP một cách tuần tự và chỉ định các thành phần Ethereum bị ảnh hưởng trong mỗi trường hợp.
EIP-7251: Tăng MAX_EFFECTIVE_BALANCE
Tham khảo: EIP-7251
Kể từ hard fork Phase0 đầu tiên, để chuẩn bị cho bằng chứng cổ phần của Ethereum, số dư hiệu quả tối đa của các trình xác thực đã được cố định ở mức 32 ETH cho đến Electra. Yêu cầu trình xác thực kích hoạt ít nhất là spec.min_activation_balance (32 ETH). Sau khi được kích hoạt, trình xác thực bắt đầu với số dư hiệu quả tối đa này, nhưng có thể giảm số dư hiệu quả của chúng xuống spec.ejection_balance (16 ETH) và bị loại bỏ khi đạt đến ngưỡng đó. Logic "tối thiểu" này vẫn giữ nguyên trong Electra, nhưng bây giờ spec.max _effective _balance đã 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ả số tiền này sẽ đóng góp vào số dư hiệu quả của họ. Sự thay đổi này đánh dấu sự thay đổi từ "32ETH - Proof of Stake" sang "Proof of Stake": )
Số dư hiện tại có thể thay đổi sẽ được sử dụng cho:
Hai hoạt động đầu tiên là các hoạt động mang lại lợi nhuận cao nhất cho người xác minh. Do đó, sau Electra, các người xác minh với số tiền gửi lớn sẽ tham gia vào việc đề xuất khối và hội đồng đồng bộ thường xuyên hơn, tần suất này tương ứng với số dư hiệu lực của họ.
Một yếu tố khác ảnh hưởng đến việc cắt giảm. Tất cả các khoản phạt cắt giảm tỷ lệ thuận với số dư hiệu lực của các nhà xác minh:
Electra cũng đề xuất thay đổi tỷ lệ cắt giảm, xác định một phần số dư của người xác minh bị cắt giảm và được nhận bởi người tố cáo.
Tiếp theo là ảnh hưởng về tính không hợp lệ. Khi người xác minh không hoạt động (chứng minh hoặc đề xuất) khi ngoại tuyến, điểm không hợp lệ sẽ tích luỹ, dẫn đến áp dụng hình phạt không hợp lệ cho mỗi chu kỳ. Những hình phạt này cũng tương quan với số dư hợp lệ của người xác minh theo tỷ lệ.
Do sự gia tăng số dư hiệu quả, "giới hạn thay thế" cho trình xác thực cũng đã thay đổi. Trong Ethereum "tiền 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ế thoát được định nghĩa là "không quá 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 trình xác thực "cố định" có cùng cổ phần để thoát. Tuy nhiên, sau "Electra", có thể chỉ có một vài "cá voi" sẽ thoát ra, vì chúng chiếm một phần đáng kể trong tổng số cổ phần.
Một trong những điều cần xem xét khác là việc xoay vòng nhiều khóa xác minh trên một trường hợp xác minh đơn lẻ. Hiện tại, các trường hợp xác minh lớn phải chạy hàng nghìn khóa xác minh để thích nghi với việc giao rất nhiều tiền đặt cược, chia nhỏ chúng thành phần 32 ETH. Với Electra, hành vi này không còn bắt buộc nữa. Về mặt tài chính, thay đổi này không ảnh hưởng nhiều vì phần thưởng và xác suất tỷ lệ thuận với số tiền đặt cược. Do đó, 100 khóa xác minh mỗi phần 32 ETH tương đương với một khóa xác minh 3200 ETH. Ngoài ra, nhiều khóa xác minh hoạt động có thể có cùng một chứng chỉ rút tiền Eth1, cho phép tất cả phần thưởng được rút về một địa chỉ ETH duy nhất, tránh chi phí gas liên quan đến việc hợp nhất phần thưởng. Tuy nhiên, quản lý một lượng lớn khóa có thể tạo ra chi phí quản lý bổ sung.
Khả năng cân đối của người xác minh đã được tăng cường với một loại yêu cầu thực thi mới. Trước đó, chúng ta có tiền gửi và rút tiền. Bây giờ, sẽ có một loại khác: yêu cầu tổng hợp. Nó sẽ hợp nhất hai người xác minh thành một. Yêu cầu thao tác sẽ bao gồm khóa công khai của người xác minh nguồn và đích, và sẽ được xử lý tương tự như tiền gửi và rút tiền. Yêu cầu tổng hợp cũng sẽ có giới hạn yêu cầu chờ xử lý và cân đối, giống như tiền gửi và rút tiền.
Tóm lại như sau:
Một chủ đề quan trọng khác là dữ liệu lịch sử và ước lượng lợi nhuận của người xác minh, đặc biệt quan trọng đối với những người mới tham gia, họ cố gắng đánh giá rủi ro và lợi ích. Trước Electra (tính đến thời điểm viết bài này), sự đồng đều đã được tạo ra trên dữ liệu lịch sử với giới hạn 32 ETH (dù là tối thiểu hay tối đa) . Tất cả số dư hợp lệ của người xác minh, phần thưởng, trừng phạt cắt giảm cá nhân, tần suất đề xuất khối và các chỉ số khác đều tương đồng. Sự đồng đều này giúp Ethereum có thể thử nghiệm cơ chế đồng thuận mà không cần xử lý các giá trị ngoại lệ thống kê, từ đó thu thập dữ liệu hành vi mạng có giá trị.
Sau Electra, phân phối staking sẽ trải qua những thay đổi đáng kể. Các nhà xác minh lớn sẽ tham gia thường xuyên hơn trong việc đề xuất khối và ủy ban đồng bộ, và sẽ phải đối mặt với hình phạt lớn hơn trong sự kiện cắt giảm, cũng như có ảnh hưởng lớn hơn đối với việc cắt giảm trễ, hàng đợi kích hoạt và hàng đợi rút khỏi. Mặc dù điều này có thể tạo ra thách thức trong việc tập trung dữ liệu, nhưng sự đồng thuận của Ethereum đảm bảo tính toán phi tuyến tính là tối thiểu. Chỉ có thành phần phi tuyến tính duy nhất sử dụng sqrt)total_effective_balance( để tính toán phần thưởng cơ bản, áp dụng cho tất cả các nhà xác minh. Điều này có nghĩa là phần thưởng và cắt giảm của nhà xác minh vẫn có thể được ước tính dựa trên “mỗi 1 ETH” (hoặc chính xác hơn là dựa trên spec.effective_balance_increment, điều này có thể thay đổi trong tương lai).
Để biết thêm thông tin chi tiết, vui lòng xem bài viết của chúng tôi về hành vi xác minh trước đó.
EIP-7002: Lớp thực thi có thể kích hoạt để thoát
Tham khảo: EIP-7002
Mỗi người xác minh trong Ethereum đều có hai cặp khóa: một cặp khóa hoạt động và một cặp khóa rút tiền. Khóa công khai BLS hoạt động được sử dụng như là danh tính chính của người xác minh trên chuỗi cái phong, cặp khóa này được sử dụng để ký vào các khối, chứng minh, cắt giảm, tổng hợp ủy viên đồng bộ và (trước EIP này) thoát tự nguyện (để bắt đầu quá trình rút người xác minh khỏi sự đồng thuận sau một khoảng thời gian chờ). Cặp khóa thứ hai ("chứng chỉ rút tiền") có thể là một cặp khóa BLS khác hoặc một tài khoản Eth1 thông thường (bao gồm cả khóa riêng tư và địa chỉ). Bây giờ, việc rút tiền vào địa chỉ ETH yêu cầu thông điệp rút tiền được ký bởi khóa riêng tư BLS hoạt động. EIP này đã thực hiện các thay đổi.
Trên thực tế, chủ sở hữu của hai cặp khóa (hoạt động và rút tiền) này có thể khác nhau. Khóa hoạt động của trình xác thực chịu trách nhiệm xác minh: chạy máy chủ, duy trì hoạt động, v.v., trong khi thông tin rút tiền thường được kiểm soát bởi chủ sở hữu cổ phần, người nhận phần thưởng và chịu trách nhiệm về tiền. Hiện tại, chỉ chủ sở hữu cổ phần kiểm soát thông tin rút tiền mới không thể bắt đầu rút tiền của trình xác thực và chỉ có thể rút phần thưởng. Tình huống này cho phép chủ sở hữu khóa hoạt động của trình xác thực giữ số dư của trình xác thực một cách hiệu quả với tư cách là "con tin". Người xác thực có thể "ký trước" thông báo thoát và giao nó cho chủ sở hữu cổ phần, nhưng cách giải quyết này không lý tưởng. Ngoài ra, cả trích xuất và rút tiền hiện đều yêu cầu tương tác với trình xác thực lớp đèn hiệu thông qua API chuyên dụng.
Giải pháp tốt nhất là cho phép chủ sở hữu đặt cược để thực hiện rút và rút tiền cùng một lúc thông qua cuộc 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, giúp đơn giản hóa đáng kể quy trình.
EIP này cho phép chủ sở hữu cược đặt kích hoạt việc rút tiền và rút ra thông qua việc gửi giao dịch tiêu chuẩn từ địa chỉ ETH của họ đến hợp đồng thông minh riêng biệt (tương tự 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 quy trình rút ra khi đủ điều kiện đặt cược) như sau:
Mặc dù việc gửi tiền là một hoạt động được kích hoạt trong khối Eth1 và sau đó được "di chuyển" vào tầng mốc tín hiệu thông qua hàng đợi gửi tiền "đang xử lý", nhưng việc rút tiền tuân theo một kế hoạch khác nhau. Chúng được kích hoạt trên tầng mốc tín hiệu (thông qua CLI) và sau đó được "di chuyển" vào khối Eth1. Hiện nay, hai kế hoạch sẽ hoạt động thông qua một khung chung (như mô tả dưới đây): tạo yêu cầu tại tầng Eth1, xử lý hàng đợi gửi tiền/rút tiền/gộp "đang xử lý" và xử lý tại tầng mốc tín hiệu. Đố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.
Thông qua EIP này, người thế chấp có thể rút và thoát khỏi các nhà xác minh của họ bằng giao dịch ETH thông thường mà không cần tương tác trực tiếp với CLI của nhà xác minh hoặc truy cập cơ sở hạ tầng của nhà xác minh. Điều này đáng kể đơn giản hóa quá trình thế chấp, đặc biệt đối với các nhà cung cấp thế chấp lớn. Cơ sở hạ tầng của nhà xác minh hiện nay hầu như có thể được cô lập hoàn toàn, vì chỉ cần duy trì khóa của các nhà xác minh hoạt động và tất cả quá trình thế chấp có thể được xử lý ở nơi khác. Điều này loại bỏ nhu cầu chờ đợi các hành động nhà xác minh hoạt động độc lập của các nhà thế chấp và đơn giản hóa đáng kể phần ngoại tuyến của dịch vụ Lido như Mô-đun Thế chấp Cộng đồng.
Do đó, EIP này đã "hoàn thành" quá trình giao dịch đặt cọc và hoàn toàn chuyển nó vào tầng Eth1, giảm thiểu rủi ro an ninh hạ tầng và tăng cường tính phi tập trung của đề xuất đặt cọc độc lập.
EIP-6110: Gửi khoản tiền đặt cọc cho ngườ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 sự kiện trong hợp đồng 'Tiền gửi' của hệ thống (như đã được đề cập chi tiết trong bài viết trước đó). Hợp đồng chấp nhận ETH và chứng chỉ xác thực của các nhà xác minh, phát ra sự kiện 'Deposit)(', sau đó các sự kiện này được phân tích và chuyển đổi thành yêu cầu tiền gửi trên tầng beacon. Hệ thống này có nhiều điểm hạn chế: nó yêu cầu bỏ phiếu cho eth1data trên tầng beacon, điều này làm tăng đáng kể độ trễ. Ngoài ra, tầng beacon cần truy vấn tầng 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 xử lý nhiều vấn đề này, là đưa yêu cầu tiền gửi trực tiếp vào khối Eth1 tại vị trí được chỉ định. Cơ chế này tương tự như quy trình rút tiền được mô tả trong EIP trước đó.
Những thay đổi được đề xuất trong EIP này rất triển vọng. Xử lý eth1data hiện nay có thể hoàn toàn loại bỏ, không cần phải bỏ phiếu hoặc trì hoãn trong thời gian dài giữa các gói tiền gửi trên Eth1 và lớp hiệu lực (được ước lượng khoảng 12 giờ). Nó cũng loại bỏ logic của bản chụp hợp đồng gửi tiền. EIP này đơn giản hóa việc xử lý tiền gửi và làm cho nó phù hợp với giải pháp xử lý tiền rút được đề cập ở trên.
Đối với người đặt cọc và người xác minh, những thay đổi này giảm thiểu đáng kể sự trì hoãn giữa tiền gửi và việc kích hoạ xác minh. Khi xác minh bị cắt giảm, việc bổ sung cũng sẽ nhanh hơn.
Về EIP này không có gì để nói thêm, 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ả các bên liên quan.
EIP-7685: Yêu cầu Tầng Thực thi Chung
Tham khảo: EIP-7685
EIP này nên được đề xuất trước ba EIP liên quan đến tiền gửi/rút tiền/gộp vốn, vì nó tạo nền tảng cho những EIP này. Tuy nhiên, việc giới thiệu ở đây nhằm nhấn mạnh nhu cầu ngày càng tăng về việc di chuyển dữ liệu đặc biệt giữa các khối (lớp) của Eth1 (thực thi) và beacon (đồng thuận). EIP này ảnh hưởng đến hai lớp, làm cho xử lý yêu cầu được kích hoạt bằng giao dịch ETH thông thường trở nên hiệu quả hơn. Hiện tại, chúng ta quan sát được rằng:
Ba thao tác này cho thấy sự cần thiết của việc xử lý thống nhất các loại yêu cầu khi chuyển đổi giữa tầng thực thi và tầng biểu tượng. Ngoài ra, chúng ta cần có khả năng chỉ sử dụng tầng Eth1 để kích hoạt các thao tác này, vì điều này sẽ giúp chúng ta cô lập cơ sở hạ tầng của các nhà xác minh khỏi cơ sở hạ tầng quản lý thế chấp, từ đó nâng cao tính bảo mật. Do đó, một giải pháp chung để quản lý các yêu cầu của loại này là cần thiết và thực tế.
EIP này thiết lập khung cho ít nhất ba trường hợp chính: gửi tiền, rút tiền và sáp nhập. Đó là lý do tại sao EIP ban đầu đã giới thiệu các trường như WITHDRAWAL_REQUEST_TYPE và DEPOSIT_REQUEST_TYPE, bây giờ sáp nhậ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ý các giới hạn liên quan đến các yêu cầu này (xem hằng số: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Mặc dù chi tiết cụ thể về việc triển khai của khung này vẫn chưa có sẵn, nhưng nó chắc chắn sẽ bao gồm các loại yêu cầu quan trọng, cơ chế tích hợp (ví dụ như yêu cầu băm và Merkle), cùng với hàng đợi xử lý và giới hạn tốc độ.
EIP này có ý nghĩa kiến trúc, cho phép Eth1 kích hoạt các hoạt động quan trọng trong lớp dấu hiệu thông qua một khung chung. Đối với người dùng cuối và dự án, điều này có nghĩa là tất cả các yêu cầu được kích hoạt ở tầng Eth1 sẽ được truyền và xử lý hiệu quả hơn trên tầng dấu hiệu.
EIP-2537：Sự chuẩn bị trước cho việc thao tác đường cong BLS12-381
Tham khảo: EIP-2537
Nếu bạn không muốn hiểu sâu, bạn có thể xem trước BLS12-381 như một loại phép toán băm mã hóa phức tạp, hiện đã có thể sử dụng trong hợp đồng thông minh. Đối với những người quan tâm, hãy cùng chúng tôi tìm hiểu sâu hơn.
Các phép toán toán học trên đường cong elliptic như BLS12-381 (và tương ứng BN-254) hiện đang chủ yếu được sử dụng cho hai mục đích:
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, rất tốn kém về mặt tính toán. Ethereum đã có một hợp đồng được biên dịch sẵn (EIP-196 và EIP-197) cho các hoạt động đường cong BN254. 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 hiện nay) vẫn chưa được thực hiện như đã được biên dịch sẵn. Trong trường hợp không có sự biên dịch trước như vậy, việc thực hiện ghép nối và các hoạt động đường cong khác trong hợp đồng thông minh đòi hỏi rất nhiều tính toán, như được hiển thị ở đây và tiêu thụ một lượng khí 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à trong việc xác minh chữ ký BLS rẻ tiền dựa trên đường cong BLS12-381. Điều này làm cho việc thực hiện các giải pháp ngưỡng về mục đích trở nên có thể. Như đã đề cập trước đó, người xác minh Ethereum đã sử dụng chữ ký dựa trên BLS12-381. Thông qua 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ý của người xác minh được tổng hợp. Điều này có thể đơn giản hóa chứng minh đồng thuận và cầu nối tài sản qua mạng lưới, vì chữ ký BLS được sử dụng rộng rãi trong blockchain. Chính chữ ký BLS ngưỡng cho phép xây dựng nhiều giải pháp ngưỡng hiệu quả để sử dụng 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 chứng minh zkSNARK rẻ hơn sẽ mở khóa nhiều ứng dụng. Hiện nay, nhiều giải pháp dựa trên zkSNARK đều bị rào cản bởi chi phí xác minh chứng minh cao, điều này làm cho 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 lịch sử khối hash trong trạng thái
Tham khảo: EIP-2935
Đề xuất EIP này lưu trữ 8192 bản ghi lịch sử khối (khoảng 27.3 giờ) trong trạng thái blockchain, để mở rộng lịch sử cho khách hàng không 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 mã hoạt động BLOCKHASH, giữ nguyên 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ế đặc biệt để lưu trữ và truy xuất các bản ghi lịch sử. Hợp đồng này thực hiện thao tác set)( khi xử lý khối ở tầng thực thi. Phương thức get)( của nó có sẵn cho bất kỳ ai truy cập, để truy xuất các bản ghi lịch sử khối cần thiết từ bộ đệm vòng.
Hiện tại, việc tham chiếu mã hash khối lịch sử trong EVM là khả thi, nhưng truy cập chỉ giới hạn trong 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ũ là rất quan trọng, đặc biệt là đối với ứng dụng giao mạng (cần chứng minh dữ liệu các khối trước đó) và khách hàng không trạng thái, chúng thường cần truy cập mã hash khối cũ định kỳ.
EIP này mở rộng phạm vi thời gian mà rollup và ứng dụng đa chuỗi có thể sử dụng, cho phép chúng truy cập trực tiếp vào dữ liệu lịch sử trong EVM mà không cần phải thu thập từ bên ngoài. Do đó, những giải pháp này trở nên mạnh mẽ và bền vững hơn.
EIP-7623: Tăng chi phí calldata
Tham khảo: EIP-7623
calldata điều chỉnh kích thước tải trọng hiệu quả của giao dịch và trong một số trường hợp có thể rất lớn (ví dụ, khi truyền một mảng lớn hoặc bộ đệm nhị phân như một tham số). Việc sử dụng đáng kể của calldata chủ yếu được đưa ra cho rollup, chúng gửi tải trọng hiệu quả bằng cách chứa calldata trạng thái rollup hiện tại.
Việc đưa dữ liệu nhị phân lớn và có thể chứng minh vào chuỗi khối là rất quan trọng đối với rollup. Việc nâng cấp Dencun (Deneb-Cancun) cho các trường hợp sử dụng này đã đem lại một sáng tạo quan trọng - giao dịch blob (EIP-4844). Giao dịch blob có chi phí gas "blob" riêng của nó, mặc dù nó là tạm thời lưu trữ, nhưng chứng minh mật mã của nó (cam kết KZG) cùng với băm của nó đã được tích hợp vào lớp đồng thuận. Do đó, so với việc sử dụng calldata để lưu trữ dữ liệu, blob cung cấp một giải pháp tốt hơn cho rollup.
Để khuyến khích rollup chuyển dữ liệu của nó thành blob, có thể đạt được bằng cách "cà rốt và gậy củ cải". Phí gas của blob đã giảm được coi là "cà rốt", trong khi EIP này tăng chi phí calldata làm "gậy", nhằm kiềm chế việc lưu trữ dữ liệu quá mức trong giao dịch. EIP này bổ sung EIP-7691 tiếp theo (Tăng cường lưu lượng blob), EIP-7691 nâng cao số lượng blob tối đa cho mỗi khối.
EIP-7691：Tăng tốc độ xử lý blob
Tham khảo: EIP-7691
Trong cuộc chia cắt cứng trước đó của Dencun, blob đã được giới thiệu, và giá trị ban đầu của blob "mỗi khối" tối đa và mục tiêu là một ước lượng thận trọng. Điều này là do sự 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 như thế nào khi chúng lan truyền giữa các nút xác minh. Cấu hình trước đó đã được chứng minh là tốt, điều này làm cho việc kiểm tra giá trị mới là thời điểm thích hợp. Trước đó, mục tiêu/số lượng blob tối đa cho mỗi khối đã được đặt là 3/6. Các hạn chế này hiện đã được tăng lên thành 6/9 tương ứng.
Kết hợp với EIP-7623 trước đó (tăng chi phí calldata), điều chỉnh này tiếp tục thúc đẩy rollup chuyển dữ liệu của nó từ calldata sang các blobs. Công việc tìm kiếm tham số blob tốt nhất vẫn đang được tiếp tục.
EIP-7840: Thêm lịch trình blob vào tệp cấu hình EL
Tham khảo: EIP-7840
Đề xuất EIP này thêm mục tiêu và số lượng blob tối đa '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. Chức năng này đặc biệt hữu ích trong việc ướ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 thuộc sở hữu bên ngoài) không thể có bất kỳ mã nào, nhưng có thể cung cấp chữ ký giao dịch (tx.origin). Ngược lại, một hợp đồng thông minh có bytecode, nhưng không thể chủ động đề xuất chữ ký trực tiếp của "nó". Bất kỳ tương tác người dùng nào yêu cầu logic bổ sung, tự động và có thể xác minh hiện chỉ có thể thực hiện hành động mong muốn bằng cách gọi hợp đồng bên ngoài. Tuy nhiên, trong trường hợp này, hợp đồng bên ngoài trở thành người gửi msg.sender của hợp đồng tiếp theo, thực hiện cuộc gọi "từ hợp đồng, không phải người dùng".
EIP này giới thiệu loại giao dịch SET \ _CODE \ _TX \ _TYPE = 0x04 mới (chúng tôi đã có giao dịch 0x1 cũ trước đó, giao dịch 0x02 mới từ Berlin và nâng cấp EIP-1559 và giao dịch blob 0x03 được giới thiệu ở Dencun). Loại giao dịch mới này cho phép bạn 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ó". Từ góc độ bên ngoài, EOA dường như "mượn" mã từ một hợp đồng bên ngoài và thực hiện nó trong một giao dịch. 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 kho lưu trữ "mã" của địa chỉ EOA (cho đến EIP này, kho lưu trữ "mã" này luôn trống cho EOA).
Hiện tại, kiểu giao dịch mới 0x04 trong đề xuất EIP này bao gồm một mảng:
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Mỗi yếu 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 loại này, mã của EOA cụ thể được thiết lập 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ị cho việc kết nối, 0xef0100 biểu thị giá trị ma thuật đặc biệt mà hợp đồng thông thường thông thường không thể chứa (theo EIP-3541). Giá trị ma thuật này đảm bảo rằng EOA này không thể được coi là hợp đồng thông thường, cũng không thể được gọi như một hợp đồng thông thường.
Khi EOA này thực hiện giao dịch, địa chỉ được chỉ định sẽ được sử dụng để gọi mã tương ứng trong ngữ cảnh của EOA đó. Mặc dù chi tiết triển khai đầy đủ của EIP này vẫn chưa rõ ràng, nhưng có thể xác định rằng nó sẽ mang lại những thay đổi đáng kể.
Một tác động chính là khả năng thực hiện cuộc gọi đa lớp trực tiếp từ EOA (multicall). Cuộc gọi đa lớp là một xu hướng tiếp 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ụ như Uniswap V4, Balancer V3 hoặc Euler V2). Với EIP này, bây giờ có thể khởi động cuộc gọi đa lớp 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)( yêu cầu hai giao dịch riêng biệt. EIP này cho phép logic "ủy quyền trước" phổ biến cho phép những việc như approve)X( + deposit)X( được thực hiện trong một giao dịch.
Một lợi thế khác của việc « đại diện » cho giao dịch được ủy quyền bởi 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à đặc biệt khao khát, để giúp người dùng mới tiếp cận Ethereum.
Kết hợp với EOA, logic có thể lập trình đã mở ra nhiều khả năng, chẳng hạn như thiết lập các ràng buộc bảo mật, đặt giới hạn chi tiêu, yêu cầu KYC bắt buộc, v.v.
Tất nhiên, sự thay đổi này cũng đặt ra một số câu hỏi 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 bao gồm trong chữ ký hay không. Một phức tạp khác là sự lựa chọn giữa việc sử dụng địa chỉ của mã đối tượng và nhúng bytecode thực tế. Cả hai phương pháp đều có những tính năng và hạn chế độc đáo riêng. Ngoài ra, việc sử dụng nonce đóng một vai trò quan trọng trong việc xác định xem quyền là "đa mục đích" hay "đơn mục đích". Các yếu tố này ảnh hưở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ư chữ ký vô hiệu hóa hàng loạt 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 (ở đây) đáng để khám phá thêm.
Điều đáng chú ý là sự thay đổi này sẽ ảnh hưởng đến một trong những cơ chế bảo mật của Ethereum, tx.origin. Thông tin chi tiết hơn về việc triển khai EIP này là cần thiết, nhưng có vẻ như hành vi của require)tx.origin == msg.sender( sẽ thay đổi. Kiểm tra này là cách chắc chắn nhất để đảm bảo rằng msg.sender là EOA chứ không phải hợp đồng. CÁC 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 THẤT BẠI VÀ CÓ THỂ BỊ PHÁ VỠ (VÍ DỤ: BẰNG CÁCH GỌI HÀM TẠO HOẶC BẰNG CÁCH TRIỂN KHAI MÃ TẠI MỘT ĐỊA CHỈ ĐƯỢC XÁC ĐỊNH TRƯỚC SAU KHI 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 tái xâm nhập và cho vay flash, nhưng không lý tưởng vì chúng cũng cản trở sự tích hợp với các giao thức bên ngoài. Ngay cả yêu cầu đáng tin cậy)tx.origin == msg.sender( kiểm tra dường như trở nên lỗi thời sau EIP này. Giao thức phải đáp ứ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" sẽ không còn áp dụng nữa - bây giờ mọi địa chỉ đều có thể có mã được liên kết với nó.
Sự phân tách giữa EOA truyền thống và hợp đồng thông minh tiếp tục mờ nhạt. EIP này khiến Ethereum gần hơn với thiết kế như TON, trong đó mỗi tài khoản về cơ bản đều là mã có thể thực thi. Khi tương tác với giao thức trở nên phức tạp hơn, việc sử dụng logic có thể lập trình để cải thiện trải nghiệm người dùng cuối cùng là quá trình tự nhiên của sự tiến hóa này.
Kết luận
Budapest / Electra (Pectra) được nâng cấp vào tháng 3 năm 2025. Các thay đổi kế hoạch đáng chú ý nhất bao gồm:
Như bạn có thể thấy, Pectra sẽ có tác động đáng kể đến trải nghiệm người dùng cuối của các lớp đặt cọc và đồ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 diễn ra, chúng tôi sẽ đề cập đến các bản cập nhật này trong một bài viết trong tương lai.