Hướng dẫn cho người mới bắt đầu
Gate Post
Livestream
Phòng trò chuyện
Các hoạt động tương lai
Tin tức
Gate Blog
Trang chủ
Đề xuất
Hot
Chuyên sâu
Đăng

Quá khứ, hiện tại và tương lai của việc nâng cấp Cancun

金色财经_vip

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ó thể 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. Ethereum Tác động của thuật toán đồng thuận khối lượng đối với 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ó.
  • Không gian hiện tại của mỗi khối Ethereum là khoảng 200~300 KB, 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 đó, Ethereum Layer 2 tập trung vào cách đưa một lượng lớn dữ liệu vào khối Trong không gian, tính bảo mật được đảm bảo thông qua bằng chứng gian lận và bằng chứng hợp lệ, đó 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 bản nâng cấp Cancun.
  • 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. Trước mắt Ethereum chỉ có thể xây dựng cấu trúc nhiều lớp lấy Rollup làm cốt lõi nên Cancun nâng cấp để giải quyết TPS, gas Phí và kinh 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? **

Một số nâng cấp quan trọng cuối cùng và mục tiêu của chúng

  • 2020năm12tháng1* Beacon chain chính thức được phát hành, mở đường cho việc nâng cấp POS*
  • 20218tháng5 Nâng cấp ở London, EIP1559 thay đổi mô hình kinh tế của Ethereum;*
  • 2022năm9tháng15* Nâng cấp Paris (The Hợp nhất), đã hoàn tất chuyển đổi POW POS;*
  • 2023năm4tháng12* Nâng cấp ở Thượng Hải, giải quyết vấn đề rút tiền cam kết;*
  • Mô hình kinh tế và các bản nâng cấp liên quan đến POS đã được hoàn thành và một vài bản 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 lộ trình Ethereum Các Dâng trào .
  • Mục tiêu: Đạt được hơn 100.000 TPS trong Rollup.
  • Có các kế hoạch 2, trên chuỗi và ngoài chuỗi:
  • 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 kế hoạch bảo vệ:
  • Tình thế 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ó để hoàn thành đồng bộ hóa dữ liệu nút mạng quy mô lớn, không chỉ không thể giải quyết tình trạng 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, điều này 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à Sản xuất khối tập trung + Xác minh phi tập trung + **Khả năng chống kiểm duyệt,**Điều này cũng liên quan đến tính khả dụng của dữ liệu được đề cập bên dưới Lấy mẫu (DAS), Block Producer-Packer Separation (PBS) và Danh sách kháng kiểm duyệt (Crlist). Ý nghĩa lớn nhất trong ý tưởng cốt lõi của Danksharding nằm ở việc biến Ethereum L1 thành một khu định cư (settlement) thống nhất và có sẵn dữ liệu (Data Availability) Sẵn có）层。

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

  • **Vì thế- danksharding **：
  • giới thiệu: Giúp giảm phí L2 và tăng thông lượng bằng cách giới thiệu các đốm màu , đồng thời là giải pháp phân đoạn trước để mở đường cho phân đoạn đầy đủ. Dự kiến sau proto-danksharding, việc triển khai danksharing sẽ mất từ 2-5 năm.
  • 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ể gánh nặng cho chuỗi chính. Áp lực lưu trữ cũng có thể làm giảm chi phí tổng số.
  • Tổng hợp đầy đủ
  • Giới thiệu: Tổng số được mở rộng hoàn toàn, 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 một ứ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 đ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 dài hạn của các nút khối lớn).

Cuộc họp các nhà phát triển cốt lõi của 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: Quy trình nâng cấp tập trung vào EIP đại khái như sau: Đầu tiên, EIP ban đầu được chấp nhận tại hội nghị 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 hay không nâng cấp hay không và Sau khi kiểm tra lần cuối, 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ác hội nghị được chia thành các loại 2, đó 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:
  • ** Cuộc họp lớp đồng thuận (Tất cả Sự đồng thuận của các nhà phát triển cốt lõi - ACDC), tập trung vào lớp đồng thuận Ethereum (bằng chứng cổ phần, chuỗi đèn hiệu, v.v.);**
  • Cuộc họp cấp điều hành ( Tất cả Giải pháp dành cho nhà phát triển cốt lõi - ACDE**), tập trung vào lớp thực thi của Ethereum (lịch trình EVM, **Gas , v.v.).
  • Có 3 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 duy trì mã, chịu trách nhiệm về máy 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;
  • Ethereum Magician: Một "diễn đàn" muố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 thảo luận, việc nâng cấp Cancun này có thể tạm chia thành các giai đoạn 5. ***

Giai đoạn 1 - Giới thiệu Chủ đề Nâng cấp

Giới thiệu các nhiệm vụ mớiproto-danksharding***,EOF và "tự hủy" * Opcode, thảo luận hời hợt 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ị tạm dừng 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 nhà phát triển đầu tiê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 là sơ bộ Người ta tin 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 EIP 4844, nhưng một nhóm nhà phát triển khác cho rằng sẽ hợp lý hơn nếu triển khai bản nâng cấp lớn hơn trong một bước.

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

Vào cuối 2022**, hội nghị Ethereum chủ yếu xoay quanh ***EOF và *EIP 4844 Thảo luận, đồng thời tiếp tục quảng cáo EIP 4844 Buổi lễ cài đặt trước đáng tin cậy cần thiết cho buổi lễ ***—KZG, các nhà phát triển sẽ có mặt trên *******23 **** Năm **** 1 **** tháng chính thức xác nhận nâng cấp **** 4844 **** nào sẽ xuất hiện trong ***

  • Vào ngày 22 tháng 11, EOF hoặc proto-danksharding đã được đề cập trong cuộc gọi hội nghị #149 của tất cả các nhà phát triển cốt lõi của Ethereum và 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 2 tháng 12, 22, Trent, người đứng đầu hệ sinh thái Ethereum Van Epps đã cập nhật EIP 4844 Tiến trình triển khai nghi thức thiết lập đáng tin cậy cần thiết để tạo Mã bảo mật được sử dụng trong 4844. Văn Epps hy vọ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 8.000 đến 10.000 khoản đóng góp và thời gian đóng góp công khai cho 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ẽ Khả năng vào Cancun là rất nhỏ, liên quan đến mã tự hủy, có những nhà phát triển ủng hộ việc thúc đẩy EIP vào thời điểm đó 4758, nhưng việc vô hiệu hóa trực tiếp opcode này sẽ phá vỡ một số ứng dụng và nhà phát triển tin rằng EIP này nên được cân nhắc lại một thời gian trước khi tạo trường hợp cạnh để bảo vệ loại hợp đồng này;
  • Trong cuộc họp 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 đã được thúc đẩy liên quan đến việc nâng cấp Cancun và EIP hiện tại 4844 Buổi lễ thiết lập đáng tin cậy bắt buộc đã sẵn sàng;
  • Trong cuộc họp lớp đồng thuận ngày 16/12/22 về EIP 4844, 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 yêu cầu liên quan đến cách các nút xử lý tính khả dụng của dữ liệu vượt quá một điểm nhất định sau khi cắt tỉa dữ liệu và một yêu cầu khi một khối Mã lỗi mới sẽ được đưa ra để cảnh báo các nút khi thông tin về các đốm màu bị thiếu trên
  • Trong cuộc họp nhà phát triển cốt lõi vào ngày 5 tháng 1, ngày 23 tháng 1, các nhà phát triển đã đạt được sự đồng thuận để 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, Beiko tại thời điểm này đã đề xuất quyết định sau hai tuần xem có nên đưa EOF vào Cancun đang được nâng cấp hay không;

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

