Một trong những thách thức của Ethereum là mặc định, bất kỳ giao thức chuỗi khối nào cũng tăng dần về kích thước và phức tạp theo thời gian. Điều này xảy ra ở hai nơi:

• Dữ liệu lịch sử: bất kỳ giao dịch nào được thực hiện và bất kỳ tài khoản nào được tạo ra tại bất kỳ điểm nào trong lịch sử đều cần được lưu trữ bởi tất cả các khách hàng mãi mãi, và được tải về bởi bất kỳ khách hàng mới nào thực hiện đồng bộ đầy đủ với mạng. Điều này làm tăng tải và thời gian đồng bộ của khách hàng theo thời gian, ngay cả khi khả năng của chuỗi vẫn giữ nguyên.
• Đặc điểm giao thức: việc thêm một tính năng mới dễ dàng hơn là loại bỏ một tính năng cũ, dẫn đến sự phức tạp của mã nguồn tăng theo thời gian.

Để Ethereum tồn tại trong dài hạn, chúng ta cần một áp lực đối chống mạnh mẽ với cả hai xu hướng này, giảm độ phức tạp và đồng thời giảm độ phình to theo thời gian. Nhưng đồng thời, chúng ta cũng cần bảo tồn một trong những thuộc tính quan trọng làm cho các chuỗi khối trở nên xuất sắc: tính bền vững. Bạn có thể đặt một NFT, một ghi chú tình yêu trong dữ liệu giao dịch hoặc một hợp đồng thông minh chứa một triệu đô la trên chuỗi, đi vào một hang động trong mười năm, ra ngoài và thấy nó vẫn đang đợi bạn đọc và tương tác với nó. Đối với dapps để cảm thấy thoải mái khi hoàn toàn phi tập trung và loại bỏ các khóa nâng cấp của họ, họ cần tự tin rằng các phụ thuộc của họ sẽ không được nâng cấp theo cách gây hỏng chúng - đặc biệt là L1 chính nó.

The Purge, lộ trình năm 2023.

Cân bằng giữa hai nhu cầu này, và giảm thiểu hoặc đảo ngược sự phình to, phức tạp và phân rã trong khi vẫn duy trì tính liên tục, là hoàn toàn có thể nếu chúng ta đặt tâm trí vào nó. Các sinh vật sống có thể làm điều đó: trong khi hầu hết già đi theo thời gian, một số ít may mắn không. Even social systems can có tuổi thọ cực kỳ lâu dài. Trong một số trường hợp, Ethereum đã cho thấy những thành công: công việc chứng thực đã biến mất, mã lệnh SELFDESTRUCT đã phần lớn biến mất và các nút beacon chain đã lưu trữ dữ liệu cũ chỉ lên đến sáu tháng. Tìm ra con đường này cho Ethereum một cách tổng quát hơn và tiến tới một kết quả cuối cùng ổn định trong dài hạn là thách thức cuối cùng của sự mở rộng dài hạn, bền vững kỹ thuật và thậm chí là an ninh của Ethereum.

The Purge: mục tiêu chính

• Giảm yêu cầu lưu trữ của khách hàng bằng cách giảm hoặc loại bỏ nhu cầu lưu trữ vĩnh viễn tất cả lịch sử của mỗi nút, và có lẽ cuối cùng là cả trạng thái
• Giảm độ phức tạp của giao thức bằng cách loại bỏ các tính năng không cần thiết

Trong chương này

• Lịch sử hết hạn
• Hết hạn trạng thái
• Dọn dẹp tính năng

Lịch sử hết hạn

Vấn đề nào nó giải quyết?

Đến thời điểm viết bài này, một nút Ethereum đồng bộ đầy đủ yêu cầu khoảng 1.1 terabytekhông gian đĩa chokhách hàng thực hiệnVà một vài trăm gigabyte khác cho khách hàng thống nhất. Hầu hết đều là lịch sử: dữ liệu về các khối lịch sử, giao dịch và biên nhận, phần lớn trong số đó đã có một vài năm tuổi. Điều này có nghĩa là kích thước của một nút tiếp tục tăng lên hàng trăm gigabyte mỗi năm, ngay cả khi giới hạn gas không tăng lên.

Điều đó là gì, và nó hoạt động như thế nào?

Một tính năng giúp đơn giản hóa vấn đề lưu trữ lịch sử là vì mỗi khối chỉ định đến khối trước đó thông qua một liên kết băm (và khác cấu trúc) having consensus on the present is enough to have consensus on history. As long as the network has consensus on the latest block, any historical block or transaction or state (account balance, nonce, code, storage) can be provided by any single actor along with a Merkle proof, and the proof allows anyone else to verify its correctness. While consensus is an N/2-of-N trust model, history is a Mô hình tin cậy 1-trong-N.

Điều này mở ra rất nhiều tùy chọn về cách chúng ta có thể lưu trữ lịch sử. Một tùy chọn tự nhiên là một mạng nơi mỗi nút chỉ lưu trữ một phần trăm nhỏ của dữ liệu. Đây là cách mà các mạng torrent đã hoạt động trong nhiều thập kỷ: trong khi mạng tổng thể lưu trữ và phân phối hàng triệu tệp, mỗi người tham gia chỉ lưu trữ và phân phối một số ít tệp. Có thể ngược lại, phương pháp này thậm chí không nhất thiết làm giảm tính mạnh mẽ của dữ liệu. Nếu, bằng cách làm cho việc chạy nút trở nên phù hợp hơn, chúng ta có thể có được một mạng với 100.000 nút, trong đó mỗi nút lưu trữ 10% ngẫu nhiên của lịch sử, sau đó mỗi mảnh dữ liệu sẽ được nhân bản 10.000 lần - chính xác cùng một hệ số nhân bản như mạng 10.000 nút nơi mỗi nút lưu trữ tất cả.

