Một bài viết để hiểu về việc nâng cấp Ethereum Pectra: Phân tích đầy đủ các EIPs

?

Bản gốc: Pectra: Cập nhật lớn tiếp theo của Ethereum

Tác giả: Tanay Ved, Coin Metrics

Biên dịch: GaryMa, 吴说区块链

Ngoài việc biên dịch bản gốc, bài viết này còn bổ sung giới thiệu về các EIP khác của Pectra mà bản gốc không đề cập.

Điểm chính

Pectra là bản nâng cấp lớn tiếp theo của Ethereum, liên quan đến sự thay đổi của lớp thực thi (Prague) và lớp đồng thuận (Electra). Sau nhiều lần thử nghiệm nâng cấp mạng thử nghiệm Pectra, cuối cùng đã xác định được thời gian 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ể về 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 linh hoạt, cải thiện trừu tượng 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", và 13 tháng kể từ nâng cấp "Dencun", Ethereum sắp đón nhận bản nâng cấp lớn tiếp theo --- --- hard fork Pectra.

Trước khi nâng cấp mạng chính Pectra, việc nâng cấp mạng thử nghiệm đã trải qua nhiều khó khăn.

Nâng cấp Pectra trên mạng thử nghiệm Holesky đã được kích hoạt vào lúc 21:55 UTC ngày 24 tháng 2, nhưng đã bị gián đoạn do lỗi cấu hình phần mềm khách hàng (địa chỉ hợp đồng gửi tiền của Geth, Nethermind và Besu bị sai), dẫn đến phân nhánh chuỗi. Các nhà phát triển đã thảo luận về kế hoạch phục hồi mạng thông qua sự kiện phạt quy mô lớn, nhằm tăng tốc độ thoát của các validator lỗi và đạt được tính xác định cuối cùng của mạng, cho đến ngày 11 tháng 3 mới có thể hoàn tất.

Nâng cấp Pectra trên mạng thử nghiệm Sepolia đã được thực hiện theo kế hoạch vào ngày 5 tháng 3, nhưng do vấn đề cấu hình hợp đồng gửi tiền tùy chỉnh đã khiến 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, tuy nhiên vấn đề đã nhanh chóng được khắc phục và mạng đã đạt được tính xác định cuối cùng.

Vào ngày 19 tháng 3, để thử nghiệm việc thoát của các validator, mạng thử nghiệm mới Hoodi đã được ra mắt và đã thành công kích hoạt nâng cấp mạng Pectra vào ngày 26 tháng 3.

Nâng cấp mạng thử nghiệm Pectra của Ethereum đã trải qua hai tháng khó khăn, mở đường cho việc triển khai mạng chính, cuối cùng đã xác định được thời gian 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 nâng cấp Ethereum trước đây, Pectra cũng liên quan đến lớp thực thi (EL) và lớp đồng thuận (CL). Tên của nó phản ánh trọng tâm kép này: Prague (Praha) đại diện cho nâng cấp lớp thực thi, để tưởng nhớ địa điểm tổ chức Devcon 4; Electra (Sao Electra) tượng trưng cho 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 (11 EIPs). Nó tối ưu hóa dựa trê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 các EIP.

Cải tiến cho validator và cơ chế staking

Pectra tối ưu hóa trải nghiệm hoạt động của các validator trong hệ thống PoS của Ethereum thông qua ba EIP chính:

EIP-7251: Tăng giới hạn số dư hiệu quả tối đa (MaxEB)

Hiện tại, cơ chế staking của Ethereum giới hạn số dư hiệu quả tối đa của một validator 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 này sẽ không được tính vào số dư hiệu quả.

EIP-7251 đề xuất tă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 mở rộng từ 32 đến 2048 ETH, mang lại các tác động bao gồm:

· Tăng tính linh hoạt trong staking: Các nhà đầu tư có thể tái đầu tư tất cả lợi nhuận vào số dư staking hiệu quả mà không bị giới hạn bởi bội số của 32 ETH. Ví dụ, một validator nắm giữ 33 ETH, giờ đây tất cả 33 ETH đều có thể nhận phần thưởng staking, nâng cao hiệu quả và tính linh hoạt của vốn.

