Tương lai có thể có của giao thức Ethereum(5): Cuộc thanh trừng

Bài viết này cung cấp cái nhìn sâu sắc về cách đơn giản hóa kiến ​​trúc blockchain cũng như cải thiện hiệu quả và tính bền vững của mạng mà không làm giảm hiệu suất.

Văn bản gốc: Tương lai có thể có của giao thức Ethereum, phần 5: Cuộc thanh trừng (vitalik.eth)

Tác giả: Vitalik.eth

Biên soạn bởi: ChoeyGit, 183Aaros, LXDAO

Lời nói đầu của người dịch

Là người theo dõi và tìm hiểu công nghệ blockchain và hệ sinh thái Ethereum , tôi vô cùng phấn khích và thích thú khi nhìn thấy kế hoạch “The Purge” do Vitalik đề xuất. Kế hoạch này đề xuất một ý tưởng phát triển độc đáo: trong bối cảnh blockchain theo đuổi việc mở rộng chức năng, thay vào đó, nó sẽ cải thiện hiệu quả mạng bằng cách tối ưu hóa và đơn giản hóa kiến ​​trúc hệ thống. Kế hoạch chủ yếu tập trung vào giải quyết vấn đề mở rộng dữ liệu blockchain và đơn giản hóa độ phức tạp của hệ thống, nhằm hạ thấp ngưỡng tham gia và cải thiện tính bền vững của mạng.

Với sự phát triển nhanh chóng của công nghệ blockchain , những khó khăn trong tăng trưởng liên tục của dữ liệu mạng và kiến ​​trúc hệ thống ngày càng phức tạp đã dần xuất hiện. Đặc biệt ngày nay khi các giải pháp Layer 2 được sử dụng rộng rãi, chúng mang lại mở rộng cao hơn và cũng mang lại sự phức tạp hơn cho hệ thống. Trong bối cảnh đó, kế hoạch “Thanh trừng” của bài viết này đề xuất một hướng tư duy mới.

Liệu tuyến kỹ thuật này có thể giảm trọng lượng hiệu quả mà không ảnh hưởng đến hiệu suất mạng không? Làm thế nào để đạt được sự cân bằng giữa sự đơn giản và chức năng? Hãy theo dõi bài viết để thảo luận sâu hơn về những vấn đề này.

Tổng quan về bài viết này

Bài viết này tổng cộng khoảng 10.000 từ và có 3 phần. Ước tính sẽ mất 50 phút để đọc xong bài viết này.

1. Lịch sử hết hạn
2. Nhà nước hết hạn
3. Dọn dẹp tính năng

Nội dung văn bản

"Tương lai có thể có của Giao thức Ethereum(5): Cuộc thanh trừng"

Đặc biệt cảm ơn Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden và Tomasz Stanczak vì những phản hồi và đánh giá của họ.

Ethereum phải đối mặt với một thách thức: Theo mặc định, các giao thức blockchain tăng trưởng kích thước và độ phức tạp theo thời gian. Thực trạng này thể hiện chủ yếu ở hai khía cạnh:

Dữ liệu lịch sử : Bất cứ khi nào các giao dịch và tài khoản được tạo (trên Chuỗi), chúng cần được lưu trữ vĩnh viễn bởi tất cả máy trạm. Đồng thời, máy trạm mới cũng cần tải xuống tất cả dữ liệu khi thực hiện đồng bộ hóa toàn bộ nút . Điều này dẫn đến thời gian tải và đồng bộ hóa của khách hàng tiếp tục tăng ngay cả khi khả năng xử lý của Chuỗi không đổi.

Các tính năng của giao thức : Việc thêm các tính năng mới dễ dàng hơn nhiều so với việc loại bỏ các tính năng cũ, khiến độ phức tạp của mã tăng lên theo thời gian.

Để Ethereum phát triển lâu dài bền vững, chúng ta cần tìm ra các biện pháp mạnh mẽ để chống lại hai xu hướng này: liên tục giảm độ phức tạp và phình to theo thời gian . Đồng thời, chúng ta cũng cần giữ lại đặc điểm cốt lõi của blockchain: tính lâu dài . Bạn có thể lưu trữ NFT, một bức thư tình được viết bằng dữ liệu giao dịch (calldata) hoặc triển khai hợp đồng thông minh chứa một triệu đô la trên Chuỗi. Ngay cả khi bạn có trốn trong hang động mười năm, bạn sẽ thấy nó vẫn ở đó chờ bạn đọc và tương tác khi bạn bước ra. Các ứng dụng phi tập trung(dapp) cần phải tự tin rằng các thành phần mà chúng dựa vào để chạy ứng dụng sẽ không gây ra những thay đổi có hại do nâng cấp trước khi chúng có thể đạt được phi tập trung hoàn toàn một cách an toàn và loại bỏ các khóa nâng cấp của mình—— — Đặc biệt là chính L1.

Chúng ta cần tìm sự cân bằng giữa hai nhu cầu này trong khi giảm thiểu hoặc đảo ngược sự phình to, phức tạp và phân rã dữ liệu trong khi vẫn duy trì tính liên tục. Chúng tôi tin rằng điều này chắc chắn có thể đạt được miễn là chúng tôi đầu tư vào nghiên cứu trong lĩnh vực này. Các sinh vật có thể làm được điều này: trong khi hầu hết mọi người già đi theo thời gian, một số ít may mắn thì không. Ngay cả các hệ thống xã hội cũng có thể đạt được tuổi thọ siêu dài. Ethereum đã chứng minh những câu chuyện thành công trong một số lĩnh vực: cơ chế Bằng chứng công việc(Pow) đã bị loại bỏ, opcode SELFDESTRUCT (opcode) về cơ bản đã biến mất và Beacon Chain beacon nút chỉ lưu trữ dữ liệu trong sáu tháng qua . Đây là thách thức cuối cùng của Ethereum về mở rộng lâu dài, tính bền vững kỹ thuật và thậm chí cả bảo mật, nhằm tìm ra con đường phát triển phổ quát hơn cho Ethereum và hướng tới mục tiêu cuối cùng là ổn định lâu dài.

