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

aslesarenko · 2020-05-25T15:18:51Z

UPD:
Completely revised version:

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

eip-0008.md

kushti · 2020-05-26T10:21:37Z

eip-0008.md

+
+- All checks performed in Protocol v1
+- INPUTS contain at least one `p2pk(senderPk)` box
+- current height is within `feeOut.R6` interval


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

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.

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

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.

eip-0008.md

kushti · 2020-05-26T10:28:28Z

@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 · 2020-05-26T11:19:01Z

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:

leave the comments "in context", related to specific lines of the text (avoid general comments at the end)
write separate issues/questions as separate comments, so they can be discussed and resolved independently
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.
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.

eip-0008.md

robkorn

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

aslesarenko · 2020-05-26T16:01:41Z

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

Please see my response above.

kushti · 2020-05-27T09:22:27Z

@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.

eip-0008.md

polarker · 2020-07-04T09:48:31Z

eip-0008.md

+The solution proposed (see [2], Lemma1) incentivizes correct execution of scripts by rational miners
+under the condition that miners only accept to verify the transactions that has cost limit
+bounded by `MaxTxCost = epsilon * MaxBlockCost / N` where `MaxBlockCost` is the limit on block
+verification costs, `N` is the number of transactions in a block and `epsilon` is a


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

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.

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.

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.

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.

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.

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.

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

polarker · 2020-07-04T09:59:36Z

eip-0008.md

+5) When `tx.accCost` is not predictable, which may happen when `tx` have at least one
+context dependent script (i.e. at least one script have conditions on `HEIGHT`,
+`CONTEXT.headers`, etc), then the sender can choose any value for `feeOut.value` and the
+`costLimit` will be selected by the verifier (see [details](#maximum-transaction-cost))


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.

@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.

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.

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

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)

kushti · 2020-07-15T12:53:22Z

eip-0008.md

+than `MaxTxCost`. The limit is computed as `costLimit = tx.feeOut.value /
+tx.feeOut.R4[Long]` if the register is not empty, otherwise `costLimit = MaxTxCost`. 
+The value in the `R4` register is the NERG price of a unit of cost (`costPrice`).
+The `MaxTxCost` parameter is described in the [section below](#maximum-transaction-cost).


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

aslesarenko added 6 commits March 10, 2020 12:55

initial draft of eip-0005.md

664a325

added Contents, figures, JIT costing description

0f4b00a

eip-0007.md: added

b6f84bb

renamed file to eip-0008.md

d48d678

EIP8: Implementation of the Hard-Fork on Ergo network

048f196

eip-0005.md removed

fee2fe6

aslesarenko changed the title ~~EIP-8: JIT costing~~ EIP-0008: JIT costing May 25, 2020

kushti requested changes May 26, 2020

View reviewed changes

cosmetic changes

5f9d14d

robkorn reviewed May 26, 2020

View reviewed changes

eip-0008.md Outdated Show resolved Hide resolved

robkorn reviewed May 26, 2020

View reviewed changes

aslesarenko added 4 commits May 28, 2020 12:32

cosmetic changes (2)

a09ddb6

Context-independent scripts section

4c5978b

complete rewrite and removal of rewardTx

3d38aef

Sending Transaction section, New costing clarified

6778912

aslesarenko changed the title ~~EIP-0008: JIT costing~~ EIP-0008: New Transaction Validation with Just-In-Time Costing Jun 4, 2020

aslesarenko added 2 commits June 4, 2020 14:17

removed: Implementation of the Hard-Fork on Ergo network

4f5113d

Default Transaction Cost section

7eaf2a7

polarker reviewed Jun 4, 2020

View reviewed changes

eip-0008.md Outdated Show resolved Hide resolved

more fixes

1491b7a

aslesarenko mentioned this pull request Jun 8, 2020

[planning] Sigma roadmap 2020 ergoplatform/sigmastate-interpreter#629

Closed

14 tasks

aslesarenko added the S-ready-for-merge Status: This PR is ready for merge label Jul 1, 2020

polarker reviewed Jul 4, 2020

View reviewed changes

suggestion from @polarker

357a1db

kushti requested changes Jul 15, 2020

View reviewed changes

EIP-0008: simplification of JIT Costing description

4a59efd

arobsn mentioned this pull request Dec 7, 2022

Ready to merge/implemented PRs #86

Open

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

aslesarenko commented May 25, 2020 •

edited

Loading

kushti May 26, 2020

aslesarenko May 26, 2020

kushti May 26, 2020

aslesarenko May 27, 2020

kushti commented May 26, 2020

aslesarenko commented May 26, 2020 •

edited

Loading

robkorn left a comment

aslesarenko commented May 26, 2020

kushti commented May 27, 2020

polarker Jul 4, 2020

aslesarenko Jul 5, 2020

polarker Jul 5, 2020 •

edited

Loading

polarker Jul 5, 2020

polarker Jul 5, 2020

aslesarenko Jul 5, 2020

polarker Jul 5, 2020

aslesarenko Jul 14, 2020

polarker Jul 4, 2020

aslesarenko Jul 5, 2020

polarker Jul 5, 2020 •

edited

Loading

aslesarenko Jul 5, 2020

polarker Jul 5, 2020

aslesarenko Jul 14, 2020

kushti Jul 15, 2020

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

Are you sure you want to change the base?

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

Conversation

aslesarenko commented May 25, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kushti commented May 26, 2020

aslesarenko commented May 26, 2020 • edited Loading

robkorn left a comment

Choose a reason for hiding this comment

aslesarenko commented May 26, 2020

kushti commented May 27, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

polarker Jul 5, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

polarker Jul 5, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aslesarenko commented May 25, 2020 •

edited

Loading

aslesarenko commented May 26, 2020 •

edited

Loading

polarker Jul 5, 2020 •

edited

Loading

polarker Jul 5, 2020 •

edited

Loading