Đặc biệt cảm ơn Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden và Tomasz Stanczak đã đóng góp ý kiến và xem xét.

Một trong những thách thức mà Ethereum đang đối mặt là tính phình to và phức tạp của giao thức Khối mặc định tăng lên theo thời gian. Điều này xảy ra ở hai nơi:

· Dữ liệu lịch sử: Bất kỳ giao dịch nào được thực hiện và bất kỳ tài khoản nào được tạo tại bất kỳ thời điểm nào trong lịch sử đều cần được lưu trữ vĩnh viễn bởi tất cả khách hàng và được tải xuống bởi bất kỳ khách hàng mới nào, do đó được đồng bộ hóa hoàn toàn với mạng. Điều này làm cho tải máy khách và thời gian đồng bộ hóa tăng lên theo thời gian, ngay cả khi dung lượng của chuỗi vẫn giữ nguyên.

· chức năng giao thức: Thêm chức năng mới dễ hơn là xóa chức năng cũ, dẫn đến sự phức tạp của mã nguồn tăng theo thời gian.

Để giữ cho Ethereum tồn tại trong thời gian dài, chúng ta cần áp lực phản kháng mạnh mẽ đối với hai xu hướng này, giảm độ phức tạp và sự phình to. Tuy nhiên, đồng thời, chúng ta cần giữ lại một trong những thuộc tính chính làm cho blockchain trở nên tuyệt vời: tính bền vững. Bạn có thể đặt một Token không thể thay thế, một lá thư tình trong dữ liệu giao dịch hoặc một Hợp đồng thông minh chứa 1 triệu đô la trên on-chain, đi vào một hang động trong mười năm, và phát hiện nó vẫn đang đợi bạn đọc và tương tác. Để cho DApp hoàn toàn Phi tập trung và loại bỏ Chìa khoá bảo mật, họ cần đảm bảo rằng các phụ thuộc của họ sẽ không được nâng cấp theo cách làm hỏng họ - đặc biệt là L1.

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

The Purge: Mục tiêu chính.

· Thông qua việc giảm hoặc loại bỏ nhu cầu lưu trữ vĩnh viễn tất cả lịch sử hoặc trạng thái cuối cùng của mỗi Nút, để giảm yêu cầu lưu trữ của khách hàng.

· Thả复杂性giao thức bằng cách loại bỏ các tính năng không cần thiết.

Mục lục bài viết:

· Lịch sử hết hạn

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

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

Lịch sử hết hạn

Giải quyết vấn đề gì?

Hiện tại, một nút Ethereum hoàn toàn đồng bộ cần khoảng 1,1 TB dung lượng đĩa để thực thi khách hàng, và cả rất nhiều GB dung lượng đĩa cho nhận thức chung khách hàng. Đa phần là lịch sử: dữ liệu về Khối, giao dịch và biên nhận trong lịch sử, trong đó phần lớn đã tồn tại trong nhiều năm. Điều này có nghĩa là kích thước của nút sẽ tiếp tục tăng hàng năm khoảng vài trăm GB, ngay cả khi giới hạn Gas không tăng lên.

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

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

Điều này cung cấp nhiều lựa chọn cho chúng ta về cách lưu trữ lịch sử. Một lựa chọn tự nhiên là mạng lưới mỗi Nút chỉ lưu trữ một phần nhỏ dữ liệu. Đây là cách hoạt động của mạng lưới hạt giống trong vài thập kỷ qua: mặc dù mạng lưới lưu trữ và phân phối tổng cộng hàng triệu tệp tin, nhưng mỗi người tham gia chỉ lưu trữ và phân phối một số tệp tin. Có thể ngược lại với trực giác, phương pháp này thậm chí còn không chắc chắn Thả tính ổn định của dữ liệu. Nếu bằng cách làm cho Nút hoạt động hiệu quả hơn, chúng ta có thể xây dựng một mạng lưới với 100.000 Nút, trong đó mỗi Nút lưu trữ 10% lịch sử ngẫu nhiên, vậy mỗi dữ liệu sẽ được sao chép 10.000 lần - giống với hệ số sao chép 10.000 của 10.000 Nút - Mạng lưới Nút, mỗi Nút đều lưu trữ toàn bộ nội dung.

Hiện nay, Ethereum đã bắt đầu thoát khỏi mô hình lưu trữ vĩnh viễn tất cả lịch sử trên tất cả Nút. Phần liên quan đến Nhận thức chungKhối (tức là phần liên quan đến Bằng chứng về cổ phầnNhận thức chung) chỉ lưu trữ khoảng 6 tháng. Blob chỉ lưu trữ khoảng 18 ngày. EIP-4444 nhằm mục đích giới thiệu thời gian lưu trữ lịch sử Khối và biên nhận trong vòng một năm. 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ể khoảng 18 ngày), trong đó mỗi Nút chịu trách nhiệm lưu trữ toàn bộ nội dung, sau đó xây dựng một mạng lưới ngang hàng gồm các Nút Ethereum để lưu trữ dữ liệu cũ theo cách phân phối.