Cuộc thanh trừng: Mục tiêu chính

• Giảm yêu cầu lưu trữ của máy khách , thậm chí có thể giảm sự phụ thuộc vào việc lưu trữ dữ liệu trạng thái bằng cách giảm hoặc loại bỏ nhu cầu mỗi nút lưu trữ vĩnh viễn tất cả dữ liệu lịch sử .
• 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.

Nội dung của chương này

• Lịch sử hết hạn
• Nhà nước hết hạn
• Dọn dẹp tính năng

Lịch sử đã hết hạn

Chúng ta đang cố gắng giải quyết vấn đề gì?

Tính đến văn bản này, nút Ethereum được đồng bộ hóa hoàn toàn cần khoảng 1,1 TB dung lượng ổ đĩa để thực thi máy trạm và thêm vài trăm GB để lưu trữ máy trạm đồng thuận. Phần lớn trong đó là dữ liệu lịch sử : bao gồm dữ liệu lịch sử về khối, giao dịch và biên nhận, hầu hết trong dữ liệu đã có từ nhiều năm lịch sử. Điều này có nghĩa là ngay cả khi gas không tăng chút nào, kích thước của nút vẫn sẽ tăng hàng trăm GB mỗi năm.

Nó là gì và nó được thực hiện như thế nào?

Có một thuộc tính đơn giản hóa quan trọng của vấn đề lưu trữ lịch sử: vì mỗi khối được liên kết bằng một hàm băm (trong số các cấu trúc khác) và trỏ đến khối trước đó, điều này có nghĩa là bất cứ khi nào có sự đồng thuận về trạng thái hiện tại thì sẽ có sự đồng thuận về lịch sử.. Miễn là mạng đạt được sự đồng thuận về khối mới nhất, mọi khối, giao dịch hoặc trạng thái lịch sử(số dư tài khoản, số nonce, mã, bộ nhớ) đều có thể được cung cấp bởi bất kỳ người tham gia nào và kèm theo bằng chứng Merkle, cho phép tất cả trừ một người tham gia để xác minh tính chính xác của nó theo cách thủ công. Khi sự đồng thuận sử dụng mô hình tin cậy N/2-of-N, lịch sử là mô hình tin cậy 1-of-N.

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

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

Mã xóa có thể cải thiện độ bền dữ liệu trong khi vẫn duy trì hệ số sao chép tương tự. Trên thực tế, để hỗ trợ việc lấy mẫu tính khả dụng dữ liệu , bản thân Blobs đã sử dụng công nghệ mã hóa xóa. Giải pháp đơn giản nhất có thể là sử dụng lại công nghệ mã hóa xóa này và đưa dữ liệu khối của lớp thực thi và lớp đồng thuận vào Blobs.

Các kết nối với nghiên cứu hiện tại là gì?

• Đề án EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• mạng torrent và Đề án EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
• Mạng cổng thông tin: https://ethereum.org/en/developers/docs/networking-layer/portal-network/
• Đề án mạng cổng thông tin và EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308
• Lưu trữ phân tán và truy xuất các đối tượng SSZ trong 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 Phí gas ( Paradigm): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

Những gì còn lại để làm và 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 giải pháp lưu trữ lịch sử phân tán cụ thể - ít nhất là dữ liệu lịch sử của lớp thực thi và cuối cùng là dữ liệu và các đốm màu lớp đồng thuận . Có hai giải pháp đơn giản nhất: (i) nhập trực tiếp các thư viện torrent hiện có và (ii) giải pháp gốc Ethereum được gọi là mạng Cổng thông tin. Khi một trong hai tình huống này được đưa ra, chúng tôi có thể kích hoạt EIP-4444. Bản thân EIP-4444 không yêu cầu hard fork nhưng yêu cầu phiên bản giao thức mạng mới. Do đó, điều quan trọng là bật tính năng này trên tất cả máy trạm cùng một lúc, nếu không, khi máy trạm kết nối với nút khác, có thể có rủi ro lỗi khi máy khách muốn tải xuống dữ liệu lịch sử hoàn chỉnh nhưng thực tế không thể lấy được dữ liệu đó.

Sự đánh đổi chính là chúng ta sẽ đi bao xa để đảm bảo tính sẵn có của dữ liệu lịch sử "cổ". Giải pháp đơn giản nhất là ngừng lưu trữ dữ liệu lịch sử "cổ" bắt đầu từ ngày mai và thay vào đó dựa vào nút lưu trữ hiện có và các nhà cung cấp dịch vụ tập trung khác nhau để sao chép dữ liệu . Điều này rất dễ thực hiện nhưng nó sẽ làm suy yếu địa vị của Ethereum như một kho lưu trữ băng đĩa lâu dài. Con đường khó khăn hơn nhưng an toàn hơn trước tiên là xây dựng và tích hợp mạng torrent để lưu trữ dữ liệu lịch sử theo cách phân tán. “Chúng ta cố gắng biết bao” ở đây có hai chiều:

1. Chúng ta cần nỗ lực bao nhiêu để đảm bảo rằng số lượng nút tối đa thực sự lưu trữ tất cả dữ liệu ?
2. Chúng ta nên tích hợp lưu trữ dữ liệu lịch sử vào giao thức ở mức độ nào?