Vào cuối 23********1 **********EOF chuyển đến Cancun để thăng chức sau khi được chuyển từ chương trình khuyến mãi ở Thượng Hải, kể từ đó *2 **** tháng chủ yếu xoay quanh ngoại trừ EOF và EIP Các đề xuất khác ngoài 4844 đã được thảo luận, đồng thời, ***EOF được đề xuất chuyển ra 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 nhà phát triển cốt lõi vào ngày 6 tháng 3 năm 23, đề xuất sơ bộ cho việc nâng cấp Cancun là: EIP 4788 (gốc trạng thái chuỗi đèn hiệu công cộng), EIP 2537 (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 opcode PAY mới) và EIP Việc triển khai kết hợp 6189 (để 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 nhà phát triển cốt lõi vào ngày 16 tháng 3, 23, ngoại trừ EOF và EIP 4844, các đề xuất sau đã được xem xét để đưa vào Cancun: định dạng SSZ, xóa TỰ TỬ, EIP 2537、EVMMAX、EIP
  1. Hướng dẫn SWAP và DUP không giới hạn, giới thiệu mã PAY và gốc trạng thái đèn hiệu trong EVM;
  • Trong cuộc họp 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, từ Erigon (EL) Một nhà phát triển trong nhóm khách hàng cho biết EOF 'Quá nhiều thay đổi' để cạnh tranh với EIP đề xuất cải tiến Ethereum trong bản nâng cấp Cancún sắp tới 4844, đã có đề xuất triển khai EOF trong đợt hard fork ngay sau khi nâng cấp Cancun;

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

Trong tháng 234, có định hướng rõ ràng cho các đề xuất sẽ được đưa vào bản nâng cấp Cancun và các nút chính nằm trong 4 ********************************************* *************************************************** ********** EIP, và **tim cũng đã thảo luận sâu hơn về các đề xuất thay thế, trong 4tháng Trong cuộc họp ngày 27,EIP 6780、*EIP 6475 và *EIP 1153 được xác định là có trong Cancun, đồng thời *EOF và EVMMAX (với * *****EOF **tập hợp con liên quan đến việc triển khai EIP) đã bị xóa khỏi bản nâng cấp Cancun, nâng cấp EOF chủ yếu giúp ích EVM thực hiện kiểm soát phiên bản và có thể chạy nhiều bộ quy tắc hợp đồng cùng một lúc, điều này sẽ giúp mở rộng Ethereum sau này, nhưng xem xét tính khả thi của toàn bộ nâng cấp, ** * EOFViệc nâng cấp có thể được tiếp tục với việc nâng cấp hàng ngày

  • 234tháng12*, quá trình nâng cấp Ethereum Shanghai đã hoàn tất;**
  • Trong cuộc họp nhà phát triển cốt lõi vào ngày 13.04.23, các nhà phát triển đã thảo luận về EIP 4844 (để hiển thị dữ liệu về gốc trạng thái CL trong EL), có ít nhất chín EIP khác đang được xem xét để nâng cấp, cụ thể là EIP 4844**, TỰ HẠI XÓA (EIP-6780, EIP 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIP（EIP 6601 và EIP 6690), SS thay đổi（EIP 6475、EIP 6493、EIP 6465、EIP 6404 và EIP 6466）、EIP 5656 và **EIP 6193；
  • Trong cuộc họp của nhà phát triển cốt lõi vào ngày 27 tháng 4 năm 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, với việc bổ sung các EIP sau: EIP 6780 (Thay đổi chức năng của opcode SELFDESTRUCT), EIP 6475 (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), EIP 1153 (thêm một opcode mới vào trạng thái hoạt động); thứ hai, EIP đang được xem xét nhưng chưa chính thức đưa vào nâng cấp là EIP 6913 (giới thiệu lệnh SETCODE), EIP 6493 (Xác định sơ đồ chữ ký cho các giao dịch được mã hóa SSZ), EIP 4788 (Hiển thị gốc khối chuỗi đèn hiệu trong tiêu đề khối EL), EIP 2537 (thêm đường cong BLS12-381 làm tiền biên dịch) và EIP 5656 (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** (** EOF ** phụ thuộc vào việc triển khai ** * EIP* subset) đã bị xóa khỏi bản nâng cấp Cancun. EOF Bản nâng cấp đã được chuyển ra khỏi Thượng Hải tại Hội nghị các nhà phát triển Ethereum vào đầu 20231*** và sau đó được nâng cấp từ * *** Từ cuối 1 đến đầu 4 trong 23****, nó sẽ xuất hiện trong bản nâng cấp Cancun theo mặc định, nhưng trong ** 23** **EOF ** lại bị xóa trong cuộc họp nhà phát triển vào 29, 4. **

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

23**5tháng chủ yếu hợp lý hóa và cải thiện các chi tiết của đề xuất cuối cùng,SSZ-> Các thay đổi RLP có nghĩa là hai ****** SSZ ở Cancun không còn cần thiết nữa EIP , vì vậy ****** EIP 6475 và 6493 sẽ được chuyển ra khỏi Cancun để nâng cấp. Đồng thời, trong buổi họp cốt cán ngày 26, Tim Beiko khuyến nghị rằng các cuộc trò chuyện trong tương lai xung quanh việc mở rộng phạm vi tiếp cận của Cancun nên được giới hạn trong năm EIP sau đây:*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/5/23, thảo luận về EIP được đề cập lần cuối 4788, trong khi thêm EIP 6987 và EIP Thảo luận trong 6475, hai đề xuất này lần lượt là về người xác minh 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, Tim Beiko 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ó lời khuyên rõ ràng từ các nhà phát triển, phạm vi nâng cấp Cancun sẽ vẫn ở trạng thái "mặc định" và cuộc thảo luận về EIP-4844 cho thấy rằng sự phát triển Tác giả đã đồng ý loại bỏ SSZ khỏi việc triển khai EL của EIP-4844, **nhưng nó vẫn chưa ảnh hưởng đến tiến trình tiếp 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à EIP 6969（EIP
  1. và EIP 5656 (hướng dẫn EVM hiệu quả để sao chép vùng bộ nhớ);
  • Các phát triển trong 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-ngày 23 tháng 5, 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 khuyến nghị rằng các cuộc trò chuyện trong tương lai xung quanh việc mở rộng phạm vi tiếp cận của Cancun nên được giới hạn trong năm EIP sau: EIP-5920**, 5656, 7069,* ** 4788* ** và ** 2530**. Các nhà phát triển sẽ xác nhận trong vài tuần tới ** Dencun** (****Deneb
  • phạm vi đầy đủ của Cancun****);**
  • 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 rằng EIP Thông số kỹ thuật 4844 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 EIP 4788 được đưa vào bản nâng cấp Cancun;
  • Trong cuộc họp 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 EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788；
  • 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 ý đến phần sau Mạng thử nghiệm EIP-4844 Devnet6 sẽ kiểm tra số lượng đốm màu tăng lên và đưa ra quyết định cuối cùng về vấn đề này trong vòng hai tuần, trong khi nhà nghiên cứu Michael Foundation của Ethereum Neuder đã đề xuất loại bỏ giới hạn đặt cược 32 ETH để giúp giảm tốc độ tăng trưởng của bộ xác thực đang hoạt động;
  • Trong cuộc họp ngày 22/6/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ù biên dịch trước qua EIP 2537, nhưng nó sẽ không được xem xét ở 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, giới hạn mục tiêu Tăng từ 2 lên 3, tăng giới hạn blob tối đa từ 4 lên 6 và 4844 mạng thử nghiệm Devnet #7 sắp ra mắt.

cuộc sống này

  • Nội dung cốt lõi là EIP 4844，即Proto-Danksharding
  • Phạm vi EIP cuối cùng cho bản nâng cấp Cancun này là: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. Trong khi đó, tại 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ề EIP 6988、** EIP 7044**、**EIP 7045 để đư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 KeyEIP

EIP 4844

  • Giới thiệu:
  • Tên của đề xuất EIP4844 là Proto-Danksharding, là tiền giao thức của phiên bản mở rộng bảo vệ đầy đủ Danksharding. Toàn bộ các kế hoạch bảo vệ thực sự dựa trên Rollup để mở rộng trên chuỗi. **Mục đích của chương trình là mở rộng lớp ** 2 **** **Rollup——****Bằng cách giúp L2 giảm phí và tăng thông lượng , đồng thời mở đường cho quá trình bảo vệ hoàn toàn (sharding). **
  • Trong cuộc gọi hội nghị ngày 23 tháng 2, các nhà phát triển Ethereum sẽ EIP Bản nâng cấp 4844 được đặt tên là Deneb, là tên của một ngôi sao cấp độ một trong chòm sao Cygnus, là EIP trên phiên bản GitHub có liên quan trong tương lai Tên của 4844 sẽ được cập nhật thành Deneb, trong cuộc họp vào ngày 1 tháng 6 năm 23, sẽ 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 buổi gặp mặt nhà phát triển vào ngày 23/06/23, các nhà phát triển đã chuẩn bị cập nhật EIP Địa chỉ được biên dịch sẵn của 4844. 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ẽ kích hoạt EIP bằng cách 4844 và 4788 lần lượt tạo hai tiền biên dịch dưới địa chỉ "0xA" và "0xB". Trong cuộc họp đồng thuận vào ngày 29 tháng 6, EIP đã sẵn sàng ra mắt Mạng thử nghiệm ngắn hạn chuyên dụng của 4844 Devnet #7。
  • EIP-4844** giới thiệu một loại giao dịch hoàn toàn mới - ****Blob Chuyển đổi **。
  • Hồ sơ blob:
  • Blob, tương tự như gói dữ liệu plug-in, lúc đầu chỉ có 128 Không gian lưu trữ của KB, 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 và nó đã được điều chỉnh thành 3/6 trong cuộc họp nhà phát triển vào ngày 9 tháng 6 năm 23. Nghĩa 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, tức là 384 KB, mục tiêu của mỗi khối Dung lượng Blob là 6, tức là 768 KB, có thể mang tới 16 đốm màu, tức là 2 MB;
  • 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 trước để tránh phải thực hiện các hard fork tiếp theo để mở rộng khối blob.
  • Blob trong ** KZG cam kết Hash ** Là một ** Hash, được sử dụng để xác minh dữ liệu, chức năng tương tự như ** Merkle ;
  • Nút đồng bộ hóa Blob trên chuỗi Sau Giao dịch, 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.
  • Chức năng 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 xa chính sổ cái nhiều lần;
  • Đối với các nút, tải xuống thêm 1 MB đến 2 MB dữ liệu blob cho 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 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;
  • Trên thực tế, bản thân nút không cần lưu trữ tất cả dữ liệu blob, 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 câu chuyện Danksharding**
  • **Mở rộng dung lượ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 lên 2MB lên 16MB lên 32MB, đảm bảo tính phi tập trung và bảo mật Trong khi đạt được khả năng mở rộng cao hơn;
  • **Phí thấp: **Các nhà phân tích của Bernstein chỉ ra rằng 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à hiện tại không thể đánh giá chi phí DA của nó, 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 chứng chỉ lưu trữ Lớp 2 lên 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í xuống 100~1000 lần, 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.
  • **DA****Giải pháp: Danksharding (một giải pháp bảo vệ cho việc mở rộng Ethereum) hiện tại, nếu việc mở rộng tiếp tục, gánh nặng của nút có thể quá lớn (****16mb **** ở trên) và không đủ dữ liệu (hiệu lực 30 ngày). Giải pháp: **
  • Lấy mẫu dữ liệu sẵn có (Dữ liệu Lấy mẫu khả dụng) - giảm gánh nặng cho các nút
  • Cắt dữ liệu trong Blob thành các đoạn dữ liệu và để 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 là được lưu trữ trong toàn bộ Trong sổ cái Ethereum, tiền đề là các nút cần phải đủ và phi tập trung;
  • DAS sử dụng hai công nghệ: xóa mã (Erasure Mã hóa) và Cam kết đa thức KZG (KZG Sự cam kết);
  • Tách người đề xuất-người đóng gói (PBS)——Đã giải quyết vấn đề phân công lao động của các nút, để 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 để phân phối mã hóa và để các nút có cấu hình hiệu suất thấp chịu trách nhiệm xác minh kiểm tra tại chỗ.
  • Một 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 một khối (Block), sau đó phát nó đến các nút khác để kiểm tra tại chỗ. Đối với trình tạo, vì khối lượng dữ liệu đồng bộ hóa và yêu cầu băng thông cao, vì vậy 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) và 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 (Block Header), nhưng đối với người đề xuất (Proposer) thì yêu cầu về dung lượng dữ liệu đồng bộ và băng thông thấp nên sẽ được phân quyền.
  • 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à sắp xếp và chèn ngẫu nhiên các giao dịch mà họ muốn lấy MEV do quyền xem xé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 Gas giới hạn đã đầ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 (Khối Tiêu đề) và phát sóng;
  • 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 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);
  • Hội đồng 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;
  • Hội đồng xác minh (Các Ủy ban) xác nhận phần thân của khối thắng cuộc và tiến hành bỏ phiếu xác minh (nếu khối được thông qua thì khối đó sẽ được tạo ra, nếu nhà đóng gói cố tình không đưa ra phần thân khối thì sẽ bị coi là khối đó không tồn tại).
  • Nghĩa:
  • Trước hết, người xây dựng (Builder) có nhiều quyền hơn trong việc đó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, sau đó Nó cần phải trả rất nhiều chi phí đấu thầu 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, khi đó lợi nhuận MEV mà nó thu được sẽ càng giảm và về tổng thể, nó sẽ ảnh hưởng đến phương tiện và giá trị thực tế nhận MEV;
  • 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. Đồng thời, số lượng người đóng gói rất ít Trong trường hợp , 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ế;
  • Có một số tác động đối với một số giải pháp MEV sử dụng đấu giá MEV.
  • Nghĩa:
  • EIP 4844 Thực ra là một phiên bản siêu đơn giản Danksharding**: **Nó cung cấp giao diện ứng dụng giống như Danksharding, bao gồm một opcode mới có tên là Data Hash; và một đối tượng dữ liệu mới gọi là Binary Đối tượng lớn, nghĩa là Blob;
  • proto-danksharding ** được sử dụng để triển khai toàn bộ thông số kỹ thuật ** Danksharding ** "ngoặc"** (** là định dạng giao dịch và quy tắc xác minh****) * * Đề xuất: Tuy nhiên, chưa triển khai phân đoạn nào và tất cả người xác minh cũng như 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 triển vọng dài hạn lại chọn proto-danksharding không EIP 4488 ** trực tiếp giảm phí của ** layer2 , 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:
  • EIP Sự khác biệt thực tế chính giữa 4488 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 thực hiện sharding hoàn chỉnh là một nhiệm vụ rất phức tạp (với việc lấy mẫu dữ liệu sẵn có, v.v.) và vẫn còn rất nhiều công việc phức tạp sau khi triển khai proto-danksharding, những sự phức tạp này sẽ được kiểm soát trên lớp đồng thuận. Sau khi proto-danksharding được triển khai, nhóm khách hàng của 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 để chuyển sang phân đoạn đầy đủ.
  • Để đạt được phân đoạn hoàn toàn, cần phải hoàn thành triển khai thực tế của ** PBS, bằng chứng ủ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 ** CL * * lớp, Nhà phát triển không cần điều chỉnh lại **: 4844 hiện triển khai một loại giao dịch mới, hoàn toàn giống với định dạng giao dịch, logic xác thực chéo đồng thuận và logic lớp thực thi cần có trong phân đoạn hoàn chỉnh, đồng thời bắt nguồn từ blobs , định giá gas độc lập tự điều chỉnh, để đạt được sharding hoàn chỉnh trong tương lai, cần phải hoàn thành việc triển khai thực tế PBS, lấy mẫu tính khả dụng của dữ liệu và bằng chứng ủy quyền, nhưng những sửa đổi này chỉ ở lớp CL và không yêu cầu các nhà phát triển lớp EL hoặc bản tổng số sửa đổi, điều này thuận tiện cho việc phát triển Bởi.

