The reason Gather downtime (see #74 ) seems to be an SSD issue
Optimism sent bulk contracts for verification
ipfs add takes 25 mins. Could this be causing many disk writes, degrading SSD? Currently the repo is both in its directory repository/ and being replicated to ~/.ipfs/. Using filestore feature should avoid replication.
Only looking for constructor arguments when bytecodes don't match but are the same length (e.g. with immutables). Should we look every time?
Note: We are scraping the creation code and constructor arguments from the block explorer.
Erigon meeting was on 03.11
They don't directly have a way to access creation codes but might consider to have it in v2. They asked us to come up with an estimation of how much space this data would take.
We might try to convert to badgerds at some point. That's why asked about the back up on S3 on Matrix. Ligi pointed out we have enough space on Komputing if needed.
Swarm has a file limit of 5mb. Not many contract and metadata are on swarm, but it would be nice as a backup content-addressed file service if we publish the repo there.
We are scraping the creation code from block explorers and it is not really favorable.
There's an Erigon archive run running.
Action Items
As Optimism Mainnet is soon (Nov. 11) verifying Testnet contracts should be a priority.
Take a look if there are files larger than 5mb on the repo.
The compiler marks immutable positions on bytecode so we should be able to match excluding immutables on bytecode. Then we should also distinguish runtime bytecode vs. creation bytecode match and document this.
Convert the SQL db to LevelDB with current complete contract data to find out an upper limit storage requirement Erigon asked from us.
ipfs add
takes 25 mins. Could this be causing many disk writes, degrading SSD? Currently the repo is both in its directoryrepository/
and being replicated to~/.ipfs/
. Usingfilestore
feature should avoid replication.