marigold-dev / marigold-dev/deku
use clock for replay attack prevention
Nobody has claimed this yet.
- Dominant language
- OCaml
- Stars
- 82
- Forks
- 17
- PR merge metrics
- No merged PRs in 30d
Description
## Problem
As our blocks are async we cannot rely on block_height to prevent replay attack, as while it prevents replay attack if it is not included really fast the operation may be lost. So our current solution is only okay because we constantly produce blocks every second.
## Suggested solution
Have a distributed clock which agrees on time, so that we can say "this operation can be included in up to 10min".
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by mapping how operations are currently tied to block height and how replay prevention is enforced, then define the distributed-clock design and its failure cases. Done means operations can safely expire after the proposed 10-minute window without relying on rapid block production.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ocaml
- Domain
- blockchain, distributed-systems, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100