Không phải mọi quốc gia đều bình đẳng

Trạng thái của Ethereum không đồng đều: một vài hợp đồng nắm giữ hầu hết dung lượng lưu trữ, trong khi hầu hết các tài khoản đều tồn tại trong thời gian ngắn—đôi khi chỉ một khối duy nhất. Nghiên cứu các mô hình truy cập trạng thái cho thấy khối nào vẫn nóng và khối nào nguội. Nếu chúng ta tối ưu hóa cho việc sử dụng thực tế, chúng ta có thể làm cho lớp thực thi hoạt động nhanh hơn.

Phân tích

Nghiên cứu này phân tích mức sử dụng trạng thái theo loại tài khoản, mức sử dụng mã byte, mô hình triển khai và nhà máy, kích thước mã và hoạt động của khe cắm. Nghiên cứu bao gồm tất cả các khối từ genesis đến khối 22.431.083 trước Pectra (tháng 5 năm 2025).

EOA so với Hợp đồng — cái nào có hiệu lực lâu hơn?

Khoảng hoạt động = khoảng cách khối từ lần truy cập đầu tiên đến lần truy cập cuối cùng (đọc và ghi) của một trạng thái cụ thể.
Khoảng hoạt động 0 = trạng thái chỉ được truy cập trong một khối duy nhất.

Giả sử 1 khối = 12 giây .

S1afkFMcxx.png 1189×790 32,6 KB

rJvp0Ofqxx.png 1189×790 33,7 KB

1. EOA rõ ràng có hiệu lực lâu hơn hợp đồng.
   EOA có khoảng thời gian trung vị khác không (~3,1 ngày), trong khi khoảng thời gian co bóp trung vị bằng không . Đuôi bên phải của EOA nặng hơn ở mọi phân vị (q75, q95), cho thấy nhóm tuổi thọ dài hơn.

2. Hầu hết các hợp đồng đều có tính chất tạm thời theo thiết kế hoặc mục đích.
   Khoảng 55% hợp đồng là hợp đồng không thời hạn. Các yếu tố có thể tác động bao gồm:

   • Mẫu spam và tạo hàng loạt của nhà máy (ví dụ: bản sao mã thông báo, hợp đồng cặp không bao giờ được theo dõi).
   • Triển khai MEV/tiện ích được tạo cho một giao dịch duy nhất.
   • Các mẫu tự hủy (đặc biệt là trước EIP-6780), trong đó quá trình tạo và hủy diễn ra trong cùng một khối/giao dịch.

3. “EOA ngắn hạn” cũng rất phổ biến.
   EOA trung bình chỉ hoạt động trong khoảng 3,1 ngày kể từ lần quan sát đầu tiên đến lần quan sát cuối cùng, và 75% kết thúc trong vòng khoảng 6 tháng. Điều này có thể bao gồm người yêu cầu/người đúc coin một lần, địa chỉ gửi tiền trên sàn giao dịch và ví bot.

4. Có những hợp đồng dài hạn nhưng không điển hình.
   Các hợp đồng có thời hạn nhiều năm thường được điều chỉnh theo tiêu chuẩn hoặc dựa trên cơ sở hạ tầng : hợp đồng token (ERC-20/721), sổ đăng ký, bộ định tuyến, hợp đồng quản trị đa chữ ký/proxy và các nguyên hàm cốt lõi khác. Nhiều nhóm ứng dụng luân phiên địa chỉ khi nâng cấp, điều này làm phân mảnh hoạt động trên các lần triển khai mới hơn và rút ngắn khoảng thời gian đo lường tại mỗi địa chỉ.

Các hợp đồng đa dạng như thế nào?

1 hợp đồng ≠ 1 ứng dụng duy nhất. Trên thực tế, nhiều hợp đồng tái sử dụng các mã bytecode hiện có hoặc được triển khai bằng cùng một mẫu (với các nhà máy). Chúng ta có thể phân tích các hợp đồng dựa trên các danh mục khác nhau:

• Mẫu so với Mã byte duy nhất
• Theo địa chỉ của người triển khai
• Theo địa chỉ nhà máy
• Theo Mã Kích thước
• Có trạng thái (Có khe cắm) so với Không trạng thái (Không có khe cắm)

Mẫu so với Mã byte duy nhất

