Support for pre-Damask runtime rounds #362

mitjat · 2023-03-23T23:37:28Z

This PR brings support for indexing "old" runtime blocks. Changes:

Refactor: Extracts all runtime-related gRPC methods into a new RuntimeApiLite class. This mirrors the existing ConsensusApiLite in scope: provides 1:1 mapping to a subset of RPCs, responses are encoded in indexer-internal types. (Those types often contain fields from the latest oasis-core or oasis-sdk, so we're not fully disconnected from them, but it's a step in the right direction.)
Tweaks GetBlock() so it supports old rounds. This is actually a Cobalt vs Damask issue, because we ask technically ask consensus (specifically, its roothash app) for the runtime block info. And its API has changed going from Cobalt to Damask.
Reimplements event parsing from oasis-sdk (and uses this reimplementation) such that each SDK Event CBOR is parsed as either a) a list of events or b) a single event. Structure (a) is used for most rounds; structure (b) is used for a few 1000 earliest rounds of Emerald :)

Testing:

Indexed emerald from blocks 1 to 114_297, and also at recent heights. No crashes/errors.
reindex_and_run.sh for 100 rounds in Damask.

analyzer/runtime/extract.go

Andrew7234

Looks good; mostly minor comments. The runtime block processing looks cleaner now, thanks

storage/oasis/runtime.go

analyzer/consensus/consensus.go

Andrew7234 · 2023-03-29T23:43:58Z

api/v1/types/util.go

-	Erc20Transfer = "erc20.transfer"
-	Erc20Approval = "erc20.approval"
+	Erc20Transfer = "Transfer"
+	Erc20Approval = "Approval"


was there a specific reason for this?

yeah what did these erc20. prefixes used to do?

I'm pretty sure we just accidentally mis-named these when introducing them. We use these as event names for ERC-20 tokens, and the Transfer and Approval names are prescribed by ERC-20. We don't read these names from the ABI currently, but we will, and if we did now, these are the names that would come out of there.

Not related to the rest of the PR, just a drive-by bugfix. It doesn't affect anything, other than how we tag ERC-20 events in our output. @lukaw3d @csillag @buberdds FYI - these are the new values you'll see in evm_log_name once this change deploys. IDK if you depend on the old values in any way.

not clear that having the erc20. prefix was wrong. this system of evm log "names" is completely our own invention. removing the prefix actually seems a little lossy. I just looked, and we use these values as the evm_log_name column. that looks like it's our substitute for the topic id, which the event name doesn't fully convey (it also hashes the parameter types). with the "erc20." we had at least a fighting chance.

