Một 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ử: 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 quá khứ đều cần được tất cả các khách hàng lưu trữ vĩnh viễn, và được bất kỳ khách hàng mới nào tải xuống để hoàn toàn đồng bộ hóa với mạng. Điều này dẫn đến tải trọng của khách hàng và thời gian đồng bộ hóa ngày càng tăng, ngay cả khi dung lượng của chuỗi vẫn không thay đổi.
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 theo thời gian.
Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng sức ép phản đối 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. Đồng thời, chúng ta cần giữ lại một trong những thuộc tính chính khiến blockchain trở nên vĩ đại: tính bền vững. Bạn có thể đặt NFT, những bức thư tình trong nhật ký giao dịch, hoặc một hợp đồng thông minh chứa 100 triệu đô la lên chuỗi, và sau 10 năm, nó vẫn ở đó chờ bạn đọc và tương tác. Để DApp có thể hoàn toàn phi tập trung mà không cần khóa nâng cấp, họ cần phải chắc chắn rằng các phụ thuộc của họ sẽ không được nâng cấp theo cách phá hoại họ - đặc biệt là L1 tự thân.
Nếu chúng ta quyết tâm cân bằng giữa hai nhu cầu này và giảm thiểu hoặc đảo ngược sự cồng kềnh, phức tạp và thoái hóa trong khi duy trì tính liên tục, điều này hoàn toàn có thể. Các sinh vật có thể làm điều này: trong khi hầu hết các sinh vật sẽ lão hóa 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ọ 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ã lệnh SELFDESTRUCT hầu như đã biến mất, và các nút chuỗi tín hiệu đã 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à hướng tới kết quả cuối cùng ổn định lâu dài là thử thách tối thượ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.
Mục tiêu chính của The Purge:
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 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
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 để thực thi 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. Phần lớn trong số này là lịch sử: dữ liệu về các khối lịch sử, giao dịch và biên nhận, phần lớn trong số đó đã có từ nhiều năm trước. Điều này có nghĩa là ngay cả khi giới hạn Gas không hề tăng, kích thước của nút vẫn 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 chính của vấn đề lưu trữ lịch sử là, vì mỗi khối được liên kết với khối trước đó thông qua băm ( và các cấu trúc khá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 đạ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ữ ) có thể được cung cấp bởi bất kỳ người tham gia nào cũng như 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ạng 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ó lẽ 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 tính ổn định của dữ liệu. Nếu bằng cách làm cho việc vận hành các nút trở nên 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ữ ngẫu nhiên 10% lịch sử, 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 10,000 nút, mỗi nút lưu trữ toàn bộ nội dung.
Ngày 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ử của tất cả các nút. 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 và biên nhận 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ể khoảng 18 ngày ), trong khoảng thời gian này 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 bao gồm 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 để cải thiện tính bền bỉ, đồ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 sẵn có của dữ liệu. Giải pháp đơn giản nhất có lẽ là tái sử dụng loại 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 nghiên cứu hiện có?
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 đố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ũng 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. Một khi đưa vào bất kỳ cái nào trong số đó, chúng ta có thể mở EIP-4444. EIP-4444 bản thân nó không cần 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 có nguy cơ xảy ra sự cố cho khách hàng vì kết nối với các nút khác mong đợi tải về lịch sử đầy đủ nhưng thực tế không nhận được.
Sự cân nhắc 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à dựa vào các nút lưu trữ hiện có và nhiều nhà cung cấp tập trung khác để sao chép. Điều này dễ dàng, nhưng 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 khó hơn nhưng an toàn hơn là xây dựng và tích hợp mạng torrent trước, để lưu trữ lịch sử theo cách phân tán. Tại đâ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 giao thức là bao nhiêu?
Một phương pháp cực kỳ bảo thủ đối với ( 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ột cách 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 về 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 triển khai 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ử của Ethereum. Việc triển khai triệt để hơn sẽ liên quan đến việc thực sự kết nối nó với quy trình đồng bộ, để nếu ai đó muốn đồng bộ 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ữ 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 nhu cầu lưu trữ lịch sử có thể nói là quan trọng hơn cả trạng thái không. 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ỉ bằng cách đạt được trạng thái không và EIP-4444, mới có thể thực hiện 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.
Việc hạn chế lưu trữ lịch sử cũng làm cho việc triển khai các nút 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ụ, bây giờ có thể xóa một cách 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. Khi việc chuyển sang chứng minh cổ phần đã trở thành lịch sử, khách hàng có thể xóa tất cả mã liên quan đến chứng minh công việc một cách an toàn.
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 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 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ế 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, có người cho rằng vấn đề này có thể không tồi tệ như vậy: chỉ có các lớp xây dựng khối chuyên biệt cần lưu trữ trạng thái thực tế, trong khi tất cả các nút khác ### thậm chí bao gồm cả danh sách sinh! ( có thể chạy 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 này sẽ mãi mãi ở 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 quan trọng 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 nhiều tính toán bổ sung để thực hiện quy trình đáo hạn.
Tính thân thiện với người dùng: Nếu có 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 ETH, ERC20, NFT, vị thế CDP...
Tính thân thiện với nhà phát triển: Các nhà phát triển không cần phải chuyển sang một mô hình tư duy hoàn toàn xa lạ. 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ễ giải quyết vấn đề. Ví dụ, bạn có thể làm cho 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 kéo dài ngày hết hạn bằng cách đốt ETH, điều này có thể tự động xảy ra 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 sẽ tạo ra yêu cầu tính toán bổ sung, ) thậm chí là yêu 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 rất 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ữ giá trị đôi khi được đặt lại thành 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 xem xét 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 đã được cộng đồng phát triển cốt lõi 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 trong các đề xuất và tập trung vào hai loại "giải pháp được biết đến là không tồi 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ỉ
) Hết hạn trạng thái một phần
Một số đề xuất trạng thái hết hạn đều tuân theo cùng một 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ữ "bản đồ hàng đầu" vĩnh viễn, trong đó các khối có thể là rỗng hoặc không rỗ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ế "tá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 ta định nghĩa "gần đây", và )ii( cách 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ế "chồi 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 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ữ liền kề đượ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 chồi có thể có tối đa 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 nhất định 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ữ 32 byte của dữ liệu đó.
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.
Ethereum The Purge: Thả lịch sử lưu trữ, đơn giản hóa giao thức, nâng cao tính bền vững
Tương lai có thể của Ethereum: The Purge
Tác giả: Vitalik Buterin
Một 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ử: 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 quá khứ đều cần được tất cả các khách hàng lưu trữ vĩnh viễn, và được bất kỳ khách hàng mới nào tải xuống để hoàn toàn đồng bộ hóa với mạng. Điều này dẫn đến tải trọng của khách hàng và thời gian đồng bộ hóa ngày càng tăng, ngay cả khi dung lượng của chuỗi vẫn không thay đổi.
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 theo thời gian.
Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng sức ép phản đối 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. Đồng thời, chúng ta cần giữ lại một trong những thuộc tính chính khiến blockchain trở nên vĩ đại: tính bền vững. Bạn có thể đặt NFT, những bức thư tình trong nhật ký giao dịch, hoặc một hợp đồng thông minh chứa 100 triệu đô la lên chuỗi, và sau 10 năm, nó vẫn ở đó chờ bạn đọc và tương tác. Để DApp có thể hoàn toàn phi tập trung mà không cần khóa nâng cấp, họ cần phải chắc chắn rằng các phụ thuộc của họ sẽ không được nâng cấp theo cách phá hoại họ - đặc biệt là L1 tự thân.
Nếu chúng ta quyết tâm cân bằng giữa hai nhu cầu này và giảm thiểu hoặc đảo ngược sự cồng kềnh, phức tạp và thoái hóa trong khi duy trì tính liên tục, điều này hoàn toàn có thể. Các sinh vật có thể làm điều này: trong khi hầu hết các sinh vật sẽ lão hóa 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ọ 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ã lệnh SELFDESTRUCT hầu như đã biến mất, và các nút chuỗi tín hiệu đã 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à hướng tới kết quả cuối cùng ổn định lâu dài là thử thách tối thượ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.
Mục tiêu chính của The Purge:
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 để thực thi 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. Phần lớn trong số này là lịch sử: dữ liệu về các khối lịch sử, giao dịch và biên nhận, phần lớn trong số đó đã có từ nhiều năm trước. Điều này có nghĩa là ngay cả khi giới hạn Gas không hề tăng, kích thước của nút vẫn 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 chính của vấn đề lưu trữ lịch sử là, vì mỗi khối được liên kết với khối trước đó thông qua băm ( và các cấu trúc khá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 đạ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ữ ) có thể được cung cấp bởi bất kỳ người tham gia nào cũng như 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ạng 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ó lẽ 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 tính ổn định của dữ liệu. Nếu bằng cách làm cho việc vận hành các nút trở nên 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ữ ngẫu nhiên 10% lịch sử, 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 10,000 nút, mỗi nút lưu trữ toàn bộ nội dung.
Ngày 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ử của tất cả các nút. 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 và biên nhận 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ể khoảng 18 ngày ), trong khoảng thời gian này 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 bao gồm 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 để cải thiện tính bền bỉ, đồ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 sẵn có của dữ liệu. Giải pháp đơn giản nhất có lẽ là tái sử dụng loại 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 nghiên cứu hiện có?
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ũng 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. Một khi đưa vào bất kỳ cái nào trong số đó, chúng ta có thể mở EIP-4444. EIP-4444 bản thân nó không cần 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 có nguy cơ xảy ra sự cố cho khách hàng vì kết nối với các nút khác mong đợi tải về lịch sử đầy đủ nhưng thực tế không nhận được.
Sự cân nhắc 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à dựa vào các nút lưu trữ hiện có và nhiều nhà cung cấp tập trung khác để sao chép. Điều này dễ dàng, nhưng 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 khó hơn nhưng an toàn hơn là xây dựng và tích hợp mạng torrent trước, để lưu trữ lịch sử theo cách phân tán. Tại đâ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 giao thức là bao nhiêu?
Một phương pháp cực kỳ bảo thủ đối với ( 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ột cách 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 về 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 triển khai 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ử của Ethereum. Việc triển khai triệt để hơn sẽ liên quan đến việc thực sự kết nối nó với quy trình đồng bộ, để nếu ai đó muốn đồng bộ 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ữ 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 nhu cầu lưu trữ lịch sử có thể nói là quan trọng hơn cả trạng thái không. 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ỉ bằng cách đạt được trạng thái không và EIP-4444, mới có thể thực hiện 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.
Việc hạn chế lưu trữ lịch sử cũng làm cho việc triển khai các nút 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ụ, bây giờ có thể xóa một cách 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. Khi việc chuyển sang chứng minh cổ phần đã trở thành lịch sử, khách hàng có thể xóa tất cả mã liên quan đến chứng minh công việc một cách an toàn.
![Vitalik：Ethereum的可能未来，The Purge]###https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
Hết hạn trạng thái
) Giải quyết 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 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 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ế 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, có người cho rằng vấn đề này có thể không tồi tệ như vậy: chỉ có các lớp xây dựng khối chuyên biệt cần lưu trữ trạng thái thực tế, trong khi tất cả các nút khác ### thậm chí bao gồm cả danh sách sinh! ( có thể chạy 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 này sẽ mãi mãi ở 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 quan trọng 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 nhiều tính toán bổ sung để thực hiện quy trình đáo hạn.
Tính thân thiện với người dùng: Nếu có 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 ETH, ERC20, NFT, vị thế CDP...
Tính thân thiện với nhà phát triển: Các nhà phát triển không cần phải chuyển sang một mô hình tư duy hoàn toàn xa lạ. 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ễ giải quyết vấn đề. Ví dụ, bạn có thể làm cho 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 kéo dài ngày hết hạn bằng cách đốt ETH, điều này có thể tự động xảy ra 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 sẽ tạo ra yêu cầu tính toán bổ sung, ) thậm chí là yêu 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 rất 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ữ giá trị đôi khi được đặt lại thành 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 xem xét 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 đã được cộng đồng phát triển cốt lõi 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 trong các đề xuất và tập trung vào hai loại "giải pháp được biết đến 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 trạng thái hết hạn đều tuân theo cùng một 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ữ "bản đồ hàng đầu" vĩnh viễn, trong đó các khối có thể là rỗng hoặc không rỗ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ế "tá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 ta định nghĩa "gần đây", và )ii( cách 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ế "chồi 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 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ữ liền kề đượ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 chồi có thể có tối đa 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 nhất định 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ữ 32 byte của dữ liệu đó.