Mẫu = Băm bytecode được triển khai bởi nhiều hơn một địa chỉ hợp đồng.
Duy nhất = Băm bytecode được triển khai đúng một lần.

SJdamI49lg.png 1189×790 69.6 KB

Dữ liệu cho thấy:

• Mật độ hợp đồng cực cao : ~150.000 bytecode mẫu chiếm 97% tổng số hợp đồng. Chỉ riêng mã băm top 1 đã bao phủ 14,4% hợp đồng; top 10 bao phủ 51% ; top 100 bao phủ 81,8% . Đây là sự tái sử dụng mẫu đuôi dài nặng nề chứ không phải là sự đa dạng trong triển khai.
• Các khe không phải là nơi chứa các bản sao : Mặc dù chỉ chiếm 2,9% hợp đồng, các mã byte duy nhất nắm giữ ~875,2 triệu khe lưu trữ so với ~429,1 triệu đối với các mẫu — ~67% trạng thái nằm trong các triển khai một lần.

Khoảng thời gian hoạt động trung bình của các hợp đồng duy nhất (~4,1 tháng) gần gấp đôi so với các mẫu (~2,1 tháng). Điều này phù hợp với trực giác: nhiều mẫu là các proxy/bản sao tối thiểu, nhà máy token hoặc các triển khai tạm thời (spam/memecoin, khung MEV, các mẫu tự hủy trước EIP-6780) tồn tại trong thời gian ngắn hoặc không bao giờ được sử dụng sau khi tạo.

Việc các hợp đồng độc đáo nặng về trạng thái hơn có thể phản ánh các hệ thống phức tạp (DEX, staking, cầu nối, cơ sở hạ tầng rollup) quản lý dữ liệu lớn và bền vững. Mặt khác, việc chia sẻ mẫu hợp đồng khổng lồ giải thích cho tình trạng triển khai zero-activity-span kéo dài - nhiều bản sao không bao giờ thực thi có ý nghĩa sau khi được tạo.

Theo địa chỉ của người triển khai

Đơn = Người triển khai chỉ triển khai một hợp đồng.
Nhiều = Người triển khai triển khai nhiều hơn một hợp đồng.

BkDlFuNqle.png 1190×790 37 KB

rJneK_Vcxl.png 1189×790 72,8 KB

Dữ liệu cho thấy:

• Một nhóm nhỏ đảm nhiệm hầu hết việc triển khai — Chỉ 15,1% số người triển khai chiếm 90,4% hợp đồng. Sự tập trung rất cao: chỉ riêng 500 người triển khai hàng đầu đã chiếm 57,4% tổng số hợp đồng; riêng người triển khai lớn nhất chiếm 3,15% .
• Các nhà triển khai tích cực tạo ra nhiều hợp đồng dài hạn hơn, nặng về slot hơn trung bình . Hợp đồng từ nhiều nhà triển khai có thời gian tồn tại lâu hơn khoảng 3,5 lần (687 nghìn khối so với 197 nghìn khối) và sử dụng nhiều slot hơn khoảng 6 lần cho mỗi hợp đồng (193 so với 31 slot). Mô hình này phù hợp với các nhóm/dịch vụ duy trì sản phẩm trên chuỗi (và họ thành công), so với các thử nghiệm đơn lẻ.
• Nhưng các đơn vị triển khai khối lượng lớn nhất lại thiên về tính chất tạm thời . Trong số 10 đơn vị hàng đầu xét theo khối lượng, các hợp đồng có khoảng thời gian hoạt động cực kỳ ngắn (trung bình hàng trăm khối) và dung lượng lưu trữ tối thiểu—tương tự như các bản sao sản xuất hàng loạt, thư rác nhà máy và giàn giáo MEV. Nói cách khác: trong nhóm "nhiều đơn vị", có sự phân chia giữa các đơn vị xây dựng (triển khai bền vững, có trạng thái) và các đơn vị phun (triển khai khối lượng lớn, ngắn hạn).

Việc triển khai theo hợp đồng rất tập trung. Hầu hết các hợp đồng lâu dài, mang tính chất nhà nước đều đến từ các đơn vị triển khai lặp lại, trong khi các đơn vị triển khai khối lượng lớn nhất lại lấp đầy chuỗi bằng các hợp đồng ngắn hạn.

