Vitalik: Mục tiêu chính của giai đoạn The Purge của Ethereum

Tác giả: Vitalik, người sáng lập Ethereum; Người biên soạn: Deng Tong, Golden Finance

Lưu ý: Bài viết này là bài thứ năm trong chuỗi bài viết về "Sự phát triển trong tương lai của Giao thức Ethereum" được xuất bản gần đây bởi Vitalik, người sáng lập Ethereum Phần "Tương lai có thể có của giao thức Ethereum, phần 5: The Purge", để biết phần thứ tư, hãy xem "Vitalik: Ethereum Tương lai của hội thảo The Verge". Bạn có thể tìm thấy phần thứ ba trong "Vitalik: Mục tiêu chính của Giai đoạn tai họa của Ethereum", và phần thứ hai có thể có thể tìm thấy trong "Vitalik: Giao thức Ethereum nên phát triển như thế nào trong The Surge", hãy xem phần đầu tiên trong "< a href="https:// www.jinse.cn/blockchain/3699549.html">Những điều gì khác có thể được cải thiện trong Ethereum PoS". Sau đây là toàn văn Phần 5:

Đặ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ận xét của họ.

Một trong những thách thức mà Ethereum phải đối mặt là, theo mặc định, sự cồng kềnh và phức tạp của bất kỳ giao thức blockchain nào sẽ tăng lên theo thời gian. Điều này xảy ra theo hai cách:

• Dữ liệu lịch sử: Mọi giao dịch và mọi tài khoản được tạo tại bất kỳ thời điểm lịch sử nào đều cần được tất cả khách hàng lưu trữ vĩnh viễn và được tải xuống bởi bất kỳ khách hàng mới nào được đồng bộ hóa hoàn toàn với mạng. Điều này khiến thời gian tải máy khách và đồng bộ hóa tăng lên theo thời gian, ngay cả khi công suất của chuỗi không đổi.

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

Để Ethereum bền vững về lâu dài, chúng ta cần có áp lực đối phó mạnh mẽ với cả hai xu hướng, giảm độ phức tạp và sự phình to theo thời gian. Nhưng đồng thời, chúng tacần duy trì một trong những thuộc tính chính của blockchain: độ bền. Bạn có thể đặt NFT, một bức thư tình trong dữ liệu cuộc gọi 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 hang động trong mười năm và đi ra và thấy nó vẫn ở đó đang chờ bạn đọc và tương tác. Để các dapp cảm thấy thoải mái khi được phân quyền hoàn toàn và loại bỏ các khóa nâng cấp, họ cần tự tin rằng các phần phụ thuộc của họ sẽ không được nâng cấp theo cách phá vỡ chúng - đặc biệt là chính L1.

Cuộc thanh trừng, Lộ trình năm 2023.

Nếu chúng ta tập trung vào nó, chúng ta hoàn toàn có thể đạt được sự cân bằng giữa hai nhu cầu này, giảm thiểu hoặc đảo ngược sự phình to, phức tạp và suy thoái trong khi vẫn duy trì tính liên tục. Các sinh vật có thể làm được điều này: Trong khi hầu hết các sinh vật 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ể có tuổi thọ cực kỳ dài. Trong một số trường hợp, Ethereum đã thành công: bằng chứng công việc không còn nữa, opcode SELFDESTRUCT phần lớn đã biến mất và các nút chuỗi beacon đã lưu trữ dữ liệu cũ trong tối đa sáu tháng. Tìm ra con đường này cho Ethereum một cách tổng quát hơn và hướng tới kết quả cuối cùng là sự ổn định lâu dài là thách thức cuối cùng đối với khả năng 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 của Ethereum.

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 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ả lịch sử, Thậm chí có thể tuyên bố cuối cùng

• Giảm độ phức tạp của giao thức bằng cách loại bỏ chức năng không cần thiết

  < /li>

Dữ liệu lịch sử hết hạn

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

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

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

Một thuộc tính đơn giản hóa quan trọng của vấn đề lưu trữ lịch sử là vì mỗi khối trỏ đến khối trước đó thông qua liên kết băm (và các cấu trúc khác), nên sự đồng thuận ở hiện tại là đủ để đạt đượ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ố không, mã, bộ nhớ) đều có thể được cung cấp bởi bất kỳ người tham gia nào bằng bằng chứng Merkle và bằng chứng cho phép bất kỳ ai khác xác minh điều đó đó là giới tính đúng đắn. Trong khi sự đồng thuận là mô hình tin cậy N/2-of-N thì lịch sử là mô hình tin cậy 1-of-N.

