Giới thiệu nội dung hard fork Ethereum Dencun

Dencun bao gồm hai tên Deneb và Cancun, đại diện cho hard fork của lớp đồng thuận Ethereum và lớp thực thi tương ứng. Hard fork Dencun đã được hoàn thành trên các mạng thử nghiệm Goerli, Sepolia và Holesky, và mạng chính sẽ được ra mắt vào Kỷ nguyên 269568 (khoảng ngày 13 tháng 3 năm 2024).

Mẹo đọc

Trước khi đọc bài viết này, bạn cần cần biết Kiến thức tiên quyết bao gồm:

• Hard fork

< li >

Ethereum được chia thành Lớp đồng thuận và Lớp thực thi

Nâng cấp Dencun bao gồm 9 EIP, đó là:

• EIP- 1153: Opcode lưu trữ tạm thời (thay đổi lớp thực thi )

• EIP-4788: Gốc khối báo hiệu trong EVM (lớp thực thi và lớp đồng thuận) Thay đổi)

• EIP-4844: Giao dịch Shard Blob (Thay đổi lớp thực thi và lớp đồng thuận)

< li>

EIP-5656: MCOPY - Hướng dẫn sao chép bộ nhớ (thay đổi lớp thực thi)

• EIP-6780: SELFDESTRUCT chỉ trong cùng một giao dịch (thay đổi lớp thực thi)

• EIP-7044: Thoát tự nguyện có chữ ký hợp lệ vĩnh viễn (thay đổi lớp đồng thuận)

• EIP-7045: Tăng khe cắm bao gồm chứng thực tối đa (Thay đổi lớp đồng thuận)

• EIP-7514: Thêm giới hạn khuấy trộn kỷ nguyên tối đa (thay đổi lớp đồng thuận)

• EIP-7516 : Opcode BLOBBASEFEE (thay đổi lớp thực thi)

Bài viết này sẽ giới thiệu những thay đổi và tác động của EIP (không bao gồm EIP-4844). phần giới thiệu về EIP-4844, vui lòng tham khảo:

Bài đăng quan trọng của Rollup: Proto-Danksharding (1)

• https://medium.com/taipei-ethereum-meetup/rollup- and-the-boost-from-proto-danksharding -85d2fe0566b6

Bài đăng lớn của Rollup: Proto- Danksharding (2)

• https://medium.com/taipei-ethereum -meetup/rollup-proto-danksharding-implementation-detail- 913a3c61fde8

Phần giới thiệu và trình tự sau sẽ đại khái Nó được chia thành "EIP liên quan đến thay đổi lớp thực thi" , "EIP liên quan đến thay đổi lớp đồng thuận" và "EIP liên quan đến EIP-4844".

EIP-1153

• Thay đổi lớp thực thi

• EIP-1153: Mã hoạt động lưu trữ tạm thời

• https://eips. ethereum.org/EIPS/eip-1153

• EIP-1153:  trang người hâm mộ< /p>

• https://www.eip1153.com/

• EIP-1153: Mã hoạt động lưu trữ tạm thời< /p>

• https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

EIP-1153 bổ sung hai Opcode mới: TSTORE và TLOAD, được sử dụng để ghi và đọc dữ liệu lưu trữ "tạm thời". Họ sẽ tiết kiệm cho nhiều nhà phát triển hợp đồng rất nhiều chi phí gas.

Nền

Bộ nhớ đề cập đến hợp đồng thông minh thông qua The SSTORE Opcode ghi dữ liệu vào không gian lưu trữ của hợp đồng, dữ liệu sau khi được ghi sẽ tồn tại vĩnh viễn cho đến khi hợp đồng chủ động xóa dữ liệu. Đặc tính "tạm thời" được so sánh với "tồn tại vĩnh viễn", dữ liệu do TSTORE ghi chỉ có hiệu lực cho đến khi kết thúc giao dịch, sau khi giao dịch được thực hiện, giá trị do TSTORE ghi sẽ bị loại bỏ.

Chi tiết hoạt động

TSTORE rất rẻ so với SSTORE Có rất nhiều và thời hạn hiệu lực của nó có thể kéo dài các cuộc gọi giữa các hợp đồng khác nhau (cho đến khi kết thúc giao dịch).Không giống như Bộ nhớ, mặc dù giá rẻ nhưng giá trị trong Bộ nhớ là độc quyền cho từng hợp đồng.Hợp đồng A không thể đọc Bộ nhớ của Hợp đồng B. . Điều này rất hữu ích cho nhiều mục đích:

1. Khóa Reentrancy. Hiện tại, Reentrancy Lock chỉ có thể mô phỏng với SSTORE.Mặc dù các quy tắc của SSTORE đã giảm rất nhiều chi phí gas cho các mục đích sử dụng như Reentrancy Lock sau khi vượt qua EIP-2200, nhưng TSTORE có thể giảm đáng kể chi phí: từ 5000 xuống 100.

2. ERC-20 phê duyệt được sử dụng trong một giao dịch. Nếu hợp đồng A tương tác với hợp đồng B và hợp đồng A cần chuyển ERC-20 từ hợp đồng B, trước tiên hợp đồng B sẽ phê duyệt ERC-20 cho hợp đồng A và sau đó gọi hợp đồng A. Do việc phê duyệt ERC-20 được thực hiện thông qua SSTORE nên chi phí không thấp, việc chuyển sang sử dụng TSTORE sẽ giảm chi phí đáng kể.

3. Các tham số triển khai khi triển khai hợp đồng thông qua CREATE2. Vì các tham số của Constructor sẽ ảnh hưởng đến địa chỉ hợp đồng do CREATE2 triển khai nên nếu bạn không muốn bị ảnh hưởng bởi các tham số của Constructor thì hợp đồng Constructor sẽ được thiết kế để đọc các tham số từ Storage của hợp đồng người triển khai, chẳng hạn như Pool của Uniswap V3. Thông qua TSTORE, mô hình này có thể tiết kiệm được rất nhiều chi phí.

Ghi chú

• Khi các nhà phát triển hợp đồng sử dụng TSTORE để viết lại Khóa Reentrancy của riêng họ, hãy nhớ xóa Khóa khi đến lúc xóa nó và đừng xóa nó muốn nói về các giao dịch Nó sẽ tự xóa sau khi hoàn thành nên có thể tiết kiệm lượng gas tiêu thụ của việc thanh toán bù trừ. Nếu không, nếu bạn cần nhập lại hợp đồng trong quá trình giao dịch, bạn có thể không vào được vì không có Khóa đã mở khóa (không bị xóa).

• EIP-1153 đã được ra mắt trong phiên bản Solidity 0.8.24 và các nhà phát triển có thể dùng thử trước. Đây là ví dụ về Mutex do nhà phát triển triển khai. Uniswap V4, dựa trên TSTORE, cũng sẽ trực tuyến sau khi quá trình nâng cấp Dencun hoàn tất.

• EIP này thêm Opcode mới, vì vậy nếu nhà phát triển muốn triển khai hợp đồng cho nhiều chuỗi, vui lòng hãy chú ý xem tất cả các chuỗi có hỗ trợ Opcode mới nhất hay không, nếu không sẽ không sử dụng được.

EIP-4788

• Thay đổi lớp thực thi

• EIP-4788: Khối báo hiệu root trong EVM

• https://eips.ethereum.org/EIPS/eip-4788

• EIP-4788: Gốc báo hiệu trong EVM

• https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281

EIP-4788 thêm hợp đồng BEACON_ROOTS_ADDRESS cho phép mọi người đọc dữ liệu của khối lớp đồng thuận, tức là lớp thực thi sẽ có thể đọc được lớp đồng thuận Dữ liệu. Thông qua hợp đồng này, các giao thức Đặt cược và Đặt lại có thể đọc và sử dụng dữ liệu lớp đồng thuận mà không cần tin tưởng bất kỳ bên thứ ba nào, chẳng hạn như đọc trạng thái của một trình xác thực nhất định.

Chi tiết hoạt động

Người dùng hoặc hợp đồng có thể chuyển Gọi hợp đồng để truy vấn gốc khối lớp đồng thuận (Beacon Block Root) tại một thời điểm nhất định. Khối gốc giống như giá trị băm của nội dung khối (Beacon Block Hash), là gốc của Merkle Tree (Merkle Tree Root) thu được bằng cách mã hóa SSZ của nội dung khối. Người gọi mã hóa timestamp (dấu thời gian) thành giá trị uint256 và sử dụng nó làm nội dung cuộc gọi, Contract sẽ sử dụng timestamp để tìm root khối lớp đồng thuận tương ứng trong Storage và trả về.

