Hardhat-Polkadot: Matching Revive Responses To Hardhat Node

Dec 4, 2025 by Alex Johnson 60 views

Ensuring compatibility between different development environments is crucial for seamless testing and deployment in the blockchain space. This article delves into the intricacies of aligning transaction response formats between revive and Hardhat node within the hardhat-polkadot ecosystem. This is particularly important because Hardhat employs the Ethereum Development Runtime (EDR), which generates specific custom error responses for reverted dry-runs, while revive delivers responses adhering to the Geth standard. The discrepancies in these response formats can lead to test failures and inconsistencies, making standardization a key objective. Let's explore the challenges and potential solutions to bridge this gap.

The Challenge: Divergent Response Formats

When working with blockchain development tools, consistency in response formats is vital. Hardhat, a popular Ethereum development environment, utilizes the Ethereum Development Runtime (EDR). EDR produces custom error responses for reverted dry-runs. These responses differ significantly from those generated by revive, which aligns with the Geth standard. This divergence can cause friction, especially when tests are designed to expect a specific format. Let's examine the core of the problem with the help of concrete examples. Discrepancies in error response formats between different blockchain development environments like Hardhat and Geth (via revive) can significantly hinder the development and testing process. These inconsistencies often lead to test failures, increased debugging efforts, and a general slowdown in development cycles. One primary reason for these discrepancies is the use of different error-handling mechanisms and data structures. For instance, Hardhat, leveraging EDR (Ethereum Development Runtime), generates custom error responses specifically designed for reverted dry-runs. These responses include detailed information about the error, such as the error code, message, and additional data, often formatted in a nested structure. In contrast, revive, which adheres to the Geth standard, typically provides a simpler error response format. Geth-style responses usually include an error code, a generic message like "execution reverted," and the reverted data itself, without the detailed breakdown offered by Hardhat. This fundamental difference in error reporting complicates the process of writing consistent tests. When tests are designed to expect the Hardhat response format, they may fail when interacting with a revive-based environment, and vice versa. This necessitates conditional logic within tests to handle different response structures, adding complexity and potentially obscuring the core logic being tested. Moreover, the discrepancy extends beyond the structure of the error response to the content and specificity of the error messages. Hardhat's EDR often provides more descriptive error messages that include the reason for the revert, such as a specific custom error defined in the smart contract. This level of detail is invaluable for debugging and quickly identifying the root cause of issues. Geth-style responses, while functional, typically offer less granular information, making it harder to pinpoint the exact cause of a transaction failure. Addressing these inconsistencies is not merely a matter of cosmetic preference; it directly impacts the efficiency and reliability of blockchain development workflows. Standardizing error responses across different environments ensures that developers can write tests that are portable and consistent, reducing the overhead of environment-specific adjustments. This alignment also enhances the overall developer experience, making it easier to debug issues and maintain a high level of code quality across different platforms and tools.

Response Examples

To illustrate the differences, consider these examples:

Revive and Geth Response Format:

"error": {
        "code": 3,
        "data": "0x118cdaa70000000000000000000000003cd0a705a2dc65e5b1e1205896baa2be8a07c6e0",
        "message": "execution reverted"
}

Hardhat Response Format:

{
  "error": {
    "code": -32000,
    "message": "VM Exception while processing transaction: reverted with an unrecognized custom error (return data: 0x118cdaa700000000000000000000000070997970c51812dc3a010c7d01b50e0d17dc79c8)",
    "data": {
      "reason": {
        "Revert": "0x118cdaa700000000000000000000000070997970c51812dc3a010c7d01b50e0d17dc79c8"
      },
      "data": "0x118cdaa700000000000000000000000070997970c51812dc3a010c7d01b50e0d17dc79c8",
      "transactionHash": "0xb750ab3de4478d8e119f55080733da991ab505e0a5e69b8eb2b487bd609c4b19"
    }
  }
}

The Hardhat response is considerably more detailed, providing a structured breakdown of the error, including a reason, data, and the transaction hash. This level of detail is invaluable for debugging. The difference in structure and content highlights the core challenge: tests written expecting the Hardhat format may fail when run against a revive environment, and vice versa. This necessitates a solution to standardize these responses, ensuring consistency across different environments.

Impact on Testing

Tests often rely on specific error formats to assert the correct behavior of smart contracts. For instance, a test might check for a particular error code or a custom error message. When the response format differs, these tests can fail, leading to confusion and wasted time. One such example can be found in the scc-testing repository, where tests in AxelarExecutable.js expect the Hardhat response format. Addressing this discrepancy is crucial for maintaining test integrity and ensuring reliable contract behavior across different environments. The impact of divergent response formats on testing in blockchain development cannot be overstated. Testing is a cornerstone of smart contract development, ensuring that contracts behave as expected and that potential vulnerabilities are identified before deployment. When the error responses from different environments are inconsistent, the reliability and effectiveness of these tests are severely compromised. Specifically, tests often rely on specific error codes, messages, or data structures within the response to assert that a contract function behaves correctly under certain conditions. For example, a test might be designed to ensure that a specific custom error is returned when a user attempts an unauthorized action. If the environment under test returns errors in a different format—say, a Geth-style error instead of a Hardhat error—the test will fail, even if the contract logic is sound. This leads to false negatives, where the test incorrectly indicates a problem, or, conversely, false positives, where a real issue is masked by an unexpected error format. The problem is compounded by the fact that debugging such failures can be time-consuming and frustrating. Developers must first discern whether the failure is due to an actual contract bug or simply a mismatch in error formats. This adds overhead to the development process and can slow down the delivery of reliable software. Furthermore, inconsistent error formats make it harder to write portable tests that can be run across different environments and testing frameworks. Ideally, tests should be environment-agnostic, ensuring that the same tests can validate contract behavior regardless of the underlying blockchain implementation or development toolchain. When error responses vary significantly, achieving this portability becomes a significant challenge. To mitigate these issues, it's crucial to standardize error responses across different development environments. This can involve modifying the error reporting mechanisms of specific tools or implementing translation layers that convert errors into a common format. By ensuring consistency in error responses, blockchain developers can write more robust and reliable tests, ultimately leading to higher-quality and more secure smart contracts. This standardization not only streamlines the development process but also enhances the overall developer experience, making it easier to build and maintain complex blockchain applications.

Solution: Intercept and Transform

One effective solution is to intercept the responses from revive and modify them to align with the Hardhat node's format. This approach involves creating a middleware or a wrapper that sits between revive and the test environment, transforming the responses on the fly. By doing so, existing tests that expect the Hardhat format can continue to function without modification. This strategy avoids the need to rewrite tests, saving time and effort. Modifying revive's response format to match Hardhat node's responses is a strategic approach that offers several key benefits in the context of blockchain development, particularly within the hardhat-polkadot ecosystem. This strategy primarily focuses on enhancing the consistency and reliability of the testing environment. By ensuring that error responses adhere to a unified format, developers can write tests that are more robust and less prone to false negatives or positives caused by format discrepancies. This ultimately leads to a more efficient and accurate testing process, reducing the time and resources spent on debugging and validation. Intercepting and transforming responses allows for a seamless integration of different environments without requiring extensive changes to existing codebases or test suites. This is especially valuable in complex projects where numerous tests and contracts have been developed with the expectation of a specific error format. The transformation process can be implemented as middleware or a wrapper, effectively acting as an intermediary layer that intercepts responses from one environment (e.g., revive) and converts them into the format expected by another (e.g., Hardhat). This approach ensures that tests designed for Hardhat's EDR (Ethereum Development Runtime) environment, which produces detailed custom error responses, can also function correctly when interacting with a revive-based environment that typically provides Geth-style responses. The transformation involves mapping the error codes, messages, and data structures from the revive format to the corresponding Hardhat format. This may include adding additional fields or restructuring the data to match Hardhat's nested error structure, which includes the error code, message, reason, and transaction hash. By aligning the response formats, developers can avoid the need for conditional logic within their tests to handle different error formats, simplifying the test code and making it easier to maintain. Moreover, this approach ensures that tests remain portable and consistent across different environments, reducing the risk of environment-specific issues and enhancing the overall developer experience. In addition to simplifying testing, modifying response formats can also improve the clarity and usability of error messages. Hardhat's EDR often provides more descriptive error messages that include the specific reason for a revert, making it easier for developers to diagnose and fix issues. By transforming revive responses to match this format, developers can benefit from more informative error reporting, leading to faster debugging and issue resolution. Overall, this strategy of modifying response formats represents a pragmatic and effective way to bridge the gap between different blockchain development environments. It minimizes disruption to existing workflows while maximizing the consistency and reliability of the testing process, ultimately contributing to the development of higher-quality and more robust smart contracts.