Điều này mở ra rất nhiều lựa chọn về cách chúng ta lưu trữ lịch sử. Lựa chọn tự nhiên là mạng trong đó mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu. Đây là cách các mạng torrent đã hoạt động trong nhiều thập kỷ: Mặc dù mạng lưu trữ và phân phối tổng cộng hàng triệu tệp nhưng mỗi người tham gia chỉ lưu trữ và phân phối một vài tệp trong số đó. Có lẽ trái ngược với trực giác, cách tiếp cận này thậm chí không nhất thiết làm cho dữ liệu trở nên kém tin cậy hơn. Nếu bằng cách giảm chi phí chạy 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% lịch sử, thì mỗi nút sẽ lưu trữ ngẫu nhiên 10% lịch sử phần dữ liệu sẽ được sao chép 10.000 lần - chính xác là hệ số sao chép giống như mạng 10.000 nút trong đó mỗi nút lưu trữ mọi thứ.

Ngày nay, Ethereum đã bắt đầu thoát khỏi mô hình tất cả các nút lưu trữ vĩnh viễn tất cả 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. EIP-4444 nhằm mục đích giới thiệu thời gian 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à có một khoảng thời gian phối hợp (có thể ~ 18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ mọi thứ và sau đó có một mạng lưới các nút Ethereum ngang hàng lưu trữ dữ liệu cũ theo kiểu phân tán.

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

Có những nghiên cứu nào hiện có?

EIP-4444: https://eips.ethereum.org/EIPS/eip-4444

Torrent và 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/

Mạng cổng thông tin 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 trong Portal : https://ethresear.ch/t/distributed-storage-and-cryptographically- protected -retrieval-of-ssz-objects-for-portal-network/19575

Cách tăng giới hạn gas (mô hình): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

Còn lại Việc cần làm tiếp theo là gì 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 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 là sự đồng thuận và các đốm màu. Giải pháp đơn giản nhất là (i) chỉ cần đưa vào 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. Sau khi bất kỳ tùy chọn nào trong số này được giới thiệu, 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 nó yêu cầu phiên bản giao thức mạng mới. Do đó, việc kích hoạt tính năng này cho tất cả máy khách cùng lúc là rất có giá trị, vì nếu không, máy khách có thể gặp trục trặc khi kết nối với các nút khác mong muốn toàn bộ lịch sử được tải xuống nhưng thực tế không đạt được điều đó.

Sự đánh đổi chính liên quan đến cách chúng tôi cố gắng cung cấp dữ liệu lịch sử "trước". Giải pháp đơn giản nhất là ngừng lưu trữ dữ liệu trước đó vào ngày mai và dựa vào các nút lưu trữ hiện có cũng như các nhà cung cấp tập trung khác nhau để sao chép. Điều đó thật dễ dàng, nhưng nó làm suy yếu vị thế của Ethereum như một bản ghi dữ liệu vĩnh viễn. Một cách tiếp cận khó hơn nhưng an toàn hơn là trước tiên hãy xây dựng và tích hợp mạng torrent lưu trữ lịch sử theo kiểu phân tán. Ở đây "chúng ta làm việc chăm chỉ như thế nào" có hai khía cạnh:

• Chúng ta nên làm việc chăm chỉ như thế nào Để đả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?

• Chúng tôi tích hợp lưu trữ lịch sử vào giao thức sâu đến mức nào?

Đối với (1), cách tiếp cận nghiêm ngặt nhất sẽ liên quan đến bằng chứng lưu ký: yêu cầu hiệu quả mỗi người xác thực bằng chứng cổ phần phải lưu trữ một tỷ lệ lịch sử nhất định và chuyển qua định kỳ Kiểm tra bằng mật mã nếu họ làm. Một cách tiếp cận khiêm tốn hơn sẽ là đặt ra một tiêu chuẩn tự nguyện cho tỷ lệ phần trăm lịch sử mà mỗi khách hàng lưu trữ.

Đối với (2), việc triển khai cơ bản chỉ liên quan đến những gì đã được thực hiện ngày hôm nay: Cổng thông tin đã lưu trữ 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 quy 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 bằng cách đồng bộ hóa trực tiếp từ mạng cổng thông tin, ngay cả khi không có nút lưu trữ nào khác 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 việc chạy hoặc khởi động một nút trở nên cực kỳ đơn giản thì việc giảm yêu cầu lưu trữ 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 mà một nút yêu cầu, ~300 GB là trạng thái và phần còn lại ~ 800 GB là lịch sử. Tầm nhìn về các 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ể thực hiện được nếu không trạng thái và EIP-4444 được triển khai đồng thời.

Việc hạn chế lưu trữ lịch sử cũng giúp việc triển khai nút Ethereum mới hơn trở nên khả thi hơn khi chỉ hỗ trợ phiên bản mới nhất của giao thức, khiến chúng trở nên đơn giản hơn. Ví dụ: nhiều dòng mã có thể được gỡ bỏ một cách an toàn vì các khe lưu trữ trống được tạo trong cuộc tấn công DoS 2016 đều đã bị xóa. Giờ đây, việc chuyển sang Proof-of-Stake đã là lịch sử, khách hàng có thể xóa tất cả mã liên quan đến Proof-of-Work một cách an toàn.

Trạng thái hết hạn dữ liệu

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ữ lịch sử của khách hàng, yêu cầu lưu trữ của khách hàng sẽ tiếp tục tăng lên hàng năm Giới thiệu 50 GB do trạng thái ngày càng tăng: số dư tài khoản và số dư tài khoản, mã hợp đồng và dung lượng lưu trữ hợp đồng. Người dùng có thể trả khoản phí một lần, khoản phí này mãi mãi gây gánh nặng cho các khách hàng Ethereum hiện tại và tương lai.

Trạng thái khó "hết hạn" hơn lịch sử vì giả định cơ bản trong thiết kế của EVM là khi một đối tượng trạng thái được tạo, nó sẽ tồn tại mãi mã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. Một số người lập luận rằng vấn đề này có thể không quá tệ nếu chúng ta đưa ra trạng thái không trạng thái: chỉ một lớp chuyên gia xây dựng khối mới thực sự cần lưu trữ trạng thái và tất cả các nút khác (thậm chí cả việc tạo danh sách!) có thể chạy không trạng thái. Tuy nhiên, một số người cho rằng chúng tôi không muố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 tôi có thể muốn các tiểu bang hết hạn để giữ cho Ethereum được phân cấp.

Nó là gì vậy? Nó hoạt động 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ể thực hiện theo một trong ba cách: (i) gửi ETH đến tài khoản mới, (ii) sử dụng mã để tạo tài khoản mới, (iii ) ) đặt một khe lưu trữ chưa được chạm tới trước đó), đối tượng trạng thái sẽ ở trạng thái đó mãi mãi. Thay vào đó, điều chúng ta muốn là các đối tượng sẽ tự động hết hạn theo thời gian. Thử thách chính là thực hiện việc này theo cách đạt được ba mục tiêu:

• < p>< mạnh>Hiệu quả: Không cần tính toán bổ sung rộng rãi để chạy quy trình hết hạn.

• Thân thiện với người dùng: Nếu ai đó đi vào hang động và quay lại sau 5 năm, họ sẽ không mất quyền kiểm soát ETH, ERC20, NFT của mình , Vị trí CDP Quyền truy cập…

• Sự 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 cứng nhắc và không được cập nhật ngày nay sẽ tiếp tục hoạt động tốt.

Không cần phải đạt được những mục tiêu này và vấn đề có thể được giải quyết dễ dàng. Ví dụ: bạn có thể yêu cầu mỗi đối tượng trạng thái cũng lưu trữ một bộ đếm để ghi lại ngày hết hạn của nó (có thể kéo dài bằng cách hủy ETH, điều này có thể tự động xảy ra khi đọc hoặc ghi) và có một vòng lặp lặp lại trạng thái để loại bỏ đố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í cả yêu cầu lưu trữ) và chắc chắn 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 khó giải thích về các trường hợp góc liên quan đến các giá trị được lưu trữ đôi khi bị đặt lại về 0. Nếu bạn đặt bộ hẹn giờ hết hạn trên toàn bộ hợp đồng, về mặt kỹ thuật, điều này sẽ giúp công việc của nhà phát triển trở nên dễ dàng hơn nhưng lại khiến vấn đề kinh tế trở nên khó khăn hơn: nhà phát triển phải xem xét cách "chuyển" chi phí lưu trữ liên tục sang người dùng của họ.

Đây là những vấn đề mà cộng đồng phát triển cốt lõi Ethereum đã phải vật lộn trong nhiều năm, bao gồm các đề xuất như "cho thuê blockchain" và "tái tạo". Cuối cùng, chúng tôi đã kết hợp những phần hay nhất của đề xuất và tập trung vào hai loại "giải pháp ít được biết đến nhấ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 khoảng thời gian đị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 cũng tuân theo các nguyên tắc tương tự. Chúng tôi chia nhà nước thành nhiều phần. Mỗi bản đồ lưu trữ vĩnh viễn một "bản đồ cấp cao nhất" trong đó các khối trống hoặc không trống. Dữ liệu trong mỗi khối chỉ được lưu trữ nếu nó được truy cập gần đây. Có một cơ chế "hồi sinh" trong đó nếu một khối không còn được lưu trữ nữa thì bất kỳ ai cũng có thể khôi phục dữ liệu bằng cách cung cấp bằng chứng về nó.

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

