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

• Dữ liệu lịch sử: mọi giao dịch được thực hiện và mọi tài khoản được tạo ra tại bất kỳ thời đ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 xuống bởi bất kỳ khách hàng mới nào thực hiện đồng bộ hoàn toàn với mạng lưới. Điều này gây ra tải cho khách hàng và thời gian đồng bộ hóa tăng theo thời gian, ngay cả khi khả năng của chuỗi vẫn giữ nguyên.
• Tính năng giao thức: việc thêm một tính năng mới dễ 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 lên theo thời gian.

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

The Purge, lộ trình 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à suy giảm trong khi duy trì tính liên tục hoàn toàn có thể nếu chúng ta tập trung vào nó. Các hệ thống sống có thể làm được điều này: trong khi hầu hết tuổi tác theo thời gian, một vài người may mắn không. Ngay cả các hệ thống xã hội cũng có thểcó tuổi thọ cực lớn. Trong một số trường hợp, Ethereum đã chứng tỏ được những thành công: công việc chứng minh đã mất, lệnh SELFDESTRUCT hầu như đã 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 hiểu con đường này cho Ethereum một cách tổng quát hơn, và tiến gần đến một kết quả cuối cùng ổn định trong dài hạn, là thách thức tối cao của khả năng mở rộng dài hạn, bền vững kỹ thuật và thậm chí là bảo mật 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 thiểu hoặc loại bỏ nhu cầu cho mỗi nút lưu trữ vĩnh viễn toàn bộ lịch sử và có thể cuối cùng là 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

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

Hết hạn lịch sử

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

Kể từ thời điểm viết bài này, một nút Ethereum được đồng bộ đầy đủ yêu cầu khoảng 1,1 terabyte của không gian đĩa cho khách hàng thực thi, cộng thêm một vài trăm gigabyte khác cho khách hàng đồng thuận. Đa số lớn của điều này 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ó từ nhiều năm trước. Đ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.

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

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

