VMOpts#activatePrecompiles behavior and doc

[alcuadrado]

I'm opening this issue because I find VMOpts#activatePrecompiles very confusing.

I'd expect that if it was false, the precompiles wouldn't work, and their accounts would be normal (empty) accounts instead. This is not the case, and they work despite the value of VMOpts#activatePrecompiles.

What is this param for?

It's only used here:

if (opts.activatePrecompiles) {
  for (let i = 1; i <= 8; i++) {
    trie.put(new BN(i).toArrayLike(Buffer, 'be', 20), new Account().serialize())
  }
}

which just sets them as empty accounts.

[s1na]

Yeah, I've also been curious about that one. Just did a search and found these: #65 and trufflesuite/ganache#88.

Not sure I fully got the context or whether this is still a valid use-case. We should verify if anything changes when the flag is true, this includes gas costs of the tx and details of the account created for the precompile.

I also wonder if this is somehow related:

https://github.com/ethereumjs/ethereumjs-vm/blob/c3d7a57971a54b91294f37cd5f9b329733d89740/lib/evm/evm.ts#L120-L128

[alcuadrado]

Forgot to comment here. Those links were super useful @s1na .

The difference between activating or not the precompiles is that if you don't the first time you call each of them is a little more expensive because of the account creation cost.

[s1na]

Was trying to figure out where this account creation cost is coming from. It's here:

https://github.com/ethereumjs/ethereumjs-vm/blob/87b18808c5c02e8437e84f9b348825b314994d72/lib/evm/opFns.ts#L703-L708

I guess that's why in genesis states they put accounts with a balance of 1, so the account exists.

[evertonfraga]

Maybe we can rename it to touchPrecompileAddresses or createPrecompileState. Or something else :)