Nếu nhà phát triển muốn sử dụng thông tin lớp đồng thuận, hợp đồng của anh ta sẽ truy vấn gốc khối của khối lớp đồng thuận mà anh ta muốn đọc qua hợp đồng BEACON_ROOTS_ADDRESS. Sau đó, nó được kết hợp với thông tin của khối lớp đồng thuận (chẳng hạn như số dư của một trình xác thực nhất định) và Merkle Proof để xác minh xem thông tin có thuộc về gốc của khối hay không. (SSZ chuyển tất cả nội dung thành Merkle Tree nên mọi thông tin trong nội dung đều có thể tạo Merkle Proof tương ứng để xác minh rằng thông tin đó tồn tại trong nội dung.)



△ Người dùng cung cấp Bằng chứng Merkle và khối lớp đồng thuận Dấu thời gian



△ Bằng chứng Merkle được sử dụng với truy vấn gốc khối để xác minh số dư của trình xác thực tại một thời điểm nhất định

Tuy nhiên, gốc khối lớp đồng thuận được lưu trữ trong hợp đồng BEACON_ROOTS_ADDRESS thực sự là Nó là khối gốc của khối "mẹ" (nghĩa là khối trước đó), không phải khối gốc của cùng khối với lớp thực thi.



△ Dấu thời gian của Khối 11001 (1234567) tương ứng với gốc khối của Khối 11000. Tương tự, dấu thời gian của Khối 11000 (1234555) tương ứng với gốc khối của Khối 10999.

Ghi chú

BEACON_ROOTS_ADDRESS có thể lưu trữ tới 8191 mục trong hợp đồng Lớp đồng thuận khối gốc, 8191 gốc khối trước đó sẽ bị ghi đè. Ví dụ: giả sử đó là Khối 18191, gốc khối có thể được truy cập vào lúc này sẽ nằm trong khoảng từ Khối 10000 đến Khối 18190.

EIP-5656

• Thay đổi lớp thực thi

• EIP-5656: MCOPY - Hướng dẫn sao chép bộ nhớ

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-5656

EIP-5656 Thêm mới một MCOPY Opcode được sử dụng đặc biệt để sao chép giá trị được lưu trong Bộ nhớ trong quá trình thực hiện hợp đồng. Các hợp đồng sẽ được hưởng lợi từ việc tiết kiệm chi phí gas của Opcode này.

Nếu nhà phát triển hợp đồng muốn sử dụng MCOPY Opcode, họ cần chỉ định phiên bản trình biên dịch là 0.8.24 (hoặc cao hơn) và phiên bản EVM là Cancun:



△ Để sử dụng MCOPY, bạn cần đặt phiên bản trình biên dịch và phiên bản EVM

Lưu ý: Phiên bản trình biên dịch 0.8.24 chỉ cho phép sử dụng MCOPY thông qua Assembly ( mcopy(), link), các phiên bản trong tương lai sẽ tự động cho phép trình biên dịch áp dụng MCOPY khi cần sao chép Bộ nhớ.

Ghi chú

EIP này thêm một Opcode mới , vì vậy nếu các nhà phát triển muốn triển khai hợp đồng trên nhiều chuỗi, họ phải chú ý xem liệu tất cả các chuỗi có hỗ trợ Opcode mới nhất hay không, nếu không sẽ không sử dụng được.

EIP-6780

• Thay đổi lớp thực thi

• EIP-6780: SELFDESTRUCT chỉ trong cùng một giao dịch

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-6780

• EIP-6780: Vô hiệu hóa SELFDESTRUCT, ngoại trừ trường hợp nó xảy ra trong cùng một giao dịch trong đó hợp đồng được tạo

• < p style="text-align: left;">https://ethereum-magicians.org/t/eip-6780-deactivate-selfdstruct-Exception-where-it-occurs-in-the-same-transaction -in-which-a-contract-was-created/13539

EIP-6780 Đã sửa đổi hành vi của Opcode SELFDESTRUCT để chuẩn bị cho Verkle Tree và loại bỏ Opcode SELFDESTRUCT. Các nhà phát triển có hợp đồng sử dụng Opcode SELFDESTRUCT cần đặc biệt chú ý.

Nền

SELFDESTRUCT Hành vi hiện tại của Opcode là : ( 1) Xóa mã và lưu trữ hợp đồng và (2) chuyển tất cả ETH trên người bạn đến địa chỉ được chỉ định.

