Bản nâng cấp Ethereum Cancun đang đến gần, điểm lại quá khứ, hiện tại và tương lai của bản nâng cấp Cancun

Tác giả: Fat Bird Finance

kiếp trước

Tại sao cần nâng cấp Cancun?

Tầm nhìn của Ethereum là trở nên có khả năng mở rộng hơn và an toàn hơn dưới tiền đề phân quyền. Bản nâng cấp hiện tại của Ethereum cũng cam kết giải quyết bộ ba bất khả thi này, nhưng nó đã và đang phải đối mặt với những thách thức lớn.

Các vấn đề với Ethereum:

Hiện tại, TPS và hiệu suất thấp, phí gas cao và tắc nghẽn nghiêm trọng, đồng thời, dung lượng ổ đĩa cần thiết để chạy ứng dụng khách Ethereum cũng đang tăng lên nhanh chóng. của thuật toán đồng thuận trên toàn bộ môi trường cũng ngày càng trở nên quan trọng hơn.

Do đó, dưới tiền đề phân cấp, cách truyền nhiều dữ liệu hơn và giảm gas để tăng cường khả năng mở rộng cũng như cách tối ưu hóa thuật toán đồng thuận để đảm bảo an ninh là tất cả những nỗ lực mà Ethereum hiện đang thực hiện.

Để giải quyết bộ ba bất khả thi về bảo mật, phân cấp và khả năng mở rộng, Ethereum đã sử dụng cơ chế PoW-to-PoS để giảm thêm ngưỡng nút và cũng đang lên kế hoạch sử dụng chuỗi đèn hiệu để chỉ định ngẫu nhiên trình xác minh nhằm tối ưu hóa bảo mật. về khả năng mở rộng, Ethereum xem xét sử dụng sharding để giảm khối lượng công việc của các nút, điều này cũng cho phép Ethereum tạo nhiều khối cùng một lúc và nâng cao khả năng mở rộng của nó.

Hiện tại, không gian của mỗi khối Ethereum là khoảng 200 ~ 300KB, kích thước tối thiểu của mỗi giao dịch là khoảng 100 byte, khoảng 2000 giao dịch, chia cho thời gian khối là 12 giây, giới hạn trên của TPS của Ethereum được giới hạn ở khoảng 100 . Dữ liệu này rõ ràng không thể đáp ứng nhu cầu của Ethereum.

Do đó, lớp Ethereum 2 tập trung vào cách đưa một lượng lớn dữ liệu vào không gian khối và đảm bảo tính bảo mật thông qua bằng chứng gian lận và bằng chứng hợp lệ.Đây là lý do tại sao lớp DA xác định giới hạn bảo mật trên, đây cũng là nội dung cốt lõi của lớp Nâng cấp Cancún

Lộ trình lặp đi lặp lại của hệ sinh thái Ethereum không thể xây dựng hiệu suất của Solana chuẩn (về độ trễ và thông lượng) và hiệu suất phân mảnh của Near sẽ không được nhìn thấy trong thời gian ngắn, cũng như hiệu suất thực thi song song của Sui và Aptos. trong ngắn hạn, Ethereum chỉ có thể Xây dựng cấu trúc nhiều lớp với Rollup làm cốt lõi, vì vậy việc nâng cấp Cancun để giải quyết TPS, gasfee và trải nghiệm của nhà phát triển là rất quan trọng đối với lộ trình Ethereum.

Lộ trình Ethereum được lên kế hoạch như thế nào?

Nâng cấp quan trọng gần đây và mục tiêu của họ

Ngày 1 tháng 12 năm 2020, beacon chain chính thức ra mắt, mở đường cho việc nâng cấp POS

Nâng cấp ở London vào ngày 5 tháng 8 năm 2021, EIP1559 đã thay đổi mô hình kinh tế của Ethereum;

Vào ngày 15 tháng 9 năm 2022, bản nâng cấp Paris (TheMerge) đã hoàn thành việc chuyển POW sang POS;

Vào ngày 12 tháng 4 năm 2023, Thượng Hải đã được nâng cấp để giải quyết vấn đề rút tiền cam kết;

Mô hình kinh tế và các nâng cấp liên quan đến POS đã được hoàn thành và một số nâng cấp tiếp theo đã giải quyết các vấn đề về hiệu suất của Ethereum, TPS và trải nghiệm của nhà phát triển;

Bước tiếp theo là tập trung vào TheSurge trong lộ trình Ethereum.

Mục tiêu: Đạt được hơn 100.000 TPS trong Rollup.

Chủ yếu có 2 giải pháp, on-chain và off-chain:

Giải pháp ngoài chuỗi: đề cập đến Lớp 2, bao gồm tổng số, v.v.

Sơ đồ trên chuỗi: đề cập đến việc thực hiện các thay đổi trực tiếp trong L1, đây là sơ đồ phân đoạn phổ biến. Hiểu đơn giản về phân đoạn là chia tất cả các nút thành các khu vực khác nhau và hoàn thành nhiệm vụ của từng khu vực, điều này sẽ giúp tăng tốc độ một cách hiệu quả;

Phân tích sơ đồ phân mảnh:

Vấn đề tiến thoái lưỡng nan của sơ đồ sharding: Sharding từng bao gồm sharding trạng thái, sharding giao dịch, v.v., nhưng việc đồng bộ hóa giữa các phân đoạn khác nhau là một vấn đề. Hiện tại, rất khó về mặt kỹ thuật để hoàn thành đồng bộ hóa dữ liệu nút mạng quy mô lớn. Không chỉ nó có thể không giải quyết được tình trạng của MEV mà còn có thể cần một số lượng lớn các bản vá để bù đắp cho các vấn đề khác nhau có thể phát sinh mà không thể thực hiện được trong thời gian ngắn.

Danksharding là một thiết kế sharding mới được đề xuất cho Ethereum. Ý tưởng cốt lõi của nó là tạo khối tập trung + xác minh phi tập trung + chống kiểm duyệt. Điều này cũng liên quan đến việc lấy mẫu tính khả dụng của dữ liệu (DAS) và các nhà sản xuất khối được đề cập bên dưới. Danh sách Kháng chiến (Crlist) liên quan. Ý nghĩa lớn nhất của ý tưởng cốt lõi của Danksharding là biến Ethereum L1 thành một lớp giải quyết thống nhất và tính khả dụng của dữ liệu (DataAvailability).

Sơ đồ sharding được chia thành 2 bước, hiện tại được chia thành Proto-danksharding và Complete-Rollup.

proto-danksharding：

Giới thiệu: Bằng cách giới thiệu các đốm màu để giúp L2 giảm phí và tăng thông lượng, nó cũng mở đường cho việc bảo vệ hoàn toàn như một kế hoạch trước cho quá trình bảo vệ. Dự kiến sau khi danksharding proto-danksharding, sẽ mất 2-5 năm để triển khai danksharing.

Nội dung: Tính năng chính của proto-danksharding là giới thiệu một loại giao dịch blob mới. Blob có đặc điểm là dung lượng lớn và chi phí thấp. Việc thêm các gói dữ liệu như vậy vào Ethereum có thể cho phép tất cả dữ liệu tổng số được lưu trữ trong blob, giảm đáng kể lưu trữ áp suất chuỗi chính, mà còn giảm chi phí cuộn lên.

Tổng số đầy đủ

Giới thiệu: Rollup mở rộng hoàn toàn dung lượng, tập trung vào việc tận dụng dữ liệu sẵn có.

nội dung:

Thiết kế P2P của DAS: Một số công trình và nghiên cứu liên quan đến vấn đề kết nối mạng data sharding;

Ứng dụng khách lấy mẫu tính khả dụng của dữ liệu: phát triển ứng dụng khách nhẹ có thể nhanh chóng xác định xem dữ liệu có sẵn hay không bằng cách lấy mẫu ngẫu nhiên một vài kilobyte;

Tự phục hồi DA hiệu quả: có thể xây dựng lại tất cả dữ liệu một cách hiệu quả trong các điều kiện mạng tồi tệ nhất (ví dụ: tấn công trình xác thực độc hại hoặc thời gian ngừng hoạt động lâu của các nút khối lớn).

Cuộc họp các nhà phát triển lõi Ethereum

Mọi nâng cấp của Ethereum đều phụ thuộc vào cuộc họp của nhà phát triển cốt lõi, thông qua thảo luận chung của những người đóng góp cốt lõi và theo một loạt đề xuất từ các nhà phát triển, hướng phát triển trong tương lai được xác định

Định nghĩa: Cuộc họp của nhà phát triển cốt lõi là cuộc gọi hội nghị hàng tuần do cộng đồng phát triển Ethereum tổ chức, nơi những người đóng góp cốt lõi từ các tổ chức khác nhau thảo luận về các vấn đề kỹ thuật và điều phối công việc trong tương lai trên Ethereum. Họ xác định hướng kỹ thuật trong tương lai của giao thức Ethereum, đồng thời cũng là cơ quan thực sự đưa ra quyết định về việc nâng cấp Ethereum, chịu trách nhiệm quyết định liệu EIP có được đưa vào bản nâng cấp hay không, có cần thay đổi lộ trình hay không và các vấn đề quan trọng khác. vấn đề.

Quy trình cốt lõi: Quá trình nâng cấp tập trung vào EIP đại khái như sau: Đầu tiên, EIP được chấp nhận sơ bộ tại cuộc họp của nhà phát triển cốt lõi (viết tắt là ACD), sau đó nhóm khách hàng sẽ kiểm tra nó bất kể EIP có được đưa vào bản nâng cấp hay không hay không Sau lần kiểm tra cuối cùng, hãy xem xét lại và sau đó quyết định có đưa nó vào bản nâng cấp thực tế hay không dựa trên cuộc thảo luận.

Có hai loại cuộc họp, đó là cuộc họp cấp đồng thuận và cuộc họp cấp điều hành, được tổ chức luân phiên mỗi tuần:

Hội nghị lớp đồng thuận (AllCore Developers Consensus - ACDC), tập trung vào lớp đồng thuận của Ethereum (Proof of Stake, Beacon Chain, v.v.);

Hội nghị lớp điều hành (giải pháp AllCore Developers - ACDE), tập trung vào lớp thực thi của Ethereum (EVM, lịch trình Gas, v.v.).

Có ba loại người bảo trì cốt lõi Ethereum, chủ yếu là các tổ chức chính thức hoặc diễn đàn tình nguyện thảo luận về các đề xuất:

AllCoreDevs: người bảo trì mã, chịu trách nhiệm về ứng dụng khách mạng ETH1, nâng cấp, bảo trì mã Ethereum và kiến trúc lõi;

Phần "Quản lý dự án": hỗ trợ các nhà phát triển Ethereum, điều phối các nhánh cứng, giám sát EIP, v.v. và trực tiếp trợ giúp AllCoreDevs về giao tiếp và vận hành;

EthereumMagicians: Một "diễn đàn" để thảo luận về EIP và các chủ đề kỹ thuật khác.

Dòng thời gian của các cuộc họp liên quan đến leo thang Cancun

Theo nội dung của cuộc thảo luận, việc nâng cấp Cancun này có thể được chia thành năm giai đoạn.

Giai đoạn đầu tiên - giới thiệu chủ đề nâng cấp

Giới thiệu các nhiệm vụ mới proto-danksharding, EOF và opcodes "tự hủy", thảo luận ngắn gọn về nội dung nâng cấp Thượng Hải

Sau khi việc sáp nhập Ethereum hoàn tất vào ngày 15 tháng 9 năm 22, cuộc họp của nhà phát triển đã bị đình chỉ trong 4 tuần, cho phép các nhà phát triển kiểm tra EIP được thảo luận trong lần nâng cấp tiếp theo trong một tháng;

Vào ngày 28 tháng 10 năm 22, cuộc họp đầu tiên của nhà phát triển sau khi sáp nhập đã đề xuất triển khai lần đầu tiên proto-danksharding, EOF và opcode "tự hủy". Tại thời điểm này, phạm vi cụ thể của proto-danksharding vẫn chưa được xác định và một số nhà phát triển ban đầu nghĩ rằng, bản nâng cấp Thượng Hải có thể được chia thành nhiều bản nâng cấp nhỏ, chẳng hạn như cho phép rút ETH đã cam kết trước, sau đó nâng cấp EIP4844, nhưng một số nhà phát triển cho rằng việc triển khai bản nâng cấp lớn hơn trong một bước sẽ có ý nghĩa hơn.

Giai đoạn 2 - Xác định khung thời gian và công tác chuẩn bị cho lễ KZG

Vào cuối năm 2022, hội nghị Ethereum sẽ chủ yếu tập trung vào EOF và EIP4844. Đồng thời, chúng tôi sẽ tiếp tục thúc đẩy buổi lễ thiết lập tiền đáng tin cậy theo yêu cầu của EIP4844 - buổi lễ KZG. Các nhà phát triển sẽ chính thức xác định việc nâng cấp 4844 sẽ là gì xuất hiện vào ngày 23 tháng 1

Vào ngày 22 tháng 11, EOF hoặc proto-danksharding đã được đề cập trong cuộc gọi hội nghị số 149 của tất cả các nhà phát triển cốt lõi của Ethereum.Tại thời điểm này, các nhà phát triển vẫn đang xem xét đưa nó vào bản nâng cấp Thượng Hải;

Trong cuộc họp Lớp đồng thuận vào ngày 22/12/2020, Trent Van Epps, người đứng đầu hệ sinh thái Ethereum, đã cập nhật về tiến trình của buổi lễ thiết lập đáng tin cậy cần thiết để triển khai EIP4844, nhằm mục đích tạo ra một đoạn mã bảo mật sẽ được được sử dụng trong EIP4844. VanEpps hy vọng rằng buổi lễ sẽ là một trong những buổi lễ lớn nhất từ trước đến nay trong không gian tiền điện tử, thu thập được 8.000 đến 10.000 đóng góp.Thời gian đóng góp công khai của buổi lễ sẽ kéo dài khoảng 2 tháng và bắt đầu vào khoảng tháng 12;

