Một trong những thách thức mà Ethereum phải đối mặt là, theo mặc định, sự phình to 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 khía cạnh: dữ liệu lịch sử và chức năng của giao thức. Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng áp lực phản đối mạnh mẽ cho cả hai xu hướng này, giảm độ phức tạp và phình to theo thời gian. Nhưng đồ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 vĩ đại: tính bền vững.
Mục tiêu chính của The Purge là:
Giảm yêu cầu lưu trữ của khách hàng 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ả các lịch sử hoặc thậm chí 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.
Lịch sử hết hạn
Giải quyết vấn đề gì?
Tính đến thời điểm viết bài này, một nút Ethereum hoàn toàn đồng bộ cần khoảng 1,1 TB dung lượng ổ đĩa để thực hiện khách hàng, ngoài ra còn cần hàng trăm GB dung lượng ổ đĩa cho khách hàng đồng thuận. Phần lớn trong số đó là lịch sử: dữ liệu về các khối lịch sử, giao dịch và biên lai, trong đó phần lớn đã có từ nhiều năm trước. Điều này có nghĩa là ngay cả khi giới hạn Gas không tăng lên, kích thước của các nút cũng sẽ tiếp tục tăng hàng trăm GB mỗi năm.
Nó là gì, nó 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à, vì mỗi khối được liên kết bằng băm ( và các cấu trúc khác ) chỉ tới khối trước đó, nên việc đạt được sự đồng thuận hiện tại là đủ để đạt được sự đồng thuận lịch sử. Chỉ cần mạng lưới đạt được sự đồng thuận về khối mới nhất, bất kỳ khối lịch sử, 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ỳ người tham gia đơn lẻ 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ó. 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 cung cấp cho chúng ta nhiều lựa chọn về cách lưu trữ lịch sử. Một lựa chọn tự nhiên là một mạng lưới mà mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu. Đây là cách mà mạng hạt giống hoạt động trong nhiều thập kỷ: mặc dù mạng lưu trữ và phân phối 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ó thể trái ngược với trực giác, phương pháp này thậm chí không nhất thiết làm giảm độ bền của dữ liệu. Nếu 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ử một cách ngẫu nhiên, thì mỗi dữ liệu sẽ được sao chép 10,000 lần - giống hệt như hệ số sao chép của mạng lưới 10,000 nút, trong đó mỗi nút đều lưu trữ tất cả nội dung.
Hiện nay, Ethereum đã bắt đầu thoát khỏi mô hình mà tất cả các nút lưu trữ vĩnh viễn tất cả lịch sử. Khối đồng thuận ( liên quan đến phần đồng thuận bằng chứng cổ phần 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ữ một năm cho các khối lịch sử và biên lai. Mục tiêu dài hạn là xây dựng 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ữ tất cả nội dung, sau đó xây dựng một mạng điểm-điểm được tạo thành từ các nút Ethereum, lưu trữ dữ liệu cũ theo cách phân tán.
Mã xóa có thể được sử dụng để tăng cường tính mạnh mẽ, đồng thời giữ nguyên hệ số sao chép. Trên thực tế, Blob đã thực hiện mã xóa để hỗ trợ mẫu khả dụng của dữ liệu. Giải pháp đơn giản nhất có thể là tái sử dụng mã xóa này và cũng đưa dữ liệu thực thi và khối đồng thuận vào blob.
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òn bao gồm sự đồng thuận 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( được gọi là giải pháp gốc Ethereum Portal. Một khi bất kỳ cái nào trong số đó được giới thiệu, chúng ta có thể mở EIP-4444. EIP-4444 bản thân nó không yêu cầu một hard fork, nhưng nó thực sự cần một phiên bản giao thức mạng mới. Do đó, việc kích hoạt nó cho tất cả các khách hàng cùng một lúc là có giá trị, nếu không sẽ có nguy cơ khách hàng gặp sự cố do kết nối với các nút khác mong đợi tải xuống lịch sử đầy đủ nhưng thực tế không nhận được.
Sự đánh đổi chính liên quan đến cách chúng tôi nỗ lực cung cấp dữ liệu lịch sử "cổ đại". 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à phụ thuộc vào các nút lưu trữ hiện có và các nhà cung cấp tập trung khác để sao chép. Điều này rất dễ dàng, nhưng nó làm suy yếu vị thế của Ethereum như một nơi lưu giữ hồ sơ vĩnh viễn. 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 nỗ lực như thế nào" có hai chiều:
Chúng tôi nỗ lực như thế 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?
Độ sâu của việc tích hợp lưu trữ lịch sử vào trong giao thức là bao nhiêu?
Một phương pháp cực kỳ bảo thủ cho ) sẽ liên quan đến việc chứng minh quyền sở hữu: thực tế yêu cầu mỗi trình xác thực quyền sở hữu lưu trữ một tỷ lệ nhất định của lịch sử và thường xuyên kiểm tra mã hóa xem họ có làm như vậy hay không. Một phương pháp nhẹ nhàng hơn là thiết lập một tiêu chuẩn tự nguyện cho tỷ lệ phần trăm lịch sử được lưu trữ bởi mỗi khách hàng.
Đối với (2), việc thực hiện cơ bản chỉ liên quan đến công việc đã hoàn thành hôm nay: Portal đã lưu trữ các tệp ERA chứa toàn bộ lịch sử Ethereum. Việc thực hiện triệt để hơn sẽ liên quan đến việc kết nối thực tế với quá trình đồng bộ hóa, như vậy, 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ữ, ngay cả khi không có nút lưu trữ nào khác trực tuyến, họ cũng có thể thực hiện điều đó thông qua việc đồ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?
Nếu chúng ta muốn việc chạy hoặc khởi động nút trở nên cực kỳ dễ dàng, thì việc giảm nhu cầu lưu trữ lịch sử có thể nói là quan trọng hơn tính không trạng thái: trong 1.1 TB mà nút cần, khoảng 300 GB là trạng thái, còn lại khoảng 800 GB đã trở thành lịch sử. Chỉ có thể đạt được tầm nhìn về việc chạy nút Ethereum trên đồng hồ thông minh và chỉ cần vài phút để thiết lập khi thực hiện tính không trạng thái và EIP-4444.
Việc hạn chế lưu trữ lịch sử cũng khiến cho các node Ethereum mới hơn trở nên khả thi hơn, chỉ hỗ trợ phiên bản mới nhất của giao thức, điều này làm cho chúng trở nên đơn giản hơn. Ví dụ, giờ đây có thể xóa an toàn nhiều dòng mã, vì tất cả các khe lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được xóa. Bây giờ khi việc chuyển sang cơ chế chứng minh cổ phần đã trở thành lịch sử, khách hàng có thể xóa an toàn tất cả các mã liên quan đến chứng minh công việc.
Ngay cả khi chúng ta loại bỏ nhu cầu lưu trữ lịch sử của client, nhu cầu lưu trữ của client vẫn sẽ tiếp tục tăng, khoảng 50 GB mỗi năm, vì trạng thái tiếp tục phát triể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ể trả một khoản phí một lần, từ đó mang lại gánh nặng cho các khách hàng Ethereum hiện tại và trong tương lai.
Trạng thái khó "hết hạn" hơn lịch sử, vì EVM đượ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 ra, nó sẽ luôn tồn tại và có thể được bất kỳ giao dịch nào đọc bất cứ lúc nào. Nếu chúng ta giới thiệu tính không trạng thái, một số người cho rằng vấn đề này có thể không tệ đến vậy: chỉ có các lớp xây dựng khối chuyên dụng cần thực sự lưu trữ trạng thái, trong khi tất cả các nút khác ) thậm chí bao gồm danh sách sinh! ### có thể hoạt động không trạng thái. Tuy nhiên, có một quan điểm cho rằng, chúng ta không muốn quá phụ thuộc vào tính không trạng thái, cuối cùng chúng ta có thể muốn làm cho trạng thái hết hạn để duy trì sự 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 theo một trong ba cách sau: ###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 ) 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 này sẽ mãi mãi ở trạng thái đó. Ngược lại, điều chúng ta muốn là đối tượng tự động hết hạn theo thời gian. Thách thức chính là làm điều này theo cách đạt được ba mục tiêu:
Hiệu suất: Không cần tính toán bổ sung nhiều để thực hiện quy trình đáo hạn.
Tính thân thiện với người dùng: Nếu ai đó vào hang động năm năm và trở về, họ không nên mất quyền truy cập vào các vị thế ETH, ERC20, NFT, CDP...
Tính thân thiện với nhà phát triển: Các nhà phát triển không 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 cập nhật nên có thể tiếp tục hoạt động bình thường.
Không đạt được những mục tiêu này thì rất dễ để giải quyết vấn đề. Ví dụ, bạn có thể khiến mỗi đối tượng trạng thái cũng lưu trữ một bộ đếm ngày hết hạn ) có thể được gia hạn ngày hết hạn bằng cách đốt ETH, điều này có thể xảy ra tự động bất cứ lúc nào khi đọ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 có ngày hết hạn. Tuy nhiên, điều này đã đưa ra yêu cầu tính toán ( bổ sung ngay cả nhu cầu lưu trữ ), và chắc chắn không thể đáp ứng 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 gặp khó khăn trong việc suy luận các trường hợp biên liên quan đến việc lưu trữ các giá trị đôi khi được thiết lập lại về không. Nếu bạn đặt bộ đếm thời gian hết hạn trong phạm vi hợp đồng, điều này về mặt kỹ thuật sẽ làm cho cuộc sống của các nhà phát triển dễ dàng hơn, nhưng nó sẽ làm cho kinh tế trở nên khó khăn hơn: các nhà phát triển phải xem xét cách "chuyển giao" chi phí lưu trữ liên tục cho người dùng.
Những điều này đều là những vấn đề mà cộng đồng phát triển cốt lõi của Ethereum đã nỗ lực giải quyết trong nhiều năm qua, bao gồm các đề xuất như "thuê blockchain" 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 đã biết là không tệ nhất":
Giải pháp trạng thái hết hạn một phần
Đề xuất hết hạn trạng thái dựa trên chu kỳ địa chỉ.
(# Partial state expiry phần trạng thái đến hạn
Một số đề xuất trạng thái hết hạn đều tuân theo các nguyên tắc giống nhau. Chúng tôi phân chia trạng thái thành các khối. Mọi người đều lưu trữ vĩnh viễn "bản đồ hàng đầu", trong đó khối có thể trống hoặc không trống. Dữ liệu trong mỗi khối chỉ được lưu trữ khi dữ liệu đó được truy cập gần đây. Có một 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### chúng ta định nghĩa "gần đây" như thế nào, và(ii) chúng ta định nghĩa "khối" như thế nào? Một đề xuất cụ thể là EIP-7736, nó được xây dựng dựa trên thiết kế "cành lá" đượ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 trạng thái không có trạng thái nào, chẳng hạn như cây nhị phân). Trong thiết kế này, các tiêu đề, mã và khe lưu trữ kề nhau được lưu trữ dưới cùng một "thân cây". Dữ liệu được lưu trữ dưới một cành có tối đa 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 cũng như nhiều khe lưu trữ khóa sẽ được lưu trữ dưới cùng một thân cây. Nếu dữ liệu dưới thân cây đã cho không được đọc hoặc ghi trong vòng 6 tháng, thì dữ liệu đó sẽ không còn được lưu trữ nữa, mà chỉ lưu trữ cam kết 32 byte của dữ liệu đó( "gốc"). Giao dịch truy cập dữ liệu trong tương lai sẽ cần "hồi sinh" dữ liệu và cung cấp chứng minh để kiểm tra theo gốc.
Còn có những phương pháp khác để thực hiện ý tưởng tương tự. Ví dụ, nếu độ chi tiết ở cấp độ 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/232 của cây được kiểm soát bởi một cơ chế thân lá tương tự.
Do các yếu tố khuyến khích, điều này trở nên phức tạp hơn: kẻ tấn công có thể "cập nhật cây" bằng cách đưa một lượng lớn dữ liệu vào một cây con và gửi một giao dịch mỗi năm, từ đó buộc khách hàng phải lưu trữ một lượng lớn trạng thái vĩnh viễn. Nếu bạn làm cho chi phí gia hạn tỷ lệ 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ể làm hại người dùng khác bằng cách đưa một lượng lớn dữ liệu vào cùng một cây con với họ. Mọi người có thể cố gắng hạn chế hai vấn đề này bằng cách làm cho độ tinh vi động theo kích thước cây con: ví dụ, mỗi 216= 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 cuống thì đơn giản và có thể điều chỉnh các yếu tố khuyến khích, vì thường thì dưới cuống.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
6 thích
Phần thưởng
6
6
Đăng lại
Chia sẻ
Bình luận
0/400
AirdropHunterXiao
· 3giờ trước
Cũng thật sự có chút mong đợi việc dọn dẹp dữ liệu rác.
Xem bản gốcTrả lời0
pumpamentalist
· 3giờ trước
Ether lại làm việc mới rồi
Xem bản gốcTrả lời0
MevHunter
· 3giờ trước
Anh em ơi, purge khi nào thì lên sóng? Nhìn phí lại cao rồi.
Xem bản gốcTrả lời0
MysteriousZhang
· 3giờ trước
Dọn dẹp một chút cũng tốt, dữ liệu lịch sử này quá cồng kềnh.
Xem bản gốcTrả lời0
EntryPositionAnalyst
· 3giờ trước
BTC còn chưa đủ lớn nhỉ~ Tiếp tục mã hóa mã
Xem bản gốcTrả lời0
TideReceder
· 4giờ trước
Sự mở rộng chính là sự thu hẹp lớn nhất, bạn hiểu không?
Ethereum tương lai bản đồ: The Purge nhằm mục đích đơn giản hóa giao thức Thả sự phình to.
Tương lai có thể của Ethereum: The Purge
Một trong những thách thức mà Ethereum phải đối mặt là, theo mặc định, sự phình to 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 khía cạnh: dữ liệu lịch sử và chức năng của giao thức. Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng áp lực phản đối mạnh mẽ cho cả hai xu hướng này, giảm độ phức tạp và phình to theo thời gian. Nhưng đồ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 vĩ đại: tính bền vững.
Mục tiêu chính của The Purge là:
Lịch sử hết hạn
Giải quyết vấn đề gì?
Tính đến thời điểm viết bài này, một nút Ethereum hoàn toàn đồng bộ cần khoảng 1,1 TB dung lượng ổ đĩa để thực hiện khách hàng, ngoài ra còn cần hàng trăm GB dung lượng ổ đĩa cho khách hàng đồng thuận. Phần lớn trong số đó là lịch sử: dữ liệu về các khối lịch sử, giao dịch và biên lai, trong đó phần lớn đã có từ nhiều năm trước. Điều này có nghĩa là ngay cả khi giới hạn Gas không tăng lên, kích thước của các nút cũng sẽ tiếp tục tăng hàng trăm GB mỗi năm.
Nó là gì, nó 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à, vì mỗi khối được liên kết bằng băm ( và các cấu trúc khác ) chỉ tới khối trước đó, nên việc đạt được sự đồng thuận hiện tại là đủ để đạt được sự đồng thuận lịch sử. Chỉ cần mạng lưới đạt được sự đồng thuận về khối mới nhất, bất kỳ khối lịch sử, 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ỳ người tham gia đơn lẻ 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ó. 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 cung cấp cho chúng ta nhiều lựa chọn về cách lưu trữ lịch sử. Một lựa chọn tự nhiên là một mạng lưới mà mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu. Đây là cách mà mạng hạt giống hoạt động trong nhiều thập kỷ: mặc dù mạng lưu trữ và phân phối 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ó thể trái ngược với trực giác, phương pháp này thậm chí không nhất thiết làm giảm độ bền của dữ liệu. Nếu 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ử một cách ngẫu nhiên, thì mỗi dữ liệu sẽ được sao chép 10,000 lần - giống hệt như hệ số sao chép của mạng lưới 10,000 nút, trong đó mỗi nút đều lưu trữ tất cả nội dung.
Hiện nay, Ethereum đã bắt đầu thoát khỏi mô hình mà tất cả các nút lưu trữ vĩnh viễn tất cả lịch sử. Khối đồng thuận ( liên quan đến phần đồng thuận bằng chứng cổ phần 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ữ một năm cho các khối lịch sử và biên lai. Mục tiêu dài hạn là xây dựng 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ữ tất cả nội dung, sau đó xây dựng một mạng điểm-điểm được tạo thành từ các nút Ethereum, lưu trữ dữ liệu cũ theo cách phân tán.
Mã xóa có thể được sử dụng để tăng cường tính mạnh mẽ, đồng thời giữ nguyên hệ số sao chép. Trên thực tế, Blob đã thực hiện mã xóa để hỗ trợ mẫu khả dụng của dữ liệu. Giải pháp đơn giản nhất có thể là tái sử dụng mã xóa này và cũng đưa dữ liệu thực thi và khối đồng thuận vào blob.
![Vitalik：Ethereum的可能未来，The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
) còn cần phải làm gì, cần phải cân nhắc điều 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òn bao gồm sự đồng thuận 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( được gọi là giải pháp gốc Ethereum Portal. Một khi bất kỳ cái nào trong số đó được giới thiệu, chúng ta có thể mở EIP-4444. EIP-4444 bản thân nó không yêu cầu một hard fork, nhưng nó thực sự cần một phiên bản giao thức mạng mới. Do đó, việc kích hoạt nó cho tất cả các khách hàng cùng một lúc là có giá trị, nếu không sẽ có nguy cơ khách hàng gặp sự cố do kết nối với các nút khác mong đợi tải xuống lịch sử đầy đủ nhưng thực tế không nhận được.
Sự đánh đổi chính liên quan đến cách chúng tôi nỗ lực cung cấp dữ liệu lịch sử "cổ đại". 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à phụ thuộc vào các nút lưu trữ hiện có và các nhà cung cấp tập trung khác để sao chép. Điều này rất dễ dàng, nhưng nó làm suy yếu vị thế của Ethereum như một nơi lưu giữ hồ sơ vĩnh viễn. 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 nỗ lực như thế nào" có hai chiều:
Một phương pháp cực kỳ bảo thủ cho ) sẽ liên quan đến việc chứng minh quyền sở hữu: thực tế yêu cầu mỗi trình xác thực quyền sở hữu lưu trữ một tỷ lệ nhất định của lịch sử và thường xuyên kiểm tra mã hóa xem họ có làm như vậy hay không. Một phương pháp nhẹ nhàng hơn là thiết lập một tiêu chuẩn tự nguyện cho tỷ lệ phần trăm lịch sử được lưu trữ bởi mỗi khách hàng.
Đối với (2), việc thực hiện cơ bản chỉ liên quan đến công việc đã hoàn thành hôm nay: Portal đã lưu trữ các tệp ERA chứa toàn bộ lịch sử Ethereum. Việc thực hiện triệt để hơn sẽ liên quan đến việc kết nối thực tế với quá trình đồng bộ hóa, như vậy, 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ữ, ngay cả khi không có nút lưu trữ nào khác trực tuyến, họ cũng có thể thực hiện điều đó thông qua việc đồ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?
Nếu chúng ta muốn việc chạy hoặc khởi động nút trở nên cực kỳ dễ dàng, thì việc giảm nhu cầu lưu trữ lịch sử có thể nói là quan trọng hơn tính không trạng thái: trong 1.1 TB mà nút cần, khoảng 300 GB là trạng thái, còn lại khoảng 800 GB đã trở thành lịch sử. Chỉ có thể đạt được tầm nhìn về việc chạy nút Ethereum trên đồng hồ thông minh và chỉ cần vài phút để thiết lập khi thực hiện tính không trạng thái và EIP-4444.
Việc hạn chế lưu trữ lịch sử cũng khiến cho các node Ethereum mới hơn trở nên khả thi hơn, chỉ hỗ trợ phiên bản mới nhất của giao thức, điều này làm cho chúng trở nên đơn giản hơn. Ví dụ, giờ đây có thể xóa an toàn nhiều dòng mã, vì tất cả các khe lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được xóa. Bây giờ khi việc chuyển sang cơ chế chứng minh cổ phần đã trở thành lịch sử, khách hàng có thể xóa an toàn tất cả các mã liên quan đến chứng minh công việc.
![Vitalik：Ethereum的可能未来，The Purge])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###
Hết hạn trạng thái
( Giải quyết vấn đề gì?
Ngay cả khi chúng ta loại bỏ nhu cầu lưu trữ lịch sử của client, nhu cầu lưu trữ của client vẫn sẽ tiếp tục tăng, khoảng 50 GB mỗi năm, vì trạng thái tiếp tục phát triể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ể trả một khoản phí một lần, từ đó mang lại gánh nặng cho các khách hàng Ethereum hiện tại và trong tương lai.
Trạng thái khó "hết hạn" hơn lịch sử, vì EVM đượ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 ra, nó sẽ luôn tồn tại và có thể được bất kỳ giao dịch nào đọc bất cứ lúc nào. Nếu chúng ta giới thiệu tính không trạng thái, một số người cho rằng vấn đề này có thể không tệ đến vậy: chỉ có các lớp xây dựng khối chuyên dụng cần thực sự lưu trữ trạng thái, trong khi tất cả các nút khác ) thậm chí bao gồm danh sách sinh! ### có thể hoạt động không trạng thái. Tuy nhiên, có một quan điểm cho rằng, chúng ta không muốn quá phụ thuộc vào tính không trạng thái, cuối cùng chúng ta có thể muốn làm cho trạng thái hết hạn để duy trì sự 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 theo một trong ba cách sau: ###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 ) 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 này sẽ mãi mãi ở trạng thái đó. Ngược lại, điều chúng ta muốn là đối tượng tự động hết hạn theo thời gian. Thách thức chính là làm điều này theo cách đạt được ba mục tiêu:
Không đạt được những mục tiêu này thì rất dễ để giải quyết vấn đề. Ví dụ, bạn có thể khiến mỗi đối tượng trạng thái cũng lưu trữ một bộ đếm ngày hết hạn ) có thể được gia hạn ngày hết hạn bằng cách đốt ETH, điều này có thể xảy ra tự động bất cứ lúc nào khi đọ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 có ngày hết hạn. Tuy nhiên, điều này đã đưa ra yêu cầu tính toán ( bổ sung ngay cả nhu cầu lưu trữ ), và chắc chắn không thể đáp ứng 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 gặp khó khăn trong việc suy luận các trường hợp biên liên quan đến việc lưu trữ các giá trị đôi khi được thiết lập lại về không. Nếu bạn đặt bộ đếm thời gian hết hạn trong phạm vi hợp đồng, điều này về mặt kỹ thuật sẽ làm cho cuộc sống của các nhà phát triển dễ dàng hơn, nhưng nó sẽ làm cho kinh tế trở nên khó khăn hơn: các nhà phát triển phải xem xét cách "chuyển giao" chi phí lưu trữ liên tục cho người dùng.
Những điều này đều là những vấn đề mà cộng đồng phát triển cốt lõi của Ethereum đã nỗ lực giải quyết trong nhiều năm qua, bao gồm các đề xuất như "thuê blockchain" 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 đã biết là không tệ nhất":
(# Partial state expiry phần trạng thái đến hạn
Một số đề xuất trạng thái hết hạn đều tuân theo các nguyên tắc giống nhau. Chúng tôi phân chia trạng thái thành các khối. Mọi người đều lưu trữ vĩnh viễn "bản đồ hàng đầu", trong đó khối có thể trống hoặc không trống. Dữ liệu trong mỗi khối chỉ được lưu trữ khi dữ liệu đó được truy cập gần đây. Có một 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### chúng ta định nghĩa "gần đây" như thế nào, và(ii) chúng ta định nghĩa "khối" như thế nào? Một đề xuất cụ thể là EIP-7736, nó được xây dựng dựa trên thiết kế "cành lá" đượ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 trạng thái không có trạng thái nào, chẳng hạn như cây nhị phân). Trong thiết kế này, các tiêu đề, mã và khe lưu trữ kề nhau được lưu trữ dưới cùng một "thân cây". Dữ liệu được lưu trữ dưới một cành có tối đa 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 cũng như nhiều khe lưu trữ khóa sẽ được lưu trữ dưới cùng một thân cây. Nếu dữ liệu dưới thân cây đã cho không được đọc hoặc ghi trong vòng 6 tháng, thì dữ liệu đó sẽ không còn được lưu trữ nữa, mà chỉ lưu trữ cam kết 32 byte của dữ liệu đó( "gốc"). Giao dịch truy cập dữ liệu trong tương lai sẽ cần "hồi sinh" dữ liệu và cung cấp chứng minh để kiểm tra theo gốc.
Còn có những phương pháp khác để thực hiện ý tưởng tương tự. Ví dụ, nếu độ chi tiết ở cấp độ 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/232 của cây được kiểm soát bởi một cơ chế thân lá tương tự.
Do các yếu tố khuyến khích, điều này trở nên phức tạp hơn: kẻ tấn công có thể "cập nhật cây" bằng cách đưa một lượng lớn dữ liệu vào một cây con và gửi một giao dịch mỗi năm, từ đó buộc khách hàng phải lưu trữ một lượng lớn trạng thái vĩnh viễn. Nếu bạn làm cho chi phí gia hạn tỷ lệ 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ể làm hại người dùng khác bằng cách đưa một lượng lớn dữ liệu vào cùng một cây con với họ. Mọi người có thể cố gắng hạn chế hai vấn đề này bằng cách làm cho độ tinh vi động theo kích thước cây con: ví dụ, mỗi 216= 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 cuống thì đơn giản và có thể điều chỉnh các yếu tố khuyến khích, vì thường thì dưới cuống.