Opcode SELFDESTRUCT ban đầu được thiết kế với cơ chế Hoàn tiền nhằm khuyến khích các nhà phát triển loại bỏ các hợp đồng và dung lượng lưu trữ không sử dụng để giúp duy trì trạng thái Ethereum ở kích thước phù hợp. Nhưng không có nhiều người thực sự làm điều này. Thay vào đó, những sự cố như Parity Multisig đã khiến hàng trăm nghìn ETH bị đóng băng do SELFDESTRUCT. Do đó, cộng đồng Ethereum hy vọng sẽ dần dần loại bỏ Opcode SELFDESTRUCT. Trước đây đã có nhiều đề xuất sửa đổi hoặc loại bỏ Opcode SELFDESTRUCT và EIP-6780 là một trong số đó và cuối cùng đã được đưa vào hard fork Dencun.

Lưu ý: Trong đợt hard fork Thượng Hải vào đầu năm 2023, EIP-6049 đã chính thức thông báo rằng SELFDESTRUCT sẽ bị loại bỏ.

Verkle Tree là cấu trúc lưu trữ trạng thái hiện đang được cộng đồng Ethereum tích cực nghiên cứu và phát triển và sẽ được sử dụng để thay thế Merkle Patricia Tree hiện tại. Verkle Tree sẽ làm cho kích thước bằng chứng của trạng thái Ethereum nhỏ hơn và do đó đóng vai trò quan trọng trong thiết kế của Stateless Client. Với Stateless Client, phần cứng của các nút sẽ được giảm bớt, cho phép nhiều người chạy các nút hơn với phần cứng nhẹ hơn và rẻ hơn, cải thiện tính phân cấp của mạng.

Chi tiết hoạt động

Sau EIP-6780, SELFDESTRUCT Opcode sẽ loại bỏ hành vi của (1) và chỉ giữ lại chức năng (2) "chuyển tất cả ETH của bạn đến địa chỉ được chỉ định". Mã và Bộ nhớ của hợp đồng sẽ không thay đổi trừ khi hợp đồng được tạo trong cùng một giao dịch và sau đó SELFDESTRUCT được thực hiện.

Vì vậy, khi SELFDESTRUCT được kích hoạt:

• Nếu hợp đồng không được tạo trong cùng một giao dịch, mã và lưu trữ của hợp đồng sẽ không thay đổi, nhưng tất cả ETH trên đó sẽ được chuyển đến địa chỉ được chỉ định.

• Nếu hợp đồng được tạo trong cùng một giao dịch thì hành vi vẫn giống như trước (trước EIP-6780 ) giống nhau: mã hợp đồng và Kho lưu trữ sẽ bị xóa và ETH sẽ được chuyển đến địa chỉ được chỉ định.

Đối với Verkle Tree, hành vi của (1) phải được loại bỏ

Trong thiết kế của Verkle Tree, cách lưu trữ trạng thái của nó khác với Merkle Patricia Tree. Trạng thái lưu trữ của Cây Merkle Patricia có thể được hình dung dưới dạng cấu trúc hai lớp (cây trong cây): lớp đầu tiên là một cây bao gồm tất cả các địa chỉ, lớp thứ hai là một cây bao gồm tất cả các kho lưu trữ của mỗi địa chỉ; và Verkle Cây có thể được tưởng tượng như một cấu trúc một tầng, hoàn toàn bằng phẳng. Do đó, trong Merkle Patricia Tree chúng ta có thể dễ dàng xác định vị trí Storage của một địa chỉ và xóa nó, nhưng trong Verkle Tree gần như không thể xác định được Storage của một địa chỉ vì tất cả các địa chỉ và mỗi giá trị Storage của địa chỉ đều bị làm phẳng và phân tán. cùng một cây, không dễ để biết giá trị nào thuộc địa chỉ lưu trữ nào nên chúng ta không thể xóa mã hợp đồng và toàn bộ lưu trữ của nó trong Verkle Tree.



△ Thiết kế cây trạng thái hiện tại (Cây Merkle Patricia) là cấu trúc hai lớp: State Root tương ứng với một cây bao gồm tất cả các địa chỉ và Storage Root tương ứng với một cây bao gồm tất cả các Kho lưu trữ trong một địa chỉ.

Nguồn hình ảnh: https://fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mpt.html



△  Cây trạng thái Verkle Tree là cây một lớp, hoàn toàn phẳng.