Có những phương pháp khác Những ý tưởng tương tự có thể được thực hiện. Ví dụ: nếu các tài khoản không có đủ khoảng cách, chúng ta có thể phát triển một sơ đồ trong đó mỗi phần 1/232 của cây được kiểm soát bởi cơ chế thân và lá tương tự.

Điều này phức tạp hơn do có các biện pháp khuyến khích: kẻ tấn công có thể "cập nhật cây" bằng cách đưa nhiều dữ liệu vào một cây con và gửi một giao dịch mỗi năm, buộc khách hàng phải lưu trữ vĩnh viễn nhiều trạng thái . Nếu bạn thực hiện chi phí cập nhật tỷ lệ thuận với kích thước cây (hoặc thời lượng cập nhật tỷ lệ nghịch với kích thước cây), thì ai đó có thể gây hại cho người dùng khác bằng cách đưa nhiều dữ liệu vào cùng 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 khoảng thời gian tài khoản linh hoạt theo kích thước cây 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; các cách tiếp cận dựa trên gốc rất đơn giản và có thể phối hợp các biện pháp khuyến khích vì thông thường tất cả dữ liệu trong một gốc đề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 thời gian địa chỉ

Điều gì sẽ xảy ra nếu chúng ta muốn tránh hoàn toàn mọi sự tăng trưởng trạng thái vĩnh viễn, ngay cả với sơ khai 32 byte? Đây là một câu hỏi khó: Đ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 đó sẽ đặ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ó? Đối với trạng thái hết hạn một phần, "sơ khai" sẽ ngăn không cho dữ liệu mới được tạo. Để hết hạn trạng thái đầy đủ, chúng tôi thậm chí không thể lưu trữ sơ khai.

Thiết kế dựa trên chu kỳ địa chỉ là cách tốt nhất để giải quyết vấn đề này. Thay vì một cây trạng thái lưu trữ toàn bộ trạng thái, chúng ta có một danh sách cây trạng thái ngày càng tăng và mọi trạng thái được đọc hoặc ghi đều đượ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 chu kỳ (ví dụ: 1 năm). Cây trạng thái cũ hơn được cố định. Một nút đầy đủ chỉ cần lưu trữ hai cây gần nhất. Nếu đối tượng trạng thái không được chạm vào trong hai chu kỳ và do đó rơi vào cây hết hạn, nó vẫn có thể được đọc hoặc ghi, nhưng giao dịch sẽ cần phải chứng minh bằng chứng Merkle cho nó - sau khi hoàn thành việc này, bản sao sẽ được lưu ở cây mới nhất lại ở giữa.

Ý tưởng chính giúp điều này trở nên thân thiện với tất cả người dùng và nhà phát triển là khái niệm về chu kỳ địa chỉ. Kỳ địa chỉ là số 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 danh sách cây trạng thái đạt đến độ dài 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), nếu bạn đảm bảo đưa đối tượng trạng thái vào hợp đồng có chu kỳ địa chỉ 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 trước đó không có gì. Mặt khác, bất kỳ bổ sung hoặc chỉnh sửa trạng thái nào đối với chu kỳ địa chỉ cũ đều yêu cầu chứng thực.

Thiết kế này giữ lại hầu hết các thuộc tính hiện tại của Ethereum với rất ít tính toán bổ sung, cho phép các ứng dụng được viết gần như như hiện tại (ERC20 cần được viết lại để đảm bảo sự cân bằng cho các địa chỉ có chu kỳ địa chỉ N được lưu trữ trong một sub -hợp đồng có kỳ địa chỉ N) và giải quyết vấn đề "người dùng đã ở trong hang được 5 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 để phù hợp với chu kỳ địa chỉ.

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

Đề xuất là giới thiệu định dạng địa chỉ 32 byte mới bao gồm số phiên bản, số khoảng thời gian địa chỉ và giá trị băm mở rộng.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

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

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

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

0xffffffff000169125d5dFcb7B8C2659029395bdF

