ethereumjs/ethereumjs-common

Project is in active development and has been moved to the EthereumJS VM monorepo.

ethereumjs-common's Issues

TypeError: Common is not a constructor

const Common = require('ethereumjs-common');

// Instantiate with only the chain
let c = new Common('ropsten');

This keeps giving me this error:

let c = new Common('ropsten');
        ^

TypeError: Common is not a constructor

Remove Gas postfix in chainstart.js

Some gasPrice values in chainstart.js have survived the ...Gas postfix ending in the name.

These have to be removed and published as a new release.

Remove hybridCasper hardfork draft

There is still some hybridCasper hardfork file along with some references both in code and docs as a left over from some time where there was some kind of a linear hardfork roadmap. 😄

This should be removed.

Updated pre-/post reentrency Constantinople support

As far as I can read out from both the notes from core developers meeting 53 as well as some covering media articles like this one on blockonomi.com there will now technically be two Constantinople hardforks, the current already happened on test nets including EIP-1283 and a second one again removing the feature. On mainnet there will only be the last one applied.

Technically this would mean two Constantinople files here in the src/hardforks directory. For naming I would prefer to keep constantinople for the latter one - since this will be the lasting one staying relevant in mid- and long term and choose something like constantinopleTmp for the testnet fixing one. In constantinopleTmp all parameters would have to be set to the values currently collected in the current constantinople file. The new constantinople file would then re-set the SSTORE values to its pre constantinopleTmp state.

For the different src/chains files the two (!) hardforks have to be added. There has to be special care regarding upstream libraries that this is done (and applied on upstream libraries like the VM) in a way that on mainnet on Constantinople switch all the values from constantinopleTmp are taken and then the value resetting (overwriting) in constantinople is also taking place. This can probably be achieved by adding both hardforks with the same block number, constantinopleTmp coming first. This has to be carefully tested if it really works on upstream though.

Before we continue on this I would like to have at least one confirmation that my analysis is correct.

Add support for private networks

In order to support private networks, we should allow an instance of Common to be created from a chain spec and/or a geth genesis file. Any of the following would be user-friendly ways to construct a Common instance from a spec file:

const common = Common.fromSpec('./genesis.json')

const common = Common.fromJson('./genesis.json')

const spec = require('./genesis.json')
const common = new Common(spec) // detect first argument is an Object instead of string

We could also consider migrating the json definition files in the chains/ folder to the chain spec format for consistency and future-proofing.

Consistent/unified value format on genesis file accounts

Value format on genesis file accounts (see e.g. rinkeby.json should be made consistent along the guide from this to avoid ambiguous behavior.

Also to consider: 0x1, 0x01 or 0x000000000000000000000000000000000000000000000000000000000000001?

Support for new Goerli testnet

Goerli is a new - currently still experimental - cross-client PoA network, see https://github.com/goerli/testnet for information on network setup, genesis information and bootnodes.

Along with Goerli setup there is also some reactivation and new discussion here ethereum/EIPs#1085 around a common genesis file format. We should actively engage, integrate stuff here (minimally e.g. the terminology) which is settled and contribute with ideas where there is still need for discussion.

Integration here would be a separate issue, generally Goerli support and genesis file format integration is complementary.

forCustomChain is not a function

Hi,

I'm following this example https://github.com/ethereumjs/ethereumjs-tx/blob/9a6324f64f4da1cb550a3eec4eaef95da4ab441b/examples/custom-chain-tx.ts to try to get a tx for a private network.

My code is:
const Tx = require('ethereumjs-tx').Transaction; const Common = require('ethereumjs-common') const customCommon = Common.forCustomChain( 'mainnet', { name: 'my-network', networkId: 8995, chainId: 8995, }, 'petersburg', )

If I try a console.log(Common) forCustomChain seems to be a function but when trying to execute the js file it shows an error forCustomChain is not a function...

Any help is appreciated

Guillermo

This library is too restrictive for testing networks

I'm planning to upgrade ethereumjs-tx in Buidler, and found that it may not be possible to do that if I want to enable EIP155.

The problem is that testing networks normally use non-standard chain ids (e.g. Ganache). If I want to sign a tx locally, I should do something like:

const { Transaction } = require("ethereumjs-tx");
new Transaction({ ... }, { chain: 123 });

But this results in this error:

Error: Chain with ID 123 not supported
    at Common.setChain (/private/tmp/tcommon/node_modules/ethereumjs-common/dist/index.js:35:23)
    at new Common (/private/tmp/tcommon/node_modules/ethereumjs-common/dist/index.js:16:34)
    at new Transaction (/private/tmp/tcommon/node_modules/ethereumjs-tx/dist/transaction.js:65:28)
    at Object.<anonymous> (/private/tmp/tcommon/index.js:2:1)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Function.Module.runMain (module.js:694:10)

Taking a look at setChain I noticed that it's impossible to use a non-standard chain id.

The only workaround I see is by extending this class or creating a new one altogether, but it doesn't feel right for users to have to do this.

I'd LOVE to have an option to create a chain with the same params than a standard one, except for the genesis state and the chain id.

[Istanbul] EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

Part of ethereumjs/ethereumjs-monorepo#501

Follow-up EIP to the failed Constantinople SSTORE EIP, see also #27 . There need to be some update to the price params respectively new params added, eventually named along the lines of PR #27 .

Should likely be addressed together with #61 in one combined PR (or at least released).

Update: Since EIP-2200 is still in heavy discussion it might actually be also make sense to handle and release separately.

Account addresses in genesisStates should be prefixed with '0x'

Many of the addresses in the alloc field in the genesisStates json files aren't prefixed with 0x. This causes state roots computed from these files to be incorrect when using ethereumjs/merkle-patricia-tree to load these states. The reason for this is that the Trie.prototype.put function https://github.com/ethereumjs/merkle-patricia-tree/blob/master/src/baseTrie.js#L87) calls ethUtil.toBuffer() on the account address which treats the address as a plain string instead of a hex string if it's not prefix with a 0x.

As a fix, we can either prefix all of the addresses with a 0x in the alloc field of each genesisStates file or modify genesisStates/index.js to programmatically add a '0x' prefix if its missing.

Add Kovan hardfork blocks

When I set up this library I left out the Kovan hardfork blocks - see here - simply because I didn't find them online on first sight.

These should be added, shouldn't be such a thing, eventually grabbable by some Parity Ethereum code search or something.

[Istanbul] EIP-1884: Trie-size-dependent Opcode Repricing > Price Parameters

Part of ethereumjs/ethereumjs-monorepo#501

EIP-1884 introduces price changes for trie-size-dependent opcode to better balance the network along growth, as well as a new opcode SELFBALANCE.

The new price parameters have to be added to the Common library for the Istanbul HF.

Should likely be addressed together with #62 in one combined PR (or at least released).

Update: Since EIP-2200 is still in heavy discussion it might actually be also make sense to handle and release separately.