Digital Twins (Detailed View)

This goes into more detail on Digital Twins, but this level of understanding is not necessary for interfacing with the Knova system.

Not shown here- This is the core object only. A Digital Twin also relates to other parts of the platform, such as the contracts and workflows that act on it, the asset rules that govern it, and where the underlying asset is held. These relationships are managed by the platform and aren’t part of the stored object described below.

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 is a detailed view of Digital Twin and its structure, which is serialized as FlatBuffers to be stored as a compact binary format.

This binary object is cryptographically signable, verifiable, and represents an asset issued by an asset authority comprising of:

• a universally unique identifier
• a version number
• a cryptographic signature system
• a decimal amount
• an asset code
• a cryptographic public key matching a cryptographic signing key
• a cryptographic public key of the asset owner
• a cryptographic public key of the asset authority
• an issuance date timestamp
• a cryptographic signature by the transaction validator aka "notary" of the object hash;
• a cryptographic signature by the previous owner of the object hash
• a notary that authorizes a transfer, including information describing the notary cryptographic public key and a
• signature of the notary cryptographic public key from the asset authority
• a list of asset provenance, comprising an identifier, cryptographic hash of the previous object, and a respective decimal amount deducted from a previous object to add to the value of the new object
• a commitment group configured to link the new object to the transaction identifier, commitment identifiers between involved parties, and a group name;
  creating, using the computing device and based on information stored in the new object, an initial hash of the new object, wherein the initial hash is signed by the cryptographic signing key of the asset authority and the notary

Digital Twin Lifecycle

This section describes Digital Twins issued and circulated within Knova. Twins that mirror external assets follow the lifecycle of the asset in the external system.

Wallets govern assets in the Knova system. The Transaction Validator can configure certain wallets as the "Authority" for a given asset code. That wallet then sets its own policies for limits, minting and redemption of the asset, and its limit is the upper bound of the asset's supply.

Once the ruleset exists, Digital Twins can be created and distributed by interacting with the Transaction Validator Service. These Digital Twins are then "in circulation" and can be used in transactions. At any time (unless the Authority's rules say otherwise), Digital Twins can be redeemed against the Authority wallet and taken out of circulation, which restores the value available under the asset's minting limit.

After redemption, retired Digital Twins can optionally be archived and moved into long-term storage.

Transaction Processing with UTXO

Digital Twins have a fixed value at issuance (say $5.00 USD), but a payment may need a different amount (for example $4). Knova uses a modified UTXO approach to denominations, so a Digital Twin can be split into different values as required.

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

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

Once these Digital Twins are locked in, the Transaction Validator authorizes the change immediately and returns it. Alice can use it in a new transaction while the previous one is still in progress.

For transferred and refund, depending on how the contract logic plays out, the Transaction Validator authorizes one or the other, never both. It signs and verifies Digital Twins during a transaction to confirm this.

Knova's modified UTXO approach allows independent transaction processing, which supports horizontal scalability. See Horizontal Scalability.

This section covers signing and transferring Digital Twins directly within Knova, but Digital Twins can be carried under other schemas. For example, messaging standards such as ISO 20022 can include Digital Twin information in the message payload.

Privacy and Security with Digital Twins

Digital Twins are pseudonymous and use public/private key cryptography. The default is Ed25519 (FIPS 186-5), chosen for performance, security and efficiency, and the scheme is extensible to others such as Secp256k1 or post-quantum algorithms such as ML-DSA (Dilithium). This creates an immutable chain for each Digital Twin, and together with the two-phase signature process for transfers, it is designed to prevent double-spending. Sensitive data and keys can be kept in vaults or hardware security modules (HSMs), and only the minimum data needed to meet financial regulations is shared.

Pseudonymity protects a holder's personal data while still giving financial institutions the information their compliance programs need. A Digital Twin contains its own proof of ownership and authorized transfer, and it discloses no more of its provenance to transacting parties than the transfer itself. It doesn't need to be published to any external chain or public ledger, so its data is auditable for authorized intermediaries without being publicly visible.

Knova uses Rust throughout for memory safety and performance. Services can communicate over gRPC/HTTP2 for binary transport and multiplexing, which enables high throughput and low latency.

Horizontal Scalability via Digital Twins

Scalability has been a problem for several payment and asset systems that have tried to modernize parts of the financial system. It stems from passing every transaction through a single point of entry, which creates a bottleneck as volume grows. Fragmented back-office functions, intermediaries and settlement times also limit traditional systems, especially at the retail level.

Through Digital Twins, Knova uses a non-account-based design that scales to fit an institution's regulatory and financial requirements. Large financial institutions can process tens of thousands of transactions per second for millions of customers, and Knova is designed for that level of reliability, throughput and low latency.

Transaction validation is distributed across horizontally scaled Transaction Validators (see Sample Architecture), which supports high concurrency. Because Digital Twins are independent objects, they can be signed and validated in parallel, so the order of Digital Twins doesn't matter and processing is more flexible. The validators use non-blocking database calls to improve performance.

When validating an asset, only its row is locked, which prevents contention and allows parallel processing. A sharded database architecture also distributes write load across shards, which improves throughput and reliability.

To increase throughput, add transaction validators to the network. This design avoids the need for batching and expensive consensus algorithms.