Sự hy sinh chính của phương pháp này là nó gây ra rủi ro bảo mật cho địa chỉ phản thực: nắm giữ tài sản hoặc quyền. mã vẫn chưa được xuất bản tới địa chỉ trên chuỗi. Rủi ro liên quan đến việc ai đó 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 có một đoạn mã hợp lệ khác có hàm băm trỏ đến cùng một địa chỉ. Việc tính toán một xung đột như vậy ngày nay đòi hỏi 280 giá trị băm; việc thu hẹp không gian địa chỉ sẽ giảm con số này xuống còn 256 giá trị băm rất dễ tiếp cận.

Khu vực rủi ro chính, địa chỉ phản thực tế cho các ví không do một chủ sở hữu duy nhất nắm giữ, ngày nay tương đối hiếm khi xảy ra, nhưng điều này có thể thay đổi khi chúng ta chuyển sang thế giới đa L2 trở nên phổ biến hơn. 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 phổ biến có thể phát sinh vấn đề và đưa ra cách giải quyết hiệu quả.

Có những nghiên cứu nào hiện có?

Đề xuất sớm

Phí thuê blockchain: https://github.com/ethereum/EIPs/issues/35< /p >

Tái sinh: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ể dẫn đến 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

< strong>Trạng thái một phần đã hết hạn đề xuất

EIP-7736: https://eips.ethereum.org/EIPS/eip-7736

Tài liệu mở rộng không gian địa chỉ

Đề xuất ban đầu: https: //ethereum-magicians .org/t/increasing-address-size-from-20-to-32-bytes/5485

Ipsilon Nhận xét : https:/ /notes.ethereum.org/@ipsilon/address-space-extension-exploration

Nhận xét bài đăng trên blog: https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6

Điều gì sẽ xảy ra nếu chúng ta mất khả năng chống va chạm: https://ethresear.ch/t/what-would-break -if-we- loss-address-collision-resistance/11356

Còn việc gì phải làm? Sự đánh đổi là gì?

Tôi nghĩ có bốn con đường khả thi trong tương lai:

• < p> Chúng tôi không có quốc tịch và không bao giờ đưa ra quyết định hết hạn trạng thái. Trạng thái đang phát triển (mặc dù chậm: chúng ta có thể sẽ không thấy nó 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 PoS cũng không cần trạng thái.

  Một tính năng 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ể triển khai tính năng này theo cách phi tập trung: Mỗi người dùng chịu trách nhiệm duy trì một phần trạng thái cây chứa tài khoản của chính họ. Khi họ phát một giao dịch, họ sẽ phát đi bằng chứng về đối tượng trạng thái được truy cập trong bước xác minh (điều này áp dụng cho các tài khoản EOA và 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 toàn bộ danh sách.

• Chúng tôi thực hiện hết hạn một phần trạng thái và chấp nhận tốc độ tăng trưởng quy mô trạng thái vĩnh viễn thấp hơn nhiều nhưng vẫn khác 0. Kết quả như vậy có thể tương tự như đề xuất hết hạn lịch sử liên quan đến mạng ngang hàng, chấp nhận tốc độ tăng trưởng lưu trữ lịch sử vĩnh viễn mà tại đó mỗi khách hàng phải lưu trữ một tỷ lệ phần trăm dữ liệu lịch sử thấp hơn nhưng cố định, nhưng ở mức nhiều tốc độ tăng trưởng thấp hơn Nhiều hơn, nhưng vẫn không bằng không.

• Chúng tôi đã tuyên bố ngày hết hạn và mở rộng không gian địa chỉ. Điều này sẽ bao gồm một quy trình kéo dài nhiều năm để đảm bảo rằng phương thức chuyển đổi định dạng địa chỉ có hiệu quả và an toàn, bao gồm cả các ứng dụng hiện có.

• Chúng tôi tuyên bố ngày hết hạn và thu hẹp không gian địa chỉ. Điều này sẽ bao gồm một quy trình kéo dài 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ỉ, bao gồm cả các tình huống xuyên chuỗi, đều được xử lý.

Một điểm quan trọng là việc triển khai có phụ thuộc vào định dạng địa chỉ hay không thay đổi Sơ đồ hết hạn trạng thái cuối cùng phải giải quyết vấn đề mở rộng và thu hẹp không gian địa chỉ. Ngày nay, cần khoảng 2^80 hàm băm để tạo ra xung đột địa chỉ và tải tính toán này đã khả thi đối với các tác nhân cực kỳ giàu tài nguyên: GPU có thể thực hiện khoảng 2^27 hàm băm, tức là chạy trong một năm có thể tính toán 2^52, vì vậy tất cả ~2^30 GPU trên thế giới có thể tính toán xung đột trong ~1/4 năm, đồng thời FPGA và ASIC có thể tăng tốc quá trình này hơn nữa. Trong tương lai, những cuộc tấn công như vậ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ỉ đầy thách thức 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 thực hiện hết hạn trạng thái có thể giúp chuyển đổi từ định dạng cây trạng thái này sang định dạng cây trạng thái khác dễ dàng hơn vì không cần quá trình chuyển đổi: bạn chỉ cần bắt đầu tạo những cái mới trong cây định dạng mới và sau đó thực hiện phân nhánh cứng sau đó để chuyển đổi cây cũ. Vì vậy, mặc dù việc hết hạn trạng thái rất phức tạp nhưng nó giúp đơ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 được 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 giao thức đẹp và đơn giản thì ít xảy ra lỗi. Nó làm tăng cơ hội cho các nhà phát triển mới có thể tham gia và sử dụng bất kỳ phần nào của nó. Nó có vẻ công bằng hơn và dễ bảo vệ hơn trước những 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 không muốn Ethereum rơi vào hố đen ngày càng phức tạp, chúng ta cần thực hiện một trong hai việc: (i) Ngừng thực hiện các thay đổi và Làm cho giao thức trở nên cứng nhắc, (ii) cho phép loại bỏ chức năng trong thực tế và giảm độ phức tạp. Cũng có thể thực hiện được mộtcon đường trung gian, thực hiện ít thay đổi hơn đối với giao thức trong khi loại bỏ ít nhất một chút 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ậy? Nó hoạt động như thế nào?

Không một bản sửa lỗi 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 bản sửa lỗi nhỏ.

Một ví dụ gần như đã hoàn thiện có thể đóng vai trò là bản thiết kế chi tiết về cách xử lý các vấn đề khác là xóa mã opcode SELFDESTRUCT. Mã 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 độ phức tạp triển khai ứng dụng khách cao hơn để tránh DoS các cuộc tấn công. Mục đích ban đầu của opcode này là thực hiện việc dọn dẹp trạng thái tự nguyện, cho phép giảm kích thước trạng thái theo thời gian. Trên thực tế, rất ít người sử dụng nó. Mã hoạt động đã bị suy yếu để chỉ cho phép các tài khoản tự hủy được tạo trong cùng một giao dịch trong hard fork Dencun. Điều này giải quyết các vấn đề DoS và cho phép đơn giản hóa đáng kể mã máy khách. Trong tương lai, việc loại bỏ hoàn toàn opcode này có thể là hợp lý.

Các ví dụ chính về một số cơ hội đơn giản hóa giao thức được xác định cho đến nay bao gồm những ví dụ sau. Đầu tiên, một số ví dụ bên 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à thực hiện trong thời gian ngắn hơn.

• Chuyển đổi RLP → SSZ: Ban đầu, Đối tượng Ethereum được tuần tự hóa bằng cách sử dụng mã hóa gọi là RLP. Ngày nay, beacon chain sử dụng SSZ, loại SSZ này tốt hơn đáng kể về nhiều mặt, bao gồm cả việc hỗ trợ không chỉ tuần tự hóa mà còn hỗ trợ băm. Cuối cùng, chúng tôi hy vọng sẽ loại bỏ hoàn toàn RLP và chuyển tất cả các loại dữ liệu sang cấu trúc SSZ, điều này sẽ giúp việc nâng cấp dễ dàng hơn nhiều. Các EIP hiện được đề xuất cho việc này bao gồm [1] [2] [3].

• Xóa các loại giao dịch cũ: Hiện nay có quá nhiều loại giao dịch và nhiều loại trong số đó 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à tính năng Trừu tượng tài khoản, theo đó tài khoản thông minh có thể chứa mã để xử lý và xác minh các giao dịch cũ nếu họ chọn.

• Cải cách LOG: Nhật ký tạo ra các bộ lọc nở và logic khác, làm tăng độ phức tạp của giao thức, nhưng do tốc độ quá chậm nên máy khách thực sự sẽ không sử dụng nó. Chúng tôi có thể loại bỏ các tính năng này và thay vào đó đầu tư nỗ lực vào 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 ngoài giao thức sử dụng các công nghệ hiện đại như SNARK.

• Cuối cùng đã hủy cơ chế ủy ban đồng bộ hóa chuỗi beacon:Cơ chế ủy ban đồng bộ hóa ban đầu được giới thiệu để triển khai xác minh ứng dụng khách hạng nhẹ trong Ethereum. Tuy nhiên, nó làm tăng độ phức tạp của 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 cách sử dụng SNARK, điều này sẽ loại bỏ nhu cầu về các giao thức xác minh ứng dụng khách hạng nhẹ chuyên dụng. Bằng cách tạo ra một giao thức light client “bản địa” hơn bao gồm việc xác minh chữ ký từ một tập hợp con ngẫu nhiên của trình xác thực đồng thuận Ethereum.

• Điều phối định dạng dữ liệu: Ngày nay, 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 đốm màu được cam kết trong KZG Gửi biểu mẫu. Trong tương lai, sẽ rất hợp lý nếu tạo một định dạng thống nhất duy nhất cho dữ liệu và trạng thái khối. Các định dạng này sẽ đáp ứng tất cả các yêu cầu quan trọng: (i) bằng chứng đơn giản về máy khách không trạng thái, (ii) mã hóa dữ liệu tuần tự và xóa, (iii) cấu trúc dữ liệu được tiêu chuẩn hóa.

• Xóa Ủy ban Chuỗi Beacon: Cơ chế này ban đầu được giới thiệu để hỗ trợ một phiên bản cụ thể của phân đoạn thực thi. Thay vào đó, chúng tôi kết thúc việc phân chia thông qua L2 và các đốm màu. Vì vậy, ủy ban là không cần thiết và những nỗ lực đang được thực hiện để loại bỏ nó.

• Xóa bỏ endian hỗn hợp:EVM là big endian và lớp đồng thuận là little endian. Có thể hợp lý nếu sắp xếp lại và biến mọi thứ thành big endian (có thể là big endian vì EVM khó thay đổi hơn).

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

• Cơ chế gas đơn giản hóa:Các quy tắc gas hiện tại chưa được tối ưu hóa tốt và không thể giới hạn rõ ràng số lượng tài nguyên cần thiết để xác minh các khối. Các ví dụ chính về điều này bao gồm (i) chi phí đọc/ghi lưu trữ, được thiết kế để giới hạn số lần đọc/ghi trong một khối nhưng hiện tại rất tùy tiện và (ii) các quy tắc lấp đầy bộ nhớ, hiện khó ước tính mức tối đa. mức tiêu thụ bộ nhớ của EVM. Các biện pháp khắc phục được đề xuất bao gồm thay đổi chi phí gas không trạng thái, điều chỉnh tất cả chi phí liên quan đến lưu trữ thành một công thức đơn giản và đề xuất giá bộ nhớ.

• Xóa các trình biên dịch trước: Nhiều trình biên dịch trước mà Ethereum có ngày nay đều phức tạp không cần thiết và tương đối không được sử dụng, đồng thời gây ra một số lượng lớn lỗi đồng thuận bị lỗi. Tỷ lệ phần trăm lớn nhưng không thực sự được sử dụng bởi bất kỳ ứng dụng nào. Hai cách để giải quyết vấn đề này là (i) loại bỏ trực tiếp quá trình biên dịch trước và (ii) thay thế nó bằng mã EVM (chắc chắn đắt hơn) thực hiện cùng một logic. Bản dự thảo EIP này khuyên bạn nên thực hiện việc này để biên dịch trước danh tính trước; sau đó, RIPEMD160, MODEXP và BLAKE có thể bị xóa.

• Loại bỏ khả năng quan sát khí: Làm cho việc thực thi EVM không còn có thể xem lượng khí còn lại. Điều này sẽ phá vỡ một số ứng dụng (đáng chú ý nhất là các giao dịch được tài trợ), nhưng sẽ giúp nâng cấp dễ dàng hơn trong tương lai (ví dụ: đối với các phiên bản khí đa chiều tiên tiến hơn). Đặc tả EOF đã làm cho khí không thể quan sát được, nhưng để giúp đơn giản hóa giao thức, EOF cần phải trở thành bắt buộc.

• Cải tiến phân tích tĩnh:Mã EVM ngày nay khó phân tích tĩnh, đặc biệt vì các bước nhảy có thể động. Điều này cũng gây khó khăn hơn cho việc triển khai EVM được tối ưu hóa để 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ụ: chi phí gas tuyến tính với tổng số JUMPDEST trong hợp đồng). EOF thực hiện điều đó, nhưng việc thu được lợi ích đơn giản hóa giao thức từ nó đòi hỏi phải bắt buộc phải thực hiện EOF.

Có những nghiên cứu nào hiện có?

Các bước tiếp theo để thanh lọc: https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA

SELFDESTRUCT: https://hackmd.io/@vbuterin/selfdstruct

EIPS-ification SSZ: [1] [2] [3]

Thay đổi chi phí gas không trạng thái : https://eips.ethereum org. /EIPS/eip-4762

Giá bộ nhớ tuyến tính: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw

Đã xóa phần biên dịch trước:< a href="https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg" _src="https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg">https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg

Xóa bộ lọc Bloom: https://eips.ethereum.org/EIPS/eip-7668

A Một cách tiếp cận để tắt -truy xuất nhật ký an toàn chuỗi bằng cách sử dụng tính toán có thể kiểm chứng gia tăng (đọc: STARK đệ quy): https ://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

Nên làm gì khác và phải đánh đổi những gì?

Sự đánh đổi chính trong việc đơn giản hóa tính năng này là (i) mức độ và tốc độ đơn giản hóa của chúng tôi so với (ii) khả năng tương thích ngược. Giá trị của Ethereum như một chuỗi nằm ở chỗ nó là nền tảng nơi bạn có thể triển khai một ứng dụng và tin tưởng rằng nó vẫn sẽ hoạt động trong nhiều năm sau đó. Đồng thời, có thể đưa lý tưởng này đi quá xa và theo cách nói của William Jennings Bryan, “đóng đinh Ethereum trên thập giá của 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 và một trong số chú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à đạt được giá trị tổng hợp là 57 USD, thì chúng ta nên loại bỏ tính năng đó. tính năng, nếu cần thiết. Trả $57 tiền túi cho nạn nhân.

Vấn đề xã hội rộng hơn là việc tạo ra một quy trình tiêu chuẩn hóa để thực hiện các thay đổi vi phạm khả năng tương thích ngược không khẩn cấp. Một cách để giải quyết vấn đề này là kiểm tra và mở rộng các tiền lệ hiện có, chẳng hạn như quy trình SELFDESTRUCT. Quy trình trông như thế này:

• Bước 1: mạnh mẽ>Bắt đầu thảo luận về việc xóa tính năng X.

• Bước 2: Tiến hành phân tích để xác định xem việc loại bỏ gây tổn hại như thế nào được tiến hành theo kế hoạch hoặc (iii) xác định phương pháp sửa đổi "ít phá hoại nhất" loại bỏ X và tiến hành.

• Bước 3: Phát triển 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í) tôn trọng điều này và ngừng sử dụng tính năng này.

