Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Runtime: Eras in transactions #202

Closed
gavofyork opened this issue Jun 5, 2018 · 2 comments
Closed

Runtime: Eras in transactions #202

gavofyork opened this issue Jun 5, 2018 · 2 comments
Assignees
Labels
J0-enhancement An additional feature request. Z2-medium Can be fixed by a coder with good Rust knowledge but little knowledge of the codebase.
Milestone

Comments

@gavofyork
Copy link
Member

gavofyork commented Jun 5, 2018

This is to avoid fringe replay attacks on deleted accounts, since when an account is reaped the nonce is discarded, all pre-existing transactions could be replayed if the account becomes funded (it remains to be seen how one could use this to craft an attack in practice, but nonetheless remains an open question).

To avoid it, we ensure transactions are signed with a recent headerhash to identify them with a single era. The recentness of the hash can be adjusted to give a tradeoff between safety (i.e. how long can pass before the transaction becomes inherently un(re)playable) and liveness (i.e. how long it can float around off-chain and still remain valid).

What to do

Add an 8-bit version identifier on to the beginning of the transaction. That should be set to 0.

Append a 16-bit Age onto the inner Transaction format:

<CheckPoint (12 bits)><LogDuration (4 bits)>

This comes alongside a second requirement that the signed Transaction format (i.e. the data that is signed) have an additional hash field, which must be the hash of the correct header of the block number B given the current block number N:

B = quantize(N + C, D) - C

where

quantize(num, quot) := floor(num / quot) * quot

and

D = 2 ** (Duration + 2)

and

C = CheckPoint * (LogDuration + 2**12-1) / 2**12

This requirement fulfils three goals:

  • The transaction is valid only for a range of blocks;
  • that range of blocks itself has a wide variance from the very small (4 blocks) to very large (131,072 blocks);
  • it adds a negligible additional payload into the transaction;
  • it is only valid on a particular fork of the chain.
@gavofyork gavofyork changed the title Eras in transactions Runtime: Eras in transactions Jun 5, 2018
@gavofyork
Copy link
Member Author

@rphmeier comments?

@gavofyork gavofyork self-assigned this Jun 12, 2018
@gavofyork gavofyork added this to the PoC-3 milestone Jun 12, 2018
@gavofyork gavofyork added J0-enhancement An additional feature request. M4-core labels Jun 12, 2018
@gavofyork gavofyork added the Z2-medium Can be fixed by a coder with good Rust knowledge but little knowledge of the codebase. label Jun 21, 2018
@gavofyork gavofyork removed their assignment Jun 21, 2018
@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done


This issue now has a funding of 0.55 ETH (259.82 USD @ $472.4/ETH) attached to it.

@gavofyork gavofyork self-assigned this Sep 17, 2018
@gavofyork gavofyork mentioned this issue Sep 17, 2018
4 tasks
JoshOrndorff pushed a commit to moonbeam-foundation/substrate that referenced this issue Apr 21, 2021
* update types package

* bumped types and added test

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>
liuchengxu pushed a commit to chainx-org/substrate that referenced this issue Aug 23, 2021
liuchengxu added a commit to chainx-org/substrate that referenced this issue Aug 23, 2021
* Add missing types

* Inject NEW_TYPES instead of the manual way

* Fix typo

* Set ExistentialDeposit = 0
liuchengxu added a commit to autonomys/substrate that referenced this issue Jun 3, 2022
Decoupled execution skeleton: fraud proof
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
J0-enhancement An additional feature request. Z2-medium Can be fixed by a coder with good Rust knowledge but little knowledge of the codebase.
Projects
None yet
Development

No branches or pull requests

2 participants