Erasure codes có thể được sử dụng để nâng cao tính bền vững, đồng thời giữ nguyên hệ số sao chép. Trên thực tế, Blob đã được mã hóa để hỗ trợ việc 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 Erasure codes này và đưa cả dữ liệu khối thực hiện vàNhận thức chung vào trong Blob.

Có liên quan đến nghiên cứu hiện có những gì?

· EIP-4444;

· Torrents và EIP-4444 ；

Mạng cổng

· Mạng cổng và EIP-4444 ；

· Lưu trữ và truy xuất phân tán của đối tượng SSZ trong cổng thông tin；

· Làm thế nào để tăng giới hạn gas (Paradigm).

Cần phải làm gì thêm, cần cân nhắc điều gì?

Công việc chính còn lại bao gồm 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à thực hiện lịch sử, nhưng cuối cùng cũng bao gồm Nhận thức chung và blob. Giải pháp đơn giản nhất là (i) đơn giản là giới thiệu thư viện torrent hiện có, cũng như (ii) một giải pháp nguyên sinh cho ETH gọi là Mạng Cổng. Một khi giới thiệu bất kỳ cái nào, chúng ta có thể mở EIP-4444. EIP-4444 chính nó không cần hardfork, nhưng nó thực sự cần phiên bản giao thức mạng mới. Do đó, việc bật nó cho tất cả các khách hàng cũng có giá trị, nếu không, có nguy cơ các khách hàng sẽ gặp sự cố khi kết nối với các Nút khác mong đợi tải xuống toàn bộ lịch sử nhưng thực tế lại không nhận được.

Cân nhắc chính đề cập đến cách chúng tôi nỗ lực cung cấp dữ liệu lịch sử “cổ xưa”. Giải pháp đơn giản nhất là ngừng lưu trữ lịch sử cổ xưa từ ngày mai và phụ thuộc vào các nút lưu trữ hiện tại và các nhà cung cấp trung tâm khác nhau để 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ữ lịch sử vĩnh cửu. Cách tiếp cận 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 bao nhiêu” có hai chiều:

1. Làm thế nào chúng tôi đảm bảo rằng Tập hợp Nút lớn nhất thật sự lưu trữ tất cả dữ liệu?

2. Chúng tôi sẽ tích hợp lịch sử lưu trữ vào Độ sâu của giao thức là bao nhiêu?

Phương pháp cực kỳ cực đoan cho (1) sẽ liên quan đến chứng thực lưu trữ: thực tế yêu cầu mỗi Bằng chứng cổ phần xác minh viên lưu trữ một tỷ lệ lịch sử nhất định và định kỳ kiểm tra xem chúng có làm như vậy theo cách mã hóa. Phương pháp ôn hòa hơn là thiết lập một tiêu chuẩn tự nguyện cho tỷ lệ 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 hôm nay: Cổng đã lưu trữ tệp ERA chứa toàn bộ lịch sử Ethereum. Triển khai toàn diện hơn sẽ liên quan đến việc kết nối nó với quá trình đồng bộ hóa, để những người muốn đồng bộ hóa Nút lưu trữ hoặc Nút lưu trữ lưu trữ đầy đủ lịch sử, ngay cả khi không có Nút lưu trữ lưu trữ trực tuyến khác, họ cũng có thể đạt được điều này bằng cách đồng bộ trực tiếp từ mạng Cổng.

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

Nếu chúng ta muốn việc vận hành hoặc khởi động 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ó thể được coi là quan trọng hơn tính trạng thái: trong số 1,1 TB mà Nút cần, khoảng 300 GB là trạng thái, khoảng 800 GB còn lại đã trở thành lịch sử. Chỉ khi thực hiện tính trạng thái và EIP-4444, thì tầm nhìn có thể chạy Nút Ethereum trên đồng hồ thông minh và chỉ mất vài phút để thiết lập.

Hạn chế lưu trữ lịch sử cũng làm cho các nút Ethereum mới hơn trở nên khả thi hơn, chỉ hỗ trợ phiên bản giao thức mới nhất, điều này làm cho chúng trở nên đơn giản hơn. Ví dụ, hiện nay có thể an toàn xóa nhiều dòng mã vì tất cả các kho lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được xóa hết. Vì việc chuyển sang bằng chứng cổ phần đã trở thành quá khứ, khách hàng có thể an toàn xóa tất cả mã liên quan đến bằng chứng công việc.

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

Giải quyết vấn đề gì?