Đối với khía cạnh (1), một giải pháp cực kỳ nghiêm ngặt sẽ liên quan đến bằng chứng về quyền giám sát: mỗi người xác thực Bằng chứng cổ phần thực sự được yêu cầu lưu trữ một tỷ lệ dữ liệu lịch sử nhất định và thực hiện kiểm tra crypto định kì để đảm bảo rằng họ xác minh các điều kiện lưu trữ của mình. Một giải pháp khác, khiêm tốn hơn là đặt ra tiêu chuẩn tự nguyện và để mỗi máy trạm tự nguyện lưu trữ một tỷ lệ dữ liệu lịch sử nhất định.

Đối với chiều hướng (2), giải pháp triển khai cơ bản là áp dụng trực tiếp các kết quả hiện có: Cổng thông tin đã lưu trữ các tệp ERA chứa toàn bộ lịch sử của Ethereum . Việc triển khai toàn diện hơn sẽ thực sự kết nối điều này với quy trình đồng bộ hóa, để nếu ai đó muốn đồng bộ hóa một nút hoặc nút lưu trữ lưu trữ toàn bộ lịch sử , họ có thể thực hiện việc đó trực tiếp từ mạng Cổng thông tin, ngay cả khi không có kho lưu trữ nào khác nút trực tuyến.

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

Nếu chúng tôi muốn làm cho việc chạy hoặc khởi động nút trở nên cực kỳ đơn giản thì việc giảm yêu cầu lưu trữ dữ liệu lịch sử được cho là quan trọng hơn việc không có trạng thái: trong số 1,1 TB dung lượng lưu trữ mà nút yêu cầu, dữ liệu trạng thái chiếm khoảng 300 GB và lịch sử Dữ liệu chiếm còn lại khoảng 800 GB. Viễn cảnh mong đợi cho phép nút Ethereum chạy trên đồng hồ thông minh và chỉ mất vài phút để thiết lập chỉ có thể đạt được nếu cả trạng thái không trạng thái và EIP-4444 đều được triển khai.

Việc giới hạn lưu trữ dữ liệu lịch sử ở “ nút Ethereum mới hơn chỉ cần hỗ trợ phiên bản mới nhất của giao thức” sẽ cải thiện tính khả thi, điều này cũng giúp việc triển khai nút trở nên đơn giản hơn. Ví dụ: do các khe lưu trữ trống được tạo trong cuộc tấn công DoS 2016 đều đã bị xóa nên nhiều dòng mã liên quan hiện có thể được xóa một cách an toàn. Tương tự như vậy, giờ đây việc chuyển sang Bằng chứng cổ phần(PoS) đã là lịch sử“cổ xưa”, giờ đây máy trạm có thể xóa tất cả mã liên quan đến Bằng chứng công việc (PoW) một cách an toàn.

Trạng thái đã hết hạn

Nó giải quyết được vấn đề gì?

Ngay cả khi chúng tôi loại bỏ nhu cầu lưu trữ dữ liệu lịch sử của máy trạm , nhu cầu lưu trữ của khách hàng sẽ tiếp tục tăng trưởng, khoảng 50 GB mỗi năm, vì dữ liệu trạng thái tiếp tục tăng trưởng : số dư tài khoản và giá trị nonce, mã hợp đồng và lưu trữ hợp đồng. Người dùng phải trả chi phí một lần, đặt gánh nặng lưu trữ vĩnh viễn lên máy trạm Ethereum hiện tại và tương lai.

Dữ liệu trạng thái khó "hết hạn" hơn dữ liệu lịch sử vì thiết kế cơ bản của EVM dựa trên giả định rằng một khi đối tượng trạng thái được tạo, nó sẽ tồn tại vĩnh viễn và có thể được đọc bởi bất kỳ giao dịch nào vào bất kỳ lúc nào. Có một quan điểm cho rằng vấn đề này có thể không quá nghiêm trọng nếu chúng ta đưa ra trạng thái không trạng thái: chỉ một số lớp người xây dựng khối nhất định mới thực sự lưu trữ dữ liệu trạng thái, trong khi tất cả nút khác (thậm chí cả việc tạo danh sách bao gồm!) Có thể chạy ở chế độ không trạng thái . Tuy nhiên, một quan điểm khác cho rằng chúng ta không nên phụ thuộc quá nhiều vào tình trạng không quốc tịch và cuối cùng chúng ta có thể vẫn cần hết hạn trạng thái để đảm bảo phi tập trung của Ethereum .

Nó là gì và nó được thực hiện như thế nào?