Trong cuộc họp của nhà phát triển cốt lõi cùng ngày, đã có một số cuộc thảo luận xung quanh EOF và việc hủy kích hoạt opcode tự hủy. sẽ nhập Khả năng xảy ra Cancun là rất nhỏ. Về mã tự hủy, một số nhà phát triển đã ủng hộ việc nâng cao EIP4758 vào thời điểm đó, nhưng việc vô hiệu hóa trực tiếp mã này sẽ phá vỡ một số ứng dụng. Các nhà phát triển tin rằng trước khi tạo ra một trường hợp cạnh để bảo vệ loại hợp đồng này, EIP này nên được cân nhắc lại trong một khoảng thời gian;

Trong cuộc họp của nhà phát triển cốt lõi vào ngày 9 tháng 12 năm 22, việc triển khai buổi lễ KZG liên quan đến việc nâng cấp Cancun đã được thúc đẩy. Hiện tại, buổi lễ thiết lập đáng tin cậy theo yêu cầu của EIP4844 đã sẵn sàng;

Trong cuộc họp Lớp đồng thuận vào ngày 16/12/22, về chủ đề EIP4844, các nhà phát triển đã thảo luận về việc hợp nhất hai yêu cầu kéo (PR) khác nhau vào thông số kỹ thuật cho proto-danksharding, một liên quan đến cách các nút xử lý dữ liệu bị cắt bớt. Một là khi thông tin về các đốm màu bị thiếu trên một khối nhất định, một mã lỗi mới sẽ được đưa vào các nút cảnh báo;

Trong cuộc họp nhà phát triển cốt lõi vào ngày 5 tháng 1 năm 23, các nhà phát triển đã đạt được sự đồng thuận về việc loại bỏ các sửa đổi mã liên quan đến việc triển khai EOF khỏi bản nâng cấp Thượng Hải. Tại thời điểm này, Beiko đề xuất quyết định xem có nên đưa EOF vào rào cản sau hai tuần hay không. Kun đang được nâng cấp;

Giai đoạn 3 - Thảo luận sơ bộ về phạm vi của đề xuất

Vào cuối ngày 23 tháng 1, EOF đã được chuyển đến Cancun để nâng cấp sau khi bị xóa khỏi Thượng Hải. Trong hai tháng sau đó, các cuộc thảo luận chủ yếu tập trung vào các đề xuất khác ngoại trừ EOF và EIP4844. Đồng thời, EOF được đề xuất chuyển khỏi Cancun . Khoảng thời gian này chủ yếu dành cho việc xác định phạm vi của các đề xuất nâng cấp Cancún.

Trong cuộc họp nhà phát triển cốt lõi vào ngày 20, 23 tháng 1, EOF đã được chuyển đến Cancun để nâng cấp;

Trong cuộc họp của nhà phát triển cốt lõi vào ngày 6 tháng 3 năm 23, các đề xuất sơ bộ cho việc nâng cấp Cancun là: EIP4788 (gốc trạng thái chuỗi đèn hiệu công khai), EIP2537 (thực hiện hiệu quả các hoạt động như xác minh chữ ký BLS và xác minh SNARK), EIP-5920 (giới thiệu mới opcode PAY) và triển khai kết hợp EIP6189 (để làm cho SELFDESTRUCT tương thích với cây Verkle) và EIP-6190 (thay đổi chức năng SELFDESTRUCT để chỉ gây ra một số thay đổi trạng thái hạn chế);

Trong cuộc họp của nhà phát triển cốt lõi vào ngày 16 tháng 3, 23, ngoài EOF và EIP4844, các đề xuất sau đã được xem xét để đưa vào Cancun: định dạng SSZ, xóa SELFDESTRUCT, EIP2537, EVMMAX, EIP1153, hướng dẫn SWAP và DUP không giới hạn, giới thiệu PAY Beacon gốc trạng thái trong mã và EVM;

Trong cuộc họp của nhà phát triển cốt lõi vào ngày 30 tháng 3 năm 23, đề xuất EIP-6780 về việc vô hiệu hóa SELFDESTRUCT lần đầu tiên được đưa ra, đây cũng là đề xuất vô hiệu hóa SELFDESTRUCT mà Cancun cuối cùng đã quyết định sử dụng. Nhưng liên quan đến việc triển khai EOF, một nhà phát triển từ nhóm khách hàng Erigon(EL) đã tuyên bố rằng EOF "đã thay đổi quá nhiều" để được kết hợp với đề xuất cải tiến Ethereum EIP4844 trong bản nâng cấp Cancun sắp tới, được đề xuất nâng cấp trong Triển khai Cancun EOF trong đợt hard fork ngay sau đó;

Giai đoạn thứ tư - xác định hướng rõ ràng của việc nâng cấp đề xuất và xóa các đề xuất không liên quan

Vào ngày 23 tháng 4, đã có định hướng rõ ràng cho các đề xuất nên được đưa vào bản nâng cấp Cancun, điểm mấu chốt là cuộc họp của nhà phát triển vào ngày 13 tháng 4. Cuộc họp này đã đề xuất 9 EIP và bản thân Tim cũng đã hiểu sâu hơn về các đề xuất thay thế. Thảo luận, trong cuộc họp vào ngày 27 tháng 4, EIP6780, EIP6475 và EIP1153 đã được xác định sẽ được đưa vào Cancun, trong khi EOF và EVMMAX (tập hợp con EIP liên quan đến triển khai EOF) đã bị xóa khỏi bản nâng cấp Cancun, việc nâng cấp EOF chủ yếu có thể giúp ích Kiểm soát phiên bản EVM và nhiều bộ quy tắc hợp đồng có thể được chạy cùng một lúc, điều này có lợi cho việc mở rộng Ethereum sau này. hướng lên

Vào ngày 12, 23 tháng 4, quá trình nâng cấp Ethereum Shanghai đã hoàn tất;