Điều này mở ra nhiều tùy chọn cho 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 cùng mạng 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 giảm tính ổn định 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ể đạt đượ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ột mạng 10.000 nút trong đó 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 tất cả các nút lưu trữ toàn bộ 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ọc) chỉ được lưu trữ trong khoảng ~6 tháng. Các đối tượng chỉ được lưu trữ trong khoảng ~18 ngày.EIP-4444mục tiêu 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 nhận lịch sử. Một mục tiêu dài hạn là có một khoảng thời gian được điều hòa (có thể là ~18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ tất cả 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 cách phân tán.

Mã hóa sửa lỗi 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 dữ liệu đã được mã hóa sửa lỗi để 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 sửa lỗi này và đưa dữ liệu khối thực thi và đồng thuận vào các khối dữ liệu.

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

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrents và EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
• Mạng 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 trong Cổng: 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 (Mô hình): https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

Còn gì để làm, và phải đánh đổi những 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 hiện, nhưng cuối cùng cũng là sự đồng thuận và các khối dữ liệu. Các giải pháp dễ dàng nhất cho điều này là (i) đơn giản là giới thiệu một thư viện torrent hiện có, và (ii) một giải pháp Ethereum-native được gọi là mạng cổng. Một khi một trong số này được giới thiệu, chúng ta có thể bật EIP-4444 lên. Chính EIP-4444 không yêu cầu một hard fork, mặc dù nó yêu cầu 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 client cùng một lúc, vì nếu không, có nguy cơ client hoạt động không đúng từ việc kết nối với các node khác mong đợi tải xuống toàn bộ lịch sử nhưng thực tế không nhận được nó.

Sự đánh đổi chính là 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 sẽ là đơn giản ngừng lưu trữ lịch sử cổ ngày mai và phụ thuộc vào các nút lưu trữ lưu trữ hiện tại và các nhà cung cấp trung tâm khác nhau cho việc sao chép. Điều này dễ dàng, nhưng làm suy yếu vị trí của Ethereum như một nơi để lưu trữ hồ sơ vĩnh viễn. Con đường khó khăn hơn, nhưng an toàn hơn, là trước tiên xây dựng và tích hợp mạng torrent để lưu trữ lịch sử theo cách phân tán. Ở đây, có hai chiều của việc “cố gắng đến đâu”:

1. Chúng ta cố gắng đến đâu để đảm bảo rằng một tập hợp các nút càng lớn càng tối đa thực sự 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 phương pháp cực kỳ hoang tưởng cho (1) sẽ liên quan đếnchứng minh quản lý tài sản: thực sự yêu cầu mỗi người chứng minh cổ phần lưu trữ một phần trăm lịch sử và kiểm tra mật mã thường xuyên để đảm bảo họ làm vậy. Một cách tiếp cận ôn hòa hơn là thiết lập một tiêu chuẩn tự nguyện cho phần trăm lịch sử mà mỗi khách hàng lưu trữ.

Đối với (2), một việc triển khai cơ bản chỉ đơn giản là lấy công việc đã được thực hiện ngày hôm nay: Cổng đã lưu trữ các tệp ERA chứa toàn bộ lịch sử Ethereum. Một việc triển khai cẩn thận hơn sẽ liên quan đến việc kết nối thực sự này với quá trình đồng bộ hóa, để nếu ai đó muốn đồng bộ hóa một nút lưu trữ toàn bộ lịch sử hoặc một 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ộ trực tiếp từ mạng Cổng.

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 cho là thậm chí còn quan trọng hơn tình trạng không trạng thái nếu chúng ta muốn làm cho nó cực kỳ dễ dàng để chạy hoặc quay một nút: trong số 1.1 TB mà một nút cần có, ~ 300 GB là trạng thái và ~ 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 để thiết lập chỉ có thể đạt được nếu cả tình trạng không trạng thái và EIP-4444 được triển khai.

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 phiên bản Ethereum mới hơn, từ đó giúp chúng trở nên đơn giản hơn rất nhiều. Ví dụ, nhiều dòng code có thể được an toàn loại bỏ bây giờ khi tất cả các ô lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được xoá bỏ.đã xóa. Bây giờ rằng việc chuyển đổi sang giao thức chứng minh cổ phần đã trở thành lịch sử cổ xưa, các khách hàng có thể an toàn loại bỏ tất cả mã liên quan đến giao thức chứng minh công việc.

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

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

Dù chúng tôi loại bỏ nhu cầu lưu trữ lịch sử cho 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, khoảng 50 GB mỗi năm, do sự phát triển liên tục của trạng thái: số dư và số lần gọi không hợp lệ, mã hợp đồng và lưu trữ hợp đồng. Người dùng có thể trả một khoản phí một lần để gán gánh nặng cho khách hàng 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ử, bởi vì EVM được thiết kế căn bản xung quanh 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ỳ thời điểm nào. Nếu chúng ta giới thiệu sự không có trạng thái, có một lý do rằng có lẽ vấn đề này không phải là quá tệ: chỉ có một lớp chuyên môn 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ồm(sản xuất!) có thể chạy không lưu 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 không lưu trạng thái, và cuối cùng chúng ta có thể muốn hủy bỏ trạng thái để duy trì tính phân tán của Ethereum.

Đó là cái 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 lưu trữ chưa được 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 hết hạn tự động theo thời gian. Thách thức chính là làm điều này một cách sao cho đạt được ba mục tiêu:

1. Hiệu quả: không đòi hỏi một lượng tính toán phụ lớn để 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. Sự 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 không quen thuộc. Ngoài ra, các ứng dụng hiện tại đã cứng nhắc và không cập nhật nên vẫn tiếp tục hoạt động tương đối tốt.

Thật dễ dàng để giải quyết vấn đề mà không thỏa mãn các 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 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 ghi ETH, có thể xảy ra tự động bất cứ lúc nào nó được đọc hoặc ghi) và có một quy trình lặp qua trạng thái để xóa các đối tượng trạng thái đã hết hạn. Tuy nhiên, điều này giới thiệu tính toán bổ sung (và thậm chí cả 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. Các nhà phát triển cũng sẽ gặp khó khăn trong việc lý luận về các trường hợp cạnh liên quan đến giá trị lưu trữ, đôi khi đặt lại về không. Nếu bạn thực hiện hợp đồng hẹn giờ hết hạn trên toàn hợp đồng, điều này làm cho cuộc sống của các nhà phát triển dễ dàng hơn về mặt kỹ thuật, nhưng nó làm cho tính kinh tế khó khăn hơn: các nhà phát triển sẽ phải suy nghĩ về cách “vượt qua” chi phí lưu trữ liên tục 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 đã gặp phải trong nhiều năm qua, bao gồm các đề xuất như “blockchain thuê“ và “regenesis“Cuố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 loại “giải pháp tốt nhất nhất đã được biết đến”:

• 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ỉ thời gian.

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 hoạt động theo nguyên tắc tương tự nhau. 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 các 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 lưu trữ nữa, bất kỳ ai cũng có thể đưa dữ liệu đó trở lại bằng cách cung cấp chứng cứ về dữ liệu đó là gì.

Sự khác biệt chính giữa các đề xuất này là: (i) làm thế nào để chúng ta định nghĩa “gần đây” và (ii) làm thế nào để chúng ta định nghĩa “khối”? Một đề xuất cụ thể là EIP-7736, xây dựng trên cơ sở 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 quốc tịch nào, ví dụ: cây nhị phân). Trong thiết kế này, tiêu đề, mã và khe lưu trữ liền kề nhau được lưu trữ dưới cùng một “thân”. Dữ liệu được lưu trữ dưới một thân cây có thể tối đa là 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ữ khóa, của một tài khoản sẽ được lưu trữ trong cùng một gốc. Nếu dữ liệu dưới một gốc nhất định 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 và thay vào đó chỉ có cam kết 32 byte (“sơ khai”) đối với dữ liệu được lưu trữ. Các giao dịch trong tương lai truy cập dữ liệu đó sẽ cần phải “hồi sinh” dữ liệu, với bằng chứng sẽ được kiểm tra so với sơ khai.