Implementing the Solution

The implementation would involve:

Intercepting responses from revive before they reach the test environment.
Transforming the response to match the Hardhat format. This includes mapping error codes, messages, and data structures.
Injecting the transformed response into the test environment.

This ensures that tests receive the expected format, regardless of the underlying environment. The implementation of a solution to intercept and transform error responses between different blockchain environments involves several key steps and considerations. The primary goal is to create a seamless bridge that converts error responses from one format (e.g., revive's Geth-style responses) to another (e.g., Hardhat's EDR-style responses), ensuring consistency and compatibility in the testing environment. This process typically involves designing and implementing middleware or a wrapper function that can intercept and modify the responses on the fly. One of the initial steps is to thoroughly analyze the structure and content of the error responses from both environments. This involves identifying the key differences in error codes, messages, and data structures. For instance, as demonstrated in the examples provided earlier, Hardhat's responses include a detailed breakdown of the error, including a reason, data, and transaction hash, while revive's responses are more concise, providing only the error code, message, and reverted data. Understanding these differences is crucial for creating an effective transformation mapping. Once the differences are well-understood, the next step is to implement the interception mechanism. This can be achieved by creating a proxy or middleware that sits between the testing environment and the blockchain node (e.g., revive). This intermediary can intercept the responses before they reach the test environment, allowing for modification and transformation. The transformation logic itself involves mapping the error codes, messages, and data structures from the source format to the target format. This may require creating a set of rules or a mapping table that defines how each element in the source response should be translated to the corresponding element in the target response. For example, a specific Geth error code might need to be mapped to a corresponding Hardhat error code, and the error message might need to be adjusted to align with Hardhat's more descriptive error reporting. In addition to mapping error codes and messages, the transformation process should also handle the data structures within the error response. This may involve restructuring the data, adding additional fields, or reformatting existing fields to match the target format. For example, the Hardhat format includes a nested data structure that provides detailed information about the error, including the reason for the revert and the transaction hash. The transformation logic should ensure that these elements are correctly populated in the transformed response. Finally, the transformed response is injected into the test environment, ensuring that tests receive the expected format regardless of the underlying environment. This ensures that tests designed for Hardhat's EDR environment can also function correctly when interacting with a revive-based environment, and vice versa. Testing is a critical part of this process. The transformation logic should be thoroughly tested to ensure that it correctly handles a wide range of error scenarios and that the transformed responses are accurate and complete. This may involve creating a set of test cases that cover different error conditions and verifying that the transformed responses match the expected format and content. By carefully implementing these steps, developers can create a robust and effective solution for intercepting and transforming error responses, ensuring consistency and compatibility in their blockchain development environment.

Handling Failed Transactions