Ngoài cuộc họp nhà phát triển cốt lõi vào ngày 13.04.23, nơi các nhà phát triển đã thảo luận về EIP4844 (về việc tiết lộ dữ liệu về trạng thái gốc CL trong EL), có ít nhất chín EIP khác đang được xem xét để nâng cấp, đó là EIP4844, loại bỏ SELFDESTRUCT ( EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIPs (EIP6601 và EIP6690), SSZchanges (EIP6475, EIP6493, EIP 6465, EIP6404 và EIP6466 ), EIP 5656 và EIP6193 ;

Trong cuộc họp của nhà phát triển cốt lõi vào ngày 27 tháng 4, 23, một số tiến bộ và sự đánh đổi đã được tập trung vào. Đầu tiên, EIP4844 tiếp tục được xác định để đưa vào bản nâng cấp Cancun, trong khi các EIP sau đã được thêm vào: EIP6780 (thay đổi chức năng của opcode SELFDESTRUCT), EIP6475 (một loại Số sê-ri hóa đơn giản (SSZ) mới để biểu thị các giá trị tùy chọn), EIP1153 ( bổ sung mới thứ hai, các EIP đang được xem xét nhưng không chính thức được đưa vào nâng cấp là EIP6913 (giới thiệu hướng dẫn SETCODE), EIP6493 (xác định sơ đồ chữ ký cho các giao dịch được mã hóa SSZ), EIP4788 (tiết lộ gốc chuỗi đèn hiệu trong khối EL tiêu đề), EIP2537 (thêm đường cong BLS12-381 dưới dạng tiền biên dịch) và EIP5656 (giới thiệu hướng dẫn EVM mới để sao chép vùng bộ nhớ); cuối cùng, EOF và EVMMAX (tập hợp con của EIP liên quan đến triển khai EOF) đã bị xóa khỏi bản nâng cấp Cancun. Bản nâng cấp EOF đã bị xóa khỏi bản nâng cấp Thượng Hải tại Hội nghị các nhà phát triển Ethereum vào đầu tháng 1 năm 2023 và nó được mặc định xuất hiện trong bản nâng cấp Cancun từ cuối tháng 1 năm 2023 đến đầu tháng 4 năm 2023, nhưng sự phát triển vào ngày 29 tháng 4 năm 23 EOF lại bị xóa trong cuộc họp của các tác giả.

Giai đoạn thứ năm - xác định đề xuất cuối cùng và cải tiến chi tiết

Vào ngày 23 tháng 5, các chi tiết đề xuất cuối cùng chủ yếu được sắp xếp hợp lý và cải thiện. Việc thay đổi SSZ->RLP có nghĩa là hai SSZEIP ở Cancun sẽ không còn cần thiết nữa, vì vậy EIPs6475 và 6493 sẽ được chuyển ra khỏi Cancun để nâng cấp. Cũng tại cuộc họp kín vào ngày 26, Tim Beiko đề xuất rằng các cuộc thảo luận trong tương lai xung quanh việc mở rộng phạm vi của Cancun sẽ được giới hạn trong năm EIP sau: EIP-5920, 5656, 7069, 4788 và 2530. Các nhà phát triển hiện đã xác định toàn bộ phạm vi nâng cấp Cancun.

Cuộc họp đồng thuận cốt lõi Ethereum vào ngày 5 tháng 5 năm 23 đã thảo luận về EIP4788, đã được đề cập lần trước và đã thêm các cuộc thảo luận về EIP6987 và EIP6475, lần lượt là về trình xác thực và giao dịch SSZ;

Trong cuộc họp lớp điều hành Ethereum lần thứ 161 vào ngày 11 tháng 5 năm 23, TimBeiko nói rằng phạm vi nâng cấp Cancun vẫn có thể được sửa đổi trong vài tuần tới, nhưng nếu không có đề xuất rõ ràng từ nhà phát triển, phạm vi nâng cấp Cancun sẽ được Giữ trạng thái "mặc định" và cuộc thảo luận về EIP-4844 cho thấy rằng các nhà phát triển đồng ý xóa SSZ khỏi triển khai EL của EIP-4844, nhưng nó không ảnh hưởng đến sự phát triển liên tục của 6475. Ngoài ra, các nhà phát triển cũng thảo luận ngắn gọn về hai EIP để xem xét ở Cancun, đó là EIP6969 (phiên bản sửa đổi của EIP1559) và EIP5656 (Hướng dẫn EVM hiệu quả để sao chép vùng bộ nhớ);

Sự phát triển của 4844 đã được thảo luận ngắn gọn trong cuộc họp Đồng thuận của Nhà phát triển vào ngày 18.05.23, chẳng hạn như cho phép các ứng dụng hợp đồng thông minh trên EL xác minh bằng chứng về trạng thái CL;

Việc hủy kích hoạt SELFDESTRUCT, thay đổi thông số kỹ thuật EIP-4844, quản lý opcode và các bổ sung Cancun tiềm năng cuối cùng đã được thảo luận trong cuộc họp Ethereum Core lần thứ 162 vào ngày 25 tháng 5 năm 2023. Tim Beiko gợi ý rằng các cuộc thảo luận trong tương lai xung quanh việc mở rộng phạm vi của Cancun nên được giới hạn trong năm EIP sau: EIP-5920, 5656, 7069, 4788 và 2530. Nhà phát triển sẽ xác định phạm vi đầy đủ của Dencun (Deneb+Cancun) trong vài tuần tới;

Tại Cuộc họp lớp đồng thuận Ethereum lần thứ 110 vào ngày 1 tháng 6 năm 2023, một nhà nghiên cứu từ Ethereum Foundation đã giới thiệu kết quả của một thử nghiệm dữ liệu về khả năng phân phối lượng lớn dữ liệu của các nút mạng chính Ethereum. Từ kết quả này, nhà nghiên cứu đề xuất EIP4844 The thông số kỹ thuật tăng từ tối đa 4 đốm màu lên 6 đốm màu mỗi khối. Đồng thời, các nhà phát triển đang xem xét kết hợp EIP4788 vào bản nâng cấp Cancun;

Trong cuộc họp dành cho nhà phát triển cốt lõi vào ngày 13 tháng 6 năm 2023, các nhà phát triển đã chính thức xác nhận phạm vi nâng cấp, bao gồm EIP4844, EIP1153, EIP5656, EIP6780 và EIP4788;

Trong cuộc họp đồng thuận vào ngày 15 tháng 6 năm 2023, người ta đã thảo luận về việc đưa EIP lấy CL làm trung tâm vào Deneb, trong đó, EIP-6988, EIP-7044, EIP-7045 đã được đề xuất bổ sung và nhóm khách hàng CL đã đồng ý về lần tiếp theo Kiểm tra số lượng đốm màu tăng lên trên mạng thử nghiệm EIP-4844 Devnet6 và đưa ra quyết định cuối cùng về vấn đề này trong vòng hai tuần Đồng thời, Michael Neuder, một nhà nghiên cứu tại Ethereum Foundation, đã đề xuất hủy bỏ 32 ETH giới hạn cam kết để giúp giảm sự phát triển của bộ xác thực đang hoạt động;

Trong cuộc họp vào ngày 22 tháng 6 năm 2023, Tim đã đề xuất chuyển địa chỉ biên dịch trước 4844 sang 0xA, đóng gói chúng và chuyển BLS sang địa chỉ khác, mặc dù địa chỉ biên dịch trước này đã được giới thiệu thông qua EIP2537, nhưng nó sẽ không được xem xét trong kế hoạch Cancun;

Trong cuộc họp đồng thuận vào ngày 29 tháng 6 năm 2023, các nhà phát triển tiếp tục thảo luận về số lượng đốm màu, nâng giới hạn đốm màu mục tiêu từ 2 lên 3 và nâng giới hạn đốm màu tối đa từ 4 lên 6. Đồng thời, mạng thử nghiệm 4844 Devnet #7 sẽ sớm ra mắt.

cuộc sống này

Nội dung cốt lõi là EIP4844, Proto-Danksharding

Phạm vi EIP cuối cùng cho bản nâng cấp Cancun là: EIP4844, EIP1153, EIP5656, EIP6780 và EIP4788. Đồng thời, trong cuộc họp Ethereum ACDC lần thứ 111 vào ngày 19 tháng 6, các nhà phát triển tiếp tục thảo luận về EIP6988, EIP7044 và EIP7045 để đưa vào Deneb. Các nhà phát triển cho biết họ có kế hoạch hợp nhất ba EIP nói trên vào đặc điểm kỹ thuật của Deneb trong vài tuần tới.

Phân tích các EIP chính

EIP4844

Giới thiệu:

Tên của đề xuất EIP4844 là Proto-Danksharding, đây là giải pháp phân đoạn trước cho phiên bản đầy đủ của Danksharding. Toàn bộ các kế hoạch phân đoạn thực sự xoay quanh Rollup để mở rộng trên chuỗi. Mục đích của giải pháp là mở rộng Rollup lớp 2 - bằng cách giúp L2 giảm phí và tăng thông lượng, đồng thời mở đường cho phân đoạn đầy đủ.

Trong cuộc gọi hội nghị vào ngày 23 tháng 2, các nhà phát triển Ethereum đã nâng cấp EIP4844 và đặt tên cho nó là Deneb, là tên của một ngôi sao hạng nhất trong Cygnus. Tức là tên của EIP4844 trên phiên bản GitHub có liên quan sẽ được cập nhật thành Deneb trong tương lai; Trong cuộc họp vào ngày 1 tháng 3, đã có một số thay đổi trong thông số kỹ thuật nâng cấp tiếp theo của Ethereum, được gọi là Deneb ở phía CL và Cancun ở phía EL;

Trong cuộc họp nhà phát triển vào ngày 23 tháng 6 năm 23, các nhà phát triển sẽ cập nhật địa chỉ được biên dịch trước của EIP4844. Hiện tại, các nhà phát triển cốt lõi đã thêm 9 tiền biên dịch vào EVM và sẽ tạo hai tiền biên dịch dưới địa chỉ "0xA" và "0xB" bằng cách kích hoạt EIP4844 và 4788 tương ứng. Trong cuộc họp đồng thuận vào ngày 29 tháng 6, Devnet#7, một mạng thử nghiệm ngắn hạn dành riêng cho EIP4844, đã được chuẩn bị.

EIP-4844 giới thiệu một loại giao dịch hoàn toàn mới - BlobTranscation.

Giới thiệu về đốm màu:

Blob, tương tự như gói dữ liệu plug-in, chỉ có dung lượng lưu trữ là 128KB khi bắt đầu thảo luận về đề xuất, mục tiêu và giới hạn của Blob là 2/4. Trong cuộc họp nhà phát triển vào ngày 9 tháng 6 , 23, nó đã được điều chỉnh thành 3/6 . Tức là, hiện tại, mỗi giao dịch trong Ethereum có thể thực hiện tối đa ba giao dịch Blob, là 384KB và dung lượng targetBlob của mỗi khối là 6, là 768KB và có thể thực hiện tối đa 16 giao dịch Blob, là 2MB;

Nó có thể có tác động nhất định đến sự ổn định của mạng, nhưng nhóm phát triển Ethereum vẫn quyết định thử nghiệm nó trước để tránh phải thực hiện các hard fork tiếp theo để mở rộng khối blob.

Blob sử dụng KZGcommit Hash làm Hash để xác minh dữ liệu, tương tự như Merkle;

Sau khi nút đồng bộ hóa BlobTransaction trên chuỗi, phần Blob sẽ hết hạn và bị xóa sau một khoảng thời gian và thời gian lưu trữ là ba tuần.

Vai trò của Blob - cải thiện TPS của Ethereum đồng thời giảm chi phí

Hiện tại, tổng khối lượng dữ liệu của toàn bộ Ethereum chỉ khoảng 1TB và Blob có thể mang lại 2,5-5TB khối lượng dữ liệu bổ sung cho Ethereum mỗi năm, trực tiếp vượt quá chính sổ cái nhiều lần;

Đối với các nút, tải xuống 1 MB đến 2 MB dữ liệu blob mỗi khối sẽ không gây gánh nặng băng thông và dung lượng lưu trữ sẽ chỉ tăng lượng dữ liệu blob cố định khoảng 200 ~ 400 GB mỗi tháng, điều này sẽ không ảnh hưởng đến việc phân cấp toàn bộ Nút Ethereum, nhưng việc mở rộng xung quanh Rollup được cải thiện rất nhiều;

Và bản thân nút không cần lưu trữ tất cả dữ liệu blob, bởi vì blob thực sự là một gói dữ liệu tạm thời, vì vậy trên thực tế, nút chỉ cần tải xuống một lượng dữ liệu cố định trong ba tuần.

Vai trò của EIP-4844 - mở đầu chương đầu tiên của tường thuật Danksharding

Khả năng mở rộng cao: Hiện tại, EIP-4844 ban đầu có thể mở rộng dung lượng L2. Phiên bản đầy đủ của Danksharding có thể mở rộng dung lượng dữ liệu Blob trong EIP-4844 từ 1MB đến 2MB lên 16MB đến 32 MB.

Phí thấp: Theo các nhà phân tích của Bernstein, Proto-dank-sharding có thể giảm phí của mạng lớp 2 xuống 10-100 lần so với mức hiện tại;

Dữ liệu thực tế:

Mạng thử nghiệm Opside đã triển khai 4844 và quan sát hiện tại có thể giảm 50% chi phí triển khai;

Giải pháp kỹ thuật DA của EigenLayer không tiết lộ quá nhiều để đánh giá dữ liệu của nó;

Nói đúng ra, Celestia ít liên quan đến Ethereum và chi phí DA của nó hiện không thể được đánh giá, tùy thuộc vào các giải pháp kỹ thuật cụ thể của nó;

Giải pháp của Ethstorage là tải lên chứng chỉ lưu trữ Lớp 2 và chi phí DA của nó có thể giảm xuống 5% so với ban đầu;

Topia hy vọng sẽ giảm chi phí từ 100 đến 1000 lần, bởi vì mạng chính Danksharding cũng cần tính đến tính bảo mật và khả năng tương thích với phát sóng mạng P2P Lớp 1.

Giải pháp DA: Danksharding (một giải pháp sharding để mở rộng Ethereum) hiện có thể gây ra các sự cố như gánh nặng nút quá mức (trên 16mb) và không đủ dữ liệu (thời hạn hiệu lực là 30 ngày). Giải pháp:

Lấy mẫu khả dụng của dữ liệu - giảm gánh nặng cho nút

Cắt dữ liệu trong Blob thành các đoạn dữ liệu và để các nút thay đổi từ tải xuống dữ liệu Blob sang kiểm tra ngẫu nhiên các đoạn dữ liệu Blob, để các đoạn dữ liệu Blob nằm rải rác trong mỗi nút của Ethereum, nhưng dữ liệu Blob hoàn chỉnh được lưu trữ trong toàn bộ sổ cái Ethereum In Fang, tiền đề là các nút cần phải đầy đủ và phi tập trung;

DAS sử dụng hai công nghệ: mã hóa xóa (ErasureCoding) và cam kết đa thức KZG (KZGCommitment);

Phân tách người đề xuất-người đóng gói (PBS) - giải quyết vấn đề phân công lao động giữa các nút, cho phép các nút có cấu hình hiệu suất cao chịu trách nhiệm tải xuống tất cả dữ liệu để mã hóa và phân phối, đồng thời cho phép các nút có cấu hình hiệu suất thấp chịu trách nhiệm kiểm tra tại chỗ và xác minh.

Các nút có cấu hình hiệu suất cao có thể trở thành trình tạo. Trình tạo chỉ cần tải xuống dữ liệu blob để mã hóa và tạo khối, sau đó phát tới các nút khác để kiểm tra tại chỗ. Đối với trình tạo, do khối lượng dữ liệu đồng bộ hóa và yêu cầu băng thông cao nên sẽ tương đối tập trung;

Một nút có cấu hình hiệu suất thấp có thể trở thành người đề xuất (Proposer) Người đề xuất chỉ cần xác minh tính hợp lệ của dữ liệu và tạo và phát tiêu đề khối (BlockHeader) Tuy nhiên, đối với người đề xuất (Proposer) thì lượng dữ liệu đồng bộ và yêu cầu băng thông tương đối cao, thấp nên sẽ phi tập trung.

Danh sách chống kiểm duyệt (crList) - giải quyết vấn đề mà các nhà đóng gói có thể cố tình bỏ qua một số giao dịch nhất định và chèn các giao dịch mà họ muốn lấy MEV do quyền kiểm duyệt quá mức của họ.

Trước khi người xây dựng (Builder) đóng gói các giao dịch khối, người đề xuất (Proposer) trước tiên sẽ xuất bản một danh sách chống xem xét (crList), chứa tất cả các giao dịch trong mempool;

Người xây dựng (Builder) chỉ có thể chọn đóng gói và sắp xếp các giao dịch trong crList, nghĩa là người xây dựng không thể chèn giao dịch riêng tư của mình để lấy MEV, cũng như không thể cố tình từ chối một giao dịch (trừ khi Gaslimit đã đầy);

Sau khi đóng gói, Người xây dựng phát phiên bản cuối cùng của danh sách giao dịch Băm cho Người đề xuất và Người đề xuất chọn một trong các danh sách giao dịch để tạo tiêu đề khối (BlockHeader) và phát nó;

Khi nút đồng bộ hóa dữ liệu, nó sẽ lấy tiêu đề khối từ người đề xuất (Proposer), sau đó lấy phần thân khối từ trình đóng gói (Builder), để đảm bảo rằng phần thân khối là phiên bản được chọn cuối cùng.

PBS hai khe - giải quyết vấn đề các trình đóng gói tập trung ngày càng trở nên tập trung hơn bằng cách mua MEV

Sử dụng chế độ đặt giá thầu để xác định khối:

Trình xây dựng (Builder) tạo tiêu đề khối của danh sách giao dịch sau khi nhận được crList và giá thầu;

Người đề xuất (Proposer) chọn tiêu đề khối và người xây dựng (Builder) cuối cùng đã đặt giá thầu thành công và người đề xuất nhận được phí đấu giá thắng một cách vô điều kiện (bất kể khối hợp lệ có được tạo hay không);

Ủy ban xác minh (Các Ủy ban) xác nhận tiêu đề khối chiến thắng;

Người xây dựng tiết lộ nội dung của khối chiến thắng;

Ủy ban xác minh (Các Ủy ban) xác nhận phần thân của khối chiến thắng và tiến hành bỏ phiếu xác minh (nếu khối được thông qua, khối đó sẽ được tạo ra và nếu nhà đóng gói cố tình không đưa ra phần thân khối, thì khối đó được coi là không hiện hữu).

tầm quan trọng:

Trước hết, người xây dựng (Builder) có nhiều quyền hơn để đóng gói các giao dịch, nhưng crList được đề cập ở trên trước hết hạn chế khả năng chèn tạm thời các giao dịch và thứ hai, nếu người xây dựng (Builder) muốn kiếm lợi nhuận bằng cách thay đổi thứ tự giao dịch, thì nó cần phải trả một chi phí đấu thầu lớn ngay từ đầu để đảm bảo rằng nó có thể đạt được tiêu chuẩn của người đứng đầu khối, sau đó lợi nhuận MEV mà nó thu được sẽ giảm hơn nữa và về tổng thể, nó sẽ ảnh hưởng đến phương pháp lấy MEV và lợi nhuận của nó. giá trị thực;

Tuy nhiên, trong giai đoạn đầu, chỉ một số ít người có thể trở thành người đóng gói (xem xét các vấn đề về hiệu suất của nút), trong khi hầu hết mọi người chỉ trở thành người đề xuất, điều này có thể dẫn đến việc tập trung hóa hơn nữa. nhỏ Trong một số trường hợp nhất định, một số công cụ khai thác có kinh nghiệm với khả năng MEV sẽ có nhiều khả năng đặt giá thầu thành công hơn, điều này sẽ ảnh hưởng nhiều hơn đến hiệu quả của giải pháp MEV thực tế;

Điều này có ý nghĩa đối với một số giải pháp MEV sử dụng đấu giá MEV.

tầm quan trọng:

EIP4844 thực sự là một phiên bản siêu đơn giản của Danksharding: nó cung cấp giao diện ứng dụng giống như Danksharding, bao gồm một mã lệnh mới có tên là DataHash và một đối tượng dữ liệu mới có tên là Đối tượng BinaryLarge, là Blob;

proto-danksharding là một đề xuất "khung" (nghĩa là định dạng giao dịch và quy tắc xác minh) để triển khai thông số kỹ thuật Danksharding hoàn chỉnh: tuy nhiên, chưa có sharding nào được triển khai và tất cả người xác minh và người dùng vẫn cần xác minh trực tiếp tính khả dụng của dữ liệu hoàn chỉnh ;

Tại sao bạn chọn proto-danksharding thay vì EIP4488 để trực tiếp giảm phí layer2 về lâu dài, bởi vì chỉ cần một sự điều chỉnh nhỏ khi nâng cấp lên phân đoạn đầy đủ trong tương lai:

Sự khác biệt thực tế chính giữa EIP4488 và proto-danksharding là EIP-4488 cố gắng giảm thiểu những thay đổi mà Ethereum cần thực hiện hôm nay, trong khi proto-danksharding tạo ra nhiều thay đổi hơn cho Ethereum hôm nay để nâng cấp lên Ethereum trong tương lai. cần thiết cho sharding phiên bản đầy đủ;

Mặc dù việc triển khai phân đoạn đầy đủ (với lấy mẫu tính khả dụng của dữ liệu, v.v.) là một nhiệm vụ phức tạp và vẫn còn nhiều công việc phức tạp phải hoàn thành sau khi triển khai proto-danksharding, nhưng những phức tạp này sẽ được kiểm soát ở lớp đồng thuận. Sau khi proto-danksharding được triển khai, nhóm khách hàng lớp điều hành, nhà phát triển tổng số và người dùng không cần thực hiện thêm bất kỳ công việc nào khi chuyển đổi sang phân đoạn đầy đủ.

Để đạt được sharding hoàn chỉnh, cần phải hoàn thành việc triển khai thực tế PBS, bằng chứng được ủy quyền và lấy mẫu tính khả dụng của dữ liệu, nhưng những sửa đổi đó sẽ tập trung vào lớp CL và các nhà phát triển không cần phải điều chỉnh lại: hiện tại 4844 triển khai một loại giao dịch mới , tương tự như Định dạng giao dịch, logic xác thực chéo đồng thuận và logic lớp thực thi được yêu cầu trong quá trình phân đoạn hoàn chỉnh hoàn toàn giống nhau và giá gas độc lập tự điều chỉnh cho các đốm màu cũng được tạo ra. Để đạt được quá trình phân đoạn hoàn chỉnh trong trong tương lai, PBS và chứng chỉ ủy quyền cần phải được hoàn thành Và triển khai thực tế lấy mẫu tính khả dụng của dữ liệu, nhưng những sửa đổi này chỉ ở lớp CL và không yêu cầu sửa đổi bởi lớp EL hoặc nhà phát triển tổng số, điều này thuận tiện cho nhà phát triển.

Tiếp theo là SELFDESTRUCTremoval, EIP-6780 cuối cùng đã được xác định là giải pháp phù hợp nhất, nhưng tại cuộc họp nhà phát triển vào ngày 26, Tim đã đề xuất thêm một opcode SETCODE khác vào đề xuất này để cho phép các tài khoản có lập trình vẫn được cập nhật

TỰ HẠIXóa bỏ EIP-6780：X

lý lịch:

Vào ngày 21 tháng 3, Vitalik đã đề xuất rằng SELFDESTRUCT gây hại nhiều hơn lợi cho hệ sinh thái Ethereum. Lý do chính là nó là thứ duy nhất có thể thay đổi vô số đối tượng trạng thái trong một khối, dẫn đến thay đổi mã hợp đồng và có thể được sửa đổi mà không có sự đồng ý của tài khoản Mã hoạt động của số dư tài khoản có mối nguy hiểm tiềm ẩn lớn đối với tính bảo mật của Ethereum;

Cách duy nhất để xóa hợp đồng trên chuỗi là TỰ PHÂN BIỆT. Nếu bạn gọi chức năng tự hủy trong hợp đồng, bạn có thể tự hủy hợp đồng. Ethereum được lưu trữ trong hợp đồng sẽ được gửi đến địa chỉ được thiết kế. Các biến lưu trữ và mã còn lại sẽ bị xóa trong máy trạng thái. Trên thực tế, hành động hủy hợp đồng về mặt lý thuyết nghe có vẻ tốt nhưng thực chất lại rất nguy hiểm. Mặc dù chức năng tự hủy có thể giúp các nhà phát triển xóa hợp đồng thông minh và chuyển số dư trong hợp đồng đến địa chỉ được chỉ định trong trường hợp khẩn cấp, nhưng tính năng này cũng được bọn tội phạm sử dụng, biến nó thành phương tiện tấn công.

Trong cuộc họp của nhà phát triển cốt lõi vào ngày 13 tháng 4 năm 23, bốn đề xuất về SELFDESTRUCT đã được giới thiệu để tham gia vào cuộc thảo luận, đó là 6780, 4758, 6046 và 6190, và EIP6780 tiếp theo được xác định là đề xuất cuối cùng.

Giới thiệu: tự hủy là nút khẩn cấp của hợp đồng thông minh, nút này sẽ hủy hợp đồng và chuyển số ETH còn lại vào tài khoản được chỉ định.

EIP6780: Vô hiệu hóa SELFDESTRUCT trừ khi chúng nằm trong cùng một giao dịch trong hợp đồng.

CẬP NHẬT: Vào ngày 26 tháng 5, tim đã đề xuất rằng ngoài việc xóa SELFDESTRUCT, hãy thêm một opcode khác - SETCODE, để cho phép các tài khoản có lập trình vẫn được cập nhật. (Nghĩa là, chức năng cập nhật được thêm vào và tài sản trong hợp đồng thông minh được cập nhật bằng phương pháp cập nhật/nâng cấp), ở đây, những ưu điểm của EIP4758 được hấp thụ, cho phép dapp có chỗ để nâng cấp.

Lý do: Thao tác với mã SELFDESTRUCT ban đầu yêu cầu nhiều thay đổi đối với trạng thái tài khoản, chẳng hạn như xóa tất cả các mã và bộ nhớ. Điều này gây khó khăn cho việc sử dụng cây Verkle trong tương lai: mỗi tài khoản sẽ được lưu trữ trong nhiều khóa tài khoản khác nhau sẽ không được kết nối rõ ràng với tài khoản gốc.

ĐÃ THAY ĐỔI: EIP này thực hiện một thay đổi loại bỏ TỰ HẠI, với hai ngoại lệ sau

Các ứng dụng chỉ được sử dụng để rút tiền từ SELFDESTRUCT sẽ vẫn hoạt động;

SELFDESTRUCT được sử dụng trong cùng một giao dịch trong hợp đồng cũng không cần phải thay đổi.

Ý nghĩa: Cải thiện an toàn

Trước đây, có một hợp đồng trên mạng chính sử dụng SELFDESTRUCT để hạn chế những người có thể bắt đầu giao dịch thông qua hợp đồng;

Để ngăn người dùng tiếp tục gửi tiền và giao dịch trong một kho tiền sau khi TỰ TỬ VONG, thì kho tiền này có thể khiến bất kỳ ai đánh cắp mã thông báo trong kho tiền trong quá trình sử dụng nhiều lần.

Ba đề xuất sau đây là các đề xuất liên quan đến SELFDESTRUCT sau đó đã bị xóa.6780 đã được chính thức chọn trong cuộc họp của nhà phát triển cốt lõi vào ngày 28 tháng 4 năm 23 và ba đề xuất còn lại đã bị loại bỏ vì nhóm phát triển Ethereum cuối cùng muốn xóa hoàn toàn opcode SELFDESTRUCT. và ba đề xuất sau đây được sửa đổi bổ sung bằng phương tiện thay thế.

EIP-4758 (KHÔNG ĐƯỢC DÙNG): Vô hiệu hóa SELFDESTRUCT bằng cách thay đổi SELFDESTRUCT thành SENDALL, khôi phục tất cả tiền cho người gọi (gửi tất cả ether trong tài khoản cho người gọi), nhưng không xóa bất kỳ mã hoặc bộ nhớ nào.

Lý do: Tương tự như trên, trước đây việc thao tác với mã SELFDESTRUCT yêu cầu nhiều thay đổi đối với trạng thái tài khoản, chẳng hạn như xóa tất cả mã và bộ nhớ. Điều này gây khó khăn cho việc sử dụng cây Verkle trong tương lai: mỗi tài khoản sẽ được lưu trữ trong nhiều khóa tài khoản khác nhau sẽ không được kết nối rõ ràng với tài khoản gốc.

Thay đổi:

Opcode SELFDESTRUCT được đổi tên thành SENDALL, giờ đây chỉ chuyển tất cả ETH trong tài khoản tới người gọi, lược đồ không còn phá vỡ mã và lưu trữ hoặc thay đổi nonce;

Tất cả các khoản tiền hoàn lại có liên quan SELFDESTRUCT đã bị xóa

tầm quan trọng:

Chức năng ban đầu được giữ nguyên so với EIP-6780, vì một số ứng dụng vẫn/cần sử dụng mã SELFDESTRUCT.

EIP-6046 (không dùng nữa): Thay thế SELFDESTRUCT bằng DEACTIVATE. Thay đổi SELFDESTRUCT để không xóa khóa lưu trữ và sử dụng một giá trị đặc biệt trong tài khoản nonce để biểu thị hủy kích hoạt

Lý do: Tương tự như trên, với cây Verkle, các tài khoản sẽ được tổ chức khác nhau: thuộc tính tài khoản (bao gồm cả bộ nhớ) sẽ có các khóa riêng biệt, nhưng sẽ không thể duyệt và tìm tất cả các khóa đã sử dụng. Thao tác với các mã SELFDESTRUCT trước đây yêu cầu nhiều thay đổi đối với trạng thái tài khoản, khiến việc tiếp tục sử dụng SELFDESTRUCT trong cây Verkle trở nên rất khó khăn.

Thay đổi:

Thay đổi các quy tắc được giới thiệu bởi EIP-2681 sao cho các số gia nonce thông thường được giới hạn bởi 2^64-2 thay vì 2^64-1;

SELFDESTRUCT được đổi thành:

Không xóa bất kỳ khóa lưu trữ nào và để nguyên tài khoản;

Chuyển số dư tài khoản sang mục tiêu và đặt số dư tài khoản thành 0.

Đặt nonce tài khoản thành 2^64-1.

Không hoàn lại tiền kể từ EIP-3529;

Quy tắc liên quan SELFDESTRUCT của EIP-2929 vẫn không thay đổi.

tầm quan trọng:

Đề xuất này linh hoạt hơn các hành vi khác trực tiếp xóa TỰ TỬ.

EIP-6190 (không dùng nữa): Thay đổi SELFDESTRUCT, tương thích với Verkle, để nó chỉ gây ra một số thay đổi trạng thái hạn chế

Lý do: Tương tự như trên, với cây Verkle, các tài khoản sẽ được tổ chức khác nhau: thuộc tính tài khoản (bao gồm cả bộ nhớ) sẽ có các khóa riêng biệt, nhưng sẽ không thể duyệt và tìm tất cả các khóa đã sử dụng. Tuy nhiên, việc thao tác với mã SELFDESTRUCT yêu cầu một số lượng lớn các thay đổi đối với trạng thái tài khoản, điều này khiến việc tiếp tục sử dụng SELFDESTRUCT trong cây Verkle trở nên rất khó khăn.

Thay đổi: Thay vì hủy hợp đồng khi kết thúc giao dịch, điều sau đây xảy ra khi kết thúc giao dịch được gọi là:

Mã hợp đồng được đặt thành 0x1 và số ngẫu nhiên được đặt thành 2^64-1.

Vị trí thứ 0 của hợp đồng được đặt thành địa chỉ sẽ được xuất bản khi hợp đồng sử dụng opcode CREATE (keccak256(contractAddress, nonce)). Số ngẫu nhiên luôn là 2^64-1.

Nếu hợp đồng tự hủy sau khi cuộc gọi được chuyển tiếp bởi một hoặc nhiều hợp đồng bí danh, hãy đặt vị trí lưu trữ thứ 0 của hợp đồng bí danh thành địa chỉ được tính ở bước 2;

Số dư của hợp đồng sẽ được chuyển đến địa chỉ ở trên cùng của ngăn xếp;

Đỉnh của ngăn xếp được bật lên.

tầm quan trọng:

Được thiết kế để cho phép SELFDESTRUCT sau đó hình thành cây Verkle với những thay đổi tối thiểu;

Chi phí gas tăng khi áp dụng EIP-2929.

Sau đó là EIP1153, giúp tiết kiệm gas và mở đường cho thiết kế lưu trữ trong tương lai

EIP1153X

Tóm tắt: Mã cửa hàng tạm thời, thêm mã lệnh cho trạng thái thao tác hoạt động giống như cửa hàng nhưng loại bỏ sau mỗi giao dịch.

lý do:

Chạy một giao dịch trong Ethereum có thể tạo ra nhiều khung thực thi lồng nhau, mỗi khung được tạo bởi lệnh CALL (hoặc tương tự). Hợp đồng có thể được nhập lại trong cùng một giao dịch, trong trường hợp đó, nhiều khung thuộc về một hợp đồng.

Hiện tại, các khung này có thể giao tiếp theo hai cách: đầu vào/đầu ra thông qua lệnh GỌI và thông qua cập nhật cửa hàng. Giao tiếp qua I/O là không an toàn nếu có một khung trung gian thuộc về một hợp đồng không đáng tin cậy khác.

Lấy reentrancylock làm ví dụ, nó không thể dựa vào các khung trung gian để truyền trạng thái của khóa: Giao tiếp SSTORE SLOAD thông qua lưu trữ rất tốn kém và lưu trữ tạm thời là một giải pháp chuyên dụng và tiết kiệm gas cho vấn đề giao tiếp giữa các khung.

Đã thay đổi: Hai opcode mới đã được thêm vào EVM, TLOAD (0xb3) và TSTORE (0xb4).

Lưu trữ tạm thời là riêng tư đối với hợp đồng sở hữu nó và giống như lưu trữ liên tục, chỉ khung hợp đồng sở hữu mới có thể truy cập vào lưu trữ tạm thời của nó. Khi truy cập vào bộ lưu trữ, tất cả các khung đều truy cập vào cùng một bộ lưu trữ tạm thời giống như cách lưu trữ liên tục, nhưng khác với bộ nhớ.

Các trường hợp sử dụng tiềm năng:

reentrancylock；

Các địa chỉ CREATE2 có thể tính toán trên chuỗi: các tham số hàm tạo được đọc từ hợp đồng xuất xưởng, thay vì được chuyển như một phần của hàm băm mã khởi tạo;

Phê duyệt EIP-20 cho một giao dịch, ví dụ: #temporaryApprove(addressspender, uint256mount);

Hợp đồng phí chuyển nhượng: trả một khoản phí cho hợp đồng mã thông báo để mở khóa chuyển khoản trong các giao dịch;

Chế độ "till": Cho phép người dùng thực hiện tất cả các thao tác như một phần của lệnh gọi lại và kiểm tra xem "til" có được cân bằng ở cuối hay không;

Siêu dữ liệu cuộc gọi proxy: Truyền siêu dữ liệu bổ sung để triển khai hợp đồng mà không sử dụng dữ liệu cuộc gọi, chẳng hạn như các giá trị của tham số hàm tạo proxy bất biến.

tầm quan trọng:

Tiết kiệm gas và có các quy tắc thanh toán gas đơn giản hơn;

Giải quyết vấn đề liên lạc giữa các khung;

không thay đổi ngữ nghĩa của các hoạt động hiện có;

Không cần xóa khe lưu trữ sau khi sử dụng;

Các thiết kế lưu trữ trong tương lai (chẳng hạn như cây Verkle) không cần xem xét vấn đề bồi hoàn cho lưu trữ tức thời.

Sau đó, có 4788, có thể làm giảm giả định về niềm tin của nhóm cầm cố

EIP4788：X

Tóm tắt: Rễ khối Beacon trong EVM.

Cập nhật: Trong cuộc họp nhà phát triển vào ngày 15.06.23, các nhà phát triển đã đề xuất thực hiện thay đổi mã để cải thiện trải nghiệm của người đặt cược, EIP này sẽ tiết lộ gốc của khối chuỗi đèn hiệu, chứa thông tin trạng thái chuỗi nội bộ EVM, để các nhà phát triển DApp tin tưởng- truy cập tối thiểu.

Đã thay đổi: Gửi các gốc băm của mỗi khối chuỗi đèn hiệu trong tiêu đề tải trọng thực thi tương ứng, lưu trữ các gốc này trong một hợp đồng ở trạng thái thực thi và thêm một opcode mới để đọc hợp đồng đó.

Ý nghĩa: Đây là một đề xuất sửa đổi mã, đề xuất sửa đổi Máy ảo Ethereum (EVM) để nó có thể tiết lộ dữ liệu gốc trạng thái lớp hợp đồng (CL) trong lớp thực thi (EL), có thể tạo các giao thức khác nhau và các ứng dụng trong mạng Ethereum Giao tiếp giữa các chương trình hiệu quả và an toàn hơn. Cho phép nhiều thiết kế đáng tin cậy hơn cho nhóm đặt cược, bắc cầu và giao thức đặt lại.

Cuối cùng là 5656, cung cấp opcode sao chép bộ nhớ mới hiệu quả, nhưng hiện đang ở trạng thái tạm thời được đưa vào bản nâng cấp do băng thông thử nghiệm của nó

EIP5656X

Giới thiệu: MCOPY- lệnh sao chép bộ nhớ.

CẬP NHẬT: Vào ngày 06.09.23, nhóm phát triển tuyên bố rằng ban đầu họ đã chia rẽ về MCOPY vì trong khi nó giải quyết được vấn đề bảo mật, họ lo ngại về việc triển khai + băng thông thử nghiệm cần thiết để thêm nó vào bản nâng cấp, nhưng cuối cùng đã đồng ý đưa vào EIP 👉 Tuy nhiên, nếu nhà phát triển gặp vấn đề về dung lượng trong quá trình thử nghiệm hoặc ở phía máy khách thì sẽ bị xem xét gỡ bỏ. Do đó, MCOPY đang ở trạng thái tạm thời được đưa vào bản nâng cấp Cancun.

Đã thay đổi: Cung cấp hướng dẫn EVM hiệu quả để sao chép vùng bộ nhớ.

Ý nghĩa: Sao chép bộ nhớ là một hoạt động cơ bản, nhưng có một chi phí để thực hiện nó trên EVM.

Với tính khả dụng của lệnh MCOPY, các từ mã và câu có thể được sao chép chính xác hơn, điều này sẽ tăng hiệu suất sao chép bộ nhớ lên khoảng 10,5%, rất hữu ích cho các hoạt động tính toán chuyên sâu khác nhau;

Nó cũng sẽ hữu ích cho các trình biên dịch để tạo mã byte hiệu quả hơn và nhỏ hơn;

Nó có thể tiết kiệm một lượng chi phí gas nhất định cho việc biên dịch trước danh tính, nhưng nó thực sự không thể thúc đẩy việc thực hiện phần này.

Danh sách ứng viên EIP

Vào ngày 15 tháng 6 năm 23, cuộc họp đồng thuận của nhà phát triển đã thảo luận về những EIP tập trung vào CL nào sẽ được đưa vào Deneb, trong đó, EIP6988, EIP7044 và EIP7045 đã được đề xuất bổ sung.

EIP6988：X

Tóm tắt: Ngăn người xác thực bị cắt giảm được bầu làm người đề xuất khối.

Ý nghĩa: Tăng hình phạt đối với các nút vi phạm sẽ có lợi cho DVT.

EIP7044：X

Tóm tắt: Đảm bảo rằng các lần thoát khỏi trình xác thực đã ký có hiệu lực vĩnh viễn.

Ý nghĩa: Nó có thể cải thiện trải nghiệm của người đặt cược ở một mức độ nhất định.

EIP7045：X

Tóm tắt: Mở rộng phạm vi bao gồm vùng chứng thực từ cửa sổ cuộn của một kỷ nguyên thành hai kỷ nguyên.

Ý nghĩa: Tăng cường an ninh mạng.

Xóa phân tích của EIP

Trong cuộc họp Ethereum ACDE lần thứ 160 vào ngày 29, 23 tháng 4, EVMMAX và EOF đã được xác nhận sẽ bị xóa khỏi bản nâng cấp này và những thay đổi liên quan đến EOF có thể được giới thiệu trong các bản nâng cấp hàng ngày tiếp theo

EVMMAXEIPs：

Tóm tắt: EVMMAX nhằm mục đích mang lại tính linh hoạt cao hơn cho các hoạt động số học và sơ đồ chữ ký trên Ethereum. Hiện tại, có hai đề xuất EVMMAX, một có EOF và một không có EOF.

EIP6601: Phần mở rộng số học mô-đun EVM (EVMMAX)

Thay đổi: Đây là phiên bản lặp lại của EIP5843, điểm khác biệt so với EIP5843 là:

6601 giới thiệu loại phần EOF mới lưu trữ mô-đun, tham số Montgomery được tính toán trước, số lượng giá trị sẽ được sử dụng (mô-đun có thể định cấu hình thời gian chạy vẫn được hỗ trợ);

6601 sử dụng một không gian bộ nhớ riêng cho các giá trị EVMMAX, với các opcode tải/lưu trữ mới để di chuyển các giá trị giữa EVM<->bộ nhớ EVMMAX;

6601 hỗ trợ các hoạt động trên các mô-đun lên tới 4096 bit (giới hạn dự kiến được đề cập trong EIP).

Ý nghĩa: EIP-5843 giới thiệu phép cộng, phép trừ và phép nhân mô-đun hiệu quả cho Máy ảo Ethereum và EIP-6601 xây dựng dựa trên điều này bằng cách giới thiệu một phần thiết lập, một không gian bộ nhớ riêng biệt và các mã lệnh mới cho các hoạt động số học mô-đun Cung cấp tính linh hoạt và tổ chức tốt hơn đồng thời hỗ trợ các mô-đun lớn hơn và cải thiện hiệu suất EVM.

Là một hợp đồng EVM, cho phép thực hiện các phép toán số học đường cong elip trên nhiều đường cong khác nhau, bao gồm cả BLS12-381;

MULMOD giảm 90-95% chi phí gas khi vận hành trên các giá trị lên tới 256 bit so với các opcode ADDMOD hiện có;

Cho phép triển khai tiền biên dịch modexp dưới dạng hợp đồng EVM;

Giảm đáng kể chi phí xác minh ZKP trong các hàm băm đại số (chẳng hạn như MiMC/Poseidon) và EVM.

EIP6690：

Thay đổi: EIP-6990 là một đề xuất được điều chỉnh từ EIP-6601 để giới thiệu các phép toán số học mô-đun được tối ưu hóa cho EVM mà không cần dựa vào EOF. Trong khi EIP-6601 yêu cầu EIP-4750 và EIP-3670 làm phụ thuộc, EIP-6990 cung cấp giải pháp độc lập hơn. Nó cung cấp một cách tiếp cận đơn giản hơn bằng cách loại bỏ sự phụ thuộc vào EOF.

Ý nghĩa: Nó giữ lại chức năng cốt lõi của EIP-6601 để thực hiện các phép tính số học mô-đun được tối ưu hóa trên các mô-đun lẻ lên tới 4096 bit, sự đơn giản hóa này cho phép triển khai và áp dụng hiệu quả hơn trong khi vẫn cung cấp các lợi ích liên quan đến EIP-6601.

EOFthay đổi：

Giới thiệu: EOF là bản nâng cấp của EVM, giới thiệu các tiêu chuẩn hợp đồng mới và một số mã hành động mới. Mã byte EVM truyền thống (mã byte) là một chuỗi mã byte hướng dẫn không có cấu trúc. EOF giới thiệu khái niệm về bộ chứa, thực thi mã byte có cấu trúc. Vùng chứa bao gồm một tiêu đề và một số phần để cấu trúc mã byte. Sau khi nâng cấp, EVM sẽ có thể thực hiện kiểm soát phiên bản và chạy nhiều bộ quy tắc hợp đồng cùng một lúc.

EIP663：

Tóm tắt: Hướng dẫn SWAP và DUP không giới hạn

Ý nghĩa: Bằng cách giới thiệu hai lệnh mới: SWAPN và DUPN, khác với SWAP và DUP bằng cách tăng độ sâu ngăn xếp từ 16 phần tử lên 256 phần tử

EIP3540：

Giới thiệu:

Trước đây, mã byte EVM được triển khai trên chuỗi không có cấu trúc được xác định trước và mã sẽ chỉ được xác minh trước khi được chạy trong máy khách.Đây không chỉ là chi phí gián tiếp mà còn cản trở các nhà phát triển giới thiệu các chức năng mới .Hoặc loại bỏ chức năng cũ.

EIP này giới thiệu một vùng chứa có thể được mở rộng và kiểm soát phiên bản cho EVM, đồng thời tuyên bố định dạng của hợp đồng EOF. Dựa trên điều này, mã có thể được xác minh khi hợp đồng EOF được triển khai, nghĩa là xác thực thời gian tạo, nghĩa là thay đổi này thực hiện kiểm soát phiên bản EOF, điều này sẽ giúp vô hiệu hóa các hướng dẫn EVM hiện có hoặc giới thiệu các chức năng quy mô lớn (chẳng hạn như trừu tượng hóa tài khoản) trong tương lai.

tầm quan trọng:

Kiểm soát phiên bản có lợi cho việc giới thiệu hoặc ngừng sử dụng các chức năng mới trong tương lai (chẳng hạn như giới thiệu tính năng trừu tượng hóa tài khoản);

Việc tách mã hợp đồng và dữ liệu có lợi cho quá trình xác minh L2 (op), giảm chi phí gas của trình xác nhận L2, đồng thời việc tách mã hợp đồng và dữ liệu cũng thuận tiện hơn cho các công cụ phân tích dữ liệu trên chuỗi.

EIP3670：

Giới thiệu: Dựa trên EIP-3540, mục đích là để đảm bảo rằng mã của hợp đồng EOF tuân theo định dạng hợp lệ và việc triển khai hợp đồng không tuân theo định dạng sẽ bị ngăn chặn và Legacybytecode sẽ không bị ảnh hưởng.

Ý nghĩa: Dựa trên vùng chứa do 3540 giới thiệu, EIP-3670 đảm bảo rằng mã trong hợp đồng EOF hợp lệ hoặc ngăn không cho mã được triển khai. Điều này có nghĩa là các mã lệnh không xác định không thể được triển khai trong các hợp đồng EOF, điều này có thêm lợi ích là giảm số lượng phiên bản EOF cần được thêm vào.

EIP4200：

Giới thiệu:

Các opcode dành riêng cho EOF đầu tiên được giới thiệu: RJUMP, RJUMPI và RJUMPV, mã hóa các đích dưới dạng các giá trị ngay lập tức được ký. Trình biên dịch có thể sử dụng các opcode JUMP mới này để tối ưu hóa chi phí gas khi triển khai và thực thi JUMP vì chúng loại bỏ thời gian chạy cần thiết để thực hiện phân tích nhảy cho các opcode JUMP và JUMPI hiện có. EIP này là phần bổ sung cho bước nhảy động.

So với thao tác JUMP truyền thống, điểm khác biệt là các thao tác như RJUMP không chỉ định một vị trí offset cụ thể mà chỉ định một vị trí offset tương đối (từ bước nhảy động -> bước nhảy tĩnh), bởi vì bước nhảy tĩnh thường là đủ.

Ý nghĩa: tối ưu hóa mạng lưới và giảm chi phí.

EIP4750：

Thực hiện chức năng của 4200 thêm một bước: bằng cách giới thiệu hai opcode mới CALLF và RETF, một giải pháp thay thế được thực hiện cho tình huống không thể thay thế bằng RJUMP, RJUMPI và RJUMPV, do đó JUMPDEST không còn cần thiết trong hợp đồng EOF, tức là, Do đó, nhảy động bị vô hiệu hóa.

Ý nghĩa: Tối ưu hóa mã bằng cách chia mã thành nhiều phần.

EIP5450：

Bối cảnh: Nền tảng vẫn là hợp đồng Ethereum không được kiểm tra khi nó được triển khai và chỉ thực hiện một loạt kiểm tra khi nó đang chạy, liệu ngăn xếp có bị tràn (giới hạn trên là 1024), liệu khí có đủ hay không và sớm.

Nội dung: Đã thêm một kiểm tra tính hợp lệ khác cho các hợp đồng EOF, lần này là xung quanh ngăn xếp. EIP này ngăn chặn các tình huống trong đó việc triển khai hợp đồng EOF có thể dẫn đến tràn/tràn ngăn xếp. Bằng cách này, khách hàng có thể giảm số lần kiểm tra tính hợp lệ mà họ thực hiện trong quá trình thực hiện hợp đồng EOF.

Ý nghĩa: Một cải tiến lớn là làm cho các kiểm tra xảy ra trong quá trình thực thi càng ít càng tốt và nhiều kiểm tra hơn xảy ra khi hợp đồng được triển khai.

Sau khi cập nhật cuộc họp nhà phát triển vào ngày 26 tháng 5, việc thay đổi loại giao dịch từ SSZ sang RLP liên quan đến EIP4844 có nghĩa là hai SSZEIP ở Cancun không còn cần thiết nữa, vì vậy EIPs6475 và 6493 đã được chuyển ra khỏi Cancun để nâng cấp

EIP6475X

Giới thiệu: Đề xuất đồng hành với EIP4844. Proto-danksharding giới thiệu một loại giao dịch mới sử dụng mã hóa SSZ thay vì mã hóa RLP được sử dụng bởi các loại giao dịch khác.

CẬP NHẬT: Trong Cuộc họp các nhà phát triển cốt lõi lớp thực thi Ethereum lần thứ 161, các cuộc thảo luận về định dạng tuần tự hóa SSZ cho EIP4844 đã tiết lộ rằng ban đầu các nhà phát triển có xu hướng giới thiệu các lần lặp lại sớm của định dạng SSZ cho EL thông qua các giao dịch blob và cuối cùng các nhà phát triển có kế hoạch mang tất cả các loại giao dịch đã được nâng cấp từ RLP lên SSZ, nhưng các nhà phát triển đã cân nhắc việc loại bỏ SSZ khỏi EIP-4844 do đường dẫn không rõ ràng của nó và chắc chắn không thể triển khai nó trên bản nâng cấp Cancun. Sau nhiều cuộc thảo luận, các nhà phát triển đã đồng ý xóa SSZ khỏi triển khai EL của EIP-4844, nhưng họ vẫn chưa xóa EIP6475. Sau bản cập nhật ngày 26 tháng 5, thay đổi SSZ->RLP có nghĩa là hai SSZEIP ở Cancun không còn cần thiết nữa: do đó, EIP 6475 và 6493 sẽ được chuyển ra khỏi Cancun để nâng cấp.

EIP6493X

Giới thiệu: Lược đồ chữ ký giao dịch SSZ. EIP này xác định sơ đồ chữ ký cho các giao dịch được mã hóa theo thứ tự đơn giản (SSZ) và sẽ giải quyết cách các nút xử lý các loại giao dịch blob được định dạng ở định dạng SSZ trên CL nhưng được mã hóa khác trên EL. EIP này là một phần của bản cập nhật định dạng tuần tự hóa Ethereum để có tính nhất quán giữa các lớp;

Bối cảnh: SSZchanges

Giới thiệu: SimpleSerialiZe là phương pháp tuần tự hóa được sử dụng trên chuỗi đèn hiệu.

SSZchanges cũng bao gồm ba đề xuất hỗ trợ khác, lần này chỉ có 6465 được giới thiệu.

EIP6465: Gốc rút tiền SSZ, xác định quá trình di chuyển các cam kết Merkle-PatriciaTrie (MPT) hiện có sang rút tiền Sê-ri hóa Đơn giản (SSZ);

EIP6404/EIP6466：

Cả hai đều xác định một quy trình để di chuyển các cam kết Merkle-PatriciaTrie (MPT) hiện có sang Sê-ri hóa đơn giản (SSZ).

EIP-6404— Gốc giao dịch SSZ

EIP-6466— Đế nhận SSZ

Tim Beiko đã đề xuất trong cuộc họp nhà phát triển cốt lõi vào ngày 26 tháng 5 rằng các cuộc thảo luận trong tương lai xung quanh việc mở rộng phạm vi của Cancun sẽ được giới hạn trong năm EIP sau: EIP5920, 5656, 7069, 4788 và 2537, đồng thời các đề xuất tiếp theo sẽ được tạo trong phạm vi này. EIP5656 và EIP4788 sau đó đã được xác nhận là đề xuất nâng cấp chính thức và 5920, 7069 và 2537 đã bị xóa. và công việc bảo mật. Đã xóa khỏi nâng cấp.

EIP5920：X

Giới thiệu: opcode thanh toán. Giới thiệu opcode PAY mới cho chuyển Ethereum, gửi Ether đến một địa chỉ mà không cần gọi bất kỳ chức năng nào của nó.

Lý do: Hiện tại, việc gửi ether đến một địa chỉ yêu cầu người dùng gọi một hàm trên địa chỉ đó, điều này có một số vấn đề:

Đầu tiên, nó mở ra một vectơ cho các cuộc tấn công vào lại, vì người nhận có thể gọi lại cho người gửi;

Thứ hai, nó mở ra một vectơ DoS, vì vậy hàm cha phải biết rằng bộ thu có thể hết gas hoặc gọi lại;

Cuối cùng, opcode CALL đắt một cách không cần thiết đối với các chuyển ether đơn giản, vì nó yêu cầu mở rộng bộ nhớ và ngăn xếp, tải toàn bộ dữ liệu của người nhận, bao gồm mã và bộ nhớ, và cuối cùng cần thực hiện một cuộc gọi, có thể thực hiện các thao tác không chủ ý khác.

Thay đổi:

Một opcode mới đã được giới thiệu: (PAY)PAY_OPCODE, trong đó:

Pop hai giá trị từ ngăn xếp: addrthenval.

Chuyển wei từ địa chỉ thực thi val sang địa chỉ addr. Nếu addr là địa chỉ 0, valwei sẽ được lập trình từ địa chỉ thực thi.

Những cạm bẫy tiềm ẩn: Các hợp đồng hiện tại sẽ được sử dụng độc lập với số dư thực tế trong ví của họ, vì đã có thể gửi ether đến một địa chỉ mà không cần gọi đến địa chỉ đó.

Ý nghĩa: tiết kiệm xăng.

CẬP NHẬT: Vào ngày 06.09.23, PAY đã bị xóa khỏi bản nâng cấp do lo ngại về các tác dụng phụ tiềm ẩn có thể tồn tại trong cách chuyển ETH cũng như lý do, thử nghiệm và công việc bảo mật cần thiết để thông qua đề xuất.

EIP7069X

Giới thiệu: Lệnh CALL đã sửa đổi

Thay đổi: Đã giới thiệu ba hướng dẫn cuộc gọi mới, CALL2, DELEGATECALL2 và STATICCALL2, có tác dụng đơn giản hóa ngữ nghĩa. Nhằm mục đích loại bỏ khả năng quan sát gas khỏi chỉ thị mới và mở ra cơ hội cho một loại hợp đồng mới không bị ảnh hưởng bởi việc định giá lại.

lý lịch:

Quy tắc 63/64: giới hạn độ sâu của cuộc gọi và đảm bảo rằng người gọi còn khí để thay đổi trạng thái sau khi người được gọi trở lại;

Trước khi quy tắc 63/64 được đưa ra, gas có sẵn cho người gọi cần được tính toán chính xác. Solidity có một quy tắc phức tạp cố gắng ước tính chi phí ở phía người gọi khi thực hiện chính cuộc gọi để đặt giá trị gas hợp lý.

Quy tắc 63/64 hiện đang được giới thiệu:

Đã xóa kiểm tra độ sâu cuộc gọi;

Đảm bảo dự trữ ít nhất 5000 gas trước khi thực hiện hành vi được gọi;

Đảm bảo có ít nhất 2300 gas cho hành vi được gọi.

Quy tắc trợ cấp: chẳng hạn như trợ cấp 2300 nổi tiếng, khi một hợp đồng gọi một hợp đồng khác, hợp đồng được gọi sẽ nhận được 2300gas để thực hiện các hoạt động rất hạn chế (đủ để thực hiện một phép tính nhỏ và tạo nhật ký, nhưng không đủ để lấp đầy một khe lưu trữ ), vì nó đặt một lượng gas cố định, miễn là giá gas có thể được điều chỉnh, mọi người không có cách nào xác định loại tính toán này có thể hỗ trợ loại gas nào.

Ý nghĩa: Mở đường cho việc giới thiệu EOF trong tương lai và giúp thực hiện các hợp đồng lớn dễ dàng hơn.

Loại bỏ tùy chọn gas: lệnh mới không cho phép chỉ định giới hạn gas mà dựa trên "quy tắc thứ 63/64" (chủ yếu đề cập đến việc định giá lại gas được sử dụng cho một số lượng lớn hoạt động IO trong EIP-150, điều này làm tăng mức tiêu thụ gas của các hoạt động cụ thể) thành Hạn chế gas, cải tiến quan trọng này nhằm đơn giản hóa các quy tắc xung quanh "trợ cấp", bất kể giá trị có được gửi hay không, người gọi không cần thực hiện các phép tính về gas;

Với việc giới thiệu đề xuất mới, người dùng luôn có thể khắc phục lỗi Hết gas bằng cách gửi thêm gas trong giao dịch (tất nhiên là tùy thuộc vào giới hạn gas khối).

Một số hợp đồng chỉ gửi một lượng gas giới hạn cho các cuộc gọi của họ đã bị phá vỡ bởi cơ chế tính phí mới khi trước đó tăng chi phí lưu trữ (ví dụ: EIP-1884 đã tăng gas cho một số mã nhất định). Trước đây, một số hợp đồng có giới hạn gas giới hạn vĩnh viễn lượng gas họ có thể chi tiêu, ngay cả khi họ gửi nó vào cuộc gọi phụ của mình thì điều đó cũng không thành, cho dù họ có gửi thêm bao nhiêu gas đi chăng nữa, bởi vì cuộc gọi sẽ giới hạn số tiền đã gửi.

Mở đường cho việc giới thiệu EOF: Sau khi Định dạng đối tượng EVM (EOF) được giới thiệu, các lệnh gọi cũ có thể bị từ chối trong hợp đồng EOF, đảm bảo rằng chúng hầu như không bị ảnh hưởng bởi những thay đổi về giá gas. Vì các hoạt động này là cần thiết để loại bỏ khả năng quan sát khí, EOF sẽ yêu cầu chúng thay cho các hướng dẫn hiện có;

Mã trả về trạng thái tiện lợi hơn: Các chức năng tiện lợi đã được giới thiệu để trả về mã trạng thái chi tiết hơn: thành công (0), hoàn nguyên (1), thất bại (2) và có thể mở rộng trong tương lai.

EIP2537：X

Tóm tắt: Biên dịch trước thao tác đường cong BLS12-381.

ĐÃ THAY ĐỔI: Đã thêm các hoạt động trên đường cong BLS12-381 dưới dạng tiền biên dịch thành bộ cần thiết để thực hiện hiệu quả các hoạt động như xác minh chữ ký BLS và thực hiện xác minh SNARK.

Ý nghĩa: Ethereum có thể tạo bằng chứng mật mã an toàn hơn và cho phép khả năng tương tác tốt hơn với chuỗi đèn hiệu.

PR3175 đã được đề cập, nhưng không bao giờ lọt vào danh sách rút gọn, không thảo luận thêm

PR3175：X

Tóm tắt: Đề xuất này sẽ ngăn những người xác thực bị phạt đề xuất các khối khi xếp hàng. Nếu hơn 50% người xác thực bị phạt vì hành vi nguy hiểm, thì những người xác thực đó vẫn có thể đề xuất các khối trong khi bị buộc xóa khỏi mạng. Các nhà phát triển cho biết việc thay đổi logic này là một thay đổi lớp CL tương đối nhỏ nhằm cung cấp khả năng bảo vệ chống lại "các chế độ lỗi cao".

Theo Cuộc họp đồng thuận của các nhà phát triển Ethereum Core lần thứ 108 vào ngày 4 tháng 5, PR3175 đang trong quá trình được định dạng là EIP và sẽ được đổi thành EIP-6987, nghĩa là, vì lý do bảo mật, để ngăn các nút xác minh bị cắt giảm được chọn là chặn người đề xuất.

tương lai

Dựa trên các thông tin trên, chúng tôi đã đi đến kết luận sau:

1. Các mục tiêu chính của việc nâng cấp Cancun theo thứ tự ưu tiên là mở rộng, bảo mật, tiết kiệm xăng và khả năng tương tác:

Không có nghi ngờ rằng mở rộng là ưu tiên hàng đầu (4844);

An toàn và tiết kiệm xăng là ưu tiên thứ hai (6780, 1153, 5656 và 7045), đồng thời tính đến trải nghiệm nhất định của nhà phát triển;

Thứ ba là khả năng tương tác, chẳng hạn như tối ưu hóa kết nối, giao tiếp và khả năng tương tác giữa các dapp (4788, 7044 và 6988);

Dữ liệu dự kiến: Testnet 4844 có thể giảm 50% chi phí opsiderollup; các giải pháp kỹ thuật của EigenLayer và Celestia chưa tiết lộ quá nhiều và dữ liệu của họ không thể được đánh giá; Ethstorage ước tính rằng chi phí DA sẽ giảm xuống 5% so với ban đầu ;Topia dự kiến sẽ giảm chi phí 100~1000 lần .

2. 2 đến 5 năm tới khi Cancun được nâng cấp lên Danksharding là giai đoạn phát triển vàng cho các dự án DA layer

Giới hạn bảo mật trên của Lớp 2 phụ thuộc vào lớp DA mà nó sử dụng. Proto-Danksharding sẽ mang lại lợi ích cho các giao thức lưu trữ, giao thức mô-đun và mạng mở rộng lưu trữ L1 thông qua lưu trữ dữ liệu trạng thái rẻ hơn.

Đầu tiên, Danksharding trở lại bản chất của cỗ máy trạng thái Ethereum. V God đã đề cập rằng mục đích của giao thức đồng thuận Ethereum không phải là đảm bảo việc lưu trữ vĩnh viễn tất cả dữ liệu lịch sử. Thay vào đó, mục đích là cung cấp một bảng thông báo thời gian thực có độ bảo mật cao và dành chỗ cho các giao thức phi tập trung khác để lưu trữ lâu dài hơn (Mục đích của giao thức đồng thuận Ethereum không phải là đảm bảo lưu trữ tất cả dữ liệu lịch sử mãi mãi. Thay vào đó, mục đích là là cung cấp một bảng thông báo thời gian thực có độ bảo mật cao và nhường chỗ cho các giao thức phi tập trung khác thực hiện việc lưu trữ lâu dài hơn. );

Thứ hai, Danksharding giảm chi phí DA, nhưng thời gian hạ cánh thực tế và các vấn đề về tính sẵn có của dữ liệu cũng cần được giải quyết.

Giảm chi phí DA: Trước bản cập nhật này, cần phải gọi calldata để giải phóng dữ liệu từ cuộn lên chuỗi chính Ethereum và phí gas để gọi mã này rất đắt, đây là khoản chi lớn nhất trong lớp 2. EIP4844 giới thiệu các đốm màu dữ liệu dưới dạng rollups Không gian dữ liệu bổ sung duy nhất sẽ giảm đáng kể chi phí lưu trữ, do đó giảm chi phí DA.

Thời gian hạ cánh thực tế còn dài và TPS có thể được cải thiện và lượng khí có thể giảm vẫn còn hạn chế, vì vậy điều này rất tốt cho việc tiếp tục phát triển các dự án lớp DA trong tương lai:

Trong bài viết về bảo vệ dữ liệu iablesecurity của polynya về danksharding, nó cho thấy rằng sẽ mất 2-5 năm để thực hiện;

Ngay cả khi nó hạ cánh, TPS nó có thể tăng và mức gas nó có thể giảm vẫn bị hạn chế:

EIP4844 hiện hỗ trợ 6 đốm màu và vấn đề mở rộng trong tương lai chỉ có thể được giải quyết bằng Danksharding;

Không gian khối Ethereum hiện tại là khoảng 200KB. Sau Danksharding, kích thước dự kiến trong thông số kỹ thuật là 32 megabyte, tức là cải thiện gấp 100 lần. Hiện tại, TPS của Ethereum là khoảng 15 và ở trạng thái lý tưởng hóa, nó sẽ là khoảng 1500 sau khi được tăng lên 100 lần, đây không phải là một sự cải thiện lớn về mức độ.

Do đó, thời gian triển khai dài + thay đổi thực tế hạn chế sẽ có lợi cho các dự án lớp DA. Một số dự án DA như Celestia và Eigenda vẫn có thể cạnh tranh với Danksharding nhờ chi phí rẻ hơn và TPS nhanh hơn. Các dự án DA mới như ETHstoragetopia cũng có thể lấp đầy khoảng trống thị trường trước đó.

Các vấn đề kỹ thuật như lưu trữ dữ liệu và các vấn đề về tính sẵn có của dữ liệu cũng cần được giải quyết:

Có hai chi phí chính của DA, một là chi phí băng thông mạng, hai là chi phí lưu trữ và bản thân 4844 không giải quyết được vấn đề lưu trữ và vấn đề băng thông của chuỗi khối

Blob sẽ được lưu trữ trên lớp đồng thuận Ethereum trong khoảng 3 tuần và sau đó sẽ bị xóa. Nếu bạn muốn lưu trữ toàn bộ hồ sơ lịch sử và cung cấp tất cả dữ liệu, các giải pháp hiện tại bao gồm: dapp tự lưu trữ dữ liệu liên quan đến chính nó và mạng cổng thông tin Ethereum (hiện đang được phát triển) đang được phát triển) hoặc các giao thức của bên thứ ba như trình khám phá khối, dữ liệu lịch sử trong BitTorrent hoặc lưu trữ tự phát của người dùng cá nhân.

Do đó, Proto-Danksharding sẽ mang lại lợi ích cho các giao thức lưu trữ, giao thức mô-đun và mạng mở rộng lưu trữ L1:

Nhu cầu gọi dữ liệu lịch sử sẽ dẫn đến một kênh phát triển mới cho các giao thức lưu trữ phi tập trung hoặc giao thức chỉ mục của bên thứ ba;

Các thỏa thuận mô-đun tiếp theo có thể thực hiện các giao dịch thông qua Rollup tốc độ cao, lớp giải quyết an toàn chịu trách nhiệm giải quyết và lớp khả dụng dữ liệu dung lượng lớn và chi phí thấp chịu trách nhiệm đảm bảo;

Nó phù hợp với mạng mở rộng lưu trữ L1, chẳng hạn như Ethstorage, có thể cung cấp giải pháp cấp hai cho lưu trữ có thể lập trình với chi phí lưu trữ thấp hơn.

3. Nâng cấp Cancun tốt cho đa dạng L2, L3, RAAS và tính khả dụng của dữ liệu cũng như các bản nhạc khác

Phân tích theo dõi L2:

Lớp trên cùng 2, năm dự án như ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (thuộc StarkWare) và HyperChain (thuộc zkSync) sẽ được hưởng lợi. Việc giảm phí lưu trữ do blob mang lại sẽ cải thiện đáng kể hàng loạt vấn đề về chi phí và khả năng mở rộng trước đây đã hạn chế sự phát triển của lớp 2 và tăng cường đáng kể thông lượng dữ liệu. chức năng, hệ sinh thái L3 đồng thời đa chuỗi tùy chỉnh cấp cao;

Khoảng cách về chi phí vận hành giữa Lớp 2 hạng hai và Lớp 2 chính thống sẽ được thu hẹp, giúp một số dự án nhỏ có nhiều cơ hội phát triển hơn, chẳng hạn như Aztec, Metis, Boba, ZKspace, layer2.finance, v.v.;

Mặc dù nhu cầu thực sự của các dự án chuỗi khối mô-đun vẫn đang được xác minh, nhưng các ngôn ngữ lập trình đa dạng vẫn có thể thực hiện được, chẳng hạn như Cario của Starkware, ngôn ngữ sê-ri Move, ngôn ngữ sê-ri C, c ++, C # và Go được Wasm hỗ trợ, có thể giới thiệu nhiều web2 hơn nhà phát triển.

Phân tích theo dõi Raas:

Bản thân ưu điểm của Raas nằm ở mức độ tùy biến cao, tùy chỉnh theo yêu cầu > chi phí thuần túy và hiệu quả nên việc giảm chi phí là một lợi thế lớn của Rollup tùy chỉnh.

Nhưng vấn đề với bản nhạc RAAS là nó có thể là OverHype và thậm chí còn có những nghi ngờ về bản thân bản nhạc RAAS. Đối mặt với sự cạnh tranh từ 5 layer2 hàng đầu và sự xuất hiện của nhiều DA mới, chúng ta phải đặt dấu hỏi liệu các dự án mới có thể tạo thành đường đua hay không.

Trước hết, lợi thế của việc triển khai chuỗi ứng dụng lớp 2 đầu tiên nằm ở tính toàn vẹn của khung mạng và tính bảo mật của hệ sinh thái liên chuỗi, và lợi thế của RAAS nằm ở khả năng tùy chỉnh và tự do của nó;

Tuy nhiên, các rào cản kỹ thuật RAAS của dòng OP và ZK hiện tại không mạnh và chúng vẫn đang ở giai đoạn testnet trong thời gian ngắn và không có tương tác sản phẩm thực tế.Xem xét tiến độ thực tế của RAAS, các hình thức kỹ thuật và lợi thế sinh thái của lớp 3 trong tương lai, nhu cầu thực tế đối với RAAS là đáng nghi ngờ.

Sê-ri OP: Mặc dù bản nâng cấp nền tảng +4844 của ngăn xếp OP đã mang lại một số cải tiến nhỏ về chi phí và hiệu quả, nhưng sức hấp dẫn của các cải tiến không mạnh;

Dòng ZK: Hiện tại, nhiều dự án hàng đầu đi theo lộ trình ZKEVM và chú ý nhiều hơn đến khả năng tương thích với Ethereum, vì vậy thiết kế mạch sẽ hy sinh hiệu quả nhất định và nó không được nhắm mục tiêu như dòng OP. Tuy nhiên, hầu hết các ZKRAAS hiện có trên thị trường vẫn sử dụng các dự án hàng đầu (chẳng hạn như ZkSync) để phân nhánh chuỗi và các rào cản vẫn chưa mạnh.

Vì vậy, trong ngắn hạn, OPRAAS vẫn còn một số dư địa để phát triển trước khi lớp 3 đổ bộ, về lâu dài, ZKRAAS và lớp 3 có thể là xu hướng trong tương lai.

ZKRAAS có nhược điểm về chi phí lớn hơn sau 4844 và nó tiêu tốn nhiều năng lượng tính toán hơn so với OP. Mặc dù chi phí tải lên L1 thấp hơn so với OP, nhưng đây chỉ là một phần giảm trong thùng so với chi phí của quy trình chứng minh, trong khi OP Ưu điểm là có thể nhanh chóng xây dựng hệ sinh thái trong thời gian ngắn, vẫn còn chỗ phát triển trước khi lớp 3 đổ bộ;

Đối với các ứng dụng DeFi thông thường và thị trường NFT, việc chuyển đổi tổng số không phải là một yêu cầu cứng nhắc. Chỉ các ứng dụng thanh toán hoặc trò chơi yêu cầu hiệu quả cao mới có nhu cầu tăng mạnh hơn. Trong tương lai, các dự án defi có thể ở trên l2, các dự án xã hội có thể ở trên l3 hoặc ngoài chuỗi, và cuối cùng là dữ liệu cốt lõi và các mối quan hệ được đặt trên l2. trò chơi chuỗi về cơ bản là Tiền và việc không thể lưu hành mã thông báo ra bên ngoài đã gây ra tắc nghẽn phát triển, cùng với sự xuất hiện của trò chơi trên toàn bộ chuỗi, sức hấp dẫn sinh thái của bản thân l3 lớn hơn nhiều so với trò chơi cuộn.

4. Nâng cấp Cancun cải thiện trải nghiệm của nhà phát triển và người dùng

Đề xuất quan trọng thứ hai của bản nâng cấp Cancun, SELFDESTRUCTremoval, sẽ cải thiện hơn nữa tính bảo mật của Ethereum. Đồng thời, đối với vấn đề cập nhật tài khoản theo thủ tục có thể tồn tại sau khi xóa, một mã hoạt động mới SETCODE đã được chuẩn bị để cải thiện tình trạng này;

Đề xuất thứ ba EIP1153 do Cancun nâng cấp bổ sung mã hoạt động lưu trữ tạm thời, thứ nhất có thể tiết kiệm xăng, thứ hai giải quyết vấn đề giao tiếp giữa các khung và cuối cùng mở đường cho thiết kế lưu trữ trong tương lai, chẳng hạn như cây Verkle sẽ không cần xem xét hoàn tiền của câu hỏi lưu trữ tạm thời;

EIP5656, đề xuất thứ tư của bản nâng cấp Cancun, giới thiệu hướng dẫn sao chép bộ nhớ MCOPY, có thể sao chép chính xác hơn các từ và câu mã, giúp cải thiện hiệu suất sao chép bộ nhớ khoảng 10%;

Đề xuất thứ năm của bản nâng cấp Cancun là EIP4788, có thể giúp giao tiếp giữa các giao thức và ứng dụng khác nhau trong mạng Ethereum hiệu quả và an toàn hơn, đồng thời cho phép thiết kế không tin cậy hơn cho nhóm đặt cược, giao thức bắc cầu và đặt lại;

Bản nâng cấp Cancun mới nhất (ngày 15 tháng 6, 23) đề xuất thêm các bản nâng cấp EIP lấy CL làm trung tâm: EIP6988, EIP7044 và EIP7045, giúp cải thiện chi tiết tính bảo mật và khả năng sử dụng của Ethereum, chẳng hạn như cải thiện Trải nghiệm của người cầm cố và cải thiện bảo mật mạng, v.v.

Trong số các đề xuất đã bị xóa, quá trình chuyển đổi SSZ->RLP đã khiến hai SSZEIP (EIP6475 và EIP6493) bị xóa khỏi bản nâng cấp Cancun; các đề xuất liên quan đến EOF lại bị xóa khỏi bản nâng cấp Cancun sau khi bị xóa khỏi bản nâng cấp Thượng Hải và hiện đang được xem xét có thể Nó sẽ được triển khai trực tiếp trong các bản nâng cấp hàng ngày sau này; EVMMAX cũng bị xóa khỏi Cancun để nâng cấp cùng với EOF vì nó là một tập hợp con của EIP liên quan đến việc triển khai EOF; xem xét các tác dụng phụ tiềm ẩn có thể tồn tại trong cách chuyển ETH, và sự cần thiết phải thông qua đề xuất Công việc lý luận, thử nghiệm và bảo mật, EIP5920 bị loại bỏ khỏi bản nâng cấp.

5. Mối quan hệ với zkml và trừu tượng hóa tài khoản

Ít ảnh hưởng đến zkml

ZKML là sự kết hợp giữa Bằng chứng tri thức bằng không (ZeroKnowledge) và Học máy (Machine Learning); sự kết hợp giữa mô hình blockchain và ML giải quyết các vấn đề về bảo vệ quyền riêng tư và khả năng kiểm chứng của học máy:

Bảo vệ quyền riêng tư: tính bảo mật của dữ liệu đầu vào, chẳng hạn như sử dụng một lượng lớn thông tin cá nhân làm dữ liệu để cung cấp cho máy đào tạo, tính bảo mật của thông tin cá nhân là yêu cầu chính; hoặc các tham số mô hình, như khả năng cạnh tranh cốt lõi của dự án, cũng cần được mã hóa để duy trì các rào cản cạnh tranh. Khi tồn tại các vấn đề về độ tin cậy như vậy, các mô hình ML sẽ bị cản trở trong việc thu thập các ứng dụng và dữ liệu quy mô lớn hơn.

Khả năng xác minh: Công nghệ bằng chứng không kiến thức có nhiều ứng dụng và ZKP cho phép người dùng biết tính chính xác của thông tin mà không cần xác minh. Và vì mô hình học máy yêu cầu nhiều tính toán nên mô hình ML có thể tạo bằng chứng thông qua ZK-SNARK, giảm kích thước bằng chứng và giảm nhu cầu về sức mạnh tính toán của ML.

Các yêu cầu lưu trữ của ZKML ít liên quan đến DA: cần có cấu trúc lưu trữ riêng biệt như Không gian và Thời gian và công nghệ cốt lõi của nó là giao thức bảo mật mới "Bằng chứng SQL".Hoặc kết nối dữ liệu trên chuỗi và ngoài chuỗi một cách đơn giản Định dạng SQL và tải kết quả trực tiếp vào hợp đồng thông minh;

ZK-SNARKs là dạng ZK chính trong ZKML, có thể thích ứng với các yêu cầu về sức mạnh tính toán của ML trên chuỗi. Với sự phát triển của mật mã, đặc biệt là bằng chứng SNARK đệ quy sẽ có lợi cho việc triển khai ZKML trên chuỗi:

ZK-SNARKs được đặc trưng bởi độ gọn cao. Sử dụng ZK-SNARKs cho phép người chứng minh tạo ra một bằng chứng ngắn và người xác minh không cần phải tương tác và chỉ cần thực hiện một lượng nhỏ phép tính để xác minh tính hợp lệ của nó. Điều này chỉ cần một người chứng minh Bản chất của việc tương tác với trình xác minh làm cho ZK-SNARK trở nên hiệu quả và thiết thực trong các ứng dụng thực tế, đồng thời phù hợp hơn với các yêu cầu về sức mạnh tính toán trên chuỗi của ML.

Hiện tại không thể đào tạo trên chuỗi và chỉ có thể lưu trữ kết quả tính toán ngoài chuỗi trên chuỗi:

Vấn đề ML hiện tại nhiều hơn do yêu cầu về sức mạnh tính toán không được đáp ứng và hiệu suất thấp do giới hạn thuật toán (không thể tính toán song song) Mô hình ZK lớn chứng tỏ cần có sức mạnh tính toán cao hơn, điều này không thể hỗ trợ trên chuỗi phổ biến hiện nay ZK-SNARK chỉ hỗ trợ quy mô nhỏ Bằng chứng không kiến thức ML về quy mô và số lượng tính toán nhỏ, nghĩa là hạn chế về sức mạnh tính toán là yếu tố chính ảnh hưởng đến sự phát triển của các ứng dụng chuỗi khối ZKML và chuỗi chỉ có thể lưu trữ kết quả tắt -xích tính toán.

** Tóm tắt tài khoản tốt **

Trước hết, bản nâng cấp Cancun có thể giảm chi phí bằng chứng ZKrollup ở một mức độ nhất định:

Phí giao dịch zkSync hiện tại phụ thuộc vào 3 khía cạnh:

Chi phí tài nguyên cố định mà người xác minh sử dụng để tạo và xác minh chứng chỉ SNARK là tương đối cao;

Phí gas khi người xác minh gửi bằng chứng SNARK cho mạng chính Ethereum, phần phí này sẽ tăng tương ứng do sự tắc nghẽn của mạng chính;

Phí dịch vụ mà người dùng trả cho người xác minh, bao gồm xác nhận giao dịch, gửi tin nhắn, v.v.

Do đó, nếu 4844 được giới thiệu, vấn đề tăng phí gas do tắc nghẽn mạng chính sẽ được giảm bớt và chi phí chứng minh ZKP có thể giảm ở một mức độ nhất định.Không nên đánh giá thấp xu hướng phát triển của dòng ZK.

Thứ hai, tính năng trừu tượng hóa tài khoản biến các giao dịch tx truyền thống thành các thao tác của người dùng, sau đó đóng gói các thao tác của người dùng thành các khối bằng ECDSA, chiếm nhiều dung lượng lưu trữ trên chuỗi hơn trước, vì vậy yêu cầu lưu trữ cao hơn;

Sau đó, trừu tượng hóa tài khoản và ZKrollup có thể bổ sung cho nhau:

Hiện tại, vấn đề trừu tượng hóa tài khoản là GasFee đắt đỏ, do có quá nhiều bước và liên quan đến hợp đồng thông minh nên có rất nhiều dữ liệu khiến GasFee trở nên đắt đỏ, Ưu điểm của ZKRollup là có thể giảm dữ liệu;

Tính trừu tượng của tài khoản gây khó khăn cho việc đảm bảo tính bảo mật: Vì AA liên quan đến nhiều hợp đồng nên tính bảo mật là một vấn đề. Tuy nhiên, sau khi L2 dần hình thành trong tương lai, lớp đồng thuận sẽ không còn thay đổi, hợp đồng thông minh sẽ có nhiều công dụng hơn và tính bảo mật trừu tượng hóa tài khoản cũng sẽ tăng lên.Điều này có thể được đảm bảo và với sự xác minh đáng tin cậy của ZKrollup, tính bảo mật sẽ được cải thiện hơn nữa.

Cuối cùng, khi xem xét sự phát triển của công nghệ AI, nó có thể giúp tăng cường tính bảo mật của các hợp đồng trực tuyến và tối ưu hóa các giao dịch hoặc các bước hoạt động trên chuỗi:

AI và bảo mật: Công nghệ AI có thể được sử dụng để tăng cường bảo mật và bảo vệ quyền riêng tư của các giao dịch trên chuỗi. Ví dụ: nền tảng bảo mật Web3 SeQure sử dụng AI để phát hiện và ngăn chặn các cuộc tấn công độc hại, gian lận và rò rỉ dữ liệu, đồng thời cung cấp cơ chế giám sát và cảnh báo theo thời gian thực để đảm bảo tính bảo mật và ổn định của các giao dịch trên chuỗi;

Tối ưu hóa AI và các hoạt động trên chuỗi: Các hoạt động trên chuỗi khối bao gồm giao dịch, thực hiện hợp đồng và lưu trữ dữ liệu. Thông qua khả năng phân tích và dự đoán thông minh của AI, các hoạt động trên chuỗi có thể được tối ưu hóa tốt hơn, đồng thời cải thiện hiệu quả và hiệu suất tổng thể. AI có thể giúp xác định các mẫu giao dịch, phát hiện hoạt động bất thường và đưa ra các đề xuất theo thời gian thực để tối ưu hóa phân bổ tài nguyên cho mạng chuỗi khối thông qua phân tích dữ liệu và đào tạo mô hình.

Do đó, việc nâng cấp Cancun sẽ dần dần mang lại lợi ích cho sự phát triển trừu tượng hóa tài khoản trong tương lai từ việc mở rộng không gian lưu trữ, đến sự bổ sung với ZKrollup và sau đó là sự kết hợp với công nghệ AI.

6. Nhìn lại lộ trình Ethereum, điều gì tiếp theo

Hiện tại, Layer2 không có hiệu suất tương tự như Solana (về độ trễ và thông lượng), cũng không có hiệu suất phân mảnh như Near, cũng như không có hiệu suất thực thi song song như Sui và Aptos. lãnh đạo;

Sau khi nâng cấp Cancun, người ta ước tính rằng một số thời điểm phát triển chính sẽ bao gồm hoàn toàn nhúng (2 ~ 5 năm), hạ cánh MEV và PBS (1 ~ 3 năm), trừu tượng hóa tài khoản (1 ~ 2 năm), ZK mọi thứ (3 ~ 6 năm) ), EOF và kinh nghiệm của nhà phát triển (bạn đã thấy tiện ích mở rộng bao nhiêu lần?).