Ngày nay, khi bạn tạo một đối tượng trạng thái mới (có thể được thực hiện theo một trong ba cách: (i) gửi ETH đến tài khoản mới, (ii) tạo tài khoản mới bằng mã, (iii) thiết lập Khe lưu trữ chưa sử dụng trước đó, đối tượng trạng thái sẽ tồn tại vĩnh viễn trong trạng thái và điều chúng tôi muốn làm là có ba mục tiêu sau :

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

Thực sự rất dễ giải quyết vấn đề mà không cần nghĩ đến việc đạt được những mục tiêu này. Ví dụ: bạn có thể yêu cầu mỗi đối tượng trạng thái lưu trữ một bộ đếm ngày hết hạn (thời gian hết hạn có thể được kéo dài bằng cách đốt ETH, việc này có thể được thực hiện tự động trên lần đọc hoặc ghi) và thiết lập một vòng lặp đi qua trạng thái để xóa các đối tượng trạng thái đã hết hạn . quá trình. Tuy nhiên, điều này đưa ra tính toán bổ sung (và thậm chí làm tăng yêu cầu lưu trữ) và rõ ràng là không đáp ứng được yêu cầu về tính thân thiện với người dùng. Các nhà phát triển cũng có thể gặp khó khăn trong việc xử lý các trường hợp góc trong đó các giá trị được lưu trữ đôi khi được đặt lại về 0. Nếu bộ hẹn giờ hết hạn được đặt ở mức hợp đồng, về mặt kỹ thuật, điều này sẽ giúp các nhà phát triển dễ dàng hơn nhưng lại tạo ra nhiều khó khăn hơn về mặt kinh tế: các nhà phát triển cần xem xét cách "chuyển" chi phí lưu trữ liên tục sang người dùng của họ.

Những vấn đề này đã gây khó khăn cho cộng đồng phát triển cốt lõi Ethereum trong nhiều năm, trong đó Đề án như “cho thuê blockchain ” và “tái tạo” đã xuất hiện. Cuối cùng, chúng tôi đã kết hợp những phần hay nhất của Đề án này để tạo ra hai loại "tình huống xấu nhất ít được biết đến nhất":

• Giải pháp hết hạn trạng thái một phần
• Đề án cơ chế hết hạn dữ liệu trạng thái dựa trên chu kỳ địa chỉ

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

Tất cả Đề án hết hạn trạng thái một phần đều tuân theo các nguyên tắc giống nhau. Chúng tôi chia dữ liệu trạng thái thành dữ liệu. Mỗi bảng lưu trữ vĩnh viễn một "bảng ánh xạ cấp cao nhất"đánh dấu khối dữ liệu nào trống hoặc không trống. Dữ liệu trong mỗi khối dữ liệu chỉ được lưu trữ nếu nó được truy cập gần đây. Ngoài ra còn có cơ chế "kích hoạt": nếu một khối dữ liệu không còn được lưu trữ, bất kỳ ai cũng có thể khôi phục nó bằng cách cung cấp bằng chứng về dữ liệu.

Sự khác biệt chính giữa Đề án này là: (i) cách xác định "ngắn hạn" và (ii) cách xác định "các khối dữ liệu". Trong đó Đề án cụ thể là EIP-7736, dựa trên thiết kế "thân và lá" được giới thiệu cho cây Verkle (mặc dù nó tương thích với mọi dạng không trạng thái, chẳng hạn như cây nhị phân). Trong thiết kế này, các tiêu đề, mã và vị trí liền kề được lưu trữ dưới cùng một "gốc". Dữ liệu tối đa được lưu trữ dưới mỗi thân là 256 * 31 = 7.936 byte. Trong nhiều trường hợp, toàn bộ tiêu đề, mã và nhiều khe lưu trữ chính của tài khoản được lưu trữ dưới cùng một thân. Nếu dữ liệu dưới gốc không được đọc hoặc ghi trong vòng 6 tháng, dữ liệu sẽ không còn được lưu trữ nữa và thay vào đó chỉ có cam kết 32 byte ("sơ khai") được lưu trữ. Các giao dịch trong tương lai truy cập vào dữ liệu này cần phải "kích hoạt"dữ liệu và cung cấp bằng chứng có thể được kiểm tra dựa trên sơ khai.

Có nhiều cách khác để thực hiện những ý tưởng tương tự. Ví dụ: nếu độ chi tiết ở cấp tài khoản không đủ tốt, chúng ta có thể thiết kế giải pháp sao cho mỗi phần 1/232 của cây trạng thái được quản lý bằng cơ chế thân và lá tương tự.

Nhưng phương pháp này sẽ làm cho việc triển khai cơ chế khích lệ trở nên khó khăn hơn: kẻ tấn công có thể buộc máy trạm lưu trữ vĩnh viễn lượng lớn trạng thái bằng cách lưu trữ lượng lớn dữ liệu trong một cây trạng thái con duy nhất và sau đó gửi giao dịch tới "cập nhật". cây trạng thái" hàng năm. Nếu chi phí cập nhật được đặt tỷ lệ thuận với kích thước của cây trạng thái (hoặc thời lượng cập nhật tỷ lệ nghịch với kích thước của cây), thì kẻ tấn công có thể quấy rối những người dùng khác bằng cách gửi lượng lớn dữ liệu vào cùng một đứa trẻ. cây trạng thái Chúng ta có thể cố gắng hạn chế cả hai vấn đề với mức độ chi tiết động dựa trên kích thước của cây trạng thái con: ví dụ: mỗi đối tượng trạng thái 2^16 = 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; ngược lại, phương pháp dựa trên gốc rất đơn giản và có thể phối hợp khích lệ tốt vì thông thường tất cả dữ liệu trong một thân đều liên quan đến cùng một ứng dụng hoặc người dùng.

Đề án cơ chế hết hạn trạng thái dựa trên chu kỳ địa chỉ

Điều gì sẽ xảy ra nếu chúng ta muốn tránh hoàn toàn tăng trưởng trạng thái vĩnh viễn và thậm chí không muốn giữ lại phần sơ khai 32 byte? Đây là một vấn đề phức tạp vì xung đột kích hoạt có thể xảy ra: giả sử một đối tượng trạng thái bị xóa, việc thực thi EVM tiếp theo sẽ đặt một đối tượng trạng thái khác vào cùng một vị trí và sau đó ai đó quan tâm đến đối tượng trạng thái ban đầu sẽ quay lại và cố gắng khôi phục nó. Điều gì sẽ xảy ra với nó? Trong các trường hợp hết hạn trạng thái một phần, "sơ khai" sẽ ngăn không cho dữ liệu mới được tạo. Nhưng trong sơ đồ hết hạn trạng thái hoàn chỉnh, chúng tôi thậm chí không thể lưu trữ sơ khai.

Thiết kế dựa trên địa chỉ theo chu kỳ là giải pháp được biết đến nhiều nhất cho vấn đề này. Thay vì sử dụng cây trạng thái để lưu trữ toàn bộ trạng thái, nó duy trì một danh sách cây trạng thái liên tục tăng trưởng và mọi trạng thái được đọc hoặc ghi sẽ được lưu trong cây trạng thái mới nhất. Một cây trạng thái trống mới được thêm vào mỗi kỳ (ví dụ: 1 năm). Cây trạng thái cũ bị đóng băng hoàn toàn. Nút đầy đủ chỉ cần lưu trữ hai cây trạng thái gần đây nhất. Nếu một đối tượng trạng thái chưa được truy cập trong hai chu kỳ và do đó rơi vào cây trạng thái đã hết hạn, nó vẫn có thể được đọc hoặc ghi, nhưng giao dịch liên quan sẽ cần cung cấp bằng chứng Merkle cho nó - sau khi được chứng minh thành công, một bản sao của trạng thái lại được lưu trong cây trạng thái mới nhất.

Một khái niệm quan trọng giúp điều này trở nên thân thiện với người dùng và nhà phát triển là "chu kỳ địa chỉ". Khoảng thời gian địa chỉ là một phần của địa chỉ. Nguyên tắc chính là địa chỉ có chu kỳ địa chỉ N chỉ có thể được đọc hoặc ghi trong hoặc sau giai đoạn N (tức là khi độ dài danh sách cây trạng thái đạt đến N) . Nếu bạn muốn 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), chỉ cần đảm bảo đặt đối tượng trạng thái vào hợp đồng có chu kỳ địa chỉ N hoặc N-1 và bạn có thể lưu nó ngay lập tức mà không cần Cung cấp bằng chứng cho thấy địa điểm này trước đây trống. Nhưng mặt khác, bất kỳ bổ sung hoặc chỉnh sửa nào về trạng thái của các giai đoạn địa chỉ trước đó đều cần có bằng chứng.

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

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

