Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transaction hash standard #388

Closed
SebastienGllmt opened this issue Jun 16, 2024 · 0 comments
Closed

Transaction hash standard #388

SebastienGllmt opened this issue Jun 16, 2024 · 0 comments

Comments

@SebastienGllmt
Copy link
Contributor

SebastienGllmt commented Jun 16, 2024

Right now, transactions in Paima don't have a globally unique hash.

If we want a globally unique tx hash system, we have to consider the following cases for how the STF gets called:

  1. a user submitting a transaction directly to an underlying chain
  2. batcher transaction (that contains multiple underlying txs)
  3. a primitive triggering on the underlying chain
  4. scheduled data triggered by a timer

We do have some similar concepts though:

  • Nonces for user inputs to an underlying chain are calculated using [blockHeight] + [userAddress] + [game input]
  • Nonces from a batcher perspective are calculated using [millisecondTimestamp] + [userAddress] + [game input]
  • scheduledTxHash which gives the underlying tx hash for primitives

However, this is incomplete as it doesn't handle all 4 cases.

Additionally, a better tx hash than these nonces could be something like hash(caip2 prefix + underlying tx hash + idx) where idx is because one tx in the underlying chain can trigger multiple STF calls (ex: trigger multiple primitives). This would handle all cases except for timers though. Note: idx here is not a global counter or a per-block counter, but rather a per-tx counter. This means that idx can be computer on the client side theoretically (if they know how many STF calls their transaction will trigger, or if they just query for idx=0 from the node and check if any with higher IDs exist later)

For timers, we can do something like blockNumber + contents, but perhaps a different way to do it that is more tooling-friendly is to implement #387 first, then make that timers need a "percompile name" as an argument to set the address of these timers. This would allow us to do something like address + blockNumber + idx for the hash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant