Network transactions

[Mirko-von-Leipzig]

Network transactions are a major unsupported feature where users may submit a public transaction which the network should execute when some user-defined conditions are met. The transactions must be public since they'll be executed and proven by the node operator.

There are some open questions regarding this feature, which we should discuss and then iterate on a design.

I'll enumerate my initial questions here, but will initialize discussion threads for them below.

1. How do we minimize DoS vectors? What are possible concerns.
2. Possible conditions.
3. Fee structuring.
4. Implementation.

[Mirko-von-Leipzig]

DoS minimization

How do we prevent users from submitting invalid transactions which cause the operator to waste time executing and proving only to have this fail?

One argument provided so far is that execution is cheap, and an executed transaction should be provable which minimizes this risk.

How do we prevent transactions that never complete? Do we restrict the instruction set of network transactions?

Similarly how do we minimize receiving transactions with too little gas? Gas estimation is often done by simulating/executing beforehand offchain but that won't work since the state may/will change. Once again we could restrict the instruction set to make gas estimation trivially calculable without simulation.

[Mirko-von-Leipzig]

Possible trigger conditions

What conditions should users be able to select. I'm just guessing here; I don't really know what would be desired.

1. Block height range, a maximum block height is already allowed (expiration height).
2. Note creation/consumption.
3. Account state change (private as well) i.e. trigger on any update to an account.
4. Storage change/matches (public account only)

Should conditions be combinable, if yes to what limit?

[Mirko-von-Leipzig]

@bobbinth if an input note is the original trigger indicating network transaction creation, would there ever be additional conditions required?

[Mirko-von-Leipzig]

Fee structuring

Maybe a bit premature/out-of-scope, but how do we structure things so node operators are encouraged to run these transactions? This will likely form part of the overall fee design for the protocol so not strictly necessary to discuss it here.

[Mirko-von-Leipzig]

Design attempt #1

1. Add a new RPC endpoint add_network_transaction.
2. Network transaction is submitted to mempool.
3. Mempool holds transaction until conditions are met.
4. Mempool spawns task to execute and prove transaction.
5. Mempool forgets the network transaction entirely.
6. Completed transaction is placed back in the mempool via the conventional Mempool::add_transaction method.

This elides error handling etc, but I think is fairly simple. What can occur is that the network transaction conflicts with another transaction submitted before the network transaction completes. This could be prevented around by marking the appropriate state inputs in some way, but that seems more complex for no good reason aka no reason to prefer the network transaction over the other.

This does raise the question of transaction selection/acceptance strategies, but in this case probably the operator could design a more general system where the mempool can evict transactions if an incoming conflicting transaction is deemed more valauable.

Transaction execution and proving can of course be delegated etc, and that design is orthogonal to this.

[PhilippGackstatter]

We may need to mark such accounts somehow, potentially via account IDs

Why do we need such a mark, isn't this a higher level concern? If I see that some account has a procedure with MAST root 0x1234 in its account code which is a known procedure doing push.1 exec.account::incr_nonce (i.e. it increments the nonce without authentication) then wouldn't that be enough for an operator or user to determine that an account is such a "shared account"?
This would guarantee that an account can be updated. On the other hand, if we introduce the mark, then without additional checks it will be just a hint and not a guarantee that an account can be updated (for example, what if the account has the mark but does not export 0x1234?)

The mark would definitely be useful for finding such accounts, but I'm not sure if it's really a protocol concern.

[bobbinth]

Yeah - I think putting this outside of the protocol is probably the right approach here. We'll need to come up with some strategy (could be simple at first) for the node to identify "shared accounts." Relying on MAST roots could work, but also feels a bit fragile.

[Mirko-von-Leipzig]

Oh great; that's much simpler then that I thought we needed :)

Accounts would be flagged on code creation/update. Though this might be awkward since we'll have to scan every output note for matching tags against some list of accounts? What would such a tag look like in practice?

Some prefix identifying that its a public transaction, and then the target account? The former so we can cheaply scan each note..

If the public account list is expected to be short-ish then we can just store it permanently in memory, otherwise we'll need to reach out to the store each time we encounter such a note which may or may not be an issue.

[igamigo]

Note tags already have an encoding for network notes (link), similar to the ones for directing notes to specific accounts.
If anyone can deploy a shared/network account, doesn't this also become a DoS vector? Specially if you are doing things like tracking them in memory.

[bobbinth]

Accounts would be flagged on code creation/update. Though this might be awkward since we'll have to scan every output note for matching tags against some list of accounts? What would such a tag look like in practice?

As @igamigo mentioned above, identifying if a note is for a specific account should be relatively straight-forward:

1. We care only about public notes - so, private notes can be ignored.
2. The first two bits of the note tag are enough to tell if a note is intended for network consumption.
3. The next 30 bits of the tag identify the account the note is intended for. There is a small chance that there could be a collision here - i.e., two "network accounts" have the same 30 bit prefix in their IDs, but I think this should be relatively easy to handle.

Also, to simplify things, we can make the process only "forward-looking". That is, when a network account is created, we don't scan any of the existing notes but start tracking only the incoming notes.

If the public account list is expected to be short-ish then we can just store it permanently in memory, otherwise we'll need to reach out to the store each time we encounter such a note which may or may not be an issue.

Hard to say - may be thousand or millions of such accounts. I probably would add a field in the database to mark network accounts as such. This way, when the node starts up it can just get a list of network accounts from the store. Similarly, we could attach some extra data to notes intended for public consumption to make re-starting the server easier.

If anyone can deploy a shared/network account, doesn't this also become a DoS vector?

Good point. We could probably have some kind of LRU-cache-like system where only the accounts which have some activity are kept in memory. This could be a future improvement though.

Also, since network accounts are public by definition, cost of creating them would be higher than for private accounts. We could try to structure the fee system to make it prohibitively expensive to create a large number of public accounts in a short period of time. Though this needs to be much better thought through.