Transaction Processing

[noamnelke]

Transaction syntactic validation

See SMIP #23 for transaction structure and encoding.

• Transaction type must be valid (supported types are currently 0-5).
• Transaction size must be within the bounds for the declared transaction type.
• For transactions that include a public key, the signature must be valid.
• For SVM transactions, SVM validation must pass.

Transaction counter/nonce and batching

We must decide on what makes the transaction counter/nonce valid and how to handle batching before specifying the following:

• Criteria for gossip propagation.
• Criteria for mempool admittance and eviction.
• Prioritization of transactions in the mempool for inclusion in blocks.
• Selecting specific transactions for a block from a prioritized list.
• Transaction processing [when a layer is validated]

This topic, along with a proposal for adding a time-to-live value on each transaction, is discussed in this forum thread.

Gossip propagation criteria

• Transaction must be syntactically valid.
• Transaction counter must be greater than- or equal to the spending account counter.

Open questions

• Should we add a feasibility criterion? E.g. what if the transaction counter is much higher than the account counter? What if there's not enough balance in the account? Etc.

Transaction mempool admittance criteria

• Transaction must pass gossip propagation criteria.
• If the mempool is full, fee must be higher (per byte / transaction / gas unit) than the lowest ranking transaction.

Open questions

• What should be the mempool size limit?
• What should be the limit on number of competing transactions for the same counter? Could be 1-∞.

Transaction mempool eviction

When one of the transaction mempool admittance criteria changes - transactions should be evicted.

Limits on block content

See forum thread.

There should be limits on:

• Sum of the gas limit of all referenced transactions.
• Referenced transactions total byte size.
• Referenced transaction count.

The limits should be set such that the sum of the gas limit is the limiting factor. The other limits should be more relaxed, to make optimization easier in the common case.

Prioritization of transactions in the mempool for inclusion in blocks

• Higher fee transactions should be preferred.
• Transactions that are more likely to be applicable should be preferred (have sufficient balance, have a matching counter value with the account, etc.).

Selecting specific transactions for a block from a prioritized list

• There should be a cutoff in the list where it's likely that all the transactions above the threshold will be included in the layer.
• From above the threshold, miners should randomly select a number of transactions that satisfy the block content limits.

Syntactic validation of blocks

• Blocks that reference a syntactically invalid or unavailable transaction should be considered syntactically invalid themselves.
• Blocks that violate block size limits (bytes / transaction count / total gas) should be considered invalid.

Voting against blocks in the Hare protocol, if they have bad / too few transactions

Should we do something of this sort?

Withholding or granting rewards, based on included transactions

Should we do something of this sort?

Transaction processing [when a layer is validated]

1. Deterministic unpredictable sorting and de-duplication of transactions that appear in contextually valid blocks.
2. For each transaction:
   1. Contextually validate (matching counter, sufficient balance).
   2. Execute (using SVM / simple transfer handler).
   3. Store receipt (all transactions included in contextually valid blocks should have a matching receipt).

Fees

• All executed transactions incur a fee.
• Simple transactions incur the declared fee.
• SVM transactions incur a fee based on declared gas price and actual gas consumed.
• SVM transactions resulting in an error will pay for the gas consumed until the error occurred.
• SVM transactions that consumed the declared gas limit will pay the maximum amount possible (gas_price x gas_limit).

Important note: While charging fees is part of this SMIP, distributing proceeds from fees to miners will be covered by a separate SMIP once the reward scheme is finalized.

Open questions

• Should we charge the fee or partial fee from transactions that were included in blocks but execution was never attempted (e.g. due to insufficient balance)?

[avive]

Add a receipts generation and storage in the db step to Transaction processing section. All execution cases should be considered. Every executed transaction needs to generate a receipt even if it fails. Correct fees needs to be deducted in cases such as svm runtime error, etc...

[avive]

Regarding: SVM transactions resulting in an error will pay for the gas consumed until the error occurred.. I think that what you want here is for callers to pay the maximum amount to discourage attacks that call with bad params to create an exception close to beginning of execution. @lrettig