Có cách khác để thực hiện ý tưởng tương tự. Ví dụ, nếu độ chi tiết cấp tài khoản chưa đủ, chúng ta có thể tạo một kế hoạch trong đó mỗi 1/232 phần của cây được quản lý bằng cách sử dụng cơ chế tương tự 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ỉ và thời gian

Nếu chúng ta muốn tránh mọi tăng trưởng trạng thái vĩnh viễn, ngay cả khi chỉ là các 32-byte stubs, chúng ta sẽ phải đối mặt với một vấn đề khó khăn.@vbuterin/state_size_management#Resurrection-conflicts”>resurrection conflicts: điều gì sẽ xảy ra nếu một đối tượng trạng thái bị xóa, sau đó thực thi EVM đặ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 chu kỳ địa chỉ là ý tưởng được biết đến 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 ta có một danh sách cây trạng thái không ngừng mở rộng, và bất kỳ trạng thái nào được đọc hoặc ghi đều được lưu trữ trong cây trạng thái mới nhất. Một cây trạng thái mới trống rỗng được thêm vào mỗi chu kỳ (nghĩ: 1 năm). Các cây trạng thái cũ được đóng băng. Các nút đầy đủ chỉ cần lưu trữ hai cây mới nhất. Nếu một đối tượng trạng thái không được chạm trong hai chu kỳ và do đó rơi vào một cây đã hết hạn, nó vẫn có thể được đọc hoặc ghi, nhưng giao dịch sẽ cần chứng minh một chứng chỉ Merkle cho nó - và một khi đã làm, một bản sao sẽ được lưu trữ trong cây mới nhất.

