chore(node-core): decouple runtime and app module #1438
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
plan:
New: |
|
wait is ur plan to have two modules then? or have the app call our runtime for Finalize Block ns tuff? |
WalkthroughThe changes update and expand the capabilities of the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (13)
- mod/node-core/pkg/builder/builder.go (2 hunks)
- mod/node-core/pkg/builder/creator.go (4 hunks)
- mod/node-core/pkg/builder/empty_components.go (1 hunks)
- mod/node-core/pkg/builder/extended_options.go (1 hunks)
- mod/node-core/pkg/components/chain_service.go (1 hunks)
- mod/node-core/pkg/components/middleware.go (3 hunks)
- mod/node-core/pkg/components/module/depinject.go (2 hunks)
- mod/node-core/pkg/components/module/module.go (2 hunks)
- mod/node-core/pkg/components/runtime.go (3 hunks)
- mod/node-core/pkg/components/storage.go (3 hunks)
- mod/node-core/pkg/components/types.go (1 hunks)
- mod/node-core/pkg/components/validator_service.go (1 hunks)
- mod/runtime/pkg/runtime/runtime.go (5 hunks)
Additional comments not posted (18)
mod/node-core/pkg/components/module/depinject.go (2)
46-47: The addition ofABCIFinalizeBlockMiddlewareandABCIFinalizeBlockMiddlewareinModuleInputstruct aligns with the PR's objectives to enhance modularity and direct middleware routing.
59-62: The updatedProvideModulefunction correctly integrates the new middleware components into the module setup, supporting the decoupling and direct middleware routing.mod/node-core/pkg/components/types.go (1)
34-62: The updated type aliases intypes.gocorrectly reflect the new modular architecture and ensure that each component is properly parameterized according to the new system design.mod/node-core/pkg/builder/extended_options.go (1)
37-67: The updates to the handler setting functions inextended_options.gocorrectly implement the decoupling fromcosmos-sdk/typesand enhance the system's modularity and flexibility.mod/node-core/pkg/components/runtime.go (1)
57-60: TheProvideRuntimefunction has been correctly updated to build theBeaconKitRuntimewith the new type parameters and dependencies, supporting the system's new modular design.mod/node-core/pkg/builder/creator.go (1)
Line range hint
36-92: Ensure that all new components and middleware are correctly integrated and initialized.Verification successful
The search results indicate that the
AppCreatorfunction is defined inmod/node-core/pkg/builder/creator.goand is used inmod/node-core/pkg/builder/builder.goandmod/cli/pkg/commands/cometbft/cometbft.go.To verify that all new components and middleware are correctly integrated and initialized, we need to examine these files for proper usage and ensure there are no runtime errors or misconfigurations.
Let's proceed by inspecting the specific lines in the files where
AppCreatoris used to verify the integration and initialization.
The search results show that
AppCreatoris integrated into the command setup and enhancement inmod/node-core/pkg/builder/builder.goand is used to create commands inmod/cli/pkg/commands/cometbft/cometbft.go. These usages suggest thatAppCreatoris properly integrated into the command infrastructure.However, to ensure that all components and middleware are correctly initialized and there are no runtime errors, a deeper inspection of the initialization process and potential error handling is necessary. Specifically, we should check if the components like
emptyAppBuilder,emptyRuntime,emptyValidatorMiddleware, andemptyFinalizeBlockMiddlewareare correctly defined and initialized.Let's search for the definitions of these components to ensure they are properly set up.
The search results confirm that the components
emptyAppBuilder,emptyRuntime, andemptyValidatorMiddlewareare defined and initialized correctly inmod/node-core/pkg/builder/empty_components.go. However, the search did not return any results foremptyFinalizeBlockMiddleware.To ensure that
emptyFinalizeBlockMiddlewareis correctly defined and initialized, we should search for its definition again, possibly with a slight variation in the function name or pattern to capture any potential discrepancies.
The search results confirm that all the components and middleware, including
emptyAppBuilder,emptyRuntime,emptyValidatorMiddleware, andemptyFinalizeBlockMiddlware, are correctly defined and initialized inmod/node-core/pkg/builder/empty_components.go.This thorough verification indicates that the components and middleware are correctly integrated and initialized within the
AppCreatorfunction.
emptyAppBuilderis defined and returns a newsdkruntime.AppBuilder.emptyRuntimeis defined and returns a newruntime.BeaconKitRuntime.emptyValidatorMiddlewareis defined and returns a newmiddleware.ValidatorMiddleware.emptyFinalizeBlockMiddlwareis defined and returns a newmiddleware.FinalizeBlockMiddleware.Based on this evidence, the review comment's concern about ensuring the correct integration and initialization of new components and middleware has been addressed.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all new components and middleware are correctly integrated. # Test: Search for the function usage. Expect: Proper initialization and no runtime errors. rg --type python $'AppCreator'Length of output: 60
Script:
#!/bin/bash # Search for the definition of the AppCreator function in Go files ast-grep --lang go --pattern $'func (nb *NodeBuilder[NodeT]) AppCreator($_, $_, $_, $_) NodeT { $$$ }' # Search for the usage of the AppCreator function across the codebase rg 'AppCreator' --type goLength of output: 4352
Script:
#!/bin/bash # Display the lines around the usage of AppCreator in mod/node-core/pkg/builder/builder.go rg -C 5 'AppCreator' mod/node-core/pkg/builder/builder.go # Display the lines around the usage of AppCreator in mod/cli/pkg/commands/cometbft/cometbft.go rg -C 5 'AppCreator' mod/cli/pkg/commands/cometbft/cometbft.goLength of output: 594
Script:
#!/bin/bash # Search for the definition of emptyAppBuilder ast-grep --lang go --pattern $'func emptyAppBuilder() $_ { $$$ }' # Search for the definition of emptyRuntime ast-grep --lang go --pattern $'func emptyRuntime() $_ { $$$ }' # Search for the definition of emptyValidatorMiddleware ast-grep --lang go --pattern $'func emptyValidatorMiddleware() $_ { $$$ }' # Search for the definition of emptyFinalizeBlockMiddleware ast-grep --lang go --pattern $'func emptyFinalizeBlockMiddleware() $_ { $$$ }'Length of output: 2234
Script:
#!/bin/bash # Search for the definition of emptyFinalizeBlockMiddleware with a slight variation in the function name or pattern ast-grep --lang go --pattern $'func emptyFinalizeBlockMiddlware() $_ { $$$ }'Length of output: 643
mod/node-core/pkg/components/validator_service.go (1)
53-53: Ensure that the newStorageBackendtype is correctly integrated and utilized within the validator service.mod/node-core/pkg/components/storage.go (1)
53-53: Verify that the newBackendtype is correctly integrated and utilized across the application.Verification successful
The search results indicate that the
Backendtype is widely integrated and utilized across various files in the codebase. This includes its usage in type definitions, function parameters, and return types. The integration appears consistent and comprehensive.
mod/node-core/pkg/components/storage.gomod/node-api/backend/backend.gomod/node-api/server/handlers/beacon.gomod/runtime/pkg/runtime/types.gomod/runtime/pkg/runtime/runtime.gomod/runtime/pkg/runtime/middleware/validator.gomod/runtime/pkg/runtime/middleware/types.gomod/node-core/pkg/components/validator_service.gomod/node-core/pkg/components/types.gomod/node-core/pkg/builder/empty_components.gomod/node-core/pkg/components/runtime.gomod/node-core/pkg/components/middleware.gomod/node-core/pkg/components/chain_service.gomod/node-core/pkg/components/storage/storage.gomod/node-core/pkg/components/keyring.gomod/node-core/pkg/components/defaults.gomod/node-core/pkg/components/client_context.gomod/node-api/main.gomod/node-api/backend/beacon.gomod/node-api/backend/rewards.gomod/node-api/backend/mock.gomod/execution/pkg/deposit/contract.abigen.gomod/execution/pkg/deposit/contract.gomod/beacon/validator/types.gomod/beacon/blockchain/service.gomod/beacon/blockchain/types.gomod/beacon/validator/service.goThe integration of the
Backendtype appears to be thorough and consistent throughout the codebase.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the new `Backend` type is correctly integrated. # Test: Search for the type usage. Expect: Correct integration and no runtime errors. rg --type python $'Backend'Length of output: 57
Script:
#!/bin/bash # Description: Verify that the new `Backend` type is correctly integrated. # Test: Search for the type usage in Go files. Expect: Correct integration and no runtime errors. rg --type go 'Backend'Length of output: 7085
mod/node-core/pkg/components/middleware.go (1)
49-49: Ensure that the newBackendtype and middleware components are correctly integrated and utilized across the application.Also applies to: 65-65, 96-96
Verification successful
The search results indicate that the
Backendtype and middleware components are extensively integrated into various parts of the codebase, including themod/node-core/pkg/components/middleware.gofile. The integration appears to be thorough, with multiple references and implementations across different files.
- Key locations:
mod/runtime/pkg/runtime/types.gomod/runtime/pkg/runtime/runtime.gomod/runtime/pkg/runtime/middleware/validator.gomod/runtime/pkg/runtime/middleware/types.gomod/node-api/backend/mock.gomod/node-api/backend/rewards.gomod/node-api/backend/beacon.gomod/node-api/backend/backend.gomod/node-core/pkg/components/types.gomod/node-core/pkg/components/validator_service.gomod/node-core/pkg/components/storage.gomod/node-core/pkg/components/runtime.gomod/node-core/pkg/components/middleware.gomod/node-core/pkg/components/chain_service.gomod/node-core/pkg/components/storage/storage.gomod/node-core/pkg/components/keyring.gomod/node-core/pkg/builder/empty_components.gomod/node-core/pkg/components/defaults.gomod/node-core/pkg/components/client_context.gomod/node-core/pkg/builder/config.gomod/node-api/main.gomod/node-api/server/handlers/handler.gomod/node-api/server/handlers/beacon.gomod/execution/pkg/deposit/contract.gomod/execution/pkg/deposit/contract.abigen.gomod/node-api/server/types/backend.gomod/beacon/blockchain/types.gomod/beacon/validator/types.gomod/beacon/blockchain/service.gomod/beacon/validator/service.goGiven the comprehensive integration, it is reasonable to conclude that the new
Backendtype and middleware components are correctly integrated into the application.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the new `Backend` type and middleware components are correctly integrated. # Test: Search for the type usage. Expect: Correct integration and no runtime errors. rg --type python $'Backend'Length of output: 57
Script:
#!/bin/bash # Description: Verify that the new `Backend` type and middleware components are correctly integrated. # Test: Search for the type usage in Go files. Expect: Correct integration and no runtime errors. rg --type go 'Backend'Length of output: 7085
mod/node-core/pkg/components/chain_service.go (1)
71-71: The change toStorageBackendtype enhances flexibility by allowing various backend implementations.mod/node-core/pkg/builder/empty_components.go (4)
40-54: Refined type specification inemptyStorageBackendenhances type safety and integration with the system.
57-66:emptyValidatorMiddlewarenow includes more specific type parameters, improving the middleware's integration and functionality.
70-75: The update toemptyFinalizeBlockMiddlewarewith detailed type parameters aligns with the system's needs for more precise type handling.
79-89:emptyRuntimefunction's updated type parameters enhance the runtime's compatibility and functionality within the system.mod/node-core/pkg/components/module/module.go (2)
49-62: Restructuring ofAppModuleto utilize middleware directly simplifies interactions and potentially enhances performance.
117-130: Ensure thatInitGenesisandEndBlockmethods are properly integrated with the new middleware structure.Would you like assistance in ensuring that these methods are correctly integrated with the new middleware structure?
mod/runtime/pkg/runtime/runtime.go (1)
122-125: Updates toBeaconKitRuntimeconstructor enhance component integration and configurability.mod/node-core/pkg/builder/builder.go (1)
96-98: The injection of empty middlewares here is noted. Can you confirm if this is a temporary measure during the transition phase of the refactoring? It's essential to ensure that this approach aligns with the overall architectural goals of reducing coupling and enhancing modularity.
There was a problem hiding this comment.
Actionable comments posted: 2
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files ignored due to path filters (2)
go.work.sumis excluded by!**/*.summod/node-core/go.sumis excluded by!**/*.sum
Files selected for processing (8)
- mod/node-core/go.mod (1 hunks)
- mod/node-core/pkg/builder/builder.go (2 hunks)
- mod/node-core/pkg/builder/empty_components.go (1 hunks)
- mod/node-core/pkg/components/defaults.go (1 hunks)
- mod/node-core/pkg/components/middleware.go (5 hunks)
- mod/node-core/pkg/components/module/depinject.go (2 hunks)
- mod/node-core/pkg/components/module/module.go (2 hunks)
- mod/node-core/pkg/components/types.go (1 hunks)
Additional comments not posted (11)
mod/node-core/pkg/components/module/depinject.go (2)
46-46: This change aligns with the PR’s objectives to decouple middleware from direct runtime dependencies. Consider adding a comment explaining the role ofABCIMiddlewarein this context for better maintainability.
58-60: Correct implementation of dependency injection usingABCIMiddlewareto initializeAppModule. This encapsulates the middleware handling effectively.mod/node-core/pkg/components/defaults.go (1)
30-30: Addition ofProvideABCIMiddlewareto the default components list is appropriate and supports enhanced middleware handling. Verify its usage across the application to ensure it integrates smoothly with other components.mod/node-core/pkg/components/types.go (1)
34-67: The updated type definitions align with the architectural changes intended in the PR. Adding detailed comments to each type definition could enhance understanding and maintainability.mod/node-core/pkg/builder/empty_components.go (1)
38-80: Updated empty component functions correctly provide placeholders for the new architecture. Ensure these are properly utilized in testing or other dependency injection scenarios.Verification successful
The functions
emptyValidatorMiddleware,emptyFinalizeBlockMiddlware,emptyRuntime, andemptyAppBuilderare utilized increator.gowithin a dependency injection configuration block. This indicates they are likely used as placeholders for components in the application's architecture.
mod/node-core/pkg/builder/creator.go, lines 51-54Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of empty component functions across the application. # Test: Search for the usage of empty component functions. Expect: They should be utilized correctly in tests or dependency injection scenarios. rg --type go $'emptyValidatorMiddleware|emptyFinalizeBlockMiddlware|emptyRuntime|emptyAppBuilder'Length of output: 1074
Script:
#!/bin/bash # Description: Verify the correct usage of empty component functions in creator.go. # Test: Extract lines from creator.go where empty component functions are used. rg --type go --line-number --context 5 $'emptyValidatorMiddleware|emptyFinalizeBlockMiddlware|emptyRuntime|emptyAppBuilder' mod/node-core/pkg/builder/creator.goLength of output: 617
mod/node-core/pkg/components/module/module.go (2)
49-51: TheAppModulestruct now usesABCIMiddlewareto encapsulate middleware logic, enhancing modularity and separation of concerns.
56-59: The constructorNewAppModulecorrectly initializes theAppModulewith the newABCIMiddleware. This change aligns with the decoupling objectives of the PR.mod/node-core/pkg/components/middleware.go (3)
49-49: The introduction of theBackendtype inValidatorMiddlewareInputis a positive change that supports the decoupling effort by abstracting the storage backend details.
65-65: TheProvideValidatorMiddlewarefunction has been updated to use the new generic types and theBackendabstraction, which should enhance flexibility and maintainability.
96-96: TheProvideFinalizeBlockMiddlewarefunction has been correctly updated to align with the new middleware structure. This is consistent with the overall architecture improvements.mod/node-core/go.mod (1)
31-31: The updated version ofmod/runtimeensures compatibility with the new changes. It's important to validate that all necessary changes from the runtime module are included in this version.Verification successful
The commit history confirms that the changes from
mod/runtimeare included in the updated version. The modifications involve significant refactoring and renaming within themod/runtime/pkg/middlewaredirectory, ensuring consistency and improved structure.
- The
mod/runtime/pkg/runtime/middlewaredirectory has been renamed tomod/runtime/pkg/middleware.- Several middleware-related files were moved and refactored to align with the new directory structure.
- The updates also include the addition of
ABCIMiddlewareand its integration within themod/node-core/pkg/componentsmodule.These changes are consistent with the new version specified in the
go.modfile, ensuring that the necessary updates are reflected in the codebase.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Confirm all necessary changes from `mod/runtime` are included in the updated version. # Test: Compare the current `mod/runtime` version with the repository's commit history. Expect: All necessary changes are included. git diff v0.0.0-20240610210054-bfdc14c4013c v0.0.0-20240613210046-f9ac140054ec -- mod/runtimeLength of output: 152
Script:
#!/bin/bash # List all tags or revisions in the repository to identify the correct identifiers for comparison git tag --listLength of output: 843
Script:
#!/bin/bash # Search for the specific commit hashes in the repository to verify their existence and retrieve their details git show bfdc14c4013c git show f9ac140054ecLength of output: 14187
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (3)
- mod/node-core/pkg/builder/empty_components.go (1 hunks)
- mod/node-core/pkg/components/runtime.go (1 hunks)
- mod/runtime/pkg/runtime/runtime.go (1 hunks)
Additional comments not posted (5)
mod/node-core/pkg/components/runtime.go (2)
32-32: Type alias is correctly defined and matches the new modular architecture.
47-47: Ensure that all necessary components are initialized before this function is called, as it directly uses the inputs to constructBeaconKitRuntime.Verification successful
To ensure that all necessary components are initialized before the
ProvideRuntimefunction is called, we need to verify the initialization of each component used withinProvideRuntime.
To ensure all necessary components are initialized before the
ProvideRuntimefunction is called, we need to verify the initialization ofChainSpec,Logger, andServiceRegistry.
The results indicate that the components
ChainSpec,Logger, andServiceRegistryare indeed initialized in various parts of the codebase before theProvideRuntimefunction is invoked. Here are the relevant findings:
ChainSpecis initialized in multiple places, such as inProvideChainSpecand several other provider functions.Loggeris initialized and passed to various components, ensuring logging capabilities are set up.ServiceRegistryis constructed and populated with services, ensuring it is initialized properly before use.Given this information, it is clear that the necessary components are initialized before the
ProvideRuntimefunction is called.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all components required by `ProvideRuntime` are initialized before its invocation. # Test: Search for the function usage and check initialization. rg --type go 'ProvideRuntime' -A 5 -B 5Length of output: 1624
Script:
#!/bin/bash # Description: Verify that all components required by `ProvideRuntime` are initialized before its invocation. # Step 1: Identify the components required by `ProvideRuntime`. # Extract the parameters from `RuntimeInput` used within `ProvideRuntime`. rg 'type RuntimeInput struct' -A 10 mod/node-core/pkg/components/runtime.go # Step 2: Verify initialization of these components before calling `ProvideRuntime`. # Check for initialization of each component. rg 'ProvideRuntime' -A 5 -B 5Length of output: 1982
Script:
#!/bin/bash # Description: Verify initialization of components required by `ProvideRuntime`. # Step 1: Identify where `ChainSpec`, `Logger`, and `ServiceRegistry` are initialized. # Search for initialization of `ChainSpec`. rg 'ChainSpec' -A 5 -B 5 # Search for initialization of `Logger`. rg 'Logger' -A 5 -B 5 # Search for initialization of `ServiceRegistry`. rg 'ServiceRegistry' -A 5 -B 5Length of output: 150558
mod/runtime/pkg/runtime/runtime.go (2)
32-32: StructBeaconKitRuntimeis well-defined with clear, concise comments and appropriate field types.
47-47: Creation ofBeaconKitRuntimeis handled correctly. Ensure that the parameters passed are properly validated before this function is called.mod/node-core/pkg/builder/empty_components.go (1)
37-71: All functions correctly provide empty instances for dependency injection. This is useful for unit testing and when default values are needed. Ensure these functions are only used in appropriate contexts to avoid issues with uninitialized components.
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range comments (1)
mod/node-core/pkg/components/storage/storage.go (1)
[!TIP]
Codebase VerificationThe previous script successfully found test functions related to
BeaconState, but did not find any forAvailabilityStore,BeaconStore, andDepositStore. This indicates that there might be a lack of unit tests for these specific methods in theBackendstruct.
- Please ensure that unit tests are implemented for the following methods in the
Backendstruct:
AvailabilityStoreBeaconStoreDepositStoreAnalysis chain
Line range hint
103-135: The methodsAvailabilityStore,BeaconState,BeaconStore, andDepositStoreprovide clear and direct access to respective storage components. Ensure these methods are covered by unit tests to verify their functionality.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that unit tests cover new methods in Backend struct. # Test: Search for unit tests related to Backend struct methods. Expect: At least one test per method. rg --type go $'func Test.*Backend' tests/Length of output: 89
Script:
#!/bin/bash # Description: Verify that unit tests cover the methods in the Backend struct. # Test: Search for unit tests related to specific methods in the Backend struct. # We will look for test functions that mention the methods AvailabilityStore, BeaconState, BeaconStore, and DepositStore. methods=("AvailabilityStore" "BeaconState" "BeaconStore" "DepositStore") for method in "${methods[@]}"; do echo "Searching for tests covering method: $method" rg --type go "func Test.*${method}" doneLength of output: 1123
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files ignored due to path filters (1)
mod/runtime/go.sumis excluded by!**/*.sum
Files selected for processing (6)
- mod/node-core/pkg/builder/creator.go (4 hunks)
- mod/node-core/pkg/builder/empty_components.go (1 hunks)
- mod/node-core/pkg/components/defaults.go (2 hunks)
- mod/node-core/pkg/components/storage.go (3 hunks)
- mod/node-core/pkg/components/storage/storage.go (7 hunks)
- mod/runtime/go.mod (3 hunks)
Additional comments not posted (8)
mod/node-core/pkg/components/defaults.go (1)
30-30: Ensure that all components listed inDefaultComponentsWithStandardTypesare updated according to the new architecture and interfaces.Verification successful
All components listed in
DefaultComponentsWithStandardTypesare correctly defined and match the new architecture.
ProvideABCIMiddlewareis defined inmod/node-core/pkg/components/middleware.go.ProvideAvailabilityPruneris defined inmod/node-core/pkg/components/availability_store.go.ProvideAvailibilityStoreis defined inmod/node-core/pkg/components/availability_store.go.ProvideBlsSigneris defined inmod/node-core/pkg/components/signer.go.ProvideBlockFeedis defined inmod/node-core/pkg/components/block_feed.go.ProvideBlobProcessoris defined inmod/node-core/pkg/components/blobs.go.ProvideBlobProofVerifieris defined inmod/node-core/pkg/components/blobs.go.ProvideChainServiceis defined inmod/node-core/pkg/components/chain_service.go.ProvideChainSpecis defined inmod/node-core/pkg/components/chain_spec.go.ProvideConfigis defined inmod/node-core/pkg/components/config.go.ProvideDBManageris defined inmod/node-core/pkg/components/db_manager.go.ProvideDepositPruneris defined inmod/node-core/pkg/components/deposit_store.go.ProvideDepositServiceis defined inmod/node-core/pkg/components/deposit_service.go.ProvideDepositStoreis defined inmod/node-core/pkg/components/deposit_store.go.ProvideBeaconDepositContractis defined inmod/node-core/pkg/components/deposit_contract.go.ProvideEngineClientis defined inmod/node-core/pkg/components/engine.go.ProvideExecutionEngineis defined inmod/node-core/pkg/components/engine.go.ProvideFinalizeBlockMiddlewareis defined inmod/node-core/pkg/components/middleware.go.ProvideJWTSecretis defined inmod/node-core/pkg/components/jwt_secret.go.ProvideLocalBuilderis defined inmod/node-core/pkg/components/payload_builder.go.ProvideServiceRegistryis defined inmod/node-core/pkg/components/service_registry.go.ProvideStateProcessoris defined inmod/node-core/pkg/components/state_processor.go.ProvideStorageBackendis defined inmod/node-core/pkg/components/storage.go.ProvideTelemetrySinkis defined inmod/node-core/pkg/components/telemetry_sink.go.ProvideTrustedSetupis defined inmod/node-core/pkg/components/trusted_setup.go.ProvideValidatorMiddlewareis defined inmod/node-core/pkg/components/middleware.go.ProvideValidatorServiceis defined inmod/node-core/pkg/components/validator_service.go.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all components listed in `DefaultComponentsWithStandardTypes` match the new architecture. # Test: Search for each component's definition and ensure it matches the new architecture. rg --type go $'ProvideABCIMiddleware|ProvideAvailabilityPruner|ProvideAvailibilityStore|ProvideBlsSigner|ProvideBlockFeed|ProvideBlobProcessor|ProvideBlobProofVerifier|ProvideChainService|ProvideChainSpec|ProvideConfig|ProvideDBManager|ProvideDepositPruner|ProvideDepositService|ProvideDepositStore|ProvideBeaconDepositContract|ProvideEngineClient|ProvideExecutionEngine|ProvideFinalizeBlockMiddleware|ProvideJWTSecret|ProvideLocalBuilder|ProvideServiceRegistry|ProvideStateProcessor|ProvideStorageBackend|ProvideTelemetrySink|ProvideTrustedSetup|ProvideValidatorMiddleware|ProvideValidatorService'Length of output: 8153
mod/node-core/pkg/builder/creator.go (2)
24-24: Consider using specific imports instead of generic ones for clarity and to avoid potential conflicts.
90-91: Replacepanicwith more graceful error handling to improve the robustness of the application.mod/node-core/pkg/builder/empty_components.go (1)
41-51: Ensure that theemptyValidatorMiddlewarefunction returns an implementation that matches the updated middleware interfaces.Verification successful
The
emptyValidatorMiddlewarefunction appears to return the correct type based on the provided context and the extracted definition ofValidatorMiddleware.
- The type parameters in the function match the expected types in the
ValidatorMiddlewaredefinition:
*dastore.Store[*consensustypes.BeaconBlockBody]aligns withAvailabilityStoreT.*consensustypes.BeaconBlockaligns withBeaconBlockT.*consensustypes.BeaconBlockBodyaligns withBeaconBlockBodyT.Therefore, the implementation of the
emptyValidatorMiddlewarefunction is correct.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the `emptyValidatorMiddleware` returns the correct type. # Test: Search for the implementation of `ValidatorMiddleware` and ensure it matches the expected type. rg --type go $'ValidatorMiddleware'Length of output: 2356
Script:
#!/bin/bash # Description: Extract the definition and type parameters of ValidatorMiddleware. # Search for the definition of ValidatorMiddleware in the relevant file. rg --type go --context 10 'type ValidatorMiddleware' mod/runtime/pkg/middleware/validator.goLength of output: 816
mod/node-core/pkg/components/storage.go (1)
53-53: Verify that theProvideStorageBackendfunction correctly uses the updated types and interfaces for storage components.Verification successful
The
ProvideStorageBackendfunction appears to be correctly implemented using the updated types and interfaces. It takesStorageBackendInputand returns aBackendwhile correctly callingstorage.NewBackendwith the necessary types and dependencies.
mod/node-core/pkg/components/storage.go:51-68: Implementation ofProvideStorageBackend.mod/node-core/pkg/components/defaults.go: Usage of ProvideStorageBackend.The function seems to be correctly instantiated and used.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the correct use of types in `ProvideStorageBackend`. # Test: Search for the use of `ProvideStorageBackend` in the codebase to ensure it matches the updated types. rg --type go $'ProvideStorageBackend'Length of output: 407
Script:
#!/bin/bash # Description: Extract the implementation of `ProvideStorageBackend` and its usage. # Extract the implementation of `ProvideStorageBackend` from storage.go ast-grep --lang go --pattern $'func ProvideStorageBackend($_) $_ { $$$ }' mod/node-core/pkg/components/storage.go # Extract the usage of `ProvideStorageBackend` in defaults.go rg --type go 'ProvideStorageBackend' mod/node-core/pkg/components/defaults.goLength of output: 1405
mod/node-core/pkg/components/storage/storage.go (2)
44-56: Refined theAvailabilityStoreinterface to handle data availability and persistence more explicitly.
Line range hint
61-91: Updated theBackendstruct to integrate new type parameters for enhanced flexibility and type safety.mod/runtime/go.mod (1)
44-44: The addition ofgit.luolix.top/berachain/beacon-kit/mod/engine-primitivesas an indirect dependency should be justified by the usage within themod/runtimemodule. Verify this to ensure that the dependency is necessary.Verification successful
The previous script failed due to an incorrect path. Let's adjust the path to search within the correct directory structure.
The previous script did not find any usage of
engine-primitivesin themod/runtimedirectory. To ensure thorough verification, let's extend the search to the entire repository.
The search results indicate that the
engine-primitivesdependency is utilized across multiple files in various modules within the repository. This confirms that the addition ofgit.luolix.top/berachain/beacon-kit/mod/engine-primitivesas an indirect dependency in thego.modfile is necessary.
- Locations with usage of
engine-primitives:
mod/state-transition/pkg/core/types.gomod/state-transition/pkg/core/state_processor_payload.gomod/payload/pkg/builder/types.gomod/payload/pkg/builder/builder.gomod/state-transition/pkg/core/state/statedb.gomod/payload/pkg/builder/payload.gomod/payload/pkg/builder/attributes.gomod/node-core/pkg/components/payload_builder.gomod/node-core/pkg/components/types.gomod/node-core/pkg/components/storage.gomod/node-core/pkg/components/defaults.gomod/node-core/pkg/components/state_processor.gomod/node-core/pkg/components/storage/storage.gomod/engine-primitives/pkg/engine-primitives/attributes_test.gomod/engine-primitives/pkg/engine-primitives/withdrawal_test.gomod/engine-primitives/pkg/engine-primitives/withdrawal_ssz_test.gomod/engine-primitives/pkg/engine-primitives/mocks/built_execution_payload_env.mock.gomod/engine-primitives/pkg/engine-primitives/transactions_test.gomod/engine-primitives/pkg/engine-primitives/engine_test.gomod/engine-primitives/pkg/engine-primitives/requests_test.gomod/engine-primitives/pkg/engine-primitives/blobs_bundle_test.gomod/engine-primitives/pkg/engine-primitives/payload_env_test.gomod/execution/pkg/client/errors.gomod/execution/pkg/client/helpers.gomod/execution/pkg/client/eth.gomod/execution/pkg/client/engine.gomod/execution/pkg/client/ethclient/client.gomod/execution/pkg/client/ethclient/engine.gomod/execution/pkg/client/cache/cache_test.gomod/execution/pkg/client/cache/cache.gomod/execution/pkg/engine/metrics.gomod/execution/pkg/engine/engine.gomod/da/pkg/blob/factory.gomod/consensus-types/pkg/types/payload.gomod/consensus-types/pkg/types/payload_test.gomod/consensus-types/pkg/types/payload.json.gomod/consensus-types/pkg/types/payload.ssz.gomod/consensus-types/pkg/types/mocks/inner_execution_payload.mock.gomod/consensus-types/pkg/types/block_test.gomod/consensus-types/pkg/genesis/genesis.gomod/cli/pkg/commands/genesis/payload.gomod/beacon/validator/types.gomod/beacon/validator/propose.gomod/beacon/blockchain/receive.gomod/beacon/blockchain/types.gomod/beacon/blockchain/execution_engine.goScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the necessity of the newly added engine-primitives dependency in the runtime module. # Test: Search for usage of engine-primitives in the runtime module. Expect: At least one usage. rg --type go $'github.com/berachain/beacon-kit/mod/engine-primitives' src/mod/runtime/Length of output: 142
Script:
#!/bin/bash # Description: Verify the necessity of the newly added engine-primitives dependency in the runtime module. # Test: Search for usage of engine-primitives in the runtime module. Expect: At least one usage. rg --type go 'github.com/berachain/beacon-kit/mod/engine-primitives' mod/runtime/Length of output: 81
Script:
#!/bin/bash # Description: Verify the necessity of the newly added engine-primitives dependency across the entire repository. # Test: Search for usage of engine-primitives in the entire repository. Expect: At least one usage. rg --type go 'github.com/berachain/beacon-kit/mod/engine-primitives'Length of output: 7189
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (5)
- mod/node-core/pkg/builder/empty_components.go (1 hunks)
- mod/node-core/pkg/components/defaults.go (2 hunks)
- mod/node-core/pkg/components/middleware.go (2 hunks)
- mod/node-core/pkg/components/storage.go (1 hunks)
- mod/node-core/pkg/components/types.go (3 hunks)
Additional comments not posted (6)
mod/node-core/pkg/components/defaults.go (1)
29-29: Addition ofProvideABCIMiddlewareto the components list supports the PR's goal of enhancing modularity. Ensure all dependencies of this middleware are correctly configured.Verification successful
The implementation of
ProvideABCIMiddlewareinmiddleware.goappears to be correctly defined, and its usage is appropriately integrated intodefaults.go. This supports the modularity and decoupling goals of the PR.
mod/node-core/pkg/components/middleware.go:85: Implementation ofProvideABCIMiddleware.mod/node-core/pkg/components/defaults.go:29: Usage ofProvideABCIMiddleware.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all dependencies of `ProvideABCIMiddleware` are correctly configured. # Test: Search for the configuration of `ProvideABCIMiddleware`. Expect: Proper configuration in the codebase. rg --type go 'ProvideABCIMiddleware' | grep 'depinject'Length of output: 170
Script:
#!/bin/bash # Description: Locate the implementation of `ProvideABCIMiddleware` and examine its usage across the codebase. # Find the implementation of `ProvideABCIMiddleware` ast-grep --lang go --pattern 'func ProvideABCIMiddleware($_) $_' # Find all usages of `ProvideABCIMiddleware` in the codebase rg 'ProvideABCIMiddleware'Length of output: 841
mod/node-core/pkg/components/storage.go (1)
Line range hint
29-29: The changes in theProvideStorageBackendfunction align with the PR's objectives of decoupling the storage backend. Ensure the new backend setup integrates smoothly with other components.Verification successful
The
ProvideStorageBackendfunction is integrated into theDefaultComponentsWithStandardTypesfunction indefaults.go, which suggests it is part of the default component setup. This indicates that the new backend setup is integrated with other components as expected.
ProvideStorageBackendis included in the list of default components, showing it is part of the standard initialization process.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify integration of the new storage backend setup with other components. # Test: Search for usage of `ProvideStorageBackend`. Expect: Smooth integration in the codebase. rg --type go 'ProvideStorageBackend' | grep 'depinject'Length of output: 174
Script:
#!/bin/bash # Description: Search for all occurrences of `ProvideStorageBackend` to verify its integration with other components. # Search for all occurrences of `ProvideStorageBackend` in the codebase. rg 'ProvideStorageBackend'Length of output: 397
Script:
#!/bin/bash # Description: Display the contents of defaults.go to verify the integration of ProvideStorageBackend. # Display the contents of defaults.go cat mod/node-core/pkg/components/defaults.goLength of output: 2011
mod/node-core/pkg/components/middleware.go (1)
27-27: Introduction ofABCIMiddlewareand related changes support the PR's goal of enhancing modularity. Verify correct utilization of these new middleware components in the system.Also applies to: 84-90
Verification successful
The search results confirm that
ABCIMiddlewareis being provided, injected, and utilized within the codebase. Specifically, it is used in themodule.gofile for initializing and ending blocks, which indicates its integration into the application logic.
mod/node-core/pkg/components/module/module.go: Utilization ofABCIMiddlewareinFinalizeBlock.InitGenesisandFinalizeBlock.EndBlock.The integration appears to be consistent with the intended modularity enhancements.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify correct utilization of new middleware components. # Test: Search for usage of `ABCIMiddleware`. Expect: Correct utilization in the codebase. rg --type go 'ABCIMiddleware' | grep 'depinject'Length of output: 326
Script:
#!/bin/bash # Description: Verify actual usage of `ABCIMiddleware` in the code logic. # Test: Search for usage of `ABCIMiddleware` in the codebase. rg --type go 'ABCIMiddleware'Length of output: 1523
mod/node-core/pkg/builder/empty_components.go (1)
37-72: Addition of new empty component functions aligns with the PR's goals of enhancing flexibility and modularity. Verify that these placeholders are correctly used in scenarios where they are needed.Verification successful
The newly added empty component functions are correctly utilized in various parts of the codebase, particularly in
builder.goandcreator.go, ensuring they align with the intended modularity and flexibility goals of the PR.
emptyABCIMiddlewareis used inmod/node-core/pkg/builder/builder.go.emptyValidatorMiddlewareis used inmod/node-core/pkg/builder/creator.go.emptyAppBuilderis used inmod/node-core/pkg/builder/creator.go.emptyServiceRegistryis used inmod/node-core/pkg/builder/creator.go.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that new empty component functions are used correctly. # Test: Search for usage of new empty component functions. Expect: Correct usage in testing or other scenarios. rg --type go 'emptyABCIMiddleware|emptyValidatorMiddleware|emptyFinalizeBlockMiddleware|emptyAppBuilder|emptyServiceRegistry' | grep 'depinject'Length of output: 144
Script:
#!/bin/bash # Description: Verify that new empty component functions are used correctly. # Search for usage of emptyABCIMiddleware rg --type go 'emptyABCIMiddleware' # Search for usage of emptyValidatorMiddleware rg --type go 'emptyValidatorMiddleware' # Search for usage of emptyFinalizeBlockMiddleware rg --type go 'emptyFinalizeBlockMiddleware' # Search for usage of emptyAppBuilder rg --type go 'emptyAppBuilder' # Search for usage of emptyServiceRegistry rg --type go 'emptyServiceRegistry'Length of output: 1234
mod/node-core/pkg/components/types.go (2)
39-39: The updated import path aligns with the structural changes described in the PR. Good job on maintaining the consistency.
182-185: The introduction ofABCIMiddlewarestruct is a critical part of decoupling the runtime and app module. Please ensure that theFinalizeBlockMiddlewareandValidatorMiddlewaretypes are correctly implemented and that they match the expected interfaces for handling ABCI-specific operations.Consider documenting the responsibilities and interactions of
ABCIMiddlewarewithin the system to enhance understandability and maintainability.Verification successful
The
FinalizeBlockMiddlewareandValidatorMiddlewaretypes are not directly defined in themiddleware.gofile. Instead, they are returned by themiddleware.NewFinalizeBlockMiddlewareandmiddleware.NewValidatorMiddlewarefunctions, respectively. This confirms that the types are correctly referenced and utilized within theABCIMiddlewarestruct.
FinalizeBlockMiddlewareis provided bymiddleware.NewFinalizeBlockMiddleware.ValidatorMiddlewareis provided bymiddleware.NewValidatorMiddleware.No issues were found with the implementation of
ABCIMiddleware.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of middleware interfaces in `ABCIMiddleware`. # Test: Search for the implementation of `FinalizeBlockMiddleware` and `ValidatorMiddleware` in the codebase. Expect: Correct implementation details. ast-grep --lang go --pattern $'type $_ { FinalizeBlock *FinalizeBlockMiddleware Validator *ValidatorMiddleware }'Length of output: 463
Script:
#!/bin/bash # Description: Verify the definition of `FinalizeBlockMiddleware` and `ValidatorMiddleware`. # Search for the definition of `FinalizeBlockMiddleware`. ast-grep --lang go --pattern $'type FinalizeBlockMiddleware struct { $$$ }' # Search for the definition of `ValidatorMiddleware`. ast-grep --lang go --pattern $'type ValidatorMiddleware struct { $$$ }'Length of output: 149
Script:
#!/bin/bash # Description: Search for all type definitions in the Go codebase to locate `FinalizeBlockMiddleware` and `ValidatorMiddleware`. # Search for all type definitions and filter for `FinalizeBlockMiddleware`. ast-grep --lang go --pattern $'type $_ struct { $$$ }' | grep 'FinalizeBlockMiddleware' # Search for all type definitions and filter for `ValidatorMiddleware`. ast-grep --lang go --pattern $'type $_ struct { $$$ }' | grep 'ValidatorMiddleware'Length of output: 519
Script:
#!/bin/bash # Description: Display the contents of `middleware.go` to verify the definitions of `FinalizeBlockMiddleware` and `ValidatorMiddleware`. # Display the contents of `middleware.go`. cat ./mod/node-core/pkg/components/middleware.goLength of output: 2954
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range comments (2)
mod/node-core/pkg/builder/creator.go (1)
[!TIP]
Codebase VerificationConsider replacing
panicwith more robust error handling to improve the application's resilience and error reporting. This ensures that any errors during the initialization of components are logged appropriately, providing better diagnostics and avoiding abrupt termination.
- File:
mod/node-core/pkg/builder/creator.go- Lines: 68-98
- panic(err) + logger.Error("Failed to inject dependencies", "err", err) + return nil
- File:
mod/node-core/pkg/builder/creator.go- Lines: 68-98
- panic("goleveldb is not supported") + logger.Error("goleveldb is not supported") + return nil
- File:
mod/node-core/pkg/builder/creator.go- Lines: 68-98
- panic(err) + logger.Error("Failed to start runtime services", "err", err) + return nilAnalysis chain
Line range hint
36-96: Review the integration of middleware and error handling inAppCreator.Consider replacing
panicwith more robust error handling to improve the application's resilience and error reporting.- panic(err) + log.Fatal("Failed to start services: ", err)Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of middleware and runtime services in `AppCreator`. # Test: Search for the function usage and check for any errors in logs. rg --type go $'AppCreator'Length of output: 525
Script:
#!/bin/bash # Description: Examine the context of `AppCreator` usage in the identified files. # Extract 10 lines before and after the usage of `AppCreator` in each file for context. rg --type go --context 10 'AppCreator' mod/node-core/pkg/builder/builder.go rg --type go --context 10 'AppCreator' mod/cli/pkg/commands/root.go rg --type go --context 10 'AppCreator' mod/cli/pkg/commands/cometbft/cometbft.goLength of output: 1733
mod/node-core/pkg/builder/builder.go (1)
Line range hint
1-1: Consider refactoring to reduce dependency injection complexity.The current setup requires a lot of manual supply of components for dependency injection, which could lead to high maintenance costs and potential errors. Consider using a factory pattern or a service locator to manage dependencies more efficiently.
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (7)
- mod/node-core/pkg/builder/builder.go (2 hunks)
- mod/node-core/pkg/builder/creator.go (3 hunks)
- mod/node-core/pkg/builder/extended_options.go (1 hunks)
- mod/node-core/pkg/components/types.go (2 hunks)
- mod/runtime/pkg/middleware/middleware.go (1 hunks)
- mod/runtime/pkg/middleware/types.go (2 hunks)
- mod/runtime/pkg/middleware/validator.go (1 hunks)
Additional comments not posted (8)
mod/runtime/pkg/middleware/middleware.go (1)
10-41: Well-structuredABCIMiddlewaredefinition.The use of generics here enhances flexibility and reusability by accommodating various types, which aligns well with the decoupling objectives of the PR.
mod/node-core/pkg/builder/extended_options.go (4)
41-46: Well-implemented handler setup inWithPrepareProposal.This function correctly abstracts the setting of the prepare proposal handler, promoting modularity and clean code practices.
49-54:WithProcessProposalcorrectly abstracts the process proposal handler setup.This promotes clean separation of concerns and enhances the configurability of the base application.
57-62: Proper implementation ofWithPreBlocker.This function is a good example of how to extend base application functionalities in a modular fashion.
33-38: Ensure correct functionality ofWithCometParamStore.Verification successful
Let's review the usage of
WithCometParamStoreincreator.goto ensure it correctly sets the param store.
The context shows that
WithCometParamStoreis used within theNewBeaconKitAppinitialization alongside other handlers. This indicates it is part of the app setup process, which is a good sign. However, to ensure it is correctly integrated, we need to verify ifNewBeaconKitAppcorrectly utilizes the param store set byWithCometParamStore.
The
NewBeaconKitAppfunction initializes aBeaconAppand uses theappBuilderto build theruntime.Appwith the providedbaseAppOptions, which includesWithCometParamStore. This indicates that the param store should be correctly set within theruntime.App.Based on the gathered information,
WithCometParamStoreappears to be correctly integrated and utilized within the application initialization process.
WithCometParamStoreis used in theNewBeaconKitAppinitialization.NewBeaconKitAppbuilds theruntime.Appusing the providedbaseAppOptions, which includesWithCometParamStore.Thus, the functionality of
WithCometParamStoreseems to be correctly implemented.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that `WithCometParamStore` correctly sets the param store. # Test: Search for the function usage and check for any errors in logs. rg --type go $'WithCometParamStore'Length of output: 300
Script:
#!/bin/bash # Description: Review the context of `WithCometParamStore` usage in `creator.go`. # Extract 10 lines before and after the usage of `WithCometParamStore` in `creator.go`. rg --type go -A 10 -B 10 $'WithCometParamStore' mod/node-core/pkg/builder/creator.goLength of output: 732
Script:
#!/bin/bash # Description: Verify if `NewBeaconKitApp` correctly utilizes the param store set by `WithCometParamStore`. # Search for the definition of `NewBeaconKitApp` and extract relevant lines. rg --type go -A 20 -B 10 $'func NewBeaconKitApp'Length of output: 1690
mod/runtime/pkg/middleware/types.go (1)
36-49: Refinement ofBeaconStateinterface.The updated
BeaconStateinterface provides clear and specific methods for accessing state information, which aligns well with the decoupling and clarity objectives of the PR.mod/node-core/pkg/components/types.go (1)
39-55: Type aliases and imports are correctly defined and aligned with the PR objectives.The type definitions in this file are well-structured and contribute to the modularity and clarity of the codebase.
mod/runtime/pkg/middleware/validator.go (1)
Line range hint
1-1: ProcessProposalHandler correctly implements proposal processing.The method effectively integrates with the chain service to process proposals, ensuring that beacon blocks and blobs are correctly handled.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (1)
- mod/runtime/pkg/middleware/middleware.go (1 hunks)
Additional comments not posted (3)
mod/runtime/pkg/middleware/middleware.go (3)
24-27: Imports are correctly utilized for the types and functions referenced in theABCIMiddlewarestruct.
30-60: TheABCIMiddlewarestruct is well-defined with appropriate generic type parameters. This struct effectively encapsulates the middleware responsibilities between ABCI and Beacon logic, promoting modularity and type safety.
32-47: The usage of generic type parameters in theABCIMiddlewarestruct is commendable. It ensures that the middleware can be adapted to various storage, block, and state types, enhancing the adaptability and reusability of the code.
Summary by CodeRabbit
New Features
ABCIMiddlewarestruct that enhances interaction between ABCI and Beacon logic.Enhancements
BeaconStateinterface for better access to beacon state information.Refactor
Chores