Dự kiến chia rẽ cứng của Pectra sẽ bắt đầu triển khai mạng chính vào tháng 3 năm 2025. Bản nâng cấp của Pectra bao gồm 11 giao thức kỹ thuật (EIP), bao gồm:
EIP-2537: BLS12-381 Curve Operation Precompile
EIP-2935: Lưu giá trị băm khối lịch sử trong State
EIP-6110: Cung cấp tiền gửi của người xác minh trên chuỗi
EIP-7002: Lớp thực thi kích hoạt việc thoát
EIP-7251: Tăng the MAX_EFFECTIVE_BALANCE
EIP-7549: Di chuyển chỉ số ủy ban ra khỏi quá trình xác thực
EIP-7623: Tăng chi phí calldata
EIP-7685: Yêu cầu lớp thực thi chung
EIP-7691: Tăng lượng lưu lượng Blob
EIP-7702: Thiết lập mã tài khoản EOA
EIP-7840: Thêm kế hoạch Blob vào tệp cấu hình EL
Các giao thức công nghệ liên quan đến thế chấp
EIP-6110: BLS12-381 Curve Operation Precompile
Đơn giản hóa quy trình tham gia cầm cố cho người dùng, giảm thiểu thời gian chờ đợi một cách đáng kể.
Cách mà người dùng tham gia cam kết là gửi 32 ETH vào tầng thực thi và được ghi lại trong Nhật ký Sự kiện, sau đó tầng đồng thuận thực thi sẽ phân tích Nhật ký Sự kiện để xác định liệu có ai tham gia cam kết hay không, sau đó người dùng tham gia cam kết sẽ trở thành người xác minh.
Tuy nhiên, người xác minh tầng đồng thuận đầu tiên cần xác định thời điểm nào để thực hiện đồng thuận, nếu không, một số người xác minh sẽ thấy 5 khoản tiền mới được gửi, trong khi một số người xác minh chỉ thấy 3 khoản tiền, do đó những người xác minh tầng đồng thuận sẽ bỏ phiếu cho khối tầng thực hiện nào để tham khảo (eth1data), đảm bảo rằng tất cả mọi người đều nhìn thấy cùng một khối tầng thực hiện.
Tuy nhiên, ban đầu trong quá trình thiết kế để tránh sự cố lớn xảy ra tại lớp thực thi dẫn đến phân nhánh chuỗi, do đó khối dữ liệu thực thi tham khảo (eth1data) sẽ là một khối thực thi khoảng 10 giờ trước, đảm bảo rằng khi xảy ra sự cố lớn, các nhà phát triển tầng đồng thuận có đủ thời gian phản ứng và xử lý, tuy nhiên điều này cũng dẫn đến việc tham gia cầm cố cũng phải đợi ít nhất 10 giờ mới có hiệu lực.
!
△ Dữ liệu eth1data trong khối CL là 10900000, Hash khối được ghi trong đó là 21683339, xuất hiện 10 giờ trước khối tầng thực thi.
Sau khi giao thức kỹ thuật EIP-6110 được thực thi, dữ liệu cam kết của người dùng trên hợp đồng sẽ trực tiếp trở thành một phần của lớp thực thi và vì bản thân khối lớp đồng thuận sẽ chứa khối lớp thực thi (nhưng không phải eth1data), người xác thực lớp đồng thuận không còn cần phải xem xét vấn đề "xác nhận rằng khối bộ nhớ lớp thực thi tham chiếu là như nhau", miễn là khối bộ nhớ lớp đồng thuận được hơn hai phần ba số người xác thực bình chọn, mọi người sẽ đạt được sự đồng thuận trên cùng một khối lớp thực thi. Do đó, sau khi tham gia cam kết, người dùng có thể đợi khối bộ nhớ lớp thực thi hoàn tất quá trình xử lý sớm nhất trong khoảng 13 phút và máy khách lớp đồng thuận cũng có thể loại bỏ logic phức tạp ban đầu được sử dụng để xử lý dữ liệu đặt cọc.
EIP-7002: Lưu trữ giá trị băm khối lịch sử trong State
Có thể được sử dụng để cải thiện quy trình rút tiền và lợi nhuận cho người xác minh hoặc rút tiền gửi tiền, giảm thiểu rủi ro cho người xác minh.
Để tham gia staking, bạn cần có hai khóa, đó là Validator Key và Withdrawal Credential.
Validator Key được sử dụng để xác minh nội dung của người xác minh, và Credential Rút Tiền được sử dụng để địa chỉ mà tiền đặt cọc và lợi nhuận sẽ được rút ra khi người xác minh rút tiền cọc. Ngoài ra, hiện nay, việc rút tiền cọc phải được thực hiện bằng cách sử dụng Validator Key.
Nếu mất Validator Key, bạn sẽ không thể thực hiện công việc của người xác minh và không thể rút tiền gửi; nếu mất Withdrawal Credential, bạn sẽ mất tất cả tiền đặt cược và lợi nhuận. Ngoài ra, một số người dùng có thể sử dụng dịch vụ đặt cược bên thứ ba như Lido, khi sử dụng các nền tảng này, người dùng cần tự giữ Withdrawal Credential, trong khi Validator Key sẽ được nhà cung cấp dịch vụ quản lý và thực hiện công việc của người xác minh thay mặt.
Bằng cách thực hiện giao thức kỹ thuật EIP-7002, người dùng có thể sử dụng thông tin Xác nhận Rút tiền để gọi hợp đồng "Rút" (được triển khai tại 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) để rút cọc (Rút) hoặc rút tiền đặt cược và thu nhập (Rút một phần), từ đó giảm thiểu rủi ro liên quan đến việc sử dụng dịch vụ cọc của bên thứ ba. Nếu người dùng tham gia cọc một cách tự do nhưng mất Khóa Xác nhận, họ cũng có thể rút cọc thông qua cách thức này.
Tham số yêu cầu bao gồm validator_pubkey và số lượng: validator_pubkey là Validator (Public) Key của người xác thực, amount là số lượng cần rút.
Yêu cầu Credential Rút tiền phải là Credential Rút tiền của validator_pubkey xác minh.
Khi gọi hợp đồng Rút tiền để khởi tạo yêu cầu, bạn cần đính kèm phí Gas (ETH), phí Gas sẽ được tính dựa trên số lượng yêu cầu rút hiện tại, nếu số lượng yêu cầu lớn, phí Gas sẽ tăng lên.
Nếu Credential Rút tiền của người dùng là một hợp đồng, họ có thể truy cập hợp đồng Rút tiền để lấy số tiền phí hiện tại, sau đó thực hiện yêu cầu và đính kèm phí; nhưng nếu Credential Rút tiền là một tài khoản EOA, họ sẽ không thể lấy được phí chính xác, chỉ có thể mô phỏng trước chuỗi và trả phí thừa (không hoàn lại) để đảm bảo yêu cầu được thực hiện thành công.
Lưu ý: Nếu thông tin Xác thực Rút tiền của bạn vẫn ở định dạng Khóa công khai BLS, hãy nhớ chuyển đổi trước, đổi nó thành định dạng Địa chỉ EL.
EIP-7251: Thêm vào MAX_EFFECTIVE_BALANCE
Có thể tăng đáng kể giới hạn tiền gửi để giảm số lượng người xác minh, và người xác minh chưa đạt đến giới hạn có thể tự động hưởng lợi từ lợi nhuận tiền gửi.
Người dùng đặt cược để trở thành người xác minh cần cung cấp số lượng ETH của MAX_EFFECTIVE_BALANCE, không ít hơn cũng không nhiều hơn (hiện tại MAX_EFFECTIVE_BALANCE là 32 ETH). Nếu người dùng giữ 1024 ETH để đặt cược, họ có thể tham gia cược 32 lần, kích hoạt 32 người xác minh, và chạy 32 nút xác minh. Sự tích cực tham gia cược của mọi người đã dẫn đến khoảng 1 triệu người xác minh hiện tại và tiếp tục tăng lên, điều này không chỉ làm cho dữ liệu trạng thái tầng đồng thuận trở nên lớn hơn và phức tạp hơn, mà còn tăng tải cho tầng mạng p2p của tầng đồng thuận, vì mỗi Slot (mỗi 12 giây) đều có hàng chục ngàn chữ ký của người xác minh cần được truyền đi và tổng hợp liên tục trong tầng mạng p2p.
Sau khi thực hiện giao thức EIP-7251, giới hạn đặt cược tối thiểu (MIN_ACTIVATION_BALANCE) vẫn là 32 ETH, nhưng giới hạn tối đa (MAX_EFFECTIVE_BALANCE) sẽ được tăng đáng kể lên 2048 ETH, bạn có thể đặt cược bất kỳ số lượng ETH nào từ 32 đến 2048, có thể nhận được lợi nhuận từ việc đặt cược mà không cần rút lợi nhuận định kỳ, tích lũy 32 ETH sau đó tiếp tục đặt cược mới.
Hiện tại, các validator hiện tại không cần rút khỏi staking trước, sau đó hợp nhất và tham gia lại staking với nhau, mà có thể trực tiếp sử dụng "hợp đồng hợp nhất tiền gửi" mới (được triển khai trong 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) trên lớp thực hiện và Crendential rút tiền của validator sẽ gọi hợp đồng để bắt đầu yêu cầu hợp nhất tiền gửi.
Các tham số của yêu cầu ký quỹ hợp nhất bao gồm nguồn_pubkey và target_pubkey: cả hai khóa đều là khóa xác thực của trình xác thực và trình xác thực nguồn sẽ được hợp nhất vào trình xác thực đích.
Thông tin xác thực rút tiền khởi tạo yêu cầu phải là Thông tin rút tiền của trình xác minh nguồn.
Khi gửi yêu cầu kích hoạt hợp đồng tiền gửi hợp nhất, bạn cần phải đính kèm phí giao dịch (ETH), phí giao dịch sẽ được tính dựa trên số lượng yêu cầu hiện tại, nếu có nhiều yêu cầu, phí giao dịch sẽ tăng lên.
Nếu Credential Rút tiền của người dùng là một hợp đồng, người có thể gọi hợp đồng gửi tiền trước để nhận số tiền phí hiện tại, sau đó mới gửi yêu cầu và đính kèm phí; nhưng nếu Credential Rút tiền là một tài khoản EOA, không thể nhận được số tiền phí chính xác, chỉ có thể mô phỏng chuỗi trước và trả phí thừa (không hoàn trả), đảm bảo yêu cầu được thực hiện thành công.
Lưu ý: Nếu Thông tin rút tiền của bạn ở định dạng khóa công khai BLS, trước tiên bạn cần chuyển nó sang định dạng địa chỉ EL.
EIP-7685: Yêu cầu Tầng Thực thi Phổ quát
Thiết lập một kênh thông tin chính thức từ EL sang CL, giúp người dùng và dịch vụ đặt cược có thể gửi yêu cầu trực tiếp đến tầng đồng thuận.
Người dùng có thể gửi yêu cầu trực tiếp từ tầng thực thi đến tầng đồng thuận, dịch vụ đặt cọc (ví dụ như Lido) có thể hoạt động theo cách phi trung tâm hơn. Ví dụ như yêu cầu rút cọc theo EIP-7002 đã đề cập trước đó và yêu cầu gộp tiền đặt cọc theo EIP-7251. Nếu không có giao thức công nghệ này, người dùng của Lido sẽ phải tin tưởng rằng nhà cung cấp dịch vụ nút Lido sẽ thực hiện việc rút cọc hoặc gộp tiền đặt cọc một cách trung thực tại tầng đồng thuận; nhờ có giao thức công nghệ này, người dùng của Lido có thể trực tiếp gửi yêu cầu thông qua hợp đồng quản trị trên tầng thực thi.
Các yêu cầu này sẽ được phân biệt bằng Loại Yêu Cầu để phân biệt các loại yêu cầu khác nhau, cũng như thông qua các hợp đồng khác nhau để khởi động yêu cầu, cuối cùng các yêu cầu này sẽ được ghi vào khối bộ nhớ của tầng thực thi, do đó tầng đồng thuận có thể trực tiếp lấy thông tin này thông qua các khối bộ nhớ của tầng thực thi, không cần phải viết logic phân tích riêng lẻ nữa.
EIP-6110, EIP-7002 và EIP-7251 đều dựa trên các tiêu chí được xác định bởi EIP-7685:
Yêu cầu tham gia đặt cọc: Loại yêu cầu=0, thông qua hợp đồng Deposit
Công nghệ hợp đồng để cải thiện trải nghiệm người dùng
EIP-7702: Thiết lập mã tài khoản EOA
Cho phép tài khoản EOA biến hình thành tài khoản hợp đồng mới khi cần thiết, tăng trợi nghiệm sử dụng đến mục độ lớn.
Có một số thiếu sót trong việc sử dụng tài khoản EOA, bao gồm:
Cần ghi lại và giữ khóa riêng hoặc cụm từ ghi nhớ, và ngưỡng đăng ký người dùng mới cao.
Tài khoản EOA chỉ có thể thực hiện một thao tác cho mỗi giao dịch, ví dụ: nếu bạn muốn truy cập Uniswap để đổi USDT lấy ETH, trước tiên bạn phải bắt đầu giao dịch để phê duyệt USDT, sau đó bạn có thể gửi một giao dịch khác để thực hiện trao đổi.
Quản lý quyền hạn không thể chi tiết hóa, như việc giao việc quản lý tài khoản cho bên thứ ba thực hiện, người dùng phải tự xử lý mọi vấn đề và mỗi thao tác đều phải ký tên và thực hiện giao dịch một lần.
Không có cơ chế phục hồi, chỉ có thể tự bảo quản cẩn thận khóa riêng tư hoặc từ khóa ghi nhớ, nếu bị mất thì không thể lấy lại tài sản trong tài khoản nữa.
Nếu là một tài khoản hợp đồng thông minh (ví dụ Safe), thì tất cả các vấn đề trên đều có thể được giải quyết:
Người dùng có thể sử dụng khóa riêng tư trong chip an toàn của điện thoại (hoặc máy tính) để ký và ủy quyền, không cần nhớ bất kỳ khóa riêng tư hoặc từ khóa nào, hoặc có thể sử dụng Email để ký và ủy quyền, hoặc các cách khác nhau khác để ủy quyền.
Nhiều hoạt động có thể được kết hợp với nhau trong cùng một giao dịch và các hoạt động DApp phức tạp ban đầu có thể được hoàn thành chỉ với một ủy quyền chữ ký và một giao dịch.
Có thể kiểm soát quyền hạn rất tinh vi, người dùng có thể ủy quyền cho bên thứ ba để kiểm soát tài khoản của mình, nhưng đồng thời chỉ định "có thể tương tác với hợp đồng nào" "không thể thực hiện thao tác nào", "liên quan đến việc chuyển nhượng tài sản tối đa chỉ có thể sử dụng bao nhiêu tài sản" hoặc "mỗi tuần tối đa không thể thực hiện quá bao nhiêu lần thao tác" và cả những hạn chế khác.
Bạn có thể thêm cơ chế khôi phục và bạn cũng có thể chuyển tài sản của tài khoản sang tài khoản mới thông qua cơ chế khôi phục khi bạn mất cụm từ ghi nhớ hoặc điện thoại di động hoặc email.
Đề xuất EIP-7702 cung cấp cho các tài khoản EOA khả năng trở thành tài khoản hợp đồng. Người dùng ký tin nhắn đã chuyển đổi bằng khóa riêng EOA, bao gồm "ID chuỗi", "Địa chỉ hợp đồng đã thay đổi" và "Giá trị Nonce EOA":
Chain ID: được sử dụng để ngăn chặn việc chữ ký của chuỗi A bị tái phát trên chuỗi B. Tuy nhiên, nếu Chain ID được điền là 0, điều đó có nghĩa là sẵn lòng biến đổi trên mỗi chuỗi.
Địa chỉ hợp đồng bạn muốn trở thành: Nếu bạn điền địa chỉ hợp đồng An toàn, tài khoản EOA của bạn sẽ trở thành hợp đồng An toàn; Nếu bạn điền địa chỉ trống (địa chỉ (0)), điều đó có nghĩa là bạn muốn hủy thay đổi và quay lại tài khoản EOA thuần túy.
Giá trị Nonce của EOA: Được sử dụng để ngăn chặn việc ký bản sao. Nếu giá trị Nonce tăng lên, chữ ký ban đầu sẽ trở nên không còn hiệu lực.
Tuy nhiên, có vài điểm cần chú ý:
Chìa khóa riêng của EOA vẫn có thể tiếp tục sử dụng
Ngay cả khi tài khoản EOA của người dùng trở thành hợp đồng, anh ta vẫn có thể tiếp tục sử dụng nó theo cách tương tự như tài khoản EOA ban đầu. Ví dụ: nếu tài khoản EOA của bạn trở thành Hợp đồng an toàn, bạn có thể sử dụng giao diện An toàn, thực hiện quy trình Giao dịch an toàn hoặc tiếp tục ký và gửi giao dịch bằng ví EOA ban đầu. Tuy nhiên, điều này cũng đồng nghĩa với việc tính bảo mật của tài khoản vẫn bị giới hạn ở khóa riêng.
Nó vẫn là bảo mật của khóa riêng EOA
Ngay cả khi EOA của người dùng trở thành MultiSig, miễn là anh ta không mất khóa riêng EOA, bảo mật tài khoản của anh ta sẽ luôn là bảo mật của khóa riêng EOA: anh ta vẫn phải giữ khóa riêng hoặc cụm từ ghi nhớ của mình an toàn và tài khoản của anh ta sẽ không trở nên an toàn như MultiSig.
Bộ nhớ của tài khoản EOA không được định dạng
Khi một tài khoản EOA biến thành hợp đồng và ghi dữ liệu vào Bộ nhớ của nó, trừ khi có hành động xóa dữ liệu cụ thể, dữ liệu được ghi vào Bộ nhớ không được định dạng lại do tài khoản EOA biến thành hợp đồng khác hoặc hủy bỏ việc biến đổi, vì vậy nhà phát triển cần chú ý rằng Bộ nhớ không đọc được dữ liệu cũ do hợp đồng trước đó đã để lại, có thể tham khảo ERC-7201.
Quy trình của EIP-7702 không bao gồm khởi tạo
Nói chung, tài khoản hợp đồng sẽ cần một bước khởi tạo để ghi đồng bộ thông tin của chủ sở hữu tài khoản (chẳng hạn như khóa công khai hoặc địa chỉ) khi tài khoản được triển khai, để tránh mất quyền sở hữu tài khoản do frontrun của bước triển khai. Điều này thường được thực hiện bởi hợp đồng nhà máy triển khai tài khoản hợp đồng để thực hiện "triển khai + khởi tạo", nhưng vì EIP-7702 là một thay đổi trực tiếp, chứ không phải là một nhà máy triển khai hợp đồng lên EOA, kẻ tấn công có thể sao chép chữ ký chuyển đổi của người dùng và gửi trước giao dịch đến chuỗi để chuyển đổi cho người dùng nhưng khởi tạo tài khoản để kẻ tấn công có thể kiểm soát được, vì vậy các nhà phát triển cần chú ý đến EIP-7702. Một phương pháp bảo vệ có thể là kiểm tra chữ ký của tài khoản EOA trong chức năng khởi tạo, để ngay cả khi nó được ưu tiên, kẻ tấn công sẽ không thể tạo chữ ký của tài khoản EOA để hoàn tất quá trình khởi tạo.
Yêu cầu thay đổi người gác cổng ví
Ví cần làm tốt công việc kiểm tra người dùng, đồng thời dừng yêu cầu và cảnh báo người dùng khi website DApp độc hại yêu cầu người dùng ký giao dịch chuyển đổi, nếu không nếu người dùng ký giao dịch chuyển đổi độc hại, tài sản sẽ được chuyển đi ngay lập tức. Dưới đây là một số ví dụ về cách chuyển đổi thành hợp đồng:
Modified Safe Ithaca Account
Tài khoản Ithaca
** Giao thức kỹ thuật DApp **
**EIP-2537: Trình biên dịch trước hoạt động đường cong BLS12-381 **
Giảm chi phí và làm cho nó khả thi hơn đối với các ứng dụng bằng chứng không có kiến thức dựa trên đường cong BLS.
EIP-2537 bổ sung một số hợp đồng biên dịch trước mới để cung cấp các hoạt động đường cong BLS rẻ tiền, giúp việc phát triển các ứng dụng chứng minh không có kiến thức dựa trên đường cong BLS trở nên khả thi hơn.
EIP-2935: Lưu giữ giá trị Hash khối lịch sử trong State
Nó cho phép các nhà phát triển hoặc các nút đọc hàm băm khối của các khối bộ nhớ trong quá khứ trực tiếp từ việc lưu trữ hợp đồng hệ thống.
Nếu nhà phát triển cần chứng minh nội dung của một khối nhớ trước đó, ví dụ trong thách thức gian lận của Optimismtic Rollup, để chứng minh rằng có 1000 khối nhớ trước đó tồn tại một giao dịch nào đó, thì người thách thức không thể nói trực tiếp.
"Tin tôi đi, 1000 khối bộ nhớ thực sự tồn tại trước đây", anh ta phải đưa ra bằng chứng, nhưng không có bằng chứng trực tiếp để chứng minh rằng "1000 khối bộ nhớ trước đó chứa những nội dung này", vì vậy anh ta phải chứng minh giao dịch trong một "chuỗi" khối bộ nhớ, từng khối một, cho đến khi nó đạt đến 1000 khối trước đó, và sau đó chứng minh rằng giao dịch tồn tại trong khối.
!
Mỗi khối sẽ trỏ đến một khối cha, vì vậy có thể chứng minh bất kỳ khối nào trong lịch sử.
Giả sử nó hiện là một khối bộ nhớ có số 10000 và thử thách gian lận muốn cung cấp bằng chứng rằng khối bộ nhớ có số 9000 có giao dịch X, người thách thức cần bắt đầu với hàm băm của khối bộ nhớ 10000, trước tiên chứng minh hàm băm của khối bộ nhớ mẹ 9999 được kết nối với khối bộ nhớ 10000, sau đó chứng minh khối bộ nhớ 9998... Cho đến khối bộ nhớ 9000, nội dung của khối bộ nhớ 9000 được đề xuất để chứa giao dịch X.
Sau EIP-2935, sẽ có một hợp đồng hệ thống (được triển khai trên 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) sẽ lưu trữ các hàm băm của tối đa 8192 khối bộ nhớ trước đó. Mỗi khi một khối bộ nhớ mới được tạo, hợp đồng hệ thống sẽ tự động cập nhật để ghi hàm băm của khối trước đó vào hợp đồng hệ thống (hàm băm của 8192 khối bộ nhớ trước đó sẽ được viết lại).
Bằng cách này, trong ví dụ về thử thách gian lận Optimismtic Rollup, người thách thức không phải quay lại khối bộ nhớ trước đó để chứng minh từng khối bộ nhớ một, nhưng có thể trực tiếp chứng minh rằng trong trạng thái hiện tại của chuỗi khối bộ nhớ 10000, giá trị của một Lưu trữ nhất định (tương ứng với khối bộ nhớ 9000) của hợp đồng hệ thống là giá trị băm của khối bộ nhớ 9000. Nếu phạm vi vượt quá 8192, chẳng hạn như khối bộ nhớ 1000, thì nhiều nhất là một bước nữa để chứng minh giá trị băm của khối bộ nhớ 1808 (= 10000 - 8192), sau đó chứng minh giá trị băm của khối bộ nhớ 1000 trong hợp đồng hệ thống ở trạng thái hiện tại của chuỗi khối bộ nhớ 1808.
Điều này cũng mở đường cho một máy khách không trạng thái trong tương lai: trong tương lai, các nút ánh sáng sẽ không còn cần lưu trữ các tiêu đề khối của tất cả các khối bộ nhớ lịch sử, mà sẽ chỉ cần yêu cầu người khác cung cấp bằng chứng bằng phương pháp bằng chứng trong ví dụ thử thách gian lận trước đó khi cần sử dụng hàm băm của khối bộ nhớ trong lịch sử hoặc nội dung của khối bộ nhớ.
EIP-7623: Tăng chi phí calldata
Tăng chi phí xuất bản dữ liệu với calldata để tạo đủ không gian an toàn để tăng Giới hạn Gas Khối và Giới hạn Blob.
Với nhu cầu phát hành dữ liệu ngày càng tăng, sau khi giới thiệu blob trong EIP-4844 để cho phép rollups đưa dữ liệu vào một cách rất rẻ, việc tăng số lượng blob đã là một nâng cấp mà cộng đồng đang mong đợi.
!
Ngày càng nhiều người xác minh cho biết họ ủng hộ việc tăng Giới hạn Gas khối.
Tuy nhiên, việc tăng Giới hạn Gas Block hoặc số lượng Blob đều sẽ tăng áp lực đối với mạng p2p Ethereum do lượng dữ liệu giao dịch tăng lên, điều này sẽ làm tăng hiệu suất của kẻ tấn công, trừ khi chi phí phát hành dữ liệu cũng được tăng lên.
Sau khi giao thức EIP-7623 được phát hành, chi phí của calldata sẽ được tăng lên 2,5 lần từ "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas" lên "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas".
Ban đầu, nếu kẻ tấn công sử dụng tất cả Block Gas Limit (30M) để đưa dữ liệu rác, kích thước dữ liệu của khối bộ nhớ sẽ vào khoảng 1,79 MB (30M/16), so với kích thước khối bộ nhớ trung bình chỉ khoảng 100 KB. Nếu giới hạn khí khối được tăng lên 40M, kẻ tấn công có thể tạo ra một khối bộ nhớ khoảng 2,38 MB. Khi chi phí calldata tăng lên 2,5 lần, hiệu quả của kẻ tấn công sẽ giảm xuống tối đa 0,72MB cho 30M và 0,95MB cho 40M, do đó Block Gas Limit và Blob có thể được tăng lên một cách tự tin hơn. Tuy nhiên, giao thức kỹ thuật này không muốn ảnh hưởng đến người dùng phổ thông "không sử dụng calldata để xuất bản dữ liệu", vì vậy nó sẽ tính tổng mức sử dụng gas của giao dịch theo hai cách, tùy theo cách nào cao hơn:
Cách tính lượng Gas giao dịch ban đầu, kết hợp với chi phí calldata cũ để tính: nghĩa là tính calldata theo cách 'Byte không: 4 Gas, Byte khác không: 16 Gas', sau đó cộng thêm Gas tiêu thụ khi thực hiện giao dịch và Gas tiêu thụ khi triển khai hợp đồng.
Đơn giản chỉ cần tính toán lượng khí calldata, nhưng sử dụng chi phí mới để tính toán: tức là calldata được tính theo cách "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas", nhưng không bao gồm lượng gas tiêu thụ khi thực hiện hoặc lượng gas tiêu thụ khi triển khai hợp đồng, vì vậy đối với những người dùng thường "không sử dụng calldata để xuất bản dữ liệu" (chẳng hạn như lên Uniswap để trao đổi) thì đó là Gas chính Tiêu thụ là một phần của việc thực thi và ngay cả khi calldata được tính toán với chi phí mới, nó sẽ không vượt quá lượng gas tiêu thụ khi thực thi, vì vậy người dùng nói chung sẽ không bị ảnh hưởng.
Tác động thực sự sẽ là đối với các bản tổng hợp nhỏ hơn, bởi vì blob có kích thước cố định và phí cố định, do đó, các bản tổng hợp nhỏ không hiệu quả để sử dụng blob và sử dụng calldata sẽ hiệu quả hơn về chi phí, nhưng sau EIP-7623, chi phí của các bản tổng hợp nhỏ này sẽ tăng 2,5 lần và họ có thể phải chuyển sang sử dụng blob hoặc tìm cách hợp lực để chia sẻ blob.
**EIP-7691: Tăng thông lượng Blob **
Tăng số lượng blob và thêm không gian để xuất bản dữ liệu vào bản tổng hợp. *
EIP-7691 sẽ tăng số lượng Blob từ "Mục tiêu: 3 Blob, Giới hạn: 6 Blob" lên thành "Mục tiêu: 6 Blob, Giới hạn: 9 Blob", tạo thêm không gian cho việc xuất bản thông tin cho Rollup.
Lưu ý: Ngoài ra, thị trường phí Blob cũng cần một số điều chỉnh thiết kế, ví dụ như tốc độ điều chỉnh phí không đủ nhanh chóng và giới hạn phí quá thấp, nhưng điều này không phải là vấn đề mà giao thức kỹ thuật này cần giải quyết.
Các thỏa thuận kỹ thuật khác
**EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi xác nhận **
Điều chỉnh nội dung bỏ phiếu của validator để giúp tổng hợp phiếu bầu dễ dàng hơn và giảm áp lực lên mạng P2P.
Người xác thực được chỉ định ngẫu nhiên cho một nhóm các ủy ban và cặp cho mỗi kỷ nguyên
Trong bỏ phiếu khối bộ nhớ, phiếu bầu của người xác thực trong mỗi ủy ban có thể được tổng hợp lại với nhau, điều này làm giảm số phiếu bầu được thông qua trong mạng P2P, nhưng phiếu bầu của người xác thực sẽ chứa thông tin về số lượng ủy ban mà trình xác thực thuộc về, có nghĩa là phiếu bầu của các ủy ban khác nhau không thể được tổng hợp, ngay cả khi tất cả họ bỏ phiếu trên cùng một khối bộ nhớ.
EIP-7549 loại bỏ thông tin rằng trình xác thực thuộc về ủy ban đầu tiên khỏi nội dung bỏ phiếu, để các trình xác thực từ các ủy ban khác nhau có thể được tổng hợp lại với nhau khi nội dung bỏ phiếu giống nhau, giảm hơn nữa số phiếu bầu được thông qua trong mạng P2P và giảm áp lực lên mạng P2P.
EIP-7840: Thêm lịch trình Blob vào tệp cấu hình EL
Để tạo một tệp cấu hình cho tham số Blob ở tầng thực thi, từ bỏ việc tìm kiếm thông tin tham số Blob từ nút tầng thực thi đến nút tầng đồng thuận.
Các tham số liên quan đến Blob hiện đang được lưu trữ ở nút tầng đồng thuận, nhưng các nút tầng thực thi vẫn cần những tham số này trong một số trường hợp (ví dụ: RPC eth_feeHistory), vì vậy chúng phải hỏi nút tầng đồng thuận.
EIP-7840 tạo một tệp cấu hình cho các tham số liên quan đến Blob ở tầng thực thi, các nút tầng thực thi có thể trực tiếp đọc các tham số liên quan đến Blob thông qua tệp cấu hình này mà không cần phải hỏi các nút tầng đồng thuận nữa.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Giới thiệu về Ethereum Pectra Hard Fork
Bởi NIC Lin, Trung bình
Dự kiến chia rẽ cứng của Pectra sẽ bắt đầu triển khai mạng chính vào tháng 3 năm 2025. Bản nâng cấp của Pectra bao gồm 11 giao thức kỹ thuật (EIP), bao gồm:
Các giao thức công nghệ liên quan đến thế chấp
EIP-6110: BLS12-381 Curve Operation Precompile
Đơn giản hóa quy trình tham gia cầm cố cho người dùng, giảm thiểu thời gian chờ đợi một cách đáng kể.
Cách mà người dùng tham gia cam kết là gửi 32 ETH vào tầng thực thi và được ghi lại trong Nhật ký Sự kiện, sau đó tầng đồng thuận thực thi sẽ phân tích Nhật ký Sự kiện để xác định liệu có ai tham gia cam kết hay không, sau đó người dùng tham gia cam kết sẽ trở thành người xác minh.
Tuy nhiên, người xác minh tầng đồng thuận đầu tiên cần xác định thời điểm nào để thực hiện đồng thuận, nếu không, một số người xác minh sẽ thấy 5 khoản tiền mới được gửi, trong khi một số người xác minh chỉ thấy 3 khoản tiền, do đó những người xác minh tầng đồng thuận sẽ bỏ phiếu cho khối tầng thực hiện nào để tham khảo (eth1data), đảm bảo rằng tất cả mọi người đều nhìn thấy cùng một khối tầng thực hiện.
Tuy nhiên, ban đầu trong quá trình thiết kế để tránh sự cố lớn xảy ra tại lớp thực thi dẫn đến phân nhánh chuỗi, do đó khối dữ liệu thực thi tham khảo (eth1data) sẽ là một khối thực thi khoảng 10 giờ trước, đảm bảo rằng khi xảy ra sự cố lớn, các nhà phát triển tầng đồng thuận có đủ thời gian phản ứng và xử lý, tuy nhiên điều này cũng dẫn đến việc tham gia cầm cố cũng phải đợi ít nhất 10 giờ mới có hiệu lực.
!
△ Dữ liệu eth1data trong khối CL là 10900000, Hash khối được ghi trong đó là 21683339, xuất hiện 10 giờ trước khối tầng thực thi.
Sau khi giao thức kỹ thuật EIP-6110 được thực thi, dữ liệu cam kết của người dùng trên hợp đồng sẽ trực tiếp trở thành một phần của lớp thực thi và vì bản thân khối lớp đồng thuận sẽ chứa khối lớp thực thi (nhưng không phải eth1data), người xác thực lớp đồng thuận không còn cần phải xem xét vấn đề "xác nhận rằng khối bộ nhớ lớp thực thi tham chiếu là như nhau", miễn là khối bộ nhớ lớp đồng thuận được hơn hai phần ba số người xác thực bình chọn, mọi người sẽ đạt được sự đồng thuận trên cùng một khối lớp thực thi. Do đó, sau khi tham gia cam kết, người dùng có thể đợi khối bộ nhớ lớp thực thi hoàn tất quá trình xử lý sớm nhất trong khoảng 13 phút và máy khách lớp đồng thuận cũng có thể loại bỏ logic phức tạp ban đầu được sử dụng để xử lý dữ liệu đặt cọc.
EIP-7002: Lưu trữ giá trị băm khối lịch sử trong State
Có thể được sử dụng để cải thiện quy trình rút tiền và lợi nhuận cho người xác minh hoặc rút tiền gửi tiền, giảm thiểu rủi ro cho người xác minh.
Để tham gia staking, bạn cần có hai khóa, đó là Validator Key và Withdrawal Credential.
Validator Key được sử dụng để xác minh nội dung của người xác minh, và Credential Rút Tiền được sử dụng để địa chỉ mà tiền đặt cọc và lợi nhuận sẽ được rút ra khi người xác minh rút tiền cọc. Ngoài ra, hiện nay, việc rút tiền cọc phải được thực hiện bằng cách sử dụng Validator Key.
Nếu mất Validator Key, bạn sẽ không thể thực hiện công việc của người xác minh và không thể rút tiền gửi; nếu mất Withdrawal Credential, bạn sẽ mất tất cả tiền đặt cược và lợi nhuận. Ngoài ra, một số người dùng có thể sử dụng dịch vụ đặt cược bên thứ ba như Lido, khi sử dụng các nền tảng này, người dùng cần tự giữ Withdrawal Credential, trong khi Validator Key sẽ được nhà cung cấp dịch vụ quản lý và thực hiện công việc của người xác minh thay mặt.
Bằng cách thực hiện giao thức kỹ thuật EIP-7002, người dùng có thể sử dụng thông tin Xác nhận Rút tiền để gọi hợp đồng "Rút" (được triển khai tại 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) để rút cọc (Rút) hoặc rút tiền đặt cược và thu nhập (Rút một phần), từ đó giảm thiểu rủi ro liên quan đến việc sử dụng dịch vụ cọc của bên thứ ba. Nếu người dùng tham gia cọc một cách tự do nhưng mất Khóa Xác nhận, họ cũng có thể rút cọc thông qua cách thức này.
Lưu ý: Nếu thông tin Xác thực Rút tiền của bạn vẫn ở định dạng Khóa công khai BLS, hãy nhớ chuyển đổi trước, đổi nó thành định dạng Địa chỉ EL.
EIP-7251: Thêm vào MAX_EFFECTIVE_BALANCE
Có thể tăng đáng kể giới hạn tiền gửi để giảm số lượng người xác minh, và người xác minh chưa đạt đến giới hạn có thể tự động hưởng lợi từ lợi nhuận tiền gửi.
Người dùng đặt cược để trở thành người xác minh cần cung cấp số lượng ETH của MAX_EFFECTIVE_BALANCE, không ít hơn cũng không nhiều hơn (hiện tại MAX_EFFECTIVE_BALANCE là 32 ETH). Nếu người dùng giữ 1024 ETH để đặt cược, họ có thể tham gia cược 32 lần, kích hoạt 32 người xác minh, và chạy 32 nút xác minh. Sự tích cực tham gia cược của mọi người đã dẫn đến khoảng 1 triệu người xác minh hiện tại và tiếp tục tăng lên, điều này không chỉ làm cho dữ liệu trạng thái tầng đồng thuận trở nên lớn hơn và phức tạp hơn, mà còn tăng tải cho tầng mạng p2p của tầng đồng thuận, vì mỗi Slot (mỗi 12 giây) đều có hàng chục ngàn chữ ký của người xác minh cần được truyền đi và tổng hợp liên tục trong tầng mạng p2p.
Sau khi thực hiện giao thức EIP-7251, giới hạn đặt cược tối thiểu (MIN_ACTIVATION_BALANCE) vẫn là 32 ETH, nhưng giới hạn tối đa (MAX_EFFECTIVE_BALANCE) sẽ được tăng đáng kể lên 2048 ETH, bạn có thể đặt cược bất kỳ số lượng ETH nào từ 32 đến 2048, có thể nhận được lợi nhuận từ việc đặt cược mà không cần rút lợi nhuận định kỳ, tích lũy 32 ETH sau đó tiếp tục đặt cược mới.
Hiện tại, các validator hiện tại không cần rút khỏi staking trước, sau đó hợp nhất và tham gia lại staking với nhau, mà có thể trực tiếp sử dụng "hợp đồng hợp nhất tiền gửi" mới (được triển khai trong 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) trên lớp thực hiện và Crendential rút tiền của validator sẽ gọi hợp đồng để bắt đầu yêu cầu hợp nhất tiền gửi.
Lưu ý: Nếu Thông tin rút tiền của bạn ở định dạng khóa công khai BLS, trước tiên bạn cần chuyển nó sang định dạng địa chỉ EL.
EIP-7685: Yêu cầu Tầng Thực thi Phổ quát
Thiết lập một kênh thông tin chính thức từ EL sang CL, giúp người dùng và dịch vụ đặt cược có thể gửi yêu cầu trực tiếp đến tầng đồng thuận.
Người dùng có thể gửi yêu cầu trực tiếp từ tầng thực thi đến tầng đồng thuận, dịch vụ đặt cọc (ví dụ như Lido) có thể hoạt động theo cách phi trung tâm hơn. Ví dụ như yêu cầu rút cọc theo EIP-7002 đã đề cập trước đó và yêu cầu gộp tiền đặt cọc theo EIP-7251. Nếu không có giao thức công nghệ này, người dùng của Lido sẽ phải tin tưởng rằng nhà cung cấp dịch vụ nút Lido sẽ thực hiện việc rút cọc hoặc gộp tiền đặt cọc một cách trung thực tại tầng đồng thuận; nhờ có giao thức công nghệ này, người dùng của Lido có thể trực tiếp gửi yêu cầu thông qua hợp đồng quản trị trên tầng thực thi.
Các yêu cầu này sẽ được phân biệt bằng Loại Yêu Cầu để phân biệt các loại yêu cầu khác nhau, cũng như thông qua các hợp đồng khác nhau để khởi động yêu cầu, cuối cùng các yêu cầu này sẽ được ghi vào khối bộ nhớ của tầng thực thi, do đó tầng đồng thuận có thể trực tiếp lấy thông tin này thông qua các khối bộ nhớ của tầng thực thi, không cần phải viết logic phân tích riêng lẻ nữa.
EIP-6110, EIP-7002 và EIP-7251 đều dựa trên các tiêu chí được xác định bởi EIP-7685:
（0x00000000219ab540356cbb839cbe05303d7705fa）gửi yêu cầu.
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Khởi tạo yêu cầu.
（0x00431F263cE400f4455c2dCf564e53007Ca4bbBb）gửi yêu cầu.
Công nghệ hợp đồng để cải thiện trải nghiệm người dùng
EIP-7702: Thiết lập mã tài khoản EOA
Cho phép tài khoản EOA biến hình thành tài khoản hợp đồng mới khi cần thiết, tăng trợi nghiệm sử dụng đến mục độ lớn.
Có một số thiếu sót trong việc sử dụng tài khoản EOA, bao gồm:
Nếu là một tài khoản hợp đồng thông minh (ví dụ Safe), thì tất cả các vấn đề trên đều có thể được giải quyết:
Đề xuất EIP-7702 cung cấp cho các tài khoản EOA khả năng trở thành tài khoản hợp đồng. Người dùng ký tin nhắn đã chuyển đổi bằng khóa riêng EOA, bao gồm "ID chuỗi", "Địa chỉ hợp đồng đã thay đổi" và "Giá trị Nonce EOA":
Tuy nhiên, có vài điểm cần chú ý:
Ngay cả khi tài khoản EOA của người dùng trở thành hợp đồng, anh ta vẫn có thể tiếp tục sử dụng nó theo cách tương tự như tài khoản EOA ban đầu. Ví dụ: nếu tài khoản EOA của bạn trở thành Hợp đồng an toàn, bạn có thể sử dụng giao diện An toàn, thực hiện quy trình Giao dịch an toàn hoặc tiếp tục ký và gửi giao dịch bằng ví EOA ban đầu. Tuy nhiên, điều này cũng đồng nghĩa với việc tính bảo mật của tài khoản vẫn bị giới hạn ở khóa riêng.
Ngay cả khi EOA của người dùng trở thành MultiSig, miễn là anh ta không mất khóa riêng EOA, bảo mật tài khoản của anh ta sẽ luôn là bảo mật của khóa riêng EOA: anh ta vẫn phải giữ khóa riêng hoặc cụm từ ghi nhớ của mình an toàn và tài khoản của anh ta sẽ không trở nên an toàn như MultiSig.
Khi một tài khoản EOA biến thành hợp đồng và ghi dữ liệu vào Bộ nhớ của nó, trừ khi có hành động xóa dữ liệu cụ thể, dữ liệu được ghi vào Bộ nhớ không được định dạng lại do tài khoản EOA biến thành hợp đồng khác hoặc hủy bỏ việc biến đổi, vì vậy nhà phát triển cần chú ý rằng Bộ nhớ không đọc được dữ liệu cũ do hợp đồng trước đó đã để lại, có thể tham khảo ERC-7201.
Nói chung, tài khoản hợp đồng sẽ cần một bước khởi tạo để ghi đồng bộ thông tin của chủ sở hữu tài khoản (chẳng hạn như khóa công khai hoặc địa chỉ) khi tài khoản được triển khai, để tránh mất quyền sở hữu tài khoản do frontrun của bước triển khai. Điều này thường được thực hiện bởi hợp đồng nhà máy triển khai tài khoản hợp đồng để thực hiện "triển khai + khởi tạo", nhưng vì EIP-7702 là một thay đổi trực tiếp, chứ không phải là một nhà máy triển khai hợp đồng lên EOA, kẻ tấn công có thể sao chép chữ ký chuyển đổi của người dùng và gửi trước giao dịch đến chuỗi để chuyển đổi cho người dùng nhưng khởi tạo tài khoản để kẻ tấn công có thể kiểm soát được, vì vậy các nhà phát triển cần chú ý đến EIP-7702. Một phương pháp bảo vệ có thể là kiểm tra chữ ký của tài khoản EOA trong chức năng khởi tạo, để ngay cả khi nó được ưu tiên, kẻ tấn công sẽ không thể tạo chữ ký của tài khoản EOA để hoàn tất quá trình khởi tạo.
Ví cần làm tốt công việc kiểm tra người dùng, đồng thời dừng yêu cầu và cảnh báo người dùng khi website DApp độc hại yêu cầu người dùng ký giao dịch chuyển đổi, nếu không nếu người dùng ký giao dịch chuyển đổi độc hại, tài sản sẽ được chuyển đi ngay lập tức. Dưới đây là một số ví dụ về cách chuyển đổi thành hợp đồng:
** Giao thức kỹ thuật DApp **
**EIP-2537: Trình biên dịch trước hoạt động đường cong BLS12-381 **
Giảm chi phí và làm cho nó khả thi hơn đối với các ứng dụng bằng chứng không có kiến thức dựa trên đường cong BLS.
EIP-2537 bổ sung một số hợp đồng biên dịch trước mới để cung cấp các hoạt động đường cong BLS rẻ tiền, giúp việc phát triển các ứng dụng chứng minh không có kiến thức dựa trên đường cong BLS trở nên khả thi hơn.
EIP-2935: Lưu giữ giá trị Hash khối lịch sử trong State
Nó cho phép các nhà phát triển hoặc các nút đọc hàm băm khối của các khối bộ nhớ trong quá khứ trực tiếp từ việc lưu trữ hợp đồng hệ thống.
Nếu nhà phát triển cần chứng minh nội dung của một khối nhớ trước đó, ví dụ trong thách thức gian lận của Optimismtic Rollup, để chứng minh rằng có 1000 khối nhớ trước đó tồn tại một giao dịch nào đó, thì người thách thức không thể nói trực tiếp.
"Tin tôi đi, 1000 khối bộ nhớ thực sự tồn tại trước đây", anh ta phải đưa ra bằng chứng, nhưng không có bằng chứng trực tiếp để chứng minh rằng "1000 khối bộ nhớ trước đó chứa những nội dung này", vì vậy anh ta phải chứng minh giao dịch trong một "chuỗi" khối bộ nhớ, từng khối một, cho đến khi nó đạt đến 1000 khối trước đó, và sau đó chứng minh rằng giao dịch tồn tại trong khối.
!
Mỗi khối sẽ trỏ đến một khối cha, vì vậy có thể chứng minh bất kỳ khối nào trong lịch sử.
Giả sử nó hiện là một khối bộ nhớ có số 10000 và thử thách gian lận muốn cung cấp bằng chứng rằng khối bộ nhớ có số 9000 có giao dịch X, người thách thức cần bắt đầu với hàm băm của khối bộ nhớ 10000, trước tiên chứng minh hàm băm của khối bộ nhớ mẹ 9999 được kết nối với khối bộ nhớ 10000, sau đó chứng minh khối bộ nhớ 9998... Cho đến khối bộ nhớ 9000, nội dung của khối bộ nhớ 9000 được đề xuất để chứa giao dịch X.
Sau EIP-2935, sẽ có một hợp đồng hệ thống (được triển khai trên 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) sẽ lưu trữ các hàm băm của tối đa 8192 khối bộ nhớ trước đó. Mỗi khi một khối bộ nhớ mới được tạo, hợp đồng hệ thống sẽ tự động cập nhật để ghi hàm băm của khối trước đó vào hợp đồng hệ thống (hàm băm của 8192 khối bộ nhớ trước đó sẽ được viết lại).
Bằng cách này, trong ví dụ về thử thách gian lận Optimismtic Rollup, người thách thức không phải quay lại khối bộ nhớ trước đó để chứng minh từng khối bộ nhớ một, nhưng có thể trực tiếp chứng minh rằng trong trạng thái hiện tại của chuỗi khối bộ nhớ 10000, giá trị của một Lưu trữ nhất định (tương ứng với khối bộ nhớ 9000) của hợp đồng hệ thống là giá trị băm của khối bộ nhớ 9000. Nếu phạm vi vượt quá 8192, chẳng hạn như khối bộ nhớ 1000, thì nhiều nhất là một bước nữa để chứng minh giá trị băm của khối bộ nhớ 1808 (= 10000 - 8192), sau đó chứng minh giá trị băm của khối bộ nhớ 1000 trong hợp đồng hệ thống ở trạng thái hiện tại của chuỗi khối bộ nhớ 1808.
Điều này cũng mở đường cho một máy khách không trạng thái trong tương lai: trong tương lai, các nút ánh sáng sẽ không còn cần lưu trữ các tiêu đề khối của tất cả các khối bộ nhớ lịch sử, mà sẽ chỉ cần yêu cầu người khác cung cấp bằng chứng bằng phương pháp bằng chứng trong ví dụ thử thách gian lận trước đó khi cần sử dụng hàm băm của khối bộ nhớ trong lịch sử hoặc nội dung của khối bộ nhớ.
EIP-7623: Tăng chi phí calldata
Tăng chi phí xuất bản dữ liệu với calldata để tạo đủ không gian an toàn để tăng Giới hạn Gas Khối và Giới hạn Blob.
Với nhu cầu phát hành dữ liệu ngày càng tăng, sau khi giới thiệu blob trong EIP-4844 để cho phép rollups đưa dữ liệu vào một cách rất rẻ, việc tăng số lượng blob đã là một nâng cấp mà cộng đồng đang mong đợi.
!
Ngày càng nhiều người xác minh cho biết họ ủng hộ việc tăng Giới hạn Gas khối.
Tuy nhiên, việc tăng Giới hạn Gas Block hoặc số lượng Blob đều sẽ tăng áp lực đối với mạng p2p Ethereum do lượng dữ liệu giao dịch tăng lên, điều này sẽ làm tăng hiệu suất của kẻ tấn công, trừ khi chi phí phát hành dữ liệu cũng được tăng lên.
Sau khi giao thức EIP-7623 được phát hành, chi phí của calldata sẽ được tăng lên 2,5 lần từ "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas" lên "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas".
Ban đầu, nếu kẻ tấn công sử dụng tất cả Block Gas Limit (30M) để đưa dữ liệu rác, kích thước dữ liệu của khối bộ nhớ sẽ vào khoảng 1,79 MB (30M/16), so với kích thước khối bộ nhớ trung bình chỉ khoảng 100 KB. Nếu giới hạn khí khối được tăng lên 40M, kẻ tấn công có thể tạo ra một khối bộ nhớ khoảng 2,38 MB. Khi chi phí calldata tăng lên 2,5 lần, hiệu quả của kẻ tấn công sẽ giảm xuống tối đa 0,72MB cho 30M và 0,95MB cho 40M, do đó Block Gas Limit và Blob có thể được tăng lên một cách tự tin hơn. Tuy nhiên, giao thức kỹ thuật này không muốn ảnh hưởng đến người dùng phổ thông "không sử dụng calldata để xuất bản dữ liệu", vì vậy nó sẽ tính tổng mức sử dụng gas của giao dịch theo hai cách, tùy theo cách nào cao hơn:
Tác động thực sự sẽ là đối với các bản tổng hợp nhỏ hơn, bởi vì blob có kích thước cố định và phí cố định, do đó, các bản tổng hợp nhỏ không hiệu quả để sử dụng blob và sử dụng calldata sẽ hiệu quả hơn về chi phí, nhưng sau EIP-7623, chi phí của các bản tổng hợp nhỏ này sẽ tăng 2,5 lần và họ có thể phải chuyển sang sử dụng blob hoặc tìm cách hợp lực để chia sẻ blob.
**EIP-7691: Tăng thông lượng Blob **
EIP-7691 sẽ tăng số lượng Blob từ "Mục tiêu: 3 Blob, Giới hạn: 6 Blob" lên thành "Mục tiêu: 6 Blob, Giới hạn: 9 Blob", tạo thêm không gian cho việc xuất bản thông tin cho Rollup.
Lưu ý: Ngoài ra, thị trường phí Blob cũng cần một số điều chỉnh thiết kế, ví dụ như tốc độ điều chỉnh phí không đủ nhanh chóng và giới hạn phí quá thấp, nhưng điều này không phải là vấn đề mà giao thức kỹ thuật này cần giải quyết.
Các thỏa thuận kỹ thuật khác
**EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi xác nhận **
Điều chỉnh nội dung bỏ phiếu của validator để giúp tổng hợp phiếu bầu dễ dàng hơn và giảm áp lực lên mạng P2P.
Người xác thực được chỉ định ngẫu nhiên cho một nhóm các ủy ban và cặp cho mỗi kỷ nguyên
Trong bỏ phiếu khối bộ nhớ, phiếu bầu của người xác thực trong mỗi ủy ban có thể được tổng hợp lại với nhau, điều này làm giảm số phiếu bầu được thông qua trong mạng P2P, nhưng phiếu bầu của người xác thực sẽ chứa thông tin về số lượng ủy ban mà trình xác thực thuộc về, có nghĩa là phiếu bầu của các ủy ban khác nhau không thể được tổng hợp, ngay cả khi tất cả họ bỏ phiếu trên cùng một khối bộ nhớ.
EIP-7549 loại bỏ thông tin rằng trình xác thực thuộc về ủy ban đầu tiên khỏi nội dung bỏ phiếu, để các trình xác thực từ các ủy ban khác nhau có thể được tổng hợp lại với nhau khi nội dung bỏ phiếu giống nhau, giảm hơn nữa số phiếu bầu được thông qua trong mạng P2P và giảm áp lực lên mạng P2P.
EIP-7840: Thêm lịch trình Blob vào tệp cấu hình EL
Để tạo một tệp cấu hình cho tham số Blob ở tầng thực thi, từ bỏ việc tìm kiếm thông tin tham số Blob từ nút tầng thực thi đến nút tầng đồng thuận.
Các tham số liên quan đến Blob hiện đang được lưu trữ ở nút tầng đồng thuận, nhưng các nút tầng thực thi vẫn cần những tham số này trong một số trường hợp (ví dụ: RPC eth_feeHistory), vì vậy chúng phải hỏi nút tầng đồng thuận.
EIP-7840 tạo một tệp cấu hình cho các tham số liên quan đến Blob ở tầng thực thi, các nút tầng thực thi có thể trực tiếp đọc các tham số liên quan đến Blob thông qua tệp cấu hình này mà không cần phải hỏi các nút tầng đồng thuận nữa.