Optimism L2 - token [Hardhat - v2]#33
Conversation
e4fb6db to
e971321
Compare
e9afcef to
9464717
Compare
- Update OZ lib to v3.4.0, polish contracts, fix tests - Turn off solc bytecodeHash metadata generation - Move continuous integration to GitHub - Add target (OVM) support to getContractFactroy fn - Add Optimism L2 network bootstrap to CI integration job - Strictly declare Versions and Targets - Integrating @chainlink/optimism-utils - Update env loading and docs - Use 1_000_000 optimizer runs for v0.7 - Add LinkTokenChild contract - Run on self-hosted CI runner - Add yargs lib to parse argv - Add contract size and gas reporters
9464717 to
5d44e69
Compare
|
@alex & @yos please check out the Hardhat/OVM integration here. It supports the compilation of multiple versions (v0.4, v0.6, ...) and multiple targets (EVM, OVM,...). We'd need this functionality in multiple Solidity projects, so an idea is to try to share a setup like this and include it everywhere. I'd appreciate your feedback. @Steve & @kaleofduty the |
| "dependencies": { | ||
| "@chainlink/contracts": "^0.1.6", | ||
| "@openzeppelin/contracts": "^3.4.0" | ||
| "@chainlink/optimism-utils": "https://github.com/smartcontractkit/optimism-utils.git", |
There was a problem hiding this comment.
Can't all of these other than OZ be moved into dev dependencies?
There was a problem hiding this comment.
"Needs to be" a proper dependency as this is now more than just a raw contracts package. It brings some useful functions for consumers like Gauntlet to use, for example, the getContractFactory fn to load the factory by name for a specific version & target.
Most of that code could be extracted in a separate lib, and then reused here, in Feeds Registry repo, in our core evm-contracts, etc.
The specific "@chainlink/optimism-utils" dependency is because of optimism.loadEnv fn which is currently repo specific and does not have much use externally.
There was a problem hiding this comment.
I've cleaned this a little, but still left the @chainlink/optimism-utils as a dependency. It's less confusing to use it this way currently. I agree we can organize this better, and please share your suggestions, but I guess this is good enough for now.
I vote we try to see how all of this fits into our larger set of contract repos & tools. We can try to use it (share hardhat & optimism utils) in Gauntlet, Feed Registry, core contracts, and then restructure it to fit better depending on the outcome.
There was a problem hiding this comment.
Remove export of JS helper functions is the commit that addresses this.
JS code is not exported anymore and will be manually c/p to Gauntlet.
6dfa2c8 to
604d6fe
Compare
604d6fe to
557b4f2
Compare
se3000
left a comment
There was a problem hiding this comment.
Probably not for this PR, but I think we should vendor our Solidity dependencies for this repo like we do for the others.
5ce76ef to
8a5bfde
Compare
|
To see an example usage of the LinkTokenChild contract, in the context of Optimism, please check out the Optimism L2 - bridge #34 PR. P.S. The CI fails because of upstream Optimism monorepo issues, locally works perfectly. Investigating... |
85e7a18 to
4051cd9
Compare
- By doing this we are trying to lower the probablity of supply chain type of attacks
- By doing this we are trying to lower the probablity of supply chain type of attacks
|
Again, wondering if we should use submodules instead of manually copying a hash. Seems error prone and non-standard as is. |
24bf548 to
b84c373
Compare
b84c373 to
3b0ca75
Compare
1665f62 to
6a1c917
Compare
6be520c to
6c37ec6
Compare
- style changes to LinkTokenChild contract - additional useful documentationn
lawrencexia
left a comment
There was a problem hiding this comment.
👍 to unblock merge - with the understanding that this branch has previously been reviewed, audited, and deployed
LinkTokenChildcontract, an access-controlled mintable & burnable LinkToken, for use on sidechains and L2 networks