Dù chúng ta đã loại bỏ nhu cầu lưu trữ lịch sử của khách hàng trên máy khách, nhu cầu lưu trữ trên máy khách vẫn tiếp tục tăng lên, khoảng 50 GB mỗi năm, vì trạng thái tiếp tục tăng lên: 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ể thanh toán một lần để tránh gánh nặng cho khách hàng ETH hiện tại và tương lai.

Tình trạng khó ‘hết hạn’ hơn lịch sử, vì EVM được thiết kế quanh một giả định: một khi đối tượng tình trạng được tạo ra, nó sẽ tồn tại mãi mãi và có thể được đọc bất kỳ lúc nào bởi bất kỳ giao dịch nào. Nếu chúng ta giới thiệu tính vô trạng thái, có người cho rằng vấn đề này có lẽ không tệ như vậy: chỉ có các lớp xây dựngKhối cụ thể cần lưu trữ tình trạng, 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 có trạng thái. Tuy nhiên, có quan điểm cho rằng, chúng ta không muốn phụ thuộc quá nhiều vào tính vô trạng thái, cuối cùng có thể chúng ta muốn tình trạng hết hạn để duy trì tính Phi tập trung của Ethereum.

Nó là gì, 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 thông qua một trong ba cách sau: (i) gửi ETH vào tài khoản mới, (ii) tạo tài khoản mới bằng mã, (iii) thiết lập khe lưu trữ chưa được tiếp xúc trước đó), đối tượng trạng thái đó sẽ luôn ở trong trạng thái đó. Ngược lại, những gì chúng ta muốn là đối tượng sẽ tự động hết hạn theo thời gian. Thách thức chính là cách thức để đạt được ba mục tiêu này:

1. Hiệu suất: Không cần phải tính toán phụ để chạy quá trình đáo hạn.

2. 用户友好性：如果有人进入洞穴五年并回来，他们不应该失去对 ETH、ERC 20、Token không thể thay thế、CDP 头寸的访问权……

3. Thân thiện với nhà phát triển: Nhà phát triển không cần chuyển sang 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 cập nhật nên vẫn có thể hoạt động bình thường.

Nếu bạn không đạt được những mục tiêu này, thật dễ dàng để giải quyết vấn đề. 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 ngày hết hạn (ngày hết hạn có thể được gia hạn bằng cách ghi ETH, có thể xảy ra tự động bất cứ lúc nào đọc hoặc ghi) và có một quá trình lặp qua trạng thái để loại bỏ ngày hết hạn của đối tượng trạng thái. 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 cá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ó có thể 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 đặt hẹn giờ hết hạn trong phạm vi hợp đồng, điều này về mặt kỹ thuật sẽ giúp cuộc sống của nhà phát triển dễ dàng hơn, nhưng nó sẽ khiến nền kinh tế trở nên khó khăn hơn: nhà phát triển sẽ phải suy nghĩ về 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 lõi Ethereum đã nỗ lực giải quyết trong nhiều năm qua, bao gồm các đề xuất như ‘Khối thuê’ và ‘Tái sinh’. Cuối cùng, chúng tôi đã kết hợp những phần tốt nhất trong các đề xuất và tập trung vào hai loại ‘giải pháp tốt nhất đã biết’.

· Phần giải pháp hết hạn

· Gợi ý hết hạn trạng thái dựa trên chu kỳ Địa chỉ.

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

Một số đề xuất hết hạn cho trạng thái tuân theo cùng nguyên tắc. Chúng tôi chia trạng thái thành các khối. Mọi người đều lưu trữ một ‘top-level mapping’ vĩnh viễn, trong đó các khối có thể trống hoặc không trống. Chỉ lưu trữ dữ liệu trong mỗi khối khi dữ liệu này được truy cập gần đây. Có cơ chế ‘tái sinh’ nếu không còn lưu trữ nữa.

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, được xây dựng dựa trên thiết kế “thân và lá” được giới thiệu cho cây Verkle (mặc dù tương thích với bất kỳ dạng trạng thái không quốc tịch nào, chẳng hạn như cây nhị phân). Trong thiết kế này, các tiêu đề, mã và khe cắm liền kề được lưu trữ dưới cùng một “xương sống”. Dữ liệu được lưu trữ dưới thân cây 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 tài khoản, cũng như nhiều khe cắm chính, sẽ được lưu trữ dưới cùng một xương sống. Nếu dữ liệu dưới một xương sống nhất định không được đọc hoặc ghi trong vòng 6 tháng, dữ liệu đó không còn được lưu trữ nữa mà chỉ có cam kết 32 byte (“sơ khai”) của dữ liệu đó được lưu trữ. Các giao dịch trong tương lai truy cập dữ liệu này sẽ cần phải “hồi sinh” dữ liệu và cung cấp bằng chứng rằng nó đã được kiểm tra so với sơ khai.

