top of page

Route

Route

Route

Route

Route

Route

Route

Route

Route

Route

Route

Route

Ledger Routing Communication

Network Flow & Code Examples

Request

Request

Request

Request

Request

Request

Request

Request

Request

Request

Request

Request

Terminal

[

    {

        "BankID": "BankA",

        "CanFacilitatePayment": 1,

        "AvailableLiquidity": 500000,

        "ExchangeFee": 0.01,

        "DirectAccess": 0,

        "ConnectedBanks": [

            {"BankID": "BankB", "RoutingFee": 0.005},

            {"BankID": "BankC", "RoutingFee": 0.01}

        ]

    },

    {

        "BankID": "BankB",

        "CanFacilitatePayment": 1,

        "AvailableLiquidity": 300000,

        "ExchangeFee": 0.02,

        "DirectAccess": 0,

        "ConnectedBanks": [

            {"BankID": "BankA", "RoutingFee": 0.005},

            {"BankID": "BankD", "RoutingFee": 0.004}

        ]

    },

    {

        "BankID": "BankC",

        "CanFacilitatePayment": 1,

        "AvailableLiquidity": 700000,

        "ExchangeFee": 0.015,

        "DirectAccess": 0,

        "ConnectedBanks": [

            {"BankID": "BankA", "RoutingFee": 0.01},

            {"BankID": "BankE", "RoutingFee": 0.003}

        ]

    },

    {

        "BankID": "BankD",

        "CanFacilitatePayment": 1,

        "AvailableLiquidity": 250000,

        "ExchangeFee": 0.01,

        "DirectAccess": 0,

        "ConnectedBanks": [

            {"BankID": "BankB", "RoutingFee": 0.004},

            {"BankID": "BankE", "RoutingFee": 0.006}

        ]

    },

    {

        "BankID": "BankE",

        "CanFacilitatePayment": 1,

        "AvailableLiquidity": 1000000,

        "ExchangeFee": 0.005,

        "DirectAccess": 1,

        "ConnectedBanks": [

            {"BankID": "BankC", "RoutingFee": 0.003},

            {"BankID": "BankD", "RoutingFee": 0.006}

        ]

    }

]

Routing...

Cheapest route cost: 0.028, path: ['BankA', 'BankC', 'BankE']

Initialization

Inspired by quantum communication principles, the protocol merges the robustness of packetized transmission with the security of the BB84 QKD protocol, aiming to futurize and secure payments against modernizing cyber threats. The primary objective is to create a network where value can be transmitted securely and eavesdropping can be detected. This protocol leverages the principles of quantum mechanics to generate encryption keys that are theoretically immune to interception, ensuring that the data remains confidential and unaltered during transmission. By integrating packetization, the protocol also enhances the efficiency of data transmission, allowing for the seamless handling of complex payment data across various nodes. The focus on cross-border payments ensures compatibility with international remittance systems, paving the way for a global, secure, and instantaneous payment network.

Photon

Future-Proof Payment Network utilizing Quantum Key Distribution

To see the entire Photon project, please load this page on a desktop browser

This page looks better on a Desktop!

To see the entire Photon project, please load this page on a desktop browser

This page looks better on a Desktop!

Latest Version: 1.4.0_7.15.24

Project Overview

The project ensures secure payment transmission using Quantum Key Distribution (QKD). It is broken down into five layers - Electrons/Ledgers, Ledger Routing Communication, Initialization, QKD, and the Transport Layer. Using quantum mechanics principles, the transport layer leverages the BB84 protocol to securely generate and distribute encryption keys. The network architecture outlines the three layers: routing, error correction, and eavesdropping detection mechanisms. 

Note: This project isn't practical with today's technologies, but rather just a concept. Implementing QKD in a payment network would create redundancies and still does not protect the network from side-channel attacks (that is, attacks where the adversary takes advantage of information beyond what the model gives the attacker). This was just a project for me to learn about Quantum Mechanics and uses for it.

Click here to see a mathmatical overview of the transmission protocol used

Core Concepts

