fix(contracts-communication): deduplicate versioning libraries #2402
Conversation
WalkthroughThis comprehensive update introduces the Changes
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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## feat/interchain-versioning-library #2402 +/- ##
============================================================================
- Coverage 46.91836% 46.91493% -0.00344%
============================================================================
Files 383 383
Lines 29189 29189
Branches 83 83
============================================================================
- Hits 13695 13694 -1
Misses 14036 14036
- Partials 1458 1459 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Deploying sanguine-fe with
|
| Latest commit: |
523f1e3
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://87afd63c.sanguine-fe.pages.dev |
| Branch Preview URL: | https://feat-interchain-versioning-d.sanguine-fe.pages.dev |
![coderabbitai[bot]](https://github.com/avatars/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review Status
Configuration used: .coderabbit.yaml
Files selected for processing (18)
- packages/contracts-communication/contracts/InterchainClientV1.sol (5 hunks)
- packages/contracts-communication/contracts/InterchainDB.sol (3 hunks)
- packages/contracts-communication/contracts/libs/InterchainBatch.sol (1 hunks)
- packages/contracts-communication/contracts/libs/InterchainTransaction.sol (1 hunks)
- packages/contracts-communication/contracts/modules/InterchainModule.sol (3 hunks)
- packages/contracts-communication/test/InterchainClientV1.Base.t.sol (4 hunks)
- packages/contracts-communication/test/InterchainClientV1.Dst.t.sol (11 hunks)
- packages/contracts-communication/test/InterchainClientV1.GenericViews.t.sol (2 hunks)
- packages/contracts-communication/test/InterchainDB.Dst.t.sol (6 hunks)
- packages/contracts-communication/test/InterchainDB.Src.t.sol (4 hunks)
- packages/contracts-communication/test/harnesses/InterchainBatchLibHarness.sol (1 hunks)
- packages/contracts-communication/test/harnesses/InterchainTransactionLibHarness.sol (1 hunks)
- packages/contracts-communication/test/integration/ICIntegration.t.sol (1 hunks)
- packages/contracts-communication/test/integration/ICSetup.t.sol (3 hunks)
- packages/contracts-communication/test/libs/InterchainBatchLib.t.sol (1 hunks)
- packages/contracts-communication/test/libs/InterchainTransaction.t.sol (3 hunks)
- packages/contracts-communication/test/modules/SynapseModule.Destination.t.sol (9 hunks)
- packages/contracts-communication/test/modules/SynapseModule.Source.t.sol (5 hunks)
Additional Context Used
Additional comments not posted (77)
packages/contracts-communication/test/harnesses/InterchainBatchLibHarness.sol (3)
11-12: TheencodeBatchfunction correctly exposes theInterchainBatchLib.encodeBatchfunctionality for testing. It's good practice to ensure that the library's encoding logic is thoroughly tested, especially since encoding and decoding are critical for data integrity across contracts.
15-16: ThedecodeBatchfunction properly exposes theInterchainBatchLib.decodeBatchfunctionality. This is essential for validating that the encoded data can be accurately decoded back into its original structure. It's important to include comprehensive tests for various edge cases to ensure robustness.
19-20: ThedecodeBatchFromMemoryfunction is correctly implemented to test decoding of batches from memory usingInterchainBatchLib.decodeBatchFromMemory. This adds an additional layer of testing to ensure that decoding works as expected in different contexts (calldata vs. memory). Including tests that compare the results ofdecodeBatchanddecodeBatchFromMemorycould be beneficial for ensuring consistency.packages/contracts-communication/test/harnesses/InterchainTransactionLibHarness.sol (2)
25-26: TheencodeTransactionfunction correctly exposes theInterchainTransactionLib.encodeTransactionfunctionality for testing. This is crucial for ensuring that transactions are encoded correctly before being sent across chains. It's recommended to include tests that verify the encoded data against expected values to ensure accuracy.
29-30: ThedecodeTransactionfunction properly exposes theInterchainTransactionLib.decodeTransactionfunctionality. Testing the decoding process is essential for ensuring that transactions received from other chains are interpreted correctly. It would be beneficial to test decoding of transactions with various option and message lengths to cover more scenarios.packages/contracts-communication/contracts/libs/InterchainTransaction.sol (2)
56-57: TheencodeTransactionfunction has been simplified to useabi.encode, which is a straightforward and efficient way to encode structured data in Solidity. This change simplifies the encoding process and reduces the potential for errors. Ensure comprehensive testing is performed to validate the encoded data, especially for transactions with complex or nested structures.
60-61: ThedecodeTransactionfunction has been updated to useabi.decode, which matches the simplicity and efficiency of the encoding process. This ensures symmetry between encoding and decoding, which is crucial for data integrity. Testing should include various transaction payloads to ensure that decoding is accurate across all expected input types.packages/contracts-communication/contracts/libs/InterchainBatch.sol (3)
39-41: TheencodeBatchfunction has been updated to useabi.encode, which is a clean and efficient approach for encoding structured data. This change aligns with best practices for data encoding in Solidity. It's important to ensure that the encoding process is thoroughly tested, particularly for batches with varying sizes and contents.
44-46: ThedecodeBatchfunction now usesabi.decodefor decoding batch data from calldata. This simplification enhances readability and maintainability of the code. Comprehensive testing should be conducted to verify that batches are decoded correctly, especially when handling complex or large batches.
49-51: ThedecodeBatchFromMemoryfunction is correctly implemented to decode batch data from memory usingabi.decode. This addition ensures that the library can handle batch data in different contexts (calldata vs. memory). Testing for consistency betweendecodeBatchanddecodeBatchFromMemoryresults is recommended to ensure reliability.packages/contracts-communication/test/libs/InterchainBatchLib.t.sol (2)
51-54: Thetest_encodeBatch_roundTripfunction correctly tests the round-trip encoding and decoding ofInterchainBatchobjects usingencodeBatchanddecodeBatch. This is essential for ensuring data integrity. It's recommended to include various batch sizes and contents in the tests to cover more edge cases.
57-60: Thetest_encodeBatchFromMemory_roundTripfunction tests the round-trip encoding and decoding ofInterchainBatchobjects usingencodeBatchanddecodeBatchFromMemory. This adds valuable coverage for different contexts (calldata vs. memory). Expanding the test cases to include batches with complex structures would further ensure the robustness of the encoding and decoding logic.packages/contracts-communication/test/InterchainClientV1.GenericViews.t.sol (1)
53-54: Thetest_encodeTransactionfunction has been updated to useVersionedPayloadLibHarnessfor extracting the version and payload, which is a good practice for ensuring that the versioning logic is correctly applied. It's important to test with various transaction versions to ensure compatibility and correct decoding across version changes.packages/contracts-communication/test/libs/InterchainTransaction.t.sol (2)
47-49: Thetest_encodeTransaction_roundTripfunction correctly tests the round-trip encoding and decoding ofInterchainTransactionobjects. This is crucial for ensuring the integrity of transactions across chains. Including a variety of transaction types and sizes in the tests would enhance coverage and robustness.
62-62: Thetest_payloadSizefunction has been updated to include theVersionedPayloadLibHarnessin the expected size calculation, which is important for ensuring that the payload size calculation accounts for versioning overhead. Testing with various option and message lengths is recommended to validate the accuracy of the payload size calculation across different scenarios.packages/contracts-communication/contracts/modules/InterchainModule.sol (2)
29-29: The use ofversionedBatch.getPayload()inrequestBatchVerificationfor decoding batches is a good practice, as it ensures that the versioning logic is applied correctly. It's important to test this functionality with batches of different versions to ensure backward compatibility and correct handling of versioned data.
57-57: The use ofversionedBatch.getPayloadFromMemory()in_verifyBatchfor decoding batches from memory aligns with the changes inrequestBatchVerificationand ensures consistency in handling versioned data. Testing with various batch sizes and structures is recommended to ensure the robustness of the decoding process.packages/contracts-communication/test/integration/ICSetup.t.sol (3)
15-16: The addition ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessimports is appropriate for testing purposes, ensuring that the contract can interact with these libraries in a controlled environment.
39-40: The declaration ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessas public variables is correctly done. This allows other contracts or tests to interact with these harness instances, facilitating comprehensive testing scenarios.
64-74: ThedeployLibraryHarnessesfunction is well-implemented. It correctly initializes thebatchLibHarnessandpayloadLibHarnessby deploying new instances of their respective harness contracts. This setup is crucial for testing the integration with these libraries in a controlled manner.packages/contracts-communication/test/InterchainClientV1.Base.t.sol (4)
12-13: The addition ofInterchainTransactionLibHarnessandVersionedPayloadLibHarnessimports is correctly done to facilitate testing with these libraries in a controlled environment. This ensures that the contract can interact with these libraries for testing purposes.
31-32: The declaration ofInterchainTransactionLibHarnessandVersionedPayloadLibHarnessas public variables is appropriate. This allows other contracts or tests to interact with these harness instances, which is beneficial for creating comprehensive testing scenarios.
55-56: The initialization oftxLibHarnessandpayloadLibHarnessin the constructor is correctly implemented. Deploying new instances of their respective harness contracts is crucial for testing the integration with these libraries in a controlled manner.
239-240: The modification of thegetEncodedTxfunction to usepayloadLibHarnessfor encoding the versioned payload is correctly implemented. This change ensures that the function can leverage the testing harness forVersionedPayloadLib, facilitating more controlled and flexible testing scenarios.packages/contracts-communication/contracts/InterchainDB.sol (3)
10-10: The import ofVersionedPayloadLibis correctly added to enable the handling of versioned payloads within theInterchainDBcontract. This library is essential for encoding and decoding versioned data, aligning with the contract's requirements for version compatibility.
71-75: The modification in theverifyRemoteBatchfunction to useVersionedPayloadLibfor decoding the versioned batch is correctly implemented. This change ensures that the function can handle versioned payloads appropriately, checking the version compatibility before proceeding with the batch verification.
224-227: The changes in therequestBatchVerificationfunction to useVersionedPayloadLibfor encoding the versioned batch are correctly implemented. This ensures that the function can create versioned payloads in a standardized manner, facilitating interoperability and version compatibility in batch verification requests.packages/contracts-communication/test/modules/SynapseModule.Source.t.sol (4)
10-11: The addition ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessimports is correctly done to facilitate testing with these libraries in a controlled environment. This ensures that the contract can interact with these libraries for testing purposes.
19-20: The declaration ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessas public variables is appropriate. This allows other contracts or tests to interact with these harness instances, which is beneficial for creating comprehensive testing scenarios.
47-48: The initialization ofbatchLibHarnessandpayloadLibHarnessin the constructor is correctly implemented. Deploying new instances of their respective harness contracts is crucial for testing the integration with these libraries in a controlled manner.
64-66: The addition of thegetVersionedBatchfunction to handle encoding withbatchLibHarnessandpayloadLibHarnessis correctly implemented. This change ensures that the function can leverage the testing harness forInterchainBatchLibandVersionedPayloadLib, facilitating more controlled and flexible testing scenarios.packages/contracts-communication/test/integration/ICIntegration.t.sol (2)
239-239: Changing the visibility of thegetEthSignedBatchHashfunction frompuretoviewis appropriate given the function now indirectly interacts with state through thegetModuleBatchfunction. This adjustment aligns with Solidity's visibility and mutability rules.
244-246: The update to thegetModuleBatchfunction to usepayloadLibHarnessandbatchLibHarnessfor encoding the versioned payload and batch is correctly implemented. This change ensures that the function can leverage the testing harness forVersionedPayloadLibandInterchainBatchLib, facilitating more controlled and flexible testing scenarios.packages/contracts-communication/test/modules/SynapseModule.Destination.t.sol (9)
11-12: The introduction ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessharnesses is a good practice for isolating and testing the functionality of these libraries in a controlled environment. This approach facilitates more focused and effective testing of the versioning logic.
22-23: The instantiation ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessas public variables allows for easy access and manipulation in test cases. This setup is appropriate for testing purposes, ensuring that the harnesses can be utilized across different test scenarios within this file.
39-39: The declaration ofmockVersionedBatchas a bytes array without initialization is acceptable in this context, as it is later assigned a value in thesetUpfunction usinggetVersionedBatch. This lazy initialization pattern is suitable for test setups where certain values depend on the execution of initialization logic.
59-61: Instantiating the harnesses within thesetUpfunction is a standard practice in testing. It ensures that each test starts with a fresh instance of the necessary components, thereby avoiding unintended side effects from previous tests. This setup contributes to the reliability and independence of the tests.
60-60: The assignment ofmockVersionedBatchusinggetVersionedBatch(mockBatch)within thesetUpfunction is a critical step for preparing the test environment. It ensures that a versioned batch is available for tests that require it, encapsulating the versioning logic in a reusable function. This approach enhances the modularity and maintainability of the test setup.
124-126: ThegetVersionedBatchfunction encapsulates the logic for encoding aInterchainBatchinto a versioned payload using theVersionedPayloadLibHarness. This function is a key component of the test setup, enabling the simulation of versioned batch processing. The use of a harness for encoding ensures that the versioning logic can be tested in isolation, which is beneficial for identifying and addressing issues specific to version encoding.
177-177: The test casetest_verifyRemoteBatch_zeroSignatures_revertNotEnoughSignaturescorrectly simulates a scenario where a versioned batch is verified with zero signatures, expecting a revert due to not meeting the minimum signature requirement. This test is essential for ensuring the robustness of the batch verification logic against invalid inputs.
214-218: The test cases for verifying remote batches with various signature scenarios (valid, invalid, sorted, unsorted, duplicates) are comprehensive and cover a wide range of possible inputs. These tests are crucial for ensuring the integrity and security of the batch verification process, validating that only correctly signed and ordered signatures allow a batch to be verified successfully.
316-319: The test casetest_verifyRemoteBatch_revertSameChainIdeffectively checks the logic for preventing the verification of a batch originating from the same chain as the destination. This test ensures that the system adheres to the intended behavior of only allowing interchain transactions between distinct chains, which is a fundamental aspect of the interchain communication protocol.packages/contracts-communication/contracts/InterchainClientV1.sol (5)
19-19: The addition ofVersionedPayloadLibimport is a crucial step for enabling versioned payload handling within theInterchainClientV1contract. This library provides the necessary functionality for encoding and decoding versioned data, which is integral to the contract's operation in handling versioned interchain transactions.
30-30: UtilizingVersionedPayloadLibwith ausingstatement for bytes simplifies the syntax for calling library functions on byte arrays. This approach enhances code readability and maintainability by allowing direct invocation of versioning functions on byte array variables, which are commonly used to represent encoded data.
214-218: The refactoredencodeTransactionfunction now leveragesVersionedPayloadLibto encode interchain transactions with a version prefix. This modification is essential for ensuring compatibility across different versions of interchain transactions, facilitating future upgrades and interoperability within the interchain ecosystem. The use ofCLIENT_VERSIONas the version parameter ensures consistency and traceability of transaction versions.
253-253: The calculation oftransactionIdusing the encoded versioned transaction ensures that the version information is included in the transaction identifier. This approach enhances the robustness of transaction tracking and verification by incorporating version data, which is critical for distinguishing between transactions across different protocol versions.
370-379: The_assertCorrectVersionfunction plays a vital role in validating the version of incoming transactions. By checking againstCLIENT_VERSION, it ensures that only transactions matching the current client version are processed. This version assertion mechanism is crucial for maintaining protocol compatibility and preventing the execution of transactions that are not aligned with the contract's expected version.packages/contracts-communication/test/InterchainDB.Dst.t.sol (11)
13-14: The introduction ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessharnesses is a good practice for isolating and testing the functionality of these libraries in a controlled environment. This approach facilitates more focused and effective testing of the versioning logic.
30-31: The instantiation ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessas public variables allows for easy access and manipulation in test cases. This setup is appropriate for testing purposes, ensuring that the harnesses can be utilized across different test scenarios within this file.
46-47: Instantiating the harnesses within thesetUpfunction is a standard practice in testing. It ensures that each test starts with a fresh instance of the necessary components, thereby avoiding unintended side effects from previous tests. This setup contributes to the reliability and independence of the tests.
51-57: The use ofgetVersionedBatchin thesetUpfunction to prepare versioned batches for verification tests is a key step in setting up a comprehensive test environment. This approach ensures that the tests accurately reflect the handling of versioned data, which is critical for validating the system's behavior in real-world scenarios.
60-61: ThegetVersionedBatchfunction encapsulates the logic for encoding aInterchainBatchinto a versioned payload using theVersionedPayloadLibHarness. This function is a key component of the test setup, enabling the simulation of versioned batch processing. The use of a harness for encoding ensures that the versioning logic can be tested in isolation, which is beneficial for identifying and addressing issues specific to version encoding.
64-66: TheverifyBatchfunction, which now operates on versioned batches, is crucial for simulating the verification process in a test environment. By incorporating versioned data, this function allows for the testing of batch verification logic under conditions that closely mimic actual operational scenarios, ensuring the robustness and accuracy of the verification process.
171-172: The adjustment to handle versioned batches inassertCorrectInitialVerificationTimeand other test helper functions is an important update that aligns the test logic with the introduction of versioning. This change ensures that the tests accurately assess the system's behavior when processing versioned data, which is essential for validating the integrity and functionality of the versioning mechanism.
235-237: The test casetest_verifyBatch_new_emitsEventcorrectly simulates the verification of a new versioned batch, expecting an event to be emitted. This test is essential for ensuring that the system behaves as expected when processing new versioned batches, including the correct emission of events to signal successful verification.
325-327: The test casetest_verifyBatch_revert_conflict_sameModuleeffectively simulates a scenario where a versioned batch conflicts with an existing batch verified by the same module, expecting a revert. This test ensures that the system correctly handles conflicts between versioned batches, maintaining data integrity and preventing inconsistent state.
333-335: The test casetest_verifyBatch_revert_sameChainIdchecks for the correct handling of an attempt to verify a batch originating from the same chain, expecting a revert. This test ensures that the system adheres to the intended behavior of disallowing self-referential batch verification, which is crucial for maintaining the integrity of interchain communication.
341-342: The test casetest_verifyBatch_revert_wrongVersionis designed to simulate the verification of a batch with an incorrect version, expecting a revert. This test is critical for ensuring that the system robustly enforces version compatibility, rejecting batches that do not match the expected version. This behavior is essential for maintaining protocol integrity and preventing the processing of incompatible or potentially malicious data.packages/contracts-communication/test/InterchainDB.Src.t.sol (3)
14-15: The addition ofInterchainBatchLibHarnessandVersionedPayloadLibHarnessimports aligns with the PR's objective to streamline versioning functionalities. Ensure that these harnesses are properly implemented and tested as they play a crucial role in encoding and decoding versioned payloads and batches.
35-43: > 📝 NOTEThis review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [38-61]
The instantiation of
batchLibHarnessandpayloadLibHarnesswithin thesetUpfunction is correctly implemented. This setup is essential for testing the encoding and decoding functionalities of versioned payloads and batches using the newly integratedVersionedPayloadLib. It's important to ensure that these harnesses mimic the behavior of their production counterparts accurately for effective testing.
103-109: The modifications togetModuleCalldatato utilizepayloadLibHarnessandbatchLibHarnessfor encoding versioned payloads and batches are in line with the PR's objectives. It's crucial to verify that the encoded data meets the expected format and is compatible with the decoding process on the receiving end. Additionally, comprehensive testing of this functionality, including edge cases, will ensure robustness and prevent potential issues in production.packages/contracts-communication/test/InterchainClientV1.Dst.t.sol (16)
176-176: TheexecuteTransactionfunction has been refactored to takeencodedTxdirectly, which is a positive change for code clarity and efficiency. However, it's crucial to ensure that all tests correctly pass theencodedTxparameter and that it is properly constructed before being passed to this function.
212-213: The refactoring of test functions to retrieveencodedTxbefore callingexecuteTransactionenhances readability and maintainability. This change aligns with the PR's objective of streamlining versioning functionalities. Ensure thatencodedTxis correctly encoded in all test cases where this pattern is applied.
227-229: The usage ofencodedTxin thecheckHappyPathScenariofunction demonstrates the improved approach to handling transactions. It's important to verify thatencodedTxis correctly encoded and that theexecuteTransactionfunction is called with the appropriate parameters in all scenarios.
283-289: > 📝 NOTEThis review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [286-308]
In the
checkNotEnoughConfirmationsAandcheckNotEnoughConfirmationsABfunctions, the pattern of preparing a transaction, checking its executability, and then attempting execution is correctly followed. However, ensure that the logic for determining the number of required confirmations and the actual confirmations received is accurately implemented in these scenarios.
787-789: The testtest_interchainExecute_revert_srcChainNotRemotecorrectly simulates a scenario where the source chain ID is incorrectly set to the local chain ID. This is a good practice for testing edge cases and ensuring robust error handling in the contract.
796-798: Similarly, thetest_interchainExecute_revert_srcChainNotLinkedtest case ensures that the contract correctly handles scenarios where the source chain is not linked. This is crucial for maintaining the integrity of interchain transactions.
805-807: Thetest_interchainExecute_revert_dstChainIncorrecttest case checks for incorrect destination chain IDs, which is essential for preventing transactions from being executed on unintended chains. This test reinforces the contract's security by validating chain ID checks.
812-816: Thetest_interchainExecute_revert_emptyOptionstest case addresses the scenario of executing a transaction with empty options. It's important to ensure that the contract can handle such cases gracefully, potentially by reverting with a meaningful error message.
821-824: Thetest_interchainExecute_revert_invalidOptionsV0test case is crucial for ensuring that transactions with invalid options (incorrect version) are not executed. This helps maintain the integrity of the versioning system in the contract.
829-833: Thetest_interchainExecute_revert_invalidOptionsV1test case similarly checks for transactions with invalid options but focuses on a different version. This thorough testing of versioning is important for the contract's versioning logic.
839-841: Thetest_interchainExecute_revert_alreadyExecutedtest case ensures that the contract prevents the execution of transactions that have already been executed. This is a critical security measure to prevent duplicate transactions.
852-856: Thetest_interchainExecute_revert_withAirdrop_zeroMsgValuetest case checks the contract's handling of transactions with an airdrop option but a zero message value. This test is important for ensuring that the contract enforces the correct airdrop requirements.
867-871: Thetest_interchainExecute_revert_withAirdrop_lowerMsgValuetest case is crucial for verifying that the contract correctly handles cases where the message value is lower than required for the airdrop. This ensures that the airdrop logic is strictly enforced.
882-886: Thetest_interchainExecute_revert_withAirdrop_higherMsgValuetest case ensures that the contract can handle cases where the message value is higher than required for the airdrop. While not a critical issue, it's good to test for overpayment scenarios.
897-900: Thetest_interchainExecute_revert_noAirdrop_nonZeroMsgValuetest case checks for scenarios where a transaction without an airdrop option is executed with a non-zero message value. This test ensures that the contract correctly handles message value discrepancies.
913-915: Thetest_interchainExecute_revert_zeroRequiredResponsestest case is important for ensuring that the contract does not allow transactions with zero required responses. This test helps maintain the integrity of the response verification process.
ChiTimesChi
merged commit 269fcde
into
feat/interchain-versioning-library
ChiTimesChi
deleted the
feat/interchain-versioning-deduplicate-libraries
branch
* Scaffold `VersionedPayload` library * Implement basic encode/decode * Implement decoding in memory * Update Options versioning * Update AppConfig versioning * Use new version getter in Execution Service * Fix: decodeOptions is now view * Update tests * Regenerate `sin-executor` * Additional tests to mimic real usage * feat(contracts-communication): Interchain versioning for batches (#2390) * Implement Batch versioning * Scaffold versioned batch verification * Update tests with expected behavior for versioned batches * Complete versioned batch verification * feat(contracts-communication): Interchain versioning for transactions (#2393) * Implement Transaction versioning * Implement tests for versioned txs * Adjust integration tests * Implement client/tx versioning * Chore: cleanup deprecated functions * Chore: remove unused imports * Chore: `forge fmt` * fix(contracts-communication): deduplicate versioning libraries (#2402) * Bring back the vanilla encoding/decoding funcs * Deduplicate Batch library * Update DB and Module to use generic library * Update tests * Deduplicate Transaction library * Update Client to use generic library * Update tests * Adjust `verifyRemoteBatch` mock for Go tests * Regenerate `sin-executor` * Fix Go test * Regenerate `committee`
Description
Deduplicates versioning functions introduced in:
Summary by CodeRabbit
VersionedPayloadLibfor handling versioned payloads.