Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Detecting ZK EVM contracts deployment is done similar to the OP stack way. In short:
code_change
ZkEVMDeployerContract
, so for these we additionally check theNewDeterministicDeployment
event emittanceTransparentUpgradeableProxy
so for these there is extra logicPolygonZkEvm
under a proxy we are checking that there is a set of very specific events along the deploymentPolygonZkEVMGlobalExitRoot
under the same proxy type we are even doing an RPC read call to the implementation address to make sure we detected the correct proxy addressAgain, I think one of the next steps should probably be to start using Substreams store modules in order to make sure we are correctly enriching one rollup entity instead of creating a new one, because right now we're relying on the separate sink logic to merge the data when updating data in Postgres, which doesn't seem to work well (we miss a lot of contracts' addresses for OP).
Another improvement I figured at the very end of this PR's work is to use RPC read calls in substreams to actually query the majority of the periphery contracts' addresses from one of the main contracts which can hold [almost] all of them.