Manual and unaided debugging of Solidity Python blockchain applications.

[n4n0b1t3]

Manual and unaided debugging of Solidity Python blockchain applications.

I haven't worked directly in software development for many years, so I'm not an expert when it comes to programming. But somehow I know it differently. Finding bugs in code used to be a lot easier. Maybe it's just me, but I find debugging blockchain applications quite tedious. Now, in the last month, I've become active in the discussion group around this repository. Judging by the questions I read and sometimes answer, I think I'm not alone. Many users struggle just like I do with error messages that rarely help find the error. In this article, I will go through an example that illustrates the code error scenario. There are of course other scenarios, such as incorrect settings, software version problems, or network errors, to name a few.

To anticipate what went wrong in the example that follows. I had tried to do mathematical operations with different types of integers in my solidity code. This is of course a noob mistake. The problem, once I found it, was very easy to fix. It just wasn't easy to spot from the information I got.

What I will describe in the following is on the one hand the flow in the development process and at which point you notice that something is wrong and on the other hand what clues there are that can help you to find out where to start looking for the error.

The Solidity Code

The following code has been reduced to the essentials for debugging purposes. I have systematically switched off all other error sources one after the other. For example, I do not load the data stream key from the configuration file and do not pass it to the constructor during deployment.
There are no error messages under VSCode or Remix and the code compiles without any problems. Yet this code produces and error when running the test.

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.7 <0.9.0;

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract LotterySimple {
    AggregatorV3Interface internal priceFeed;
    uint16 public TICKET_PRICE_USD;

    constructor() {
        priceFeed = AggregatorV3Interface(0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419);
        TICKET_PRICE_USD = 50;
    }

    function getEntranceFee() public view returns (uint256 _entranceFeeInWei) {
        (int256 exchangeRate, uint8 decimals) = getExchangeRate();
        uint256 ticketPriceUsdWeiEquivalent = TICKET_PRICE_USD * 10**18;
        uint256 exchangeRateWeiEquivalent = uint256(exchangeRate) * 10**(18 - decimals);
        uint256 entranceFeeInWei = (ticketPriceUsdWeiEquivalent * 10**18) / exchangeRateWeiEquivalent;
        return entranceFeeInWei;
    }

    function getExchangeRate() public view returns (int256 exchangeRate, uint8 decimals) {
        (, int256 _exchangeRate, , , ) = priceFeed.latestRoundData();
        return (_exchangeRate, priceFeed.decimals());
    }
}

Output of the compilation

(py39brownie) lottery>brownie compile

Brownie v1.18.1 - Python development framework for Ethereum

Compiling contracts...
  Solc version: 0.8.12
  Optimizer: Enabled  Runs: 200
  EVM Version: Istanbul
Generating build data...
 - smartcontractkit/chainlink-brownie-contracts@0.4.0/AggregatorV3Interface
 - Lottery
 - LotterySimple

Project has been compiled. Build artifacts saved at C:\Users\n4n0b1t3\blockchainProjects\brownieprojects\lottery\build\contracts

How I became aware of the error

After completing my contract and compiling it uneventfully (i.e. without error warnings). I set about writing a test for the getEntranceFee() function.

It looks like the following. What you see here is already reduced considerably to exclude additional error sources in order to better isolate the error. For this, I created a separate file so that I can test it separately via brownie test [path]. This way I don't ruin the work I had put into writing the test until the error occurred.

# current price 2799USD -> 50USD ~ 0.0178
from brownie import LotterySimple, accounts, Wei


def test_lottery_simple():
    account = accounts[0]
    lottery = LotterySimple.deploy({"from": account})
    entrance_fee = lottery.getEntranceFee()
    print(f"entrance_fee {entrance_fee} >= {Wei('0.018 ether')} ")
    assert entrance_fee <= Wei("0.02 ether")
    assert entrance_fee >= Wei("0.016 ether")

The error message
I will now show the complete error message so that it becomes clear how much of the output text does not help in solving the problem. There are 72 lines in the error message. After this, I will go into what of it is helpful in finding the error.

(py39brownie) lottery>brownie test .\tests\test_lottery_simplified.py
INFORMATION: Es konnten keine Dateien mit dem angegebenen
Muster gefunden werden.
Brownie v1.18.1 - Python development framework for Ethereum