Log/event names are not our invention. The topic of the event is derived from the name and the types of its params, see e.g. "Topics in Ethereum Log Records" here, or how the event API/ABI defines the name here.
We do expose the topic (which is what we'll eventually want to support filtering on, presumably), but it's a little hidden, in the untyped JSON body field. Example from indexer DB:

runtime | emerald round | 2784 tx_index | 0 tx_hash | e415d067861d27a50331bc1ba66097af6cc034b53d1c379c07be858815cc778c type | evm.log body | {"address":"oXu9ULEcodbSP5Ca5AxBNNghrF4=","topics":["3fJSrRviyJtpwrBo/DeNqpUrp/FjxKEWKPVaTfUjs+8=","AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=","AAAAAAAAAAAAAAAAisMZWuyjmKrHiCUg3RnTx8XmnkY="],"data":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAUrfS3MgM0uQAAAA="} evm_log_name | Transfer evm_log_signature | 3fJSrRviyJtpwrBo/DeNqpUrp/FjxKEWKPVaTfUjs+8= evm_log_params | [{"name": "from", "value": "0x0000000000000000000000000000000000000000", "evm_type": "address"}, {"name": "to", "value": "0x8ac3195aeca398aac7882520dd19d3c7c5e69e46", "evm_type": "address"}, {"name": "value", "value": "100000000000000000000000000", "evm_type": "uint256"}] related_accounts | {oasis1qqm0rpeswnu8a5p0rphkppg2zulwrg57zskpxp0j,oasis1qqctk3c8a2ualcwufcxn337hchdflyjurgdmqt3e}

I'm open to eventually surfacing the topic(s) (or maybe just the first one, and only for non-anonymous events? i.e. the topic that represents the event signature/type) in a dedicated field.

that's a different "name," originating from solidity code. EVM logs don't have a name, only topic. as the page describes, solidity contracts in particular derive the topic from a name and parameter types.

We do expose the topic (which is what we'll eventually want to support filtering on, presumably)

oh in body, great. hadn't noticed that

Andrew7234 · 2023-03-29T23:58:00Z

storage/oasis/nodeapi/universal_runtime.go

+// Implementation of `RuntimeApiLite` that supports all versions of the node ABI
+// and all versions of the oasis-sdk ABI. (SDK events are CBOR-encoded according


just curious - there's just a single node ABI used here right? But the resulting grpc.RawMessage is then decoded into one of two possible sdk ABIs? (cobalt/damask)

I'm perhaps splitting hairs here. All I wanted to say was that this struct works with all versions of everything. It speaks two node ABIs (cobalt and damask, although technically those are not ABI version names, and ABI changes just happen to coincide with launching a new dump-restore chain). See GetBlockHeader() to see two versions being supported; for the other calls, i.e. GetTransactionsWithResults() and GetEventsRaw() and SimulateCall(), damask and cobalt use the same ABI and so we just pretend everything is damask and use the damask SDK.

By SDK decoding and ABIs, I meant how events are encoded. Those are decoded with support for all versions in https://github.com/oasisprotocol/oasis-indexer/blob/90968f1819dcf486c74df323d52b48f081a7ebfb/analyzer/runtime/decode_events.go#L14-L14; note the use of unmarshalSingleOrArray. I think all of this decoding should really happen in nodeapi so that nodeapi can present a unified internal type to the indexer, but I didn't want to refactor more than I had to in this PR.

pro-wh · 2023-03-30T18:00:44Z

storage/oasis/runtime.go

-			continue
-		}
+		// Iterate over all networks and find the one that contains the runtime.
+		// Any network will do; we assume that paratime IDs are unique across networks.


paratime IDs are chosen by the entity that registers them

Oooh! A potential for some malarkey then. Very good to know, thanks.
I just left a TODO/note of this; once we sort out how to merge this with your #352, this hacky approach will hopefully not be needed any more.

Actually, we'll need to tweak/expand DefaultChains from #352 a little so that they include some runtime info. The existing DefaultNetworks from oasis-sdk assign a paratime to a specific chaincontext, but really with dump-restores they can be assigned to a "metachain", i.e. to all of the chaincontexts that comprise(d) mainnet.
We could do that inference programmatically, but I think it will be much more readable to just copy paste a li'l more info over into DefaultChains and then use it here.

Ah actually your PR intentionally limits its scope to consensus only. Added a task to https://github.com/oasisprotocol/oasis-indexer/pull/352/files#r1152431146 where I previously started discussing follow-ups.

yeah, and that DefaultNetworks lookup also gets complicated by the custom chains used for testing etc.

pro-wh · 2023-03-30T18:02:49Z

api/v1/types/util.go

@@ -2,9 +2,11 @@ package types

 import "fmt"

+// Hardcoded event names emitted by ERC-20 contracts.
+// TODO: Remove these once we are able to query the ABI of the contract.


oh we have the ABI checked in now. it's in the analyzer directory tho. evmabi.ERC20

You're right, we could extract them from the ABI already. It's just that it's only one ABI that we have, so it was easier to hardcode than to implement "properly", the way we'll have to once we support arbitrary contracts/ABIs/events. I reworded the TODO. I'm not implementing it here though if that's what you meant; it's completely out of scope for the PR.

I just looked at the abi structures, and it's all Events map[string]Event, so we wouldn't be able to get it from a constant anyway

pro-wh · 2023-03-30T18:09:32Z

analyzer/runtime/decode_events.go

+// unmarshalSingleOrArray tries to interpret `data` as an array of `T`.
+// Failing that, it interprets it as a single `T`, and returns a slice
+// of size 1 containing that `T`.
+func unmarshalSingleOrArray[T any](data []byte, dst *[]T) error {


wow our first generic code

being dragged kicking and screaming into the Century of the Fruitbat :)
(obscure reference, move along)

pro-wh · 2023-03-30T19:00:48Z

analyzer/runtime/extract.go

 				// Inaccurate: Treat as not using any gas.
+				// TODO: Decode the tx; if it failed with "out of gas", assume it used all the gas.


maybe we should treat transactions that came before the GasUsed event as always using all the gas unless the authentication failed

eh let's discuss that outside of this pr

Possibly. Or we could do what I described in the comment, or something even more complex, like your suggestion from Slack:

in that case we can do
auth failed -> no gas used
insufficient balance (outside evm) -> no gas used
most things within evm -> all gas used

Or we could leave things as-is, which I argued for in slack (but didn't update this TODO afterwards):

I tried charging full gas_limit to all txs, and the fallout took me a while to figure out ...

It turns out that some failed txs have a huge gas_limit; for example, I hit one with MAX_INT64. When you add other txs' gas limits to it, the block gas limit overflows int64 (and could easily overflow uint64). So that blows up in other places that expect total block gas to not exceed uint64; the db even uses int64. [GitHub edit: Maybe we'd avoid this with the full three-pronged approach above, but I have no impulse to play around more; see also below.]

Long story short, I'm leaving failed txs with no GasUsed event as-is, meaning we estimate them to have used 0 gas.
I also like this product-wise. If the gas we show is going to be a little wrong (and it always will be, no matter how we refine our heuristic), it should at least be easy to explain on the rare occasion when we have to acknowledge the discrepancy.

So -- removing the TODO.

…e yet. No support for very early blocks.

…m internal struct

…ingle list

…not from internal struct

… in a single list

…cting events

pro-wh · 2023-03-30T20:44:46Z

storage/oasis/runtime.go

@@ -45,24 +48,6 @@ func (rc *RuntimeClient) EVMSimulateCall(ctx context.Context, round uint64, gasP
 	return rc.nodeApi.EVMSimulateCall(ctx, round, gasPrice, gasLimit, caller, address, value, data)
 }

-// Name returns the name of the client, for the RuntimeSourceStorage interface.
-func (rc *RuntimeClient) Name() string {


😈 goodbye name

pro-wh · 2023-03-30T20:59:30Z

analyzer/runtime/extract.go

 		blockData.Size += blockTransactionData.Size
 	}
 	return &blockData, nil
 }

-func extractEvents(blockData *BlockData, relatedAccountAddresses map[apiTypes.Address]bool, eventsRaw []*nodeapi.RuntimeEvent) (*extractEventResult, error) {
+func sumGasUsed(events []*EventData) (sum uint64, foundGasUsedEvent bool) {


there aren't really multiple though, are there?

pro-wh

reviewed

mitjat requested review from aefhm, Andrew7234 and pro-wh as code owners March 23, 2023 23:37

Base automatically changed from mitjat/statecheck-no-internal-apis to main March 24, 2023 21:56

mitjat force-pushed the mitjat/cobalt-runtime branch 3 times, most recently from 17e0ed1 to c80694f Compare March 24, 2023 23:46

mitjat commented Mar 27, 2023

View reviewed changes

analyzer/runtime/extract.go Outdated Show resolved Hide resolved

mitjat marked this pull request as draft March 28, 2023 00:23

mitjat force-pushed the mitjat/cobalt-runtime branch from c80694f to f1081e5 Compare March 28, 2023 20:17

mitjat marked this pull request as ready for review March 28, 2023 21:46

Andrew7234 approved these changes Mar 30, 2023

View reviewed changes

pro-wh reviewed Mar 30, 2023

View reviewed changes

mitjat force-pushed the mitjat/cobalt-runtime branch from 0c4f7be to 7a221cb Compare March 30, 2023 19:31

mitjat added 13 commits March 30, 2023 12:31

cleanup: storage/api: RuntimeAllData: Remove unused fields.

feef1cf

hardcode cobalt history (chain context mapping etc)

a78f9b9

comment

140ad38

evm: Fix ERC-20 event names

dd9a2e2

storage/runtime: Support fetching data from Cobalt. No ParatimeApiLit…

f617dee

…e yet. No support for very early blocks.

analyzer/runtime: Correctly decode early-Cobalt sdk events

496094a

analyzer/runtime: Document lack of GasUsed event

ddd9aa3

Abstract node access into RuntimeApiLite

f1931f2

nodeapi: Use indexer-internal types for SDK events

35a92ec

Rename RuntimeEvent->RuntimeRegisteredEvent, SdkEvent->RuntimeEvent

af6a878

nodeapi: Visually separate consensus and runtimes

73dbcee

grpc: Connect to local sockets without TLS

4470833

bugfix: Generate runtime block hash directly server response, not fro…

88f5d40

…m internal struct

mitjat added 5 commits March 30, 2023 12:31

analyzer/runtime: Deduplicate some info in internal structs

9b897dc

analyzer/runtime: BlockData: Store tx events and non-tx events in a s…

e937ba2

…ingle list

fixup! bugfix: Generate runtime block hash directly server response, …

0bfb548

…not from internal struct

fixup! analyzer/runtime: BlockData: Store tx events and non-tx events…

175aa9c

… in a single list

cleanup: analyzer/runtime: extractEvents(): Limit scope to just extra…

e3d4029

…cting events

mitjat mentioned this pull request Mar 30, 2023

config: archive node configuration #352

Merged

mitjat force-pushed the mitjat/cobalt-runtime branch from 7a221cb to 72ad55f Compare March 30, 2023 20:11

PR review: Reword some comments

72ad55f

mitjat enabled auto-merge March 30, 2023 20:12

mitjat mentioned this pull request Mar 30, 2023

refactor: analyzer/runtime: Store a more-parsed tx in the db #368

Merged

mitjat merged commit 341df91 into main Mar 30, 2023

mitjat deleted the mitjat/cobalt-runtime branch March 30, 2023 20:37

pro-wh reviewed Mar 30, 2023

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for pre-Damask runtime rounds #362

Support for pre-Damask runtime rounds #362

mitjat commented Mar 23, 2023 •

edited

Loading

Andrew7234 left a comment

Andrew7234 Mar 29, 2023

pro-wh Mar 30, 2023

mitjat Mar 30, 2023

pro-wh Mar 30, 2023

mitjat Mar 30, 2023

pro-wh Mar 30, 2023

Andrew7234 Mar 29, 2023

mitjat Mar 30, 2023

pro-wh Mar 30, 2023

mitjat Mar 30, 2023

mitjat Mar 30, 2023

pro-wh Mar 30, 2023

pro-wh Mar 30, 2023

mitjat Mar 30, 2023

pro-wh Mar 30, 2023

pro-wh Mar 30, 2023

mitjat Mar 30, 2023

pro-wh Mar 30, 2023

pro-wh Mar 30, 2023

mitjat Mar 30, 2023

pro-wh Mar 30, 2023

pro-wh Mar 30, 2023

pro-wh left a comment

		// Implementation of `RuntimeApiLite` that supports all versions of the node ABI
		// and all versions of the oasis-sdk ABI. (SDK events are CBOR-encoded according

		// Inaccurate: Treat as not using any gas.
		// TODO: Decode the tx; if it failed with "out of gas", assume it used all the gas.

Support for pre-Damask runtime rounds #362

Support for pre-Damask runtime rounds #362

Conversation

mitjat commented Mar 23, 2023 • edited Loading

Andrew7234 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pro-wh left a comment

Choose a reason for hiding this comment

mitjat commented Mar 23, 2023 •

edited

Loading