feat: EBOFinalityModule
#2
Conversation
GRT-14 Build EBOFinalityModule
The EBOFinalityModule will receive the response and emit the relevant events and allows an address to push an amendment |
src/contracts/EBOFinalityModule.sol
Outdated
| // uint256 _length = _response.chainIds.length; | ||
| // if (_length != _response.blocks.length) revert EBOFinalityModule_LengthMismatch(); | ||
|
|
||
| // for (uint256 _i; _i < _length; ++_i) { | ||
| // emit NewEpoch(_response.epoch, _response.chainIds[_i], _response.blocks[_i]); | ||
| // } |
There was a problem hiding this comment.
The Response struct would first need to be redeclared for this to work.
There was a problem hiding this comment.
For now, add a todo and just put a decode here as to how the response "could be" and then me modify
src/contracts/EBOFinalityModule.sol
Outdated
| /// @inheritdoc IModule | ||
| function validateParameters(bytes calldata _encodedParameters) | ||
| external | ||
| view | ||
| override(Module, IModule) | ||
| returns (bool _valid) |
There was a problem hiding this comment.
Will EBOFinalityModule override validateParameters()?
src/contracts/EBOFinalityModule.sol
Outdated
| // uint256 _length = _response.chainIds.length; | ||
| // if (_length != _response.blocks.length) revert EBOFinalityModule_LengthMismatch(); | ||
|
|
||
| // for (uint256 _i; _i < _length; ++_i) { | ||
| // emit NewEpoch(_response.epoch, _response.chainIds[_i], _response.blocks[_i]); | ||
| // } |
There was a problem hiding this comment.
For now, add a todo and just put a decode here as to how the response "could be" and then me modify
src/contracts/EBOFinalityModule.sol
Outdated
| _validateResponse(_request, _response); | ||
|
|
||
| // uint256 _length = _response.chainIds.length; | ||
| // if (_length != _response.blocks.length) revert EBOFinalityModule_LengthMismatch(); |
There was a problem hiding this comment.
We will have just one chain per response in the end
| } | ||
|
|
||
| contract EBOFinalityModule_Unit_FinalizeRequest is EBOFinalityModule_Unit_BaseTest { | ||
| struct FinalizeRequestParams { |
There was a problem hiding this comment.
This struct doesnt exist in the contract, maybe we shouldn't use it and create the happy path with each param
There was a problem hiding this comment.
At the moment of fuzz testing—specially when there are many parameters to fuzz—I like taking advantage of custom structs because:
- Their members can be adjusted out of the scope of the test case function (e.g., within the
happyPathmodifier) due to its variable being a memory pointer. - They work around stack too deep errors when the amount of parameters is large.
- They concentrate all the fuzzed parameters in one place, easing the burden of eventual maintenance.
- They minimize the visual load and improve readability of test case functions.
🤖 Linear
Closes GRT-14