File-Based Digital Assets (FBDA)

Note: When specialized to just represent banknotes, File-Based Digital Assets (FBDAs) may also be called File-Based Digital Banknotes (FBDBs). FBDAs can take the form of, but are not limited to, digital banknotes/cash, treasury securities, repurchase agreements, central bank digital currencies (CBDCs) and other cash analogues.

A File for the Future of Money

The building block of the Knox Network system is the File-Based Digital Asset, which is moved through the system and between stakeholders via the Interbank Platform run by Knox Networks. The FBDA provides the same benefits of physical banknotes with the added benefits of a digital-first technology. FBDA are authorized into circulation as direct obligations against a particular Authority (such as central banks), and distributed into circulation by Authorized Intermediaries (such as commercial banks).

Diagram of a Sample $100.00 note FBDA with block depth N.

Note: Maximum FBDA Size: ~6kb to keep FBDAs small. Default signature system is Ed25519, but is configurable.

As shown in the figure above, each banknote comes with a number of properties inherent to the FBDA itself, including (but not limited to) its cryptographic hash, amount and currency (e.g., US $100.00), and addresses for the Distributor and the Authority for that particular FBDA. The linked list grows from “size 1” to “size n” with each individual transaction adding a block to the chain.

How FBDAs Work

Rather than a distributed ledger-based system across the entire network , every FBDA builds its own individual linked hash-chain list, with the chain growing with each transaction (default max list size is 60 transactions, but this is configurable). The block depth of each FBDA grows as transfers occur through a two-part signature process.
Every FBDA in a transaction can be considered independent from one another, which allows for transactions themselves to be independent. This independence of FBDAs and transactions allows for concurrent processing of transactions via sharding techniques, and enables the Knox Networks system to horizontally scale transaction validation within the system. This independence does not require a dependency of analyzing past payments (such as the case for UTXO models) nor of distributed consensus to authorize payments or assert the validity of a given FBDA. Since the integrity of the FBDA starts with the initial blocks signed by trusted entities (the Authority and the Authorized Intermediaries), any attempts to tamper with the FBDA are easily detectable. Also, an attempted compromise on an FBDA only renders that tampered individual the FBDA untranslatable, and not the entire network.

Despite this power, FBDAs are designed to be compact. A fully transacted FBDA maxes out at 6kb under the Ed25519 signature system to remain small enough for storage on mobile devices or for embedding within other payment formats. After an FBDA hits the transaction block depth threshold, the FBDA is redeemed by the Authorized Intermediaries, retired to the Analytics Service or Archival Service, and a new FBDA of equivalent value is re-distributed to go back into circulation, without interrupting the user experience. This threshold keeps FBDA file sizes small, and allows for renewal through the system of new versions of the FBDAs and historical pseudonymous analytics on transactions.

FBDA Flexibility

FBDAs can tokenize a variety of different asset types. Non-banknote asset classes could be “tokenized” via FBDA technology to similarly track the ownership, management, and transfer of different digital asset classes in a manner similar to what has been shown with FBDAs. These different asset classes could include assets like securities, treasuries, and repurchase agreements as shown below, and are applicable to be used both by central banks (such as issuing treasuries or other government securities) and by commercial banks (such as corporate bonds or other securities).

Signing and Transferring FBDAs

Each FBDA contains a public key of the Authority and of the Authorized Intermediary that originally minted each file. The Authority Public Key identifies which authority has authorized the issuance of the FBDA’s, and the Distributor Public Key identifies which Authorized Intermediary distributed the FBDA.

Each FBDA contains two signatures: a "Transfer Signature" and an "Authorization Signature."
The owner of each FBDA is identified by the public key in the latest signature block. The Transfer Signature indicates the transfer of ownership from the previous owner and the Authorization Signature indicates the legitimacy of the transfer.