Hôm nay, Ethereum đã bắt đầu di chuyển khỏi mô hình mọi nút lưu trữ tất cả lịch sử mãi mãi. Các khối đồng thuận (tức là các phần liên quan đến đồng thuận chứng cứ cổ phần) chỉ được lưu trữ trong khoảng ~6 tháng. Blobs chỉ được lưu trữ trong khoảng ~18 ngày.EIP-4444Mục tiêu của là giới thiệu một khoảng thời gian lưu trữ một năm cho các khối và biên lai lịch sử. Một mục tiêu dài hạn là có một khoảng thời gian cân đối (có thể là ~18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ mọi thứ, sau đó có một mạng ngang hàng được tạo thành từ các nút Ethereum lưu trữ dữ liệu cũ hơn theo một cách phân tán.

Mã hóa đánh mất có thể được sử dụng để tăng tính ổn định trong khi vẫn giữ nguyên hệ số sao chép. Trong thực tế, các khối đã được mã hóa đánh mất để hỗ trợ lấy mẫu sẵn có dữ liệu. Giải pháp đơn giản nhất có thể là tái sử dụng mã hóa đánh mất này và đưa dữ liệu khối thực thi và đồng thuận vào các khối.

Có những liên kết nào đến nghiên cứu hiện tại?

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrents và EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
• Mạng lưới cổng: https://ethereum.org/en/developers/docs/networking-layer/portal-network/
• Mạng cổng và EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308
• Lưu trữ và truy xuất phân tán các đối tượng SSZ trên Cổng thông tin:https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• Cách tăng giới hạn gas (Paradigm): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

Còn gì để làm, và các sự đánh đổi là gì?

Công việc chính còn lại liên quan đến việc xây dựng và tích hợp một giải pháp phân tán cụ thể để lưu trữ lịch sử - ít nhất là lịch sử thực thi, nhưng cuối cùng cũng bao gồm sự nhất quán và blobs. Các giải pháp dễ nhất cho việc này là (i) đơn giản chỉ cần giới thiệu một thư viện torrent hiện có và (ii) một giải pháp gốc Ethereum được gọi là gate.mạng Cổng. Khi một trong hai yếu tố này được giới thiệu, chúng ta có thể bật EIP-4444. EIP-4444 không yêu cầu một hard fork, mặc dù nó đòi hỏi một phiên bản giao thức mạng mới. Vì lý do này, có giá trị trong việc kích hoạt nó cho tất cả các máy khách cùng một lúc, vì nếu không có nguy cơ máy khách gặp sự cố khi kết nối với các nút khác mong đợi tải xuống toàn bộ lịch sử nhưng thực sự không nhận được nó.

Sự đánh đổi chính là việc chúng ta cố gắng đến đâu để có sẵn dữ liệu lịch sử “cổ xưa”. Giải pháp dễ dàng nhất là đơn giản là ngừng lưu trữ lịch sử cổ xưa từ ngày mai, và phụ thuộc vào các nút lưu trữ cũ và các nhà cung cấp trung tâm khác nhau để sao chép. Điều này thì dễ dàng, nhưng làm suy yếu vị thế của Ethereum như một nơi lưu trữ hồ sơ vĩnh viễn. Con đường khó khăn, nhưng an toàn hơn, là xây dựng và tích hợp mạng torrent để lưu trữ lịch sử một cách phân tán. Ở đây, có hai chiều của “chúng ta cố gắng đến đâu”:

1. Chúng tôi cố gắng đến mức nào để đảm bảo rằng một tập hợp các nút cực kỳ lớn thực sự đang lưu trữ tất cả dữ liệu?
2. Chúng ta tích hợp lưu trữ lịch sử vào giao thức như thế nào?

Một cách tiếp cận cực đoan dành cho (1) sẽ liên quan đếnchứng minh việc giữ chỗ: thực tế yêu cầu mỗi nhà xác minh chứng cứ cổ phần lưu trữ một phần trăm lịch sử và thường xuyên kiểm tra mật mã rằng họ đã làm như vậy. Một cách tiếp cận ôn hòa hơn là đặt tiêu chuẩn tự nguyện cho phần trăm lịch sử mà mỗi client lưu trữ.

Đối với (2), việc triển khai cơ bản chỉ liên quan đến việc thực hiện công việc đã được thực hiện ngày hôm nay: Portal đã lưu trữ các tệp ERA chứa toàn bộ lịch sử Ethereum. Việc triển khai kỹ lưỡng hơn sẽ liên quan đến việc thực sự kết nối điều này với quá trình đồng bộ hóa, để nếu ai đó muốn đồng bộ hóa nút lưu trữ lịch sử đầy đủ hoặc nút lưu trữ, họ có thể làm như vậy ngay cả khi không có nút lưu trữ nào khác tồn tại trực tuyến, bằng cách đồng bộ hóa trực tiếp từ mạng Cổng thông tin.

Nó tương tác như thế nào với các phần khác của lộ trình?

Giảm yêu cầu lưu trữ lịch sử có thể coi là quan trọng hơn cả trạng thái không có trạng thái nếu chúng ta muốn làm cho việc chạy hoặc quay một nút trở nên rất dễ dàng: trên tổng số 1,1 TB mà một nút cần có, khoảng 300 GB là trạng thái và khoảng 800 GB còn lại là lịch sử. Tầm nhìn về một nút Ethereum chạy trên đồng hồ thông minh và chỉ mất vài phút để cài đặt chỉ có thể đạt được nếu cả trạng thái không có trạng thái và EIP-4444 được thực thi.

Giới hạn lưu trữ lịch sử cũng làm cho việc hỗ trợ các phiên bản gần đây của giao thức trở nên khả thi hơn đối với các thiết lập mới của nút Ethereum, cho phép chúng trở nên đơn giản hơn rất nhiều. Ví dụ, nhiều dòng mã có thể được loại bỏ an toàn bây giờ khi các khe lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được hoàn toàn điền đầy.Đã xóaBây giờ khi việc chuyển đổi sang chứng chỉ cổ phần đã trở thành quá khứ, khách hàng có thể an toàn xóa toàn bộ mã liên quan đến chứng chỉ công việc.

Hết hạn trạng thái

Vấn đề nào nó giải quyết?

Dù chúng ta loại bỏ nhu cầu lưu trữ lịch sử cho các máy khách, yêu cầu lưu trữ của một máy khách sẽ tiếp tục tăng lên, khoảng 50GB mỗi năm, do sự tăng trưởng liên tục của trạng thái: số dư và số nonce của tài khoản, mã hợp đồng và lưu trữ hợp đồng. Người dùng có thể trả một lần để gánh nặng cho các máy khách Ethereum hiện tại và tương lai mãi mãi.

Trạng thái khó “hết hạn” hơn lịch sử, vì EVM được thiết kế căn bản dựa trên giả định rằng một khi một đối tượng trạng thái được tạo ra, nó sẽ luôn tồn tại và có thể được đọc bởi bất kỳ giao dịch nào vào bất kỳ lúc nào. Nếu chúng ta giới thiệu tính vô trạng thái, có một lập luận rằng có lẽ vấn đề này không quá tồi tệ: chỉ có một lớp chuyên biệt của người xây dựng khối cần phải thực sự lưu trữ trạng thái, và tất cả các nút khác (thậm chídanh sách bao gồmsản xuất!) có thể chạy mà không cần trạng thái. Tuy nhiên, có một lập luận rằng chúng ta không muốn phụ thuộc quá nhiều vào trạng thái không có, và cuối cùng chúng ta có thể muốn hết hạn trạng thái để duy trì Ethereum phi tập trung.

Đó là gì, và nó hoạt động như thế nào?

Hôm nay, khi bạn tạo một đối tượng trạng thái mới (có thể xảy ra theo một trong ba cách: (i) gửi ETH đến một tài khoản mới, (ii) tạo một tài khoản mới với mã, (iii) thiết lập một khe cắm lưu trữ chưa từng chạm đến trước đó), đối tượng trạng thái đó sẽ tồn tại mãi mãi. Điều chúng tôi muốn thay vào đó, là để các đối tượng tự động hết hạn theo thời gian. Thách thức chính là làm điều này một cách hoàn thành ba mục tiêu:

1. Hiệu quả: không đòi hỏi một lượng lớn tính toán phụ để chạy quá trình hết hạn
2. Thân thiện với người dùng: nếu ai đó đi vào hang động trong năm năm và quay lại, họ sẽ không mất quyền truy cập vào các vị trí ETH, ERC20, NFT, CDP của họ…
3. Độ thân thiện với nhà phát triển: nhà phát triển không nên phải chuyển sang một mô hình tư duy hoàn toàn xa lạ. Ngoài ra, các ứng dụng đã cố định hiện tại và không cập nhật nên tiếp tục hoạt động tương đối tốt.

Dễ dàng giải quyết vấn đề mà không cần đạt được những mục tiêu này. Ví dụ, bạn có thể khiến mỗi đối tượng trạng thái cũng lưu trữ một bộ đếm cho ngày hết hạn của nó (có thể được mở rộng bằng cách đốt ETH, điều này có thể xảy ra tự động bất kỳ lúc nào nó được đọc hoặc viết), và có một quy trình lặp lại các trạng thái để loại bỏ các đối tượng trạng thái hết hạn. Tuy nhiên, điều này tạo ra tính toán phụ (và thậm chí là yêu cầu lưu trữ), và nó chắc chắn không đáp ứng yêu cầu thân thiện với người dùng. Nhà phát triển cũng sẽ gặp khó khăn khi suy luận về những trường hợp biên liên quan đến giá trị lưu trữ đôi khi được đặt lại thành không. Nếu bạn làm cho hợp đồng hẹn hết hạn trên toàn bộ hợp đồng, điều này làm cho cuộc sống kỹ thuật dễ dàng hơn cho nhà phát triển, nhưng nó làm cho kinh tế khó hơn: nhà phát triển sẽ phải suy nghĩ về cách “đi qua” chi phí lưu trữ đang diễn ra cho người dùng của họ.

Đây là những vấn đề mà cộng đồng phát triển lõi Ethereum đã đấu tranh suốt nhiều năm, bao gồm các đề xuất như “cho thuê blockchain“ và “regenesisCuối cùng, chúng tôi kết hợp những phần tốt nhất của các đề xuất và hội tụ vào hai danh mục của “các giải pháp tệ nhất nhất được biết”:

• Giải pháp hết hạn trạng thái một phần
• Đề xuất hết hạn trạng thái dựa trên địa chỉ.

Hết hạn trạng thái một phần

Các đề xuất hết hạn trạng thái một phần đều hoạt động theo cùng một nguyên lý. Chúng tôi chia trạng thái thành các phần. Mọi người lưu trữ vĩnh viễn “bản đồ cấp cao” của những phần trống hoặc không trống. Dữ liệu trong mỗi phần chỉ được lưu trữ nếu dữ liệu đó đã được truy cập gần đây. Có cơ chế “tái sinh” nơi nếu một phần không còn được lưu trữ, bất kỳ ai cũng có thể đưa dữ liệu đó trở lại bằng cách cung cấp chứng minh về dữ liệu đó là gì.

Những điểm khác biệt chính giữa những đề xuất này là: (i) làm thế nào chúng ta xác định “gần đây”, và (ii) làm thế nào chúng ta xác định “mảnh”? Một đề xuất cụ thể là EIP-7736, xây dựng trên thiết kế “stem-and-leaf” được giới thiệu cho cây Verkle (mặc dù tương thích với bất kỳ hình thức không có trạng thái nào, chẳng hạn như cây nhị phân). Trong thiết kế này, tiêu đề, mã và các khe lưu trữ kề nhau được lưu trữ dưới cùng một “stem”. Dữ liệu được lưu trữ dưới một stem có thể là tối đa 256 * 31 = 7.936 byte. Trong nhiều trường hợp, toàn bộ tiêu đề và mã, và nhiều khe lưu trữ quan trọng, của một tài khoản sẽ được lưu trữ dưới cùng một stem. Nếu dữ liệu dưới một stem cụ thể không được đọc hoặc ghi trong 6 tháng, dữ liệu sẽ không còn được lưu trữ nữa, thay vào đó chỉ lưu trữ một cam kết 32 byte (“stub”) cho dữ liệu. Các giao dịch trong tương lai truy cập vào dữ liệu đó sẽ cần “phục sinh” dữ liệu, với một chứng minh sẽ được kiểm tra so với stub.

Có các cách khác để triển khai một ý tưởng tương tự. Ví dụ, nếu mức độ chi tiết cấp tài khoản không đủ, chúng ta có thể tạo một kế hoạch trong đó mỗi phân phối 1/232 của cây được điều chỉnh bởi một cơ chế tương tự như cành lá.

Điều này phức tạp hơn vì các ưu đãi: kẻ tấn công có thể buộc khách hàng lưu trữ vĩnh viễn một lượng trạng thái rất lớn bằng cách đưa một lượng dữ liệu rất lớn vào một cây con duy nhất và gửi một giao dịch duy nhất mỗi năm để “làm mới cây”. Nếu bạn làm cho chi phí gia hạn tỷ lệ thuận (hoặc thời gian gia hạn tỷ lệ nghịch) với kích thước cây, thì ai đó có thể làm phiền người dùng khác bằng cách đưa một lượng dữ liệu rất lớn vào cùng một cây con với họ. Người ta có thể cố gắng hạn chế cả hai vấn đề bằng cách làm cho động lực chi tiết dựa trên kích thước cây con: ví dụ, mỗi đối tượng trạng thái 216 = 65536 liên tiếp có thể được coi là một “nhóm”. Tuy nhiên, những ý tưởng này phức tạp hơn; Cách tiếp cận dựa trên STEM rất đơn giản và nó phù hợp với các ưu đãi, bởi vì thông thường tất cả dữ liệu trong STEM đều liên quan đến cùng một ứng dụng hoặc người dùng.

Đề xuất hết hạn trạng thái dựa trên địa chỉ

Loại bỏ bất kỳ sự phát triển trạng thái cố định nào, ngay cả các đoạn 32 byte? Điều này là một vấn đề khó khăn vì củaxung đột phục sinh: điều gì sẽ xảy ra nếu một đối tượng trạng thái bị xóa, việc thực thi EVM sau đó đặt một đối tượng trạng thái khác vào cùng một vị trí, nhưng sau đó ai đó quan tâm đến đối tượng trạng thái ban đầu quay lại và cố gắng khôi phục nó? Với việc hết hạn một phần trạng thái, “sơ khai” ngăn không cho dữ liệu mới được tạo. Với việc hết hạn trạng thái đầy đủ, chúng tôi không thể đủ khả năng để lưu trữ ngay cả sơ khai.

Thiết kế dựa trên khoảng thời gian địa chỉ là ý tưởng nổi tiếng nhất để giải quyết vấn đề này. Thay vì có một cây trạng thái lưu trữ toàn bộ trạng thái, chúng tôi có một danh sách các cây trạng thái liên tục phát triển và bất kỳ trạng thái nào được đọc hoặc viết đều được lưu trong cây trạng thái gần đây nhất. Một cây trạng thái trống mới được thêm một lần mỗi kỳ (nghĩ: 1 năm). Cây trạng thái cũ bị đóng băng rắn. Các nút đầy đủ dự kiến chỉ lưu trữ hai cây gần đây nhất. Nếu một đối tượng trạng thái không được chạm vào trong hai khoảng thời gian và do đó rơi vào một cây hết hạn, nó vẫn có thể được đọc hoặc ghi vào, nhưng giao dịch sẽ cần phải chứng minh bằng chứng Merkle cho nó - và một khi nó xảy ra, một bản sao sẽ được lưu lại trong cây mới nhất.

Một ý tưởng quan trọng để làm cho tất cả điều này thân thiện với người dùng và nhà phát triển là khái niệm về khoảng thời gian địa chỉ. Khoảng thời gian địa chỉ là một số là một phần của địa chỉ. Một quy tắc quan trọng là một địa chỉ có khoảng thời gian địa chỉ N chỉ có thể được đọc hoặc ghi vào trong hoặc sau giai đoạn N (nghĩa là khi danh sách cây trạng thái đạt đến độ dài N). Nếu bạn đang lưu một đối tượng trạng thái mới (ví dụ: hợp đồng mới hoặc số dư ERC20 mới), nếu bạn đảm bảo đặt đối tượng trạng thái vào hợp đồng có khoảng thời gian địa chỉ là N hoặc N-1, thì bạn có thể lưu nó ngay lập tức mà không cần cung cấp bằng chứng rằng không có gì ở đó trước đó. Mặt khác, bất kỳ bổ sung hoặc chỉnh sửa nào để nêu trong các khoảng thời gian địa chỉ cũ hơn đều yêu cầu bằng chứng.

Thiết kế này bảo tồn hầu hết các tính năng hiện tại của Ethereum, rất nhẹ về tính toán thêm, cho phép các ứng dụng được viết gần như như hôm nay (ERC20s sẽ cần phải viết lại, để đảm bảo rằng số dư của địa chỉ với chu kỳ địa chỉ N được lưu trữ trong một hợp đồng con mà chính nó có chu kỳ địa chỉ N), và giải quyết vấn đề “người dùng đi vào hang động trong năm năm”. Tuy nhiên, nó có một vấn đề lớn: địa chỉ cần được mở rộng vượt quá 20 byte để vừa với chu kỳ địa chỉ.

Mở rộng không gian địa chỉ

Một đề xuất là giới thiệu một định dạng địa chỉ mới 32 byte, bao gồm một số phiên bản, một số giai đoạn địa chỉ và một hash mở rộng.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

Màu đỏ là một số phiên bản. Bốn số không màu cam ở đây được định nghĩa là không gian trống, có thể chứa một số shard trong tương lai. Màu xanh lá cây là một số kỳ hạn địa chỉ. Màu xanh dương là một hash 26 byte.

Thách thức chính ở đây là khả năng tương thích ngược. Các hợp đồng hiện có được thiết kế xung quanh địa chỉ 20 byte, và thường sử dụng kỹ thuật đóng gói byte chặt chẽ mà rõ ràng cho rằng địa chỉ có đúng 20 byte.Một ý tưởng để giải quyết điều nàyliên quan đến một bản đồ dịch, trong đó hợp đồng theo kiểu cũ tương tác với địa chỉ theo kiểu mới sẽ nhìn thấy một băm 20 byte của địa chỉ theo kiểu mới. Tuy nhiên, có những khó khăn đáng kể liên quan đến việc làm cho điều này an toàn.

Thu gọn không gian địa chỉ

Một cách tiếp cận khác lại đi theo hướng ngược lại: chúng ta ngay lập tức cấm một số phạm vi con có kích thước 2128 (ví dụ tất cả địa chỉ bắt đầu bằng 0xffffffff), và sau đó sử dụng phạm vi đó để giới thiệu các địa chỉ với khoảng thời gian địa chỉ và băm 14 byte.

0xfffffff000169125d5dFcb7B8C2659029395bdF

Sự hy sinh quan trọng mà phương pháp này thực hiện, là nó giới thiệu rủi ro bảo mật cho các địa chỉ phi thực tế: địa chỉ giữ tài sản hoặc quyền hạn, nhưng mã của nó chưa được công bố trên chuỗi. Rủi ro liên quan đến việc ai đó tạo ra một địa chỉ khẳng định có một đoạn mã (chưa được công bố) nhưng cũng có một đoạn mã hợp lệ khác có cùng địa chỉ hash. Tính toán một va chạm như vậy yêu cầu 2⁸⁰hôm nay; sự rút ngắn không gian địa chỉ sẽ giảm số này xuống còn 2 rất dễ tiếp cận⁵⁶hashes.

Lĩnh vực rủi ro chính, các địa chỉ phản chứng không phải là ví tiền được nắm giữ bởi một chủ sở hữu duy nhất, hiện nay là trường hợp hiếm gặp, nhưng có thể trở nên phổ biến hơn khi chúng ta bước vào một thế giới đa L2. Giải pháp duy nhất là chấp nhận rủi ro này, nhưng xác định tất cả các trường hợp sử dụng thông thường mà điều này có thể gây ra vấn đề và đưa ra các giải pháp tạm thời hiệu quả.

Có những liên kết nào đến nghiên cứu hiện tại?

• Các đề xuất sớm
  • Thuê blockchain: https://github.com/ethereum/EIPs/issues/35
  • Regenesis: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• Một lý thuyết về quản lý kích thước trạng thái Ethereum: https://hackmd.io/
• Một vài con đường có thể dẫn đến trạng thái không có trạng thái và hết hạn trạng thái:https://hackmd.io/
• Đề xuất hết hạn trạng thái một phần
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• Tài liệu mở rộng không gian địa chỉ
  • Đề xuất gốc: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • Đánh giá Ipsilon: https://notes.ethereum.org/
  • Đánh giá bài viết trên blog: https://medium.com/
• Những gì sẽ bị hỏng nếu chúng ta mất tính chống va chạm:https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

Còn gì để làm và đánh đổi như thế nào?

Tôi nhìn thấy bốn con đường khả thi cho tương lai:

• Chúng tôi thực hiện không có trạng thái, và không bao giờ giới thiệu việc hết hạn trạng thái. Trạng thái luôn tăng lên (mặc dù chậm: có thể không vượt quá 8 TB trong vài thập kỷ), nhưng chỉ cần được giữ bởi một lớp người dùng tương đối chuyên môn: ngay cả các nhà xác nhận PoS cũng không cần trạng thái.

Một chức năng cần truy cập vào một số phần của trạng thái là sản xuất danh sách bao gồm, nhưng chúng ta có thể hoàn thành điều này một cách phi tập trung: mỗi người dùng chịu trách nhiệm duy trì phần của cây trạng thái chứa các tài khoản của riêng họ. Khi họ phát sóng một giao dịch, họ phát sóng nó với một chứng minh của các đối tượng trạng thái được truy cập trong quá trình xác minh (điều này hoạt động cho cả các tài khoản EOA và ERC-4337). Các trình xác minh không có trạng thái sau đó có thể kết hợp các chứng minh này thành một chứng minh cho toàn bộ danh sách bao gồm.

• Chúng tôi thực hiện việc hết hạn trạng thái một phần và chấp nhận tỷ lệ tăng kích thước trạng thái vĩnh viễn thấp hơn nhưng vẫn khác không. Kết quả này có thể được coi là tương tự như cách các đề xuất hết hạn lịch sử liên quan đến mạng ngang hàng chấp nhận tỷ lệ tăng trữ lưu trữ lịch sử vĩnh viễn thấp hơn nhưng vẫn khác không từ mỗi khách hàng phải lưu trữ một phần trăm lịch sử dữ liệu thấp nhưng cố định.
• Chúng tôi thực hiện việc hết hạn trạng thái, với việc mở rộng không gian địa chỉ. Điều này sẽ liên quan đến quá trình kéo dài nhiều năm để đảm bảo rằng phương pháp chuyển đổi định dạng địa chỉ hoạt động và an toàn, bao gồm cả cho các ứng dụng hiện có.
• Chúng tôi thực hiện việc hết hạn giao thức, với sự thu hẹp không gian địa chỉ. Điều này sẽ liên quan đến quá trình kéo dài nhiều năm để đảm bảo tất cả các rủi ro bảo mật liên quan đến va chạm địa chỉ, bao gồm tình huống liên chuỗi, được xử lý.

Một điểm quan trọng là những vấn đề khó khăn về mở rộng và thu hẹp không gian địa chỉ sẽ cuối cùng phải được giải quyết bất kể liệu các chương trình hết hạn trạng thái phụ thuộc vào các thay đổi định dạng địa chỉ có được triển khai hay không. Hôm nay, mất khoảng 2⁸⁰hashes để tạo ra một va chạm địa chỉ, một tải trọng tính toán mà hiện tại đã khả thi đối với các bên thực hiện tài nguyên rất tốt: một GPU có thể thực hiện khoảng 2²⁷hashes, vì vậy chạy trong một năm nó có thể tính toán 2⁵²vì vậy tất cả~2^30 GPUs trên thế giớicó thể tính toán va chạm trong khoảng 1/4 năm, và FPGAs và ASICs có thể tăng tốc điều này. Trong tương lai, các cuộc tấn công như vậy sẽ trở nên phổ biến hơn và hơn nữa. Do đó, chi phí thực tế của việc triển khai hết hạn trạng thái đầy đủ có thể không cao như vẻ ngoài, vì chúng ta phải giải quyết vấn đề địa chỉ khó khăn này bất kể.

Nó tương tác như thế nào với các phần khác của lộ trình?

Việc hết hạn trạng thái có thể làm cho các chuyển tiếp từ một định dạng cây trạng thái sang một định dạng khác dễ dàng hơn, vì sẽ không cần thiết phải có quy trình chuyển tiếp: bạn có thể đơn giản bắt đầu tạo cây mới bằng định dạng mới, và sau đó làm một hard fork để chuyển đổi các cây cũ hơn. Do đó, mặc dù việc hết hạn trạng thái là phức tạp, nhưng nó có lợi trong việc đơn giản hóa các khía cạnh khác của lộ trình.

Dọn dẹp tính năng

Nó giải quyết những vấn đề gì?

Một trong những điều kiện tiên quyết quan trọng về an ninh, tính khả dụng vàtin cậy tính trung lập là sự đơn giản. Nếu một giao thức đẹp và đơn giản, nó sẽ làm giảm khả năng sẽ có lỗi. Nó làm tăng cơ hội mà các nhà phát triển mới sẽ có thể đến và làm việc với bất kỳ phần nào của nó. Nó có nhiều khả năng công bằng và dễ dàng hơn để bảo vệ chống lại các lợi ích đặc biệt. Thật không may, các giao thức, giống như bất kỳ hệ thống xã hội nào, theo mặc định trở nên phức tạp hơn theo thời gian. Nếu chúng ta không muốn Ethereum đi vào một lỗ đen ngày càng phức tạp, chúng ta cần làm một trong hai điều: (i) ngừng thực hiện các thay đổi và hóa thạch giao thức, (ii) có thể thực sự loại bỏ các tính năng và giảm độ phức tạp. Một lộ trình trung gian, thực hiện ít thay đổi hơn đối với giao thức và cũng loại bỏ ít nhất một chút phức tạp theo thời gian, cũng có thể. Phần này sẽ nói về cách chúng ta có thể giảm hoặc loại bỏ sự phức tạp.

Đây là gì và nó hoạt động như thế nào?

Không có một giải pháp duy nhất lớn nào có thể giảm độ phức tạp của giao thức; bản chất vốn đang gặp vấn đề là có quá nhiều giải pháp nhỏ.

Một ví dụ đã gần hoàn thành và có thể được coi là một bản thiết kế cho cách xử lý các ví dụ khác, làloại bỏ opcode SELFDESTRUCT. Mã opcode SELFDESTRUCT là duy nhất có thể sửa đổi một số lượng không giới hạn các khe lưu trữ trong một khối duy nhất, yêu cầu các client triển khai phức tạp hơn đáng kể để tránh các cuộc tấn công DoS. Mục đích ban đầu của mã opcode là cho phép làm sạch trạng thái tự nguyện, cho phép kích thước trạng thái giảm dần theo thời gian. Trong thực tế, rất ít người cuối cùng sử dụng nó. opcode đã bị giảm sức mạnhchỉ cho phép tài khoản tự hủy được tạo trong cùng một giao dịch trong Dencun hardfork. Điều này giải quyết vấn đề DoS và cho phép đơn giản hóa đáng kể trong mã khách hàng. Trong tương lai, có lẽ nên xóa opcode hoàn toàn.

Một số ví dụ chính về cơ hội đơn giản hóa giao thức mà cho đến nay đã được xác định bao gồm những điều sau. Đầu tiên, một số ví dụ nằm ngoài EVM; những ví dụ này tương đối không xâm phạm và do đó dễ dàng đạt được sự đồng thuận và triển khai trong một khoảng thời gian ngắn hơn.

• Chuyển đổi RLP → SSZ: ban đầu, các đối tượng Ethereum được tuần tự hóa bằng cách sử dụng một phương thức mã hóa gọi làRLP. RLP không được đánh máy, và phức tạp không cần thiết. Ngày nay, chuỗi đèn hiệu sử dụng SSZ, điều này tốt hơn rất nhiều cách, bao gồm việc hỗ trợ không chỉ việc tuần tự hóa mà còn băm. Cuối cùng, chúng tôi muốn loại bỏ hoàn toàn RLP và chuyển tất cả các loại dữ liệu thành các cấu trúc SSZ, điều này sẽ làm cho việc nâng cấp dễ dàng hơn. Các EIP hiện tại cho điều này bao gồm[1][2] [3].
• Loại bỏ các loại giao dịch cũ: hiện nay có quá nhiều loại giao dịch, trong đó có nhiều loại có thể được loại bỏ. Một phương án trung lập hơn so với việc loại bỏ hoàn toàn là tính năng trừu tượng hóa tài khoản, trong đó tài khoản thông minh có thể bao gồm mã để xử lý và xác minh các giao dịch theo kiểu cũ nếu họ muốn.
• Cải cách LOG: log tạo bộ lọc bloom và các logic khác làm tăng phức tạp cho giao thức, nhưng không được sử dụng thực sự bởi các khách hàng vì quá chậm. Chúng ta có thểxóa các tính năng này, và thay vào đó tập trung vào các phương án thay thế khác, chẳng hạn như các công cụ đọc nhật ký phi giao thức phi tập trung sử dụng các công nghệ hiện đại như SNARKs.
• Sự loại bỏ cuối cùng của cơ chế ủy ban đồng bộ chuỗi tín hiệu: cơ chế ủy ban đồng bộban đầu được giới thiệu để cho phép xác minh khách hàng nhẹ của Ethereum. Tuy nhiên, nó làm tăng đáng kể độ phức tạp của giao thức. Cuối cùng, chúng ta sẽ có thểXác minh lớp đồng thuận Ethereum trực tiếp bằng cách sử dụng SNARKs, điều này sẽ loại bỏ nhu cầu sử dụng một giao thức xác minh khách hàng nhẹ riêng biệt. Tiềm năng, các thay đổi về sự nhất quán có thể cho phép chúng tôi loại bỏ các ủy ban đồng bộ ngay cả sớm hơn, bằng cách tạo ra một giao thức khách hàng nhẹ ‘nguyên thuỷ’ hơn, liên quan đến việc xác minh chữ ký từ một tập con ngẫu nhiên của các nhà xác minh đồng thuận Ethereum.
• Đồng bộ định dạng dữ liệu: ngày nay, trạng thái thực hiện được lưu trữ trong một cây Merkle Patricia, trạng thái đồng thuận được lưu trữ trong một cây SSZ, và các blog được cam kết vớiCam kết KZG. Trong tương lai, có ý nghĩa để tạo một định dạng thống nhất duy nhất cho dữ liệu khối và một định dạng thống nhất duy nhất cho trạng thái. Những định dạng này sẽ bao gồm tất cả các nhu cầu quan trọng: (i) chứng minh dễ dàng cho các máy khách không có trạng thái, (ii) viết dữ liệu và mã hóa mất mát cho dữ liệu, (iii) cấu trúc dữ liệu tiêu chuẩn.
• Loại bỏ các ủy ban của beacon chain: cơ chế này ban đầu được giới thiệu để hỗ trợ một phiên bản cụ thể của việc tách khối thực thi. Thay vào đó, chúng tôi đã kết thúc việc thực hiện sharding qua L2s và blobs. Do đó, các ủy ban là không cần thiết, và vì vậy có một đang tiến hành tiến tới loại bỏ chúng.
• Gỡ bỏ việc kết thúc hỗn hợp: EVM là big-endian và lớp đồng thuận là little-endian. Có thể hợp lý để điều hòa lại và làm cho mọi thứ trở thành một trong hai (có lẽ là big-endian, vì EVM khó thay đổi hơn)

Bây giờ, một số ví dụ nằm bên trong EVM:

• Đơn giản hóa cơ chế gas: các quy tắc gas hiện tại chưa được tối ưu hóa để đưa ra giới hạn rõ ràng về số lượng tài nguyên cần thiết để xác minh một khối. Các ví dụ chính bao gồm (i) chi phí đọc / ghi bộ nhớ, được thiết lập để giới hạn số lần đọc / ghi trong một khối nhưng hiện tại khá tùy tiện, và (ii) quy tắc điền bộ nhớ, nơi hiện tại khó để ước tính sự tiêu thụ bộ nhớ tối đa của EVM. Các giải pháp đề xuất bao gồm thay đổi chi phí gas không có trạng thái, điều hòa tất cả các chi phí liên quan đến lưu trữ thành một công thức đơn giản, và đề xuất này về giá cả bộ nhớ.
• Loại bỏ các bộ biên dịch trước: nhiều bộ biên dịch trước mà Ethereum đang sử dụng hiện nay đều phức tạp một cách không cần thiết và tương đối ít được sử dụng, và chiếm một phần lớn trong số các lỗi gần như xảy ra trong việc đạt mục đích nhất quán mà thực tế không được sử dụng bởi bất kỳ ứng dụng nào. Hai cách để xử lý vấn đề này là (i) loại bỏ bộ biên dịch trước và (ii) thay thế nó bằng một đoạn mã EVM (chắc chắn sẽ đắt đỏ hơn) thực hiện cùng một logic.Bản dự thảo EIP này đề xuấtđể thực hiện điều này cho việc biên soạn danh tính như một bước đầu tiên; sau này, RIPEMD160, MODEXP và BLAKE có thể là ứng cử viên cho việc loại bỏ.
• Loại bỏ khả năng quan sát khí: khi thực hiện EVM không còn có thể xem được bao nhiêu khí còn lại. Điều này sẽ làm hỏng một số ứng dụng (đặc biệt là giao dịch được tài trợ), nhưng sẽ cho phép nâng cấp dễ dàng hơn trong tương lai (ví dụ, cho các phiên bản nâng cao hơn của gate).đa chiều khí). The EOF specđã làm cho gas không thể quan sát được, tuy nhiên để hữu ích cho việc đơn giản hóa giao thức, EOF sẽ cần trở thành bắt buộc.
• Cải tiến phân tích tĩnh: hiện tại mã EVM khó để phân tích tĩnh, đặc biệt là do các nhảy có thể là động. Điều này cũng làm cho việc tạo ra các phiên bản EVM tối ưu hơn, chuyển tiền mã EVM thành ngôn ngữ khác. Chúng tôi có thể sửa được điều này bằng cáchloại bỏ nhảy động (hoặc khiến chúng trở nên đắt đỏ hơn nhiều, ví dụ như chi phí gas tuyến tính theo tổng số JUMPDEST trong một hợp đồng). EOF làm điều này, tuy nhiên để đạt được các lợi ích đơn giản hóa giao thức thì yêu cầu EOF phải là bắt buộc.

