Validation rules for EBs? #72
Replies: 3 comments
-
Good question. Validation rules should be designed to avoid such attacks. Thus, IBs should be validated (in the context of EB validation) against a fixed point of reference (e.g., some stable ledger state to which they point to), and not other IBs. After an EB settles, duplicate txs, double spending txs, or time-depended validity can be checked and sanitized. |
Beta Was this translation helpful? Give feedback.
-
Context that I was missing which came up in a meeting: "After an EB settles" refers to when we're building the ranking block. IBs with invalid transactions will be rejected rather than propagated, and the fixed point of reference means a TX won't become invalid during propagation. When building the RB at the end, pools can exclude individual TXs without throwing out entire IBs/EBs. |
Beta Was this translation helpful? Give feedback.
-
Well, validity of an IB should never change. So when you say
then it should only matter when the IB was created, not when anything else that references it happens. So in that case, if it gets into an IB before the time it expires it's valid, and inclusion into any later IB is invalid. It doesn't matter whether the rest of the pipeline happens when inclusion into an IB would now not be allowed anymore. Note that this is also how it works with Praos ATM. If you have a transaction that expires at slot X, and you receive a block containing it in slot X+5 but the block was created in slot X-2 then the block is accepted if nothing else is wrong with it. |
Beta Was this translation helpful? Give feedback.
-
From internal docs, it sounds like stake pools will only vote for EBs where every contained IB is valid (and the body is already downloaded). Does this mean that if an IB contains a single invalid transaction (i.e. a TX which expires right before the Vote stage), that IB and (any EBs which contain it) are poisoned? That sounds like it could be pretty abusable.
Also, from playing with the current rust sim, it looks inevitable that there will be some TX duplication across IBs (even with sharding). Is it considered a validation error if an EB contains two IBs with the same transaction?
Beta Was this translation helpful? Give feedback.
All reactions