Nút màu đỏ trong hình là địa chỉ và nút màu xanh lá cây là địa chỉ Giá trị lưu trữ của địa chỉ. .

Nguồn ảnh: https://youtu.be/s7fm6Zz_G0I?t=572

< img src="https://img.jinse.cn/7188773_image3.png">

△  Nếu chúng ta chỉ xóa nút màu đỏ chứ không xóa Lưu trữ ( các nút màu xanh lá cây), nếu hợp đồng được triển khai lại đến cùng một địa chỉ, nó sẽ kế thừa trực tiếp Bộ lưu trữ cũ, chưa bị xóa, điều này sẽ trở thành một lỗ hổng tiềm ẩn rủi ro cao.

Nguồn ảnh: https://youtu.be/s7fm6Zz_G0I?t=572

Do đó, để chào đón Verkle Tree, chúng ta phải vô hiệu hóa Opcode SELFDESTRUCT có thể loại bỏ mã hợp đồng và Bộ nhớ.

Ghi chú

• Nếu nhà phát triển sử dụng CREATE2 + SELFDESTRUCT để triển khai nhiều lần đến cùng một địa chỉ, thì sau Dencun, việc này sẽ chỉ xảy ra đồng thời trong cùng một giao dịch để hoàn tất.

• Nếu nhà phát triển sử dụng CREATE2 + SELFDESTRUCT để đạt được hiệu quả của việc nâng cấp hợp đồng (vì vậy CREATE2 + SELFDESTRUCT sẽ không được hoàn thành trong cùng một giao dịch) và sẽ không thể tiếp tục sau Dencun, vui lòng chuyển sang chế độ nâng cấp nói chung là KHÔNG TỰ ĐỘNG.

EIP-7044

• Thay đổi lớp đồng thuận

• EIP-7044: Hợp lệ vĩnh viễn Đã ký Thoát khỏi tình nguyện

• https://eips.ethereum.org/EIPS/eip-7044

• EIP-7044: Thoát tự nguyện đã ký có hiệu lực vĩnh viễn

• https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-voluntary-exits/14348

EIP-7044 làm cho chữ ký được người xác minh sử dụng để thoát PoS có hiệu lực vĩnh viễn, ngăn chữ ký trở nên không hợp lệ do phân nhánh mạng. Những người xác thực được ủy thác cho các dịch vụ đặt cược không giám sát (chẳng hạn như Lido) sẽ có kinh nghiệm và sự đảm bảo được cải thiện: họ sẽ không phải yêu cầu bên thứ ba ký lại mỗi lần hard fork.

Nền

Trình xác thực Ethereum PoS cần phải có hai khóa riêng: một khóa được sử dụng để tham gia xác minh hàng ngày (chẳng hạn như tạo khối và ký), được gọi là Khóa xác thực; khóa còn lại là khóa riêng của địa chỉ nơi tài sản cầm cố và phí xử lý được trả lại khi thoát khỏi PoS, được gọi là Chìa khóa rút tiền. Khi người xác thực muốn thoát PoS, anh ta sẽ ký bằng Khóa xác thực và nội dung chữ ký chứa phiên bản mạng (hard fork) hiện tại.

Trong dịch vụ đặt cược không giám hộ hiện tại, nhà cung cấp dịch vụ sẽ giữ Khóa xác thực và người dùng sẽ giữ Khóa rút tiền, vì vậy nhà cung cấp dịch vụ có thể chỉ thực hiện nội dung công việc liên quan đến xác minh hàng ngày và không thể lấy đi tài sản cầm cố và phí xử lý của người dùng để đạt được mục đích không giam giữ. Để ngăn chặn các nhà cung cấp dịch vụ đe dọa tống tiền người dùng bằng cách “không thoát khỏi PoS”, các nhà cung cấp dịch vụ sẽ ký chứng chỉ rút PoS ngay từ đầu và trao chứng chỉ này cho người dùng để người dùng có thể chọn thoát bất cứ lúc nào. của nhà cung cấp dịch vụ.

Chi tiết hoạt động

Tuy nhiên, do sự rút lui của Nội dung chữ ký PoS Chứa phiên bản mạng (hard fork) hiện tại, chẳng hạn như Thượng Hải hiện tại hoặc phiên bản trước của Capella. Mạng sẽ so sánh "phiên bản hard fork trong chứng chỉ thoát" và "phiên bản hiện tại của mạng", nếu chênh lệch phiên bản nhiều hơn hai phiên bản sẽ bị coi là không hợp lệ. Nói cách khác, do mạng được cập nhật liên tục nên sau khi hard fork và nâng cấp lên phiên bản mới, các chứng chỉ thoát quá cũ sẽ trở nên không hợp lệ.