[avive]

Regarding SVM transactions incur a fee based on declared gas price and actual gas consumed. I think you should check with @YaronWittenstein - I think that all vault txs for sm 0.2 and 0.3 can have fixed gas costs defined in the template on the mesh. At least there was a discussion on this in the last svm related research-dev meeting - I just don't 100% sure what was the conclusion. Yaron - are we going with fixed gas for svm txs for 0.3 or not?

[avive]

q: can a layer be verified more than once? e.g. in case of after self-healing. if yes - can a tx be executed more than once? if yes, does the new receipts just over-ride the old receipts generated by executions of txs in that layer?

[avive]

Add to open questions: do we need to support additional transaction types beyond what we defined in this smipp? https://github.com/spacemeshos/SMIPS/issues/23

[noamnelke]

I think that what you want here is for callers to pay the maximum amount to discourage attacks that call with bad params to create an exception close to beginning of execution.

Why? If a transaction causes an error early it will cost the system very little, and pay a proportional fee. Why call it an attack or discourage it? You may as well create a smart contract that does nothing and call that - it would be identical. Is that an attack?

I think that all vault txs for sm 0.2 and 0.3 can have fixed gas costs defined in the template on the mesh.

This is an implementation detail - you're saying that instead of measuring actual consumed gas we'll query it from the contract - fine. Doesn't matter for the purpose of fee calculation.

can a layer be verified more than once?

Sure, but if a layer gets rolled back and re-applied then the state is also rolled back to before that layer. The transaction will be executed a second time, but the results of the first execution will be discarded.

do we need to support additional transaction types beyond what we defined...?

This is being discussed in the context of transaction batching, counter/nonce and [dis]allowing gaps. I don't think it makes sense as a stand-alone question.

[avive]

There are reasons why all gas is consumed on smart contract runtime exception and this is how smart contract execution works in eth 1.0. Research should form a concrete opinion about this - I'm just raising this as a consideration.

[noamnelke]

@avive

There are reasons

It seems that it was just tech-debt that was fixed 3 years ago with EIP-140.

[lrettig]

It seems that it was just tech-debt that was fixed 3 years ago with EIP-140.

I agree with this assessment. There may be specific scenarios where a smart contract developer wants the contract to consume all remaining gas on an error, or in certain scenarios, but I can't think of any off the top of my head and it seems unnecessarily punitive in general. As @noamnelke pointed out,

If a transaction causes an error early it will cost the system very little, and pay a proportional fee.

There's a separate-but-related question here, which we discussed yesterday, and which is unique to the mesh: if a tx includes a very large maxgas, but only ends up consuming a small portion of that gas, it still fills block space and prevents other transactions from occupying that space. So we clearly have to charge something for unused maxgas. We need to think, and maybe try some simulations, to figure out whether the cost should be linear (e.g., 1/2 of unused maxgas) or sublinear (e.g., log of unused maxgas) or something else.

[lrettig]

q: can a layer be verified more than once? e.g. in case of after self-healing. if yes - can a tx be executed more than once? if yes, does the new receipts just over-ride the old receipts generated by executions of txs in that layer?

A receipt includes a merkle proof of inclusion/execution of a tx (and points to the output). The old receipt would be meaningless as the state will have been updated (so its merkle proof would point nowhere).

[noamnelke]

@lrettig

So we clearly have to charge something for unused maxgas

I raised this in the meeting and suggested charging some portion of the gas for unused maxgas. Tal agreed and called it a discount for the unused gas, that can be set anywhere between 0-100% (we probably don't want it at 100%). We didn't consider making it non-linear, but it's definitely something to consider.

In any case, I think there's consensus that we'll charge something for unused maxgas and it's not critical to decide this early, as changing the exact formula should be easy.

[lrettig]

I suspect the "right" way to figure this out is by simulation. This is a great example of a small, well-defined problem that has an optimal answer - i.e., there is some number that will minimize waste (without sacrificing security).

[countvonzero]

implemented