• Bước 4:Cuối cùng, thực sự xóa X.

Cần có một quá trình kéo dài nhiều năm giữa bước 1 và bước 4, với hướng dẫn rõ ràng về dự án nào đang ở bước nào. Tại thời điểm này, có sự cân bằng giữa cường độ và tốc độ của quá trình loại bỏ tính năng so với việc thận trọng hơn và đưa 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, nhưng chúng ta vẫn còn cách xa biên giới Pareto.

EOF

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

Lợi ích của việc này là nó tạo ra 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 cách loại bỏ EVM cũ. Câu hỏi chính 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 tổng thể 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 đề 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ụ ở 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, làm lại 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 đủ tính năng trừu tượng hóa tài khoản cho phép chúng tôi loại bỏ phần lớn logic xử lý giao dịch hiện có bằng cách chuyển nó thành một đoạn "mã EVM tài khoản mặc định" mà tất cả EOA có thể thay thế bằng .

• 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 chỉnh với các phiên bản SSZ mới để tất cả cấu trúc dữ liệu Ethereum hoạt động theo cùng một cách Băm.

Một cách tiếp cận triệt để hơn: chuyển đổi hầu hết giao thức thành mã hợp đồng

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 đổi phần lớn giao thức từ chức năng giao thức sang mã hợp đồng.

Phiên bản cực đoan nhất là biến 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 (chẳng hạn như RISC-V, Cairo hoặc một máy ảo đơn giản hơn dành riêng cho hệ thống chứng minh), cho phép bất kỳ ai khác để tạo ra sự tổng hợp của riêng họ. EVM sau đó sẽ trở thành sản phẩm đầu tiên trong số các bản tổng hợp này. Trớ trêu thay, đây lại là kết quả giống hệt với đề xuất Môi trường điều hành 2019-20, mặc dù SNARK khiến việc thực hiện nó trên thực tế trở nên khả thi hơn.

Một cách tiếp cận nhẹ nhàng hơn Nó là giữ nguyên mối quan hệ giữa chuỗi beacon và môi trường thực thi Ethereum hiện tại mà thay vào đó là trao đổi EVM tại chỗ. Chúng ta có thể chọn RISC-V, Cairo hoặc một máy ảo khác làm "máy ảo Ethereum chính thức" mới và sau đó buộc tất cả các hợp đồng EVM vào mã máy ảo mới (thông qua quá trình biên dịch hoặc giải thích) để diễn giải logic của mã gốc. Về lý thuyết, điều này thậm chí có thể được thực hiện với "VM mục tiêu" dưới dạng phiên bản EOF.