Mạng lưới con của Cổng thông tin Lịch sử Chuỗi đã hoàn thiện

Lịch sử chuỗi hoàn thiện là mạng con được xây dựng trên giao thức dây Portal. Mục tiêu của nó là cung cấp kho lưu trữ phi tập trung cho dữ liệu Ethereum lịch sử đã hoàn thiện.

Giả định rằng các nút trên mạng là các máy khách Lớp thực thi lưu trữ tất cả các tiêu đề lịch sử cục bộ. Các nút không phải là máy khách Lớp thực thi sẽ cần một cách để lấy Block Header cho một số Block nhất định (để xác minh nội dung).

Trong phần phụ lục, tôi sẽ so sánh với mạng con Lịch sử Cổng thông tin hiện có và lý do cho những thay đổi được đề xuất.

Đặc điểm kỹ thuật

Chức năng khoảng cách

Mạng con Lịch sử chuỗi hoàn thiện sử dụng số liệu khoảng cách XOR có sẵn được xác định trong thông số kỹ thuật giao thức dây Portal.

Hàm dẫn xuất ID nội dung

Các khóa nội dung (được mô tả sau) sử dụng số Block . ID nội dung được tính theo cách sau:

 CYCLE_BITS = 16 OFFSET_BITS = 256 - CYCLE_BITS # 240 def content_id ( block_number ):offset_bits, cycle_bits = divmod (block_number, 2 **CYCLE_BITS) # reverse the offset bits offset_bits = int ( '{:0{width}b}' . format (offset_bits, width=OFFSET_BITS)[::- 1 ], 2 ) return cycle_bits << OFFSET_BITS | offset_bits

Giải thích chi tiết và hình ảnh minh họa của hàm content_id được cung cấp ở phần bên dưới .

Giao thức dây

Mạng chuỗi sử chuỗi hoàn thiện sử dụng thông số kỹ thuật giao thức dây Portal .

Các định danh giao thức phụ discv5 (trường protocol của tin nhắn TALKREQ ) dựa trên mạng Ethereum mà nội dung bắt nguồn từ đó:

• 0x5000 - Mạng chính
• 0x5050 - Màu đỏ tía
• 0x5060 - Áo trùm đầu
• 0x5040 - Testnet (được sử dụng cho mục đích thử nghiệm hoặc devnet bị cô lập)

Giao thức mạng con có thể được cấu hình thông qua tệp cấu hình và/hoặc lệnh cli (chi tiết sẽ được thông báo sau).

Các loại tin nhắn

Mạng chuỗi Lịch sử chuỗi hoàn thiện hỗ trợ các thông báo giao thức chuẩn:

Ping.payload và Pong.payload

Loại tải trọng của tin nhắn Ping/Pong đầu tiên giữa các nút PHẢI là Loại 0: Tải trọng thông tin máy khách, bán kính và khả năng . Tin nhắn Ping/Pong tiếp theo NÊN sử dụng loại tải trọng mới nhất được hỗ trợ bởi cả hai nút.

Danh sách các tải trọng hiện được hỗ trợ:

• Loại 1: Tải trọng bán kính cơ bản

Các loại nội dung

Mạng con Lịch sử Chuỗi Hoàn thiện chứa các loại nội dung Block và biên lai. Không giống như các mạng con Cổng thông tin khác, các loại này sử dụng mã hóa rlp của các đối tượng cơ bản.

Block Thân

Kiểu nội dung thân Block chứa các giao dịch, lệnh ommer và lệnh rút tiền của khối.

 selector = 0x09 block_body_key = Container(block_number: uint64)content_key = selector + SSZ.serialize(block_body_key)content_value = rlp.encode(block-body)

Lưu ý: block-body đề cập đến kiểu được xác định trong đặc tả devp2p , là tập hợp các giao dịch, lệnh ommer và lệnh rút tiền.

Biên lai

Kiểu nội dung biên lai chứa các biên lai của khối.

 selector = 0x0A receipt_key = Container(block_number: uint64)receipts = [receipt₁, receipt₂, ...]content_key = selector + SSZ.serialize(receipt_key)content_value = rlp.encode(receipts)

Lưu ý: receiptₙ đề cập đến loại được xác định trong đặc tả devp2p .

Những cải tiến trong tương lai

Thông số kỹ thuật hiện tại được thiết kế mà không có thay đổi nào đối với giao thức dây Portal gốc. Các thay đổi bên dưới được xác định là mong muốn và có thể được triển khai bằng cách sử dụng phiên bản giao thức tại bất kỳ thời điểm nào trong tương lai.

Một số cải tiến có thể được ưu tiên và triển khai trước khi mạng con đi vào hoạt động.

Hỗ trợ mạng tốt hơn

Hiện tại, mạng được xác định bằng giao thức phụ discv5 cụ thể (xem giao thức Wire ở trên). Điều này có thể được cải thiện bằng cách chỉ định chain_id hoặc fork_id bên trong bản ghi ENR.

Truy vấn phạm vi

Nguồn gốc ID nội dung mới được định nghĩa cho phép chúng tôi dễ dàng thêm hỗ trợ cho các truy vấn phạm vi. Nội dung đã được phân phối trên mạng theo cách mong muốn, vì vậy chúng tôi không cần phải gieo lại.

Việc thêm hỗ trợ sẽ đơn giản như thêm các loại tin nhắn mới, ví dụ:

Nội dung tìm kiếm phạm vi (0x08)

Yêu cầu tin nhắn để lấy nhiều nội dung được neo bằng content_key đã cho.

 selector = 0x08 range_find_content = Container(content_key: ByteList[ 2048 ], count: uint16)

Mỗi loại nội dung phải chỉ rõ:

• có hỗ trợ truy vấn phạm vi hay không
• giá trị count tối đa được hỗ trợ
• cách content_key biểu diễn phạm vi mong muốn
  • ví dụ liệu content_key biểu thị điểm bắt đầu hay kết thúc của phạm vi mong muốn
• liệu phản hồi một phần có được coi là hợp lệ không
  • có lẽ đây nên là một trường tin nhắn

Phạm viNội dung (0x09)

Tin nhắn phản hồi cho Nội dung tìm phạm vi (0x08).

 selector = 0x09 range_content = Union [connection_id: Bytes2,content: List [ByteList[ 2048 ], 65535 ],enrs: List [ByteList[ 2048 ], 32 ],]

Kiểu tin nhắn này gần giống với tin nhắn Nội dung . Điểm khác biệt duy nhất là content là danh sách các giá trị nội dung.

Phụ lục: Cơ sở lý luận và giải thích

So sánh với Mạng lưới cổng thông tin lịch sử cũ

Nếu chúng ta cho rằng hầu hết các nút trên mạng đều là máy khách ở lớp thực thi, chúng ta phải xem xét một số thuộc tính của chúng:

• Các máy khách EL lưu trữ tất cả các tiêu đề Block lịch sử
• Các khách hàng EL đang chạy lâu dài
• Use Case phổ biến nhất để truy cập Lịch sử chuỗi đã hoàn tất là đồng bộ hóa nút từ genesis

Các máy khách EL không có quyền truy cập vào đối tượng HistoricalSummaries cần thiết để chứng minh các tiêu đề trên History Portal Network cũ. Với sự cân nhắc này và thực tế là các máy khách EL lưu trữ tất cả các tiêu đề Block , chúng ta không còn cần phải giữ các tiêu đề trên mạng nữa. Nếu điều này thay đổi trong tương lai, chúng ta có thể dễ dàng thêm chúng và quyết định xem chúng ta có thực hiện việc này với hoặc không có bằng chứng hay không.

Sau khi máy khách EL đồng bộ hóa các tiêu đề Block , nó có thể tính toán xem nên lưu trữ các phần thân và biên lai nào và có thể lấy chúng từ mạng. Khi chuỗi đang tiến triển, máy khách EL có thể chỉ giữ lại các phần thân và biên lai mà chúng cần. Điều này loại bỏ nhu cầu và hiệu quả của các cầu nối.

Yêu cầu về đĩa cho máy khách EL dự kiến ​​sẽ tăng theo thời gian. Do đó, sẽ hợp lý hơn nếu chúng có bán kính cố định (so với máy khách cổng thông tin chủ yếu sử dụng bán kính động).

Sử dụng số Block và hàm content_id tùy chỉnh cho phép chúng ta dễ dàng thêm các yêu cầu hàng loạt trong tương lai. Điều này sẽ cải thiện hiệu suất đồng bộ hóa máy khách từ genesis.

Việc sử dụng mã hóa rlp cho nội dung và biên lai phù hợp hơn với cách máy khách EL lưu trữ và xử lý dữ liệu.

Hàm ID nội dung

Mục tiêu của hàm content_id là phân bổ nội dung đều khắp không gian miền, đồng thời giữ các khối liên tiếp ở khoảng cách khá gần nhau.

Các khối được chia thành các chu kỳ, trong đó mỗi chu kỳ chứa 65536 (2^CYCLE_BITS) khối liên tiếp. Các khối từ một chu kỳ duy nhất được phân bổ đều trên toàn bộ không gian miền. Các khối từ các chu kỳ khác nhau được bù trừ để ngăn nhiều khối ánh xạ tới cùng một content_id và để phân bổ nội dung đồng đều hơn.

Hình ảnh trực quan của ý tưởng này được thể hiện trong hình ảnh sau.

Nội dung ID ý tưởng trực quan 2500×901 107 KB

Chúng tôi thực hiện điều này bằng cách thao tác Bits của block_number (uint64) :

1. 16 Bits ít quan trọng nhất ( cycle bits ) và 48 Bits quan trọng nhất ( offset bits ) được hoán đổi
2. Việc bù trừ các khối từ các chu kỳ khác nhau theo cách mong muốn được thực hiện bằng cách đảo ngược thứ tự của offset_bits
3. Cuối cùng, chúng ta thêm số không vào để lấy giá trị từ không gian miền ( uint256 )

Hình ảnh sau đây cho thấy quá trình này đối với Block số 12'345'678 .

Nội dung id dẫn xuất trực quan 1248×479 58,6 KB

Tương tác với hàm khoảng cách ( XOR )

Vì chúng ta sử dụng XOR như một hàm khoảng cách, nên có khả năng bán kính không bao phủ phần liên tục của không gian miền (dẫn đến "lỗ hổng" trong phạm vi được lưu trữ). Đây không phải là mối quan tâm lớn vì:

• Người ta đảm bảo rằng ít nhất một nửa bán kính sẽ liên tục
  • Phần liên tục này sẽ bao gồm NodeId
• Nếu bán kính là lũy thừa hoặc hai, thì toàn bộ phạm vi được lưu trữ là liên tục
  • Nếu chúng ta cho rằng khách hàng sử dụng bán kính cố định, thì họ có thể thực thi điều này

Chọn CYCLE_BITS

Việc lựa chọn CYCLE_BITS có hai sự đánh đổi cần được cân bằng:

• giá trị lớn hơn ngụ ý rằng mỗi đối tác sẽ lưu trữ ít chuỗi dài hơn của các khối liên tiếp hơn, thay vì nhiều chuỗi ngắn hơn
• giá trị lớn hơn cũng ngụ ý rằng nếu có nhu cầu lớn hơn đối với một số khối nhất định (ví dụ về phía đầu chuỗi), thì các nút giống nhau sẽ đảm nhận gánh nặng trong thời gian dài hơn để phục vụ các yêu cầu đó

Giá trị CYCLE_BITS=16 được chọn vì nó đơn giản hóa việc triển khai hàm trong hầu hết các ngôn ngữ (thao tác trên cấp độ byte so với Bit ) và vì nếu chúng ta giả sử rằng mỗi đối tác lưu trữ ít nhất 1/256 (≈0.4%) của tất cả nội dung, thì chúng cũng sẽ lưu trữ các chuỗi gồm ít nhất 256 khối liên tiếp (có vẻ như là một sự cân bằng tốt).