Ví dụ: các phiên bản hard fork hiện tại của lớp đồng thuận từ cũ đến mới là Altair, Bellatrix và (hiện tại) Capella. Chứng chỉ rút tiền được ký tại thời điểm Altair hiện tại sẽ không còn hiệu lực; nếu nó được cập nhật lên phiên bản tiếp theo của Deneb, chứng chỉ rút tiền được ký tại thời điểm Altair và Bellatrix sẽ trở nên không hợp lệ. Để đối phó với tình trạng này, người dùng phải yêu cầu chứng chỉ thoát từ nhà cung cấp dịch vụ mỗi khi xảy ra hard fork. Nếu người dùng không lấy được chứng chỉ thoát trước, nhà cung cấp dịch vụ có thể "không lấy được chứng chỉ thoát" " sau đợt hard fork. "Exit PoS" đe dọa tống tiền người dùng.

Lưu ý: Tuy nhiên, vì "Exit PoS" chỉ được mở sau Capella nên có thể không có ai ký trước chứng chỉ thoát tại Altair hoặc Bellatrix.

Vì vậy, EIP-7044 sửa phiên bản hard fork của chứng chỉ thoát trong Capella, để tất cả các chứng chỉ thoát được ký trong phiên bản hiện tại sẽ có hiệu lực vĩnh viễn. Cho dù có cập nhật bao nhiêu lần trong tương lai, Capella sẽ luôn được ký trong chứng chỉ thoát và sẽ không còn bị ảnh hưởng bởi phiên bản hard fork nữa.

Ghi chú

Do hard fork chống thoát Phiên bản đã được sửa trong Capella, vì vậy nếu người xác minh hoặc nhà cung cấp dịch vụ ký trước chứng chỉ thoát của phiên bản Deneb, nó sẽ trở nên không hợp lệ sau Deneb.

EIP-7045

• Thay đổi lớp đồng thuận

• EIP-7045: Tăng tối đa vị trí đưa vào chứng thực

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-7045

• EIP-7045: Tăng mức chứng thực tối đa khe bao gồm

• https://ethereum-magicians.org/t/eip-7045-increase-max-attestation-inclusion-slot/14342

EIP-7045 kéo dài thời hạn hiệu lực của phiếu bầu của người xác thực (Chứng thực), cho phép có nhiều thời gian hơn để thu thập phiếu bầu và tăng tính ổn định của mạng. Không có tác động đến người dùng nói chung hoặc người xác nhận.

Nền

Phiếu bầu của người xác thực ban đầu (Chứng thực) Có có thể bao gồm một Kỷ nguyên (32 Khe). Ví dụ: giả sử rằng người xác minh Alice được chỉ định bỏ phiếu ở Khe 10000 và do vấn đề về thời gian chờ của mạng, cô ấy không thể hoàn thành phiếu bầu của mình cho đến Khe 10010 hoặc phiếu bầu của cô ấy có thể không được phát sóng thành công cho đến mạng Slot 10020. p2p, nhưng phiếu bầu của cô ấy vẫn sẽ được đưa vào. Tuy nhiên, nếu phiếu bầu của cô ấy không xuất hiện cho đến Slot 10033, phiếu bầu của cô ấy sẽ không được đưa vào và nó sẽ được coi như thể cô ấy không bỏ phiếu.

Chi tiết hoạt động

EIP-7045 sẽ bao gồm việc biểu quyết Thời hạn hiệu lực được gia hạn chậm nhất là đến khi kết thúc Kỷ nguyên bỏ phiếu tiếp theo. Ví dụ: giả sử rằng người xác minh Alice được chỉ định bỏ phiếu ở Slot 3205 của Epoch 100. Trước EIP-7045, phiếu bầu của cô ấy có hiệu lực muộn nhất cho đến Slot 3237 (3237 = 3205 + 32), sau EIP-7045, phiếu bầu của cô ấy có thể được đưa vào chậm nhất cho đến cuối Kỷ nguyên 101 (tức là Khe 3263).

Lưu ý: Kỷ nguyên 0 chứa các Ô từ 0 đến 31; Kỷ nguyên 100 chứa các Ô từ 3200 đến 3231; Kỷ nguyên 101 chứa các Ô từ 3232 đến 3263.

