Digital Twins

The building block of the Knova system is the Digital Twin (known technologically as a File-Based Digital Asset, or FBDA), which is moved throughout the system and between stakeholders via the Multi-Asset Transaction Platform. Digital Twins are not actually files but are instead just a conceptual shorthand to simplify their meaning and instead are a common data structure (i.e., Flatbuffer) stored as binary data in a traditional database or any other data stores.

Digital Twins serve as a common building block on the platform, representing all forms of different assets - whether it be cash, deposits, crypto, securities, or any financial asset. Knova can represent these assets as Digital Twins through different processes, depending on the use case. This process is used for mirroring assets that exist on an external system.

This enables a standard digital format so businesses can store, transact, audit, secure, and manage all asset types in a unified manner. Asset provenance when interacting with external systems is guaranteed under Asset Encumbrance.

Digital Twin Structure

File-Based Digital Assets are designed to be flexible for different assets.

• The Asset ID serves as a method of uniquely identifying the Digital Twin in the system.
• The Signature System field is for identifying the cryptographic signature system in use.
• Asset ID, Asset Code, Amount, and Decimals are for specifying the value and type of asset being twinned (e.g., $100 USD),
• The Created Timestamp is to signify when the Digital Twin was first created.

For ownership, the Owner Key field and the Authority Key fields are used to determine the current holder and the original issuer of the asset, respectively. In summary, Digital Twins provide Knova with a lingua franca for interacting with different assets on the platform. Details on additional keys, signatures, hashes, etc., can be found Digital Twins (Detailed View).

Digital Twin Lifecycle

Wallets serve as governors of assets in the Knova system. Certain wallets can be configured to serve as an ‘Authority’ for a given asset code by the Transaction Validator. This wallet will then set its policies for limits, minting, and redemption for the asset. This limit of assets serves as the upper bound of asset supply.

Following the creation of this ruleset, Digital Twins can be created and distributed via interacting with the Transaction Validator Service. These Digital Twins are now “in circulation,” and can be used in various transactions. Now, at any time (barring specific rulesets from the Authority), Digital Twins can be redeemed against the Authority wallet and taken out of circulation, resetting the value against the specified minting limits of the asset itself.

After redemption, “retired” Digital Twins can now optionally be Archived and moved into long-term storage.

Transaction Processing with UTXO

Digital Twins are given a fixed value at the time of issuance (say $5.00 USD) but may be asked to fulfill situations where this is not possible (e.g., trying to pay $4). Knova utilizes a Modified UTXO approach to file denominations, allowing for changing files into different denominations as required.

When Alice sends payments to Bob, she collects her Digital Twins and creates three new Digital Twins: transferred, change, and refund.

• The owner of transferred is Bob
• The owner of change is Alice
• The owner of refund is Alice

When these Digital Twins are locked in, the Transaction Validator authorizes the change immediately and returns it. This allows Alice to use this in a new transaction while the previous transaction is still in progress.

As for transferred and refund Digital Twins, depending on how the logic in the contract plays out, the Transaction Validator will authorize either “transferred” or “refunded” Digital Twins, but will not do both. The Transaction Validator signs and verifies Digital Twins during a transaction to confirm this.

A sample UTXO transaction is demonstrated below:

Knova’s Modified UTXO solution allows for independent transaction processing, leading to horizontal scalability. For more information on this, refer to Scalability.

This discussion focuses on signing and transferring Digital Twins directly on the Knova system, but Digital Twins can be transferred under various schemas. Relevant messaging standards (e.g., ISO 20022) can incorporate Digital Twin information directly as part of a message payload, for example.

Privacy and Security with Digital Twins

Digital Twins are pseudonymous, leveraging private/public key cryptography (e.g., FIPS 186-5 compliant Ed25519 by default for high performance, security, and efficiency, but extensible to other cryptographic systems such as Secp256k1 or quantum-resistant algorithms such as Dilithium, Isogeny-based, etc.). This cryptographic scheme creates an immutable chain for each Digital Twin, which, when coupled with the two-phase signature process for a transfer of Digital Twins, makes attempts at double-spending untenable. Sensitive data and keys can be stored in vaults/hardware security modules (HSMs), and only the minimal amount of data required to meet financial regulations will be granted by retail users as required.

The pseudonymity of a file holder’s personal data preserves privacy rights, while also allowing financial institutions to access the information needed for their compliance programs. The Digital Twin contains its own proof of ownership and authorized transfer and does not disclose any more of its provenance to transacting parties other than the transfer itself. It does not need to be published to any external chain (or public ledger) where non-transacting parties may view it. This makes data in the Digital Twin system auditable and transparent for Authorized Intermediaries but not publicly viewable.

Rust, a highly performant programming language with memory safety, is used throughout the Knova system for security. Rust can communicate over gRPC/HTTP2 for binary transport and multiplexing to enable high throughput and low latency.

Horizontal Scalability via Digital Twins

Scalability has proven to be an issue for several payment and asset systems that have tried to revamp aspects of the financial system. This ultimately stems from the need to pass every transaction through a singular point of entry, which creates a bottleneck in the system that prevents the system from scaling efficiently as the number of transactions grows. Due to fragmented back-office functions, intermediaries, and settlement times, traditional systems are not as scalable, especially at the retail level.

Through Digital Twins, Knova designed a non-account-based system that could scale to fit within an institution's regulatory and financial requirements. Knova understands that large financial institutions could be processing tens of thousands of transactions per second (TPS) for millions of customers worldwide and thus designed a system that could meet those requirements via high reliability, high throughput, and low latency.

Transaction validation is distributed across horizontally scaled Transaction Validators (elaborated on later in the Sample Architecture section), ensuring high concurrency and efficiency. As Digital Twins are independent objects, they can be cryptographically signed and validated in parallel; therefore, the sequencing of Digital Twins is not important, allowing for greater flexibility in processing. The transaction validators are specifically designed for high concurrency, with non-blocking database calls that enhance performance.

When validating an asset, only the corresponding row is locked, preventing contention between files and enabling seamless parallel processing. Additionally, the use of a sharded database architecture allows for horizontal scalability, further distributing the write load across multiple shards to enhance overall system throughput and reliability.

Increasing the throughput in the system can be achieved by increasing the number of transaction validators in the network as needed, and this horizontally scalable design removes the need for batching and expensive consensus algorithms.