Polygravity's products are built on top of a protocol stack called PolyXchange. At its core, PolyXchange is a highly scalable, high security, real-time double-entry bookkeeping system: It records and notarizes transactions between two parties, and puts transaction data into the private blockchain of each party where data becomes immutable. Everything can be transacted, be that conventional fiat currency, cryptocurrency, data, rights to physical assets, etc. as long as it is traded against another value (e.g. usage of a telecommunications network against fiat currency).
PolyXchange consists of three different protocols that come together to form the perfect digital transaction system:
The PSDP serves as the transport and session layer protocol, providing encrypted, authorized, real-time message-based communication including state synchronization for replication based high security and availability clusters.
The PSDP replaces TCP/UDP and other related transport layer protocols that limit the amount of possible parallel connections in a network. All PSDP communications support real-time semantics, meaning that all transactions occur in real-time.
The PSDP is quantum computing proof and DDoS hardened due to a highly modular system architecture. Encryption modules can easily be exchanged by every transacting party individually to allow for adaptation to new and evolving system threats.
The PSDP features double layer encryption, meaning that transactions are encrypted by both the application that generates the transaction and the operating system running the application. This ensures that the applications which communicate remain unidentifiable to potential eavesdroppers. In addition, transmission layer based authentication allows for identification of communicating parties to each other exclusively, further reducing feasibility of DDoS attacks.
The ESDP is a session and presentation layer protocol saving the input of the PSDP protocol's clusters into locally stored and globally interlocked Merkle trees to make an alteration of input history impossible without detection.
By distributing block hashes amongst communicating parties, the transacting ledgers become interlocked with each other and their data is rendered immutable. As a result, ESDP data can be used as court evidence to prove that occured trades were executed under consensus of both transacting parties.
PolyXchange does not have a native asset or "system currency". Because of this, a globally transparent public ledger with a history of all transactions is not required. Transaction data is mainly stored on the transacting party’s accountant’s private blockchain/ledger (see EADP tab) where only the respective transacting party has access to.
According to data protection laws, customers have the right to have their data deleted. PolyXchange's ESDP adheres to this norm by allowing transacting parties to “forget” about blocks that save transaction data after an individually configurable time period. However, much like in a double-entry bookkeeping system, every transacting party holds an immutable and fully notarized record of every transaction it made with other system participants. As a result, even if a trading party would delete their complete transaction history, other parties could still prove what transactions have been made between them and the party who deleted their records.
Polygravity's EADP is a modified, inline trusted party, fair exchange/non-repudiation protocol that performs double entry booking on the application layer level. It enables limitless system scalability and delivers high-end security mechanisms effectively empowering trade in scenarios in which interacting parties do not trust each other.
PoyXchange's EADP validates transactions locally between two transacting parties. As a result the system exhibits a runtime complexity of O(1) meaning that there is no loss in system efficiency when new parties join the network. In other words: Every joining node ads to the global amount of transactions that can be processed in the system in a linear fashion.
The EADP establishes consensus between transacting parties via an agreement mechanism involving accounting parties as illustrated.
Clients are authenticated devices that are allowed to initiate/authorize transactions. You can think of them as the hardware of the actual user. Clients store only settled transaction hashes to minimize storage requirements on the client node.
PolyXchange does not feature a hardware component, however, the client's hardware setup has a significant impact
on system security and performance.
PolyXchange’s clients can work with comparatively primitive ("thin") hardware. Cryptographic security level and transaction throughput are dependent on hardware performance, however, as explained in the EADP section, the transaction audit trail is stored on the accountants’ systems and not the transaction initiating client node.
As mentioned in the EADP section, PolyXchange does not have a global transaction throughput limit. However, localy between two transacting parties, transaction packet throughput is dependent on hardware processing capacity.
Initial load tests on an outdated 2009 2.93 GHz i7 870 processor with 4 cores yielded 12’000 transaction- packets per second with a transaction-packet size of 512 bytes of random data per transaction.
However, the transaction processing algorithm is perfectly parallel, such that doubling the computational resources will double the transaction throughput (ceteris paribus). Otherwise put: Faster hardware will deliver more transactions per second in a linear fashion, meaning that a modern midrange performance server CPU, like many AMD EPYC CPUs, with 16 cores instead of 4 would deliver a transaction-packet throughput of 48’000 per second. Assuming that cores did not become any faster in the past 9 years.
All parties in the network are able to create HACs in order to ensure maximum data availability and security of their system. One HAC consists of multiple nodes (current maximum at 12) that synchronize via private ledgers and together act as a single party (accountant or client).
By bringing together 3 nodes or more in one party, byzantine failure tolerance is achieved, meaning that one third of all nodes can be overtaken by enemies who act maliciously without the system being disturbed. If more than 3 nodes are brought together only a third + 1 nodes must be operational, a third of all nodes can be overtaken by enemies, and the remaining nodes can be down without the system experiencing any irregularities.
Because private ledgers are stored with the accountants, high availability clusters are usually less interesting to clients.
The below example illustrates the workings of the combination of PSDP, ESDP and EADP in a scenario where a telecom operator uses Polygravity's system in order to bill their customer for network usage.
Billing is executed basechange allows every network user, be that IoT sensors, phones, etc. to be billed separately in real-time without reaching any transaction throughput ceilings.