EIP-7514

• Thay đổi lớp đồng thuận

• EIP-7514: Thêm giới hạn khuấy trộn kỷ nguyên tối đa

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-7514

• EIP-7514: Thêm kỷ nguyên tối đa giới hạn rời bỏ

• https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

Nền tảng

Sau khi Thượng Hải nâng cấp trình xác thực mở để rút khỏi PoS vào năm 2023, Ngược lại, nó thu hút nhiều người dùng tham gia với tư cách là người xác nhận, khiến cho chuỗi chờ trình xác nhận (Entry Queue) luôn đầy và tổng số người xác nhận tiếp tục tăng nhanh.



△ Hàng đợi vào đã tăng mạnh kể từ khi PoS bị rút khỏi đợt khai mạc. Nguồn ảnh: https://www.validatorqueue.com/

Nếu trình tự chờ của trình xác thực tiếp tục đầy thì từ tháng 9 năm 2023 Đến tháng 5 Năm 2024 (khi EIP được đề xuất), trong khoảng 8 tháng, 50% ETH sẽ được cam kết vào PoS; đến tháng 9 năm 2024, 75% ETH sẽ được cam kết. Việc đặt cược quá nhiều ETH có một số nhược điểm, chẳng hạn như có quá nhiều trình xác thực, dẫn đến có quá nhiều phiếu bầu của trình xác thực và chữ ký tổng hợp, làm tăng gánh nặng cho mạng p2p của trình xác thực và mở rộng trạng thái của chuỗi đồng thuận. Ngoài ra, một số người cho rằng tính bảo mật mà Ethereum yêu cầu không yêu cầu cam kết ETH quá nhiều, ETH đa thế chấp là một sự lãng phí từ góc độ bảo mật.

Tại sao ETH tiếp tục đổ vào nhiều đến vậy? Bởi vì ngay cả khi 100% ETH được thế chấp, tỷ lệ hàng năm vẫn ở mức khoảng 1,6% và sự xuất hiện của Liquid Stake Token (LST) đã cải thiện hơn nữa hiệu quả sử dụng vốn. Tùy chọn rất hấp dẫn.

May mắn thay, sự bùng nổ đặt cược sẽ giảm dần vào nửa cuối năm 2023, làm chậm lại sự tăng trưởng về số lượng người xác thực.



△ Sự tăng trưởng về số lượng người xác thực sẽ chậm lại vào nửa cuối năm 2023 và vào tháng 2 năm 2024, khoảng 25% ETH sẽ được thế chấp. Nguồn hình ảnh: https://www.validatorqueue.com/

Chi tiết hoạt động

Ban đầu, giới hạn trên của số lượng Hàng đợi mục nhập thay đổi theo số lượng trình xác thực hiện tại. Đối với mỗi lần tăng hoặc giảm của 65536 trình xác thực, giới hạn trên của số lượng Hàng đợi mục nhập sẽ tăng hoặc giảm 1. 2024 Số lượng hàng đợi nhập tối đa hàng tháng là 14 (số lượng người xác nhận hiện tại là khoảng 950.000).

EIP-7514 sẽ ấn định giới hạn trên của số Hàng đợi nhập là 8 và sẽ không còn tăng khi số lượng trình xác thực hiện tại tăng lên, do đó làm chậm Tốc độ cho phép cộng đồng có nhiều thời gian hơn để đưa ra các giải pháp dài hạn, chẳng hạn như EIP-7251, có thể được đưa vào đợt hard fork tiếp theo.

EIP-4844 và EIP-7516

• EIP-4844: Giao dịch Shard Blob

• https://www.eip4844.com/

• Bài đăng quan trọng của Rollup: Proto-Danksharding (1)

• https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from- proto- danksharding-85d2fe0566b6

• Bài đăng quan trọng của Rollup: Proto-Danksharding (2)

  < /li>

  • https:// Medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

EIP-4844 Đã thêm loại giao dịch mới, giao dịch được sử dụng cụ thể để lưu trữ dữ liệu Blob. Bằng cách đặt dữ liệu vào Blobs, Rollup sẽ có thể giảm thêm phí giao dịch.

EIP-4844 không phải là sự thay đổi để mở rộng và nâng cấp mà giống như "tăng Gas Limit của khối" và "giảm chi phí" để khối có thể được đặt Một thay đổi để tăng khối lượng giao dịch bằng cách nhập nhiều giao dịch (Cuộn lên). Nhưng EIP-4844 cũng mở đường cho một giải pháp mở rộng thực sự – Danksharding.

