Xin cảm ơn Guillaume Ballet và Tanish Jasoria đã phản hồi và cảm ơn những người tham gia Stateless Implementors Call đã thảo luận trước đó về chủ đề này.

Trong bài viết này, chúng ta sẽ đi sâu vào chủ đề về chủ đề tạo ảnh trước của cây trạng thái , bao gồm:

• Giải thích đủ bối cảnh để hiểu chủ đề này phù hợp với sự phát triển của giao thức như thế nào.
• Cần có lời giải thích ở cấp độ cao về Đề xuất cải tiến Ethereum (EIP)-7612 và Đề xuất cải tiến Ethereum (EIP)-7748 để hiểu đúng vấn đề.
• Đề xuất một định dạng tệp tiềm năng cho ảnh gốc và phân tích xem liệu các định dạng phức tạp hơn có đáng để sử dụng hay không.
• Cung cấp một công cụ tạo ảnh trước mới sử dụng reth không lưu trữ để tạo và xác minh các tệp ảnh trước và tạo dữ liệu được sử dụng trong bài viết này để có thể tái tạo.

Nếu bạn biết lý do tại sao cần tạo ảnh trước cho quá trình chuyển đổi cây trong tương lai, hãy bỏ qua phần Bối cảnh .

Bối cảnh

Phần lộ trình của Verge đề xuất thay thế Merkle Patricia Trie (MPT) hiện tại bằng một cây mới, hiệu quả hơn trong việc đạt được trạng thái không trạng thái và SNARKifying L1 hơn nữa.

Các ứng cử viên cây chính hiện nay là Verkle Trees ( Đề xuất cải tiến Ethereum (EIP)-6800 ) và Binary Tree ( Đề xuất cải tiến Ethereum (EIP)-7864 ). Nếu bạn muốn biết thêm về sự phân đôi này, hãy đọc chuỗi thảo luận Đề xuất cải tiến Ethereum (EIP)-7864 . Chủ đề của bài viết này không liên quan đến quyết định này , vì vậy bạn có thể cho rằng có bất kỳ con đường nào trong tương lai.

Vì cây mới được sử dụng, chúng ta cần một chiến lược để di chuyển dữ liệu hiện có từ MPT sang cây mới. Chiến lược được đề xuất hôm nay là chuyển đổi dữ liệu bằng Overlay Tree ( Đề xuất cải tiến Ethereum (EIP)-7612 + Đề xuất cải tiến Ethereum (EIP)-7748 ), mà chúng ta sẽ khám phá sau.

Giả sử chúng ta muốn di chuyển dữ liệu của một tài khoản (Nonce, balance, code Hash) từ MPT sang cây mới. Khóa cây trong MPT là keccack(address) , nhưng trong cây mới, nó là new_key(address) , trong đó new_key không nhất thiết phải keccak . Các máy khách EL phải có quyền truy cập vào preimage cơ bản (tức là address trong trường hợp này) cho mỗi khóa trong cây. Nếu chúng chỉ có keccack(address) thì không thể tính toán new_key(address) . Điều tương tự cũng áp dụng cho các lần thử trạng thái tài khoản.

Tóm Short, mọi nút trong mạng sẽ trải qua quá trình chuyển đổi trạng thái từ MPT sang cây mục tiêu mới phải có khả năng giải quyết mọi ảnh tiền khóa MPT cho các tài khoản và thử lưu trữ.

Máy khách EL không lưu trữ ảnh gốc khóa cây sao?

Thật không may là không. Tùy thuộc vào kiến ​​trúc hiện tại và thiết kế cơ sở dữ liệu của máy khách EL, các ảnh trước này có thể được tính toán từ dữ liệu hiện có, nhưng điều này chỉ áp dụng cho một số ít máy khách.

Một số ví dụ về mối quan hệ giữa tiền ảnh khóa cây và cơ sở dữ liệu máy khách:

• Geth có flatdb để truy cập trạng thái nhanh hơn so với sử dụng cây. Các khóa trong cơ sở dữ liệu này là các giá trị băm của tài khoản hoặc sự kết hợp của Hash tài khoản và các khe lưu trữ Hash—tức là các khóa dựa trên băm. Sử dụng các phiên bản băm của khóa có ý nghĩa đối với việc đồng bộ hóa và chưa bao giờ có động lực thực sự nào để biện minh cho việc lưu trữ thêm các ảnh trước.
• Erigon và Reth cũng có flatdb nhưng sử dụng các khóa cây chưa băm làm khóa trong cơ sở dữ liệu này, rất tiện lợi cho vấn đề này.
• Nethermind hiện chưa có flatdb, do đó nó phụ thuộc vào việc truy cập hiệu quả vào cây để truy cập trạng thái, nhưng họ đang có kế hoạch giới thiệu flatdb (băm khóa) sớm.

Điều này có nghĩa là trừ khi bạn là nút Erigon hoặc Reth, bạn không có preimage thực tế của khóa cây. Theo ethernodes.org , các nút không phải Erigon+Reth chiếm hơn 80% mạng, nghĩa là hầu hết mạng đều có vấn đề preimage này. Ngay cả đối với các nút Erigon hoặc Reth, việc có thể lấy được preimage không có nghĩa là chúng có cách hiệu quả để giải quyết chúng ngày nay. Để hiểu rõ hơn về điều này, chúng ta hãy đi sâu hơn vào lý do tại sao.

Tiền ảnh được sử dụng như thế nào trong quá trình chuyển đổi cây?

Hiểu được cách cây phủ và EIP chuyển đổi trạng thái hoạt động cùng nhau có thể trả lời tốt hơn câu hỏi này. Bạn có thể đọc Đề xuất cải tiến Ethereum (EIP), nhưng đây là bản tóm tắt được nén lại để tiếp tục thảo luận về tiền ảnh.

Đề xuất cải tiến Ethereum (EIP)-7612 TL;DR

Lưu ý: Đề xuất cải tiến Ethereum (EIP) này tham chiếu đến Verkle, nhưng ý tưởng này không liên quan đến cây mục tiêu, do đó nó cũng hoạt động với Cây nhị phân.

Đề xuất cải tiến Ethereum (EIP) -7612 giải thích cách đưa cây mới vào giao thức:

• MPT trở thành chỉ đọc (tức là bị đóng băng) tại Block Fork .
• Một cây rỗng mới được tạo ra (ví dụ: Verkle hoặc Binary).
• Các cập nhật trạng thái phát sinh từ việc thực thi Block chỉ được ghi vào cây mới.
• Một tác dụng phụ nữa là việc chỉ đọc trạng thái bằng cây có nghĩa là phải đọc cây mới và nếu không tìm thấy mục thì phải kiểm tra MPT.

Tóm lại, đó là cây hai cấp (tức là lớp phủ ) trong đó cây cơ sở (MPT) bị đóng băng và cây trên cùng (Verkle hoặc Binary) bắt đầu mới, tiếp nhận các lệnh ghi. Về dấu đầu dòng cuối cùng, các máy khách EL có flatdb để truy cập trạng thái, vì vậy không nhất thiết có nghĩa là bạn phải thực hiện tra cứu cây đôi.

Đề xuất cải tiến Ethereum (EIP)-7748 TL;DR

Bây giờ chúng ta đã hiểu Đề xuất cải tiến Ethereum (EIP)-7612, đây là lúc Đề xuất cải tiến Ethereum (EIP)-7748 phát huy tác dụng:

• Tại dấu thời gian Block được xác định ( CONVERSION_START_TIMESTAMP ), quá trình chuyển đổi bắt đầu. Lưu ý rằng phải có đủ thời gian giữa kích hoạt Đề xuất cải tiến Ethereum (EIP)-7612 và CONVERSION_START_TIMESTAMP để chúng tôi có thể đảm bảo MPT bị đóng băng (tức là có chuỗi hoàn thiện để không có reorg nào có thể thay đổi thực tế)
• Trong Block tiếp theo, trước khi các giao dịch được thực hiện:
  • Xác định mục cây CONVERSION_STRIDE từ MPT.
    • Khái niệm về mục cây được định nghĩa chính xác hơn trong Đề xuất cải tiến Ethereum (EIP) (tức là đơn vị chuyển đổi được đặt tên) — chúng tôi sẽ đơn giản hóa một Bit ở đây.
    • Giá trị CONVERSION_STRIDE vẫn là TBD vì nó là sự đánh đổi giữa chi phí chuyển đổi trạng thái thực thi Block và thời lượng chuyển đổi đầy đủ. Giá trị phù hợp phụ thuộc vào cây mục tiêu vì Verkle có hàm băm lại tốn kém hơn Binary.
  • Chúng tôi sao chép nó vào cây trên cùng nếu nó không phải là giá trị cũ—vì Đề xuất cải tiến Ethereum (EIP)-7612 đã được kích hoạt, nên việc thực thi Block có thể đã ghi một giá trị mới cho khóa MPT này, không được ghi đè.