Một đề xuất là giới thiệu định dạng địa chỉ 32 byte mới trong đó số phiên bản, số chu kỳ địa chỉ và giá trị băm mở rộng.

Phần màu đỏ là số phiên bản. Bốn số 0 màu cam ở đây là các khoảng trống dành riêng có thể được sử dụng để lưu trữ số phân đoạn trong tương lai. Phần màu xanh lá cây là số chu kỳ địa chỉ. Phần màu xanh là giá trị băm 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 tại được thiết kế dựa trên địa chỉ 20 byte và thường sử dụng các kỹ thuật đóng gói byte nhỏ gọn giả định rõ ràng rằng độ dài địa chỉ chính xác là 20 byte. Một ý tưởng để giải quyết vấn đề này là sử dụng bảng ánh xạ chuyển đổi để các hợp đồng kiểu cũ tương tác với các địa chỉ kiểu mới sẽ thấy giá trị băm 20 byte của địa chỉ kiểu mới. Tuy nhiên, có nhiều vấn đề phức tạp liên quan đến việc đảm bảo phương pháp này được an toàn.

Thu hẹp không gian địa chỉ

Một phương pháp khác thì ngược lại: chúng tôi ngay lập tức vô hiệu hóa một dãy địa chỉ con có kích thước 2^128 (ví dụ: tất cả các địa chỉ bắt đầu bằng 0xffffffff), sau đó sử dụng dải này để giới thiệu các địa chỉ chứa dấu chấm địa chỉ và hàm băm 14 byte.

Cái giá phải trả chính của phương pháp này là nó gây ra rủi ro bảo mật cho các địa chỉ phản thực : các địa chỉ chứa tài sản hoặc quyền nhưng mã của chúng chưa được phát hành vào Chuỗi. Rủi ro là ai đó có thể tạo một địa chỉ tuyên bố sở hữu một đoạn mã (chưa được phát hành), nhưng đồng thời lại có một đoạn mã hợp lệ khác cũng băm vào cùng một địa chỉ. Việc tính toán một xung đột như vậy hiện yêu cầu 2^ lần phép toán băm; việc thu hẹp không gian địa chỉ sẽ giảm con số này xuống mức rất có thể đạt được là 2^ lần phép toán băm.

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

Các kết nối với nghiên cứu hiện tại là gì?

Đề án sớm

• Thuê blockchain: https://github.com/ethereum/EIPs/issues/35
• Kích hoạt Đề án tái sinh (Regenesis): https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582

Lý thuyết quản lý kích thước trạng thái Ethereum:

https://hackmd.io/@vbuterin/state_size_management

Một số con đường có thể đạt được tình trạng không quốc tịch và hết hạn trạng thái:

https://hackmd.io/@vbuterin/state_expiry_paths

Đề án đã hết hạn 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ỉ

• Đề án ban đầu: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
• Đánh giá về Ipsilon: https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
• Đánh giá bài đăng trên blog: https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6

Việc mất khả năng chống va chạm gây ra những vấn đề gì:

https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

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

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

Thực hiện trạng thái không trạng thái mà không đưa ra cơ chế hết hạn trạng thái . Dữ liệu trạng thái sẽ tiếp tục tăng trưởng(mặc dù tăng trưởng: có thể không vượt quá 8 TB trong nhiều thập kỷ), nhưng chỉ cần được nắm giữ bởi một nhóm người dùng tương đối chuyên biệt: ngay cả người xác thực Bằng chứng cổ phần(PoS) cũng không cần thiết để duy trì trạng thái. Chức năng duy nhất yêu cầu quyền truy cập vào một phần trạng thái là tạo danh sách bao gồm , nhưng chúng tôi có thể thực hiện việc này theo cách phi tập trung: mỗi người dùng chịu trách nhiệm duy trì phần cây trạng thái chứa tài khoản của riêng họ. Khi người dùng phát một giao dịch, bằng chứng về đối tượng trạng thái được truy cập trong bước xác minh cũng được phát (điều này áp dụng cho các tài khoản thuộc sở hữu bên ngoài EOA và tài khoản ERC-4337). Sau đó, người xác minh không trạng thái có thể kết hợp các bằng chứng này thành một bằng chứng chứa danh sách đầy đủ.

