Concept Series 02: Source-Dependent Messages

This is the second in a series of posts laying out what we have learned in the chain search and concepts that are needed to understand where we are going. Read the previous post: Concept Series 01: The Problems

Each time you tell the world that something exists, it creates a narrative that forms your identity. In a more technical definition, an identity is a construct formed by the aggregation of events from the same source. Each event or message is therefore source-dependent as messages without a source do not build an identity.


Most blockchain projects have focused on the concept of transfer. They have worked toward the questions around transfers: How can it be easier to transfer value from one user to another? How can these transfers be controlled programmatically? And even how can we create new unique items of value to transfer to others? The advances in answers have led down a path that has particular constraints.

Transfer centric transactions require protecting against attacks such as the double-spend attack. A transfer requires confirmation of ownership before that ownership can be transferred. This means that transfer transactions must be well ordered, have a higher level of validation and security, and can only be processed in series or other guarantees against interactions with other transactions.

Source-Dependent Creation

Social networking is a world not dependent on transferring value. Each piece of the narrative that creates the identity is starting fresh from the source. Other data in social networks may then refer to the content, but do not alter it. The only requirement is that each new creation is able to be linked to the creator.

Scientific data, supply chain checkpoints, and more share the characteristic that they need proof of who sent the message, but do not need any proof of transfer. This is the idea of an audit. We can follow the trail of who said what when and discover any falsehoods. Trust, but verify.

How does that verification happen? The simplest version of source validation is a cryptographic signature. Mathematical proof that only the holder of a private key could have signed the message. We can extend the capabilities of a signature through a secure blockchain state that links public keys together (our next concept post). The key is that the validation be easy and quick. Fast validation allows for invalid signatures and messages to be rejected quickly with no chance of being mistaken for an original. Once we focus on the source validation requirement, we can create two new features not possible in a traditional blockchain transfer transaction: off-chain validation and parallel processing.


Any action on-chain is expensive. Each action must be performed, replicated, and confirmed by consensus. The result of those actions is guaranteed with the highest possible trust level available to the chain. The cost for that guarantee is usually high and borne by the sender of the transaction. Off-chain actions have a different cost profile. The action must be done for each consumer of the transaction. This shifts the cost from the creator of the transaction to the consumer, from writing to reading. That shift is desirable when the primary value is in the consumption instead of the publication of the data.

Our source-dependent messages don’t require a prior validation of chain state to exist. We can use the chain for propagation and existence of the message and move the validation of the message source or creator off-chain. To make the cost of validation low, we use the chain to provide easy access to the necessary data for validation. We get what is called in computer science a “lazy evaluation” of message validity. Consumers desire valid messages and the low-cost means that producers of messages can expect that invalid messages will be discovered.

Source-dependent messages are parallelizable by default. Parallel processing of transactions is often seen as a holy grail of blockchain technology due to the potential performance improvements. Source-dependent messages do require some previous state, the ability to know they are sourced correctly, but that is a far more limited need (and off-chain possible).

Problems: Race Conditions and Revocation

Of course, there are some race conditions (isn’t there always?). A source-dependent message must be preceded by data needed to confirm the source. Cryptographic signatures do provide us a way to confirm the source is the holder of a private key, but nothing beyond that. If the source is not merely a public key, the identifier used must be associated with a public key before the message can be tested or an invalid message would occur pending the proper association.

Those familiar with signatures will already know the next problem: revocation. Best security practices encourage rotating keys from time to time so that if a private key is exposed, the damage can be limited. We must deal with how to remove a key from the identifier aka revocation of the permissions of a key to be a future source of messages. Users may also need to revoke or change a message after it is created.

Solving the Problems

We can solve the problems with applying a two layer approach to message validation. First, we check if the message has a valid source. This is based only on data available at the time the message was sent. Because the historical data doesn’t change, the result is immutable and can be cached indefinitely. A message with a valid source can never in the future be considered to have an invalid source.

The second layer is more difficult because we need the ability to change the validity of messages in the future. Users, services, and others need to delete messages that were unintended or where a permission was abused. In DSNP, we use Tombstoning and idempotent state changes to accomplish. Tombstoning is a revocation of a previous announcement. It says that while that announcement did exist, you should consider it to not exist anymore. Idempotent state changes don’t remove a previous message, but shift the state to a different value. Graph change announcements shift the state of a graph connection from unfollowed to followed.

However it is done, the message or state is altered by a future message. It is a much more difficult search space as it is continuously expanding. Because some use cases may desire just the immutable message, the second layer of future revocation need not always be available, but it should always be considered. While computers might not, humans change their minds all the time and DSNP is a tool for human communication.

As we continue this series of concepts, the idea of source-dependent messages, these creation focused messages, leads to more building blocks. Next in the series, we explore how we can leverage the limited requirements and ability for off-chain validation to enable scaled batching through user delegation of trust.

Next Concept Series 03: Delegation