Một ý tưởng quan trọng để làm cho tất cả điều này dễ sử dụng cho người dùng và nhà phát triển là khái niệm về khoảng thời gian địa chỉ. Một khoảng thời gian địa chỉ là một số là một phần của một địa chỉ. Một quy tắc quan trọng là một địa chỉ với khoảng thời gian địa chỉ N chỉ có thể được đọc hoặc ghi vào trong hoặc sau khoảng thời gian N (tức 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 một hợp đồng có khoảng thời gian địa chỉ là N hoặc N-1, sau đó 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ì ở đó. Bất kỳ thêm vào hoặc chỉnh sửa trạng thái trong các khoảng thời gian địa chỉ cũ hơn, tuy nhiên, đòi hỏi một bằng chứng.

Thiết kế này bảo tồn hầu hết các thuộc tính hiện tại của Ethereum, rất nhẹ về tính toán bổ sung, cho phép các ứng dụng được viết gần như ngày nay (ERC20 sẽ cần phải viết lại, để đảm bảo rằng số dư của các địa chỉ có khoảng thời gian địa chỉ N được lưu trữ trong hợp đồng con có khoảng thời gian đị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 để phù hợp với khoảng thời gian đị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, bao gồm số phiên bản, số chu kỳ địa chỉ và hàm băm mở rộng.

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

Màu đỏ là một số phiên bản. Bốn số không màu cam ở đây được dùng để làm 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à 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 các kỹ thuật đóng gói byte chặt chẽ mà rõ ràng giả định địa chỉ có đúng 20 byte.@ipsilon/address-space-extension-exploration”>Một ý tưởng để giải quyết vấn đề này liên quan đến một bản đồ dịch, trong đó hợp đồng kiểu cũ tương tác với địa chỉ kiểu mới sẽ nhìn thấy một băm 20 byte của địa chỉ kiểu mới. Tuy nhiên, có những phức tạp đáng kể liên quan đến việc làm cho điều này an toàn.

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

Một phương pháp khác đi theo hướng ngược lại: chúng ta ngay lập tức cấm một phạm vi con có kích thước 2128 địa chỉ (ví dụ: tất cả các địa chỉ bắt đầu bằng 0xffffffff), sau đó sử dụng phạm vi đó để giới thiệu địa chỉ với chu kỳ đị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 các rủi ro an ninh cho địa chỉ giả mạo: địa chỉ nắm giữ tài sản hoặc quyền hạn, nhưng mã của họ vẫ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ỉ mà cho rằng có một phần mã (chưa được công bố) nhưng cũng có một phần mã hợp lệ khác mà có cùng giá trị băm với địa chỉ đó. Việc tính toán một va chạm như vậy yêu cầu 2⁸⁰Hôm nay có hàng nghìn hashes; sự co lại không gian địa chỉ này sẽ giảm số lượng này xuống còn 2 rất dễ tiếp cận⁵⁶ băm.

Khu vực rủi ro chính, địa chỉ giả mạo không phải là ví do một chủ sở hữu duy nhất nắm giữ, là một trường hợp tương đối hiếm ngày nay, nhưng có khả năng 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 chỉ đơn giản 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 mà đây có thể là một vấn đề và đưa ra cách giải quyết hiệu quả.

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

• 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:@vbuterin/state_size_management””>@vbuterin/quản\_lý\_kích\_thước\_trạng\_thái"">https://hackmd.io/@vbuterin/quản\_lý\_kích\_thước\_trạng\_thái
• Một số 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:@vbuterin/state_expiry_paths””>@vbuterin/state\_expiry\_paths"">https://hackmd.io/@vbuterin/state\_expiry\_paths
• Đề 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: @ipsilon/address-space-extension-exploration””>@ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • Đánh giá bài đăng trên blog: @chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6””>@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
• Điều gì sẽ phá vỡ nếu chúng ta mất khả năng 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à sự đánh đổi là gì?

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

• Chúng tôi thực hiện trạng thái không, 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 phát triển (tuy chậm: chúng ta có thể không thấy nó 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: thậm chí ngay cả các người xác thực PoS cũng không cần phải giữ trạng thái. \
  \
  Một chức năng cần truy cập vào các 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ể thực hiện điều 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 họ phát một giao dịch, họ sẽ phát nó với bằng chứng về các đối tượng trạng thái được truy cập trong bước xác minh (điều này hoạt động cho cả tài khoản EOA và ERC-4337). Sau đó, người xác thực không trạng thái có thể kết hợp các bằng chứng này thành bằng chứng cho toàn bộ danh sách đưa vào.
• Chúng tôi hết hạn một phần tiểu bang và chấp nhận tỷ lệ tăng trưởng quy mô nhà nước vĩnh viễn thấp hơn nhiều nhưng vẫn không bằng không. Kết quả này được cho là tương tự như cách các đề xuất hết hạn lịch sử liên quan đến các mạng ngang hàng chấp nhận tỷ lệ tăng trưởng lưu trữ lịch sử vĩnh viễn thấp hơn nhiều nhưng vẫn không bằng không từ mỗi khách hàng phải lưu trữ một tỷ lệ phần trăm thấp nhưng cố định của dữ liệu lịch sử.
• Chúng tôi thực hiện việc hết hạn trạng thái, kèm theo việc mở rộng không gian địa chỉ. Điều này sẽ liên quan đến quy 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 hết hạn trạng thái, với việc 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 rằng tất cả các rủi ro về bảo mật liên quan đến va chạm địa chỉ, bao gồm cả các tình huống liên chuỗi, được xử lý.

Một điểm quan trọng là các vấn đề khó khăn xung quanh việc mở rộng và thu hẹp không gian địa chỉ cuối cùng sẽ phải được giải quyết bất kể các chương trình hết hạn của tiểu bang phụ thuộc vào thay đổi định dạng địa chỉ có được thực hiện hay không. Ngày nay, phải mất khoảng 2⁸⁰tạo ra va chạm địa chỉ, một lượng tính toán mà hiện tại đã có thể thực hiện được đối với các tác nhân có tài nguyên rất tốt: một GPU có thể thực hiện khoảng 2²⁷băm, vì vậy nếu chạy trong một năm, nó có thể tính toán được 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 thêm nữa. Trong tương lai, các cuộc tấn công như vậy sẽ trở nên mở rộng hơn và nhiều người hơn có thể tham gia. Do đó, chi phí thực tế để thực hiện việc hết hạn trạng thái đầy đủ có thể không cao như dường như, vì chúng ta phải giải quyết vấn đề địa chỉ khó khăn này dù sao.

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

Việc hết hạn trạng thái tiềm năng 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 phải có quy trình chuyển tiếp: bạn có thể đơn giản bắt đầu tạo ra các cây mới bằng cách sử dụng một định dạng mới, và sau đó thực hiện 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 í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

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 của bảo mật, tính khả dụng và tính trung lập đáng tin cậy 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.

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

Không có một sửa lớn nào có thể giảm bớt sự phức tạp của giao thức; bản chất bẩm sinh của vấn đề là có nhiều sửa nhỏ.

Một ví dụ đã gần hoàn thành và có thể được coi là một bản thiết kế để xử lý các ví dụ khác là @vbuterin/selfdestruct”>xóa opcode SELFDESTRUCT. Opcode SELFDESTRUCT là duy nhất opcode có thể sửa đổi một số lượng lưu trữ không giới hạn trong một khối duy nhất, yêu cầu các client triển khai phức tạp hơn để tránh tấn công DoS. Mục đích ban đầu của opcode là cho phép xóa trạng thái tự nguyện, cho phép kích thước trạng thái giảm theo thời gian. Trong thực tế, rất ít người sử dụng nó.Opcode đã bị nerfed để 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 hardfork Dencun. Điều này giải quyết vấn đề DoS và cho phép đơn giản hóa đáng kể trong mã máy khách. Trong tương lai, nó có thể có ý nghĩa để cuối cùng loại bỏ hoàn toàn opcode.

Một số ví dụ quan trọng về 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 đây. Thứ nhất, 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 khung 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 một mã hóa gọi là RLPRLP không định loại, và phức tạp không cần thiết. Ngày nay, beacon chain sử dụng SSZ, điều này tốt hơn rất nhiều mặt, bao gồm việc hỗ trợ không chỉ việc seri 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ũ: Ngày nay có quá nhiều loại giao dịch, có thể loại bỏ một số trong số chúng. 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 đó các tài khoản thông minh có thể bao gồm mã để xử lý và xác minh các giao dịch cũ theo kiểu cũ nếu họ muốn.
• LOG reform: logs tạo bộ lọc bloom và logic khác làm tăng sự phức tạp của giao thức, nhưng thực tế không được sử dụng bởi các client vì quá chậm. Chúng ta có thểxóa bỏ những tính năng nàyvà thay vào đó đặt nỗ lực vào các phương pháp thay thế, 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ô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 đèn dẫn: cơ chế hội đồng đồ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 thêm sự phức tạp đáng kể cho giao thức. Cuối cùng, chúng ta sẽ có thể xác minh trực tiếp tầng đồng thuận Ethereum bằng cách sử dụng SNARKs, điều này sẽ loại bỏ nhu cầu cho một giao thức xác minh máy khách nhẹ riêng biệt. Tiềm năng, các thay đổi về sự đồng thuận có thể cho phép chúng ta loại bỏ các ủy ban đồng bộ hóa ngay cả sớm hơn, thông qua việc tạo ra một giao thức máy khách nhẹ ‘bản địa’ hơn bằng cách xác minh chữ ký từ một tập con ngẫu nhiên của các nhà xác thực sự đồng thuận Ethereum.
• Đồng bộ định dạng dữ liệu: hiện nay, trạng thái thực hiện được lưu trữ trong cây Merkle Patricia, trạng thái đồng thuận được lưu trữ trong một cây SSZ, và các khối dữ liệu được cam kết với @vbuterin/proto_danksharding_faq#What-format-is-blob-data-in-and-how-is-it-committed-to”>KZG cam kết. Trong tương lai, thật hợp lý khi 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. Các định dạng này sẽ đáp ứng 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 trạng thái, (ii) tuần tự hóa và mã hóa xóa cho dữ liệu, (iii) cấu trúc dữ liệu được tiêu chuẩn hóa.
• Loại bỏ các ủy ban 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 phân tán thực thiThay vào đó, chúng tôi kết thúc việc làm phân mảnh qua L2s và blobs. Do đó, các ủy ban là không cần thiết, và vì vậy có một tiến trình đang diễn ra để loại bỏ chúng.
• Loại bỏ tính chất đa hướng: EVM là big-endian và lớp đồng thuận là little-endian. Có thể có ý nghĩa để làm lại-hoà và làm cho tất cả mọi thứ trở thành một trong hai (có thể là big-endian, bởi 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 không được tối ưu hóa tốt để đưa ra giới hạn rõ ràng cho 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/viết lưu trữ, được thiết kế để giới hạn số lần đọc/viết trong một khối nhưng hiện tại khá bừa bãi, và (ii) các quy tắc điền bộ nhớ, nơi mà hiện tại rất khó để ước lượng lượng bộ nhớ tối đa tiêu thụ của EVM. Các sửa đổi đề xuất bao gồm thay đổi chi phí khí không trạng thái, giúp hài hòa tất cả các chi phí liên quan đến lưu trữ vào một công thức đơn giản, và đề xuất về giá nhớ.
• Gỡ bỏ precompiles: nhiều precompiles hiện tại của Ethereum không cần thiết phức tạp và ít được sử dụng, và chiếm một phần lớn thất bại gần như đồng thuận trong khi 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) chỉ đơn giản là loại bỏ precompile và (ii) thay thế nó bằng một đoạn mã EVM (tự nhiên đắt đỏ hơn) thực hiện cùng logic.Bản nháp EIP này đề xuấtđể làm đ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í: làm cho việc thực thi EVM không còn có thể xem được còn bao nhiêu khí. Đ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 việc nâng cấp dễ dàng hơn trong tương lai (ví dụ, cho các phiên bản tiên tiến hơn củađa chiều khí). The EOF specĐã khiến khí trở nên không thể quan sát được, mặc dù để 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 về phân tích tĩnh: hiện nay mã EVM khó để phân tích tĩnh, đặc biệt là vì các nhảy có thể là động. Điều này cũng làm cho việc tối ưu hóa các phiên bản EVM khó hơn, vì chúng cần được biên dịch trước mã EVM thành ngôn ngữ khác. Chúng ta có thể khắc phục điều này bằng cách…loại bỏ những bước nhảy động (hoặc làm chúng trở nên đắt đỏ hơn rất nhiều, ví dụ như chi phí gas tuyến tính theo tổng số JUMPDESTs trong một hợp đồng). EOF làm điều này, tuy nhiên để đạt được lợi ích đơn giản hóa giao thức từ điều này sẽ yêu cầu làm cho EOF bắt buộc.

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

• Các bước tiếp theo trong quá trình Xóa sạch:https://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• TỰ HỦY: @vbuterin/selfdestruct””>@vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
• SSZ-ification EIPS: [1][2] [3]
• Thay đổi chi phí gas phi trạng thái: https://eips.ethereum.org/EIPS/eip-4762
• Định giá bộ nhớ tuyến tính: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• Gỡ bỏ tiền xử lý trước: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• Loại bỏ bộ lọc Bloom: https://eips.ethereum.org/EIPS/eip-7668
• Một cách để thực hiện truy xuất 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 gia tăng (đọc: STARK đệ quy): https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

Còn lại gì để làm và những điều đánh đổi là gì?

Sự đánh đổi chính trong việc thực hiện loại đơn giản hóa tính năng này là (i) chúng ta đơn giản hóa bao nhiêu và nhanh như thế nào 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 nơi bạn có thể triển khai một ứng dụng và tự tin rằng nó vẫn sẽ hoạt động trong nhiều năm kể từ bây giờ. Đồng thời, có thể đưa lý tưởng đó đi quá xa, và, để diễn giải lại William Jennings Bryan, “đóng đinh Ethereum trên một thập tự luyện của tính tương thích ngược”. Nếu chỉ có hai ứng dụng trong tất cả Ethereum sử dụng một tính năng cụ thể, và một trong số đó không có người dùng trong nhiều năm và cái kia gần như không được sử dụng và bảo vệ tổng cộng $57 giá trị, thì chúng ta chỉ cần loại bỏ tính năng đó, và nếu cần, trả cho nạn nhân $57 từ túi của chúng ta.

Vấn đề xã hội rộng lớn nằm ở việc tạo ra một đường ống chuẩn hóa cho việc thực hiện các thay đổi phá vỡ tính tương thích ngược không khẩn cấp. Một cách tiếp cận vấn đề này là xem xét và mở rộng các tiền lệ hiện tại, 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: phân tích để xác định việc loại bỏ X làm hỏng ứng dụng ra sao, tùy thuộc vào kết quả mà (i) từ bỏ ý tưởng, (ii) tiến hành theo kế hoạch, hoặc (iii) xác định một cách sửa đổi ‘ít gây rối’ để loại bỏ X và tiếp tục với cách đó
• Bước 3: tạo một EIP chính thức để loại bỏ X. Đảm bảo rằng các 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

Có thể có một đường ống kéo dài nhiều năm giữa bước 1 và bước 4, với thông tin rõ ràng về các mục ở bước nào. Tại thời điểm đó, có một sự cân nhắc giữa việc đường ống loại bỏ tính năng làm việc mạnh mẽ và nhanh chóng hơn, so với việc cẩ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 tôi vẫn cách xa so với biên Pareto.

EOF

Một bộ các thay đổi quan trọng đã đượ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 khí, 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 cách có tính chất mạnh hơn, trong khi vẫn giữ nguyên khả năng 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 đường dẫn tự nhiên để thêm các tính năng EVM mới 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 hơn. Nhược điểm của nó là nó tăng đáng kể sự phức tạp của giao thức, trừ khi chúng ta tìm được cách để dần dần loại bỏ và xóa 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 là nếu mục tiêu là giảm sự phức tạp của EVM như một tổng thể?

Nó tương tác như thế nào 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 tính cuối cùng của một vị trí 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 liên quan đến bằng chứng cổ phần 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 chuyển nó vào một phần mã EVM tài khoản “mặc định” mà tất cả các EOAs có thể được thay thế bởi.
• Nếu chúng ta 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 phiên bản SSZ mới, để tất cả cá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 cực đoan hơn: biến 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ư hiện tại, nhưng chuyển một phần lớn từ tính năng giao thức thành 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 chỉ là mạng beacon và giới thiệu một máy ảo tối giản (VD. RISC-V, Cairo, hoặc thậm chí là một cái gì đó còn tối giản hơn dành cho việc chứng minh hệ thống) cho phép bất kỳ ai khác tạo ra rollup riêng của họ. EVM sau đó sẽ trở thành rollup đầu tiên của chúng. Điều này là một cách trùng hợp chính xác giống như kết quả của điều đó làgiao thức môi trường thực thi từ 2019-20, mặc dù SNARKs làm cho việc triển khai trở nên khả thi hơn đáng kể.

Một cách tiếp cận vừa phải hơn sẽ 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 hoán đổ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, sau đó buộc chuyển đổi tất cả các hợp đồng EVM thành mã VM mới diễn giải logic của mã gốc (bằng cách biên dịch hoặc giải thích nó). Về mặt lý thuyết, điều này thậm chí có thể được thực hiện với “máy ảo mục tiêu” 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ả 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 Gate Họcđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là quan điểm 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 Học viên cửa hàng. Trừ khi có đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.