Thực hiện cơ chế hết hạn trạng thái một phần chấp nhận tăng trưởng kích thước trạng thái vĩnh viễn giảm đáng kể nhưng vẫn khác 0. Kết quả này được cho là tương tự với tình huống trong Đề án hết hạn lịch sử liên quan đến mạng ngang hàng: mỗi máy trạm được yêu cầu lưu trữ một tỷ lệ dữ liệu lịch sử thấp hơn nhưng cố định, do đó chấp nhận tăng trưởng giảm dần nhưng khác 0 của việc lưu trữ lịch sử vĩnh viễn .

Thực hiện cơ chế hết hạn trạng thái và mở rộng không gian địa chỉ cùng một lúc. Quá trình này sẽ tiếp tục trong nhiều năm để đảm bảo rằng phương pháp chuyển đổi định dạng địa chỉ là khả thi và an toàn, đồng thời bao gồm cả việc đảm bảo an ninh cho các ứng dụng hiện có.

Thực hiện cơ chế hết hạn trạng thái và thu hẹp không gian địa chỉ cùng một lúc. Quá trình này sẽ tiếp tục trong nhiều năm để đảm bảo rằng tất cả rủi ro bảo mật liên quan đến xung đột địa chỉ đều được giải quyết, bao gồm cả rủi ro trong các kịch bản xuyên Chuỗi .

Một quan điểm là những vấn đề gai góc xung quanh mở rộng và thu hẹp không gian địa chỉ cuối cùng sẽ cần được giải quyết bất kể kế hoạch hết hạn trạng thái dựa trên các thay đổi định dạng địa chỉ có được triển khai hay không . Hiện tại, việc tạo xung đột địa chỉ cần khoảng 2^ lần thao tác băm. Tải tính toán này đã khả thi đối với các tác nhân có nguồn lực cực kỳ đủ: GPU có thể thực hiện khoảng 2^ lần thao tác băm mỗi giây, do đó, nó có thể được tính 2^52 lần trong một năm, tức là khoảng 2^30 GPU trên toàn thế giới có thể tính toán xung đột trong khoảng 1/4 năm, đồng thời FPGA và ASIC có thể tăng tốc độ này hơn nữa. Trong tương lai, kiểu tấn công này sẽ ngày càng mở ra cho nhiều người hơn. Do đó, chi phí thực tế của việc thực hiện hết hạn trạng thái đầy đủ có thể không cao như người ta tưởng, vì dù sao thì chúng ta cũng phải giải quyết vấn đề địa chỉ cực kỳ khó khăn này.

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

Việc triển khai cơ chế hết hạn dữ liệu trạng thái có thể giúp chuyển đổi giữa các định dạng cây trạng thái dễ dàng hơn vì không cần quá trình chuyển đổi: bạn có thể trực tiếp tạo cây trạng thái mới ở định dạng mới và sau đó chuyển đổi cây trạng thái cũ thông qua hard fork. Vì vậy, mặc dù cơ chế hết hạn dữ liệu trạng thái phức tạp nhưng nó mang lại lợi ích 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

Chúng ta đang cố gắng giải quyết vấn đề gì?

Một trong những điều kiện tiên quyết quan trọng để đảm bảo tính bảo mật, khả năng truy cập và tính trung lập đáng tin cậy là tính đơn giản. Nếu một giao thức tinh tế và đơn giản, nó sẽ giảm khả năng xảy ra lỗ hổng. Điều này cũng sẽ làm tăng khả năng các nhà phát triển mới có thể tham gia và làm việc trên bất kỳ phần nào của nó. Đồng thời, sự đơn giản này khiến cho thỏa thuận có tính công bằng hơn và có khả năng chống chịu tốt hơn trước ảnh hưởng của 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, mặc định ngày càng trở nên phức tạp theo thời gian. Nếu không muốn Ethereum rơi vào lỗ đen ngày càng phức tạp, chúng ta cần thực hiện một trong hai điều: (i) dừng thay đổi và để giao thức vững chắc , (ii) có thể thực sự loại bỏ một số tính năng nhất định và giảm độ phức tạp . Con đường ở giữa cũng có thể thực hiện được: ít thay đổi hơn đối với giao thức trong khi giảm dần một số độ phức tạp theo thời gian. Phần này thảo luận về cách giảm bớt hoặc loại bỏ sự phức tạp.

Nó là gì và nó được thực hiện như thế nào ?

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

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

Một số cơ hội đơn giản hóa giao thức chính được xác định cho đến nay bao gồm những điều sau đây. Đầu tiên là một số ví dụ bên ngoài EVM; những thay đổi này có tác động tương đối thấp và do đó dễ dàng được thống nhất và thực hiện hơn trong thời gian ngắn.