The Photon Payment Network enables secure payments across multiple currencies and financial systems. The architecture consists of five layers to facilitate secure payments. The BB84 Protocol is central to the Quantum Key Distribution Payment Protocol. Colloquially, the entire stack is sometimes referred to as a "QKD Payment Protocol." Technically, however, the BB84 Protocol is only one component in the overall framework.

 

The Quantum Key Distribution Payment Protocol is not a blockchain, a token, nor a messaging service. Instead, it is a standard way of securely bridging financial systems through quantum communication principles. This architecture is inspired by the robust design principles of quantum mechanics, ensuring that payment data is transmitted with security and integrity.

Architecture 

Electrons is a term I chose to use for the different ledgers (banks/institutions) on the network. These are entities that are able to act as connectors as well as initiate payments on the transport layer.

A connector is an entity that is granted access to the network and able to earn/price a fee for acting as a liquidity provider in cross-border remittances. Entities acting as electrons or connectors must have the ability to communicate over a common quantum channel while measuring, storing, and recording qubit measurements; this is preferably done through another quantum-proof, non-hashing encryption system. As of Version 1.4.0 [July 14, 2024], there is no standard.

For any connector on the network, you must have a minimum of one vostro account within or outside of the network. You also must meet the liquidity requirements.

An electron must serve as a connector, but "x"-connector may not be an electron. A connector may not have an interest in initiating payments on the transport layer, but are able to facilitate cross-border exchanges.

"Electrons" & Connectors

Ledger Routing Communication

Ledger Communication is a private communication system within the transport layer and the nodes. In this case, a node is any entity who has access to facilitating transfers on the network.

The ledger communication protocol allows the banks to report their liquidity status to the transport layer - live. When an electron initiates a payment, the transport layer requests up to date data from the ledger communication protocol to find the cheapest route for a cross border transfer which includes forex fees.

The request will return something that looks like this:

With this information, the transport layer can chose which path is the cheapest and most efficient. This can be shown simply by running:

If you were to run the code above with the .json file shown, it would return:

The remaining sections will be covering domestic remittance for simplicity purposes.

Initialization

1. Packetization

note: the routing optimization for international transfers from the communication layer is always performed before packetizing the data

The focus here is on the packetization of payment data when Alice initiates a transaction to send money to Bob (Before QKD is Initialized [this is a separate process]). The process involves structuring the payment data into a standardized, secure format suitable for transmission over a network. This ensures both the integrity and confidentiality of the data during its journey from sender to receiver.
 
Step 1: Data Initialization and Structuring 