Tai họa

Mục tiêu: Tập trung giải quyết vấn đề MEV.

Giải pháp: Giảm thiểu MEV ở lớp ứng dụng thông qua "Tách biệt Người đề xuất-Người xây dựng (PBS)". Tại thời điểm này, các đốm màu có thể được tối ưu hóa và các dịch vụ xác nhận trước hoặc bảo vệ trước quyền sở hữu có thể được giới thiệu.

PBS là sự tách biệt giữa trình tạo khối và trình sắp xếp. Bộ sắp xếp chỉ chịu trách nhiệm phân loại, bất kể chuỗi nào và người tạo khối không quan tâm đến giao dịch và trực tiếp chọn gói do bộ sắp xếp tạo ra và đặt nó vào chuỗi. Quá trình này sẽ làm cho toàn bộ quá trình trở nên công bằng hơn và giảm bớt vấn đề về MEV, đó là ý tưởng về MEV bên ngoài.

Mức độ hoàn thành của PBS hiện tại vẫn còn rất thấp và mức độ hoàn thiện hơn là hợp tác với các giải pháp MEV bên ngoài - mevboost của flashbot.

Phiên bản nâng cao của "Phân tách Người đề xuất-Người xây dựng được tôn trọng (ePBS)" có mức độ hoàn thành thấp hơn và chu kỳ dài hơn, ước tính rằng nó sẽ không được triển khai trong thời gian ngắn. Ngoài ra, còn có các phiên bản nâng cao của PEPC và Chuyển tiếp lạc quan, giúp nâng cao tính linh hoạt và khả năng thích ứng của khung PBS

