Phân tích ngắn gọn về đồng bộ hóa dữ liệu hoạt động trong Ethereum

I. Giới thiệu

Đi thẳng vào vấn đề, đồng bộ hóa dữ liệu Ethereum sử dụng các nút (ngang hàng) làm vật mang dữ liệu để lưu trữ và truyền tải các chủ thể dữ liệu chủ yếu bao gồm Header, Body và Reciept. executor (đồng bộ chủ động sẽ Bàn giao cho Downloader, đồng bộ thụ động sẽ bàn giao cho Fetcher) để thực hiện tác vụ tải dữ liệu cuối cùng.

Sau đó hỏi chủ thể dữ liệu chúng ta cần đồng bộ hóa dữ liệu gì để đồng bộ hóa? Dữ liệu khác nhau có cần được phân loại và đồng bộ hóa không?

Biết rằng Chuangyu Blockchain Security Lab đã tiến hành phân tích toàn diện và chi tiết.

2. Đối tượng dữ liệu:

Để thực hiện đồng bộ hóa dữ liệu, trước tiên chúng ta cần làm rõ chủ thể dữ liệu mà chúng ta đang đồng bộ hóa bao gồm những gì, nói chung, có hai loại, một loại không yêu cầu các nút gửi yêu cầu đồng bộ hóa tích cực và các nút sẽ tự phát lên mạng khi dữ liệu được đóng gói.Có ba loại dữ liệu trong loại này: Loại - khối đầy đủ, băm khối và giao dịch Giao dịch. Hôm nay chúng ta tập trung vào loại dữ liệu tiếp theo.

Loại dữ liệu thứ hai là dữ liệu yêu cầu nút chủ động gửi yêu cầu đồng bộ sau đó các nút khác phản hồi dữ liệu cần đồng bộ, ngoại trừ loại dữ liệu thứ nhất, các dữ liệu cần đồng bộ khác thuộc loại thứ hai , vì vậy có thể nói rằng các loại của nó phức tạp hơn và quan trọng nhất Ngoài ra còn có ba loại tiêu đề khối, thân khối, Biên lai xác nhận giao dịch (mã cụ thể ⬇⬇⬇), khác với loại đầu tiên, ba loại này có thể được cho là một phần nhất định của khối hoàn chỉnh, điều này cũng cho thấy Để đồng bộ hóa tích cực, hy vọng rằng phạm vi đồng bộ hóa dữ liệu giữa các nút có thể tự do và có thể kiểm soát được, và dữ liệu cần thiết có thể được đồng bộ hóa trước và tạm thời không cần thiết dữ liệu có thể được từ bỏ.

⬆Header có nghĩa là tiêu đề khối, đóng vai trò rất quan trọng trong khối, ParentHash sẽ ghi lại hàm băm khối của khối trước đó, UncleHash sẽ ghi lại hàm băm khối chú và coinbase sẽ xác định địa chỉ của người khai thác. Root, Txhash và ReceiptHash lần lượt là các nút gốc của ba cây tiền tố của trạng thái trie, tx trie và Receipt.trie. Một hàm băm mã RLP được sử dụng để mô tả trạng thái của thế giới, một hàm băm được sử dụng để mô tả giao dịch, và cái còn lại được sử dụng để mô tả việc nhận giao dịch. Bloom là bộ lọc Bloom trong tiêu đề khối để nhanh chóng xác định xem hàm băm mục tiêu có nằm trong một tập hợp nhất định hay không. Dữ liệu trên trong Header được tiêu đề khối sử dụng để xác định khối và các mô-đun dữ liệu quan trọng trong khối bằng cách sử dụng hàm băm. Phần còn lại của dữ liệu có nhu cầu riêng của họ. Có thể thấy rằng một tiêu đề khối đã mô tả cơ bản một khung khối, điều này cũng mở đường cho chiến lược đồng bộ hóa dữ liệu được đề cập sau này.

⬆Body tương đối ngắn gọn, chứa một tập hợp các đối tượng giao dịch và một mảng các tiêu đề khối của các khối chú.

⬆Biên nhận là một mảng được tạo sau khi thực hiện tất cả các đối tượng giao dịch trong khối, được sử dụng để ghi lại thông tin xử lý giao dịch. Sau khi chúng được tạo, chúng sẽ được chèn vào Receipt trie từng cái một và ReceiptHash trong tiêu đề khối cũng sẽ được tạo. Biên nhận giao dịch ghi lại ba phần thông tin để quản lý và nhận dạng giao dịch. Phần đầu tiên là phần đồng thuận, PostState, Status, CumulativeGasUsed, Bloom và Logs. Chỉ năm dữ liệu này sẽ được mã hóa trong ReceiptRLP để tạo thành hàm băm biên nhận và sau đó hàm băm biên nhận sẽ tham gia vào sự đồng thuận Phần thứ hai của dữ liệu là phần giao dịch, TxHash đề cập đến hàm băm giao dịch tương ứng với biên lai giao dịch, ContractAddress là địa chỉ của hợp đồng mới khi giao dịch được triển khai và GasUsed biểu thị Gas của Cách sử dụng giao dịch, phần thứ ba là phần khối, ghi lại hàm băm khối BlockHash, BlockNumber số khối hiện tại và TransactionIndex số sê-ri của giao dịch trong khối. Biên nhận có một sự khác biệt trực quan trong chiến lược đồng bộ hóa dữ liệu.Sự khác biệt trực quan nhất giữa fullSync và fastSync được đề cập bên dưới là việc đồng bộ hóa biên nhận của máy ngang hàng hay tạo biên nhận cục bộ.