Vẫn còn cách khác để thực hiện ý tưởng tương tự. Ví dụ, nếu mức độ tài khoản không đủ, chúng ta có thể thiết lập một kế hoạch trong đó mỗi phần 1/2 32 của cây được điều khiển bằng cơ chế tương tự như cành lá.

Vì yếu tố động viên, điều này trở nên phức tạp hơn: kẻ tấn công có thể buộc người dùng lưu trữ một lượng lớn trạng thái mãi mãi bằng cách đặt nhiều dữ liệu vào một cây con duy nhất và gửi giao dịch mỗi năm để “cập nhật cây”. Nếu bạn làm cho 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 người dùng khác bằng cách đặt nhiều dữ liệu vào cùng một cây con với họ. Người ta có thể cố gắng giới hạn hai vấn đề này bằng cách làm cho độ tinh mịch của cây đổi động dựa trên kích thước của cây con: ví dụ, mỗi 2^16 = 65536 đối tượng trạng thái 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; phương pháp dựa trên thân cây thì đơn giản hơn và có thể điều chỉnh biện pháp động viên, vì thông thường tất cả dữ liệu dưới thân cây 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 chu kỳ Địa chỉ

Điều gì sẽ xảy ra nếu chúng ta muốn tránh bất kỳ trạng thái vĩnh viễn nào tăng lên hoàn toàn, ngay cả sơ khai 32 byte? Đây là một câu hỏi hóc búa do xung đột phục sinh: điều gì sẽ xảy ra nếu một đối tượng trạng thái bị xóa và sau đó việc thực thi EVM đặt đối tượng trạng thái khác vào cùng một vị trí, nhưng sau đó người 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ó? Khi một số tiểu bang hết hạn, “sơ khai” ngăn chặn việc tạo dữ liệu mới. Với trạng thái hết hạn hoàn toàn, chúng tôi thậm chí không thể lưu trữ các sơ khai.

Cơ Địa chỉ thiết kế dựa trên chu kỳ là ý tưởng nổi tiếng nhất để giải quyết vấn đề này. Chúng ta không lưu trữ toàn bộ trạng thái trong một cây trạng thái, mà là một danh sách các cây trạng thái tăng lên liên tục và bất kỳ trạng thái nào được đọc hoặc ghi sẽ được lưu trữ trong cây trạng thái mới nhất. Mỗi chu kỳ (ví dụ: 1 năm) thêm một cây trạng thái trống mới. Cây cũ đều bị đóng băng chặt chẽ. Nút đầy đủ chỉ lưu trữ hai cây trạng thái gần đây nhất. Nếu một đối tượng trạng thái không được chạm vào trong hai chu kỳ, nghĩa là rơi vào cây cũ, nó vẫn có thể được đọc hoặc ghi nhưng giao dịch cần chứng minh Merkle - một khi được chứng minh, một bản sao sẽ được lưu trữ lại trong cây mới nhất.

