I am using web3js batch.add and batch.execute to send tx for an ethereum private testnet that I have created. I send tx using batch.add and batch.execute (don't prefer to use promises since they iterate tx one after the other and send whereas batch.add creates a batch and then executes it as a whole): My batch.js looks as follows (the documentation here has about batch requests: https://web3js.readthedocs.io/en/v1.2.7/web3-eth.html#batchrequest):

function bench(size) {
    personal.unlockAccount(eth.accounts[0], "hi");
    var batch = web3.createBatch();
    start = Date.now();
    for (i = 0; i < size; i++) {
            from: eth.accounts[0],
            to: "0xBce16ea55bB357B038e612b1722A88879c665a31",
            value: 1
    end = Date.now();
    duration = end - start;
    throughput = size * 1000 /duration;
    console.log("Start: "+start);
    console.log("End: "+end);
    console.log("Transaction Number: "+size);
    console.log("Duration: "+duration);
    console.log("Throughput: "+throughput);

I use rpc to attach to the geth nodes remotely and execute multiple different batch.js parallely as follows:

geth --exec 'loadScript("batch.js")' attach &
geth --exec 'loadScript("batch1.js")' attach &
geth --exec 'loadScript("batch2.js")' attach &
geth --exec 'loadScript("batch3.js")' attach & 

I use a unique sender account for each batch.js so as to avoid tx nonce issues.

Problem - After sending tx, I checked the balance at each geth node for the receiver account. However, the amount I sent was not reflected at the EVM for the receiver account (some tx were lost). I checked whether consensus delivered the sent tx and in fact it had delivered all sent txs. This led me to believe that some txs are not executed and persisted due to nonce issues. This may well be the case as I am not using the PoW consensus but a different consensus.

Now, I could perhaps create as many accounts as txs I send and try to test this. However, creating say 100,000 accounts with "personal.newAccount('hi');" consumes a lot of time and space as I have to attach to a geth ipc and then create accounts whilst chaindata is written to the device and consumes space.

Therefore, I decided that it would be easier to disable the nonce check in geth entirely just for checking. Would it be possible for someone to point me to where I should make the changes in go-ethereum to disable nonce check (nonce too high, nonce too low, nonce invalid, etc) entirely, so the EVM would execute and persist all the tx that I send?

  • What are you trying to accomplish? Batch is only meaningful when used with queries since it guarantees the will be answered at the same block height, but for transactions it doesn't make much sense. Are you sure the balance mismatch is caused by nonce? it might be something else like gas price variations
    – Ismael
    Commented Jul 15, 2020 at 3:50
  • I am trying to get the max throughput by bombarding the test net with tx batches. A high sending rate is required to get the max throughput. I thought if the gas price was the issue, web3js would show something like transaction underpriced, etc. But it didn't. "web3.eth.sendTransaction" assigns a gas price automatically unlike raw transactions, I assume. Anyway, the sender accounts have enough balance. Do you know where in go-ethereum to disable the nonce check? I found a few places in core/tx_pool.go and core/state_transistion.go, and miner/worker.go and commented them out but it didn't work.
    – Deepal
    Commented Jul 15, 2020 at 5:31
  • To get a higher throughput I'd suggest to increase block gas limit and decrease block time. If you get transaction stuck in pending state it is likely you reached one of the limits for queued transactions and geth has started to drop pending transactions, you can play with geth to increase txpool.globalqueue and txpool.accountqueue. Perhaps setting gas price to zero and using random accounts without creating them will work. Modifying the client doesn't sound the right solution, I'd start with tx_pool and state_transitions but perhaps it is too wired into the protocol to be removed easily.
    – Ismael
    Commented Jul 15, 2020 at 14:50
  • The consensus delivers the correct amount of tx to the EVM. So the problem probably happens when the EVM tries to execute and persist the tx. This is why I said it could be an issue with the nonces being out of order. I did disable a few nonce checks in tx_pool and state_transitions but to no avail. Wondering where else I need to change
    – Deepal
    Commented Jul 15, 2020 at 16:00


Your Answer

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