tiếp theo là TỰ HẠI loại bỏ ,EIP-6780 cuối cùng đã được xác định là giải pháp phù hợp nhất, nhưng nhà phát triển trên 26 Trong cuộc họp tim đã đề xuất thêm một opcode khác vào đề xuất nàySETCODE* để cho phép các tài khoản có lập trình vẫn được cập nhật***

TỰ HỦY loại 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ử dụng mà không cần sự đồng ý của tài khoản. có thể sửa đổi mã hoạt động của số dư tài khoản, điều này tiềm ẩn những 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 TÍCH. 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 một 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 thảo luận, cụ thể là 6780, 4758, 6046 và 6190, và EIP tiếp theo 6780 được coi 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.
  • EIP 6780: 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 tiện cập nhật/nâng cấp), đây là sự hấp thụ của EIP Ưu điểm của 4758, có thể cung cấp chỗ cho dapp để 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ả 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 liên kết rõ ràng với tài khoản gốc.
  • ĐÃ THAY ĐỔI: EIP này thực hiện các thay đổi để xóa TỰ TỬ, ngoại trừ hai trường hợp sau
  • Các ứng dụng chỉ được sử dụng để TỰ CHẾT để rút tiền sẽ vẫn hoạt động;
  • SELFDESTRUCT được sử dụng trong cùng một giao dịch trong hợp đồng không cần phải thay đổi.
  • Ý nghĩa: Tăng cường bảo mật
  • 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Ự PHÂN TÍCH, khi đó 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 dưới đây là các đề xuất về SELFDETRUCT sau đó đã bị xóa, vào 23năm*****4 *** 6780 đã chính thức được chọn trong cuộc họp của nhà phát triển cốt lõi trên **28 và ba đề xuất khác đã bị loại bỏ. là 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 hầu hết được sửa đổi bằng cách thay thế. ***

  • EIP-4758 (KHÔNG ĐƯỢC DÙNG): Vô hiệu hóa SELFDESTRUCT bằng cách thay đổi SELFDESTRUCT thành GỬI TẤT CẢ, thao tác này sẽ khôi phục tất cả số 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 liên kết rõ ràng với tài khoản gốc.
  • Thay đổi:
  • Opcode SELFDESTRUCT được đổi tên thành SENDALL, giờ chỉ chuyển tất cả ETH trong tài khoản cho người gọi, chương trình này không còn hủy mã và lưu trữ hoặc thay đổi số ngẫu nhiên;
  • Tất cả các khoản hoàn trả liên quan đến SELFDESTRUCT đã bị xóa
  • Nghĩa:
  • Giữ nguyên chức năng ban đầu 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 ĐƯỢC DÙNG): Thay thế TỰ HẠI bằng TẮT. 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 để mức tăng 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 **, **đặ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.
  • Nghĩa:
  • Đề xuất này linh hoạt hơn so với việc xóa TỰ TỬ trực tiếp khác.
  • EIP-6190 (KHÔNG ĐƯỢC DÙNG): Đã 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. 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 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í lưu trữ thứ 0 của hợp đồng được đặt thành hợp đồng bằng cách sử dụng opcode CREATE ( keccak256(contractAddress, nonce)) sẽ được cấp khi địa chỉ. 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 toàn bộ đế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.
  • Nghĩa:
  • Đượ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.