Có những liên kết nào đến nghiên cứu hiện có?

• Các bước tiếp theo trong cuộc Thanh trừng: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• SELFDESTRUCT: https://hackmd.io/
• SSZ-ification EIPS: [1] [2] [3]
• Thay đổi chi phí khí đốt không quốc tịch: https://eips.ethereum.org/EIPS/eip-4762
• Định giá bộ nhớ tuyến tính: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Loại bỏ trước biên dịch: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Xóa bộ lọc Bloom: https://eips.ethereum.org/EIPS/eip-7668
• Một cách để thực hiện việc lấy nhật ký an toàn ngoại chuỗi bằng cách sử dụng tính toán có thể xác minh tăng dần (đọc: STARKs đệ quy):https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

Còn lại những gì cần làm và những sự đánh đổi là gì?

Sự đánh đổi chính trong việc đơn giản hóa tính năng này là (i) mức độ chúng ta đơn giản hóa và tốc độ đó so với (ii) khả năng tương thích ngược. Giá trị của Ethereum như một chuỗi đến từ việc nó là một nền tảng mà bạn có thể triển khai một ứng dụng và tự tin rằng nó sẽ vẫn hoạt động trong nhiều năm tới. Đồng thời, có thể đưa quan niệm đó quá xa, và,để diễn giải lại William Jennings Bryan, “đóng đinh Ethereum trên cây thánh giá của tính tương thích ngược”. Nếu chỉ có hai ứng dụng trong Ethereum sử dụng một tính năng cụ thể và một ứng dụng không có người dùng trong nhiều năm và ứng dụng kia gần như không được sử dụng và bảo vệ tổng cộng 57 đô la, thì chúng ta chỉ cần loại bỏ tính năng đó và nếu cần, trả 57 đô la cho các nạn nhân từ túi của chúng ta.