• Tiếp tục thực hiện các bước trên cho đến khi hoàn tất việc đi bộ tất cả các phím MPT.

Quyết định thiết kế rằng bước chuyển đổi trạng thái diễn ra trước khi các giao dịch được thực hiện là có lợi vì máy khách EL có thể thực hiện bước chuyển đổi trạng thái cho Block tiếp theo trước khi nó đến.

Sự kiện chính về quy trình này liên quan đến tệp tiền ảnh là thứ tự mà chúng ta lặp lại trên các mục nhập MPT. Thứ tự được đề xuất hiện tại là thực hiện toàn bộ bước đi theo chiều sâu (DFW) trong MPT(s): thực hiện DFW trong các lần thử tài khoản và khi đạt đến một lá, thực hiện DFW trong các lần thử lưu trữ tài khoản trước khi tiếp tục bước đi trong các lần thử tài khoản. Đầu tiên, chúng ta di chuyển các khe lưu trữ tài khoản và sau đó là dữ liệu của tài khoản.

Hãy xem một ví dụ để hiểu rõ hơn. Giả sử CONVERSION_STRIDE là 5 và chúng ta đang ở Block đầu tiên của quá trình chuyển đổi trạng thái. Sau đây là các mục MPT mà chúng ta có thể thấy trong quá trình đi bộ:

1. Tài khoản trie key 0x000000abc... bằng keccak(address_A) . Chúng tôi lưu ý rằng address_A có một trie lưu trữ với hai khe lưu trữ, vì vậy chúng tôi DFW vào đó.
   1. Bước #1: address_A tài khoản_A lưu trữ với khóa 0x0000131... bằng keccack(storage_slot_A) , nghĩa là chúng ta di chuyển giá trị storage_slot_A cho address_A sang cây mới.
   2. Bước #2: address_A tài khoản_A lưu trữ với khóa 0x0003012... bằng keccack(storage_slot_B) , nghĩa là chúng ta di chuyển giá trị storage_slot_B cho address_A sang cây mới.
   3. Bước #3: Vì chúng ta đã di chuyển tất cả các khe lưu trữ, nên bây giờ chúng ta di chuyển Nonce, số dư và mã của tài khoản address_A .
2. Tài khoản thử khóa 0x000000ffa... bằng keccak(address_B) . address_B là EOA
   1. Bước #4: không có khe lưu trữ, vì vậy không có DFW nào được thực hiện trong bộ lưu trữ. Chúng tôi di chuyển Nonce tài khoản address_B , số dư và mã.
3. Tài khoản trie key 0x000005630... bằng keccak(address_C) . Chúng tôi lưu ý rằng address_C có một trie lưu trữ với 1000 khe lưu trữ, vì vậy chúng tôi DFW nó.
   1. Bước #5: Bộ lưu trữ address_C của tài khoản có khóa 0x0000021... bằng keccack(storage_slot_A) , nghĩa là chúng ta di chuyển giá trị storage_slot_A cho address_C sang cây mới.

Lưu ý những điều sau:

• Thứ tự đi bộ trong trie tài khoản và các lần thử tiềm năng dựa trên băm, không phải địa chỉ hoặc giá trị khe lưu trữ đơn thuần. Đây là hậu quả của DFW trong trie vì các khóa là băm của địa chỉ hoặc khe lưu trữ.
• storage_slot_A từ address_A và address_C là một số khác (ví dụ: 10 và 24, tương ứng). Chúng có nghĩa là khe lưu trữ đầu tiên được tìm thấy khi đi bộ DFW trong các lần thử lưu trữ của chúng. Như đã đề cập trong dấu đầu dòng trước, thứ tự đi bộ khe lưu trữ dựa trên băm và không phải là thứ tự "tự nhiên", do đó storage_slot_A có thể lớn hơn storage_slot_B .
• Điểm trên cũng là lý do tại sao chúng ta cần ảnh trước—khóa đầu tiên có giá trị 0x000000abb , bạn cần biết giá trị này tương ứng với địa chỉ address_A để bạn có thể băm lại nhằm xác định khóa nào nằm trong cây mới.
• Mục nhập di chuyển cuối cùng chỉ là khe lưu trữ đầu tiên của account_C , nhưng chúng ta vẫn còn 99 khe. Chúng ta sẽ tiếp tục di chuyển chúng trong Block tiếp theo vì chúng ta đã đạt đến giới hạn CONVERSION_STRIDE!