Tiếp theo là EIP 1153, đồng thời tiết kiệm gas, mở đường cho thiết kế lưu trữ trong tương lai

EIP 1153X

  • Tóm tắt: Mã cửa hàng tạm thời, thêm mã thao tác 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 một 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.
  • với reentrancy lock làm ví dụ, nó không thể dựa vào các khung trung gian để truyền đạt trạng thái của khóa: Giao tiếp SSTORE thông qua lưu trữ SLOAD 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, TLOAD ( 0xb3 ) và TSTORE ( 0xb4 ), đã được thêm vào EVM.
  • Lưu trữ tạm thời là riêng tư đối với hợp đồng sở hữu nó, 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:
  • nhập cảnh lại khóa;
  • 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(address người chi tiêu, số tiền uint256)；
  • 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 hành động như một phần của cuộc gọi lại và kiểm tra xem "til" có cân bằng ở cuối 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.
  • Nghĩa:
  • Tiết kiệm gas**, với 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 dọn bể chứa 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 hoàn lại tiền cho việc lưu trữ tức thời. **

Tiếp theo là 4788, nó có thể làm giảm giả định về niềm tin đối với nhóm cầm cố**

EIP 4788**：**X

  • Giới thiệu: Beacon block root trong EVM. *Cập nhật: Trong cuộc họp nhà phát triển vào ngày 15 tháng 6 năm 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, để phát triển DApp niềm tin của tác giả giảm thiểu truy cập.
  • ĐÃ THAY ĐỔI: Cam kết các gốc băm của từng 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 đó trong hợp đồng ở trạng thái thực thi và thêm mã thao tác mới để đọc hợp đồng đó.
  • Ý nghĩa: Đây là đề xuất sửa đổi mã đề xuất sửa đổi Máy ảo Ethereum (EVM) để nó có thể hiển thị trạng thái lớp hợp đồng (CL) root Dữ liệu ở lớp thực thi (EL) 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**. **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 một opcode sao chép bộ nhớ mới hiệu quả, nhưng nó 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ó *

EIP 5656X

  • Giới thiệu: MCOPY
  • Lệnh sao chép bộ nhớ. Cập nhật: 09.06.23, nhóm phát triển cho biết ban đầu họ bị chia rẽ về MCOPY vì trong khi nó giải quyết được vấn đề bảo mật, họ vẫn lo ngại về việc thêm nó vào băng thông triển khai + thử nghiệm cần thiết cho bản nâng cấp, nhưng cuối cùng đã đồng ý đưa vào EIP , nhưng sẽ bị xem xét xóa nếu nhà phát triển gặp phải các vấn đề về năng lực trong quá trình thử nghiệm hoặc ở phía máy khách. 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 sự sẵn có 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 nhất định chi phí khí được biên dịch sẵn, 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 rút gọn****EIP

Vào 236tháng15**, cuộc họp đồng thuận của nhà phát triển đã thảo luận trong *** nào EIP** tập trung vào CL được bao gồm trong Deneb, trong đó **** ** EIP 6988******、EIP 7044、******EIP 7045 *** *** được đề xuất tham gia. ***

EIP 6988**：**X

  • Tóm tắt: Ngăn không cho 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.

EIP 7044**：**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.

**EIP 7045 ****：**X

  • Phần mở đầu: chứng thực di chúc Phạm vi bao gồm vị trí kéo dài từ cửa sổ cuộn của một kỷ nguyên đến hai kỷ nguyên.
  • Ý nghĩa: Tăng cường an ninh mạng.

Xóa phân tích EIP

