CassandrichA topic I once tweeted about but didn't really pursue, that's now looking more interesting/relevant, is what I call a lightweight "nocoin" notary chain/web. Some thoughts on what that would be, and why it's interesting. A 🧵
This idea started from looking at the definition of "blockchain" (merkle tree + consensus protocol) and asking whether such a thing necessarily facilitates running stupid toy money ponzi schemes on top of it.
In particular, can you make an underlying structure that can't represent the concept of "double spend" (and thus can't guard against it) so that it can't be used to trade virtual assets with parties you distrust? If so, is that useful?
The key property to achieve that seems to be making membership in the chain efficiently testable but not iterable. For example, storing only hashes. This is sounding good, because it also suggests you can make it really light.
From the user side, something like:
Submit at time T a small fixed size (hash) piece of data X you want notarized.
Get back something you can present to others to prove X existed at time T.
(In practice the data likely involves signatures and I'm glosing over matters of how you use them at this layer.)
Now, suppose we want to make a system like this scale without needing a gigantic shared ledger.
The "get back something" above is potentially doing some heavy lifting. You can make the user responsible for carrying a fairly large number of entries as part of their proof, up to a next waypoint where the notary gets one or more other lower-traffic notaries (ones it's probably paying) to notarize its state.
In this way you can build up a distributed hierarchical merkle tree where no one party even has a complete picture (unless they work really hard trying to archive it, but even then it's only hashes) but proofs work and editing things into history isn't possible.
So, since someone asked, how you bind human memorable names to key identities with something like this... there are lots of ways but yes DNS is one!
In particular, a notarized timestamp together with a complete DNSSEC signature chain from the root establishes the validity of a particular DNS record (RRset) at that time, and can serve as a 100% machine verifiable source of "domain at time" identity.
Of course if you were building identity on top of a notary system, you'd probably want to have intermediary layers of protocol that let you do things like change your keys, recover from lost keys, etc. where an identity is a chain of notarized events signed with valid-at-time keys.
One can think of this as an analog of on-chain computation, except that instead of executing on miners, it just executes on a VM evaluating whether to accept a key as corresponding to the identity.
Why is a machine-evaluable identity system interesting to begin with?
For me, it goes back to my thread on the end of Twitter, what is being lost, and what we eventually need to build in its place.
Particularly, the value Twitter had as a unified public social graph of curated trust-as-source-of-information relationships.
The same kind of trust-as-source-of-information has come up in #reprobuilds and software provenance fields.
We can't all be the experts in everything or know who the experts in everything are. But we can share with one another knowledge of who we trust for what purposes. Doing that with decentralized protocols seems appealing.