Bạn cũng có thể tìm thấy bài nói chuyện về Đề xuất cải tiến Ethereum (EIP) này tại đây , kèm theo một số hình ảnh minh họa để hỗ trợ cho lời giải thích này.

Tóm tắt lại

Hy vọng những điều trên có thể làm rõ những sự thật sau:

• Tệp preimages phải chứa tất cả address_X hiện có trong tài khoản MPT bị đóng băng.
• Tệp preimages phải chứa tất cả storage_slot_X hiện có trong tất cả các lần thử lưu trữ MPT bị đóng băng.
• Vì MPT bị đóng băng và quá trình di chuyển mang tính xác định nên thứ tự mà chúng ta cần các ảnh trước được xác định đầy đủ ngay từ đầu.

Tệp tiền ảnh

Bây giờ chúng ta sẽ đi sâu vào các kích thước khác nhau của tệp tiền ảnh này:

• Phân bổ
• Khả năng xác minh
• Tạo và mã hóa
• Cách sử dụng

Trọng tâm chính của bài viết này là Tạo và mã hóa , nhưng chúng tôi sẽ đề cập đến các chiều khác để hoàn thiện. Cho đến khi chúng tôi đến phần Tạo , vui lòng cho rằng tệp này được tạo và mã hóa một cách kỳ diệu.

Phân bổ

Với việc tệp preimage được tạo ra theo cách nào đó, làm thế nào tệp này có thể tiếp cận tất cả các nút trong mạng? Chủ đề này đã được khám phá nhiều lần trong các cuộc gọi triển khai không trạng thái (SIC) , hội thảo sự kiện L1 và các cuộc thảo luận không chính thức.

Sau khi trao đổi với nhiều nhà phát triển cốt lõi (nhưng nhìn chung là mẫu nhỏ), Consensus hiện tại là có lẽ ổn khi mong đợi khách hàng tải xuống tệp này thông qua nhiều CDN tiềm năng. Điều này so với việc dựa vào mạng Portal, phân phối trong giao thức hoặc bao gồm tiền ảnh Block .

Các lựa chọn khác được thảo luận là:

• Có cơ chế phân phối trong giao thức.
• Phân phối các ảnh tiền xử lý cần thiết được đóng gói trên mỗi Block.

Chủ đề này rất gây tranh cãi vì các tùy chọn này có sự đánh đổi khác nhau về độ phức tạp, băng thông cần thiết trong hotpath giao thức và cơ hội nén. Mặc dù đã trao đổi với nhiều nhà phát triển cốt lõi, họ vẫn chưa đủ đại diện để kết luận rằng ACD sẽ đi đến cùng một kết luận.

Bài viết này tập trung vào định dạng mã hóa và tạo tiền ảnh, chúng ta phải thực hiện bất kể tệp này được phân phối như thế nào.

Khả năng xác minh

Như đã đề cập ở trên, các nút đầy đủ sẽ nhận tệp này từ một nơi nào đó có thể là một bên không đáng tin cậy hoặc một chuỗi cung ứng bị hack. Nếu tệp bị hỏng hoặc không hợp lệ, nút đầy đủ sẽ bị chặn tại một thời điểm nào đó trong quá trình chuyển đổi.

Tệp này có thể dễ dàng xác minh bằng cách thực hiện cây đi bộ được mô tả, đọc tiền ảnh dự kiến, tính toán Hash keccak và xác minh rằng nó khớp với kỳ vọng của máy khách. Sau khi tệp này được xác minh, nó có thể được sử dụng an toàn bất cứ khi nào quá trình chuyển đổi bắt đầu, với sự đảm bảo rằng máy khách không thể bị chặn bằng cách giải quyết tiền ảnh — việc có sự đảm bảo này rất quan trọng đối với tính ổn định của mạng trong suốt thời gian chuyển đổi. Thời gian xác minh này phải được tính đến trong độ trễ thời gian giữa kích hoạt Đề xuất cải tiến Ethereum (EIP)-7612 và dấu thời gian Đề xuất cải tiến Ethereum (EIP)-7748 CONVERSION_START_TIMESTAMP *.*

Tất nhiên, các cách khác để xác minh tệp này nhanh hơn nhưng đòi hỏi nhiều giả định hơn. Ví dụ, vì bất kỳ ai tạo tệp đều có thể nhận được cùng một đầu ra, nhóm khách hàng có thể tự tạo và mã hóa Hash/checksum của tệp. Khi tệp được tải xuống/nhập, quá trình xác minh có thể so sánh Hash của tệp với băm được mã hóa cứng.

Tạo và mã hóa

Bây giờ chúng ta đã biết thông tin nào mà tệp phải chứa và thông tin này sẽ được truy cập theo thứ tự nào, chúng ta có thể xem xét cách mã hóa dữ liệu này trong tệp. Lý tưởng nhất là chúng ta muốn mã hóa đáp ứng các thuộc tính sau:

• Tối ưu hóa cho mẫu đọc dự kiến: việc chuyển đổi trạng thái là một tác vụ chạy ngầm trong khi chuỗi chính chạy, do đó việc đọc thông tin cần thiết sẽ hiệu quả.
• Tối ưu hóa kích thước: như đã đề cập trước đó, tệp phải được phân phối theo cách nào đó. Băng thông là một nguồn tài nguyên quý giá; sử dụng ít hơn là tốt hơn.
• Độ phức tạp thấp: tệp này sẽ chỉ được sử dụng một lần, vì vậy định dạng mã hóa đơn giản là tốt. Không có ý nghĩa gì khi phát minh lại bánh xe bằng cách tạo ra các định dạng phức tạp mới trừ khi chúng mang lại lợi ích đặc biệt trong khi mất nhiều thời gian hơn để xác định và thử nghiệm.

Có một mã hóa ứng viên rất đơn giản và rõ ràng có thể được mô tả như sau theo ví dụ chúng ta đã khám phá trước đó: [address_A][storage_slot_A][storage_slot_B][address_B][address_C][storage_slot_A]... . Chúng tôi nối trực tiếp các ảnh gốc thô cạnh nhau theo thứ tự di chuyển dự kiến.

Mã hóa này có những lợi ích sau:

• Định dạng mã hóa không có chi phí chung vì không yêu cầu byte tiền tố. Mặc dù các mục nhập preimage có kích thước khác nhau (20 byte cho địa chỉ và 32 byte cho khe lưu trữ), máy khách EL có thể biết cần đọc bao nhiêu byte tiếp theo tùy thuộc vào việc chúng nên giải quyết địa chỉ hay khe lưu trữ trong cây.
• Máy khách EL luôn thực hiện đọc tuyến tính hướng tới tệp, do đó không có truy cập ngẫu nhiên. Phần Sử dụng sắp tới sẽ mở rộng về điều này.

Trước khi đi sâu hơn vào hiệu quả của mã hóa này, chúng ta hãy thử tạo tệp này cho mainnet và cảm nhận về kích thước. Để thực hiện, chúng tôi đã tạo một công cụ sử dụng một nút reth đầy đủ được đồng bộ hóa (tức là không nhất thiết phải lưu trữ) để tạo, xác minh và thực hiện các phân tích khác sẽ được trình bày sau. Một thời gian trước, chúng tôi đã tạo một công cụ geth , nhưng nó yêu cầu một nút đồng bộ hóa từ genesis với cờ --cache.preimages được bật.

Chúng ta có thể tạo tệp preimage bằng cách chạy preimages generate --datadir <...> --eip7748 . Sau đây là một số thông tin về tệp được tạo trong máy tầm trung:

• Thời gian tạo: ~1 giờ
• Kích thước tệp không nén: 42GiB
• Kích thước tệp nén (zstd): 36GiB

Lưu ý rằng bất kỳ ai trong mạng chạy nút Reth (hoặc có thể là Erigon) đều có thể tạo tệp và đầu ra luôn giống nhau vì khi MPT bị đóng băng, các ảnh trước sẽ được cố định.

Đi sâu hơn vào hiệu quả mã hóa

Mặc dù định dạng mã hóa không tốn chi phí mã hóa, sự khác biệt giữa kích thước nén và không nén báo hiệu các cơ hội nén. Hãy cùng khám phá lý do tại sao lại như vậy.

Chúng ta có thể đặt từng mục tiền ảnh trong tệp vào hai nhóm:

• Địa chỉ preimages
  • Loại bỏ trùng lặp
    • Mỗi mục [address_X] là duy nhất trong tệp vì cây tài khoản chứa thông tin duy nhất cho mỗi tài khoản, do đó không có cơ hội loại bỏ trùng lặp.
  • Nén:
    • Địa chỉ là các giá trị băm, do đó không có cách nào để nén chúng.
• Khe lưu trữ preimages
  • Loại bỏ trùng lặp
    • Chúng được lặp lại trong tệp vì nhiều hợp đồng có thể (và thực sự) chồng chéo trong việc sử dụng khe lưu trữ. Ví dụ: nhiều hợp đồng sử dụng khe lưu trữ 0, 1 và 2.
    • Nhóm khe lưu trữ lặp lại lớn nhất là các khe cấp cao nhất vì chúng có chung tiền tố 0x00000... (ví dụ: các khe được đề cập trong dấu đầu dòng trước).
    • Khi hợp đồng có mảng hoặc bản đồ băm, các khe lưu trữ sẽ phân tán hơn trong không gian khe lưu trữ do bản chất của cách băm ánh xạ các biến vào các khe lưu trữ.
  • Nén
    • Các cơ hội nén cho các khe lưu trữ khác nhau. Ví dụ, các khe lưu trữ có tiền tố 0x00000.. (tức là các biến hợp đồng hàng đầu) rất dễ nén vì chúng có nhiều byte không. Các khe lưu trữ khác chủ yếu là kết quả của các hàm băm; chúng không dễ nén như vậy (nhưng "có thể khử trùng").

Tóm lại, các địa chỉ không thể được khử trùng lặp hoặc nén, nhưng các khe lưu trữ có cơ hội được khử trùng lặp/nén. Tuy nhiên, thật khó để biết tác động sẽ lớn đến mức nào và liệu có đáng hay không.

Để phân tích sâu hơn, bạn có thể chạy công cụ phân tích preimage storage-slot-freq . Trước tiên, hãy xem kết quả:

 Database block number: 21662206 Top 1000 storage slot 29 -byte prefix repetitions: 0000000000000000000000000000000000000000000000000000000000 : 57150357 ( 4.65 %) ~1580MiB (cumm 1580MiB)f3f7a9fe364faab93b216da50a3214154f22a0a2b415b23a84c8169e8b: 13671109 ( 1.11 %) ~378MiB (cumm 1958MiB)8a35acfbc15ff81a39ae7d344fd709f28e8600b4aa8c65c6b64bfe7fe3: 9429136 ( 0.77 %) ~260MiB (cumm 2219MiB)f652222313e28459528d920b65115c16c04f3efc82aaedc97be59f3f37: 8580073 ( 0.70 %) ~237MiB (cumm 2456MiB)405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3: 7750842 ( 0.63 %) ~214MiB (cumm 2671MiB)a66cc928b5edb82af9bd49922954155ab7b0942694bea4ce44661d9a87: 3545488 ( 0.29 %) ~98MiB (cumm 2769MiB)c2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f: 2663837 ( 0.22 %) ~73MiB (cumm 2842MiB)...

(Bản đầy đủ dài hơn và có thể tìm thấy ở đây )

Chương trình đếm số khe lưu trữ có cùng tiền tố 29 byte, ví dụ, đối với tiền tố 00000....00 :

• Có khoảng 57 triệu khe cắm lưu trữ, chiếm 4,65% tổng số.
• Nó ánh xạ tới ~1580MiB kích thước tệp tiền ảnh.
• Giá trị cumm là tổng các kích thước lên đến hàng hiện tại. Ví dụ, 3 tiền tố preimage khe lưu trữ hàng đầu chiếm 2219MiB của tệp preimage.

Bạn có thể tự hỏi những giá trị ở hàng thứ hai, thứ ba và các hàng tiếp theo là gì:

• f3f7... là keccak(0x000000..08)
• 8a35... là keccak(0x000000..04)