Đối với những người triển khai nhiều hợp đồng, cũng có thể họ đã mắc lỗi nên phải triển khai lại hợp đồng.

Theo địa chỉ nhà máy

Không phải nhà máy = Được tạo trực tiếp bởi EOA (không có hợp đồng trung gian).
Nhà máy – Cá thể = Được tạo ra theo hợp đồng chỉ tạo ra đúng một đứa trẻ.
Nhà máy – Nhiều = Được tạo ra theo hợp đồng tạo ra nhiều hơn một đứa trẻ.

SySRZ8V5gl.png 1189×790 37,8 KB

SJefMUNqex.png 1189×790 65,4 KB

Dữ liệu cho thấy:

• Hầu hết các hợp đồng đều là bản sao được tạo ra từ nhà máy. ~ 89,1% tổng số hợp đồng đến từ các nhà máy đa hợp đồng (32.929 địa chỉ), trong khi chỉ có 10,9% được triển khai mà không cần nhà máy. Tuy nhiên, các hợp đồng không phải nhà máy, trung bình, nặng hơn (≈ 313 khe lưu trữ/hợp đồng) và hoạt động lâu hơn (khoảng hoạt động trung bình ≈ 769 nghìn khối) so với các hợp đồng con của nhà máy (≈ 178–197 khe/hợp đồng; trung bình 431–510 nghìn khối).
• Mức độ tập trung cực cao. 5 nhà máy hàng đầu chiếm khoảng 43% tổng số lần triển khai và 100 nhà máy hàng đầu chiếm khoảng 89% . Một nửa số nhà máy triển khai ≤5 hợp đồng và 99% triển khai ≤4.978 hợp đồng.

Các nhà máy mở rộng quy mô mã nguồn nhẹ, giá rẻ. Số lượng slot trên mỗi hợp đồng thấp hơn và khoảng thời gian hoạt động trung bình ngắn hơn trong nhóm nhà máy Cá nhân và Đa nhà máy phù hợp với các mô hình proxy, spam token/cặp token, airdrop mint và hợp đồng MEV/giàn giáo—dễ sản xuất hàng loạt, thường tồn tại trong thời gian ngắn và nhiều hợp đồng không bao giờ tích lũy được slot có ý nghĩa.

Việc triển khai không phải tại nhà máy thường thiên về cơ sở hạ tầng. Dung lượng lưu trữ lớn hơn và thời gian triển khai dài hơn cho thấy các hệ thống được thiết kế riêng (quản trị, kho lưu trữ, bộ định tuyến, cầu nối, cơ sở hạ tầng rollup) được triển khai trực tiếp bởi EOA/đa chữ ký và được duy trì hoạt động theo thời gian.

“Nhà máy riêng lẻ” ≠ bền vững. Các nhà máy chỉ sản xuất đúng một con cho thấy khoảng thời gian ngắn hơn và ít khe cắm hơn so với các triển khai không phải nhà máy. Nhiều nhà máy trông giống như các ứng dụng bootstrap hoặc vanity của nhà máy hơn là các ứng dụng chạy dài.

Theo kích thước mã

Tuổi = Khối mới nhất (22431083) - khối nơi trạng thái được nhìn thấy lần đầu tiên.

Hkeyz_Bcle.png 1389×989 46,9 KB

HJN1z_Sqxx.png 1390×790 34 KB

Dữ liệu cho thấy:

• Tiny chiếm ưu thế, nhưng đó là hai thế giới khác nhau . Các hợp đồng Tiny chiếm khoảng 88% tổng số hợp đồng , nhưng hơn một nửa là hợp đồng không có khoảng thời gian (57,9%) , phù hợp với các bản sao và bản sao được đúc hàng loạt. Tuy nhiên, trong số các hợp đồng có hoạt động, Tiny có khoảng thời gian trung bình dài nhất trong bất kỳ nhóm nào ( khoảng 2,19 triệu khối ≈ 10 tháng ), cho thấy một nhóm nhỏ thứ hai có thời gian sử dụng lâu dài.
• Khoảng thời gian hoạt động so với quy mô không phải là đơn điệu—mà là hình chữ U. Dựa trên hoạt động khác không, khoảng thời gian trung vị giảm từ Nhỏ → Nhỏ → Trung bình → Lớn ( ngắn nhất, ~8,3 nghìn khối ≈ 1 ngày ), sau đó tăng trở lại thành Rất lớn (~273 nghìn khối ≈ 1 tháng) . Vì vậy, quan điểm "mã lớn hơn hoạt động lâu hơn" là sai vì kích thước trung bình có tốc độ thay đổi nhanh nhất.
• Mỗi loại kích thước đều có đuôi tồn tại lâu dài . P99 kéo dài cụm từ ~10–11,7 triệu khối (~3–4 năm) trên mọi kích thước, nghĩa là một phần nhỏ hợp đồng trong mỗi nhóm tồn tại trong nhiều năm.

