Implement network communication

Oct 13, 2025 by wbrum.org 134 views

Introduction

The state root service in Fuel Core requires a block fetcher to function efficiently. To achieve this, we initially considered depending directly on the block fetcher from network-watchtower. However, this approach presented some compatibility issues with different versions of fuel-core-types. To resolve these problems and ensure seamless integration, we have decided to incorporate a local version of the block fetcher within Fuel Core. This local implementation will not only address the current compatibility concerns but also enable the reuse of the block fetcher logic in network-watchtower once it is released.

Motivation

The block fetcher is a crucial component in the state root service, responsible for retrieving blocks from the network. By incorporating a local version of the block fetcher in Fuel Core, we can:

Improve compatibility: The local implementation will be designed to work seamlessly with the current version of fuel-core-types, eliminating the compatibility issues associated with depending directly on the network-watchtower block fetcher.
Enhance maintainability: Having a local version of the block fetcher will allow us to make changes and updates without affecting the network-watchtower implementation, ensuring that both projects can evolve independently.
Facilitate reuse: Once the local block fetcher is implemented, it can be easily reused in network-watchtower when it is released, promoting code reuse and reducing duplication of effort.

Design Considerations

When designing the local block fetcher, we must consider the following factors:

API compatibility: The local block fetcher should provide an API that is compatible with the network-watchtower block fetcher, ensuring that it can be easily integrated into the state root service.
Network communication: The block fetcher should be able to communicate with the network to retrieve blocks, using a protocol that is compatible with the network-watchtower implementation.
Error handling: The block fetcher should handle errors and exceptions in a way that is consistent with the network-watchtower implementation, ensuring that the state root service can recover from any issues that may arise.

Implementation

To implement the local block fetcher, we will follow these steps:

Design the API: We will design an API for the local block fetcher that is compatible with the network-watchtower block fetcher.
Implement network communication: We will implement the network communication protocol for the block fetcher, using a library or framework that is compatible with the network-watchtower implementation.
Handle errors and exceptions: We will implement error handling and exception handling for the block fetcher, ensuring that it can recover from any issues that may arise.
Test and validate: We will thoroughly test and validate the local block fetcher to ensure that it works correctly and is compatible with the network-watchtower implementation.

Conclusion

Porting the block fetcher from network-watchtower will enable us to create a local implementation that is compatible with the current version of fuel-core-types and can be reused in network-watchtower once it is released. By following the design considerations and implementation steps outlined above, we can ensure that the local block fetcher is efficient, maintainable, and easy to integrate into the state root service.

Future Work

Once the local block fetcher is implemented, we can focus on the following tasks:

Integrate with the state root service: We will integrate the local block fetcher with the state root service, ensuring that it works correctly and efficiently.
Test and validate: We will thoroughly test and validate the local block fetcher in the context of the state root service, ensuring that it meets the required specifications.
Refine and optimize: We will refine and optimize the local block fetcher as needed, ensuring that it is efficient, maintainable, and easy to use.

Introduction

In our previous article, we discussed the motivation behind porting the block fetcher from network-watchtower and the design considerations for the local implementation. In this article, we will address some of the frequently asked questions (FAQs) related to this project.

Q: Why did we decide to port the block fetcher from `network-watchtower`?

A: We decided to port the block fetcher from network-watchtower because of the compatibility issues that arose when we tried to depend directly on it. By creating a local implementation, we can ensure that the block fetcher works seamlessly with the current version of fuel-core-types and can be reused in network-watchtower once it is released.

Q: What are the benefits of having a local block fetcher in Fuel Core?

A: Having a local block fetcher in Fuel Core provides several benefits, including:

Improved compatibility: The local implementation will be designed to work seamlessly with the current version of fuel-core-types, eliminating the compatibility issues associated with depending directly on the network-watchtower block fetcher.
Enhanced maintainability: Having a local version of the block fetcher will allow us to make changes and updates without affecting the network-watchtower implementation, ensuring that both projects can evolve independently.
Facilitated reuse: Once the local block fetcher is implemented, it can be easily reused in network-watchtower when it is released, promoting code reuse and reducing duplication of effort.

Q: How will the local block fetcher be designed to ensure API compatibility with `network-watchtower`?

A: The local block fetcher will be designed to provide an API that is compatible with the network-watchtower block fetcher. This will ensure that the local implementation can be easily integrated into the state root service and can be reused in network-watchtower once it is released.

Q: What network communication protocol will be used by the local block fetcher?

A: The local block fetcher will use a network communication protocol that is compatible with the network-watchtower implementation. This will ensure that the block fetcher can communicate with the network to retrieve blocks in a way that is consistent with the network-watchtower implementation.

Q: How will errors and exceptions be handled by the local block fetcher?

A: The local block fetcher will handle errors and exceptions in a way that is consistent with the network-watchtower implementation. This will ensure that the state root service can recover from any issues that may arise when using the local block fetcher.

Q: What is the timeline for implementing the local block fetcher?

A: The timeline for implementing the local block fetcher is as follows:

Design the API: We will design the API for the local block fetcher within the next two weeks.
Implement network communication: We will implement the network communication protocol for the block fetcher within the next four weeks.
Handle errors and exceptions: We will implement error handling and exception handling for the block fetcher within the next six weeks.
Test and validate: We will thoroughly test and validate the local block fetcher within the next eight weeks.

Q: What is the next step after implementing the local block fetcher?

A: Once the local block fetcher is implemented, we will integrate it with the state root service, ensuring that it works correctly and efficiently. We will also thoroughly test and validate the local block fetcher in the context of the state root service, ensuring that it meets the required specifications.

Conclusion

In this article, we have addressed some of the frequently asked questions related to porting the block fetcher from network-watchtower. By creating a local implementation, we can ensure that the block fetcher works seamlessly with the current version of fuel-core-types and can be reused in network-watchtower once it is released. We will continue to provide updates on the progress of this project and will address any additional questions that may arise.