============== test session starts 
platform win32 -- Python 3.9.10, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
rootdir: C:\Users\n4n0b1t3\blockchainProjects\brownieprojects\lottery
plugins: eth-brownie-1.18.1, hypothesis-6.27.3, forked-1.4.0, xdist-1.34.0, web3-5.27.0
collected 1 item                                                                                                                                                                                                               

Launching 'ganache-cli.cmd --chain.vmErrorsOnRPCResponse true --wallet.totalAccounts 10 --hardfork istanbul --fork.url https://eth-mainnet.alchemyapi.io/v2/mykey --miner.blockGasLimit 12000000 --wallet.mnemonic brownie --server.port 8545 --chain.chainId 1'...

tests\test_lottery_simplified.py F                                                                                                                                                                                      [100%]

==================== FAILURES 
_____________________ test_lottery_simple 

    def test_lottery_simple():
        account = accounts[0]
        lottery = LotterySimple.deploy({"from": account})
>       entrance_fee = lottery.getEntranceFee()

tests\test_lottery_simplified.py:8:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  
..\..\..\.virtualEnvironments\py39brownie\lib\site-packages\brownie\network\multicall.py:115: in _proxy_call
    result = ContractCall.__call__(*args, **kwargs)  # type: ignore
..\..\..\.virtualEnvironments\py39brownie\lib\site-packages\brownie\network\contract.py:1751: in __call__
    return self.call(*args, block_identifier=block_identifier, override=override)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  

self = <ContractCall 'getEntranceFee()'>, block_identifier = None, override = None, args = (), tx = {'allow_revert': None, 'data': '0x09bc33a7', 'from': '0x66aB6D9362d4F35596279692F0251Db635165871', 'gas': None, ...}       

    def call(
        self, *args: Tuple, block_identifier: Union[int, str, bytes] = None, override: Dict = None
    ) -> Any:
        """
        Call the contract method without broadcasting a transaction.

        Arguments
        ---------
        *args
            Contract method inputs. You can optionally provide a
            dictionary of transaction properties as the last arg.
        block_identifier : int | str | bytes, optional
            A block number or hash that the call is executed at. If not given, the
            latest block used. Raises `ValueError` if this value is too far in the
            past and you are not using an archival node.
        override : dict, optional
            A mapping from addresses to balance, nonce, code, state, stateDiff
            overrides for the context of the call.

        Returns
        -------
            Contract method return value(s).
        """

        args, tx = _get_tx(self._owner, args)
        if tx["from"]:
            tx["from"] = str(tx["from"])
        del tx["required_confs"]
        tx.update({"to": self._address, "data": self.encode_input(*args)})

        try:
            data = web3.eth.call({k: v for k, v in tx.items() if v}, block_identifier, override)
        except ValueError as e:
>           raise VirtualMachineError(e) from None
E           brownie.exceptions.VirtualMachineError: revert

..\..\..\.virtualEnvironments\py39brownie\lib\site-packages\brownie\network\contract.py:1542: VirtualMachineError
============ short test summary info 
FAILED tests/test_lottery_simplified.py::test_lottery_simple - brownie.exceptions.VirtualMachineError: revert
=============== 1 failed in 12.83s 
Terminating local RPC client...

Helpful error output

And these lines help to better isolate the error.

    def test_lottery_simple():
        account = accounts[0]
        lottery = LotterySimple.deploy({"from": account})
>       entrance_fee = lottery.getEntranceFee()
[...]
brownie.exceptions.VirtualMachineError: revert

In the first part you can see from which line in the Python code something went wrong.

In the last line you can see that there was a VirtualMachineError and that this caused a "revert".

(As always, completely useless is the following text: "INFO: Could not find files for the given pattern(s).")

What other typical error sources are there in the test code and how can we exclude them as errors?

Why should you do this? The more complex the code becomes, and the more files and libraries have to interact, the harder it is to find a bug. There is also the possibility that several errors occur in combination. A systematic procedure to temporarily resolve these dependencies is therefore helpful in order to be able to narrow down the source(s) of the error by means of an exclusion procedure.

Possible source of error:
A key value is read from the configuration file and is not set or not set correctly, for example in the wrong network.

Exclusion:
For simplicity, the key can simply be written directly into the code.

Possible source of error:
A function returns a wrong value or no value at all. In this case getEntranceFee().

