Gas limit tweaks and EMP bytecode optimization

[nicholaspai]

This PR contains several features

• Increases gas limit on CI local Ethereum networks to more realistic (but conservative) 9,000,000.
• Reduces # of runs on optimizer in truffle-config to default of 200. Fewer runs = lower deployment cost and less deployed bytecode. Source: Removing Contract Size Limit ethereum/EIPs#1662 (comment)
• Change bytecode to deployedBytecode in CalculateContractBytecode.js script.
• Abstract deployment of EMP into a library, which EMPCreator will call via createExpiringMultiParty(params). H/t to @mrice32 for the idea. This separates EMP bytecode on-chain from the EMP-creator, which means that the EMP-creator is no longer the bytecode bottleneck for deploying the EMP set of contracts.

deployedBytecode Statistics:

---

This PR:

• EMP Creator = 3041 bytes
• EMP = 17170 bytes
• EMPLib = 20974 bytes

Previous:

• EMP Creator = 22983 bytes
• EMP = 17170 bytes

Integrating this PR will give us the neccessary bytecode space to merge in both #1305 and #1334 . #1305 adds ~900 bytes and #1334 adds ~500 bytes. The bytecode limit is ~24,500 bytes, so we will have plenty of bytecode remaining.

[nicholaspai]

Is there another example in the repo of linking libraries with contracts before deploying? I couldn't find one so I did it explicitly here.

[mrice32]

If you look at the TokenizedDerivativeUtils library from before we removed it from the repo, we did the same thing there.

[mrice32]

@nicholaspai Could you also include bytecode statistics for this new library? It'll probably be the largest IIUC.

[nicholaspai]

@nicholaspai Could you also include bytecode statistics for this new library? It'll probably be the largest IIUC.

great point. Done. Interesting the amount of overhead a library/contract has.

[mrice32]

This looks great -- to be honest, my biggest worry here is that this will make bytecode verification on Etherscan more difficult.

[nicholaspai]

This looks great -- to be honest, my biggest worry here is that this will make bytecode verification on Etherscan more difficult.

Do libraries make it more difficult? The optimizer runs # shouldn't affect it.

[mrice32]

This looks great -- to be honest, my biggest worry here is that this will make bytecode verification on Etherscan more difficult.

Do libraries make it more difficult? The optimizer runs # shouldn't affect it.

They shouldn't, but you have to plug them in manually, making the verification process slightly more complicated, so you never know :).

[nicholaspai]

This looks great -- to be honest, my biggest worry here is that this will make bytecode verification on Etherscan more difficult.

Do libraries make it more difficult? The optimizer runs # shouldn't affect it.

They shouldn't, but you have to plug them in manually, making the verification process slightly more complicated, so you never know :).

Ah, should we hold off then and do a testnet deployment + verification?

[chrismaree]

This is great! thanks for doing these optimizations. Glad we can fit all the required PRs now :)

[mrice32]

This looks great -- to be honest, my biggest worry here is that this will make bytecode verification on Etherscan more difficult.

Do libraries make it more difficult? The optimizer runs # shouldn't affect it.

They shouldn't, but you have to plug them in manually, making the verification process slightly more complicated, so you never know :).

Ah, should we hold off then and do a testnet deployment + verification?

Nah, I wouldn't worry about it. We'll cross that bridge when we come to it.