Ngoài việc biên dịch nguyên văn, bài viết này còn bổ sung giới thiệu các EIP khác của Pectra mà nguyên văn không đề cập.
Liên kết gốc:
Điểm mấu chốt
Pectra là bản nâng cấp quan trọng tiếp theo của Ethereum, liên quan đến những thay đổi ở lớp thực thi (Prague) và lớp đồng thuận (Electra). Sau nhiều lần thử nghiệm với bản nâng cấp Pectra trên mạng thử nghiệm, cuối cùng đã xác định được thời điểm kích hoạt nâng cấp mạng chính Pectra vào khoảng 10:05 UTC ngày 7 tháng 5.
Nâng cấp này sẽ cải thiện đáng kể việc staking, khả năng mở rộng Layer 2 và trải nghiệm người dùng (UX), đồng thời đặt nền tảng cho những thay đổi trong tương lai.
Các thay đổi chính bao gồm: tăng giới hạn staking của các validator, rút tiền staking linh hoạt, tăng cường trừu tượng hóa tài khoản và tăng thông lượng blob để nâng cao hiệu quả và an ninh mạng.
Giới thiệu
Đã 31 tháng kể từ "The Merge", 24 tháng kể từ nâng cấp "Shapella", 13 tháng kể từ nâng cấp "Dencun", Ethereum sắp đón nhận nâng cấp lớn tiếp theo — — hard fork Pectra.
Và trước khi nâng cấp mạng chính Pectra, việc nâng cấp mạng thử nghiệm đã gặp nhiều khó khăn.
Việc nâng cấp Pectra cho testnet Holesky đã được kích hoạt vào ngày 24 tháng 2 lúc 21:55 UTC, nhưng đã bị gián đoạn do cấu hình sai phần mềm máy khách (Geth, Nethermind và Besu có địa chỉ hợp đồng tiền gửi sai), dẫn đến một nhánh chuỗi. Các nhà phát triển đã thảo luận về kế hoạch khôi phục mạng thông qua các sự kiện phạt quy mô lớn, với mục đích đẩy nhanh việc thoát khỏi các trình xác thực lỗi và đạt được tính cuối cùng của mạng cho đến ngày 11 tháng Ba.
Bản nâng cấp Pectra của mạng thử nghiệm Sepolia đã được nâng cấp theo kế hoạch vào ngày 5 tháng 3. Do vấn đề cấu hình hợp đồng gửi tùy chỉnh, một số khách hàng lớp thực thi (EL) đã gặp sự cố khi bao gồm giao dịch trong khối, nhưng vấn đề đã nhanh chóng được khắc phục và mạng đã đạt được độ hoàn thiện.
Vào ngày 19 tháng 3, để kiểm tra việc rút lui của các xác nhận viên, mạng thử nghiệm mới Hoodi đã được ra mắt và đã thành công trong việc kích hoạt nâng cấp mạng Pectra vào ngày 26 tháng 3.
Việc nâng cấp mạng thử nghiệm Pectra của Ethereum đã trải qua hai tháng gian nan, tạo điều kiện cho việc triển khai mạng chính, cuối cùng được xác định sẽ kích hoạt nâng cấp mạng chính Pectra vào khoảng 10:05 UTC ngày 7 tháng 5.
Giống như các bản nâng cấp Ethereum trước đây, Pectra liên quan đến cả lớp thực thi (EL) và lớp đồng thuận (CL). Tên gọi của nó phản ánh trọng tâm kép này: Prague (Praha) đại diện cho bản nâng cấp lớp thực thi, để tưởng nhớ địa điểm tổ chức Devcon 4; Electra (hệ sao Electra) tượng trưng cho bản nâng cấp lớp đồng thuận.
Pectra là một trong những hard fork có số lượng EIP (Ethereum Improvement Proposals, đề xuất cải tiến Ethereum) nhiều nhất trong lịch sử Ethereum với 11 EIPs. Nó được tối ưu hóa thêm dựa trên bản nâng cấp Dencun năm ngoái, nhằm cải thiện trải nghiệm người dùng (UX), tối ưu hóa hoạt động của các validator, và thúc đẩy mở rộng Layer 2, dự kiến sẽ có tác động sâu rộng đến hệ sinh thái Ethereum.
Trong bài viết này, chúng tôi sẽ phân loại theo lĩnh vực của từng EIP và phân tích sâu về từng EIP.
Cải tiến cơ chế xác thực và staking
Pectra tối ưu hóa trải nghiệm hoạt động của các nhà xác thực trong hệ thống PoS của Ethereum thông qua ba EIP chính:
EIP-7251: Tăng tối đa số dư hiệu quả (MaxEB)
Hiện tại, cơ chế staking của Ethereum giới hạn giới hạn staking hiệu quả của một validator đơn lẻ là 32 ETH, điều này có nghĩa là các nhà đầu tư độc lập phải staking theo đơn vị 32 ETH, và phần thưởng vượt quá giới hạn đó sẽ không được tính vào staking hiệu quả.
EIP-7251 đề xuất nâng giới hạn số dư hiệu quả tối đa (MaxEB) lên 2048 ETH, cho phép phạm vi staking của một validator duy nhất mở rộng từ 32 đến 2048 ETH, mang lại các ảnh hưởng bao gồm:
· Tăng tính linh hoạt của việc staking: Người staking có thể tái đầu tư toàn bộ lợi nhuận vào số dư staking hợp lệ mà không bị giới hạn bởi bội số của 32 ETH. Ví dụ, một người xác thực nắm giữ 33 ETH hiện tại có thể nhận thưởng staking cho tất cả 33 ETH, nâng cao hiệu quả và tính linh hoạt của vốn.
· Giảm số lượng người xác thực: Hiện tại Ethereum có 1,05 triệu người xác thực hoạt động, EIP này cho phép các nhà điều hành lớn hợp nhất người xác thực của họ, từ đó giảm tổng số và giảm tải cho mạng.
· Giảm tải mạng: Mặc dù nhiều người xác thực hơn giúp tăng cường tính phi tập trung, nhưng cũng sẽ làm tăng gánh nặng băng thông và tính toán. Tăng MaxEB có thể tối ưu hóa tập hợp người xác thực và giảm chi phí giao tiếp ngang hàng.
EIP-7002: Lớp thực thi có thể kích hoạt rút tiền
EIP-7002 tăng cường chức năng của người xác thực, cho phép họ kích hoạt rút tiền và rút một phần thông qua chứng chỉ rút tiền từ lớp thực thi (0x01).
Hiện tại, các xác thực viên có hai khóa:
Khóa hoạt động, dùng để thực hiện nhiệm vụ xác thực;
Khóa rút tiền, dùng để truy cập và quản lý vốn đặt cược.
Trước đây, chỉ có khóa hoạt động mới có thể kích hoạt việc thoát, trong khi khóa rút tiền không thể tự hoạt động. EIP-7002 cho phép khóa rút tiền cũng có thể kích hoạt việc rút tiền, điều này mang lại:
· Kiểm soát vốn lớn hơn: Người xác thực có thể quản lý trực tiếp vốn mà không cần phụ thuộc vào nhà điều hành nút.
· Hỗ trợ các hồ bơi staking hoàn toàn không tin cậy, nâng cao độ an toàn và mức độ phi tập trung.
EIP-6110: Lưu trữ tiền gửi của người xác thực trên chuỗi
Hiện tại, khi các xác thực viên mới nạp tiền vào lớp thực thi, họ cần phải chờ lớp đồng thuận nhận diện và xử lý, dẫn đến độ trễ kích hoạt.
EIP-6110 cho phép lớp thực thi truyền thông tin gửi tiền trực tiếp đến lớp đồng thuận, giảm bớt các bước xác thực bổ sung, làm cho thời gian kích hoạt của người xác thực từ khoảng 9 giờ giảm xuống còn khoảng 13 phút.
Nâng cao khả năng mở rộng Layer 2: Tăng thông lượng Blob
EIP-7691: Tăng cường khả năng xử lý Blob
Năm ngoái, bản nâng cấp Dencun đã giới thiệu Blobs, như một cách hiệu quả để lưu trữ dữ liệu cho các rollup Layer 2. Hiện tại, mỗi ngày có khoảng 21.000 Blobs được gửi lên Ethereum, nhưng dung lượng đã gần đạt giới hạn, dẫn đến việc phí tăng lên và hạn chế khả năng xử lý.
Hiện tại, số lượng Blob mục tiêu cho mỗi khối Ethereum là 3, tối đa là 6. EIP-7691 đề xuất tăng giá trị mục tiêu lên 6 và giá trị tối đa lên 9, nhằm tăng khả năng lưu trữ dữ liệu, cải thiện thông lượng và khả năng mở rộng. Điều này sẽ giảm chi phí lưu trữ dữ liệu, từ đó giảm phí giao dịch L2.
EIP-7623: Tăng chi phí calldata
Trước khi cơ chế Blob ra mắt, L2 chủ yếu sử dụng calldata để lưu trữ dữ liệu, và trong một số trường hợp vẫn tiếp tục sử dụng vì nó có thể tiết kiệm chi phí hơn.
EIP-7623 tăng phí calldata để khuyến khích L2 sử dụng blob để lưu trữ dữ liệu, từ đó nâng cao hiệu quả giao dịch rollup.
Tăng cường trải nghiệm người dùng (UX)
EIP-7702: Thiết lập mã tài khoản EOA
Ý tưởng cốt lõi: Tạm thời cấp quyền năng hợp đồng thông minh cho EOA
EIP-7702 đã giới thiệu một loại giao dịch hoàn toàn mới (được đánh dấu là 0x04), cho phép tài khoản do bên ngoài sở hữu (EOA) tạm thời có được chức năng của hợp đồng thông minh trong quá trình thực hiện một giao dịch. Nói cách khác, mặc dù truyền thống EOA không có mã và chỉ có thể được sử dụng để ký giao dịch, nhưng thông qua đề xuất này, EOA có thể ‘tải’ một đoạn mã trong một giao dịch, từ đó thực hiện các thao tác phức tạp giống như ví hợp đồng thông minh.
Lợi thế chính
Hoạt động hàng loạt: Người dùng có thể thực hiện nhiều thao tác trong một giao dịch (ví dụ: kết hợp approve + deposit), tránh vấn đề kém hiệu quả khi cần nhiều giao dịch.
· Gas tài trợ: Cơ chế này còn hỗ trợ các bên thứ ba tài trợ phí giao dịch, cải thiện trải nghiệm người dùng, cho phép người dùng không cần giữ ETH trước đó để thực hiện giao dịch.
· Nâng cao tính an toàn và linh hoạt: Người dùng có thể kiểm soát quyền truy cập giao dịch một cách chi tiết, chẳng hạn như chỉ cho phép các tài khoản con hoạt động trong các điều kiện giới hạn, từ đó nâng cao tính an toàn cho tài khoản.
Có thể gặp phải thách thức
· Vấn đề tương thích sinh thái: Do EOA truyền thống thường được coi là không có mã, một số hợp đồng thông minh hiện có hoặc kiểm tra an toàn (ví dụ require(tx.origin == msg.sender)) có thể cần được điều chỉnh để phù hợp với cơ chế tạm thời gán mã này.
· Sự phức tạp trong cấu trúc giao dịch tăng lên: Việc giới thiệu các loại giao dịch mới sẽ yêu cầu ví và khách hàng phải thực hiện những thay đổi lớn, đảm bảo rằng không có lỗ hổng bảo mật hoặc chi phí cao thêm khi xử lý các bộ quyền mới và thiết lập mã tạm thời.
EIP-7702 cho phép các EOA thông thường tạm thời đạt được chức năng hợp đồng thông minh trong một giao dịch, cho phép giao dịch hàng loạt, tài trợ giao dịch và quản lý quyền linh hoạt hơn. Cơ chế này có thể cải thiện đáng kể trải nghiệm người dùng và mở rộng chức năng của dApps, nhưng nó cũng sẽ phá vỡ một số giả định truyền thống và yêu cầu sự thích ứng và cập nhật của tất cả các bên trong hệ sinh thái. Nhìn chung, đây là một đề xuất quan trọng để mở đường cho việc trừu tượng hóa tài khoản, với mục tiêu làm cho các tài khoản Ethereum trong tương lai vừa an toàn vừa linh hoạt.
Các EIP khác
EIP-7685: Yêu cầu tầng thực thi chung
Bối cảnh và mục đích
Hiện tại, Eth1 (tầng thực thi) và chuỗi tín hiệu (tầng đồng thuận) cần xử lý ba loại yêu cầu chính:
Gửi tiền: Sự kiện gửi tiền do người dùng khởi xướng ban đầu xuất hiện trong khối Eth1, nhưng cuối cùng cần được xử lý trên chuỗi tín hiệu.
Rút tiền: Yêu cầu rút tiền phát sinh từ chuỗi tín hiệu (thường thông qua công cụ dòng lệnh) cần được xử lý trên Eth1.
Hợp nhất người xác thực: Tương tự, yêu cầu này cũng cần được chuyển giao giữa Eth1 và chuỗi tín hiệu.
Tại sao cần đề xuất này
Hiện tại, các loại hoạt động khác nhau được truyền qua lại giữa hai lớp, dễ gây ra sự nhầm lẫn. Khung xử lý thống nhất được đề xuất bởi EIP-7685, nhằm mục đích:
· Xử lý tất cả các yêu cầu này theo một phương pháp tiêu chuẩn, giúp quy trình trở nên rõ ràng hơn và hiệu quả hơn;
· Chỉ dựa vào Eth1 để kích hoạt những thao tác này, từ đó có thể tách biệt môi trường hoạt động của các xác nhận viên và quản lý staking, qua đó nâng cao tính bảo mật.
Nội dung chính
Định danh loại yêu cầu: Đã định nghĩa một định danh cụ thể cho mỗi loại thao tác, chẳng hạn như loại yêu cầu gửi tiền và rút tiền đã có, giờ đây còn phải thêm loại yêu cầu gộp.
Đảm bảo tính toàn vẹn: Sẽ sử dụng một số cơ chế (như kiểm tra băm, dữ liệu Merkle hóa) để đảm bảo tính toàn vẹn và an toàn của dữ liệu yêu cầu.
Xử lý hàng đợi và giới hạn tốc độ: Đối với các yêu cầu đang chờ xử lý, sẽ đặt ra một số giới hạn (chẳng hạn như số lượng yêu cầu gửi tiền, rút tiền hoặc hợp nhất đang chờ cùng một lúc) để ngăn chặn quá tải hệ thống.
ý nghĩa cuối cùng
Đối với người dùng thông thường và các nhà phát triển, điều này có nghĩa là sau này, bất kể là thực hiện các thao tác gửi tiền, rút tiền hay hợp nhất người xác thực, đều có thể được hoàn thành nhanh chóng và an toàn hơn thông qua một quy trình thống nhất và chuẩn hóa. Điều này không chỉ nâng cao hiệu quả của hệ thống mà còn giúp giảm thiểu rủi ro tổng thể.
EIP-2537: Biên dịch cho các phép toán trên đường cong BLS12–381
Mục đích cốt lõi
Đề xuất này đã thêm chức năng tích hợp (được gọi là hợp đồng biên soạn trước) trong Ethereum, chuyên xử lý các phép toán toán học trên đường cong BLS12–381.
Tại sao cần biên dịch trước cái này
· Tăng cường hiệu suất: Việc thực hiện trực tiếp các phép toán đường cong elip phức tạp (như xác minh chữ ký và tổng hợp) trong hợp đồng thông minh sẽ tiêu tốn rất nhiều gas. Hợp đồng biên dịch trước có thể giảm đáng kể chi phí cho những phép toán này.
· Độ an toàn cao hơn: So với đường cong BN254 hiện tại (độ an toàn khoảng 80 bit), đường cong BLS12–381 cung cấp khoảng 120 bit độ an toàn, làm cho các thao tác mã hóa an toàn hơn.
Mục đích chính
· Xác minh chữ ký BLS: Chữ ký BLS cho phép kết hợp nhiều chữ ký thành một, từ đó giảm đáng kể khối lượng tính toán trong quá trình xác minh.
· Xác minh chứng zkSNARK: Trong một số giải pháp bảo vệ quyền riêng tư và khả năng mở rộng, cần phải xác minh chứng zkSNARK, và các thao tác này cũng phụ thuộc vào các phép toán đường cong elip phức tạp.
ý nghĩa thực tế
Thông qua EIP này, các nhà phát triển có thể sử dụng các phép toán mã hóa liên quan đến đường cong BLS12-381 một cách hiệu quả hơn và với chi phí thấp hơn trong hợp đồng thông minh, từ đó hỗ trợ nhiều ứng dụng đổi mới hơn, chẳng hạn như cơ chế đồng thuận hiệu quả hơn, tương tác giữa các chuỗi và các ứng dụng phi tập trung khác nhau.
Nói ngắn gọn, EIP-2537 được thiết kế để giải quyết vấn đề tiêu tốn quá nhiều gas khi thực hiện các phép toán mã hóa an toàn cao trên chuỗi, thông qua hợp đồng biên dịch trước để làm cho các phép toán phức tạp này trở nên hiệu quả và thực tiễn hơn.
EIP-2935: Lưu trữ hash khối lịch sử trong trạng thái
Vấn đề hiện tại
Trong máy ảo Ethereum (EVM), chỉ có thể truy cập băm của 256 khối gần đây nhất thông qua mã vận hành BLOCKHASH (khoảng 50 phút), điều này không đủ cho một số ứng dụng, chẳng hạn như các ứng dụng liên chuỗi cần chứng minh dữ liệu khối cũ hơn hoặc khách hàng không trạng thái (như rollup).
Cốt lõi của đề xuất
Đề xuất EIP-2935 lưu trữ thêm 8192 hash khối trong trạng thái blockchain (khoảng 27,3 giờ), điều này có thể mở rộng đáng kể phạm vi dữ liệu khối lịch sử có thể truy vấn.
Làm thế nào để thực hiện
Ngoài việc giữ nguyên mã thao tác BLOCKHASH chỉ có thể truy cập 256 khối gần nhất, đề xuất còn giới thiệu một hợp đồng hệ thống mới chuyên dụng:
· set() phương pháp: Khi mỗi khối được xử lý, hợp đồng mới sẽ tự động lưu trữ hàm băm của khối hiện tại vào một bộ đệm vòng.
· get() phương pháp: bất kỳ ai hoặc hợp đồng thông minh nào cũng có thể truy vấn các hash khối lịch sử được lưu trữ trong bộ đệm vòng.
Lợi ích thực tế
Như vậy, các ứng dụng chuỗi chéo, rollup hoặc các hệ thống khác cần truy cập dữ liệu khối trước đó có thể trực tiếp lấy thông tin lịch sử cần thiết trên chuỗi mà không cần phụ thuộc vào dữ liệu bên ngoài, điều này giúp thiết kế của chúng trở nên đơn giản, an toàn và đáng tin cậy hơn.
EIP-7840: Thêm lập lịch blob vào tệp cấu hình EL
Mục đích cốt lõi
Đề xuất này nhằm mục đích ghi lại các tham số quan trọng liên quan đến việc lập lịch blob (chẳng hạn như số lượng blob cho phép mỗi khối và tỷ lệ cập nhật phí cơ bản) vào tệp cấu hình của lớp thực thi (EL).
Cách làm cụ thể
· Thêm cài đặt "Số lượng blob mục tiêu" và "Số lượng blob tối đa" vào tệp cấu hình.
· Đồng thời thêm một tham số gọi là baseFeeUpdateFraction, dùng để điều chỉnh tốc độ cập nhật phí cơ bản.
· Khách hàng có thể truy vấn các tham số này thông qua API nút, từ đó biết được cấu hình cụ thể của blob trong mạng hiện tại.
Tại sao nó lại hữu ích
Thông tin này có thể giúp các nhà phát triển và người vận hành nút ước tính chính xác hơn chi phí blob gas, đồng thời cũng giúp mạng quản lý tốt hơn việc lên lịch và xử lý dữ liệu lớn trong khối.
Nói chung, EIP-7840 đã thêm một bộ tham số lập lịch blob có thể cấu hình cho lớp thực thi Ethereum, giúp mạng trở nên hiệu quả và minh bạch hơn khi xử lý dữ liệu lớn (blob).
EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi chứng minh
Ý tưởng cốt lõi
Hiện tại, thông điệp xác thực bỏ phiếu (Attestation) bao gồm ba phần:
· Bỏ phiếu LMD GHOST (bao gồm gốc khối và khe thời gian)
· Bỏ phiếu Casper-FFG (bao gồm source và target)
· Chỉ số ủy ban (index)
Vấn đề là, chỉ số của ủy ban cũng đã được ký, điều này sẽ dẫn đến việc ngay cả khi nội dung bỏ phiếu giống nhau, nhưng do chỉ số khác nhau, nên các gốc chữ ký được tạo ra cũng sẽ khác nhau. Điều này sẽ khiến cho các phiếu bầu có nội dung giống nhau không thể được tổng hợp lại với nhau.
Giải pháp được đề xuất bởi EIP-7549 là: loại bỏ chỉ mục hội đồng khỏi tin nhắn bỏ phiếu đã được ký. Như vậy, chỉ có nội dung cốt lõi của cuộc bỏ phiếu (bỏ phiếu LMD GHOST và Casper-FFG) sẽ tham gia vào tính toán ký, cho phép nhiều người xác thực có cùng một cuộc bỏ phiếu tạo ra cùng một gốc ký, từ đó có thể được tổng hợp lại.
Lợi ích chính
· Giảm đáng kể khối lượng công việc xác minh: Trong tình huống hiện tại, để đạt được sự đồng thuận 2/3, có thể cần xác minh 1366 phiếu bầu. Sau khi loại bỏ chỉ mục ủy ban, chỉ cần xác minh khoảng 22 phiếu bầu (tiết kiệm khoảng 62 lần khối lượng tính toán), điều này mang lại hiệu quả rất đáng kể cho quá trình xác minh cần nhiều phép toán ghép cặp, đặc biệt là đối với khách hàng Casper FFG dựa trên chứng minh không biết.
· Nâng cao hiệu suất lưu trữ dữ liệu trên chuỗi: Do thông tin bỏ phiếu có thể được tổng hợp hiệu quả hơn, có thể đóng gói nhiều phiếu bầu hơn trong mỗi khối. Hiện tại, một khối chỉ có thể chứa 2 khoảng thời gian bỏ phiếu, sau khi cải tiến có thể đạt tối đa 8 khoảng thời gian bỏ phiếu, ngay cả khi chỉ có 1/8 những người đề xuất trực tuyến, cũng có thể đưa tất cả phiếu bầu vào khối.
Việc loại bỏ chỉ mục ủy ban khỏi thông điệp chứng thực không chỉ có thể giảm đáng kể số lượng phép toán cặp cần xử lý khi xác minh phiếu bầu, mà còn có thể đóng gói dữ liệu phiếu bầu một cách hiệu quả hơn, nâng cao hiệu suất của toàn bộ quá trình xác minh đồng thuận và tỷ lệ sử dụng lưu trữ trên chuỗi. Cải tiến này đặc biệt quan trọng đối với cơ chế đồng thuận Casper FFG và các xác minh chứng minh không kiến thức có liên quan.
Kết luận
Pectra, như một bản nâng cấp bao gồm số lượng EIP kỷ lục, sẽ thúc đẩy Ethereum phát triển trong các lĩnh vực quan trọng như trừu tượng tài khoản, tối ưu hóa cơ chế xác thực viên, nâng cao hiệu quả mạng lưới và mở rộng Layer 2. Đồng thời, như Vitalik Buterin gần đây đã nhấn mạnh, mặc dù Ethereum áp dụng lộ trình mở rộng tập trung vào Rollup, nhưng vẫn đang liên tục tối ưu hóa Layer 1, chẳng hạn như gần đây đã nâng giới hạn Gas lên 36 triệu, và trong tương lai có thể sẽ tiếp tục nâng cao khả năng chống kiểm duyệt, thông lượng và khả năng mở rộng.
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.
Tìm hiểu về nâng cấp Pectra của Ethereum: Phân tích toàn bộ các EIP
Tác giả | Tanay Ved, Coin Metrics
Biên dịch | GaryMa Ngô nói về Blockchain
Ngoài việc biên dịch nguyên văn, bài viết này còn bổ sung giới thiệu các EIP khác của Pectra mà nguyên văn không đề cập.
Liên kết gốc:
Điểm mấu chốt
Pectra là bản nâng cấp quan trọng tiếp theo của Ethereum, liên quan đến những thay đổi ở lớp thực thi (Prague) và lớp đồng thuận (Electra). Sau nhiều lần thử nghiệm với bản nâng cấp Pectra trên mạng thử nghiệm, cuối cùng đã xác định được thời điểm kích hoạt nâng cấp mạng chính Pectra vào khoảng 10:05 UTC ngày 7 tháng 5.
Nâng cấp này sẽ cải thiện đáng kể việc staking, khả năng mở rộng Layer 2 và trải nghiệm người dùng (UX), đồng thời đặt nền tảng cho những thay đổi trong tương lai.
Các thay đổi chính bao gồm: tăng giới hạn staking của các validator, rút tiền staking linh hoạt, tăng cường trừu tượng hóa tài khoản và tăng thông lượng blob để nâng cao hiệu quả và an ninh mạng.
Giới thiệu
Đã 31 tháng kể từ "The Merge", 24 tháng kể từ nâng cấp "Shapella", 13 tháng kể từ nâng cấp "Dencun", Ethereum sắp đón nhận nâng cấp lớn tiếp theo — — hard fork Pectra.
Và trước khi nâng cấp mạng chính Pectra, việc nâng cấp mạng thử nghiệm đã gặp nhiều khó khăn.
Việc nâng cấp Pectra cho testnet Holesky đã được kích hoạt vào ngày 24 tháng 2 lúc 21:55 UTC, nhưng đã bị gián đoạn do cấu hình sai phần mềm máy khách (Geth, Nethermind và Besu có địa chỉ hợp đồng tiền gửi sai), dẫn đến một nhánh chuỗi. Các nhà phát triển đã thảo luận về kế hoạch khôi phục mạng thông qua các sự kiện phạt quy mô lớn, với mục đích đẩy nhanh việc thoát khỏi các trình xác thực lỗi và đạt được tính cuối cùng của mạng cho đến ngày 11 tháng Ba.
Bản nâng cấp Pectra của mạng thử nghiệm Sepolia đã được nâng cấp theo kế hoạch vào ngày 5 tháng 3. Do vấn đề cấu hình hợp đồng gửi tùy chỉnh, một số khách hàng lớp thực thi (EL) đã gặp sự cố khi bao gồm giao dịch trong khối, nhưng vấn đề đã nhanh chóng được khắc phục và mạng đã đạt được độ hoàn thiện.
Vào ngày 19 tháng 3, để kiểm tra việc rút lui của các xác nhận viên, mạng thử nghiệm mới Hoodi đã được ra mắt và đã thành công trong việc kích hoạt nâng cấp mạng Pectra vào ngày 26 tháng 3.
Việc nâng cấp mạng thử nghiệm Pectra của Ethereum đã trải qua hai tháng gian nan, tạo điều kiện cho việc triển khai mạng chính, cuối cùng được xác định sẽ kích hoạt nâng cấp mạng chính Pectra vào khoảng 10:05 UTC ngày 7 tháng 5.
Giống như các bản nâng cấp Ethereum trước đây, Pectra liên quan đến cả lớp thực thi (EL) và lớp đồng thuận (CL). Tên gọi của nó phản ánh trọng tâm kép này: Prague (Praha) đại diện cho bản nâng cấp lớp thực thi, để tưởng nhớ địa điểm tổ chức Devcon 4; Electra (hệ sao Electra) tượng trưng cho bản nâng cấp lớp đồng thuận.
Pectra là một trong những hard fork có số lượng EIP (Ethereum Improvement Proposals, đề xuất cải tiến Ethereum) nhiều nhất trong lịch sử Ethereum với 11 EIPs. Nó được tối ưu hóa thêm dựa trên bản nâng cấp Dencun năm ngoái, nhằm cải thiện trải nghiệm người dùng (UX), tối ưu hóa hoạt động của các validator, và thúc đẩy mở rộng Layer 2, dự kiến sẽ có tác động sâu rộng đến hệ sinh thái Ethereum.
Trong bài viết này, chúng tôi sẽ phân loại theo lĩnh vực của từng EIP và phân tích sâu về từng EIP.
Cải tiến cơ chế xác thực và staking
Pectra tối ưu hóa trải nghiệm hoạt động của các nhà xác thực trong hệ thống PoS của Ethereum thông qua ba EIP chính:
EIP-7251: Tăng tối đa số dư hiệu quả (MaxEB)
Hiện tại, cơ chế staking của Ethereum giới hạn giới hạn staking hiệu quả của một validator đơn lẻ là 32 ETH, điều này có nghĩa là các nhà đầu tư độc lập phải staking theo đơn vị 32 ETH, và phần thưởng vượt quá giới hạn đó sẽ không được tính vào staking hiệu quả.
EIP-7251 đề xuất nâng giới hạn số dư hiệu quả tối đa (MaxEB) lên 2048 ETH, cho phép phạm vi staking của một validator duy nhất mở rộng từ 32 đến 2048 ETH, mang lại các ảnh hưởng bao gồm:
· Tăng tính linh hoạt của việc staking: Người staking có thể tái đầu tư toàn bộ lợi nhuận vào số dư staking hợp lệ mà không bị giới hạn bởi bội số của 32 ETH. Ví dụ, một người xác thực nắm giữ 33 ETH hiện tại có thể nhận thưởng staking cho tất cả 33 ETH, nâng cao hiệu quả và tính linh hoạt của vốn.
· Giảm số lượng người xác thực: Hiện tại Ethereum có 1,05 triệu người xác thực hoạt động, EIP này cho phép các nhà điều hành lớn hợp nhất người xác thực của họ, từ đó giảm tổng số và giảm tải cho mạng.
· Giảm tải mạng: Mặc dù nhiều người xác thực hơn giúp tăng cường tính phi tập trung, nhưng cũng sẽ làm tăng gánh nặng băng thông và tính toán. Tăng MaxEB có thể tối ưu hóa tập hợp người xác thực và giảm chi phí giao tiếp ngang hàng.
EIP-7002: Lớp thực thi có thể kích hoạt rút tiền
EIP-7002 tăng cường chức năng của người xác thực, cho phép họ kích hoạt rút tiền và rút một phần thông qua chứng chỉ rút tiền từ lớp thực thi (0x01).
Hiện tại, các xác thực viên có hai khóa:
Khóa hoạt động, dùng để thực hiện nhiệm vụ xác thực;
Khóa rút tiền, dùng để truy cập và quản lý vốn đặt cược.
Trước đây, chỉ có khóa hoạt động mới có thể kích hoạt việc thoát, trong khi khóa rút tiền không thể tự hoạt động. EIP-7002 cho phép khóa rút tiền cũng có thể kích hoạt việc rút tiền, điều này mang lại:
· Kiểm soát vốn lớn hơn: Người xác thực có thể quản lý trực tiếp vốn mà không cần phụ thuộc vào nhà điều hành nút.
· Hỗ trợ các hồ bơi staking hoàn toàn không tin cậy, nâng cao độ an toàn và mức độ phi tập trung.
EIP-6110: Lưu trữ tiền gửi của người xác thực trên chuỗi
Hiện tại, khi các xác thực viên mới nạp tiền vào lớp thực thi, họ cần phải chờ lớp đồng thuận nhận diện và xử lý, dẫn đến độ trễ kích hoạt.
EIP-6110 cho phép lớp thực thi truyền thông tin gửi tiền trực tiếp đến lớp đồng thuận, giảm bớt các bước xác thực bổ sung, làm cho thời gian kích hoạt của người xác thực từ khoảng 9 giờ giảm xuống còn khoảng 13 phút.
Nâng cao khả năng mở rộng Layer 2: Tăng thông lượng Blob
EIP-7691: Tăng cường khả năng xử lý Blob
Năm ngoái, bản nâng cấp Dencun đã giới thiệu Blobs, như một cách hiệu quả để lưu trữ dữ liệu cho các rollup Layer 2. Hiện tại, mỗi ngày có khoảng 21.000 Blobs được gửi lên Ethereum, nhưng dung lượng đã gần đạt giới hạn, dẫn đến việc phí tăng lên và hạn chế khả năng xử lý.
Hiện tại, số lượng Blob mục tiêu cho mỗi khối Ethereum là 3, tối đa là 6. EIP-7691 đề xuất tăng giá trị mục tiêu lên 6 và giá trị tối đa lên 9, nhằm tăng khả năng lưu trữ dữ liệu, cải thiện thông lượng và khả năng mở rộng. Điều này sẽ giảm chi phí lưu trữ dữ liệu, từ đó giảm phí giao dịch L2.
EIP-7623: Tăng chi phí calldata
Trước khi cơ chế Blob ra mắt, L2 chủ yếu sử dụng calldata để lưu trữ dữ liệu, và trong một số trường hợp vẫn tiếp tục sử dụng vì nó có thể tiết kiệm chi phí hơn.
EIP-7623 tăng phí calldata để khuyến khích L2 sử dụng blob để lưu trữ dữ liệu, từ đó nâng cao hiệu quả giao dịch rollup.
Tăng cường trải nghiệm người dùng (UX)
EIP-7702: Thiết lập mã tài khoản EOA
Ý tưởng cốt lõi: Tạm thời cấp quyền năng hợp đồng thông minh cho EOA
EIP-7702 đã giới thiệu một loại giao dịch hoàn toàn mới (được đánh dấu là 0x04), cho phép tài khoản do bên ngoài sở hữu (EOA) tạm thời có được chức năng của hợp đồng thông minh trong quá trình thực hiện một giao dịch. Nói cách khác, mặc dù truyền thống EOA không có mã và chỉ có thể được sử dụng để ký giao dịch, nhưng thông qua đề xuất này, EOA có thể ‘tải’ một đoạn mã trong một giao dịch, từ đó thực hiện các thao tác phức tạp giống như ví hợp đồng thông minh.
Lợi thế chính
· Gas tài trợ: Cơ chế này còn hỗ trợ các bên thứ ba tài trợ phí giao dịch, cải thiện trải nghiệm người dùng, cho phép người dùng không cần giữ ETH trước đó để thực hiện giao dịch.
· Nâng cao tính an toàn và linh hoạt: Người dùng có thể kiểm soát quyền truy cập giao dịch một cách chi tiết, chẳng hạn như chỉ cho phép các tài khoản con hoạt động trong các điều kiện giới hạn, từ đó nâng cao tính an toàn cho tài khoản.
Có thể gặp phải thách thức
· Vấn đề tương thích sinh thái: Do EOA truyền thống thường được coi là không có mã, một số hợp đồng thông minh hiện có hoặc kiểm tra an toàn (ví dụ require(tx.origin == msg.sender)) có thể cần được điều chỉnh để phù hợp với cơ chế tạm thời gán mã này.
· Sự phức tạp trong cấu trúc giao dịch tăng lên: Việc giới thiệu các loại giao dịch mới sẽ yêu cầu ví và khách hàng phải thực hiện những thay đổi lớn, đảm bảo rằng không có lỗ hổng bảo mật hoặc chi phí cao thêm khi xử lý các bộ quyền mới và thiết lập mã tạm thời.
EIP-7702 cho phép các EOA thông thường tạm thời đạt được chức năng hợp đồng thông minh trong một giao dịch, cho phép giao dịch hàng loạt, tài trợ giao dịch và quản lý quyền linh hoạt hơn. Cơ chế này có thể cải thiện đáng kể trải nghiệm người dùng và mở rộng chức năng của dApps, nhưng nó cũng sẽ phá vỡ một số giả định truyền thống và yêu cầu sự thích ứng và cập nhật của tất cả các bên trong hệ sinh thái. Nhìn chung, đây là một đề xuất quan trọng để mở đường cho việc trừu tượng hóa tài khoản, với mục tiêu làm cho các tài khoản Ethereum trong tương lai vừa an toàn vừa linh hoạt.
Các EIP khác
EIP-7685: Yêu cầu tầng thực thi chung
Bối cảnh và mục đích
Hiện tại, Eth1 (tầng thực thi) và chuỗi tín hiệu (tầng đồng thuận) cần xử lý ba loại yêu cầu chính:
Gửi tiền: Sự kiện gửi tiền do người dùng khởi xướng ban đầu xuất hiện trong khối Eth1, nhưng cuối cùng cần được xử lý trên chuỗi tín hiệu.
Rút tiền: Yêu cầu rút tiền phát sinh từ chuỗi tín hiệu (thường thông qua công cụ dòng lệnh) cần được xử lý trên Eth1.
Hợp nhất người xác thực: Tương tự, yêu cầu này cũng cần được chuyển giao giữa Eth1 và chuỗi tín hiệu.
Tại sao cần đề xuất này
Hiện tại, các loại hoạt động khác nhau được truyền qua lại giữa hai lớp, dễ gây ra sự nhầm lẫn. Khung xử lý thống nhất được đề xuất bởi EIP-7685, nhằm mục đích:
· Xử lý tất cả các yêu cầu này theo một phương pháp tiêu chuẩn, giúp quy trình trở nên rõ ràng hơn và hiệu quả hơn;
· Chỉ dựa vào Eth1 để kích hoạt những thao tác này, từ đó có thể tách biệt môi trường hoạt động của các xác nhận viên và quản lý staking, qua đó nâng cao tính bảo mật.
Nội dung chính
Định danh loại yêu cầu: Đã định nghĩa một định danh cụ thể cho mỗi loại thao tác, chẳng hạn như loại yêu cầu gửi tiền và rút tiền đã có, giờ đây còn phải thêm loại yêu cầu gộp.
Đảm bảo tính toàn vẹn: Sẽ sử dụng một số cơ chế (như kiểm tra băm, dữ liệu Merkle hóa) để đảm bảo tính toàn vẹn và an toàn của dữ liệu yêu cầu.
Xử lý hàng đợi và giới hạn tốc độ: Đối với các yêu cầu đang chờ xử lý, sẽ đặt ra một số giới hạn (chẳng hạn như số lượng yêu cầu gửi tiền, rút tiền hoặc hợp nhất đang chờ cùng một lúc) để ngăn chặn quá tải hệ thống.
ý nghĩa cuối cùng
Đối với người dùng thông thường và các nhà phát triển, điều này có nghĩa là sau này, bất kể là thực hiện các thao tác gửi tiền, rút tiền hay hợp nhất người xác thực, đều có thể được hoàn thành nhanh chóng và an toàn hơn thông qua một quy trình thống nhất và chuẩn hóa. Điều này không chỉ nâng cao hiệu quả của hệ thống mà còn giúp giảm thiểu rủi ro tổng thể.
EIP-2537: Biên dịch cho các phép toán trên đường cong BLS12–381
Mục đích cốt lõi
Đề xuất này đã thêm chức năng tích hợp (được gọi là hợp đồng biên soạn trước) trong Ethereum, chuyên xử lý các phép toán toán học trên đường cong BLS12–381.
Tại sao cần biên dịch trước cái này
· Tăng cường hiệu suất: Việc thực hiện trực tiếp các phép toán đường cong elip phức tạp (như xác minh chữ ký và tổng hợp) trong hợp đồng thông minh sẽ tiêu tốn rất nhiều gas. Hợp đồng biên dịch trước có thể giảm đáng kể chi phí cho những phép toán này.
· Độ an toàn cao hơn: So với đường cong BN254 hiện tại (độ an toàn khoảng 80 bit), đường cong BLS12–381 cung cấp khoảng 120 bit độ an toàn, làm cho các thao tác mã hóa an toàn hơn.
Mục đích chính
· Xác minh chữ ký BLS: Chữ ký BLS cho phép kết hợp nhiều chữ ký thành một, từ đó giảm đáng kể khối lượng tính toán trong quá trình xác minh.
· Xác minh chứng zkSNARK: Trong một số giải pháp bảo vệ quyền riêng tư và khả năng mở rộng, cần phải xác minh chứng zkSNARK, và các thao tác này cũng phụ thuộc vào các phép toán đường cong elip phức tạp.
ý nghĩa thực tế
Thông qua EIP này, các nhà phát triển có thể sử dụng các phép toán mã hóa liên quan đến đường cong BLS12-381 một cách hiệu quả hơn và với chi phí thấp hơn trong hợp đồng thông minh, từ đó hỗ trợ nhiều ứng dụng đổi mới hơn, chẳng hạn như cơ chế đồng thuận hiệu quả hơn, tương tác giữa các chuỗi và các ứng dụng phi tập trung khác nhau.
Nói ngắn gọn, EIP-2537 được thiết kế để giải quyết vấn đề tiêu tốn quá nhiều gas khi thực hiện các phép toán mã hóa an toàn cao trên chuỗi, thông qua hợp đồng biên dịch trước để làm cho các phép toán phức tạp này trở nên hiệu quả và thực tiễn hơn.
EIP-2935: Lưu trữ hash khối lịch sử trong trạng thái
Vấn đề hiện tại
Trong máy ảo Ethereum (EVM), chỉ có thể truy cập băm của 256 khối gần đây nhất thông qua mã vận hành BLOCKHASH (khoảng 50 phút), điều này không đủ cho một số ứng dụng, chẳng hạn như các ứng dụng liên chuỗi cần chứng minh dữ liệu khối cũ hơn hoặc khách hàng không trạng thái (như rollup).
Cốt lõi của đề xuất
Đề xuất EIP-2935 lưu trữ thêm 8192 hash khối trong trạng thái blockchain (khoảng 27,3 giờ), điều này có thể mở rộng đáng kể phạm vi dữ liệu khối lịch sử có thể truy vấn.
Làm thế nào để thực hiện
Ngoài việc giữ nguyên mã thao tác BLOCKHASH chỉ có thể truy cập 256 khối gần nhất, đề xuất còn giới thiệu một hợp đồng hệ thống mới chuyên dụng:
· set() phương pháp: Khi mỗi khối được xử lý, hợp đồng mới sẽ tự động lưu trữ hàm băm của khối hiện tại vào một bộ đệm vòng.
· get() phương pháp: bất kỳ ai hoặc hợp đồng thông minh nào cũng có thể truy vấn các hash khối lịch sử được lưu trữ trong bộ đệm vòng.
Lợi ích thực tế
Như vậy, các ứng dụng chuỗi chéo, rollup hoặc các hệ thống khác cần truy cập dữ liệu khối trước đó có thể trực tiếp lấy thông tin lịch sử cần thiết trên chuỗi mà không cần phụ thuộc vào dữ liệu bên ngoài, điều này giúp thiết kế của chúng trở nên đơn giản, an toàn và đáng tin cậy hơn.
EIP-7840: Thêm lập lịch blob vào tệp cấu hình EL
Mục đích cốt lõi
Đề xuất này nhằm mục đích ghi lại các tham số quan trọng liên quan đến việc lập lịch blob (chẳng hạn như số lượng blob cho phép mỗi khối và tỷ lệ cập nhật phí cơ bản) vào tệp cấu hình của lớp thực thi (EL).
Cách làm cụ thể
· Thêm cài đặt "Số lượng blob mục tiêu" và "Số lượng blob tối đa" vào tệp cấu hình.
· Đồng thời thêm một tham số gọi là baseFeeUpdateFraction, dùng để điều chỉnh tốc độ cập nhật phí cơ bản.
· Khách hàng có thể truy vấn các tham số này thông qua API nút, từ đó biết được cấu hình cụ thể của blob trong mạng hiện tại.
Tại sao nó lại hữu ích
Thông tin này có thể giúp các nhà phát triển và người vận hành nút ước tính chính xác hơn chi phí blob gas, đồng thời cũng giúp mạng quản lý tốt hơn việc lên lịch và xử lý dữ liệu lớn trong khối.
Nói chung, EIP-7840 đã thêm một bộ tham số lập lịch blob có thể cấu hình cho lớp thực thi Ethereum, giúp mạng trở nên hiệu quả và minh bạch hơn khi xử lý dữ liệu lớn (blob).
EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi chứng minh
Ý tưởng cốt lõi
Hiện tại, thông điệp xác thực bỏ phiếu (Attestation) bao gồm ba phần:
· Bỏ phiếu LMD GHOST (bao gồm gốc khối và khe thời gian)
· Bỏ phiếu Casper-FFG (bao gồm source và target)
· Chỉ số ủy ban (index)
Vấn đề là, chỉ số của ủy ban cũng đã được ký, điều này sẽ dẫn đến việc ngay cả khi nội dung bỏ phiếu giống nhau, nhưng do chỉ số khác nhau, nên các gốc chữ ký được tạo ra cũng sẽ khác nhau. Điều này sẽ khiến cho các phiếu bầu có nội dung giống nhau không thể được tổng hợp lại với nhau.
Giải pháp được đề xuất bởi EIP-7549 là: loại bỏ chỉ mục hội đồng khỏi tin nhắn bỏ phiếu đã được ký. Như vậy, chỉ có nội dung cốt lõi của cuộc bỏ phiếu (bỏ phiếu LMD GHOST và Casper-FFG) sẽ tham gia vào tính toán ký, cho phép nhiều người xác thực có cùng một cuộc bỏ phiếu tạo ra cùng một gốc ký, từ đó có thể được tổng hợp lại.
Lợi ích chính
· Giảm đáng kể khối lượng công việc xác minh: Trong tình huống hiện tại, để đạt được sự đồng thuận 2/3, có thể cần xác minh 1366 phiếu bầu. Sau khi loại bỏ chỉ mục ủy ban, chỉ cần xác minh khoảng 22 phiếu bầu (tiết kiệm khoảng 62 lần khối lượng tính toán), điều này mang lại hiệu quả rất đáng kể cho quá trình xác minh cần nhiều phép toán ghép cặp, đặc biệt là đối với khách hàng Casper FFG dựa trên chứng minh không biết.
· Nâng cao hiệu suất lưu trữ dữ liệu trên chuỗi: Do thông tin bỏ phiếu có thể được tổng hợp hiệu quả hơn, có thể đóng gói nhiều phiếu bầu hơn trong mỗi khối. Hiện tại, một khối chỉ có thể chứa 2 khoảng thời gian bỏ phiếu, sau khi cải tiến có thể đạt tối đa 8 khoảng thời gian bỏ phiếu, ngay cả khi chỉ có 1/8 những người đề xuất trực tuyến, cũng có thể đưa tất cả phiếu bầu vào khối.
Việc loại bỏ chỉ mục ủy ban khỏi thông điệp chứng thực không chỉ có thể giảm đáng kể số lượng phép toán cặp cần xử lý khi xác minh phiếu bầu, mà còn có thể đóng gói dữ liệu phiếu bầu một cách hiệu quả hơn, nâng cao hiệu suất của toàn bộ quá trình xác minh đồng thuận và tỷ lệ sử dụng lưu trữ trên chuỗi. Cải tiến này đặc biệt quan trọng đối với cơ chế đồng thuận Casper FFG và các xác minh chứng minh không kiến thức có liên quan.
Kết luận
Pectra, như một bản nâng cấp bao gồm số lượng EIP kỷ lục, sẽ thúc đẩy Ethereum phát triển trong các lĩnh vực quan trọng như trừu tượng tài khoản, tối ưu hóa cơ chế xác thực viên, nâng cao hiệu quả mạng lưới và mở rộng Layer 2. Đồng thời, như Vitalik Buterin gần đây đã nhấn mạnh, mặc dù Ethereum áp dụng lộ trình mở rộng tập trung vào Rollup, nhưng vẫn đang liên tục tối ưu hóa Layer 1, chẳng hạn như gần đây đã nâng giới hạn Gas lên 36 triệu, và trong tương lai có thể sẽ tiếp tục nâng cao khả năng chống kiểm duyệt, thông lượng và khả năng mở rộng.
Liên kết tham khảo: