erigontech / erigontech/silkworm

architecture: infra should not depend on interfaces

Open
#2,448 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
318
Forks
84
PR merge metrics
No merged PRs in 30d

Description

infra is a collection of generic low level components.
interfaces contains code generated from .proto files for each of the GRPC services we implement

currently infra depends on interfaces for the following reasons:
1. client_context_pool_test and call_test depend on kv.proto as a service example to do the calls against
2. mock fix 24351: extra mocks added on top of existing generated mocks to fix an bug
3. version.hpp: defines versions of each service and helpers to call rpc Version method (it exists on all services)
4. conversion.hpp: defines convertions between numeric types from types.proto (e.g. ::types::H256 and intx::uint256, types::H160 and evmc::address etc.)

Logically each generated interface is a requirement only for each particular service client/server implementation. interfaces should be decoupled from infra, otherwise since everything depends on infra everything ingests low level details about all existing services.

Short term:
1. move tests to a higher level module, e.g. a module that implements KV server/client.
2. generate mock fix 24351 mocks within interfaces (or update grpc to fix 24351)
3. version.hpp: the methods are only used in daemon.cpp Daemon::run_checklist(), so wait_for_xxx_protocol_check helper methods could be moved to rpc. The actual version number constants should be moved to the implementation of each service. ProtocolVersion struct can and wait_for_protocol_check template be kept in infra.
4. conversion.hpp: move to a separate library that depends on types.proto (types.pb.h) and implements conversions. This could be a sub-library of infra.

Long term:
Instead of all services being generated in one place (interfaces). We could refactor cmake code gen functions to be able to work with any service .proto with details about a particular service provided as inputs. Using these functions the actual code gen can be used in other modules. Each implementation module defines targets like silkworm_interfaces_xxx for internal use. For example, sentry defines silkworm_interfaces_sentry, which is then used for sentry client/server impls.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.