Một trong những ý tưởng chính để làm cho nó thân thiện với người dùng và nhà phát triển là khái niệm chu kỳ địa chỉ. Chu kỳ địa chỉ là một con số thuộc về một phần của địa chỉ. Quy tắc chính là địa chỉ với chu kỳ địa chỉ N chỉ có thể được đọc hoặc viết trong chu kỳ N hoặc sau đó (tức là khi danh sách cây trạng thái đạt đến chiều dài N). Nếu bạn muốn lưu trữ một đối tượng trạng thái mới (ví dụ: một 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ỉ là N hoặc N-1, bạn có thể lưu trữ ngay lập tức mà không cần cung cấp bằng chứng cho thấy trước đó không có gì. Tuy nhiên, bất kỳ thêm vào hoặc chỉnh sửa nào trong chu kỳ địa chỉ cũ đều cần có bằng chứng.

Thiết kế này giữ lại phần lớn các thuộc tính hiện tại của Ethereum mà không cần tính toán bổ sung, cho phép viết ứng dụng gần như như hiện tại (ERC 20 cần được viết lại để đảm bảo số dư Địa chỉ với chu kỳ N được lưu trữ trong hợp đồng con, có chính nó có chu kỳ N), giải quyết vấn đề ‘Người dùng vào hang năm’ Tuy nhiên, nó có một vấn đề lớn: Địa chỉ cần mở rộng hơn 20 byte để phù hợp với chu kỳ Địa chỉ.

Mở rộng không gian địa chỉ Địa chỉ空间 mở rộng

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

0x01（màu đỏ）0000（màu cam）000001（màu xanh lá cây）57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF（màu xanh dương）。

Đỏ là số phiên bản. Bốn chữ số 0 màu cam ở đây được sử dụng làm khoảng trống trống, có thể chứa số phân mảnh trong tương lai. Màu xanh lá cây là số chu kỳ của Địa chỉ. Màu xanh là giá trị băm 26 byte.

Thách thức chính ở đây là tính tương thích ngược. Hợp đồng hiện có được thiết kế xung quanh Địa chỉ 20 byte và thường sử dụng kỹ thuật đóng gói byte nghiêm ngặt, giả định rõ ràng rằng Đị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 bản đồ chuyển đổi, trong đó các hợp đồng cũ tương tác với Địa chỉ mới sẽ nhìn thấy giá trị băm 20 byte của Địa chỉ mới. Tuy nhiên, đảm bảo tính an toàn của nó đang gặp phải sự phức tạp lớn.

Địa chỉ không gian co lại

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

0xffffffff000169125 d5dFcb7B8C2659029395bdF

Phương pháp này đưa ra những sự hy sinh chính là việc giới thiệu một rủi ro an ninh cho Địa chỉ ngược đảo: một Địa chỉ có quyền sở hữu tài sản hoặc quyền hạn, nhưng mã của nó chưa được công bố trên chuỗi. Rủi ro liên quan đến việc ai đó tạo ra một Địa chỉ, Địa chỉ đó tuyên bố sở hữu một đoạn mã (chưa được công bố) nhưng cũng có một đoạn mã hợp lệ khác băm vào cùng một Địa chỉ đó. Việc tính toán va chạm như vậy ngày nay yêu cầu 2^80 hàm băm; việc thu hẹp không gian Địa chỉ sẽ làm giảm con số này xuống còn 2^56 giá trị hàm băm dễ truy cập.

Trong các lĩnh vực rủi ro then chốt, việc sở hữu không đơn nhất của Ví tiền đối sự thật Địa chỉ đang trở nên hiếm gặp hôm nay, nhưng khi chúng ta bước vào thế giới đa L2, có thể trở nên phổ biến hơn. Duy nhất giải pháp là đơn giản chấp nhận rủi ro này, nhưng cần xác định tất cả các trường hợp sử dụng phổ biến có thể gặp vấn đề và đề xuất giải pháp hiệu quả.

Có liên quan đến nghiên cứu hiện có những gì?

Đề xuất ban đầu

Khối gắn kết;

Tái sinh;

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

Một số con đường có thể về trạng thái không và hết hạn;

Một số đề xuất hết hạn trạng thái

EIP-7736 ；

Địa chỉ空间扩展文档

Đề xuất ban đầu;

Bình luận Ipsilon;

Bình luận trên bài đăng trên blog;

Nếu chúng ta mất khả năng chống va đập, điều gì sẽ bị phá hủy.

Cần phải làm gì thêm, cần cân nhắc điều gì?

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

· Chúng tôi đạt được trạng thái không có trạng thái và không bao giờ giới thiệu trạng thái hết hạn. Trạng thái đang tăng lên (mặc dù chậm: chúng ta có thể không nhìn thấy nó vượt qua vài chục TB trong vài thập kỷ), nhưng chỉ cần cho người dùng loại tương đối đặc biệt: thậm chí cả trình xác minh PoS cũng không cần trạng thái.

Một tính năng cần truy cập một phần của trạng thái là bao gồm việc tạo ra danh sách, nhưng chúng ta có thể thực hiện điều này theo cách phân tán: mỗi người dùng chịu trách nhiệm duy trì một phần của cây trạng thái chứa tài khoản của họ. Khi họ gửi giao dịch, họ sẽ phát sóng giao dịch và kèm theo chứng minh của đối tượng trạng thái được truy cập trong quá trình xác minh (điều này áp dụng cho tài khoản EOA và ERC-4337). Sau đó, người xác minh không có trạng thái có thể kết hợp những chứng minh này thành một chứng minh chứa toàn bộ danh sách.

· Chúng tôi tiến hành việc hết hạn một phần trạng thái và chấp nhận tỷ lệ tăng kích thước trạng thái vĩnh viễn thấp hơn nhưng vẫn khác không. Kết quả này có thể được coi là tương tự như làm thế nào để đề xuất hết hạn lịch sử liên quan đến mạng ngang hàng chấp nhận tỷ lệ tăng kích thước bộ nhớ lịch sử vĩnh viễn thấp hơn nhưng vẫn khác không mà mỗi khách hàng phải lưu trữ một tỷ lệ lịch sử dữ liệu thấp hơn nhưng cố định.

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

· Chúng tôi sẽ sử dụng Địa chỉ để thu hẹp không gian trạng thái. Điều này sẽ là quá trình kéo dài nhiều năm để đảm bảo xử lý tất cả các rủi ro an ninh liên quan đến xung đột Địa chỉ (bao gồm cả trường hợp Tương tác chuỗi chéo).

Một điểm quan trọng là, dù có hay không thực hiện kế hoạch hết hạn trạng thái phụ thuộc vào việc thay đổi định dạng Địa chỉ, cuối cùng chúng ta cũng phải giải quyết vấn đề về việc mở rộng và thu hẹp không gian của Địa chỉ. Hiện nay, tạo xung đột Địa chỉ yêu cầu khoảng 2^80 giá trị băm, đối với những người tham gia tài nguyên rất giàu có, khối lượng tính toán này đã trở nên khả thi: GPU có thể thực hiện khoảng 2^27 giá trị băm, do đó trong một năm có thể tính được 2^52, vì vậy tất cả khoảng 230 GPU trên thế giới có thể tính toán một lần xung đột trong khoảng 1/4 năm, trong khi FPGA và ASIC có thể tăng tốc quá trình này. Trong tương lai, loại tấn công này sẽ mở rộng ra cho người dùng nhiều hơn. Do đó, chi phí thực hiện hết hạn trạng thái hoàn toàn có thể không cao như vẻ bề ngoài, vì chúng ta phải giải quyết vấn đề Địa chỉ rất thách thức này bất cứ điều gì xảy ra.

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 quá trình trạng thái hết hạn có thể làm cho việc chuyển đổi từ một định dạng cây trạng thái sang một định dạng cây trạng thái khác trở nên dễ dàng hơn, vì không cần quá trình chuyển đổi: bạn có thể đơn giản bắt đầu sử dụng định dạng mới để tạo cây mới, sau đó thực hiện một phân nhánh cứng để chuyển đổi cây cũ. Do đó, mặc dù trạng thái hết hạn rất phức tạp, nhưng nó thực sự có lợi cho các khía cạnh khác của bản đồ con đường.

Feature cleanup

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

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

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

Không có bất kỳ sửa chữa đột xuất quan trọng nào có thể giảm độ phức tạp của giao thức; bản chất của vấn đề này là có nhiều giải pháp nhỏ.

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

Một số ví dụ quan trọng về cơ hội giao thức được đơn giản hóa đã được xác định cho đến nay bao gồm những điều sau. Đầu tiên, một số ví dụ nằm ngoài EVM; những ví dụ này tương đối không xâm phạm, do đó dễ dàng đạt được Nhận thức chung và triển khai 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 gọi là RLP. RLP không có loại và phức tạp một cách không cần thiết. Ngày nay, beacon chain sử dụng SSZ, nó rõ ràng tốt hơn ở nhiều mặt, bao gồm việc hỗ trợ không chỉ tuần tự hóa mà còn hỗ trợ Hàm băm. Cuối cùng, chúng ta hy vọng 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ẽ làm cho việc nâng cấp trở nên dễ dàng hơn. Các EIP hiện tại bao gồm [1] [2] [3].

· Xóa loại giao dịch cũ: Có quá nhiều loại giao dịch hiện nay, trong đó có nhiều loại có thể sẽ bị xóa bỏ. Một phương án thay thế nhẹ nhàng hơn là chức năng trừu tượng hóa tài khoản, các 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ọ muốn).

