How header timestamps are being trusted?

Hi,

I see that Holochain’s header always contains timestamp in their header, which could be used for instance, in my understanding, to decide on an order for concurrent updates of the same entry.

However how do you trust these timestamps? If I go and add a block with a cheating hdk couldnt I tamper these timestamps and potentially alter the behavior of a hApp that is using them?

Thank you!

1 Like

Yep, you could its true.
timestamps should only be used in a high trust application, if they have an important impact on the use of the application. Holochain itself I don’t think uses them for anything particularly important, they are there for convenience more I believe.

I’ve heard @thedavidmeister wax poetic on the subject and is one of the folks who focuses on security considerations. I think he’s quoted the use of a trusted time stamping authority for security sensistive use cases?

Thank you for your answer!

I also came across this post which goes in-depth in terms of possible protocols that a hApp could use, I wonder if it is still being explored today:

1 Like

the HDK doesn’t have anything exposed to modify timestamps in headers, although this has been discussed, but yeah you could fork core itself and mess with timestamps

i wouldn’t say that we “trust” timestamps, but they do put rough bounds on things, like all the timestamps in your chain need to increase monotonically or your agent activity neighbourhood will have a signed proof to warrant you with

countersignature sessions (something i’m working on atm) will also require the parties countersigning to roughly agree on timestamps with each other and also the validating agents in the neighbourhood of the entry in order for the countersigned entry to validate

the roughtime protocol (secure timestamp service from google, cloudflare et. al.) is what ethereum 2.0 uses for their beacon chain, and i wrote a POC integrating this with holochain, so i’d expect that’s where we land if an independent trusted “time oracle” is needed for some reason

1 Like

Thank you very much for your answer!

In case of concurrent updates of the same entry, will the update actions in Holochain be sorted by timestamp or it’s up to the hApp to choose which Update is the most recent?

Thank you!

1 Like

holochain records the whole tree of CRUD operations because concurrent operations and partitions are normal

to linearize the tree presents two challenges that have no “one size fits all” solution:

  • a topological sort to create a total ordering
  • rejecting unwanted state changes if two concurrent operations are inconsistent

in a somewhat collaborative setting (e.g. project management app), or where entries are countersigned by all affected parties (e.g. turn based games), you can use timestamps like that, in a more adversarial environment you might need to layer an external source of time on top like eth 2.0 does

your app might also have a way to do the sorting/rejecting that has nothing to do with times

1 Like

That’s very helpful thank you!