Digital Assets

Digital assets hold information, which may evolve in time. Changing information is known as a state update, or state change.

As opposed to raw information in a typical computer file, information in a digital asset must have some notion of integrity, such that there cannot be conflicting versions, or conflicting histories of the same asset.

Systems for the creation and management of digital assets therefore require at least two distinct capabilities:

State management - What is the current state of an asset? Does it belong to Alice or to Bob? Has, say, a coupon been used?
Integrity management - Committing a given new state as the true next version of an asset, and having the ability to validate whether any given state is, in fact, occurred.

Many systems, including enterprise databases, ERPs, and traditional blockchain solutions, conflate these two essential capabilities. For example, an ERP database tracks not only what updates to an asset are the latest, but also all of the particulars of the current state of that asset.

In TODA, we are able to tease these ideas apart, turning integrity management into a separable lightweight operation. This leaves state management as something which the most interested party - the owner of a given asset - can take charge of.

Design Goals

Single canonical successor (a.k.a. One True History): The fundamental property TODA sets out to establish, not unlike many other cryptographic asset systems, is to guarantee that there is only one identifiable, true, integral history of an asset. For example, the person previously in control of an asset cannot simultaneously pass control to two different people: only one of these histories is canonical, or true.
System mobility and asset tracing: Assets can move between privately-managed systems and public systems of consensus and/or transmission. In most existing designs, assets cannot be moved from a private chain to a public chain, or into an enterprise database. This causes data duplication and a loss of both integrity/canonicity guarantees, as well as loss of the full history of the asset.
Upgradable cryptographic primitives: TODA is built using cryptographic primitives, which are the subject of ongoing cryptanalysis. Between this cryptanalysis and more general advances in computing, these primitives can be expected over time to lose the properties necessary to support TODA's security guarantees. For assets to retain value over the long-term, it is essential that the systems upon which they depend for their integrity can be gracefully upgraded to stronger cryptographic primitives as these developments become available.
Negligible system costs: TODA is designed such that the computational and energy costs of modifying an asset (e.g. transferring control to another entity), is carried by the entity making that modification, and any parties who are privy to those details and wish to verify them. The impact on the "network", or system of consensus, supporting this modification is designed to be absolutely minimal, and not impacted by the size of the transaction or modification.
Privacy: The particulars of a modification to an asset (e.g. transfer of control) are not revealed to the system of consensus, or anyone else. The particulars are only revealed when the entity which created that change chooses to provide another party with proof of what occurred. That is, one may be ignorant of the details of a transaction, but once provided with those details, a third party is capable of evaluating the validity of what allegedly occurred.

non-Goals

Many aspects commonly associated with cryptographic asset systems are out-of-scope for the design of TODA. The careful exclusion of these 'non-Goals' enable novel ones, such as negligible system costs. Other non-Goals describe functionality that can be better provided by existing technologies, or are trivially added atop an TODA system.

Communications networks or transmission: TODA does not prescribe how the data inside a TODA asset should be handled or transmitted, not does it describe how actual TODA proof information should be transmitted. TODAQ has developed several implementations for the transmission of proof information which are suitable for different use-cases, however these are strictly non-normative.
Data storage or databases: TODA does not prescribe how asset or proof data should be stored. While there is a prescribed layout of proof data in order to generate stable cryptographic hashes, this layout may not be the best storage format for any given application. Storage and transmission are two sides of a coin, and TODA does not seek to define either.
Lookup (e.g. ledger functionality): TODA does not aim provide any system to globally index the current owner of any given asset. Analogous to physical cash, there is no ledger which tracks who presently controls the bills of a given serial number. Similarly, the actual holder of a TODA asset, like the holder of a physical bill, is able to reveal their control of the asset to an interested party. The non-inclusion of this goal is what permits the system/network costs to reach negligible levels.
Application design and modelling: TODA at its core does not aim to force the calculation of custom business rules to assess the validity of a given asset. If an asset has a provably canonical history, this is sufficient for its legitimacy under TODA. However, an actual application built atop TODA remains free to assess whether an asset was created or modified correctly, and is able to scrutinize the full evolution of each step in that asset's history. Similarly, a business offering services in exchange for a TODA asset is equally able to assess whether the rules they instituted for their assets have been followed. The value in excluding these considerations at the cryptographic integrity layer is the efficiency gained in determining the canonicity of an asset.

Design

TODA Assets

TODA assets are designed to be unique, lightweight, controlled, digital objects. As digital objects, they are composed of, and contain, information. As controlled objects, they cannot be modified by anyone at will; they can only be modified by those who ultimately hold the necessary keys.