3. Nhà cung cấp dữ liệu

Thiết bị truyền dữ liệu là một nút ngang hàng, thiết bị mang dữ liệu ngang hàng này, nếu bạn tìm kiếm kỹ trong mã nguồn, bạn sẽ tìm thấy một số peer.go ở một số góc, trước tiên, tôi sẽ liệt kê cấu trúc ngang hàng mà tôi tìm thấy về mô-đun đồng bộ hóa dữ liệu. . Có p2p/peer.go, eth/peer.go, les/peer.go, eth/downloader/peer.go. Mạng của Ethereum cũng có lớp vận chuyển, lớp phiên, lớp trình bày và lớp giao thức.

Máy ngang hàng trong gói p2p hoạt động như một mô hình nút cơ bản, lớp vận chuyển sẽ khám phá các máy ngang hàng liền kề dựa trên giao thức UDP và duy trì các kết nối ngang hàng, đồng thời sẽ thiết lập kênh trao đổi thông tin giữa các máy ngang hàng dựa trên giao thức TCP. Quản lý ngang hàng ở lớp phiên chủ yếu quản lý sự tương tác giữa các nút và giao thức con lớp trên, trong khi quản lý NodeTable chủ yếu quản lý bảng kết nối nút bên dưới được xây dựng dựa trên giao thức UDP. Do đó, các nút ngang hàng ở lớp p2p cần có khả năng lấy và mở các giao thức phụ, đồng thời cần có khả năng ping các nút khác và tất nhiên là nhận được tin nhắn từ các nút khác. Điều này được phản ánh trong ba mô-đun chức năng quan trọng trong p2p/peer.go, pingLoop, readLoop và startProtocols, đây cũng là ba chức năng trong phương thức peer.run().

Có thể thấy hình trên là cấu trúc ngang hàng bên dưới, còn hình bên dưới là cấu trúc ngang hàng của lớp giao thức con, các lớp giao thức con khác nhau sẽ có cấu trúc ngang hàng khác nhau, chính vì vậy mới có eth/peer.go và les/peer.go xét cho cùng Các giao thức phụ khác nhau áp dụng cho các tình huống dữ liệu khác nhau.

Chúng ta có thể thấy rằng vật mang dữ liệu có lớp dưới cùng ngang hàng và lớp giao thức phụ ngang hàng, đồng bộ hóa dữ liệu cần sử dụng giao thức truyền thông để quản lý và kết nối hai lớp ngang hàng. và lớp giao thức con ngang hàng thực hiện tải xuống và đồng bộ hóa dữ liệu, và giao thức rất quan trọng cần thiết để quản lý và giao tiếp giữa hai lớp này.

4. Quá trình đồng bộ dữ liệu

Vậy làm thế nào để khởi động giao thứcManager? Chúng tôi đã giới thiệu cấu trúc ngang hàng ở trên. Nó chủ yếu đại diện cho các nút từ xa khác. Trong Ethereum, có một loại cấu trúc khác là Nút cũng đại diện cho các nút. Nó chủ yếu đại diện cho chính nút cục bộ, hơi khác một chút và nút muốn bắt đầu p2p mạng. Nó phải dựa vào mô-đun Node cục bộ, sử dụng chức năng Node.Start() để bắt đầu hai tác vụ, một là khởi động Dịch vụ Ethereum và Ethereum.start khởi động trình quản lý giao thức, nhiệm vụ còn lại là khởi động p2p. Máy chủ, tạo và làm mới bộ chứa K , bật đồng thời giám sát cổng UDP và giám sát cổng TCP, đồng thời xử lý các thông báo được gửi từ các nút từ xa.

Khi trình quản lý giao thức được khởi động, nó cần kết nối ngang hàng lớp logic bên dưới (p2p) và ngang hàng lớp giao thức lớp trên cùng (eth):