Các tiền tố này xuất hiện vì nhiều hợp đồng đã xác định các mảng trong các khe lưu trữ 8 và 4 tương ứng. Điều này có nghĩa là giá trị trong tệp preimage là Hash của các số khe đó. Vì các mục trong mảng liên tiếp từ giá trị cơ sở này, nên các "mảng cấp cao nhất" này là các tiền tố hàng đầu trong tệp preimage.

Không có gì đặc biệt khi chọn 29 byte cho tiền tố; ý tưởng là nắm bắt việc nhóm các biến và mảng cấp cao nhất. Đối với hashmap, các mục được phân phối trên toàn bộ không gian khe lưu trữ, do đó có ít cơ hội hơn để loại bỏ trùng lặp. Cơ hội thậm chí còn thấp hơn khi có nhiều "lồng ghép" xảy ra trong các biến hợp đồng. Đó là lý do tại sao các tiền tố cấp cao nhất là các mảng cấp cao nhất, vì vậy điều đó có ý nghĩa.

Nếu bạn xem LINK (Chainlink) đầu ra đầy đủ, 1000 tiền tố hàng đầu chiếm ~4GiB, gần với mức nén ~6GiB mà chúng tôi đạt được thông qua zstd. Tất nhiên, đuôi rất dài, vì vậy kích thước tối ưu có thể tốt hơn.

Cố gắng loại bỏ trùng lặp như một phần của định dạng tệp sẽ làm tăng độ phức tạp của thông số kỹ thuật định dạng tệp. Có thể có những cách để bảo toàn các lần đọc gần như tuyến tính bằng cách tách N ảnh tiền tố hàng đầu để lưu trong RAM. Tuy nhiên, có thể không đáng nếu độ phức tạp tăng thêm so với định dạng đơn giản + zstd để giảm kích thước tương đối nhỏ. Hãy nhớ rằng, đây là lần tải xuống một lần. Có thể tải xuống ở các phần không quan trọng của thời lượng khe cắm hoặc thậm chí thông qua các liên kết internet riêng biệt (nhưng điều đó đòi hỏi phải làm thủ công).

Lưu ý rằng mặc dù zstd là một công cụ nén được sử dụng nhiều, nhưng nó đang thêm một sự phụ thuộc mới cho các máy khách EL. Ngoài ra, không gian ngoài thời gian có thể được yêu cầu để giải nén tệp (nhưng có thể có những cách để tránh điều này ). Trong mọi trường hợp, mục tiêu chính của bài viết này là cung cấp các phép đo thực tế về cách đuôi của kích thước khe lưu trữ hoạt động và mời nhiều cuộc thảo luận hơn về chủ đề này.

Cách sử dụng

Cần đề cập đến một số sự thật về cách khách hàng EL có thể sử dụng tệp này:

• Vì tệp được đọc theo tuyến tính nên việc duy trì con trỏ chỉ ra vị trí tiếp tục đọc từ đầu Block tiếp theo là rất hữu ích.
• Việc giữ danh sách vị trí con trỏ cho X khối cuối cùng giúp xử lý việc tổ chức lại. Nếu việc tổ chức lại xảy ra, rất dễ dàng để tìm kiếm lại vị trí tương ứng trong tệp.
• Khách hàng cũng có thể tải trước X khối tiếp theo bằng hình ảnh trước trong bộ nhớ trong khi khách hàng chủ yếu ở chế độ nhàn rỗi trong các khe, tránh IO bổ sung trong quá trình thực thi đường dẫn nóng Block .
• Nếu việc giữ toàn bộ tệp trên đĩa quá khó chịu, bạn có thể xóa các giá trị cũ sau điểm kết thúc chuỗi . Chúng tôi nghi ngờ điều này có đáng để tăng thêm độ phức tạp không, nhưng đây là chi tiết triển khai tùy thuộc vào nhóm khách hàng EL.

Phần kết luận

Bài viết này khám phá bối cảnh, vấn đề và không gian giải pháp của tệp preimages trong bối cảnh tiến hóa của giao thức chuyển đổi cây. Không có ý tưởng nào được trình bày ở đây là cuối cùng hoặc được mong đợi sẽ có Consensus rõ ràng trong ACD.

Mục tiêu chính là cung cấp lời giải thích đủ sâu sắc để nâng cao hiểu biết của nhiều người trong cộng đồng, tiếp tục tiến triển và hy vọng đóng vai trò là nguồn lực để đẩy nhanh các cuộc thảo luận trong tương lai của ACD về chủ đề này.