Các hợp đồng nhỏ thường chứa đầy proxy và bản sao gốc. Hầu hết đều rẻ, dùng một lần và không bao giờ được sử dụng. Tuy nhiên, những hợp đồng quan trọng và thực sự hữu ích sẽ hoạt động lâu hơn nhiều, do đó có khoảng thời gian dài giữa các nhóm không phải là 0. Một khả năng khác là chúng là các hợp đồng cổng được sử dụng để nâng cấp.

Các hợp đồng Nhỏ/Vừa/Lớn tập trung vào các hợp đồng theo chu kỳ cường điệu (token/đúc NFT/trang trại, logic ứng dụng một lần). Các nhóm cũng luân phiên địa chỉ khi nâng cấp, do đó hoạt động sẽ trải dài theo từng phần.

Các hợp đồng rất lớn thường báo hiệu các hệ thống phức tạp. Chúng hiếm hơn và tồn tại lâu hơn các hợp đồng cỡ trung, nhưng không phải lúc nào cũng thành công - một số triển khai quy mô lớn không bao giờ được áp dụng.

Hợp đồng có trạng thái so với hợp đồng không trạng thái

Có trạng thái = Hợp đồng có ít nhất 1 khe lưu trữ
Không trạng thái = Hợp đồng có 0 khe lưu trữ

SkEvo3Sqll.png 1189×790 27.2 KB

Dữ liệu cho thấy:

• Hầu hết các hợp đồng đều không có trạng thái. 53,9% không bao giờ chạm vào bộ lưu trữ; 46,1% có.
• Hoạt động bằng không phổ biến hơn đối với hợp đồng không trạng thái. 58,9% so với 50,8% đối với hợp đồng có trạng thái.
• Hợp đồng không trạng thái có hiệu lực lâu hơn. Khoảng thời gian trung bình khác không của chúng dài hơn khoảng 30 lần so với hợp đồng có trạng thái (1,2 năm so với 14,6 ngày).

Tại sao điều này có thể xảy ra

• Không trạng thái = tiện ích rẻ và bền vững. Nhiều tiện ích chỉ là forwarder, proxy hoặc helper đơn giản. Chúng dễ triển khai hàng loạt (vì vậy nhiều khi không có span), nhưng những tiện ích hữu ích có thể hoạt động trong nhiều năm vì chúng không lưu trữ dữ liệu và không bao giờ cần di chuyển.
• Có trạng thái = được nâng cấp hoặc thay thế. Các token, pool, vault và ứng dụng lưu trữ dữ liệu có nhiều khả năng được nâng cấp hoặc hoán đổi sang phiên bản mới hơn. Điều này giúp phân chia hoạt động trên các địa chỉ mới và rút ngắn khoảng thời gian tại mỗi địa chỉ cũ.

Các khe lưu trữ được sử dụng tích cực như thế nào?

rypm9YS5gl.png 1389×989 44,8 KB

r1FsHjB5le.png 1189×790 71,4 KB

Dữ liệu cho thấy:

• Hơn một nửa số khe lưu trữ là tạm thời (63,3%) . Các khe này không bao giờ được truy cập sau khi cài đặt.
• Mức độ tập trung cực kỳ cao . Một hợp đồng duy nhất nắm giữ khoảng 6% tổng số slot (xem XEN Crypto ); 1000 hợp đồng hàng đầu nắm giữ khoảng 51% tổng số slot.

Các khe không hoạt động thường dùng cho cờ một lần, yêu cầu airdrop, hồ sơ khởi tạo, số dư bị bỏ rơi hoặc dữ liệu trong hợp đồng được thay thế nhanh chóng.

