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?
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?
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
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?
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