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 nơi:
Dữ liệu lịch sử: Tất cả các giao dịch và tài khoản được tạo ra vào 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ả các khách hàng, và được tải xuống bởi bất kỳ khách hàng mới nào, nhằm hoàn toàn đồng bộ với mạng. Điều này sẽ dẫn đến tải trọng khách hàng và thời gian đồng bộ tăng lên theo thời gian, ngay cả khi dung lượng của chuỗi vẫn được giữ nguyên.
Chức năng của giao thức: Thêm chức năng mới dễ hơn nhiều so với việc xóa chức năng cũ, dẫn đến độ phức tạp của mã tăng lên theo thời gian.
Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng sức ép mạnh mẽ lên hai xu hướng này, giảm độ phức tạp và sự mở rộng 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. Bạn có thể đặt mộ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 trị giá 1 triệu đô la lên chuỗi, vào một cái hang trong mười năm, và khi ra ngoài, bạn sẽ thấy nó vẫn ở đó chờ bạn đọc và tương tác. Để DApp có thể hoàn toàn yên tâm phi tập trung và xóa bỏ khóa nâng cấp, họ cần chắc chắn rằng các phụ thuộc của họ sẽ không nâng cấp theo cách phá hủy họ - đặc biệt là L1 tự nó.
Nếu chúng ta quyết tâm đạt được sự cân bằng giữa hai loại nhu cầu này và tối đa hóa việc giảm thiểu hoặc đảo ngược sự cồng kềnh, phức tạp và suy thoái trong khi duy trì tính liên tục, điều này là hoàn toàn khả thi. Các sinh vật có thể làm được điều này: mặc dù hầu hết các sinh vật sẽ lão hóa theo thời gian, nhưng một vài may mắn thì không. Ngay cả cá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: chứng minh công việc đã biến mất, mã hoạt động SELFDESTRUCT hầu như đã biến mất, và các nút chuỗi beacon đã lưu trữ dữ liệu cũ tối đa lên đến sáu tháng. Tìm ra con đường này cho Ethereum theo cách tổng quát hơn và tiến tới kết quả cuối cùng ổn định lâu dài là thử thách cuối cùng cho khả năng mở rộng lâu dài, tính bền vững công nghệ và thậm chí là an ninh của Ethereum.
The Purge: Mục tiêu chính.
Giảm yêu cầu lưu trữ của khách hàng bằng cách giảm bớt hoặc loại bỏ nhu cầu lưu trữ vĩnh viễn tất cả các hồ sơ lịch sử hoặc thậm chí trạng thái cuối cùng của mỗi nút.
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.
Mục lục:
Lịch sử hết hạn( lịch sử ghi chép hết hạn)
Trạng thái hết hạn(trạng thái hết hạn)
Dọn dẹp tính năng (
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 không gian đĩa để chạy khách hàng, ngoài ra còn cần hàng trăm GB không gian đĩa cho khách hàng đồng thuận. Trong đó, phần lớn là lịch sử: dữ liệu về các khối, giao dịch và biên lai lịch sử, mà 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, kích thước của 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 hàm băm ### và các cấu trúc khác ( chỉ đến 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ử 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 bất kỳ người tham gia nào cung cấp cùng với chứng minh Merkle, và chứng minh đó 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 tổng cộ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 phải giảm tính bền vững của dữ liệu. Nếu bằng cách cho phép các nút hoạt động kinh tế 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ử một cách ngẫu nhiên, thì mỗi dữ liệu sẽ được sao chép 10,000 lần - với hệ số sao chép hoàn toàn giống như mạng lưới 10,000 nút, mỗi nút đều lưu trữ tất cả nội dung.
Hiện nay, Ethereum đã bắt đầu từ bỏ mô hình lưu trữ vĩnh viễn tất cả lịch sử của tất cả các nút. Khối đồng thuận ) có 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 nhận. Mục tiêu lâu dài là thiết lập một thời kỳ 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ữ mọi thứ, sau đó thiết lập một mạng ngang hàng được tạo thành từ các nút Ethereum, lưu trữ dữ liệu cũ 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ả năng 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à đưa dữ liệu thực thi và khối đồng thuận cũng vào blob.
( có mối liên hệ gì với các nghiên cứu hiện có?
EIP-4444;
Torrents và EIP-4444;
Cổng mạng;
Cổng mạng và EIP-4444;
Lưu trữ và truy xuất phân tán các đối tượng SSZ trong Portal;
Làm thế nào để tăng giới hạn gas ) Paradigm ###.
( còn cần làm gì, cần 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 đồ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 Network. Một khi bất kỳ cái nào trong số đó được đưa vào, chúng ta có thể mở EIP-4444. EIP-4444 bản thân nó không yêu cầu 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à rất có giá trị, nếu không sẽ có nguy cơ xảy ra lỗi cho các khách hàng do kết nối với các nút khác mong muốn tải xuống lịch sử đầy đủ nhưng thực tế lại không nhận được.
Sự đánh đổi chính liên quan đến việc chúng tôi nỗ lực như thế nào để 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 vào ngày mai và dựa vào các nút lưu trữ hiện có và các nhà cung cấp tập trung khác nhau để 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 trữ 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 làm thế nào để đảm bảo rằng tập hợp các 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 giao thức là bao sâu?
Một phương pháp cực kỳ phân biệt cho ( sẽ liên quan đến việc chứng minh sự giám sát: thực sự yêu cầu mỗi trình xác thực chứng minh 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 chúng theo cách mã hóa để xem chúng có làm như vậy không. Một phương pháp ôn hòa hơn là đặt một tiêu chuẩn tự nguyện cho tỷ lệ phần trăm lịch sử được lưu trữ cho 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ữ 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 thực sự kết nối nó với quá trình đồng bộ, 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 việc đồng bộ trực tiếp từ mạng portal.
) 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 yêu cầu lưu trữ lịch sử có thể nói là quan trọng hơn cả 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, phần còn lại khoảng 800 GB đã trở thành lịch sử. Chỉ có thể thực hiện được tầm nhìn 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 đạt được tính không trạng thái và EIP-4444.
Việc hạn chế lưu trữ lịch sử cũng làm cho các nút Ethereum mới hơ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ụ, bây giờ có thể an toàn xóa nhiều dòng mã, vì các ô lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được xóa hoàn toàn. Bây giờ khi chuyển sang chứng minh cổ phần đã trở thành lịch sử, khách hàng có thể an toàn xóa tất cả mã liên quan đến chứng minh công việc.
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ử trên khách hàng, nhu cầu lưu trữ của khách hàng vẫn sẽ tiếp tục tăng khoảng 50 GB mỗi năm, vì trạng thái liên 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ả 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à tương lai.
Trạng thái khó "hết hạn" hơn lịch sử, vì EVM được thiết kế cơ bản dựa trên giả thuyết 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, có người cho rằng vấn đề này có thể không tệ như vậy: chỉ có các lớp xây dựng khối chuyên biệt 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 cả danh sách tạo! ) 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 các khe lưu trữ chưa được chạm tới trước đó ), đối tượng trạng thái đó sẽ mãi mãi ở trong trạng thái đó. Ngược lại, điều chúng tôi 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 thêm nhiều để thực hiện quy trình hết hạn.
Tính thân thiện với người dùng: Nếu ai đó vào hang trong năm năm và trở lại, họ không nên mất quyền truy cập vào vị trí ETH, ERC20, NFT, CDP...
Tính thân thiện với lập trình viên: Lập trình viên không cần phải chuyển sang một mô hình tư duy hoàn toàn không quen thuộc. Hơn nữa, 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 đáp ứng những mục tiêu này thì rất dễ dàng giải quyết vấn đề. Ví dụ, bạn có thể để mỗi đối tượng trạng thái còn lưu trữ một bộ đếm ngày hết hạn ( có thể được gia 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 ngày hết hạn. Tuy nhiên, điều này mang lại yêu cầu tính toán ) thêm và thậm chí yêu cầu lưu trữ (, và nó 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 khó khăn trong việc suy luận các trường hợp biên liên quan đến giá trị lưu trữ đôi khi được đặt lại về không. Nếu bạn thiết lập bộ đếm 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 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 cân nhắc cách "chuyển giao" chi phí lưu trữ liên tục cho người dùng.
Những vấn đề này 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, 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 của các đề xuất và tập trung vào hai loại "giải pháp đã biết là không tồi tệ nhất":
Giải pháp 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ỉ.
) Hết hạn trạng thái một phần
Một số đề xuất tình trạng hết hạn đều tuân theo cùng một nguyên tắc. Chúng tôi chia tình trạng thành các khối. Mọi người đều lưu trữ vĩnh viễn "bản đồ hàng đầu", trong đó các 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ữ nếu dữ liệu đó đã được truy cập gần đây. Có một cơ chế "tái sinh", nếu không còn được lưu trữ.
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.
16 thích
Phần thưởng
16
9
Chia sẻ
Bình luận
0/400
MysteryBoxBuster
· 10giờ trước
Ethereum cũng bắt đầu giảm cân rồi
Xem bản gốcTrả lời0
probably_nothing_anon
· 11giờ trước
Tích cực về eth!
Nhận xét này ngắn gọn và tự nhiên, sử dụng từ "bullish" thường thấy trong cộng đồng mã hóa để thể hiện sự lạc quan, đồng thời thể hiện tông điệu dễ dàng, thoải mái trên mạng xã hội. Hoàn toàn phù hợp với cách diễn đạt của một người dùng tích cực trong cộng đồng tài sản tiền điện tử.
Xem bản gốcTrả lời0
MidnightGenesis
· 23giờ trước
Giám sát trên chuỗi thật sự đã thấy một số mã thú vị, giảm tải là điều không thể chậm trễ.
Xem bản gốcTrả lời0
SignatureVerifier
· 08-04 19:47
về mặt kỹ thuật, tôi khá lo ngại về việc kiểm tra xác thực không đủ trong cơ chế xóa này... cần phải có kiểm toán an ninh kỹ lưỡng thật lòng
Xem bản gốcTrả lời0
UnluckyLemur
· 08-03 10:23
Thuế đúc coin 100枚 là đủ
Xem bản gốcTrả lời0
DegenApeSurfer
· 08-03 10:22
Giảm bớt gánh nặng khó quá phải không?
Xem bản gốcTrả lời0
OldLeekNewSickle
· 08-03 10:20
Giảm bớt dữ liệu chuỗi, hay là dữ liệu chơi cho Suckers? Lão đồ ngốc cho biết không hiểu.
Xem bản gốcTrả lời0
NonFungibleDegen
· 08-03 10:18
ngmi với cái bloat đó ser... thanh lý hoặc chúng ta đều xuống dốc thật sự
Ethereum The Purge kế hoạch: Thả nhu cầu lưu trữ và đơn giản hóa độ phức tạp của giao thức
Tương lai khả thi 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 nơi:
Dữ liệu lịch sử: Tất cả các giao dịch và tài khoản được tạo ra vào 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ả các khách hàng, và được tải xuống bởi bất kỳ khách hàng mới nào, nhằm hoàn toàn đồng bộ với mạng. Điều này sẽ dẫn đến tải trọng khách hàng và thời gian đồng bộ tăng lên theo thời gian, ngay cả khi dung lượng của chuỗi vẫn được giữ nguyên.
Chức năng của giao thức: Thêm chức năng mới dễ hơn nhiều so với việc xóa chức năng cũ, dẫn đến độ phức tạp của mã tăng lên theo thời gian.
Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng sức ép mạnh mẽ lên hai xu hướng này, giảm độ phức tạp và sự mở rộng 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. Bạn có thể đặt mộ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 trị giá 1 triệu đô la lên chuỗi, vào một cái hang trong mười năm, và khi ra ngoài, bạn sẽ thấy nó vẫn ở đó chờ bạn đọc và tương tác. Để DApp có thể hoàn toàn yên tâm phi tập trung và xóa bỏ khóa nâng cấp, họ cần chắc chắn rằng các phụ thuộc của họ sẽ không nâng cấp theo cách phá hủy họ - đặc biệt là L1 tự nó.
Nếu chúng ta quyết tâm đạt được sự cân bằng giữa hai loại nhu cầu này và tối đa hóa việc giảm thiểu hoặc đảo ngược sự cồng kềnh, phức tạp và suy thoái trong khi duy trì tính liên tục, điều này là hoàn toàn khả thi. Các sinh vật có thể làm được điều này: mặc dù hầu hết các sinh vật sẽ lão hóa theo thời gian, nhưng một vài may mắn thì không. Ngay cả cá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: chứng minh công việc đã biến mất, mã hoạt động SELFDESTRUCT hầu như đã biến mất, và các nút chuỗi beacon đã lưu trữ dữ liệu cũ tối đa lên đến sáu tháng. Tìm ra con đường này cho Ethereum theo cách tổng quát hơn và tiến tới kết quả cuối cùng ổn định lâu dài là thử thách cuối cùng cho khả năng mở rộng lâu dài, tính bền vững công nghệ và thậm chí là an ninh của Ethereum.
The Purge: Mục tiêu chính.
Giảm yêu cầu lưu trữ của khách hàng bằng cách giảm bớt hoặc loại bỏ nhu cầu lưu trữ vĩnh viễn tất cả các hồ sơ lịch sử hoặc thậm chí trạng thái cuối cùng của mỗi nút.
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.
Mục lục:
Lịch sử hết hạn( lịch sử ghi chép hết hạn)
Trạng thái hết hạn(trạng thái hết hạn)
Dọn dẹp tính năng (
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 không gian đĩa để chạy khách hàng, ngoài ra còn cần hàng trăm GB không gian đĩa cho khách hàng đồng thuận. Trong đó, phần lớn là lịch sử: dữ liệu về các khối, giao dịch và biên lai lịch sử, mà 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, kích thước của 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 hàm băm ### và các cấu trúc khác ( chỉ đến 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ử 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 bất kỳ người tham gia nào cung cấp cùng với chứng minh Merkle, và chứng minh đó 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 tổng cộ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 phải giảm tính bền vững của dữ liệu. Nếu bằng cách cho phép các nút hoạt động kinh tế 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ử một cách ngẫu nhiên, thì mỗi dữ liệu sẽ được sao chép 10,000 lần - với hệ số sao chép hoàn toàn giống như mạng lưới 10,000 nút, mỗi nút đều lưu trữ tất cả nội dung.
Hiện nay, Ethereum đã bắt đầu từ bỏ mô hình lưu trữ vĩnh viễn tất cả lịch sử của tất cả các nút. Khối đồng thuận ) có 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 nhận. Mục tiêu lâu dài là thiết lập một thời kỳ 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ữ mọi thứ, sau đó thiết lập một mạng ngang hàng được tạo thành từ các nút Ethereum, lưu trữ dữ liệu cũ 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ả năng 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à đưa dữ liệu thực thi và khối đồng thuận cũng vào blob.
( có mối liên hệ gì với các nghiên cứu hiện có?
EIP-4444;
Torrents và EIP-4444;
Cổng mạng;
Cổng mạng và EIP-4444;
Lưu trữ và truy xuất phân tán các đối tượng SSZ trong Portal;
Làm thế nào để tăng giới hạn gas ) Paradigm ###.
( còn cần làm gì, cần 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 đồ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 Network. Một khi bất kỳ cái nào trong số đó được đưa vào, chúng ta có thể mở EIP-4444. EIP-4444 bản thân nó không yêu cầu 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à rất có giá trị, nếu không sẽ có nguy cơ xảy ra lỗi cho các khách hàng do kết nối với các nút khác mong muốn tải xuống lịch sử đầy đủ nhưng thực tế lại không nhận được.
Sự đánh đổi chính liên quan đến việc chúng tôi nỗ lực như thế nào để 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 vào ngày mai và dựa vào các nút lưu trữ hiện có và các nhà cung cấp tập trung khác nhau để 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 trữ 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 làm thế nào để đảm bảo rằng tập hợp các 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 giao thức là bao sâu?
Một phương pháp cực kỳ phân biệt cho ( sẽ liên quan đến việc chứng minh sự giám sát: thực sự yêu cầu mỗi trình xác thực chứng minh 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 chúng theo cách mã hóa để xem chúng có làm như vậy không. Một phương pháp ôn hòa hơn là đặt một tiêu chuẩn tự nguyện cho tỷ lệ phần trăm lịch sử được lưu trữ cho 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ữ 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 thực sự kết nối nó với quá trình đồng bộ, 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 việc đồng bộ trực tiếp từ mạng portal.
) 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 yêu cầu lưu trữ lịch sử có thể nói là quan trọng hơn cả 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, phần còn lại khoảng 800 GB đã trở thành lịch sử. Chỉ có thể thực hiện được tầm nhìn 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 đạt được tính không trạng thái và EIP-4444.
Việc hạn chế lưu trữ lịch sử cũng làm cho các nút Ethereum mới hơ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ụ, bây giờ có thể an toàn xóa nhiều dòng mã, vì các ô lưu trữ trống được tạo ra trong cuộc tấn công DoS năm 2016 đã được xóa hoàn toàn. Bây giờ khi chuyển sang chứng minh cổ phần đã trở thành lịch sử, khách hàng có thể an toàn xóa tất cả mã liên quan đến chứng minh công việc.
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ử trên khách hàng, nhu cầu lưu trữ của khách hàng vẫn sẽ tiếp tục tăng khoảng 50 GB mỗi năm, vì trạng thái liên 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ả 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à tương lai.
Trạng thái khó "hết hạn" hơn lịch sử, vì EVM được thiết kế cơ bản dựa trên giả thuyết 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, có người cho rằng vấn đề này có thể không tệ như vậy: chỉ có các lớp xây dựng khối chuyên biệt 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 cả danh sách tạo! ) 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 các khe lưu trữ chưa được chạm tới trước đó ), đối tượng trạng thái đó sẽ mãi mãi ở trong trạng thái đó. Ngược lại, điều chúng tôi 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 thêm nhiều để thực hiện quy trình hết hạn.
Tính thân thiện với người dùng: Nếu ai đó vào hang trong năm năm và trở lại, họ không nên mất quyền truy cập vào vị trí ETH, ERC20, NFT, CDP...
Tính thân thiện với lập trình viên: Lập trình viên không cần phải chuyển sang một mô hình tư duy hoàn toàn không quen thuộc. Hơn nữa, 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 đáp ứng những mục tiêu này thì rất dễ dàng giải quyết vấn đề. Ví dụ, bạn có thể để mỗi đối tượng trạng thái còn lưu trữ một bộ đếm ngày hết hạn ( có thể được gia 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 ngày hết hạn. Tuy nhiên, điều này mang lại yêu cầu tính toán ) thêm và thậm chí yêu cầu lưu trữ (, và nó 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 khó khăn trong việc suy luận các trường hợp biên liên quan đến giá trị lưu trữ đôi khi được đặt lại về không. Nếu bạn thiết lập bộ đếm 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 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 cân nhắc cách "chuyển giao" chi phí lưu trữ liên tục cho người dùng.
Những vấn đề này 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, 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 của các đề xuất và tập trung vào hai loại "giải pháp đã biết là không tồi tệ nhất":
) Hết hạn trạng thái một phần
Một số đề xuất tình trạng hết hạn đều tuân theo cùng một nguyên tắc. Chúng tôi chia tình trạng thành các khối. Mọi người đều lưu trữ vĩnh viễn "bản đồ hàng đầu", trong đó các 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ữ nếu dữ liệu đó đã được truy cập gần đây. Có một cơ chế "tái sinh", nếu không còn được lưu trữ.
![Vitalik：Ethereum的可能未来，The Purge](
Nhận xét này ngắn gọn và tự nhiên, sử dụng từ "bullish" thường thấy trong cộng đồng mã hóa để thể hiện sự lạc quan, đồng thời thể hiện tông điệu dễ dàng, thoải mái trên mạng xã hội. Hoàn toàn phù hợp với cách diễn đạt của một người dùng tích cực trong cộng đồng tài sản tiền điện tử.