Add block info & ram delta to action_trace

[heifner]

Resolves #5149

action_trace & transaction_trace changes:

• Add block_num, block_time, producer_block_id, context_free to action_trace
• Add block_num, block_time, producer_block_id to transaction_trace
• Add ram_delta per account to action_trace

mongo_db_plugin chnages:

• Update block_state with irreversible=true on irreversible signal
• Add transaction_trace status to each action_trace
• Insert transaction_trace before its action_traces

[arhag]

Return optional<block_id_type> instead.

[arhag]

Using optional<block_id_type> instead. Empty value for the case when _block_status == controller::block_status::incomplete.

[arhag]

Use optional<block_id_type> instead. Same for the transaction_trace below. Traces emitted from an incomplete block would leave the producer_block_id as empty.

Then later in mongo_db_plugin, avoid adding the action traces or transaction traces to the database if the producer_block_id is empty. This way traces from speculatively executed transactions are not included in the Mongo database which can avoid potential confusion for consumers of that database.

Due to forks, it could be possible for multiple incompatible action traces with the same block_num and trx_id to exist in the database. And if the producer double produces a block, even the block_time may not disambiguate the two action traces. Without a producer_block_id to disambiguate and determine if the action trace comes from an orphaned fork branching off of the blockchain, consumers of the Mongo DB database may be reacting to a stale action trace that never actually executed in the current blockchain.

It is better to avoid this potential confusion by not logging traces from speculative execution, i.e. emitted from an incomplete block. This means that traces will not be properly recorded in speculative read-mode, but users should not be using the mongo_db_plugin in that mode anyway. It would be good if the mongo_db_plugin refuses to record any traces, whether they have producer_block_id set or not, if the node is operating under speculative read-mode; or better yet, the mongo_db_plugin could refuse to run in speculative read-mode. By generally not logging traces with empty producer_block_id in the mongo_db_plugin, it does however have the benefit that even with any of the other read-modes other than speculative (for example head), you do not get unneeded and inaccurate traces from speculatively executed transactions.

[arhag]

Instead of explicitly resetting for each action, move this field to apply_context.

[arhag]

With the change to optional<block_id_type>, the last argument of this function call would be optional<block_id_type>() instead of block_id_type().

[arhag]

Instead of adding this line here, you can create a new wrapper function in apply_context:

void apply_context::add_ram_usage( account_name account, int64_t ram_delta ) {
   trx_context.add_ram_usage( account, ram_delta );
   account_ram_delta[account] += ram_delta;
}

Then all calls to transaction_context::add_ram_usage in eosio_contract.cpp and apply_context.cpp could be replaced with calls to apply_context::add_ram_usage.

[heifner]

This allows our nodeos_run_test.py --mongodb test to pass since it has the same nodeos as both a producer and running the mongo_db_plugin. I figured people running a single test node might find that useful.

[sim31]

I think account_ram_delta will be a very useful field. So I'm looking forward for this getting merged. But I see currently each element in account_ram_delta is an array which represents a pair (account, delta). I noticed, it could make it kind of complicated to make queries for this kind of schema. Would it be possible to make it an object?

[heifner]

Not sure why array is more difficult than an object. Can you provide an example of what you would like that would be easier.

[sim31]

Say, I want to get all actions where account A payed for RAM. Now I have to query array of arrays for that. I've tried in ways, which seemed straightforward to me first - they didn't work. I had to dig around on the internet to find out how to do that, but that's not the problem. The problem is that I've found in multiple places where people say that that's a bad document structure and there will be problems when trying to do aggregation for example. Here for example.

Now, let's say I want to create an index on the payer field, to make the query I mentioned above faster. Didn't have time to think about it much yet, but I have no idea how to do it for the current document structure. Would be straightforward if account_ram_delta would contain objects. Now I could only find this so far, which again suggests that it's not the best document structure.

I'm under impression mongodb expects objects to be used these kind of scenarios and it's probably optimized better if objects are used as well.

[heifner]

@sim31

	"account_ram_deltas" : [
		{
			"account" : "eosio",
			"delta" : -128
		},
		{
			"account" : "gyydsmbxguge",
			"delta" : 128
		}
	],

Does this work for you?

[heifner]

@arhag Ready for your review of changes.