· Giảm số lượng validator: Hiện tại, Ethereum có tổng cộng 1,05 triệu validator hoạt động, EIP này cho phép các nhà điều hành lớn hợp nhất các validator của họ, từ đó giảm tổng số và giảm tải cho mạng.

· Giảm tải cho mạng: Mặc dù có nhiều validator giúp tăng cường phân quyền, nhưng cũng sẽ làm tăng băng thông và tải tính toán. Tăng MaxEB có thể tối ưu hóa tập hợp các validator, giảm chi phí giao tiếp điểm-điểm.

EIP-7002: Rút tiền có thể kích hoạt từ lớp thực thi

EIP-7002 tăng cường thêm chức năng cho các validator, cho phép họ kích hoạt việc thoát và rút tiền 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 validator có hai khóa:

1. Khóa hoạt động, dùng để thực hiện các nhiệm vụ xác thực;

2. Khóa rút tiền, dùng để truy cập và quản lý vốn staking.

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ự động 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, mang lại:

· Quyền kiểm soát vốn lớn hơn: Các validator 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 pool staking hoàn toàn không cần tin cậy, nâng cao tính an toàn và mức độ phân quyền.

EIP-6110: Lưu trữ tiền gửi của validator trên chuỗi

Hiện tại, khi các validator mới gửi tiền trên lớp thực thi, họ cần chờ lớp đồng thuận nhận diện và xử lý, dẫn đến sự chậm trễ trong việc kích hoạt.

EIP-6110 cho phép lớp thực thi truyền trực tiếp thông tin gửi tiền đến lớp đồng thuận, giảm bớt các bước xác thực bổ sung, rút ngắn thời gian kích hoạt của các validator từ khoảng 9 giờ 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 thông lượng Blob

Nâng cấp Dencun năm ngoái đã giới thiệu Blobs, như một cách hiệu quả để lưu trữ dữ liệu cho Layer 2 rollups. 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 tăng phí và hạn chế thông lượng.

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 dung lượ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 chi phí calldata để khuyến khích L2 chủ yếu sử dụng blob để lưu trữ dữ liệu, từ đó nâng cao hiệu quả giao dịch rollup.

Cải thiện trải nghiệm người dùng (UX)

EIP-7702: Thiết lập mã tài khoản EOA

