Paradigm: Giải thích chi tiết các vấn đề tăng trưởng lịch sử của Ethereum và các giải pháp tương ứng
Tuyển chọn TechFlowTuyển chọn TechFlow
Paradigm: Giải thích chi tiết các vấn đề tăng trưởng lịch sử của Ethereum và các giải pháp tương ứng
EIP-4444 có thể giải quyết vấn đề tăng trưởng lịch sử của Ethereum và tạo ra không gian để tăng giới hạn Gas.
Chuyên sâu báo cáo Web3Tác giả: Storm Slivkoff, Georgios Konstantopoulos
Biên dịch: Luffy, Foresight News
Tăng trưởng lịch sử (History growth) hiện là nút thắt lớn nhất trong việc mở rộng quy mô Ethereum. Điều đáng ngạc nhiên là tăng trưởng lịch sử đã trở thành vấn đề nghiêm trọng hơn cả tăng trưởng trạng thái. Trong vài năm tới, dữ liệu lịch sử sẽ vượt quá dung lượng lưu trữ của nhiều nút Ethereum.
Tin tốt là:
-
Tăng trưởng lịch sử là vấn đề dễ giải quyết hơn so với tăng trưởng trạng thái.
-
Các giải pháp đang được phát triển tích cực.
-
Việc giải quyết tăng trưởng lịch sử sẽ làm giảm bớt vấn đề tăng trưởng trạng thái.
Trong bài viết này, chúng tôi tiếp tục nghiên cứu các vấn đề về mở rộng quy mô Ethereum từ phần 1, chuyển sự chú ý từ tăng trưởng trạng thái sang tăng trưởng lịch sử. Với bộ dữ liệu chi tiết, mục tiêu của chúng tôi là 1) hiểu rõ về mặt kỹ thuật các điểm nghẽn mở rộng của Ethereum, và 2) hỗ trợ thảo luận về giới hạn Gas tối ưu cho Ethereum.
Tăng trưởng lịch sử là gì?
Lịch sử là tập hợp tất cả các khối và giao dịch mà Ethereum đã thực hiện trong toàn bộ vòng đời của nó – tức là mọi dữ liệu từ khối khai sinh đến khối hiện tại. Tăng trưởng lịch sử là sự tích lũy theo thời gian của các khối và giao dịch mới.
Hình 1 thể hiện mối quan hệ giữa tăng trưởng lịch sử, các chỉ số giao thức khác nhau và các giới hạn phần cứng của nút Ethereum. So với tăng trưởng trạng thái, tăng trưởng lịch sử bị giới hạn bởi một nhóm ràng buộc phần cứng khác. Tăng trưởng lịch sử gây áp lực lên I/O mạng vì các khối và giao dịch mới phải được truyền khắp mạng. Nó cũng gây áp lực lên dung lượng lưu trữ của nút do mỗi nút Ethereum đều lưu trữ bản sao đầy đủ của toàn bộ lịch sử. Nếu tốc độ tăng trưởng lịch sử đủ nhanh để vượt quá các giới hạn phần cứng này, các nút sẽ không còn có thể đạt được sự đồng thuận ổn định với các nút ngang hàng. Để biết tổng quan về tăng trưởng trạng thái và các điểm nghẽn mở rộng khác, hãy xem phần 1 của loạt bài này.
Hình 1: Các điểm nghẽn mở rộng của Ethereum
Cho đến gần đây, phần lớn thông lượng mạng trên mỗi nút đều dành để truyền tải dữ liệu lịch sử (ví dụ như khối mới và giao dịch). Điều này đã thay đổi khi Dencun hard fork giới thiệu blob. Hiện tại, blob chiếm phần lớn hoạt động mạng của nút. Tuy nhiên, blob không được coi là một phần của dữ liệu lịch sử vì 1) chúng chỉ được các nút lưu trữ trong 2 tuần rồi sau đó bị loại bỏ, 2) chúng không yêu cầu lặp lại dữ liệu kể từ khi Ethereum ra đời. Vì lý do (1), blob không làm tăng đáng kể gánh nặng lưu trữ trên từng nút Ethereum. Chúng tôi sẽ thảo luận về blob ở phần sau của bài viết này.
Trong bài viết này, chúng tôi sẽ tập trung vào tăng trưởng lịch sử và thảo luận về mối quan hệ giữa lịch sử và trạng thái. Do tăng trưởng trạng thái và tăng trưởng lịch sử có một số giới hạn phần cứng trùng lặp, chúng là hai vấn đề liên quan, và việc giải quyết một vấn đề có thể giúp giải quyết vấn đề kia.
Tăng trưởng lịch sử nhanh đến mức nào?
Hình 2 cho thấy tốc độ tăng trưởng lịch sử kể từ khi Ethereum ra đời. Mỗi đường thẳng đứng đại diện cho mức tăng trưởng trong một tháng. Trục y biểu thị số gigabyte tăng trưởng lịch sử trong tháng đó. Các giao dịch được phân loại theo "địa chỉ đích", và kích thước được đo bằng biểu diễn byte RLP (RLP). Các hợp đồng không thể nhận diện rõ ràng được xếp vào nhóm "chưa biết". Nhóm "Khác" bao gồm một loạt các danh mục nhỏ như cơ sở hạ tầng và trò chơi.
Hình 2: Tốc độ tăng trưởng lịch sử Ethereum theo thời gian
Một số điểm chính từ biểu đồ trên:
-
Tốc độ tăng trưởng lịch sử nhanh hơn 6–8 lần so với tăng trưởng trạng thái: Tốc độ tăng trưởng lịch sử gần đây đạt đỉnh 36,0 GiB/tháng, hiện tại là 19,3 GiB/tháng. Tốc độ tăng trưởng trạng thái đỉnh khoảng 6,0 GiB/tháng, hiện tại là 2,5 GiB/tháng. Phần sau của bài viết sẽ so sánh chi tiết hơn về tăng trưởng và kích thước tích lũy giữa lịch sử và trạng thái.
-
Trước Dencun, tốc độ tăng trưởng lịch sử liên tục gia tăng: Trong khi trạng thái tăng trưởng gần như tuyến tính trong nhiều năm (xem phần 1), thì lịch sử lại tăng trưởng siêu tuyến tính. Khi tỷ lệ tăng trưởng tuyến tính dẫn đến quy mô tổng thể tăng theo cấp bậc bình phương, thì tỷ lệ tăng trưởng siêu tuyến tính sẽ khiến quy mô tổng thể tăng nhanh hơn cả cấp bậc bình phương. Sự gia tăng này đột ngột dừng lại sau Dencun. Đây là lần đầu tiên Ethereum trải qua sự suy giảm mạnh về tốc độ tăng trưởng lịch sử.
-
Phần lớn tăng trưởng lịch sử gần đây đến từ Rollup: Mỗi L2 đều đăng lại bản sao giao dịch của mình lên mạng chính. Điều này tạo ra lượng lớn dữ liệu lịch sử, khiến Rollup trở thành yếu tố đóng góp lớn nhất cho tăng trưởng lịch sử trong năm qua. Tuy nhiên, Dencun cho phép L2 sử dụng blob thay vì dữ liệu lịch sử để công bố dữ liệu giao dịch, do đó Rollup không còn tạo ra phần lớn dữ liệu lịch sử Ethereum. Chúng tôi sẽ trình bày chi tiết hơn về Rollup ở phần sau.
Ai là người đóng góp lớn nhất cho tăng trưởng lịch sử Ethereum?
Số lượng lịch sử được tạo ra bởi các loại hợp đồng khác nhau tiết lộ cách sử dụng Ethereum đã tiến hóa như thế nào theo thời gian. Hình 3 cho thấy đóng góp tương đối của các loại hợp đồng khác nhau. Đây là dữ liệu giống như ở Hình 2 nhưng đã được chuẩn hóa.
Hình 3: Đóng góp của các loại hợp đồng khác nhau đối với tăng trưởng lịch sử
Dữ liệu này cho thấy bốn giai đoạn khác nhau trong cách sử dụng Ethereum:
-
Giai đoạn đầu (màu tím): Vài năm đầu tiên của Ethereum hầu như không có hoạt động trên chuỗi. Hầu hết các hợp đồng ban đầu này hiện khó nhận diện, được đánh dấu là "chưa biết" trên biểu đồ.
-
Kỷ nguyên ERC-20 (màu xanh lá): Tiêu chuẩn ERC-20 được hoàn thiện vào cuối năm 2015, nhưng chỉ bắt đầu phát triển mạnh vào năm 2017 và 2018. Hợp đồng ERC-20 trở thành nguồn tăng trưởng lịch sử lớn nhất vào năm 2019.
-
Kỷ nguyên DEX / DeFi (màu nâu): Hợp đồng DEX và DeFi xuất hiện trên chuỗi từ năm 2016 và bắt đầu thu hút sự chú ý vào năm 2017. Nhưng phải đến mùa hè DeFi năm 2020, chúng mới trở thành nhóm đóng góp lớn nhất cho tăng trưởng lịch sử. Hợp đồng DeFi và DEX chiếm hơn 50% tăng trưởng lịch sử trong một phần thời gian năm 2021 và 2022.
-
Kỷ nguyên Rollup (màu xám): Vào đầu năm 2023, các L2 Rollup bắt đầu xử lý nhiều giao dịch hơn mạng chính. Trong vài tháng trước Dencun, chúng tạo ra khoảng 2/3 dữ liệu lịch sử Ethereum.
Mỗi kỷ nguyên đại diện cho một mô hình sử dụng Ethereum phức tạp hơn so với trước đó. Theo thời gian, sự phức tạp này có thể được xem như một dạng mở rộng quy mô Ethereum, điều mà không thể đo lường bằng các chỉ số đơn giản như số giao dịch mỗi giây.
Trong tháng dữ liệu gần nhất (tháng 4 năm 2024), Rollup không còn tạo ra phần lớn dữ liệu lịch sử. Hiện chưa rõ liệu dữ liệu lịch sử trong tương lai sẽ đến từ DEX và DeFi hay sẽ xuất hiện một mô hình sử dụng mới nào đó.
Còn về blob thì sao?
Hard fork Dencun giới thiệu blob, làm thay đổi đáng kể động lực tăng trưởng lịch sử, cho phép Rollup sử dụng blob rẻ tiền thay vì dữ liệu lịch sử để công bố dữ liệu. Hình 4 phóng to tốc độ tăng trưởng lịch sử trước và sau nâng cấp Dencun. Biểu đồ này tương tự Hình 2, nhưng mỗi đường thẳng đứng đại diện cho một ngày thay vì một tháng.
Hình 4: Ảnh hưởng của Dencun đến tăng trưởng lịch sử
Từ biểu đồ này, chúng ta có thể rút ra một số kết luận chính:
-
Kể từ Dencun, tăng trưởng lịch sử từ rollup đã giảm khoảng 2/3: Hầu hết các rollup đã chuyển từ call data sang blob, làm giảm đáng kể lượng dữ liệu lịch sử mà chúng tạo ra. Tuy nhiên, tính đến tháng 4 năm 2024, vẫn còn một số rollup chưa chuyển từ call data sang blob.
-
Kể từ Dencun, tổng tăng trưởng lịch sử đã giảm khoảng 1/3: Dencun chỉ làm giảm tăng trưởng lịch sử từ rollup. Tăng trưởng lịch sử từ các loại hợp đồng khác tăng nhẹ. Ngay cả sau Dencun, tốc độ tăng trưởng lịch sử vẫn cao gấp 8 lần so với tăng trưởng trạng thái (chi tiết ở phần tiếp theo).
Mặc dù blob đã làm giảm tốc độ tăng trưởng lịch sử, nhưng chúng vẫn là tính năng mới của Ethereum. Hiện chưa rõ rằng với sự tồn tại của blob, tốc độ tăng trưởng lịch sử sẽ ổn định ở mức nào.
Tốc độ tăng trưởng lịch sử nào là chấp nhận được?
Tăng giới hạn Gas sẽ làm tăng tốc độ tăng trưởng lịch sử. Do đó, các đề xuất tăng giới hạn Gas (ví dụ như Pump the Gas) phải cân nhắc mối quan hệ giữa tăng trưởng lịch sử và các giới hạn phần cứng trên mỗi nút.
Để xác định tốc độ tăng trưởng lịch sử chấp nhận được, trước tiên cần hiểu phần cứng nút hiện tại có thể duy trì trong bao lâu về mặt mạng và lưu trữ. Về phần cứng mạng, khả năng duy trì hiện trạng có thể kéo dài vô thời hạn, vì tốc độ tăng trưởng lịch sử khó có thể quay lại mức đỉnh trước Dencun trước khi tăng giới hạn Gas. Tuy nhiên, gánh nặng lưu trữ dữ liệu lịch sử sẽ tiếp tục tăng theo thời gian. Với chiến lược lưu trữ hiện tại, ổ cứng của từng nút cuối cùng sẽ bị đầy bởi dữ liệu lịch sử — điều này là không thể tránh khỏi.
Hình 5 cho thấy gánh nặng lưu trữ của nút Ethereum theo thời gian và dự đoán sự gia tăng trong 3 năm tới. Dự báo dựa trên tốc độ tăng trưởng của tháng 4 năm 2024. Tốc độ này có thể tăng hoặc giảm tùy theo mô hình sử dụng hoặc giới hạn Gas trong tương lai.
Hình 5: Kích thước gánh nặng lưu trữ của dữ liệu lịch sử, trạng thái và nút đầy đủ
Từ biểu đồ này, chúng ta có thể rút ra một số kết luận chính:
-
Dữ liệu lịch sử chiếm khoảng 3 lần dung lượng trạng thái. Sự chênh lệch này sẽ càng lớn theo thời gian vì tốc độ tăng trưởng lịch sử cao gấp khoảng 8 lần so với trạng thái.
-
1,8 TiB là ngưỡng tới hạn, khi đó nhiều nút sẽ buộc phải nâng cấp ổ cứng. 2TB là dung lượng phổ biến, nhưng chỉ cung cấp 1,8 TiB không gian sử dụng. Lưu ý rằng TB (1 nghìn tỷ byte) và TiB (= 1024^4 byte) là các đơn vị khác nhau. Đối với nhiều nhà vận hành nút, ngưỡng "thực sự" thậm chí còn thấp hơn vì sau hợp nhất, trình xác thực phải chạy đồng thời client đồng thuận cùng với client thực thi.
-
Ngưỡng tới hạn sẽ đạt được trong 2–3 năm. Việc tăng bất kỳ lượng giới hạn Gas nào cũng sẽ đẩy nhanh thời điểm này. Khi đạt đến ngưỡng này, nhà vận hành nút sẽ phải chịu gánh nặng bảo trì đáng kể và cần mua thêm phần cứng (ví dụ như ổ NVME giá 300 đô la Mỹ).
Không giống dữ liệu trạng thái, dữ liệu lịch sử là chỉ ghi thêm (append-only) và ít được truy cập hơn nhiều. Do đó, về mặt lý thuyết, dữ liệu lịch sử có thể được lưu trữ riêng biệt trên phương tiện rẻ hơn. Điều này có thể thực hiện được trên một số client như Geth.
Ngoài dung lượng lưu trữ, I/O mạng là một giới hạn chính khác đối với tăng trưởng lịch sử. Không giống dung lượng lưu trữ, giới hạn I/O mạng sẽ không gây vấn đề cho nút trong ngắn hạn, nhưng sẽ trở nên quan trọng khi tăng giới hạn Gas trong tương lai.
Để hiểu thông lượng mạng điển hình của một nút Ethereum có thể hỗ trợ bao nhiêu tăng trưởng lịch sử, cần biết mối quan hệ giữa tăng trưởng lịch sử và các chỉ số sức khỏe mạng như tỷ lệ tổ chức lại (reorg), thiếu hụt slot, thiếu hụt finality, thiếu hụt proof, thiếu hụt hội đồng đồng bộ và độ trễ gửi khối. Phân tích các chỉ số này nằm ngoài phạm vi bài viết, nhưng có thể tìm thêm thông tin trong các nghiên cứu trước đây về sức khỏe lớp đồng thuận. Ngoài ra, dự án Xatu của Ethereum Foundation đang xây dựng các bộ dữ liệu công cộng để đẩy nhanh các phân tích như vậy.
Làm thế nào để giải quyết vấn đề tăng trưởng lịch sử?
Tăng trưởng lịch sử là vấn đề dễ giải quyết hơn so với tăng trưởng trạng thái. Nó gần như có thể được giải quyết hoàn toàn bằng đề xuất EIP-4444. EIP này sẽ thay đổi yêu cầu mỗi nút lưu trữ toàn bộ dữ liệu lịch sử Ethereum thành chỉ lưu trữ dữ liệu trong một năm. Sau khi triển khai EIP-4444, dung lượng lưu trữ sẽ không còn là điểm nghẽn mở rộng quy mô Ethereum, và việc tăng giới hạn Gas về lâu dài sẽ không còn bị giới hạn. EIP-4444 là cần thiết cho tính bền vững lâu dài của mạng; nếu không, tốc độ tăng trưởng lịch sử quá nhanh sẽ đòi hỏi phải thường xuyên nâng cấp phần cứng nút.
Hình 6 cho thấy ảnh hưởng của EIP-4444 đến gánh nặng lưu trữ trên mỗi nút trong 3 năm tới. Biểu đồ này giống Hình 4 nhưng thêm các đường mờ hơn thể hiện gánh nặng lưu trữ sau khi triển khai EIP-4444.
Hình 6: Ảnh hưởng của EIP-4444 đến gánh nặng lưu trữ của nút Ethereum
Từ biểu đồ này, ta có thể thấy một số kết luận chính:
-
EIP-4444 sẽ làm giảm một nửa gánh nặng lưu trữ hiện tại. Gánh nặng lưu trữ sẽ giảm từ 1,2 TiB xuống 633 GiB.
-
EIP-4444 sẽ ổn định gánh nặng lưu trữ lịch sử. Giả sử tốc độ tăng trưởng lịch sử không đổi, dữ liệu lịch sử sẽ bị loại bỏ với tốc độ bằng tốc độ tạo ra.
-
Sau EIP-4444, gánh nặng lưu trữ nút sẽ mất rất nhiều năm mới đạt đến mức hiện tại. Bởi vì tăng trưởng trạng thái sẽ là yếu tố duy nhất làm tăng gánh nặng lưu trữ, và trạng thái tăng chậm hơn nhiều so với lịch sử.
Sau khi triển khai EIP-4444, tăng trưởng lịch sử vẫn gây một mức độ gánh nặng lưu trữ nhất định vì nút sẽ lưu trữ dữ liệu lịch sử một năm. Tuy nhiên, ngay cả khi Ethereum đạt quy mô toàn cầu, gánh nặng này cũng không khó giải quyết. Một khi phương pháp lưu trữ lịch sử được chứng minh là đáng tin cậy, thời gian hết hạn một năm trong EIP-4444 có thể được rút ngắn xuống còn vài tháng, vài tuần hoặc thậm chí ít hơn.
Làm thế nào để lưu trữ dữ liệu lịch sử Ethereum?
EIP-4444 đặt ra câu hỏi: Nếu dữ liệu lịch sử không được lưu trữ bởi các nút Ethereum, thì nó nên được lưu trữ như thế nào? Dữ liệu lịch sử đóng vai trò then chốt trong việc xác minh, kế toán và phân tích Ethereum, do đó việc lưu trữ nó là rất quan trọng. May mắn thay, việc lưu trữ lịch sử là vấn đề đơn giản, chỉ cần 1/n nhà cung cấp dữ liệu trung thực. Điều này trái ngược hẳn với vấn đề đồng thuận trạng thái, vốn đòi hỏi từ 1/3 đến 2/3 người tham gia trung thực. Nhà vận hành nút có thể xác minh tính xác thực của tập dữ liệu lịch sử bằng cách 1) phát lại tất cả các giao dịch kể từ khối khai sinh và 2) kiểm tra xem các giao dịch này có tái tạo ra gốc trạng thái giống với đầu chuỗi hiện tại hay không.
Có nhiều phương pháp lưu trữ dữ liệu lịch sử.
-
Torrents/P2P: Torrent là phương pháp đơn giản và đáng tin cậy nhất. Các nút Ethereum có thể định kỳ đóng gói một phần dữ liệu lịch sử và chia sẻ dưới dạng tệp torrent công cộng. Ví dụ, một nút có thể tạo một tệp torrent lịch sử mới cứ sau 100.000 khối. Các client nút như erigon đã thực hiện quy trình này ở mức độ nhất định theo cách phi chuẩn hóa. Để chuẩn hóa, tất cả client nút phải dùng cùng định dạng dữ liệu, tham số và mạng P2P. Nút có thể chọn tham gia mạng này tùy theo khả năng lưu trữ và băng thông. Ưu điểm của torrent là sử dụng một tiêu chuẩn mở đã được hỗ trợ mạnh mẽ bởi nhiều công cụ dữ liệu.
-
Mạng Portal: Mạng Portal là mạng mới được thiết kế riêng để lưu trữ dữ liệu Ethereum. Phương pháp này tương tự torrent nhưng cung cấp thêm một số chức năng giúp xác minh dữ liệu dễ dàng hơn. Ưu điểm của Mạng Portal là các lớp xác minh bổ sung này mang lại tiện ích cho client nhẹ, cho phép truy vấn và xác minh hiệu quả tập dữ liệu chia sẻ.
-
Máy chủ đám mây: Dịch vụ lưu trữ đám mây như AWS S3 hoặc Cloudflare R2 cung cấp lựa chọn rẻ và hiệu suất cao để lưu trữ dữ liệu lịch sử. Tuy nhiên, phương pháp này tiềm ẩn nhiều rủi ro pháp lý và vận hành hơn, vì không đảm bảo các dịch vụ đám mây này luôn sẵn sàng và có khả năng lưu trữ dữ liệu tiền mã hóa.
Những thách thức triển khai còn lại chủ yếu là xã hội chứ không phải kỹ thuật. Cộng đồng Ethereum cần phối hợp về chi tiết triển khai cụ thể để tích hợp trực tiếp vào từng client nút. Đặc biệt, việc đồng bộ hoàn toàn từ khối khai sinh (thay vì đồng bộ nhanh) sẽ cần lấy dữ liệu lịch sử từ nhà cung cấp dữ liệu lịch sử thay vì từ các nút Ethereum. Những thay đổi này về mặt kỹ thuật không cần hard fork, do đó chúng có thể được thực hiện sớm hơn hard fork tiếp theo của Ethereum, Pectra.
Tất cả các phương pháp lưu trữ lịch sử này cũng có thể được L2 sử dụng để lưu trữ dữ liệu blob mà họ đăng lên mạng chính. So với lưu trữ lịch sử, việc lưu trữ blob 1) khó hơn do tổng lượng dữ liệu lớn hơn nhiều; 2) ít quan trọng hơn vì blob không cần thiết để phát lại lịch sử mạng chính. Tuy nhiên, việc lưu trữ blob vẫn cần thiết để mỗi L2 phát lại lịch sử riêng của mình. Do đó, một dạng lưu trữ blob nào đó là quan trọng đối với toàn bộ hệ sinh thái Ethereum. Hơn nữa, nếu L2 phát triển cơ sở hạ tầng lưu trữ blob mạnh mẽ, chúng cũng có thể dễ dàng lưu trữ dữ liệu lịch sử L1.
Việc so sánh trực tiếp các tập dữ liệu được lưu trữ bởi các cấu hình nút khác nhau trước và sau EIP-4444 sẽ rất hữu ích. Hình 7 cho thấy gánh nặng lưu trữ của các loại nút Ethereum khác nhau. Dữ liệu trạng thái là tài khoản và hợp đồng, dữ liệu lịch sử là khối và giao dịch, dữ liệu lưu trữ là một tập chỉ mục dữ liệu tùy chọn. Các con số trong bảng này dựa trên bản chụp nhanh reth gần đây, nhưng các client nút khác cũng sẽ có số liệu tương tự.
Hình 7: Gánh nặng lưu trữ của các loại nút Ethereum khác nhau
Nói cách khác,
-
Nút lưu trữ (archive node) lưu trữ dữ liệu trạng thái, lịch sử và dữ liệu lưu trữ. Người dùng có thể dùng nút lưu trữ khi cần truy vấn dễ dàng trạng thái chuỗi trong quá khứ.
-
Nút đầy đủ (full node) chỉ lưu trữ dữ liệu lịch sử và trạng thái. Hầu hết các nút hiện nay đều là nút đầy đủ. Gánh nặng lưu trữ của nút đầy đủ khoảng một nửa so với nút lưu trữ.
-
Nút đầy đủ sau EIP-4444 chỉ lưu trữ dữ liệu trạng thái và dữ liệu lịch sử một năm gần nhất. Điều này giảm gánh nặng lưu trữ từ 1,2 TiB xuống 633 GiB và giữ cho không gian lưu trữ dữ liệu lịch sử ở mức ổn định.
-
Nút không trạng thái (stateless node), còn gọi là "nút nhẹ", không lưu trữ bất kỳ tập dữ liệu nào và có thể xác minh ngay lập tức ở đầu chuỗi. Loại nút này sẽ khả thi khi Verkle trie hoặc các sơ đồ cam kết trạng thái khác được thêm vào Ethereum.
Cuối cùng, còn một số EIP bổ sung có thể hạn chế tốc độ tăng trưởng lịch sử, chứ không chỉ thích nghi với tốc độ hiện tại. Trong ngắn hạn, chúng giúp giữ tốc độ trong giới hạn I/O mạng; trong dài hạn, giúp giữ trong giới hạn lưu trữ. Mặc dù EIP-4444 vẫn là cần thiết cho tính bền vững lâu dài của mạng, nhưng những EIP khác này sẽ giúp Ethereum mở rộng hiệu quả hơn trong tương lai:
-
EIP-7623: Định giá lại call data, làm cho các giao dịch sử dụng quá nhiều call data trở nên đắt đỏ hơn. Việc làm tăng chi phí cho các mô hình sử dụng này sẽ buộc một số trong số chúng chuyển từ call data sang blob. Điều này sẽ làm giảm tốc độ tăng trưởng lịch sử.
-
EIP-4488: Giới hạn tổng lượng call data có thể chứa trong mỗi khối. Điều này sẽ đặt ra giới hạn nghiêm ngặt hơn đối với tốc độ tăng trưởng dữ liệu lịch sử.
Những EIP này dễ triển khai hơn EIP-4444, do đó chúng có thể được dùng như biện pháp tạm thời trước khi EIP-4444 đi vào sản xuất.
Kết luận
Mục đích của bài viết này là dùng dữ liệu để hiểu 1) cách thức hoạt động của tăng trưởng lịch sử và 2) các cách giải quyết vấn đề này. Nhiều dữ liệu trong bài viết này khó thu thập bằng các phương pháp truyền thống, do đó chúng tôi hy vọng việc công bố dữ liệu này sẽ mang lại cái nhìn mới về vấn đề tăng trưởng lịch sử.
Tăng trưởng lịch sử như một điểm nghẽn mở rộng quy mô Ethereum vẫn chưa được chú ý đúng mức. Ngay cả khi không tăng giới hạn Gas, thói quen hiện tại của Ethereum trong việc lưu trữ dữ liệu lịch sử sẽ buộc nhiều nút phải nâng cấp phần cứng trong vài năm tới. May mắn thay, đây không phải là vấn đề khó giải quyết. Đã có một giải pháp rõ ràng trong EIP-4444. Chúng tôi cho rằng nên đẩy nhanh việc triển khai EIP này để mở đường cho việc tăng giới hạn Gas trong tương lai.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Paradigm