Ngoài ra, hội chợ thương mại Blob và hội chợ thương mại chung là thị trường phí riêng biệt và độc lập. Mỗi thị trường có Phí cơ bản và Phí ưu tiên riêng, vì vậy EIP-7516 là một Giao dịch Blob Mã Opcode BLOBBASEFEE đã được thêm vào thị trường phí (chức năng này tương đương với Mã Opcode BASEFEE của các giao dịch thông thường), để hợp đồng Rollup có thể biết Phí cơ sở của Blob thông qua Opcode này.

Tóm tắt và các điểm chính

• Hard fork Dencun bao gồm hard fork Deneb ở lớp đồng thuận và hard fork Cancun ở lớp thực thi.

• Nhân vật chính của bản nâng cấp này là EIP-4844. Việc giới thiệu định dạng giao dịch Blob cho phép Rollup giảm hơn nữa chi phí giao dịch và ở mức đồng thời cung cấp mặt đường Danksharding.

• Những thay đổi trong lớp đồng thuận bao gồm EIP-7044, EIP-7045 và EIP-7514.

• EIP-7044 cho phép người xác thực sử dụng dịch vụ đặt cược không giám sát không bị ảnh hưởng bởi các đợt hard fork trong tương lai khi chọn không tham gia PoS.

• EIP-7045 và EIP-7514 có thể được coi là bản cập nhật nhằm tăng tính ổn định của mạng PoS.

• Các thay đổi của lớp thực thi bao gồm EIP-1153, EIP-4788, EIP-5656, EIP-6780 và EIP-7516.

• EIP-1153 cho phép nhiều mẫu thiết kế hợp đồng giúp tiết kiệm nhiều gas; EIP-5656 cũng cho phép giảm chi phí gas một chút giảm.

• EIP-4788 cho phép lớp thực thi đọc thông tin lớp đồng thuận mà không cần tin tưởng vào bên thứ ba, mở ra nhiều khả năng hơn về các dịch vụ liên quan đến đặt cược .

• EIP-6780 còn loại bỏ SELFDESTRUCT và loại bỏ khả năng "xóa mã và trạng thái hợp đồng".

• Các nhà phát triển cần cẩn thận để không dựa vào giả định rằng "bộ nhớ tạm thời sẽ bị xóa sau giao dịch" khi sử dụng EIP- 1153, và nếu bạn sử dụng SELFDESTRUCT, hãy chú ý xem liệu hợp đồng của bạn có bị ảnh hưởng hay không.

• Người dùng thông thường không cần đặc biệt chú ý đến nó. Họ có thể tận hưởng chi phí giao dịch thấp hơn miễn là Rollup áp dụng giao dịch Blob.

Dữ liệu tham khảo và đề xuất đọc thêm

< p style="text-align: left;">EIP-1153

• https://eips.ethereum.org/EIPS/eip-1153

• https://www.eip1153.com/

• https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

• https://hackmd.io/@-_WYFKbvSmip5m7MNB4b8A/SJFH66Eca

EIP-4788

• https ://eips.ethereum.org/EIPS/eip-4788

• https://ethereum -magicians.org/t/eip-4788-beacon-root-in-evm/8281

< mạnh>EIP-5656

• https://eips.ethereum.org/EIPS/eip-5656

EIP-6780

• https:/ /eips.ethereum.org/EIPS/eip-6780

• https://ethereum-magicians .org/t/eip-6780-deactivate-self destroy-ngoại trừ-where-it-occurs-in-the-same-transaction-in-which-a-contract-was-created/13539

• https://www.youtube.com/watch?v=s7fm6Zz_G0I

EIP-7044

• https://eips.ethereum.org/EIPS/eip-7044

• < p style="text-align: left;">https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-voluntary-exits/14348

EIP-7514

• https://eips.ethereum.org/EIPS/eip-7514

• https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

EIP-4844 & EIP-7516

• https://www.eip4844.com/

• https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding -85d2fe0566b6

• https://medium.com/taipei-ethereum-meetup/rollup-proto -danksharding-implementation-detail-913a3c61fde8

• https://eips.ethereum.org/EIPS /eip-7516

• https://ethereum-magicians.org/t/eip-7516 -blobbasefee-opcode/15761