• Chuyển đổi RLP sang SSZ : Ban đầu, các đối tượng Ethereum được tuần tự hóa bằng cách sử dụng mã hóa có tên RLP. RLP không có kiểu chữ và phức tạp không cần thiết. Ngày nay, Beacon Chain sử dụng SSZ, có lợi thế đáng kể về nhiều mặt, không chỉ hỗ trợ tuần tự hóa mà còn hỗ trợ băm. Chúng tôi hy vọng cuối cùng sẽ loại bỏ hoàn toàn RLP và chuyển đổi tất cả các loại dữ liệu sang cấu trúc SSZ, điều này sẽ giúp nâng cấp dễ dàng hơn. Các Đề án EIP có liên quan hiện tại bao gồm [1]https://eips.ethereum.org/EIPS/eip-6465[2]https://eips.ethereum.org/EIPS/eip-6465[3]https://eips .ethereum.org/EIPS/eip-6465
• Xóa các loại giao dịch cũ : Hiện tại có quá nhiều loại giao dịch, trong đó có thể bị xóa. Một giải pháp thay thế nhẹ nhàng hơn để loại bỏ hoàn toàn là giới thiệu tính năng Trừu tượng hóa tài khoản cho phép tài khoản thông minh tùy chọn bao gồm mã để xử lý và xác thực các giao dịch cũ nếu cần.
• Chuyển đổi ghi nhật ký : Ghi nhật ký tạo các bộ lọc nở và logic khác làm tăng thêm độ phức tạp cho giao thức nhưng chậm đến mức máy trạm không thực sự sử dụng chúng. Chúng tôi có thể loại bỏ các tính năng này và thay vào đó đầu tư vào việc phát triển các giải pháp thay thế, chẳng hạn như các công cụ đọc nhật ký phi tập trung giao thức sử dụng các công nghệ hiện đại như SNARK.
• Beacon Chain cuối cùng đã loại bỏ cơ chế ủy ban đồng bộ hóa : Cơ chế ủy ban đồng bộ hóa ban đầu được giới thiệu để cho phép xác minh máy trạm nhẹ trong Ethereum . Tuy nhiên, nó làm tăng thêm độ phức tạp đáng kể cho giao thức. Cuối cùng, chúng tôi sẽ có thể xác minh trực tiếp lớp đồng thuận Ethereum bằng SNARK, loại bỏ nhu cầu về các giao thức xác minh máy trạm hạng nhẹ chuyên dụng. Bằng cách tạo ra một giao thức máy trạm nhẹ "bản địa" hơn bao gồm việc xác minh chữ ký của một tập hợp con ngẫu nhiên các trình xác thực đồng thuận Ethereum, những thay đổi đối với sự đồng thuận có thể cho phép chúng tôi loại bỏ ủy ban đồng bộ hóa sớm hơn.
• Các định dạng dữ liệu hợp nhất : Hiện tại, trạng thái thực thi được lưu trữ trong cây Merkle Patricia, trạng thái đồng thuận được lưu trữ trong cây SSZ và các blob được cam kết sử dụng cam kết KZG. Trong tương lai, sẽ hợp lý hơn nếu phát triển các định dạng thống nhất riêng biệt cho dữ liệu khối và dữ liệu trạng thái. Các định dạng này sẽ đáp ứng tất cả các yêu cầu quan trọng: (i) chứng thực đơn giản cho máy trạm không có trạng thái, (ii) mã hóa tuần tự và xóa dữ liệu, (iii) cấu trúc dữ liệu được tiêu chuẩn hóa.
• Loại bỏ Ủy ban Beacon Chain : Cơ chế này ban đầu được giới thiệu để hỗ trợ một phiên bản sharding cụ thể. Tuy nhiên, cuối cùng chúng tôi đã triển khai shending thông qua các khối dữ liệu và mạng lớp 2. Kết quả là, các ủy ban không còn cần thiết nữa và công việc hiện đang được tiến hành để loại bỏ chúng.
• Loại bỏ độ cuối hỗn hợp : EVM sử dụng thứ tự byte endian lớn, trong khi lớp đồng thuận sử dụng thứ tự byte endian nhỏ. Sẽ rất hợp lý nếu thống nhất và thống nhất mọi thứ thành một trong đó những điểm cuối (có thể là điểm cuối lớn, vì EVM khó thay đổi hơn).

Bây giờ, hãy xem một số ví dụ 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 tốt về mặt hạn chế lượng tài nguyên cần thiết để xác minh các khối. Các ví dụ chính bao gồm: (i) chi phí lưu trữ đọc và ghi, được cho là giới hạn số lần đọc và ghi trong một khối nhưng hiện được triển khai khá tùy ý và (ii) các quy tắc lấp đầy bộ nhớ, hiện rất khó khăn; để ước tính mức tiêu thụ bộ nhớ tối đa EVM. Các biện pháp khắc phục được đề xuất bao gồm các thay đổi về chi phí gas không trạng thái nhằm thống nhất 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à Đề án này về định giá bộ nhớ.
• Loại bỏ các hợp đồng được biên dịch trước : Nhiều hợp đồng được biên dịch trước hiện tại của Ethereum phức tạp một cách không cần thiết, hiếm khi được sử dụng và chiếm tỷ lệ lớn trong các trường hợp suýt xảy ra lỗi đồng thuận, nhưng chưa có ứng dụng nào thực sự sử dụng chúng. Có hai cách để giải quyết vấn đề này: (i) loại bỏ trực tiếp hợp đồng được biên dịch trước, (ii) thay thế nó bằng mã EVM thực hiện cùng một logic (điều này chắc chắn sẽ làm tăng chi phí). Dự thảo EIP này đề xuất rằng việc này nên được thực hiện trước tiên đối với các hợp đồng được biên dịch trước nhận dạng gốc; sau đó, RIPEMD 160, MODEXP và BLAKE có thể là ứng cử viên để loại bỏ.
• Loại bỏ khả năng quan sát gas : Quá trình thực thi EVM không thể xem tổng lượng gas còn lại nữa. Điều này sẽ ảnh hưởng đến hoạt động của một số ứng dụng (đáng chú ý nhất là các giao dịch tài trợ), nhưng sẽ giúp nâng cấp trong tương lai trở nên dễ dàng hơn (ví dụ: gas đa chiều cho các phiên bản cao cấp hơn). Thông số kỹ thuật EOF đã làm cho gas không thể quan sát được, nhưng để đạt được sự đơn giản hóa giao thức, EOF cần phải trở thành thông số kỹ thuật bắt buộc.
• Tối ưu hóa cho phân tích tĩnh : Mã EVM hiện tại khó phân tích tĩnh, đặc biệt vì các lần nhảy (mã nhảy) có thể là động. Điều này cũng gây khó khăn hơn cho việc tối ưu hóa việc triển khai EVM (bằng cách biên dịch trước mã EVM sang các ngôn ngữ khác). Chúng tôi có thể giải quyết vấn đề này bằng cách loại bỏ các bước nhảy động (hoặc làm cho chúng đắt hơn, ví dụ: làm cho chi phí gas trở nên tuyến tính với tổng số JUMPDEST trong hợp đồng). EOF đã đạt được điều này, nhưng để thu được lợi nhuận từ việc đơn giản hóa giao thức, EOF cần phải được thực thi.

