Validator substate fetching problem

[stringhandler]

Problem

A user may provide an unspecified number of inputs. It becomes the validators responsibility to fetch these from remote nodes (which it technically has to connect to anyway). This could cause a massive burden on system resources and lots of queuing.

Possible solutions:

a. A user transaction must submit all substates for execution.

This would typically happen through the indexer.

If the user provides incorrect substates, this will be caught in the consensus as a foreign shard will vote to ABORT.
Pros:

• Simple

Cons:

• new transaction message sizes may be big (what is the upper bound?)
• user data may become out of date quickly
• potential for abuse

b. Foreign shards send their local substates along with the transaction to other remote shards.

Execution occurs once all substates are received. To reduce the validator burden, we could also require the user to submit the transaction to at least one replica in all shards involved.

Pros:

• transactions with erroneous inputs are never executed/are ABORTed without executing
• vns that are not involved can simply discard the transaction (we assume that only input shard vns can submit to output shard vns)

Cons:

• transactions may include inputs shards that arent actually used by the transaction to waste vn resources (fees should account for this assuming we are able to cheaply validate the validity of fee_instructions)

c. Execute once substates are exchanged in consensus

Add another initial stage where substates are received and execution takes place once consensus has begun. Transactions start with transactions in the <New, is_ready=true> -> <Proposed, is_ready=false> state, and once all substates are received <Proposed, is_ready = true>

Pros:

• transactions with erroneous inputs are never executed/are ABORTed without executing

Cons:

• extra round of consensus
• cannot tell what the output shards are until later

[stringhandler]

I like option A