Vào ngày **** của 29***************************** ********************************************** Trong ** 160****ACDE cuộc họp của Ethereum, EVMMAX và EOF **** được xác nhận là đã bị xóa khỏi bản nâng cấp này, 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

**EVMMAX EIP **：

  • 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.
  • EIP 6601: Tiện ích mở rộng số học mô-đun EVM (EVMMAX)
  • Thay đổi: là EIP 5843 lần lặp, với EIP Sự khác biệt của 5843 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 các bộ nhớ EVM<->EVMMAX;
  • 6601 hỗ trợ 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, EIP-6601 nâng cấp thêm trên cơ sở này, bằng cách giới thiệu phần thiết lập, không gian bộ nhớ riêng biệt và mã lệnh mới, để Hoạt động số học mô-đun cung cấp tổ chức tốt hơn và linh hoạt trong khi hỗ trợ 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 tính 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 cho các hoạt động trên các giá trị lên tới 256 bit so với các opcode hiện có ADDMOD;
  • 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ố (ví dụ: MiMC/Poseidon) và EVM.
  • EIP 6690：
  • 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 tính 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à 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, có thể thực hiện các phép toán 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 lợi ích của EIP-6601.

**EOF thay đổi ****：

  • Giới thiệu: EOF là bản nâng cấp của EVM, đưa ra các tiêu chuẩn hợp đồng mới và một số opcode mới. chuỗi hướng dẫn) bytecode. 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.
  • EIP 663：
  • Tóm tắt: Hướng dẫn SWAP và DUP không hạn chế
  • Ý 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ử
  • EIP 3540：
  • 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 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 mã mới các tính năng cũ hoặc các tính năng cũ không dùng nữa.
  • 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 triển khai hợp đồng EOF, tức là tạo Xác thực thời gian có nghĩa là các hợp đồng không tuân theo định dạng EOF có thể bị ngăn triển khai. 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 .
  • Nghĩa:
  • 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 việc xác minh L2 (op), giảm chi phí gas của trình xác thực 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ông việc phân tích dữ liệu trên chuỗi công cụ.
  • EIP 3670：
  • 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 phù hợp với định dạng và hợp lệ, đồng thời việc triển khai các hợp đồng không tuân theo định dạng sẽ bị ngăn chặn mà không ảnh hưởng đến Legacy mã byte。
  • Ý nghĩa: Dựa trên vùng chứa được giới thiệu bởi 3540, EIP-3670 đảm bảo rằng mã trong hợp đồng EOF là hợp lệ hoặc ngăn không cho nó đượ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.
  • EIP 4200：
  • Giới thiệu:
  • Giới thiệu opcode dành riêng cho EOF đầu tiên: RJUMP, RJUMPI và RJUMPV, mã hóa điểm đến như giá trị ngay lập tứ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ỏ nhu cầu về các opcode JUMP và JUMPI hiện có để thực hiện jumpdest Thời gian chạy cần thiết để phân tích. EIP này dành cho động Việc bổ sung các bước nhảy.
  • So với các 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ừ động nhảy -> nhảy tĩnh), vì nhiều lần tĩnh nhảy là đủ.
  • Ý nghĩa: tối ưu hóa mạng lưới và giảm chi phí.
  • EIP 4750：
  • 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 CALLF Hai mã mới của và RETF triển khai một giải pháp thay thế 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, vì vậy động bị cấm nhảy.
  • Ý nghĩa: tối ưu code bằng cách chia code thành nhiều phần.
  • EIP 5450：
  • 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), gas có đủ hay không, và như thế.
  • 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ể gây ra tràn hoặc tràn ngăn xếp (ngăn xếp tràn/tràn). 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.

5tháng26****************************** *************************************************** *************************************** 4844****** Loại giao dịch có liên quan thay đổi từ SSZ thành RLP có nghĩa là Cancun's two a****** SSZ EIP , vì vậy ****** EIP 6475 và 6493** được chuyển ra khỏi Cancun để nâng cấp***

EIP 6475X

  • Giới thiệu: EIP Đề xuất đồng hành với 4844. 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 điều hành Ethereum lần thứ 161, đã có một cuộc thảo luận về EIP Thảo luận về định dạng xê-ri hóa SSZ cho 4844 cho thấy rằng ban đầu các nhà phát triển ưu tiên giới thiệu một phiên bản lặp lại sớm của định dạng SSZ sang EL thông qua các giao dịch blob và cuối cùng các nhà phát triển đã lên kế hoạch nâng cấp tất cả các loại giao dịch từ RLP lên SSZ, nhưng do lộ trình không rõ ràng và chắc chắn không được triển khai trên bản nâng cấp Cancun, các nhà phát triển đã cân nhắc việc loại bỏ SSZ khỏi EIP-4844. Sau nhiều cuộc thảo luận, các nhà phát triển đã đồng ý loại bỏ SSZ khỏi triển khai EL của EIP-4844,** nhưng không loại bỏ EIP6475****. **SSZ-> Các thay đổi RLP có nghĩa là hai SSZ ở Cancun không còn cần thiết nữa EIP: ** Do đó EIP 6475 và 6493 sẽ được chuyển ra khỏi Cancun để nâng cấp. **

EIP 6493X

  • 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: SSZ thay đổi
  • Giới thiệu: Đơn giản SerialiZe, là phương thức lập số sê-ri được sử dụng trên chuỗi đèn hiệu.
  • SS Những thay đổi cũng bao gồm ba đề xuất hỗ trợ khác, lần này chỉ có 6465 được giới thiệu.
  • EIP 6465: Rút gốc SSZ, xác định Merkle-Patricia hiện có Di chuyển các cam kết của Trie (MPT) sang rút tiền Số sê-ri hóa đơn giản (SSZ);
  • EIP 6404 / EIP 6466：
  • Cả hai đều xác định một Merkle-Patricia hiện có Các lời hứa Trie (MPT) đang trong quá trình chuyển sang Sê-ri hóa đơn giản (SSZ).
  • EIP-6404 — Gốc giao dịch SSZ
  • EIP-6466
  • Cơ sở nhận SSZ

Tim Beiko ***** đã đề xuất những phát triển trong tương lai xung quanh việc mở rộng Cancun trong cuộc họp dành cho nhà phát triển cốt lõi vào 5tháng26****** Các cuộc trò chuyện diễn ra giới hạn trong năm EIP sau đây:EIP 5920,5656,7069,4788 và *2537, các đề xuất tiếp theo sẽ được tạo trong phạm vi này. Theo dõi EIP 5656 và EIP 4788 đã được xác nhận là đề xuất nâng cấp chính thức, 5920, 7069 và 2537 đã xóa ở đâuEIP 5920 là do nhà phát triển lo ngại về các tác dụng phụ tiềm ẩn của cách chuyển ETH, cũng như công việc lý luận, thử nghiệm và bảo mật chưa hoàn thành nên từ bản nâng cấp di dời. ***

EIP 5920**：**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 chức năng 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 hoạt động khác ngoài ý muốn.
  • 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: addrthen val.
  • 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 gas**. ** *Cập nhật: 09.06.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 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.