Hardhat node returns revert data for failed transactions, which revive and Geth do not. To maintain consistency, failed transactions might need to be resubmitted as dry-runs. This ensures that the test environment receives the same level of detail for error reporting, regardless of the transaction's outcome. Hardhat node's behavior of returning revert data for failed transactions sets it apart from revive and Geth, which typically only return the transaction hash in such cases. This discrepancy can lead to inconsistencies in test results and debugging experiences, especially when tests rely on the presence of revert data to validate error conditions. To address this, a pragmatic solution is to resubmit failed transactions as dry-runs within the test environment. This approach ensures that the test environment consistently receives the revert data, regardless of whether the transaction initially failed or succeeded on-chain. A dry-run, also known as a simulated transaction or estimate gas execution, involves executing the transaction in a virtual environment without actually committing any changes to the blockchain's state. This allows developers to inspect the transaction's outcome, including any revert reasons or error messages, without incurring gas costs or altering the blockchain. By resubmitting failed transactions as dry-runs, the test environment can retrieve the revert data that Hardhat node would normally provide, thereby aligning the behavior of revive and Geth with that of Hardhat. This process typically involves the following steps: First, the test environment detects that a transaction has failed. This can be determined by inspecting the transaction receipt or by catching an exception thrown by the transaction execution. Once a failed transaction is detected, the test environment extracts the transaction parameters, such as the sender, recipient, data, and gas limit. These parameters are then used to construct a new transaction object for the dry-run. The dry-run is executed against the blockchain node using a method such as eth_call or a similar simulation API. This simulates the transaction execution without actually modifying the blockchain's state. The result of the dry-run is inspected to retrieve the revert data, which typically includes the error code, message, and any additional data returned by the smart contract. The revert data is then incorporated into the test environment's response, ensuring that the test case has access to the same level of detail as it would if it were running against Hardhat node. This approach not only ensures consistency in error reporting but also enhances the debugging experience. By providing detailed revert data for failed transactions, developers can more easily identify the root cause of issues and implement corrective measures. This is particularly valuable when dealing with complex smart contracts or intricate transaction flows where the reasons for failure may not be immediately apparent. Moreover, resubmitting failed transactions as dry-runs can help to reduce the reliance on on-chain data for testing purposes. While on-chain data can provide valuable insights into the behavior of smart contracts, it can also be costly and time-consuming to retrieve and analyze. By leveraging dry-runs, developers can perform a significant portion of their testing off-chain, reducing the overhead associated with on-chain interactions and accelerating the development process. Overall, the strategy of resubmitting failed transactions as dry-runs represents a practical and efficient way to maintain consistency in error reporting across different blockchain environments. It ensures that tests receive the necessary revert data, regardless of the underlying transaction outcome, and enhances the debugging experience by providing developers with detailed insights into transaction failures.

Example: Hardhat Response for Failing eth_sendRawTransaction

{
    "error": {
        "code": -32603,
        "data": {
            "data": "0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000076661696c65642100000000000000000000000000000000000000000000000000",
            "message": "Error: VM Exception while processing transaction: reverted with reason string 'failed!'",
            "txHash": "0xa39bcb6f1ae91c7b7195acc6309763ee96286d6479daec5a506c6e47cea4e8d1"
        },
        "message": "Error: VM Exception while processing transaction: reverted with reason string 'failed!'"
    },
    "id": 46,
    "jsonrpc": "2.0"
}

This example illustrates the detailed information provided by Hardhat for a failing eth_sendRawTransaction, including the error code, data, message, and transaction hash. By ensuring revive responses match this format, tests can accurately assess transaction outcomes.

Conclusion

Matching revive's response format to Hardhat node's format is crucial for maintaining test integrity and consistency within the hardhat-polkadot environment. By intercepting and transforming responses, and by resubmitting failed transactions as dry-runs, developers can ensure that their tests function reliably across different environments. This standardization streamlines the development process and enhances the overall developer experience. For further reading on Ethereum development and testing, you can visit the Ethereum Foundation's website.