Andrew7234/contract accounts #428
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ptrus
reviewed
May 26, 2023
1 task
mitjat
approved these changes
Jun 2, 2023
| creation_tx: | ||
| type: string | ||
| description: The Oasis cryptographic hash of the transaction that created the smart contract. | ||
| creation_bytecode: |
There was a problem hiding this comment.
Just to have a discussion thread:
Reminder that you said you'd up the number of rounds in the e2e regression test. Maybe 10k is good? It takes almost exactly 2min on my machine, which feels like a decent amount of time to me. Or maybe 5k.
Might be worth a separate PR (before this one goes in) just because of all the diff noise. Your call.
There was a problem hiding this comment.
I'll update this in a follow-up PR - need to also add new contract accounts to query in the e2e tests
Andrew7234
force-pushed
the
andrew7234/contract-accounts
branch
from
e3b2234 to
f9cf4a2
Compare
ptrus
approved these changes
Jun 7, 2023
|
Looks good to me now, thanks! |
[analyzer] store contract address and tx
[openapi] add contract information to /runtime/accounts/{addr}
[api] add contract fields to /runtime/accounts/{addr}
[analyzer] store contract creation bytecode
[api] show contract creation bytecode
[db] add creation/runtime bytecode for evm contract accounts
nit
[db] standardize pkey format; remove evm contract fields
[openapi] address comments
address comments; simplify fields
fix bad rebase
linter
update description
Andrew7234
force-pushed
the
andrew7234/contract-accounts
branch
from
c966425 to
7e2fa47
Compare
This was referenced Dec 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Task
The indexer does not differentiate between "normal" accounts and accounts that represent a smart contract in EVM. For thet latter, we could expose an additional (structured) field in the API, with information like
Side task: We promise to show the address of the newly-created contract in our openapi docs promise as the
tofield: https://github.com/oasisprotocol/oasis-indexer/blob/46e5f0e8f65b414d7e6ce0b2037b223a91097540/api/spec/v1.yaml#L2082-L2082. Populate it. (Note: Maybe Peter Us will do it; coordinate)Implementation: A possible approach is to expand/reuse the
evm_tokensDB table (which currently contains metadata about contracts that look like ERC-XX tokens) into a more generalevm_contractstable, with the above additional columns. Or else (preferred; discussed between Mitja and Peter Us) we leaveevm_tokensfocused on token-like metadata, and split off the remaining contract metadata into a new table.This PR
This PR solves part of the task, by adding the basic structure for contract account information when a runtime account address happens to also represent a smart contract.
Several fields; notably
bytecode,abi, andverifiedare left empty or default to false currently. These fields will be populated by the evm tokens/contract analyzer in a future PR.Testing:
Ran for ~2k blocks; successfully tested that contract accounts on both emerald and sapphire behave as expected:
Side note*: The additional fields are not currently included in the
run.shapi test cases since there are no contract accounts within the first 100 blocks.. filing a ticket to expand this.Discussion copied from elsewhere:
creation_txfield can be populated by the runtime analyzer, but from my understanding thebytecodeandverifiedfields will need to be populated by the evm_token_analyzer or something similar. That seems to overlap with evm/sourcify: support EVM contract verification via Sourcify #429 to download the ABIs of existing contracts - so is populatingbytecode/verifiedout of scope for this ticket?