EIP 7069X

  • Giới thiệu: Lệnh CALL đã sửa đổi
  • ĐÃ THAY ĐỔI: Đã giới thiệu ba lệnh 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 các quy tắc 63/64 được đưa ra, cần phải tính toán chính xác hơn một chút về lượng gas khả dụng của người gọi. 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ý.
  • **Hiện đang giới thiệu **63/64th Quy tắc:
  • Đã 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 2300 gas được sử dụng để 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à vì nó đặt một lượng gas cố định nên không có cách nào để mọi người xác định đây là miễn là giá xăng có thể được điều chỉnh Loại tính toán nào có thể hỗ trợ khí?
  • Ý nghĩa: ** Mở đường cho sự ra đời của ** EOF ** trong tương lai, thuận tiện hơn cho việc vận hành các hợp đồng lớn. **
  • Đã loại bỏ tùy chọn gas: các chỉ thị mới không cho phép chỉ định gas giới hạn, nhưng dựa vào "quy tắc 63/64" (chủ yếu đề cập đến việc định giá lại khí cho một số lượng lớn hoạt động IO trong EIP-150, làm tăng mức tiêu thụ khí của các hoạt động cụ thể) để hạn chế khí. Cải tiến quan trọng này giúp đơn giản hóa quy trình xung quanh quy tắc " Allowance ", 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 liên quan đến gas;
  • Sau khi giới thiệu đề xuất mới, người dùng luôn có thể vượt qua Out bằng cách gửi thêm gas trong giao dịch (tất nhiên, tùy thuộc vào giới hạn gas của khối) của lỗi Gas.
  • Trước đây khi tăng chi phí lưu trữ (ví dụ: EIP-1884 tăng gas cho một số mã nhất định), một số hợp đồng chỉ gửi một lượng gas hạn chế đến các cuộc gọi của họ đã bị phá vỡ bởi cơ chế chi phí mới. 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 thuận tiện hơn: Đã giới thiệu các chức năng tiện lợi trả về mã trạng thái chi tiết hơn: thành công (0), khôi phục (1), thất bại (2) và có thể được mở rộng trong tương lai.

EIP 2537**：**X

  • Giới thiệu: 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 như được biên dịch sẵn thành tập hợp cần thiết để thực hiện hiệu quả xác minh chữ ký BLS và thực hiện các hoạt động xác minh SNARK, v.v.
  • Ý 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**. **

PR 3175 *** Được đề cập nhưng không lọt vào danh sách rút gọn, không thảo luận thêm ***

**PR 3175 ****：**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, PR 3175 đang trong quá trình được định dạng dưới dạng EIP và sẽ được thay đổi thành EIP-6987, vì lý do bảo mật để ngăn người xác thực bị cắt giảm được chọn làm người đề xuất khối.

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.**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 công suất, bảo mật, tiết kiệm gas 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, như tối ưu hóa kết nối, giao tiếp và 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 opside 50% chi phí tổng hợp; 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 hy vọng sẽ giảm chi phí bởi 100 ~ 1000 lần.