Vấn đề xã hội rộng lớn hơn nằm ở việc tạo ra một đường ống tiêu chuẩn cho việc thực hiện các thay đổi phá vỡ tương thích ngược không khẩn cấp. Một cách tiếp cận là xem xét và mở rộng các tiền lệ hiện có, như quy trình SELFDESTRUCT. Đường ống trông có vẻ như sau:

• Bước 1: bắt đầu nói về việc loại bỏ tính năng X
• Bước 2: tiến hành phân tích để xác định việc loại bỏ X gây ra sự cố cho ứng dụng như thế nào, tùy thuộc vào kết quả, (i) từ bỏ ý tưởng, (ii) tiếp tục theo kế hoạch ban đầu hoặc (iii) xác định một cách loại bỏ X được chỉnh sửa ít gây gián đoạn nhất và tiếp tục với cách tiếp cận đó
• Bước 3: tạo một EIP chính thức để không sử dụng X. Đảm bảo rằng cơ sở hạ tầng cấp cao phổ biến (ví dụ: ngôn ngữ lập trình, ví) tôn trọng điều này và ngừng sử dụng tính năng đó.
• Bước 4: cuối cùng, thực sự loại bỏ X

Giữa bước 1 và bước 4 nên có một đường ống kéo dài nhiều năm, với thông tin rõ ràng về các mục đang ở bước nào. Đến thời điểm đó, có sự đánh đổi giữa việc đường ống loại bỏ tính năng mạnh mẽ và nhanh chóng hơn, so với việc thận trọng hơn và đầu tư nhiều tài nguyên hơn vào các lĩnh vực phát triển giao thức khác, nhưng chúng ta vẫn còn rất xa so với biên Pareto.

