Vitalik: Tương lai có thể của Ethereum, The Purge

Một trong những thách thức mà Ethereum đang 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ẽ gia tăng 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 diễn ra vào bất kỳ thời điểm nào trong lịch sử và bất kỳ tài khoản nào được tạo ra đều cần được tất cả các khách hàng lưu trữ vĩnh viễn và được tải xuống bởi bất kỳ khách hàng mới nào, để 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ộ ngày càng tăng theo thời gian, ngay cả khi dung lượng chuỗi 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 lên theo thời gian.

Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng áp lực mạnh mẽ lên hai xu hướng này, giảm độ phức tạp và bloat 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, phát hiện nó vẫn ở đó chờ bạn đọc và tương tác. Để DApp có thể hoàn toàn yên tâm về việc phi tập trung và xóa bỏ khóa nâng cấp, họ cần chắc chắn rằng những phụ thuộc của họ sẽ không được nâng cấp theo cách phá hủy họ - đặc biệt là L1 bản thân.

Nếu chúng ta quyết tâm tìm ra sự cân bằng giữa hai nhu cầu này và tối đa hóa việc giảm thiểu hoặc đảo ngược sự phình to, phức tạp và suy thoái trong khi vẫn duy trì tính liên tục, thì điều này hoàn toàn có thể. Các sinh vật có thể làm đ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 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 đã đạt được thành công: bằng chứng công việc đã biến mất, mã vận hành SELFDESTRUCT phần lớn đã 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ách thức 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.

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 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.

Mục lục:

Lịch sử hết hạn

State expiry（状态到期）

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 đồng bộ hoàn toàn cần khoảng 1.1 TB không gian đĩa để thực thi máy khách, và cần thêm hàng trăm GB không gian đĩa cho máy khách đồ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, hầu hết 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 tăng chút nào, 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 liên kết tớ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 đồng thuận hiện tại là đủ để đạt được đồng thuận lịch sử. Chỉ cần mạng lưới đạt được đồ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 nào (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 lẻ nào 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ó. Đồ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ữ hồ sơ lịch sử. Một lựa chọn tự nhiên là 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 lưới hạt giống hoạt động trong vài thập kỷ qua: mặc dù mạng lưới 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 làm giảm tính ổn định của dữ liệu. Nếu bằng cách làm cho việc chạy nút trở nên tiết kiệm 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% hồ sơ 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 - hoàn toàn giống với một mạng lưới có 10,000 nút với hệ số sao chép, trong đó mỗi nút đều lưu trữ mọi thứ.

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ử của tất cả các node. Khối đồng thuận (tức là phần liên quan đến đồng thuận bằng chứng sở hữu) 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 đưa ra thời gian lưu trữ một năm cho các khối và biên lai lịch sử. Mục tiêu lâu dài 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 node chịu trách nhiệm lưu trữ mọi thứ, sau đó thiết lập một mạng ngang hàng gồm các node Ethereum, lưu trữ dữ liệu cũ theo cách phân tán.

Mã xóa có thể được sử dụng để nâng cao tính bền vững, trong khi vẫn giữ nguyên hệ số sao chép. Thực tế, Blob đã thực hiện mã xóa để hỗ trợ việc lấy mẫu tính khả dụng của dữ liệu. Giải pháp đơn giản nhất có lẽ là tái sử dụng mã xóa này và đưa dữ liệu thực thi và khối đồng thuận vào blob.

có mối liên hệ gì với các nghiên cứu hiện tại?

EIP-4444；

Torrents và EIP-4444；

Cổng mạng;

Mạng cổ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 phải 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 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. Khi một trong những cái đó đượ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 phân nhánh cứng, 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ó đồng thời cho tất cả các khách hàng 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 đến 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.

Những 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à 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 nhau để 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. Một con đường khó khăn hơn nhưng an toàn hơn là trước tiên xây dựng và tích hợp mạng torrent để lưu trữ lịch sử theo cách phân tán. Tại đây, "chúng tôi đã nỗ lực như thế nào" có hai khía cạnh:

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 xa?

Một phương pháp cực đoan để thực hiện (1) sẽ liên quan đến việc chứng thực lưu ký: thực tế yêu cầu mỗi trình xác thực chứng minh quyền lợi lưu trữ một tỷ lệ nhất định của lịch sử và thường xuyên kiểm tra bằng cách mã hóa xem họ có làm như vậy hay không. Phương pháp nhẹ nhàng 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ữ 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ữ 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ế nó với quy trình đồng bộ, để nếu ai đó muốn đồng bộ nút lưu trữ lịch sử hoàn chỉnh 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ể đạt được điều đó thông qua 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 tính vô trạng: trong 1.1 TB cần thiết cho nút, 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ỉ khi đạt được tính vô trạng và EIP-4444, chúng ta mới có thể hiện thực hóa 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 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ụ, giờ đây có thể xóa an toàn nhiều dòng mã, vì 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 hoàn toàn. Bây giờ khi đã chuyển sang chứng minh cổ phần, khách hàng có thể xóa an toàn 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 tôi loại bỏ nhu cầu lưu trữ lịch sử trên máy khách, nhu cầu lưu trữ của máy khách 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ể thanh toán một khoản phí một lần, từ đó tạo gánh nặng vĩnh viễn 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ó một số người cho rằng vấn đề này có thể không tồi tệ đến vậy: chỉ có các lớp xây dựng khối chuyên dụng cần phải 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ả việc tạo danh sách!) 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 phụ thuộc quá nhiều 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ẽ luôn ở trong 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à thực hiện đ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 ai đó vào hang động 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 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 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 đượ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ể để 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 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ẽ dẫn đến việc tính toán bổ sung (thậm chí 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ó để suy luận các trường hợp biên liên quan đến giá trị lưu trữ đôi khi được thiết lập lại về không. Nếu bạn thiết lập 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ẽ giúp cuộc sống của nhà phát triển dễ dàng hơn, nhưng 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, 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 từ các đề xuất và tập trung vào hai loại "giải pháp ít tệ nhất đã biết":

• Giải pháp cho một số trạng thái đã hết hạ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ữ vĩnh viễn "bản đồ hàng đầu", trong đó các khối có thể rỗng hoặc không rỗng. Chỉ khi dữ liệu đó được truy cập gần đây thì dữ liệu trong mỗi khối mới được lưu trữ. Có một cơ chế "hồi sinh", nếu không còn được lưu trữ.

Những khác biệt chính giữa các đề xuất này là: (i) chúng ta định nghĩa "