2.** Nâng cấp Cancun Trong tương lai 2~5 năm Danksharding**, đó là thời kỳ phát triển vàng của các dự án tầng DA****

  • Lớp Giới hạn bảo mật trên là 2 phụ thuộc vào lớp DA mà nó sử dụng.Proto-Danksharding sẽ mang lại lợi ích cho 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ở về 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 (Các 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à để 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. ）；
  • **Thứ hai, **Danksharding **giảm chi phí của **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 để xuất bản dữ liệu từ cuộn lên chuỗi chính Ethereum và phí gas để gọi mã này rất đắt, đó là lớp Khoản thanh toán lớn nhất trong số 2, EIP 4844 giới thiệu blob dữ liệu dưới dạng không gian dữ liệu bổ sung duy nhất cho các bản tổng hợp, điều này sẽ giúp giảm đáng kể chi phí lưu trữ, do đó giảm chi phí DA.
  • Thời gian hạ cánh thực tế dài và ** TPS ** được cải thiện và giảm ** gas ** vẫn còn hạn chế, vì vậy nó tốt cho ** DA * * các dự án lớp trong quá trình phát triển tiếp theo:
  • tôi có thể nói về danksharding trong polynya Trong bài viết bảo mật dữ liệu sharding, người ta chỉ ra rằng sẽ mất 2-5 năm để thực hiện;
  • ** Ngay cả khi nó hạ cánh, nó có thể tăng ** TPS ** và giảm ** gas ** cường độ vẫn bị hạn chế:**
  • EIP 4844 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 200 KB. 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. Ở trạng thái lý tưởng hóa, nó sẽ vào khoảng 1500 sau khi được tăng lên 100 lần, đây không phải là một cải tiến lớn về độ lớn.
  • Do đó, thời gian dài để hạ cánh + Những thay đổi thực tế hạn chế sẽ có lợi DA Các dự án lớp, một số như Celestia, ** Dự án Eigenda** ** ** DA ** vẫn có thể vượt qua chi phí rẻ hơn và nhanh hơn ** TPS ** để cạnh tranh với ** Danksharding ** trong tương lai , Lưu trữ ETH Topia* và các dự án DA mới khác cũng có thể lấp đầy khoảng trống thị trường trước khi đổ bộ. **
  • Các vấn đề kỹ thuật như lưu trữ dữ liệu và các vấn đề về tính khả dụng 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ó, mạng cổng thông tin Ethereum (hiện đang được phát triển) hoặc các giao thức của bên thứ ba, chẳng hạn 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 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;
  • Mạng mở rộng lưu trữ L1 tốt, chẳng hạn như Eth lưu trữ, 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.**Lợi ích khi nâng cấp Cancun L2đa dạng, L3, RAAS và Tính khả dụng của dữ liệu và các bản nhạc khác

  • Phân tích theo dõi L2:
  • Head Layer2, chẳng hạn như Arbitrum Quỹ đạo、OP Ngăn xếp、Đa giác2.0、Fractal 5 dự án bao gồm Scaling (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ẽ làm cho loạt lớp hạn chế trước đó 2 Các vấn đề về chi phí phát triển và khả năng mở rộng đã được cải thiện rất nhiều và thông lượng dữ liệu đã được tăng cường đáng kể.Sau khi giải quyết vấn đề chi phí, lớp đầu 2 Sẽ có cơ hội tiếp tục triển khai hệ sinh thái L3 đồng thời đa chuỗi được tùy chỉnh cao cho các chức năng cụ thể;
  • Khoảng cách về chi phí vận hành giữa Layer2 hạng hai và Layer2 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 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 hỗ trợ bởi Wasm, có thể giới thiệu Nhiều nhà phát triển web2 hơn.
  • Phân tích theo dõi Raas:
  • Bản thân ưu điểm của Raas nằm ở khả năng 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 giảm chi phí là ưu điểm 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 của ** 5 ** người đứng đầu** layer2 **, sự xuất hiện của nhiều ** DA ** mới, các dự án mới có thể tạo thành một Chúng ta phải đặt một dấu hỏi trên đường đua. **
  • Đầu tiên, lớp tiêu đề 2 Ưu điểm của việc triển khai chuỗi ứng dụng 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 giữa các chuỗi và ưu điểm 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ế của RAAS là đáng nghi ngờ.
  • Cục OP: Dù OP nâng cấp nền tảng của ngăn xếp + Sự ra mắt của 4844 đã mang lại một sự gia tăng nhỏ về chi phí và hiệu quả, nhưng mức tăng không hấp dẫn lắm;
  • 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. Nhưng ZK hiện có trên thị trường Hầu hết RAAS 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ẬY, ngắn hạn OP RAAS** **Vẫn còn chỗ để phát triển trước khi ** layer3 ** hạ cánh. Về lâu dài, ** ZK RAAS ** và ** layer3 ** có thể là xu hướng trong tương lai. **
  • ZK RAAS có nhược điểm lớn hơn về chi phí sau 4844 và nó tiêu thụ 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, bản thân sức hấp dẫn sinh thái của 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 người dùng và nhà phát triển

  • Cancun nâng cấp đề xuất quan trọng thứ hai SELFDESTRUCT việc xóa sẽ cải thiện hơn nữa tính bảo mật của Ethereum. Đồng thời, đối với các sự cố cập nhật tài khoản có lập trình có thể xảy ra sau khi xóa, chúng tôi dự định giới thiệu mã hoạt động mới SETCODE để cải thiện tình trạng này;
  • EIP đề xuất thứ ba để nâng cấp Cancun 1153 thêm mã hoạt động lưu trữ tạm thời, trước tiên có thể tiết kiệm xăng, thứ hai giải quyết vấn đề liên lạc 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 vấn đề hoàn tiền của lưu trữ tạm thời kho;
  • EIP đề xuất thứ tư để nâng cấp Cancun 5656 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ã, điều này sẽ cải thiện hiệu suất sao chép bộ nhớ khoảng 10%;
  • Đề xuất thứ năm cho việc nâng cấp Cancun là EIP 4788 có thể làm cho việc giao tiếp giữa các giao thức và ứng dụng khác nhau trong mạng Ethereum trở nên hiệu quả và an toàn hơn, đồng thời cho phép các thiết kế không tin cậy hơn cho nhóm cầm cố, giao thức bắc cầu và đặt lại;
  • Cancun nâng cấp bản nâng cấp EIP lấy CL làm trung tâm mới nhất (ngày 15 tháng 6 năm 23): EIP 6988、EIP 7044、EIP 7045, 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 an ninh mạng.
  • Trong số các đề xuất bị xóa, SSZ-> Sự biến đổi của RLP làm cho hai SSZ EIP（EIP 6475 và EIP
  1. đã bị xóa khỏi bản nâng cấp Cancun; các đề xuất liên quan đến EOF đã 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 Shanghai và hiện tại người ta cho rằng nó có thể được triển khai trực tiếp trong bản nâng cấp hàng ngày sau này; EVMMAX là do một số EIP liên quan đến Tập hợp con triển khai EOF, do đó, nó cũng đã được chuyển ra khỏi Cancun để nâng cấp cùng với 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, 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 , EIP 5920 bị xóa khỏi 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à bằng chứng không có kiến thức (Zero kiến thức) và máy học (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 máy học:
  • 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 là khả năng cạnh tranh cốt lõi của dự án và mã hóa cũng được yêu cầu để 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ư những vấn đề này, các mô hình ML bị cản trở trong việc thu thập dữ liệu và ứng dụng 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.
  • Yêu cầu lưu trữ của ZKML ** ít liên quan đến ** DA **: **Cần thứ gì đó như Space Công nghệ cốt lõi của cấu trúc lưu trữ riêng biệt này là giao thức bảo mật mới "SQL proof", nói một cách đơn giản, nó là kho dữ liệu bên cạnh blockchain, cho phép các nhà phát triển kết nối on-chain và off-chain theo định dạng SQL đơn giản và dữ liệu. tải kết quả trực tiếp vào hợp đồng thông minh;
  • ZK-SNARKs ** là dạng chính của ** ZK ** trong ** ZKML ** và có thể thích ứng với phép tính trên chuỗi của ** **ML ** ** 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 ZKML Hạ cánh trên chuỗi:
  • ZK-SNARKs có đặc điểm là nhỏ 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, 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ó. chỉ cần một lần Bản chất của sự tương tác giữa người xác minh và người 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 của ML trên chuỗi.
  • Hiện 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:
  • 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 các hạn chế của thuật toán (không thể tính toán song song) Bằng chứng ZK mô hình lớn đòi hỏi sức mạnh tính toán cao hơn, không thể hỗ trợ trên chuỗi phổ biến hiện nay ZK-SNARK chỉ hỗ trợ bằng chứng không kiến thức ML với quy mô nhỏ và số lượng tính toán nhỏ, nghĩa là giới hạn 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ả của các lần tắt tính toán dây chuyền.

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

  • Trước hết, việc nâng cấp Cancun có thể giảm đến một mức độ nhất định ZK tổng số Bằng chứng Phí:
  • 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 bằng chứng SNARK và xác minh chúng 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í cho bằng chứng ZKP có thể giảm ở một mức độ nhất định. Mặc dù nó không nhiều so với chi phí tạo bằng chứng, nhưng xét rằng ZK vẫn đang ở giai đoạn đầu, không nên đánh giá thấp xu hướng phát triển trong tương lai của dòng ZK.
  • Thứ hai, sự trừu tượng hóa tài khoản biến các giao dịch ** tx ** truyền thống thành ** thao tác người dùng, và sau đó ** thao tác người dùng sử dụng ECDSA * * Được đóng thành khối, dung lượng lưu trữ trên chuỗi chiếm nhiều hơn trước nên yêu cầu lưu trữ cao hơn;
  • **Tiếp theo, tóm tắt tài khoản và ** ZK rollup có thể bổ sung cho nhau:
  • Vấn đề trừu tượng hóa tài khoản hiện nay là Gas Phí đắt, vì 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, dẫn đến Gas Phí đắt, và ZK Ưu điểm của Rollup 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 đề, nhưng sau khi L2 hình thành dần dần trong tương lai, lớp đồng thuận sẽ không bị 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 có thể được đảm bảo, với sự trợ giúp của ZK Xác minh đáng tin cậy của tổng số sẽ cải thiện hơn nữa bảo mật.
  • **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 bước hoạt động hoặc giao dịch trực tuyến:
  • 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;
  • AI và tối ưu hóa 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 việc 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ẽ từ việc mở rộng không gian lưu trữ đến việc tích hợp với ** ZK Tính bổ sung của rollup ** và sự kết hợp với công nghệ ** AI ** 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. **

**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 (về độ trễ và thông lượng) tương tự như ** Solana **, cũng như ** Near ** Chẳng hạn sharding và không có hiệu suất thực thi song song như ** Sui ** và ** Aptos **, bản nâng cấp Cancun đã cải thiện vị trí dẫn đầu của Ethereum; **
  • Sau khi nâng cấp Cancun, một số thời gian phát triển chính được ước tính Full-Danksharding** (2~5 năm), *MEV * và ** PBS hạ cánh (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?). **

Các 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 "Phân tách 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 máy sản xuất khối và máy phân loại. 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 các vấn đề về MEV, đó là ý tưởng về MEV bên ngoài.
  • Mức độ hoàn thành của PBS còn rất thấp, càng trưởng thành thì càng Phối hợp với các giải pháp MEV bên ngoài - mevboost bởi flashbots.
  • Phiên bản nâng cao của "Được tôn vinh Proposer-Builder Separation (ePBS)" có mức độ hoàn thành thấp hơn và chu kỳ dài hơn, và người ta ước tính rằng nó sẽ không được thực hiện trong thời gian ngắn. Ngoài ra, còn có các phiên bản lũy tiến của PEPC và Lạc quan Chuyển tiếp, giúp tăng cường tính linh hoạt và khả năng thích ứng của khung PBS

Các Bờ vực

  • 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à nhẹ nhà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 để thay đổi trạng thái đồng thuận; Được tôn trọng Rollup。
  • 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 nút cha) đến nút đã chọn, mà chỉ cần chính đường dẫn đó làm bằng chứng Một phần của Verkle bằng chứng hiệu quả gấp 3 lần so với bằng chứng Merkle.
  • Được lưu giữ Tổng số đề cập đến một Tổng số 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 tổng số. Đồ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.

Các thanh lọc

  • Các Thanh lọc đề 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. Lịch sử dữ liệu 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 phục vụ ở cấp độ P2P.
  • Trạng thái không hoạt độ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 một khối, nhưng không xác minh nó; trạng thái được truy cập. Trạng thái ngủ đông sẽ giảm trạng thái mà một nút cần lưu trữ tổng cộng 20-50 GB。
  • Trong giai đoạn thanh lọc thứ năm, EIP 4444 được ghi rõ ràng vào Lộ trình, EIP-4444 yêu cầu máy khách xóa dữ liệu cũ hơn một năm và ở giai đoạn này vẫn còn một số công việc tối ưu hóa EVM, chẳng hạn như đơn giản hóa cơ chế biên dịch trước GAS và EVM, v.v.;

Các Chi tiêu

  • Trong giai đoạn thứ sáu cuối cùng Splurge, EIP 4337 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 sử dụng stablecoin để thanh toán gas, ví phục hồi xã hội, v.v.;

Những tài liệu tham khảo:

  • Cập nhật cuộc họp nhà phát triển lõi Ethereum:
  • Ethereum Tất cả các nhà phát triển cốt lõi Gọi #148 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi Gọi #149 Viết lên
  • Ethereum Cuộc gọi lớp đồng thuận #99 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi Gọi #150 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi Gọi #151 Hãy viết ra giấy
  • Ethereum Cuộc gọi lớp đồng thuận #100 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #152 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #153 Hãy viết ra giấy
  • Ethereum Thảo luận diễn đàn Magician gốc:
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #156 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #157 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #158 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #159 Hãy viết ra giấy
  • Ethereum Tất cả Core Developers ution Call #160 Hãy viết ra giấy
  • Ethereum Cuộc gọi đồng thuận của tất cả các nhà phát triển cốt lõi #108 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #161 Hãy viết ra giấy
  • Ethereum Cuộc gọi đồng thuận của tất cả các nhà phát triển cốt lõi #109 Hãy viết ra giấy
  • Ethereum Tất cả các nhà phát triển cốt lõi ution Call #162 Hãy viết ra giấy
  • Ethereum Cuộc gọi đồng thuận của tất cả các nhà phát triển cốt lõi #110 Hãy viết ra giấy *Tim đã tweet về bản nâng cấp Ethereum Cancun mới nhất (06.09.23):
  • Lời kêu gọi đồng thuận của tất cả các nhà phát triển cốt lõi Ethereum #111 Hãy viết ra giấy
  • Ethereum Cuộc gọi đồng thuận của tất cả các nhà phát triển cốt lõi #112 Hãy viết ra giấy
  • Nội dung liên quan đến nâng cấp Ethereum:
  • Giới thiệu về mã tự hủy:
  • Khám phá đề xuất EVMMAX và BLS12-381
  • Ngoài EIP-4844, bản nâng cấp Cancun sẽ bao gồm những gì khác? Xem nhanh cuộc gọi đồng thuận mới nhất của Ethereum
  • Nội dung mới nào đã được thêm vào trong bản nâng cấp của Ethereum Shanghai?
  • tweet:
  • ĐƯỢC RỒI Mạo hiểm: Sau khi nâng cấp Ethereum Thượng Hải, Cancun nâng cấp các cơ hội đầu tư tiềm năng- Tin tức tầm nhìn xa
  • Ngoài EIP-4844 cấu hình cao, bản nâng cấp Cancun sẽ bao gồm những đề xuất nào?
  • V God: Chức năng EVM đáng cân nhắc xóa
  • Tiền thân của Danksharding Câu hỏi thường gặp
  • Được đề xuất bởi V God丨Hiểu sâu về lộ trình sharding của Ethereum, đọc báo cáo này là đủ
  • Bài viết tìm hiểu về Danksharding, kế hoạch nâng cấp mới của Ethereum
  • Giải mã những sự thật thú vị và những bí mật ẩn giấu trong lộ trình mới nhất của Ethereum
  • Vitalik: Tại sao SELFDESTRUCT gây hại nhiều hơn lợi cho hệ sinh thái của Ethereum
  • Tầm nhìn Ethereum:
  • Blockworks Nghiên cứu viên Brrr: Proto-Danksharding tăng tốc L1 của Ethereum như thế nào Khả năng mở rộng tổng số
  • Cuộc họp Ethereum ACDC lần thứ 111: Thảo luận về phạm vi cuối cùng của việc nâng cấp Deneb và ba đề xuất bao gồm EIP-7044
  • KOL Cái nhìn của Stacy Muur về sự phát triển của các giải pháp mở rộng quy mô Ethereum: OP Ngăn xếp、Tùy ý Quỹ đạo、Đa giác 2.0
  • So sánh theo chiều ngang của ba loại Tổng số: Tổng số cổ điển (Lạc quan/ZK Rollup）、Được tôn vinh Rollup、Sovereign Rollup
  • [AMA] Chúng tôi là Nghiên cứu của EF (Pt. 8: 07 tháng 7, 2022):
  • 3 bản nhạc phổ biến đáng suy nghĩ lại vào năm 2023
  • Montenegro EDCON Suy nghĩ về cuối năm 2023: Nhìn vào xu hướng ứng dụng và cơ sở hạ tầng
  • Trí tưởng tượng vô tận về khả năng kết hợp AI và Web3
  • AI+Web3: Khám phá sự tích hợp của trí tuệ nhân tạo và chuỗi khối
  • So sánh zk-rollup và op-rollup: phân tích tại sao zkSync hiện tại từ phương thức xác minh Phí gas cao
  • "Thêm khối lượng vào khối lượng": giải pháp trừu tượng hóa tài khoản trong kỷ nguyên Rollup
  • Giải thích chuyên sâu về ZKML: nguyên tắc kỹ thuật, kịch bản ứng dụng, lợi thế và thách thức
  • ZKML: công nghệ triển khai mô hình tích hợp AI và chuỗi khối để bảo vệ quyền riêng tư
  • khả thi dữ liệu bảo mật sharding
  • Đối thoại với Qi, người sáng lập EthStorage Zhou | Tính khả dụng của dữ liệu và lưu trữ phi tập trung
  • Đọc phiên bản mới nhất của lộ trình phát triển Ethereum trong một bài viết
  • Về không gian Và Giới thiệu ngắn gọn về Thời gian
  • Đề xuất ban đầu:
  • EIP 4844：
  • EIP 6780：
  • EIP 1153：
  • EIP 5920：
  • EIP 5656：
  • EIP 7069：
  • EIP 4788：
  • EIP 2537：
  • EVMMAX EIP：
  • EIP 6601：
  • EIP 6990：
  • EOF thay đổi：
  • EIP 663：
  • EIP 3540：
  • EIP 3670：
  • EIP 4200：
  • EIP 4750：
  • EIP 5450：
  • EIP 6475：
  • EIP 6493：
  • PR 3175：
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
  • Phần thưởng
  • Bình luận
  • Chia sẻ
Bình luận
0/400
Không có bình luận
  • Ghim
sơ đồ trang web
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate.io
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)
    • Về chúng tôiCơ hội nghề nghiệpĐối tácThoả thuận người dùngCảnh báo rủi roChính sách bảo mậtCookie PolicyPhương tiện truyền thông100% Bằng chứng dự trữLicenseBảo mậtQuyền lợi của người dùng GTGate ChainLịchThực thi pháp luậtHội nghị thượng đỉnhGate Ventures
    Mua coinBán coinGiao dịch giao ngayGiao dịch FuturesToken đòn bẩyStartupNFTGate PayGate LifeThẻ quà tặngGate OTCGate CharityThẻ GateGate Shop
    Lợi ích VIPĐề xuất & Phản hồiThông báoTiêu chuẩn thu phíTrung tâm hỗ trợGửi yêu cầu hỗ trợĐăng ký niêm yết coinBảo mật hợp đồngTrung tâm phát triểnXác minh kênh chính thức Đăng ký thương gia P2PĐăng ký Blue V P2PChương trình Affiliate
    Gate LearnKhóa học về tiền điện tửThuật ngữ về tiền điện tửThị trường tiền điện tửBig DataBitcoin Halving
    Gate.io © 2013-2025.