Một nhóm nhỏ các hệ thống lớn nắm giữ hầu hết các khe lưu trữ trực tiếp của Ethereum. Đó là lý do tại sao chỉ một phần nhỏ hợp đồng chiếm ưu thế trong tổng số khe lưu trữ.

Một lưu ý là các mẫu proxy thường tách biệt logic và lưu trữ. Hợp đồng logic thường xuất hiện không trạng thái và tồn tại lâu dài, trong khi hợp đồng lưu trữ giữ trạng thái và có thể được luân chuyển. Chỉ xem xét các địa chỉ (không phải dự án) sẽ cho thấy khoảng thời gian ngắn hơn đối với proxy có trạng thái.

Một số khe cắm được gắn nhãn "không hoạt động" vẫn có thể được đọc ngoài chuỗi (thông qua lệnh gọi RPC). Các lần đọc đó không xuất hiện trên chuỗi.

Ý tưởng mở

Ngày hết hạn của tiểu bang

Hầu hết các trạng thái đều nguội lạnh nhanh chóng. Một hướng thực dụng là cắt tỉa định kỳ các trạng thái không hoạt động bằng một kế hoạch phục hồi :

• Cửa sổ : Cửa sổ hoạt động 12–18 tháng phù hợp với phân phối: khoảng thời gian trung bình khác không đối với nhiều vùng đất của tiểu bang kéo dài dưới một năm, trong khi các tiểu bang có thời gian tồn tại lâu dài thì cao hơn.
• Lợi ích : Giữ trạng thái nóng ở mức nhỏ, làm chậm sự phát triển của trạng thái, giảm I/O đĩa, giảm kích thước lưu trữ và cải thiện thời gian xử lý khối

Để bắt đầu, hãy xem xét chúng ta có thể tiết kiệm được bao nhiêu dung lượng lưu trữ bằng cách xóa các tài khoản và khe lưu trữ có khoảng hoạt động bằng 0. Chúng tôi đã đo lường điều này trên ảnh chụp nhanh phẳng của Geth (bảng "trạng thái" khóa-giá trị), so sánh ảnh chụp nhanh ban đầu với ảnh chụp nhanh mà các khóa đó đã bị xóa (nút đã được đồng bộ hóa với khối 22.431.083):

Chỉ tính riêng trên ảnh chụp nhanh, việc loại bỏ trạng thái zero-span sẽ cắt giảm không gian lưu trữ khoảng 56% —một tín hiệu mạnh mẽ cho thấy trạng thái hết hạn có thể làm giảm đáng kể tập hợp trạng thái nóng.

Triển khai rẻ hơn cho các mã byte đã tồn tại

Mã trùng lặp gây lãng phí gas khi triển khai mặc dù máy khách thường loại bỏ mã bytecode trùng lặp trên đĩa bằng hàm băm mã. Một số giải pháp khả thi:

1. Giảm giá trùng lặp cục bộ (cùng khối/thời đại) : Nếu codehash bytecode xuất hiện hai lần trong cùng một khối (hoặc thời đại ngắn), lần triển khai thứ hai sẽ trả một khoản tiền gửi mã giảm .
   • Ưu điểm
     • Có thể dễ dàng xác minh trong một khối dựa trên thứ tự triển khai hợp đồng
     • Tiết kiệm chi phí khí đốt ngay lập tức cho các nhà máy và ví AA
     • Hạn chế tác động của thư rác vì chiết khấu chỉ áp dụng trong khối
   • Nhược điểm
     • Bất công: ai phải trả toàn bộ số tiền?
     • Sự phức tạp trong việc triển khai máy khách EL
2. “Đăng ký mã băm” toàn cục : Một hợp đồng hệ thống lưu trữ các ánh xạ của codehash → exists trong bộ nhớ của nó. Tất cả các triển khai hợp đồng trước tiên sẽ kiểm tra xem mã byte đã tồn tại hay chưa.
   • Ưu điểm :
     • Tiết kiệm gas cho ví AA, proxy và hợp đồng nhà máy.
     • Cơ chế có thể ủy quyền cho hợp đồng nếu mã byte đã tồn tại
   • Nhược điểm :
     • Khuyến khích các bản sao spam
     • Thêm bề mặt DoS vào sổ đăng ký – cần định giá cẩn thận để giảm giá không bị những kẻ gửi thư rác lạm dụng
     • Băm bytecode có thể trở thành vấn đề đối với sự phát triển của trạng thái khi kích thước bộ nhớ lưu trữ tăng lên
     • ZKEVM phải chứng minh sự tồn tại của mã băm