· Cải cách LOG: Nhật ký tạo ra các bộ lọc nở hoa và logic khác làm tăng thêm độ phức tạp cho giao thức, nhưng không thực sự đượ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 đó tập trung vào các lựa chọn 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 loại bỏ cơ chế ủy ban đồng bộ hóa chuỗi đèn hiệu: Cơ chế ủy ban đồng bộ hóa ban đầu được giới thiệu để cho phép khách hàng ánh sáng xác minh hình vuông ETH. Tuy nhiên, nó làm tăng đáng kể sự phức tạp của giao thức. Cuối cùng, chúng ta sẽ có thể trực tiếp sử dụng SNARK để xác thực lớp Nhận thức chung của ETH, điều này sẽ loại bỏ sự cần thiết của một khách hàng chuyên dụng ánh sáng để xác thực giao thức. Có khả năng, sự thay đổi trong Nhận thức chung 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 khách hàng “bản địa” hơn ánh sánggiao thức liên quan đến việc xác minh chữ ký từ một tập hợp con ngẫu nhiên của ETH Fang Nhận thức chung.

· Dữ liệu được định dạng thống nhất: Hiện nay, trạng thái thực thi được lưu trữ trong cây Merkle Patricia, trạng thái Nhận thức chung được lưu trữ trong cây SSZ, và blob được cam kết thông qua KZG. Trong tương lai, việc thiết lập định dạng thống nhất duy nhất cho dữ liệu khối và trạng thái là có ý nghĩa. Những định dạng này sẽ đáp ứng tất cả các yêu cầu quan trọng: (i) chứng minh đơn giản cho khách hàng không trạng thái, (ii) tuần tự hóa và mã hóa xóa dữ liệu, (iii) cấu trúc dữ liệu chuẩn hóa.