Kết thúc tập tin (EOF)

Một tập hợp lớn các thay đổi đã được đề xuất cho EVM là Định dạng Đối tượng EVM (EOF). EOF giới thiệu một số thay đổi lớn, như cấm quan sát gas, quan sát mã (tức là không CODECOPY), chỉ cho phép nhảy tĩnh. Mục tiêu là cho phép EVM được nâng cấp hơn, theo một cách có tính chất mạnh hơn, trong khi vẫn bảo tồn tính tương thích ngược (vì EVM trước EOF vẫn tồn tại).

Điều này có lợi thế là tạo ra một con đường tự nhiên để thêm các tính năng mới của EVM và khuyến khích di chuyển đến một EVM hạn chế hơn với các cam kết mạnh mẽ hơn. Nhược điểm của nó là tăng đáng kể độ phức tạp của giao thức, trừ khi chúng ta có thể tìm được cách để đánh dấu và loại bỏ EVM cũ. Một câu hỏi quan trọng là: EOF đóng vai trò gì trong các đề xuất đơn giản hóa EVM, đặc biệt nếu mục tiêu là giảm độ phức tạp của EVM như một tổng thể?

Làm thế nào nó tương tác với các phần khác của lộ trình?

Nhiều trong những đề xuất “cải tiến” trong phần còn lại của lộ trình cũng là cơ hội để đơn giản hóa các tính năng cũ. Để lặp lại một số ví dụ từ trên:

