Vitalik về tương lai có thể có của Ethereum (5): Cuộc thanh trừng
Được tổng hợp bởi trí tuệ nhân tạo
Tiêu đề gốc: Tương lai có thể có của giao thức Ethereum, phần 5: Cuộc thanh trừng
Tác giả gốc: Vitalik Buterin
Bản tổng hợp gốc: Người chồng, Odaily Planet Daily
Ghi chú của người dịch: Kể từ ngày 14 tháng 10, Vitalik Buterin, người sáng lập Ethereum, đã liên tiếp đưa ra các cuộc thảo luận về tương lai có thể có của Ethereum, từ "The Merge", "The Surge" ", “The Scourge”, “The Verge” cho đến bản phát hành mới nhất “The Purge” thể hiện tầm nhìn của Vitalik về sự phát triển trong tương lai của mạng chính Ethereum và cách giải quyết các vấn đề hiện đang gặp phải.
"The Merge": Thảo luận về những cải tiến mà Ethereum cần thực hiện sau khi di chuyển sang tính hữu hạn của một khe PoS và hạ thấp ngưỡng đặt cược để tăng tốc độ tham gia và xác nhận giao dịch.
"The Surge": Đã thảo luận về các chiến lược khác nhau để mở rộng Ethereum, đặc biệt là lộ trình tập trung vào Rollup cũng như các thách thức và giải pháp của nó về khả năng mở rộng, phân cấp và bảo mật.
"Tai họa": Thảo luận về những thách thức mà Ethereum phải đối mặt trong quá trình chuyển đổi sang PoS Tập trung hóa và rủi ro khai thác giá trị, nhiều cơ chế khác nhau đã được phát triển để tăng cường phân cấp và công bằng, đồng thời thực hiện cải cách kinh tế để bảo vệ lợi ích của người dùng.
"The Verge": Thảo luận về những thách thức và thách thức của việc xác minh không trạng thái trong Ethereum Giải pháp tập trung vào cách các công nghệ như cây Verkle và STARK có thể nâng cao tính phân quyền và hiệu quả của chuỗi khối.
Vào ngày 26 tháng 10, Vitalik Buterin đã xuất bản một bài báo về "The Purge", trong đó thảo luận về thách thức mà Ethereum phải đối mặt là giảm độ phức tạp và yêu cầu lưu trữ về lâu dài trong khi vẫn duy trì độ bền và tính phân cấp của chuỗi Tập trung. , các biện pháp chính bao gồm giảm gánh nặng lưu trữ của máy khách thông qua "hết hạn lịch sử" và "hết hạn trạng thái" cũng như đơn giản hóa giao thức thông qua "làm sạch tính năng" để đảm bảo tính bền vững và khả năng mở rộng của mạng. Sau đây là nội dung gốc, được Odaily Planet Daily biên soạn.
Đặ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ọ.
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 ở 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 tại bất kỳ thời điểm nào trong lịch sử 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, do đó đồng bộ hóa hoàn toàn với mạng. Điều này khiến thời gian tải và đồng bộ hóa của khách hàng tăng lên theo thời gian, ngay cả khi công suất của chuỗi vẫn giữ nguyên.
· 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 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 ta cần duy trì một trong những thuộc tính quan trọng làm cho blockchain trở nên tuyệt vời: tính bền bỉ. 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 1 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 ở đó chờ bạn đọc và tương tác với nó . Để các DApp cảm thấy thoải mái khi được phân cấp 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 nâng cấp theo cách phá vỡ chúng - đặc biệt là chính L1.
Nếu chúng ta quyết tâm đạt được sự cân bằng giữa hai nhu cầu này và giảm thiểu hoặc việc đảo ngược sự phình to, phức tạp và phân rã trong khi vẫn duy trì tính liên tục là điều hoàn toàn có thể thực hiện đượ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 gần như không còn nữa và các nút chuỗi beacon đã lưu trữ dữ liệu cũ có giá trị lên đến sáu tháng. Tìm ra con đường này cho Ethereum một cách tổng quát hơn và 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 về bộ nhớ 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ử và thậm chí cả trạng thái cuối cùng.
· Giảm độ phức tạp của giao thức bằng cách loại bỏ các chức năng không cần thiết.
Thư mục bài viết:
· Hết hạn lịch sử (hết hạn lịch sử)
· Hết hạn trạng thái (hết hạn trạng thái) )
·Dọn dẹp tính năng
Hết hạn lịch sử
Vấn đề gì được giải quyết?
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 để thực thi ứng dụng khách, cộng với hàng trăm GB dung lượng ổ đĩa được sử dụng bởi các ứng dụng 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 trong số đó đã có từ nhiều năm trước. Điều này có nghĩa là các nút sẽ tiếp tục tăng kích thước 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à hoạt động như thế nào?
Một đặc điểm đơn giản hóa quan trọng của vấn đề lưu trữ lịch sử là do 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ẽ có sự đồng thuận về hiện tại Chỉ cần đạt được sự đồng thuận về lịch sử là đủ. Miễn là mạng đạt được sự đồng thuận về khối mới nhất, bất kỳ khối, giao dịch hoặc trạng thái lịch sử nào (số dư tài khoản, số lần sử dụng, mã, bộ lưu trữ) đề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 nó. Sự đúng đắn. Sự đồng thuận là mô hình tin cậy N/2-of-N, trong khi lịch sử là mô hình tin cậy N-of-N.
Điều này mang lại cho chúng ta nhiều lựa chọn về cách 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 chúng ta có thể xây dựng một mạng lưới gồm 100.000 nút bằng cách làm cho việc chạy các nút trở nên tiết kiệm hơn, trong đó mỗi nút lưu trữ 10% lịch sử ngẫu nhiên thì mỗi phần dữ liệu sẽ được sao chép 10.000 lần - so với 10.000. Hệ số sao chép của mỗi nút hoàn toàn giống nhau - một mạng lưới các nút, 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à thiết lập một khoảng thời gian thống nhất (có thể là khoảng 18 ngày) trong đó mỗi nút chịu trách nhiệm lưu trữ mọi thứ và sau đó thiết lập mạng lưới các nút Ethereum ngang hàng để lưu trữ dữ liệu cũ theo cách mạng phân tán.
Mã xóa có thể được sử dụng để tăng độ chắc chắn trong khi vẫn giữ nguyên hệ số sao chép. Trên thực tế, các đốm màu đã được 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 các mã xóa như vậy và đưa dữ liệu khối thực thi và đồng thuận vào các đốm màu.
Mối liên hệ với nghiên cứu hiện tại là gì?
· EIP-4444 ;
· Mạng cổng thông tin; p>
· Mạng cổng thông tin và EIP-4444 ;
· Lưu trữ phân tán và truy xuất các đối tượng SSZ trong Cổng thông tin;
· Cách tăng giới hạn gas (Mô hình).
Còn cần làm gì nữa và cần cân nhắc những gì?
Công việc chính còn lại bao gồm xây dựng và tích hợp một giải pháp phân tán cụ thể để lưu trữ lịch sử - ít nhất là lịch sử thực thi, nhưng cuối cùng cũng có sự đồng thuận và blob. Các giải pháp đơn giản nhất là (i) chỉ cần đưa vào 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 bất kỳ thứ nào trong số này được giới thiệu, chúng tôi có thể mở 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ả khách hàng cùng một lúc là rất có giá trị, nếu không sẽ có nguy cơ khách hàng không thể kết nối với các nút khác với mong muốn 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 liên quan đến việc chúng ta cố gắng cung cấp dữ liệu lịch sử "cổ" đến mức nào. Giải pháp đơn giản nhất là ngừng lưu trữ lịch sử cổ đại 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 để nhân rộng. Điều đó thật dễ dàng, nhưng nó làm suy yếu vị thế của Ethereum như một nơi lưu trữ lâu dài. 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, "chúng tôi cố gắng đến mức nào" có hai khía cạnh:
1. Chúng tôi cố gắng đến mức nào để đảm bảo rằng tập hợp nút lớn nhất thực sự lưu trữ tất cả dữ liệu?
2. Chúng tôi tích hợp lưu trữ lịch sử vào giao thức ở mức độ nào?
Một cách tiếp cận cực kỳ hoang tưởng đối với (1) sẽ liên quan đến bằng chứng cổ phần: 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ệ nhất định của lịch sử và Kiểm tra thường xuyên bằng mật mã để đảm bảo họ làm như vậy. 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 công việc đã hoàn thành ngày hôm nay: Cổng thông tin đã lưu trữ tệp ERA chứa toàn bộ lịch sử của 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 nó 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 tồn tại 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 một nút trở nên cực kỳ dễ dàng thì việc giảm yêu cầu lưu trữ lịch sử được cho là quan trọng hơn tình trạng không trạng thái: ở mức 1,1 TB theo yêu cầu của nút Trong số này, khoảng 300 GB là trạng thái và khoảng 800 GB còn lại là lịch sử. Chỉ bằng cách triển khai trạng thái không trạng thái và EIP-4444, tầm nhìn chạy nút Ethereum trên đồng hồ thông minh và chỉ mất vài phút để thiết lập mới có thể thành hiện thực.
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 chỉ hỗ trợ phiên bản mới nhất của giao thức trở nên khả thi hơn, khiến chúng trở nên đơn giản hơn. Ví dụ: nhiều dòng mã hiện 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.
Nhà nước 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ữ lịch sử của khách hàng, nhu cầu lưu trữ của khách hàng sẽ tiếp tục tăng, khoảng 50 GB mỗi năm, vì trạng thái tiếp tục tăng : số dư tài khoản và số ngẫu nhiên, mã hợp đồng và lưu trữ hợp đồng. Người dùng có thể trả phí một lần, tạo gánh nặng mãi mãi cho 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ì EVM về cơ bản được thiết kế dựa trên giả định rằng một khi đối tượng trạng thái được tạo, nó luôn tồn tại và có thể được đọc bởi bất kỳ giao dịch nào bất cứ lúc nào. Một số ý kiến cho rằng vấn đề này có thể không quá tệ nếu chúng ta đưa vào trạng thái không trạng thái: chỉ lớp xây dựng khối chuyên dụng mới thực sự lưu trữ trạng thái, trong khi 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, có một lập luận được đưa ra 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 hết hạn các trạng thái để giữ cho Ethereum được phân cấp.
Nó là gì và hoạt động như thế nào
Ngày nay, khi bạn tạo một Khi nào mới một đối tượng trạng thái được tạo (có thể xảy ra 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 khe lưu trữ chưa được chạm tới trước đó), đối tượng trạng thái mãi mãi ở trạng thái này. 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:
1. Hiệu quả: Không cần tính toán bổ sung đáng kể để chạy quy trình hết hạn.
2. Thân thiện với người dùng: Nếu ai đó vào hang trong 5 năm và quay lại, họ sẽ không mất quyền truy cập vào ETH, ERC 20, NFT, CDP vị trí… …
3. Thân thiện với nhà phát triển: 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 đang được củng cố và chưa được cập nhật sẽ tiếp tục hoạt động bình thường.
Rất dễ giải quyết vấn đề nếu không đạ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 cũng lưu trữ bộ đếm ngày hết hạn (ngày hết hạn có thể được kéo dài bằng cách đốt ETH, điều này có thể tự động xảy ra bất cứ khi nào thực hiện đọ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 quá trình ngày hết hạn. 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 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 Edge 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 trong hợp đồng, về mặt kỹ thuật, điều này giúp cuộc sống của nhà phát triển dễ dàng hơn nhưng lại gây khó khăn hơn về mặt kinh tế: nhà phát triển phải xem xét cách "chuyển" chi phí lưu trữ liên tục cho người dùng.
Đâ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 một phần
· Đề xuất thời hạn sử dụng dựa trên khoảng thời gian địa chỉ.
Hết hạn một phần trạng thái Hết hạn một phần trạng thái
Các đề xuất hết hạn trạng thái một phần đều tuân theo nguyên tắc giống nhau . Chúng tôi chia nhà nước thành nhiều phần. Mọi người đều lưu trữ vĩnh viễn một "bản đồ cấp cao nhất" gồm 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 dữ liệu đó được truy cập gần đây. Có cơ chế "hồi sinh" nếu không còn được lưu trữ
Sự khác biệt chính giữa các đề xuất này là: (i) cách chúng tôi xác định "gần đây" và (ii) ) Chúng ta định nghĩa "khối" 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 mọi dạng trạng thái 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ề nhau sẽ được lưu trữ trong cùng một "thân cây". Lượng dữ liệu tối đa được lưu trữ dưới một thân có thể là 256 * 31 = 7.936 byte. Trong nhiều trường hợp, toàn bộ tiêu đề và mã của tài khoản sẽ được lưu trữ trong cùng một đường trục cũng như nhiều khe lưu trữ chính. Nếu dữ liệu trong một đường trục nhất định không được đọc hoặc ghi trong vòng 6 tháng thì dữ liệu đó sẽ không được lưu trữ nữa mà chỉ lưu trữ cam kết 32 byte ("sơ khai") của dữ liệu đó. Các giao dịch truy cập dữ liệu trong tương lai sẽ cần phải "khôi phục" dữ liệu và cung cấp bằng chứng kiểm tra sơ khai.
Có nhiều cách khác để thực hiện những ý tưởng tương tự. Ví dụ: nếu mức độ chi tiết ở cấp tài khoản là không đủ, chúng tôi có thể phát triển một sơ đồ trong đó mỗi 1/2 32 phần của cây được kiểm soát bằng cơ chế thân và lá tương tự.
Điều này trở nên phức tạp hơn do có động cơ: 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, Điều này buộc khách hàng phải lưu trữ vĩnh viễn một lượng lớn trạng thái. Nếu bạn đặt chi phí gia hạn tỷ lệ thuận với kích thước cây (hoặc tỷ lệ nghịch với thời gian gia hạn), thì ai đó có thể gây tổn hại cho những 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 độ chi tiết động 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ể điều chỉnh 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.
Nêu đề xuất hết hạn dựa trên khoảng thời gian địa chỉ
Nếu chúng ta muốn tránh bất kỳ trạng thái vĩnh viễn nào tại tất cả Phải làm gì nếu sơ khai phát triển, thậm chí lên tới 32 byte? Do xung đột phục hồi, đâ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 và việc thực thi EVM sau đó đặt một đối tượng trạng thái khác vào cùng một vị trí, nhưng sau đó ai đó quan tâm đến đối tượng trạng thái ban đầu quay lại và cố gắng khôi phục nó thì sao? "Sơ khai" ngăn dữ liệu mới được tạo khi một phần trạng thái hết hạn. Với trạng thái hoàn toàn hết hạn, 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à ý tưởng nổi tiếng nhất để giải quyết vấn đề này. Thay vì có một cây trạng thái để lưu trữ toàn bộ trạng thái, chúng 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 kỳ (ví dụ: 1 năm). Những cây cổ thụ đã bị đóng băng hoàn toàn. Các nút đầy đủ chỉ lưu trữ hai cây gần nhất. Nếu một đối tượng trạng thái không được chạm vào trong hai chu kỳ, 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 cần chứng minh bằng chứng Merkle của nó - sau khi được chứng minh, một bản sao sẽ được lưu lại muộn nhất trong cây.
Ý tưởng chính giúp điều này trở nên thân thiện với cả người dùng và nhà phát triển là địa chỉ Cycle ý tưởng. Khoảng thời gian đị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ư ERC 20 mới), nếu bạ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, thì bạn có thể lưu Hãy làm điều đó ngay lập tức mà không đưa ra bằng chứng rằng trước đó không có gì cả. Mặt khác, bất kỳ bổ sung hoặc chỉnh sửa nào được thực hiện tại địa chỉ cũ đều cần có bằng chứng.
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, không yêu cầu tính toán bổ sung và cho phép các ứng dụng được viết gần như như ngày nay (ERC 20 cần phải được viết lại, để đảm bảo rằng số dư địa chỉ có thời hạn địa chỉ là N được lưu trữ trong hợp đồng phụ, bản thân hợp đồng này có thời hạn địa chỉ là N), 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ỉ
Một đề xuất là giới thiệu một định dạng địa chỉ 32 Byte mới, định dạng này bao gồm số phiên bản, số khoảng thời gian địa chỉ và hàm băm mở rộng.
0x01 (đỏ) 0000 (cam) 000001 (xanh lục) 57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF (xanh dương).
Số màu đỏ là số phiên bản. Bốn số 0 màu cam ở đây nhằm mục đích là các khoảng trống có thể chứa 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 nghiêm ngặt, 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 liên quan đến ánh xạ dịch thuật, trong đó 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 hàm băm 20 byte của địa chỉ kiểu mới. Tuy nhiên, có sự phức tạp đáng kể trong việc đảm bảo an ninh của nó.
Thu hẹp không gian địa chỉ
Một cách tiếp cận khác có hướng ngược lại: chúng tôi ngay lập tức cấm khoảng 2 dải địa chỉ con có kích thước 128 (ví dụ: tất cả các địa chỉ bắt đầu bằng 0x ffffffff) và sau đó sử dụng phạm vi đó để giới thiệu một địa chỉ có dấu chấm địa chỉ và hàm băm 14 byte.
0xffffffff000169125 d5dFcb7B8C2659029395bdF
Sự hy sinh chính của phương pháp này là việc đưa ra các địa chỉ phản thực tế Bảo mật rủi ro: Địa chỉ nắm giữ tài sản hoặc quyền nhưng mã chưa được phát hành vào 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ũng có một đoạn mã hợp lệ khác được băm vào cùng một địa chỉ. Việc tính toán một xung đột như vậy ngày nay sẽ cần tớ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 có thể truy cập dễ dàng.
Lĩnh vực rủi ro chính, địa chỉ giả cho ví không do một chủ sở hữu nào nắm giữ, ngày nay tương đối hiếm, nhưng có thể trở nên phổ biến hơn khi chúng ta chuyển sang một nền kinh tế đa quốc gia. Thế giới L2 sẽ 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ả.
Mối liên hệ với nghiên cứu hiện tại là gì?
Đề xuất sớm
Lý thuyết quản lý quy mô trạng thái Ethereum;
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;
Đề xuất hết hạn trạng thái một phần
EIP-7736 ;
Tài liệu mở rộng không gian địa chỉ
Điều gì sẽ xảy ra nếu chúng ta mất khả năng chống va chạm.
Còn cần làm gì nữa và cần cân nhắc những gì?
Tôi nghĩ có bốn con đường khả thi trong tương lai:
· Chúng tôi không có quốc tịch , và không bao giờ giới thiệu trạng thái hết hạn. 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ỷ), mà chỉ bởi một nhóm người dùng tương đối đặc biệt: ngay cả trình xác thực PoS cũng không yêu cầu 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ể 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ì trạng thái cây chứa một phần tài khoản của bạn. Khi họ phát một giao dịch, họ sẽ phát nó kèm theo 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 đó, trình xác nhận không có 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 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ả 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 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 thấp hơn nhiều nhưng vẫn khác 0, trong đó mỗi khách hàng phải lưu trữ tỷ lệ phần trăm dữ liệu lịch sử thấp hơn nhưng cố định.
· Chúng tôi thực hiện việc hết hạn trạng thái thông qua việc 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 thực hiện hết hạn trạng thái thông qua việc 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ả các rủi ro bảo mật liên quan đến xung đột địa chỉ, bao gồm các tình huống xuyên chuỗi, đều được giải quyết.
Điểm quan trọng là dù kế hoạch hết hạn trạng thái dựa trên thay đổi định dạng địa chỉ có được triển khai hay không thì cuối cùng các vấn đề khó khăn xung quanh việc mở rộng và thu hẹp không gian địa chỉ cũng phải được giải quyết. đã giải quyết. Ngày nay, việc tạo ra xung đột địa chỉ cần khoảng 2 80 giá trị băm 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 giá trị băm, do đó chạy trong một năm 2 52, vì vậy tất cả ~ 230 GPU trong thế giới có thể tính toán một vụ va chạm trong khoảng 1/4 năm và FPGA và ASIC có thể đẩy nhanh hơn nữa quá trình này. 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 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 một cây mới sử dụng định dạng mới và sau đó thực hiện hard fork để 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ó có lợi ích là đơ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ì sẽ ít xảy ra lỗi hơn. Nó làm tăng cơ hội cho các nhà phát triển mới có thể tham gia vào bất kỳ phần nào của nó. Nó có nhiều khả năng công bằng hơn và chống lại các lợi ích đặc biệt hơn. 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 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) ngừng thực hiện các thay đổi và củng cố 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. Cũng có thể sử dụng một đường dẫn ở giữa, một đường dẫn ít thay đổi giao thức hơn và 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à hoạt động như thế nào?
Không có cách khắc phục 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 giải pháp nhỏ.
Một ví dụ gần như đã hoàn thiện là việc loại bỏ opcode SELFDESTRUCT và có thể dùng làm bản thiết kế chi tiết về cách tiếp cận các ví dụ khác. 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 khách hàng triển khai độ phức tạp cao hơn đáng kể để tránh các cuộc tấn công DoS. Mục đích ban đầu của opcode này là cho phép thanh lý 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ó. Opcode đã 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 với hard fork Dencun. Điều này giải quyết các vấn đề DoS và đơ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 có thể là điều hợp lý.
Một số ví dụ chính 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. Đầu tiên, một số ví dụ bên ngoài EVM; đây là những ví dụ tương đối không xâm lấn 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, 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, SSZ 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. Các EIP hiện tại bao gồm [ 1 ] [ 2 ] [ 3 ].
· Xóa các loại giao dịch cũ: Ngày 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ể bao gồm 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 các bộ lọc nở hoa và logic khác làm tăng độ phức tạp của giao thức, nhưng thực tế không được khách hàng sử dụng vì nó quá chậm. Chúng tôi có thể loại bỏ các tính năng này và thay vào đó nghiên cứu 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.
· Loại bỏ lần cuối 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 nhẹ trong Ethereum. Tuy nhiên, nó làm tăng đáng kể độ phức tạp của giao thức. Cuối cùng, chúng 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. Có khả năng, 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 bằng cách tạo ra một giao thức máy khách nhẹ “bản địa” hơn bao gồm việc xác thực 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.
· Định dạng dữ liệu thống nhất: 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 blob được cam kết thông qua cam kết KZG. Trong tương lai, sẽ rất hợp lý nếu có 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 yêu cầu quan trọng: (i) bằng chứng đơn giản về các máy khách 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 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. Do đó, ủy ban là không cần thiết và hành động đang được thực hiện để loại bỏ nó.
· Loại bỏ endian hỗn hợp: EVM là endian lớn và lớp đồng thuận là endian nhỏ. Có thể hợp lý hơn nếu điều chỉnh lại và làm mọi thứ theo cách này hay cách khác (có thể là vấn đề lớn vì EVM khó thay đổi hơn)
Bây giờ, một số ví dụ về 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à không thể sử dụng các tài nguyên cần thiết để xác minh số lượng được đưa ra giới hạn rõ ràng. 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 khá tùy ý 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 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à đề xuất định giá bộ nhớ.
· Loại bỏ các trình biên dịch trước: Nhiều trình biên dịch trước mà Ethereum hiện có đều phức tạp không cần thiết, tương đối không được sử dụng và hầu như không được ứng dụng nào sử dụng. sự thất bại. Hai cách để giải quyết vấn đề này là (i) chỉ loại bỏ quá trình biên dịch trước và (ii) thay thế nó bằng một đoạn mã EVM (chắc chắn đắt hơn) thực hiện cùng một logic. Dự thảo EIP khuyến nghị thực hiện việc này để biên dịch trước danh tính như là bước đầu tiên sau này, RIPEMD 160, MODEXP và BLAKE có thể trở thành ứng cử viên để 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 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 hợp đồng 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 cao cấp hơn). Đặc tả EOF đã làm cho Gas không thể quan sát được, nhưng để đơ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 rất khó phân tích tĩnh, đặc biệt vì các bước nhảy có thể là động. Điều này cũng làm cho việc tối ưu hóa việc triển khai EVM (biên dịch trước mã EVM sang các ngôn ngữ khác) trở nên khó khăn hơn. 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 cho tổng số JUMPDEST trong hợp đồng). EOF thực hiện điều đó, mặc dù để đạt được lợi ích đơn giản hóa giao thức từ nó đòi hỏi phải thực thi EOF.
Mối liên hệ với nghiên cứu hiện tại là gì?
· Tự hủy
· EIPS được SSZ hóa: [ 1 ] [ 2 [ 3 ];
· Thay đổi chi phí gas không trạng thái ;
· Một phương pháp 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ể kiểm chứng gia tăng (Đọc: STARK đệ quy);
Còn cần làm gì nữa và cần cân nhắc những gì?
Sự cân bằng 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 xuất phát từ thực tế rằng nó là một 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, lý tưởng này có thể đi quá xa, và theo cách nói của William Jennings Bryan, “đảm bảo Ethereum phải vượt qua 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 nhất định và một ứng dụng không có người dùng trong nhiều năm, trong khi ứng dụng kia gần như hoàn toàn không được sử dụng và đạt được tổng giá trị là 57 USD, thì chúng ta nên loại bỏ chức năng đó và trả cho nạn nhân 57 USD tiền túi nếu cần thiết.
Vấn đề xã hội rộng hơn là tạo ra một quy trình chuẩn hóa để thực hiện các thay đổi phá vỡ khả năng 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à kiểm tra và mở rộng các tiền lệ hiện có, chẳng hạn như các quá trình tự hủy diệt. Quy trình trông như thế này:
1. Bắt đầu nói về việc loại bỏ chức năng X
2. . Tiến hành Phân tích để xác định tác động của việc xóa Tiếp tục;
3. Phát triển EIP chính thức để loại bỏ X. Đảm bảo cơ sở hạ tầng phổ biến cấp cao hơ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. ;
4. Cuối cùng, thực sự xóa X;
Bước 1 và 4 Cần có một lộ trình kéo dài nhiều năm ở giữa, với sự 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 tính năng độ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à dành nhiều tài nguyên hơn cho 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 tập hợp các thay đổi chính được đề xuất đối với EVM là Định dạng đối tượng EVM (EOF ) . EOF giới thiệu một số lượng lớn các 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 nhảy tĩnh. Mục tiêu là cho phép nâng cấp EVM nhiều hơn theo cách 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).
Ưu điểm 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 phương thức cuối cùng một vị trí cho chúng ta cơ hội loại bỏ các ủy ban, thiết kế lại kinh tế học và đưa ra các bằng chứng chứng minh khác đơn giản hóa liên quan đến cổ phần.
· 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ỏ nhiều logic xử lý giao dịch hiện có và chuyển nó sang "mã EVM tài khoản mặc định" mà tất cả EOA có thể thay thế ở giữa.
· 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 chiếu với các 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 được thực hiện cùng một cách.
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
A Hơn nữa Chiến lược đơn giản hóa Ethereum triệt để là giữ cho giao thức không thay đổi nhưng chuyển 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 The more những cái tối thiểu được dành riêng cho các hệ thống chứng minh), cho phép những người khác tạo ra các tập 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 hoàn toàn là kết quả tương tự như việc thực hiện các đề xuất về môi trường vào năm 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 khiêm tốn hơn là giữ lại beacon chain và hoạt động thực thi Ethereum hiện tại môi trường Mối quan hệ giữa chúng vẫn không thay đổi, nhưng EVM được trao đổi 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 để diễn giải logic mã gốc (thông qua biên dịch hoặc thông dịch). 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 của EOF.
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
