0

EDIT: In short, I want to use Brownie to deploy smartContracts to HyperLedger-Besu network on my local machine. For some reason, it doesn't work, so I wanted to ask if anyone here had experience with such an issue. I described my specific problem in more detail below.

I tried to deploy a basic Migrate.sol smartContract on my local instance of HyperLedger-Besu (named besulocal) by using Brownie.

I added its configuration to the brownie's network-config.yaml

  - name: HyperLedger-Besu
    chainid: 1337
    id: besulocal
    host: http://localhost:8545
    block_time: 5

Then confirmed it indeed works by checking the balance of pre-funded account acct. (Screenshoot below) enter image description here

However, when I am trying to migrate the Migrations.sol to the besulocal I get this Error:

 Transaction sent: 0xc3f86ca503d3d5f26dc57b30ee3039c4ecd4641ee7d0e5c8c223bd9032d38a41
      Gas price: 0.0 gwei   Gas limit: 191019   Nonce: 33
      File "<console>", line 1, in <module>
      File "/usr/local/lib/python3.8/dist-packages/eth_brownie-1.18.1-py3.8.egg/brownie/network/contract.py", line 532, in __call__
        return tx["from"].deploy(
      File "/usr/local/lib/python3.8/dist-packages/eth_brownie-1.18.1-py3.8.egg/brownie/network/account.py", line 510, in deploy
        receipt, exc = self._make_transaction(
      File "/usr/local/lib/python3.8/dist-packages/eth_brownie-1.18.1-py3.8.egg/brownie/network/account.py", line 759, in _make_transaction
        receipt = TransactionReceipt(
      File "/usr/local/lib/python3.8/dist-packages/eth_brownie-1.18.1-py3.8.egg/brownie/network/transaction.py", line 221, in __init__
        target=self._await_confirmation, args=(tx["blockNumber"], required_confs), daemon=True
      File "/usr/local/lib/python3.8/dist-packages/web3-5.27.0-py3.8.egg/web3/datastructures.py", line 51, in __getitem__
        return self.__dict__[key]  # type: ignore
    KeyError: 'blockNumber'

The interesting thing is that when I try to deploy to ganache-cli everything works as intended, but fails on besulocal enter image description here

This is my deployment-script:

from brownie import Migrations, accounts

    def main():
    
        acct = accounts.load('besulocal_account') #Account Pre-funded with ETH
        Migrations.deploy({'from': acct})

Would appreciate if anyone had any idea on how to deal with this.

NOTE: ganache-cli and besulocal are using the same port, but they are not active simultaneously. I shut down ganache-cli before using besulocal and vice versa.

EDIT2: The first answer mentioned that signer might be an issue. So I tried to transfer some ETH from pre-funded account to another address. And I indeed got the same error; however, after checking the balances, I noticed the transfer did indeed pass through regardless of the error. See screenShoot below: enter image description here

5
  • What consensus protocol implements your Besu network? Are you mining blocks on your Besu network?
    – alberto
    May 13, 2022 at 10:10
  • I see that on besulocal your tx has a 0 Gwei price while it's 20 Gwei on ganache. Did you try on besulocal with a 20 Gwei tx also? Ganache may put a default gas price to your tx while besulocal does not.
    – Undead8
    May 15, 2022 at 21:57
  • @alberto I am using POA protocol, and yes the block are being mined (I can see block number change every 5 seconds). I also tried to use Truffle to deploy contract to besulocal, and it worked. But it doesn't with with brownie, for some reason.
    – Sky
    May 16, 2022 at 12:54
  • Did you create the POA with chainID:1337 in the genesis (besu.hyperledger.org/en/stable/Concepts/NetworkID-And-ChainID) and are you passing --network-id=1337 when running Besu? May 17, 2022 at 0:27
  • @GiuseppeBertone yes, my network has chainID of 1337
    – Sky
    May 18, 2022 at 6:35

2 Answers 2

1
+50

The problem is due to Besu not fully following the standard JSON-RPC API for eth_getTransactionByHash.

After signing the tx, brownie checks the status of the tx using eth_getTransactionByHash and looks for blockNumber field. API standard says that filed should be null if the tx is pending, or equal to the block number if the tx is mined.

On the contrary, Besu's response does not contain the blockNumber field in case of pending txs, and this causes the error.

Example of Besu response for a pending tx:

{
  "jsonrpc" : "2.0",
  "id" : 6,
  "result" : {
    "from" : "0x627306090abab3a6e1400e9345bc60c78a8bef57",
    "gas" : "0x5208",
    "gasPrice" : "0x2540be400",
    "hash" : "0xfe6f9abeacbe186f6ee5edd811228e0710631c3569ee8bd45ca67c46146c762c",
    "input" : "0x",
    "nonce" : "0x32",
    "to" : "0xf12b5dd4ead5f743c6baa640b0216200e89b60da",
    "value" : "0x2",
    "v" : "0xa96",
    "r" : "0x325fd22b695b5f8e54cab34ae558373a9a15229a6cf8614d60fa7bcdc1493abf",
    "s" : "0xf1c739e11f356c7a59e8b37e36f91c423ce0298bfd089780415c60ed2652f3c",
    "chainId" : "0x539",
    "publicKey" : "0xaf80b90d25145da28c583359beb47b21796b2fe1a23c1511e443e7a64dfdb27d7434c380f0aa4c500e220aa1a9d068514b1ff4d5019e624e7ba1efe82b340a59",
    "raw" : "0xf866328502540be40082520894f12b5dd4ead5f743c6baa640b0216200e89b60da0280820a96a0325fd22b695b5f8e54cab34ae558373a9a15229a6cf8614d60fa7bcdc1493abfa00f1c739e11f356c7a59e8b37e36f91c423ce0298bfd089780415c60ed2652f3c"
  }
}   

Example in case of mined transaction:

{
  "jsonrpc" : "2.0",
  "id" : 6,
  "result" : {
    "blockHash" : "0x22a9a2ba92fa46aacd2caddba0762f7dac2eba1a9baa85a07a097fcffb12976f",
    "blockNumber" : "0x1df",
    "chainId" : "0x539",
    "from" : "0x627306090abab3a6e1400e9345bc60c78a8bef57",
    "gas" : "0x5208",
    "gasPrice" : "0x2540be400",
    "hash" : "0x7dbaf945a3f971b26a48ee3e0eba62348bcece160ba356def95f70aa85dc032f",
    "input" : "0x",
    "nonce" : "0x12",
    "publicKey" : "0xaf80b90d25145da28c583359beb47b21796b2fe1a23c1511e443e7a64dfdb27d7434c380f0aa4c500e220aa1a9d068514b1ff4d5019e624e7ba1efe82b340a59",
    "raw" : "0xf866128502540be40082520894f12b5dd4ead5f743c6baa640b0216200e89b60da0180820a96a0da2be02538d4f505a79c16eab693e54b8529e9b72ef3cf69ed482141a1273744a015c1c2d81decef6226b1c3f390b6c34cbea38af788c3e44e6e7e83ca0c759fa6",
    "to" : "0xf12b5dd4ead5f743c6baa640b0216200e89b60da",
    "transactionIndex" : "0x0",
    "value" : "0x1",
    "v" : "0xa96",
    "r" : "0xda2be02538d4f505a79c16eab693e54b8529e9b72ef3cf69ed482141a1273744",
    "s" : "0x15c1c2d81decef6226b1c3f390b6c34cbea38af788c3e44e6e7e83ca0c759fa6"
  }
}

I opened a dedicated issue on the official Besu repo, and now it's fixed with PR3906. Brownie should be able to work fine with the next Besu's release.

5
  • Yeah, it has no blockNumber, so Brownie goes haywire. Damn. So the only way to solve this is for me to edit Brownie lib myself?
    – Sky
    May 19, 2022 at 15:51
  • Actually yes. Or waiting for Besu to fix that (I'm opening an issue just now). May 19, 2022 at 15:56
  • Thanks, man, If it weren't for you, I would have taken months to figure this out. Please pass me the link once you open the issue so I can keep track of it. I will reward you the bounty, you truly deserved it.
    – Sky
    May 19, 2022 at 16:02
  • 1
    :) happy to have been of help. Here is the link: github.com/hyperledger/besu/issues/3868 May 19, 2022 at 16:23
  • 1
    The issue was fixed with PR3906. Brownie should be able to work fine with the next Besu's release. May 27, 2022 at 20:00
0

The problem seems you are trying to let Besu manage the transaction's signature.

Hyperledger Besu does not support key management inside the client. You need to use an external signer and send raw transactions to it.

See the official documentation for more details.

4
  • I tired to do basic transfer (sending some ETH from pre-funded account to another address). And did get the same error, but the transfer actually went through, (There was balance update)
    – Sky
    May 17, 2022 at 10:56
  • This is weird... The error should be related to the response of Besu, when you ask for tx["blockNumber"]. It says blockNumber key does not exist, my hypothesis is that Besu responds with an error (unchecked by the library), so the lib cannot read that value (it's essentially listening for the block number to change to understand if the tx is still pending or it's mined). Do you get the same response for balance if you check with another web3 client, i.e. with geth attach? May 19, 2022 at 13:50
  • Found! Actually the lib is signing the tx, so under the hood it uses sendRawTransaction, as expected. The problem is that Besu does not follow the expected standard response in case of pending transaction, in particular the response does not include the blockNumber parameter (it's should be set to null until mined). May 19, 2022 at 15:05
  • Aha, so Besu doesn't return blockNumber parameter therefor I get the error? And your advice is to edit the Brownie python/lib so it doesn't expect the blockNumber, and avoid error that way?
    – Sky
    May 19, 2022 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.