When Alice decides to send money to Bob, she initiates a payment transaction from her device or application. At this moment, the payment data needs to be collected and structured. This data typically includes:
 

  • Transaction Amount: The sum of money Alice wishes to send.

  • Currency Type: The currency in which the amount is denoted.

  • Sender Identifier (Alice's ID): A unique identifier for Alice.

  • Receiver Identifier (Bob's ID): A unique identifier for Bob.

  • Transaction Timestamp: The exact date and time the transaction is initiated.

     

This data is first compiled into a coherent structure. For example, it might be formatted into a single string where each piece of data is separated by a specific delimiter, such as a pipe (|).

As of version 1.4.0, the packets will include an identifier for the currency type to facilitate cross-border payments (included in the payload - not binary). This inclusion ensures that the payment data is not only secure and intact but also compatible with international remittances. By incorporating the currency information, either within the payload using a compact identifier or as part of the packet header, we optimize the efficiency of the packet structure while maintaining clarity and reliability. The currency identifier, compliant with the ISO 4217 standard, guarantees that each packet clearly conveys the currency type, thereby streamlining the process for handling multi-currency transactions.

Example of an initial data string for a domestic transfer:

Example of an initial data string for a foreign transfer:

Step 2: Data Encoding and Segmentation 

The next step is to encode this data into a machine-readable format that is also compact and secure. The string is converted into a binary format to optimize space and prepare it for any cryptographic processes that might follow. This binary data is then segmented into smaller packets, which are easier to handle and transmit. Each packet is appended with a packet header that contains metadata such as packet number and total number of packets, ensuring they can be correctly ordered and reassembled by Bob's system.

Example of a Packetized Data String:

Step 3: Adding Redundancy and Checksums

To ensure the integrity of each packet, a checksum or hash is generated for the payload of each packet. This checksum is included in the header of the packet. I figured it would serve as a way to verify that the data has not been altered upon receipt. This step is critical for detecting errors or tampering during transmission.

Updated Example with Checksums:

Updated Example with Checksums:

Below is an example of the updated packetized data string as of version 1.4.0.

My rationale for packetizing payment information this way is driven by the need to enhance the integrity and efficiency of transmission. Packetization segments complex data into manageable units, each equipped with metadata for effective error handling and sequential reconstruction at the destination. This process not only streamlines data handling but also aligns with principles of information theory related to data compression and error correction, optimizing network resources and enhancing reliability.

Transitioning to Quantum Key Distribution (QKD) post-packetization elevates the security measures to a quantum level, utilizing the principles of quantum mechanics to generate a shared, secure key between parties. This key is then used to encrypt data packets, safeguarding them against potential computational and quantum threats. The integration of QKD ensures that the security of packetized financial data is robust against both current and future cryptographic challenges, thereby fortifying the overall security framework of digital financial transactions. This approach not only protects individual packets through unique encryption keys but also mitigates broader security risks, ensuring comprehensive data protection throughout the transmission process.

Quantum Key Distribution (QKD) Setup

A. Photon Source and Preparation

  • Photon Generation: The QKD process begins with the generation of photons, which serve as quantum bits (qubits). These photons are typically produced using laser pulses, which can be attenuated to the single-photon level. Various techniques, such as spontaneous parametric down-conversion, are used to create entangled photon pairs, ensuring the quantum states required for QKD.​

  • Photon Polarization: Each photon is polarized according to a predetermined basis. In the BB84 protocol, for example, photons can be polarized in one of two bases: rectilinear (horizontal and vertical) or diagonal (45° and 135°). This random selection of polarization states is crucial for the security of the key distribution.

  • Technical Detail: The polarization states are created using polarizing beam splitters and waveplates, which adjust the orientation of the photon’s electric field vector. These devices must be highly precise to ensure the correct polarization states are consistently produced.

B. Quantum Transmission Channel

  • Channel Setup: The photons are transmitted from the sender (Alice) to the receiver (Bob) through a quantum channel. This channel can be a dedicated optical fiber or a free-space optical link. The integrity of this channel is paramount, as any disturbance indicates potential eavesdropping.​

  • Challenges and Solutions: Maintaining the coherence of quantum states over long distances is a significant challenge. Quantum repeaters and sophisticated error correction algorithms are employed to extend the range of the quantum channel and preserve the integrity of the quantum states.

  • Scientific Basis: Quantum repeaters work by entangling segments of the quantum channel and using entanglement swapping to effectively relay quantum states without direct transmission over long distances. This process leverages quantum entanglement and teleportation principles to maintain state integrity.

C. Detection and Measurement

  • Bob’s Measurement Setup: Upon receiving the photons, Bob measures their polarization using randomly selected bases (either rectilinear or diagonal in the case of BB84). This randomness ensures that any interception attempt by an eavesdropper would introduce detectable errors.​

  • Detection Equipment: Bob uses single-photon detectors, which are typically avalanche photodiodes or superconducting nanowire single-photon detectors. These devices are capable of detecting individual photons with high efficiency and low dark count rates.

  • Scientific Principle: The Heisenberg Uncertainty Principle underpins the security of this measurement process. Any measurement by an eavesdropper introduces quantum noise, detectable by comparing Bob’s measurement outcomes with Alice’s original states. This creates a process similar to, but more secure than- Trustless sending.

D. Public Communication and Basis Reconciliation

  • Basis Reconciliation: After measurement, Bob publicly announces the basis he used for each photon without revealing the measurement outcome. Alice then informs Bob which bases were correctly chosen, and they discard any bits where the bases did not match.

  • Technical Communication: This communication occurs over a classical channel, which does not need to be secure because it does not involve the actual key data. The reconciliation process ensures that both parties have an identical string of bits (the raw key) derived from the photons measured in matching bases.

  • Error Correction: Alice and Bob perform error correction using algorithms such as Cascade or LDPC (Low-Density Parity-Check) codes. This process corrects discrepancies in the raw key due to noise and imperfect detectors.

  • Privacy Amplification: To further secure the key, they apply privacy amplification techniques. This process reduces the amount of information an eavesdropper could potentially gain, even if some in formation was intercepted during transmission. Methods such as universal hashing are used to distill the raw key into a shorter, but highly secure, final key.

4. Dynamic Routing Protocol

Routing Mechanism: The architecture employs a dynamic routing protocol that adjusts the path of data packets based on current network conditions and quantum channel fidelity. This protocol uses real-time data to optimize routes, ensuring efficient and reliable data packet delivery. (e.g. when an international transfer is initialized, we use the Ledger Routing Communication protocol)

Importance of Dynamic Routing: Dynamic routing enhances the network’s resilience to congestion and failures, providing a robust framework for consistent data transmission. By optimizing paths, the system reduces latency and improves the overall efficiency of the network, crucial for real-time financial transactions.

5. Eavesdropping Detection and Response Mechanism

Ensuring the security and integrity of the quantum channel is important in a QKD setup. Eavesdropping detection and response mechanisms are crucial for maintaining the security of the communication channel. These mechanisms are designed to identify any unauthorized attempts to intercept the quantum key exchange and to take appropriate actions to protect the data.

 

1. Real-Time Monitoring: 

The system continuously monitors the integrity of the quantum channel by analyzing error rates and other metrics. Any anomalies indicating potential eavesdropping trigger immediate protective measures.

  • Error Rate Monitoring: By comparing the observed error rate with the expected error rate, the system can detect deviations that may indicate eavesdropping. An elevated error rate can suggest that an eavesdropper is attempting to intercept the qubits, as their measurement would disturb the quantum states.

  • Qubit Loss Analysis: Monitoring the rate of qubit loss can also help in detecting eavesdropping. Unusual patterns of qubit loss can signal an interception attempt.

Scientific Basis: The detection mechanisms rely on the fundamental principles of quantum mechanics:

  • Heisenberg Uncertainty Principle: Any measurement of a quantum state by an eavesdropper introduces quantum noise, which can be detected by comparing Bob's measurement outcomes with Alice's original states.

  • Quantum No-Cloning Theorem: This theorem ensures that an eavesdropper cannot create an exact copy of the qubit without disturbing its state, making undetected eavesdropping impossible.​

2. Technical Implementation:

  • Single-Photon Detectors: Bob uses highly sensitive single-photon detectors, such as avalanche photodiodes (APDs) or superconducting nanowire single-photon detectors (SNSPDs), to measure the incoming qubits. These detectors are capable of detecting individual photons with high efficiency and low dark count rates.

  • Random Basis Selection: Bob randomly chooses the basis for measuring each qubit. This randomness ensures that an eavesdropper cannot predict the basis and thus cannot avoid detection.

3. Public Communication and Basis Reconciliation: 

After measurement, Bob needs to publicly announce the basis he used for each photon without revealing the measurement outcome. Alice then informs Bob which bases were correctly chosen, and they discard any bits where the bases did not match.

  • Technical Communication: This communication occurs over a classical channel, which does not need to be secure because it does not involve the actual key data. The reconciliation process ensures that both parties have an identical string of bits (the raw key) derived from the photons measured in matching bases.

Transport

Encryption Process: Using the keys generated through QKD, the packetized data is encrypted. Each packet is encrypted individually to enhance routing speed and integrity. For simplicity purposes, international transfers utilizing connectors will not be covered in this overview, however this would require multi-step QKD

Dual-Channel Transmission: The network utilizes two channels:

  • Quantum Channel: For the transmission of qubits used in QKD.

  • Classical Channel: For transmitting the encrypted data packets and public communication necessary for QKD, such as basis reconciliation data.

  • Note: AES is used to encrypt the packets with the QKD Key.

Need for Dual-Channel Transmission: Separating the quantum and classical channels ensures that the quantum keys are securely distributed without interference. The classical channel, protected by quantum-enhanced encryption, ensures that the actual data transmission remains secure.

bottom of page