3. Hợp đồng duy nhất cho mỗi thư viện : Thay vì sử dụng các bản sao cho cùng một thư viện, hãy thêm mã lệnh LIBCREATE mới để triển khai "hợp đồng thư viện" trong đó chỉ sử dụng mã băm. Điều này có thể hữu ích để loại bỏ trùng lặp thư viện, nhưng chỉ khi phân tích sâu hơn cho thấy các thư viện này thực sự chiếm một phần lớn hợp đồng.

Giá lưu trữ theo địa chỉ lũy tiến

Ngày nay, chỉ một số ít hợp đồng thống trị thị trường lưu trữ toàn cầu. Chúng ta có thể muốn mức giá phản ánh gánh nặng biên .

Giá lưu trữ theo địa chỉ lũy tiến : Chi phí SSTORE cơ bản cộng thêm phụ phí theo từng cấp khi slot_count(address) vượt ngưỡng (yêu cầu bộ đếm khe cắm trong giao thức, như trong siêu dữ liệu kiểu EIP-2027). Giữ chi phí ở mức có thể dự đoán được (theo từng cấp), nhưng vẫn thúc đẩy các hợp đồng rất lớn nội bộ hóa chi phí ngoại biên hóa trạng thái.

Ưu điểm:

• Liên kết chi phí với mức tăng trưởng lưu trữ thực tế tại một địa chỉ.
• Phân chia theo từng bậc giúp việc lập kế hoạch chi phí dễ dàng hơn so với việc định giá theo từng vị trí.
• Khuyến khích thiết kế lưu trữ tốt hơn, nơi mà “không gian lưu trữ không giới hạn” không bị lạm dụng.

Nhược điểm:

• Cần có siêu dữ liệu và quy tắc về số lượng khe cắm; làm tăng thêm độ phức tạp.
• Ước tính gas khó hơn khi một giao dịch vượt qua một giao dịch giữa tầng.
• Có thể thúc đẩy các nhà phát triển chia nhỏ trạng thái thành nhiều hợp đồng (nhiều cuộc gọi hơn, nhiều bề mặt hơn, UX tệ hơn).
• Các hợp đồng hữu ích có xu hướng có nhiều vị trí và chúng tôi đang trừng phạt chúng vì hoạt động

Mô hình lưu trữ tạm thời

Nhiều khe cắm được ghi một lần và không bao giờ được sử dụng lại. Cung cấp cho các nhà phát triển một nơi lưu trữ dữ liệu ngắn hạn rẻ hơn, có thể đọc được theo hợp đồng và có thể loại bỏ một cách xác định.

Cách thức hoạt động (cấp cao):

• Gốc lưu trữ tạm thời theo tài khoản : thêm tempStorageRoot vào mỗi tài khoản hợp đồng để lưu trữ dữ liệu tạm thời
• Nhóm thời kỳ toàn cầu : tất cả các lần ghi đều được đưa vào thời kỳ hiện tại (ví dụ: 6-12 tháng)
• Hết hạn xác định : khi một khoảng thời gian kết thúc, dữ liệu của khoảng thời gian đó về mặt logic là 0 đối với các lần đọc, bất kể dữ liệu đó có bị cắt tỉa vật lý bởi các máy khách EL hay không
• Giá cả : Làm cho SSTORE hiện tại đắt hơn và lưu trữ dữ liệu trong bộ nhớ tạm thời rẻ hơn SSTORE

Ưu điểm:

• Điều chỉnh chi phí theo thời gian sử dụng dự kiến
• Mô hình tinh thần đơn giản: “sử dụng bộ nhớ tạm thời cho dữ liệu mà bạn có thể mất sau ~N tháng”
• Trực giao với (và tương thích với) công việc hết hạn trạng thái trong tương lai

Nhược điểm:

• Cần phải di chuyển tài khoản do có trường tài khoản mới
• Rủi ro về công cụ nếu nhà phát triển dựa vào các giá trị sau khi đặt lại bộ nhớ
• Lịch trình khí đốt cần được điều chỉnh cẩn thận để tránh lạm dụng
• SSTORE trong các hợp đồng đã triển khai có chi phí gas cao hơn, có thể không công bằng

Cải thiện hiệu suất cho máy khách EL

Một số ý tưởng về cách khách hàng EL có thể sử dụng những thông tin này để cải thiện hiệu suất của họ:

• Phân tách trạng thái nóng/lạnh trong công cụ lưu trữ : Giữ các tài khoản/khe được chạm gần đây trong công cụ lưu trữ “nóng”, sau đó nén hàng loạt và chụp nhanh các tài khoản/khe lạnh ít thường xuyên hơn để giảm sự khuếch đại ghi.
• Cam kết dựa trên số lượng khe cắm : Ưu tiên các cam kết cơ sở dữ liệu cho các đường dẫn thử nghiệm của các hợp đồng lớn nắm giữ lượng khe cắm khổng lồ. Điều này sẽ nhắm mục tiêu vào những kẻ vi phạm nghiêm trọng nhất trước.
• Lưu trữ các mã băm thường thấy và kiểm tra sự tồn tại : Đối với việc tạo hợp đồng, hãy bỏ qua việc lưu lại mã bytecode trùng lặp, giúp giảm áp lực khuếch đại ghi và nén.

Đóng cửa

Vấn đề của Ethereum không chỉ là sự phát triển của trạng thái mà còn không có cách nào để xử lý trạng thái cũ.

Hầu hết các tài khoản đều tồn tại trong thời gian ngắn. Các nhà máy và bản sao mẫu chiếm ưu thế trong việc triển khai, nhưng các hợp đồng độc đáo nắm giữ phần lớn dung lượng lưu trữ. Một tập hợp nhỏ các hợp đồng sở hữu phần lớn các khe cắm, và nhiều khe cắm được viết một lần và không bao giờ được sử dụng lại. Nếu chúng ta có thể tìm ra những đột phá trong việc giải quyết những vấn đề này mà không phá vỡ khả năng kết hợp, Ethereum có thể mở rộng nhanh hơn.

Không phải mọi trạng thái đều bình đẳng—có lẽ giao thức không nên coi như vậy.

Lời cảm ơn

Xin gửi lời cảm ơn đặc biệt tới nhóm ethPandaOps vì cơ sở hạ tầng Xatu tuyệt vời của họ.

Cũng xin cảm ơn Guillaume, Carlos, Matan và Ignacio đã xem lại bài viết này.

Các bước tiếp theo

• Phân tích cường độ : Kết hợp khoảng thời gian với cường độ hoạt động để phân biệt trạng thái “yên tĩnh kéo dài” với trạng thái “ngắn nhưng mạnh”. Lượng khí tiêu thụ cũng cần được xem xét.
• Nhóm theo nhãn : Phân tích bằng nhãn (ví dụ: mã thông báo, bộ định tuyến, kho tiền, cầu, nhà máy, proxy) để củng cố thêm lý luận.
• Đăng EIP-6780 tự hủy : Điều tra xem có bao nhiêu hợp đồng được cho là tự hủy và bị xóa khỏi trạng thái thử nghiệm nhưng không thể thực hiện được vì EIP6780. Đồng thời, điều tra xem có bao nhiêu hợp đồng đã thực thi mã lệnh SENDALL .
• Hợp đồng số dư trống : Kiểm tra xem có bao nhiêu hợp đồng được tạo, HODL trong nhiều năm, rồi bị xóa. Nếu chúng không được sử dụng, có lẽ chúng ta có thể xóa chúng và không ai quan tâm.
• Thư viện : Kiểm tra xem có bao nhiêu hợp đồng được triển khai bằng thư viện.
• Phân bổ hợp đồng nhà máy/ngoài nhà máy theo phân chia duy nhất/mẫu.
• Xác định các cụm dựa trên các thuộc tính khác nhau (ví dụ: người triển khai, nhà máy, hàm băm mã, danh mục) và dung lượng lưu trữ mà chúng chiếm trong máy khách EL.

Phụ lục

Liên kết đến kho lưu trữ mã phân tích.