TheVerge

Mục tiêu: Sử dụng cây Verkel để thay thế Merkle, giới thiệu giải pháp giảm thiểu độ tin cậy, cho phép các nút nhẹ có được bảo mật giống như các nút đầy đủ và giúp việc xác minh khối trở nên đơn giản và di động nhất có thể.

Đồng thời, ZKization của L1 rõ ràng đã được thêm vào lộ trình Verge, ZK sẽ là xu hướng chung của việc mở rộng và tăng tốc trong tương lai;

Giải pháp: Giới thiệu zk-SNARK để thay thế hệ thống bằng chứng cũ, bao gồm các ứng dụng khách nhẹ dựa trên SNARK; SNARK với các thay đổi trạng thái đồng thuận; EnshrinedRollups.

Cây Verkle là một giải pháp thay thế hiệu quả hơn cho cây Merkle dành riêng cho trạng thái không cần cung cấp đường dẫn từ mỗi nút chị em (các nút có chung cha mẹ) đến nút đã chọn, mà chỉ có chính đường dẫn đó làm bằng chứng. hiệu quả gấp 3 lần so với bằng chứng Merkle.

EnshrinedRollup đề cập đến một Rollup có một số loại tích hợp đồng thuận trên L1. Ưu điểm là nó kế thừa sự đồng thuận của L1 và không cần mã thông báo quản trị để thực hiện nâng cấp rollup. Đồng thời, bằng cách thực hiện các phép tính bên ngoài chuỗi và chỉ xuất bản kết quả đối với chuỗi khối, nó có thể Tăng số lượng giao dịch, nhưng khó khăn kỹ thuật khi thực hiện là tương đối lớn. Sự kết hợp của các bản tổng hợp này trong tương lai sẽ có thể đáp ứng hầu hết các nhu cầu của hệ sinh thái blockchain trong vài thập kỷ tới.

