EIP-0008: New Transaction Validation with Just-In-Time Costing

[aslesarenko]

UPD:
Completely revised version:

1. rewardTx and chargeTx removed thus senders are not penalized for invalid transactions
2. collatInputs are not required
3. JITC for reduction combined with AOT for Sigma Protocol proposition verification
4. Default cost limit selection is motivated and described (to make the switch transparent for existing apps)
5. Overall changes to Ergo Protocol v1 are minimized.

[kushti]

Please note that the fee box is not a part of the protocol.

[aslesarenko]

This part of JIT costing depends on the concrete implementation of miner fees.
They are both "a part" or "not a part" of the protocol (whichever the definition of the protocol).
If some other fee protocol will be developed in future (if any), it should keep JIT costing in mind.
I consider JIT costing is more important than some abstract fee protocol flexibility.
Even if the new version of fees protocol will be added, it can always be made compatible with the needs of JIT costing.

[kushti]

"All checks performed in Protocol v1" means protocol changes, right? On the definition of the protocol, see V() predicate in GKL 15.

[aslesarenko]

No, it means currently active protocol.
By this item I refer to all existing validation checks collectively.
Other items are new.
Clarified this in the text.

[kushti]

@aslesarenko I would like to propose to not to break UTXO semantics, bringing fee model (apart from storage rent component) into the protocol, vote for block intervals (which confronts with NiPoPoWs and not analyzed in a rigor way) etc. Also please note that not just miners bear validation costs but all the full-nodes propagating transactions. And current applications should stay. Thus let's discuss how to minimize changes, not to make a lot of reckless ones.

[aslesarenko]

Thus let's discuss how to minimize changes, not to make a lot of reckless ones.

Yes, this is the goal of doing "proposal first": discussion and clarification. To streamline the process, lets follow the following simple rules:

1. leave the comments "in context", related to specific lines of the text (avoid general comments at the end)
2. write separate issues/questions as separate comments, so they can be discussed and resolved independently
3. if there is a claim that something is broken, please give the reasoning, why and how, so the claim is clear and can be addressed.
4. avoid raising cosmetic issues and focus on semantics first.

After collecting and clarifying the issues/questions in this way I can create the next version.

[robkorn]

JIT costing is likely to be prohibitive to light clients which isn't great.

[aslesarenko]

JIT costing is likely to be prohibitive to light clients which isn't great.

Please see my response above.

[kushti]

@aslesarenko @polarker @robkorn Let me put this EIP in another perspective.

In the first place, block validation (consensus-critical verification protocol) works in the same way regardless a costing procedure, if the procedure ensures that maximum time to validate a block (on commodity hardware) is defined by the cost limit per block, and also validation time is secure ( << expected block interval, so 1-2 seconds at most in case of Ergo). If costing procedure is correct (there are no mispriced instructions leading to spam attacks like Ethereum suffering from back in Autumn'2016), then there are no critical spam issues on this level, thanks to PoW making producing blocks a costly venture. Thus we should look and fix problems on other levels, namely, propagation and block assembly.

In Bitcoin, a node propagating transactions is doing following steps:
network transfer -> parsing -> UTXO fetching (from db) -> signature checks

in the worst case, a failure happens during the last stage (signature validation). There were spam attacks against UTXO fetching stage (https://en.bitcoin.it/wiki/CVE-2013-2293). Currently, if transaction is not valid, a source peer got some penalty with a ban happening when penalty score reaching some threshold AFAIK.

Similarly, in AOT-Ergo:
network transfer -> parsing -> UTXO fetching (from db) -> AOT -> interpretation -> signature checks

in JIT-Ergo:
network transfer -> parsing -> UTXO fetching (from db) -> interpretation -> signature checks

However, in both cases the best spam strategy is the same: do a transaction with a cost about the limit but invalid signature. In regards with EIP-8, an attacker can use a heaviest WKC contract to avoid collateral boxes.

Thus for both AOT- and JIT-Ergo, a solution is about finding a proper fee and penalization mechanism for the p2p network. Maybe also with breaking transactions into different classes (like standard and non-standard transactions in Bitcoin), but only on the mempool level.

[polarker]

Miners could not calculate MaxTxCost when assembly a candidate block because N is not known

[aslesarenko]

MaxTxCost is fixed, same as MaxBlockCost, and can be adjusted via voting. Here epsilon is a variable which compensate for changes in N to preserve equation.
Please see the paper for rationale behind limiting per-transaction cost.

[polarker]

N is the number of transactions in a block according to your definition. Blocks could have different numbers of transactions, so N is dynamic and therefore MaxTxCost. That's why I don't get it when you say MaxTxCost is fixed.

[polarker]

N is known toverifiers, so it's not a problem for verifers. But N is unknown to block assemblies when building the block, so it will cause issues when preparing block candidates when txs are sorted according to reward efficiency. Let me try to give a concrete example in the following.

[polarker]

Let's assume that MaxBlockCost = 100, epsilon = 1. In mempool, there are 11 txs: Tx(50), Tx(10) * 10 where the numbers inside the parenthesizes are tx costs. Let's also assume that the rewards per unit are the same for all these transactions. If the block assembler takes Tx(50) first, then there is no way for it to add other txs, because MaxTxCost will be lower than 50. The assembler could take the 10 transactions Tx(10) * 10, but this will make the assembly algorithm complicated in general. However, without MaxTxCost limit, the block assembler could simply take Tx(50), Tx(10) * 50 which is invalid in your proposal. Attackers could exploit MaxTxCost to make the MaxBlockCost underused using such kind of ideas.

[aslesarenko]

Epsilon is helper variable, which will not be used in practice. I brought it here in order to draw the parallels with the paper, but it also brings some confusion.
Epsilon is purely theoretical parameter, which is here to compensate for changes in N.
When N changes so does the epsilon, while other parameters of the equation are fixed.

[polarker]

In that case, what would be the suggested values for MaxTxCost and MaxBlockCost? These values should be discussed and included in the proposal in my opinion.

[aslesarenko]

Probably yes, but they may also be voted, so I'm not sure we should put any specific value in the EIP.

[polarker]

I think costLimit should also be able to be set by sender in this case. Only when a user does not set costLimit, the verifier will use MaxTxCost.

[aslesarenko]

@polarker Yes, if the users want they can put a value in tx.feeOut.R4, thus taking control of the tx cost limit. The MaxTxCost is only used if tx.feeOut.R4 is not present.

[polarker]

thecostLimit will be selected by the verifier

Then maybe this sentence should be improved a bit, as it gives me the impression that the costLimit is always unknown and set by the verifier.

[aslesarenko]

It is mentioned in other parts of the text, but yes, please propose your formulation.

[polarker]

How about the following if I don't misunderstand the details:

When tx.accCost is not predictable, which may happen when tx has at least one context-dependent script (i.e. at least one script have conditions on HEIGHT, CONTEXT.headers, etc), then the sender can either 1) choose values for feeOut.value and costPrice based on estimation, or 2) choose a value for feeOut.value and use MaxTxCost for costPrice (see details)

[aslesarenko]

Fixed

[kushti]

Giving such semantics to R4 already breaks backwards compatibility for all the apps and standards using registers (mixer, EIP-4, DEX etc)