Ý tưởng chính: Tạm thời cấp quyền cho EOA khả năng hợp đồng thông minh

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 sở hữu bên ngoài (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. Điều này có nghĩa là, mặc dù EOA truyền thống 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 như ví hợp đồng thông minh.

Lợi ích chính

1. Thao tác hàng loạt: Người dùng có thể hoàn thành nhiều thao tác trong một giao dịch (ví dụ: kết hợp approve + deposit), tránh vấn đề không hiệu quả khi cần nhiều giao dịch.

· Tài trợ Gas: Cơ chế này cũng hỗ trợ 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 phải có ETH trước để thực hiện giao dịch.

· Tăng cường an toàn và tính 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 tài khoản con thực hiện thao tác trong các điều kiện nhất định, nâng cao tính an toàn của tài khoản.

Những thách thức có thể gặp phải

· Vấn đề tương thích hệ sinh thái: Do EOA truyền thống được coi là không có mã, một số hợp đồng thông minh hiện tại hoặc kiểm tra an toàn (ví dụ: require(tx.origin == msg.sender)) có thể cần điều chỉnh để phù hợp với cơ chế cấp quyền tạm thời này.

· Tăng độ phức tạp của cấu trúc giao dịch: Việc giới thiệu loại giao dịch mới sẽ yêu cầu ví và khách hàng cần thực hiện những thay đổi lớn, đảm bảo không xuất hiện lỗ hổng an toàn hoặc chi phí cao 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 EOA thông thường tạm thời có được chức năng hợp đồng thông minh trong một giao dịch, từ đó hỗ trợ 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 dApp, nhưng cũng sẽ phá vỡ một số giả định truyền thống, cần sự thích ứng và cập nhật từ các bên trong hệ sinh thái. Tổng thể, đây là một đề xuất quan trọng để tạo điều kiện cho trừu tượng tài khoản, với mục tiêu là làm cho các tài khoản Ethereum trong tương lai vừa an toàn vừa linh hoạt hơn.

Các EIP khác

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

Bối cảnh và mục đích

Hiện tại, Eth1 (lớp thực thi) và chuỗi beacon (lớp đồng thuận) cần xử lý ba loại yêu cầu chính:

1. Gửi tiền: Các 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 beacon.

2. Rút tiền: Các yêu cầu rút tiền phát sinh từ chuỗi beacon (thường thông qua công cụ dòng lệnh) cần được xử lý trên Eth1.

3. Hợp nhất validator: Tương tự, yêu cầu này cũng cần được truyền giữa Eth1 và chuỗi beacon.

Tại sao cần đề xuất này

Hiện tại, các loại thao tác 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 mà EIP-7685 đề xuất nhằm:

· Sử dụng một phương pháp tiêu chuẩn để xử lý tất cả các yêu cầu này, làm cho quy trình rõ ràng hơn và hiệu quả hơn;

· Chỉ dựa vào Eth1 để kích hoạt các thao tác này, từ đó tách biệt môi trường hoạt động của các validator và quản lý staking, nâng cao tính an toàn.

Nội dung chính

1. Nhận diện loại yêu cầu: Định nghĩa một nhận diện cụ thể cho mỗi loại thao tác, chẳng hạn như các loại yêu cầu gửi tiền và rút tiền hiện có, giờ đây còn cần thêm loại yêu cầu hợp nhất.

2. Đảm bảo tính toàn vẹn: Sẽ áp 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.

3. Hàng đợi xử lý và giới hạn tốc độ: Đặt ra một số giới hạn cho các yêu cầu đang chờ xử lý (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ờ) để ngăn ngừa 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à khởi xướng gửi tiền, rút tiền hay hợp nhất validator, đều có thể 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, tiêu 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 trước cho các phép toán trên đường cong BLS12--381

Mục tiêu chính

Đề xuất này thêm chức năng tích hợp (được gọi là hợp đồng biên dịch trước) vào 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 này

· Tăng hiệu suất: Việc thực hiện các phép toán phức tạp trên đường cong elip (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 hơn: So với đường cong BN254 hiện tại (có độ an toàn khoảng 80 bit), đường cong BLS12--381 cung cấp khoảng 120 bit an toàn hơn, làm cho các phép toán mã hóa an toàn hơn.

Công dụng chính

· Xác minh chữ ký BLS: Chữ ký BLS cho phép tổng hợp nhiều chữ ký thành một, từ đó giảm đáng kể khối lượng tính toán khi 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 xác minh chứng zkSNARK, và những thao tác này cũng phụ thuộc vào các phép toán phức tạp trên đường cong elip.

Ý 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ả và tiết kiệm chi phí 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 tóm lại, EIP-2537 nhằm 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 có độ an toàn cao trên chuỗi, thông qua hợp đồng biên dịch trước để làm cho những 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ữ băm khối lịch sử trong trạng thái

Vấn đề hiện tại

Trong máy ảo Ethereum (EVM), thông qua mã thao tác BLOCKHASH chỉ có thể tra cứu băm của 256 khối gần nhất (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 sớm hơn hoặc các khách hàng không trạng thái (như rollup).

Cốt lõi của đề xuất

EIP-2935 đề xuất lưu trữ thêm 8192 băm khối trong trạng thái của chuỗi (khoảng 27,3 giờ), từ đó mở rộng đáng kể phạm vi dữ liệu khối lịch sử có thể tra cứu.

Cách thực hiện

Ngoài việc giữ nguyên mã thao tác BLOCKHASH hiện tại chỉ có thể truy cập 256 khối gần nhất, đề xuất còn sẽ giới thiệu một hợp đồng hệ thống mới chuyên dụng:

· Phương thức set(): Khi mỗi khối được xử lý, hợp đồng mới sẽ tự động lưu trữ băm của khối hiện tại vào một bộ đệm vòng.

· Phương thức get(): Bất kỳ ai hoặc hợp đồng thông minh nào cũng có thể tra cứu băm khối lịch sử được lưu trữ trong bộ đệm vòng thông qua phương thức này.

Lợi ích thực tế

Như vậy, các ứng dụng liên chuỗi, rollup hoặc các hệ thống khác cần truy cập dữ liệu khối sớm hơn 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, làm cho 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 tiêu chính

Đề xuất này nhằm đưa các tham số quan trọng liên quan đến lập lịch blob (chẳng hạn như số lượng blob cho phép trong 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 thực hiện 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.

· Các khách hàng có thể tra cứu các tham số này thông qua API nút, từ đó biết được cấu hình cụ thể của mạng đối với blob.

Tại sao điều này hữu ích

Thông tin này có thể giúp các nhà phát triển và nhà điều hành nút ước lượng chính xác hơn về phí gas của blob, cũng như giúp mạng quản lý tốt hơn việc lập lịch và xử lý dữ liệu lớn trong khối.

Tổng thể, EIP-7840 đã bổ sung một bộ tham số lập lịch blob có thể cấu hình cho lớp thực thi của Ethereum, giúp mạng xử lý dữ liệu lớn (blob) một cách hiệu quả và minh bạch hơn.

EIP-7549: Di chuyển chỉ mục ủy ban ra khỏi chứng thực

Ý tưởng chính

Hiện tại, thông điệp bỏ phiếu xác thực (Attestation) bao gồm ba phần:

· Bỏ phiếu LMD GHOST (bao gồm gốc khối và khoảng thời gian)

· Bỏ phiếu Casper-FFG (bao gồm nguồn và mục tiêu)

· Chỉ mục ủy ban (index)

Vấn đề là, chỉ mục ủy ban cũng được ký, điều này dẫn đến việc ngay cả khi nội dung bỏ phiếu giống nhau, nhưng do chỉ mục khác nhau, gốc chữ ký được tạo ra cũng khác nhau. Điều này sẽ khiến cho các phiếu bầu có cùng nội dung không thể được tổng hợp lại với nhau.

Giải pháp mà EIP-7549 đề xuất là: loại bỏ chỉ mục ủy ban khỏi thông điệp bỏ phiếu được ký. Như vậy, chỉ có nội dung cốt lõi của 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 validator có cùng bỏ phiếu tạo ra cùng một gốc chữ ký, từ đó có thể tổng hợp lại với nhau.

Lợi ích chính

· Giảm đáng kể khối lượng công việc xác thực: Trong trường hợp hiện tại, để đạt được sự đồng thuận 2/3, có thể cần xác thực 1366 phiếu bầu. Sau khi loại bỏ chỉ mục ủy ban, chỉ cần xác thực 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 suất rất đáng kể cho quy trình xác thực cần nhiều phép toán ghép cặp, đặc biệt là đối với các khách hàng Casper FFG dựa trên chứng minh không kiến thức.

· Tăng cường hiệu quả 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 phiếu bầu của 2 khoảng thời gian, nhưng sau cải tiến có thể đạt tối đa 8 khoảng thời gian, ngay cả khi chỉ có 1/8 người đề xuất trực tuyến, vẫn có thể bao gồm tất cả phiếu bầu trong khối.

Bằng cách loại bỏ chỉ mục ủy ban khỏi thông điệp Attestation, không chỉ có thể giảm đáng kể số lượng phép toán ghép cặp cần xử lý khi xác thực 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ộ quy trình xác thực đồng thuận và hiệu quả 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 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 hướng quan trọng như trừu tượng tài khoản, tối ưu hóa cơ chế validator, nâng cao hiệu quả mạng và mở rộng Layer 2. Đồng thời, như Vitalik Buterin đã nhấn mạnh gần đây, mặc dù Ethereum áp dụng lộ trình mở rộng dựa trên Rollup, nhưng vẫn đang tiếp 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:

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7600.md