Assets can be issued by an organization to represent physical objects of value (e.g. a numbered gold bar held in a vault), to represent other debts or obligations (e.g. a free coffee to the bearer), or they may represent intrinsic digital value (e.g. the bearer holds a legitimate license to this e-book).

Similarly, a user may share the contents, and perhaps even the proof of their ownership, of an asset to another entity. Sharing this information does not modify the asset, and does not affect the control or ownership of the asset - it merely shares the facts that the asset has accumulated to date.

Asset Data versus Proof Data

The unit of value is the TODA asset itself. TODA assets may have been created containing the same information inside them (e.g. the same text of an e-book), however each TODA asset remains provably unique and distinguished from one another. Merely copying the information contents out of a TODA asset does not duplicate the value of the TODA asset, and the copied information would lack any provable trail of canonical history.

Creating Assets, and Asset Versions

TODA assets can be created by anyone. An asset is created by creating its first version.

A version, similar to a block in other cryptographic systems, most importantly contains a pointer to the previous version for this asset. In this way, the history of an asset consists of a chain of versions, with each subsequent one pointing to its previous.

A TODA Asset Version is defined by the following:

Canonicity - Where does this version fit in the chain of revisions, and where is this version committed
- Previous: The previous version of this asset, if any.
- Commit Target: The asset to which this version will be committed, thereby marking it as the canonical successor to the last revision
Control - What is required to modify this asset, and demonstrating how this version meets the requirements set on the previous revision
- Requirements: A key, or weighted list of keys, which must sign any successor to this version
- Requirement satisfactions: A signature or weighted list of signatures, meeting the demands of the previous version of this asset
Payload: The payload, or cargo of an asset is the non-proof information, such as the contents of an e-book, to include as part of this version.
Commitments: Versions of other assets which are being committed into this asset as canonical successors

Finally, a version also contains a random value for both enhanced privacy of the particulars of the revision, as well as additional security against a certain type of commitment attack.

An asset version has a unique identifier, composed of the list of data above. When a reference is made to this version, the reference will be to this identifier. For example, when the successor version is created, its previous field will contain the hash of this version.

Payload Data

Payload data is a set of key-value pairs, where both function as hash pointers. Payloads may contain arbitrarily deep nested structures of data. TODA presently supports three shapes, which keys or values may point to:

Key-Value pairs
A list of hashes
Unstructured bytes

While all shape formats are ultimately represented definitively as bytes, the use of nested structures can gain efficiencies where much data is re-used between versions. Further, it provides the option for a user to selectively reveal only a subset of the structure, proving its integrity, while omitting select substructures behind hashes.

Requirements and Requirement Satisfactions

Requirements are used to limit how an asset can be updated. Typically, these are used to specify a key which must be used to update the asset. In the case where a single key is specified, the holder of the key is the asset's owner.

To specify multiple keys, a requirement list is used. A requirement list specifies an unsigned one byte weight for each key. A weight in the range 1..255 is specified for each key. A requirement list has been satisfied if there are signatures from required keys totalling >= 255 in collective weight. There is no limit on the number of weights and keys which can be specified in a requirement list.

Keys are a straightforward mechanism for limiting the evolution of an asset. It is anticipated that additional types of requirements will be made available in addition to keys in the future.

Committing Versions

With the structures described so far, there are assets which accumulate history by creating a chain of versions over time, and a requirements mechanism to limit who are able to create new versions of the asset. However, while each version specifies exactly what version serves as its previous, there must be an additional mechanism to establish the uniqueness of the successor of a version. That is, if an asset is forked — has two different versions with the same previous value — only one of those versions must be the unique legitimate successor. This condition is canonicity.

To achieve canonicity, the hash of the new revision needs to be incorporated into a new version of some other asset — the asset that was specified this asset's commit target field, the last time it was specified. The purpose of these links is to grow an intertwined lattice of version histories, where it becomes impossible to show a third party that two conflicting versions are both valid.

Of course, if the commit target asset is also under one's control, is colluding with the owner, the commit target itself may attempt a fork - ad infinitum. Therefore, all assets must be committed to another - forming a large tree of interdependency. (Eventually, this becomes a graph, as some "higher" assets commit into new versions of assets which had originally committed into them)

In order to prove the canonicity of a given history of an asset, not only are all the versions of at asset required, but also considerable data from the assets this one had committed to, and the ones those had committed to, and so on. All of this data, together, is referred to as the proof of the asset.

When verifying the structure of these commitments, however, there must be some level at which one can stop. The highest level of commitment which is required for the proof of a given asset is a particular asset, designated its integrity provider. The integrity provider becomes the ultimate arbiter of canonicity should the level beneath it cause a fork.