Khi khởi động protocolManager, nút đầu tiên sẽ khởi tạo và gọi NewProtocolManager. Trong quá trình khởi tạo, chức năng SubProtocol sẽ được gọi để lấy kênh đọc và ghi tin nhắn từ dungeon p2p.peer, sau đó xây dựng bộ xử lý tin nhắn Xử lý, Xử lý , sẽ không chỉ chấp nhận Thông báo yêu cầu đồng bộ hóa mà còn chấp nhận thông báo phản hồi của nút. Trong phương thức bắt đầu của giao thứcManger, nó sẽ bắt đầu một trình đồng bộ hóa coroutine đồng bộ hóa thông thường, sẽ gọi trình thực thi trình tải xuống hoặc trình tải xuống để thực hiện đồng bộ hóa dữ liệu theo thông báo thông báo.

• Chế độ đồng bộ hóa dữ liệu

• Đồng bộ hóa dữ liệu đang hoạt động có nghĩa là các nút cục bộ yêu cầu dữ liệu khối một cách tự nhiên từ các nút lân cận và mục nhập dữ liệu nằm trong eth/downloader/downloader và eth/handler

• Đồng bộ hóa dữ liệu thụ động có nghĩa là nút cục bộ nhận được thông báo đồng bộ hóa dữ liệu (Message) từ các nút khác và sau đó yêu cầu dữ liệu khối.

• Quá trình đồng bộ hóa đang hoạt động Hãy lấy ví dụ về quá trình đồng bộ hóa đang hoạt động. Khi trình thực thi trình tải xuống được gọi, trước tiên, nó sẽ gọi findAncestor để tìm tổ tiên chung của chuỗi cục bộ và chuỗi từ xa, đồng thời bắt đầu đồng bộ hóa từ tổ tiên chung. Nó sẽ định cấu hình 4 trình tải , cụ thể là fetcherHeader và fetcherBodies , fetcherReceipts, ProcessHeaders cuối cùng gọi processFullSyncContent và processFastSyncContent theo chế độ đồng bộ hóa và cuối cùng gọi spawnSync để thực hiện đồng bộ hóa.

Trên đây là mã nguồn của quá trình đồng bộ hóa, từ mã nguồn có thể thấy rằng các tác vụ tải xuống chính được tập trung trong bộ tải có thể mở rộng do anh ấy xây dựng, đó là hàng đợi tác vụ của bộ tải. Theo các chiến lược đồng bộ hóa dữ liệu khác nhau, không chỉ cấu trúc của hàng đợi tác vụ của trình tải nạp là khác nhau mà quá trình cộng tác giữa các trình tải nạp cũng khác nhau.

5. Chiến lược đồng bộ hóa dữ liệu

Vai trò của hàng đợi tác vụ của trình tìm nạp được tóm tắt là đang diễn ra, điền dữ liệu, tập hợp dữ liệu và chèn dữ liệu cuối cùng. Loại dữ liệu nào được điền vào, dữ liệu nào cần được lắp ráp và thời điểm chèn dữ liệu đều được xác định bởi chế độ cấu trúc dữ liệu quan trọng, đại diện cho chiến lược đồng bộ hóa dữ liệu, chủ yếu được chia thành ba loại.

• lightSync: đồng bộ hóa nút nhẹ, khi điền dữ liệu, chỉ điền dữ liệu tiêu đề khối, không cần lắp ráp dữ liệu, gọi insertHeaderchain để chèn trực tiếp tiêu đề khối.

• fullSync: đồng bộ hóa toàn nút. Khi điền dữ liệu, bạn cần điền vào tiêu đề khối và phần thân khối, nhưng không điền vào biên lai giao dịch, tập hợp dữ liệu vào tập kết quả Kết quả, sau đó gọi importBlockResults để chèn dữ liệu vào kết quả được đặt vào chuỗi chính và Sự khác biệt của lightSync là không có thân khối để đồng bộ hóa ánh sáng, do đó, nó sẽ không thực thi và xác minh giao dịch, trong khi đồng bộ hóa nút đầy đủ fullSync sẽ thực hiện giao dịch và xác minh trong khi chèn dữ liệu, đó là lý do tại sao tốc độ đồng bộ hóa của nó chậm và sau đó nó sẽ tự tạo biên lai giao dịch Biên lai, vì vậy anh ta không cần Biên lai tham gia điền và lắp ráp.

• 6. Kết luận

6. Kết luận

Đồng bộ hóa dữ liệu Ethereum rất phức tạp, bao gồm kiến ​​trúc mạng, quản lý giao thức truyền thông, hợp tác của các kênh truyền dữ liệu, sắp xếp chiến lược đồng bộ hóa dữ liệu và thuật toán để tăng tốc độ đồng bộ hóa dữ liệu. Có nhiều chi tiết và mối quan hệ logic. Và đồng bộ hóa dữ liệu là nền tảng của giao tiếp giữa các nút blockchain và thế giới bên ngoài, và có nhiều quả trứng Phục sinh kiến ​​trúc tuyệt vời hơn. Mong bài viết tiếp theo chia sẻ cùng các bạn.