· Xóa ủy ban beacon chain: Cơ chế này ban đầu được giới thiệu để hỗ trợ việc thực hiện Phân mảnh cụ thể. Thay vào đó, chúng tôi cuối cùng thực hiện Phân mảnh thông qua L2 và blob. Do đó, ủy ban là không cần thiết và việc xóa ủy ban đang được thực hiện.

· Loại bỏ thứ tự byte kết hợp: EVM có thứ tự byte lớn, lớp đồng thuận có thứ tự byte nhỏ. Việc điều phối lại và làm cho tất cả nội dung trở thành một dạng hoặc dạng khác có thể có ý nghĩa (có thể là big-endian vì EVM khó thay đổi hơn)

Hiện tại, một số ví dụ trong EVM:

· Giới hạn Gas đơn giản hóa: Quy tắc Gas hiện tại vẫn chưa được tối ưu hóa tốt, không thể đặt ra giới hạn rõ ràng về số lượng tài nguyên cần thiết để xác minh Khối. Một số ví dụ quan trọng bao gồm (i) chi phí đọc/ghi lưu trữ, nhằm hạn chế số lần đọc/ghi trong một khối, nhưng hiện tại khá tùy ý, và (ii) quy tắc điền bộ nhớ, hiện tại khó để ước lượng lượng bộ nhớ tối đa tiêu thụ của EVM. Các biện pháp khắc phục đề xuất bao gồm thay đổi chi phí Gas không trạng thái (đồ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 giá bộ nhớ.

· Xóa trước biên dịch: Ethereum hiện tại có nhiều trước biên dịch không cần thiết, phức tạp và ít được sử dụng, là một phần lớn gây ra sự thất bại của Nhận thức chung mà gần như không được ứng dụng nào sử dụng. Hai cách để giải quyết vấn đề này là (i) chỉ xóa trước biên dịch và (ii) thay thế chúng bằng một đoạn mã EVM có cùng logic (tự nhiên sẽ tốn kém hơn). Bản thảo EIP đề xuất thực hiện bước đầu tiên này cho trước biên dịch về danh tính; sau đó, RIPEMD 160, MODEXP và BLAKE có thể trở thành những ứng cử viên để xóa bỏ.

· Loại bỏ khả năng quan sát gas: làm cho quá trình thực thi EVM không còn thể nhìn thấy số gas còn lại. Điều này sẽ gây hư hỏng cho một số ứng dụng (đặc biệt là giao dịch tài trợ), nhưng trong tương lai sẽ dễ dàng nâng cấp hơn (ví dụ như phiên bản cao cấp hơn về gas đa chiều). EOF đã làm cho Gas trở thành không thể quan sát được, nhưng để đơn giản hóa giao thức, EOF cần trở thành bắt buộc.

· Cải tiến phân tích tĩnh: Hiện nay, việc phân tích tĩnh mã EVM khó khăn, đặc biệt là vì nhảy có thể là động. Điều này cũng làm cho việc tối ưu hóa việc thực hiện EVM (biên dịch mã EVM thành ngôn ngữ khác trước) trở nên khó khăn hơn. Chúng ta có thể giải quyết vấn đề này bằng cách loại bỏ nhảy động (hoặc làm cho chúng trở nên tốn kém hơn, ví dụ như chi phí Gas tuyến tính của tổng số JUMPDEST trong hợp đồng). EOF làm được điều này, mặc dù việc áp dụng bắt buộc EOF để thu được lợi ích của việc đơn giản hóa giao thức.

Có liên quan đến nghiên cứu hiện có những gì?

· Các bước tiếp theo sau khi xóa;

Tự hủy

· SSZ hóa EIPS: [1] [2] [3];

· Không trạng thái gas chi phí thay đổi;

· Giá định giá bộ nhớ tuyến tính;

· Loại bỏ trước khi biên dịch;

· Loại bỏ bộ lọc bloom;

· Phương pháp sử dụng tính toán có thể xác minh tăng dần để truy xuất nhật ký an toàn off-chain (đọc: STARK đệ quy);

Cần phải làm gì thêm, cần cân nhắc điều gì?

Việc cân nhắc chính khi tiến hành việc đơn giản hóa chức năng này là (i) mức độ và tốc độ của việc đơn giản hóa của chúng ta so với (ii) tính tương thích ngược. Giá trị của mạng Ethereum đến từ việc nó là một nền tảng mà bạn có thể triển khai ứng dụng và có thể tin rằng nó sẽ vẫn hoạt động sau nhiều năm. Tuy nhiên, ý tưởng này cũng có thể đi quá xa, để dùng lời của William Jennings Bryan, “đóng Ethereum vào thập tự tính của tính tương thích ngược”. Nếu chỉ có hai ứng dụng trong toàn bộ Ethereum sử dụng tính năng cụ thể và một ứng dụng không có người dùng trong nhiều năm, trong khi ứng dụng còn lại gần như không sử dụng và chỉ có tổng giá trị 57 đô la, chúng ta nên xóa tính năng đó và nếu cần phải chi trả 57 đô la cho người bị hại.

Vấn đề xã hội phổ biến hơn là tạo ra một đường ống tiêu chuẩn để thực hiện những thay đổi không tương thích với phiên bản trước đó trong trường hợp không cấp bách. Một phương pháp để giải quyết vấn đề này là kiểm tra và mở rộng các tiền例 hiện có, ví dụ như quá trình tự hủy. Đường ống nhìn như sau:

1. Bắt đầu thảo luận về chức năng X xóa;

2. Tiến hành phân tích để xác định tác động của việc loại bỏ X đối với ứng dụng, tùy thuộc vào kết quả: (i) từ bỏ ý tưởng, (ii) tiếp tục theo kế hoạch, hoặc (iii) xác định cách sửa đổi “ít gây gián đoạn nhất” để loại bỏ X và tiếp tục;

3. Đặt ra EIP chính thức để loại bỏ X. Đảm bảo cơ sở hạ tầng cấp cao phổ biến (ví tiền, ngôn ngữ lập trình, 01928374656574839201) tôn trọng điều này và ngừng sử dụng tính năng đó.

4. Cuối cùng, thực hiện xóa X;

Giữa Bước 1 và Bước 4, cần có một đường ống kéo dài suốt nhiều năm và rõ ràng xác định các dự án nằm ở bước nào. Ở điểm này, cần cân nhắc giữa sự nhanh chóng và linh hoạt của quy trình loại bỏ tính năng và việc cẩn trọng hơn cùng việc đầu tư nhiều tài nguyên hơn vào các lĩnh vực khác của việc phát triển giao thức, nhưng chúng ta vẫn cách xa ranh giới Pareto.

Kết thúc tập tin

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

Ưu điểm của việc làm này là nó tạo ra một con đường tự nhiên để thêm các tính năng EVM mới và khuyến khích di chuyển sang EVM nghiêm ngặt hơn với đảm bảo mạnh hơn. Nhược điểm của nó là nó tăng đáng kể tính phức tạp của giao thức, trừ khi chúng ta có thể tìm ra cách loại bỏ và xóa bỏ EVM cũ cuối cùng. Vấn đề chính là: EOF có vai trò gì trong đề xuất đơn giản hóa EVM, đặc biệt nếu mục tiêu là Thả sạch sẽ tính phức tạp của toàn bộ EVM?

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

Nhiều gợi ý “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:

· Chuyển sang tính cuối cùng của một khe cắm cho chúng tôi cơ hội hủy bỏ ủy ban, thiết kế lại nền kinh tế và thực hiện việc đơn giản hóa khác liên quan đến chứng chỉ quyền cổ phần.

· Việc triển khai hoàn toàn trừu tượng hóa tài khoản sẽ cho phép chúng ta loại bỏ một lượng lớn các logic xử lý giao dịch hiện có và chuyển chúng vào “mã EVM mặc định của các tài khoản EOA có thể thay thế”.

· 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ể phù hợp 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 xử lý cây băm theo cùng một cách.

Phương pháp táo bạo hơn: Chuyển đổi phần lớn nội dung của giao thức thành mã hợp đồng

Một chiến lược đơn giản hóa ETH táo bạo hơn là giữ nguyên giao thức, nhưng chuyển hầu hết chức năng của nó từ giao thức sang mã hợp đồng.

Phiên bản cực đoan nhất là để ETH L1 chỉ là beacon chain “về mặt kỹ thuật”, và giới thiệu một Máy ảo tối thiểu (ví dụ như RISC-V, Cairo hoặc một hệ thống chứng minh tối thiểu hơn) cho phép người khác tạo ra tổng hợp của riêng họ. Sau đó, EVM sẽ trở thành tổng hợp đầu tiên trong số này. Một điều trớ trêu là điều này hoàn toàn giống với kết quả của đề xuất môi trường thực thi trong giai đoạn 2019-20, mặc dù SNARK đã làm cho việc thực hiện nó trở nên khả thi hơn thực tế.

Một cách tiếp cận nhẹ nhàng 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 hội thảo ETH hiện tại, nhưng hoán đổi EVM tại chỗ. Chúng ta có thể chọn RISC-V, Cairo hoặc các máy ảo khác làm “máy ảo ETH Square chính thức” mới và sau đó buộc tất cả các hợp đồng EVM sang mã VM mới diễn giải logic mã gốc (được biên dịch hoặc thông dịch). Về mặt lý thuyết, điều này thậm chí có thể được thực hiện với “Target Machine ảo” như một phiên bản của EAF.

liên kết gốc