When the FBDA owner transfers ownership to the next owner, a new signature block is appended that contains the next owner's public key, a timestamp, and a hash of the previous block hash + the next owner's public key + the timestamp. This hash is signed by the transferring owner’s private key to produce the Transfer Signature, indicating the transfer to the next owner. This Transfer Signature denotes the FBDA has been transferred to the new owner and can be cryptographically proven that the previous owner had assigned ownership to the new owner via the most recent signature block.

For the FBDA to be settled and to ensure the sender of the FBDA did not double spend the banknote, an Authorization Signature is required. When the FBDA is created, the Authorization Signature on the Genesis Block is always the Authority. For subsequent signature blocks, the Authorization Signature will likely be provided by the Transaction Validator Service, which is a highly-scalable service that is given permission to validate transactions by the Authority or the Authorized Intermediaries (if desired, Authorized Intermediaries or Authorities could also directly provide the Authorization Signature, though this would limit scalability via bottlenecks).
This double signature system helps to secure FBDAs, and also helps in providing value added services on top of transactions such as atomic settlement capabilities like Payment versus Payment (PvP) or Delivery versus Payment (DvP).

By authorizing the issuance of FBDAs to Authorized Intermediaries and the bulk of transaction validation to Transaction Validators, it allows for an 1) increase in the scalability of processing FBDA transactions and 2) easier separation of Authorities (such as central banks) from KYC responsibilities and daily retail transactions. In the case of a CBDC, this helps to mirror more closely the current two-tier banking system, while augmenting the banking toolkit. In the case of a commercial bank-issued coin, this can allow for easier segmentation of KYC responsibilities for different jurisdictions.

This discussion focuses on the signing and transferring of FBDAs directly on the Knox system, but FBDAs can be transferred under a variety of schemas. Relevant messaging standards (e.g, ISO-20022) can incorporate FBDA information directly as part of a message payload, for example.

File-Based Systems vs. Existing Payment Systems

Knox Network’s file-based solution provides improvement over other approaches that are being investigated to improve the current financial system. In particular, Knox Network’s file-based solution avoids many of the pitfalls and shortcomings of distributed ledger technologies (DLT) and account based systems.

Knox Network’s file-based architecture ensures and maintains atomicity, consistency, isolation, and durability principles (ACID) within its systems. By contrast, account-based systems typically attempt to maintain multiple disjointed ledgers by trying to keep them synchronized over a messaging layer. This makes account-based systems slow and error-prone, forcing the use of two-phase commits in an individual system's ledgers. In addition, these systems are not designed to build out auditable trails for every transaction and interoperate with one another easily. Indeed, auditability and interoperability usually require building an add-on system that generally adds complexity, delay, and error to the overall operation.

While distributed ledger systems have many security and interoperability advantages over traditional account based systems, these systems also fall short of the Knox Network’s file-based approach. For example, distributed ledger systems require time consuming consensus mechanisms and therefore take an enormous performance hit for security, as there becomes a bottleneck in the number of transactions that can move through the system at a given time. This solution ultimately does not scale from a throughput perspective (transactions per second) nor from a latency perspective. This is especially true when trying to reconcile transactions across different geographical regions.

File-based systems improve upon the shortcomings of both the account based and DLT systems. File-based systems can scale independently of the number of transactions because each FBDA contains its own individual ledger and can be processed concurrently. Specifically, file-based systems are tokenized at the individual asset level, which allows these assets to be independently transacted and processed. This design allows for horizontal scaling by ensuring that multiple files can be processed simultaneously (concurrently) with the addition of more compute power, avoiding the bottleneck issues seen in other systems. In addition, file-based systems can still interoperate with both account-based and DLT systems because the files (i.e. packets of data) can be added as a payload to those external systems if necessary.

File-based systems come with their challenges, however, such as the fact that the size of each file grows with the number of transactions. Knox Networks’s solution mitigates these problems via retiring and re-issuing FBDAs once they get to a certain size (~6kb), which allows files to be archived for analytical and auditing purposes. This is analogous to the current practice of removing paper notes from circulation after a certain period of wear and tear.