Thepurge

ThePurge đề cập đến mục tiêu đơn giản hóa giao thức bằng cách giảm yêu cầu lưu trữ để tham gia xác thực mạng. Điều này chủ yếu đạt được thông qua ngủ đông và quản lý lịch sử và trạng thái. Dữ liệu lịch sử không hoạt động (EIP-4444) cho phép khách hàng cắt bớt dữ liệu lịch sử cũ hơn một năm và ngừng cung cấp dịch vụ ở cấp độ P2P.

trạng thái ngủ đông. Khi nói đến việc xử lý tăng trưởng trạng thái, có hai mục tiêu chính: trạng thái không trạng thái yếu, đề cập đến mục tiêu chỉ sử dụng trạng thái để xây dựng các khối nhưng không xác minh nó; trạng thái được truy cập. Chế độ ngủ đông trạng thái sẽ giảm tổng số 20-50 GB các nút trạng thái cần lưu trữ.

Trong giai đoạn thanh lọc thứ năm, EIP4444 được ghi rõ ràng vào Lộ trình. EIP-4444 yêu cầu khách hàng xóa dữ liệu cũ hơn một năm. Đồng thời, có một số nhiệm vụ tối ưu hóa EVM trong giai đoạn này, chẳng hạn như đơn giản hóa cơ chế của Biên dịch trước GAS và EVM, v.v.;

TheSplurge

Trong giai đoạn thứ sáu cuối cùng của Splurge, EIP4337 cũng đã được đề cập. Là một đề xuất bố trí dài hạn cho hệ sinh thái ví, việc trừu tượng hóa tài khoản sẽ cải thiện hơn nữa tính dễ sử dụng của ví trong tương lai, bao gồm cả việc sử dụng stablecoin để thanh toán gas và ví phục hồi xã hội , vân vân.;