Exclusion:
Simply set the return value statically.

Possible error source:
A change to the solidity code was made but not compiled.

Exclusion:
Compile before testing.

Back to the error message

In the error message, there is a section "FAILURES". Here the code breaks at the point where lottery.getEntranceFee() is called. So the deployment seems to have worked. The function does not return any value at all.

Furthermore, there is a line
E brownie.exceptions.VirtualMachineError: revert
This indicates that the transaction was reverted.

Here at the latest, one should take a closer look at the Solidity contract. The fact that the above-mentioned error message does not refer to positions in the Solidity code is due to the fact that Python is already working with a compiled file and there is no reference to our .sol file.

some tooling after all

The first thing I did now is to compile the solidity code again. Only as a test. Again, no problems. Now I opened a remix window in the browser and copied the code into it and compiled it. Again no error messages. Connected the wallet, started Injected Web, copied the chainlink address for ETH/USD for Rinkeby and deployed the contract with the data feed address I just copied. Still no error message. If I now click on the getEntranceFee button in Remix, I get "call to LotterySimple.getEntranceFee errored: execution reverted" in the terminal.

You have to realise here how many other sources of error I have already ruled out. The rest, however, means thinking.

The Solidity smart contract

Here is the function where the error is.

    function getEntranceFee() public view returns (uint256 _entranceFeeInWei) {
        (int256 exchangeRate, uint8 decimals) = getExchangeRate();
        uint256 ticketPriceUsdWeiEquivalent = TICKET_PRICE_USD * 10**18;
        uint256 exchangeRateWeiEquivalent = uint256(exchangeRate) * 10**(18 - decimals);
        uint256 entranceFeeInWei = (ticketPriceUsdWeiEquivalent * 10**18) / exchangeRateWeiEquivalent;
        return entranceFeeInWei;
    }

We have been able to narrow the search down to 5 lines of code.

Notices

• If you look closely at the data types, there are very different forms here: uint8, uint256, int256 and the constant TICKET_PRICE_USD, which is created at the beginning of the contract with uint16.
  uint16 public TICKET_PRICE_USD;

• Using different data types without typecasting in mathematical operations is always critical. Especially when types with small memory areas are thrown together with types that have a very large memory requirement. Namely, here uint16, which can never be larger than 65.535, and a uint256 which can be an insanely large number.

Try to fix the problem:
In this line of code
uint256 ticketPriceUsdWeiEquivalent = TICKET_PRICE_USD * 10**18;
I replaced the variable with the desired number 50 like this
uint256 ticketPriceUsdWeiEquivalent = 50 * 10**18;

The test then ran successfully. Of course, this is not the final solution, this is easily achieved by typecasting as follows.
uint256 ticketPriceUsdWeiEquivalent = uint256(TICKET_PRICE_USD) * 10**18;

Summary

This relatively long post has the following key points.

1. the error messages we get in our development process are sometimes subtle, sometimes misleading, and often not very helpful.
2. the current phase of development, for example, writing tests or deployment scripts, may reveal errors that are caused somewhere else upstream.
3. a systematic approach is very helpful in finding bugs. One of the most important tools is to progressively isolate a bug by gradually eliminating the sources of the bug.
4. it makes sense to create copies of the files to be processed for this process and also to create separate tests for them.
5. solidity is not always able to detect errors in the code before, during, or after compilation. Conversely, this means that a Solidity file without error messages is not necessarily error-free.

[n4n0b1t3]

@cromewar This article is quite a mess, but maybe we could spin off a series of shorter tl;dr articles where we discuss good practices on how to solve problems. Here are some ideas:

• a table with common error messages and likely causes
• excluding possible error sources for finding the real culprit instead of trying to turn on all knobs at the same time
• list of solidity issues, which won't show up in the editor or during compiling but still will cause reverted transactions when used
• I actually would encourage Patrick to create a video focusing on the setup of a development enviroment. There are just too many problems that stem from a faulty setup. Maybe we could do this in form of a repository. This can be kept up-to-date and with every new version, everyone using this setup could update their systems with a tested approach.

[cromewar]

Hello @n4n0b1t3 well as you know I'm working a pl adding all of this, a complete apart with good practices, common problems and solutions. this should be done this weekend, if you are ok with this I'll also use parts of this post.

[n4n0b1t3]

@cromewar any time