To meet the stringent design goals of TODA, it is not feasible to agree upon a single integrity provider for all applications for all time. Even a single distributed system of consensus becomes inappropriate for situations with widely varying latency, or planned network disruptions. In order to facilitate the enormous design space desired by asset designers, TODA permits that assets themselves decide what their integrity provider ought to be. That is, at the time of asset creation, the creator of the asset specifies what its ultimate arbiter shall be.

A good default choice of integrity provider may be a major public organization, such as a central bank, or it may be something private to one's organization -- for assets which only have value within that context.

Commit Targets

Commit targets are themselves simply TODA assets. TODA assets benefit from being able to serve the dual role of being an asset of value of their own - with a payload (or 'cargo'), etc - as well as serving as a destination for another asset to commit to.

Like any other TODA asset, commit targets can - and probably should! - have requirements placed on them, to limit who can create new versions. This becomes especially important if the assets being committed do not themselves have any requirements placed on them. This is because, while an asset with no requirements is able to create new versions without fulfilling (e.g.) a signature requirement, if it has a specified commit target, then it remains invalid (properly, non-canonical), until the commit target has properly canonicalized a given revision.

This means that if one holds the keys to a commit target, it's not necessary to individually specify requirements on each of the assets which must commit to it.

Commitment Frequency

It is not necessary for every version of an asset to commit into another asset. This would cause every asset in the entire graph to evolve as quickly as versions were being added to the most frequently updated asset at the bottom.

Instead, assets need only commit at points which are important to their use in a given application. For instance, one might create an asset, committed to the company commit target, and then make dozens of modifications to it. Following these revisions, one might wish to transfer the asset to another user. In order to be able to provide a complete proof to that user, the version which includes the ownership change would be committed.

Recipients of un-committed versions of assets may rightly be skeptical of their canonicity, since a complete proof, by definition, could not be provided if the latest version had not been committed. However, in some fast-moving applications, or circumstances where there are other layers of trust between parties, this may be a desirable tradeoff.

To create a new un-committed version, the version simply omits specifying a new commit target.

Commitment Mechanism

The actual mechanism / operation for committing to a target involves bi-directional references, and takes advantage of the commitments field in both the commit target, and the asset itself.

The commitments field is a data structure known as a Trie, which provides the important guarantee that there can only be a single value for a given property.

As versions of assets are, of course, immutable, creating a strong bi-directional link of the commit takes several steps.

A given asset has a commit target from the time this value was provided in a version. Recall, there may be any number of un-committed versions in the interim. To create a new committed version:
- This new committed version must be committed into the already-specified commit target
- This new committed version must also specify a new commit target. It could remain unchanged, specify a newer version of the same commit target, or could point to an entirely different target entirely.
After creating this version, the commit target will need to create a new version of itself which incorporates this change into its commitments field. This is easy to do if one is in control of both assets, but may involve network coordination if committing into a remote asset.
- The commit target creates an entry in its commitments field. This entry maps the property (or key) representing the previously committed version of the asset being committed, to its new version.
- The commit target doesn't need to do this immediately. They may have many revisions in-between being selected as a target, and eventually incorporating this change. The responsiveness of a commit target may factor into the choice of target for a system designer.
- As a commit target does not need to incorporate the commit immediately, it is able to queue up commits from many different assets. Its commitments field may then end up containing the committed changes from many assets which had selected it as a target, and submitted a change since its last version.
For greater certainty, and for greater flexibility in how these commit structures are permitted to evolve in the future, there is an additional step which the asset being committed should undertake.
- The next time the asset is being committed (as per Step 1), it should add an entry into its own commitments field, containing a similar entry to the one which the commit target added. Except, instead of the value referring to this asset's last committed version, the value should refer to the version of the commit target which incorporated the commit.
- As this step necessarily requires a commit following the one being referred to, it will always be missing from the last commit for an asset, until which time it is no longer the last.

Implementations

The initial implementations of TODA have been authored by TODAQ, with the goal of community releases in the near term.

These implementations are not considered normative; they were constructed as implementations of specification documents - however, they may be upgraded to normative status after extensive verification.

Platforms

There are TODA implementations for both the JVM and JavaScript, with JavaScript supporting both node.js 'crypto' and browser 'crypto.subtle' cryptographic operating environments.

Primitives

While TODA supports flexibility around what primitives are selected for a given system, the existing implementations support only SHA256 for hashing, and secp256r1 for keys and signatures. Cross-platform support for other elliptic curves are a development priority.