• Chuyển sang sự xác nhận cuối cùng trong một khe duy nhất đưa cho chúng ta cơ hội để loại bỏ ủy ban, làm mới kinh tế và thực hiện các đơn giản hóa liên quan đến bằng chứng của sự giao thức cổ phiếu khác.
• Việc triển khai hoàn toàn trừu tượng hóa tài khoản cho phép chúng tôi loại bỏ rất nhiều logic xử lý giao dịch hiện có, bằng cách di chuyển nó vào một phần của “mã EVM tài khoản mặc định” mà tất cả EOAs có thể được thay thế bởi.
• Nếu chúng ta chuyển trạng thái Ethereum sang cây băm nhị phân, điều này có thể được điều hòa với một phiên bản mới của SSZ, để tất cả cấu trúc dữ liệu Ethereum có thể được băm theo cùng một cách.

Một cách tiếp cận cấp tiến hơn: chuyển đổi một phần lớn của giao thức thành mã hợp đồng

Một chiến lược đơn giản hóa Ethereum cấp tiến hơn là giữ nguyên giao thức nhưng di chuyển một phần lớn của nó từ các tính năng giao thức sang mã hợp đồng.

Phiên bản cực đoan nhất của điều này sẽ là làm cho Ethereum L1 “về mặt kỹ thuật” chỉ là chuỗi đèn hiệu và giới thiệu một máy ảo tối thiểu (ví dụ: RISC-V, Cairo, hoặc thậm chí là một cái gì đó còn tối giản hơn được chuyên biệt cho việc chứng minh hệ thống) cho phép bất kỳ ai khác tạo ra rollup của riêng họ. EVM sau đó sẽ biến thành rollup đầu tiên của chúng. Điều này là một cách trớ trêu cũng chính là kết quả giống hệt như đề xuất môi trường thực thi từ 2019-20, tuy nhiên SNARKs làm cho việc triển khai trở nên đáng tin cậy hơn đáng kể.

Một phương pháp khá hợp lý là giữ nguyên mối quan hệ giữa chuỗi đèn hiệu và môi trường thực thi Ethereum hiện tại, nhưng thực hiện một hoán đổi trong chỗ của EVM. Chúng ta có thể chọn RISC-V, Cairo hoặc một VM khác làm “VM Ethereum chính thức” mới, sau đó buộc chuyển đổi tất cả các hợp đồng EVM sang mã mới-VM để giải thích logic của mã gốc (bằng cách biên dịch hoặc giải thích). Lý thuyết, điều này có thể được thực hiện với “VM đích” là một phiên bản của EOF.

Thông báo:

1. Bài viết này được sao chép từ [Vitalik Buterin]. Tất cả các bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Cổng Họcđội ngũ, và họ sẽ xử lý nó ngay lập tức.
2. Miễn trách nhiệm về trách nhiệm: Quan điểm và ý kiến được thể hiện trong bài viết này chỉ là quan điểm và ý kiến của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi có ghi chú, việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là cấm.