Các kết nối với nghiên cứu hiện tại là gì?

• Giai đoạn thanh lọc tiếp theo: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• Đốt hợp đồng: https://hackmd.io/@vbuterin/selfdesturation
• EIPS liên quan đến SSZ:
  • https://eips.ethereum.org/EIPS/eip-6493
  • https://eips.ethereum.org/EIPS/eip-6466
  • https://eips.ethereum.org/EIPS/eip-6465
• Thay đổi chi phí gas không quốc tịch: https://eips.ethereum.org/EIPS/eip-4762
• Giá bộ nhớ hiện tại: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Xóa các hợp đồng được biên dịch trước: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Loại bỏ bộ lọc Bloom: https://eips.ethereum.org/EIPS/eip-7668
• Phương pháp truy xuất nhật ký an toàn Chuỗi bằng cách sử dụng các tính toán có thể xác minh gia tăng (tức là STARK đệ quy): https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

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

Sự đánh đổi chính trong việc thực hiện đơn giản hóa chức năng như vậy là: (i) mức độ và tốc độ đơn giản hóa so với (ii) khả năng tương thích ngược. Giá trị của Ethereum với tư cách là blockchain là nó là nền tảng mà trên đó các nhà phát triển có thể triển khai ứng dụng và tin tưởng rằng các ứng dụng này sẽ vẫn hoạt động bình thường trong nhiều năm tới. Nhưng đồng thời, lý tưởng này có thể đi quá xa. Mượn lời của William Jennings Bryan, đó là để "đóng đinh Ethereum dựa trên khả năng tương thích ngược". Nếu chỉ có hai ứng dụng trong toàn bộ Ethereum sử dụng một tính năng cụ thể và một trong đó không có người dùng trong nhiều năm và ứng dụng kia gần như hoàn toàn không được sử dụng và chỉ có giá trị $57 bị khóa, thì chúng ta chỉ nên xóa tính năng này, nếu cần thiết, $57 có thể được trả trực tiếp cho người dùng bị ảnh hưởng.

Vấn đề xã hội rộng hơn là làm thế nào để thiết lập một quy trình tiêu chuẩn hóa để thực hiện những thay đổi không khẩn cấp, không tương thích ngược. Một phương pháp là nghiên cứu và mở rộng các tiền lệ hiện có, chẳng hạn như quy trình xử lý SELFDESTRUCT (đốt hợp đồng). Quá trình này đại khái như sau:

• Bước 1: Bắt đầu thảo luận 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 cách loại bỏ các sửa đổi để loại bỏ X và tiến về phía trước
• Bước 3: Đề xuất EIP chính thức để loại bỏ 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í) tuân thủ thay đổi này và ngừng sử dụng tính năng này
• Bước 4: Cuối cùng, thực sự loại bỏ X

Sẽ có một quy trình kéo dài nhiều năm từ Bước 1 đến Bước 4, với bước hiện tại cho mỗi dự án được đánh dấu rõ ràng. Quá trình này đòi hỏi sự cân bằng giữa cường độ và tốc độ của quá trình loại bỏ tính năng và thực hiện một cách tiếp cận thận trọng hơn cũng như đầu tư nhiều nguồn lực hơn vào các lĩnh vực phát triển giao thức khác. Tuy nhiên, chúng ta vẫn còn cách xa biên giới Pareto.

EOF

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

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

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

Nhiều Đề án“tối ưu hóa” trong 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ụ trên:

• Việc chuyển sang tính năng cuối cùng một khe cho chúng tôi cơ hội loại bỏ các ủy ban, cơ cấu lại mô hình kinh tế và thực hiện các đơn giản hóa khác liên quan đến Bằng chứng cổ phần.
• Việc triển khai đầy đủ Trừu tượng hóa tài khoản cho phép chúng tôi loại bỏ lượng lớn logic xử lý giao dịch hiện có phương pháp cách chuyển nó vào một đoạn "mã EVM tài khoản mặc định" mà tất cả EOA đều có thể được thay thế.
• Nếu chúng tôi di chuyển trạng thái Ethereum sang cây băm nhị phân, điều này có thể được hài hòa với các phiên bản SSZ mới để 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 phương pháp triệt để hơn là chuyển đổi phần lớn giao thức thành mã hợp đồng.

Một chiến lược đơn giản hóa Ethereum triệt để hơn là giữ nguyên giao thức nhưng chuyển phần lớ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 phương pháp này là Ethereum L1 "về mặt kỹ thuật" chỉ tồn tại dưới dạng Beacon Chain , đồng thời giới thiệu một máy ảo tối thiểu (chẳng hạn như RISC-V, Cairo hoặc một số Bằng chứng chuyên dụng, đơn giản hơn về máy ảo của hệ thống) , cho phép mọi người tạo danh sách tổng hợp của riêng mình. EVM sẽ chuyển sang bản tổng hợp đầu tiên. Điều thú vị là kết quả này hoàn toàn phù hợp với Đề án hoàn cảnh thực thi 2019-20, nhưng SNARK khiến nó có nhiều khả năng được triển khai thực sự hơn.

Tuyên bố miễn trừ trách nhiệm: Là một nền tảng thông tin blockchain, các bài viết được xuất bản trên trang này chỉ thể hiện quan điểm tác giả và khách và không liên quan gì đến quan điểm của Web3Caff. Thông tin trong bài viết chỉ tham khảo và không cấu thành bất kỳ lời khuyên hay đề nghị đầu tư nào. Vui lòng tuân thủ luật pháp và quy định có liên quan của quốc gia hoặc khu vực nơi bạn sinh sống.