Zipchain — ray of pairwise transactions
A zipchain is a fundamentally new technology for processing high-level business transactions, which has been implemented for the first time in dia$par.
|ERP and alike||Blockchain||Zipchain|
|architecture||primitive entries in the database||chain of transaction blocks||
local cluster architecture
|processing||dispersed across modules||distributed||multi-cluster parallel processing / fog verification|
|performance||difficult to predict||low, with negative scalability||record-breaking / unlimited|
While in the case of a blockchain data reliability is ensured by primitive redundancy (which ultimately leads to catastrophically slow processing speeds in real-world applications, which further decline as the network expands), data reliability in a zipchain is based on the successive application of the fundamental law of conservation of energy.
A degenerate case of this law involves the "double entry" principle of bookkeeping — a brilliant invention of Medieval Italian mathematicians and bankers.
The zipchain business logic is founded on the principle that "nothing appears out of nowhere and nothing disappears without a trace".
Two entities (at a minimum) — the universal logical equivalents of the "sender" and the "recipient" — participate in any event occurring within the virtual reality of the dia$par.Matrix cybernetic model.
dia$par meta-system comprises two main components (systems) — your real organization (dia$par.Enterprise) and its 'image' (existing in dia$par.Matrix).
In other words, every dia$par event gives rise to rigidly linked (not unlike elements in a zipper) pairwise complimentary changes.
They represent the elementary zipchain transactions, or zip-transactions.
The zipchain architecture permits the existence of only one type of transactions (zip-transactions proper).
A random high-level business transaction of the "original" enterprise is decomposed by the mmizer into a "zipper" of successive rigidly linked zip-transactions.
Both ray of pairwise zip-transactiobs and "double entry" of ancient italian bankers have their biological sister, built on same mathematical basis.
Of course, we mean the legendary "DNA double helix".
That biological "invention" required hundreds of millions of years of evolution.
It is in turn seamlessly joined to the "zipper" of zip-transactions of the complete cybernetic model, which grows endlessly (within the lifecycle of the enterprise).
A blockchain represents a tremendous leap forward compared to the primitive two-dimensional ERP models, having introduced the concept of a directed structure of transactions in which subsequent transactions are built upon their predecessors.
The evolution of the blockchain concept stopped at large transaction blocks that are linked together.
The zipchain has brought the idea of a perfect transaction structure to its logical conclusion.
Transaction processing technologies: comparative review by reliability/performance ratio.
By utilizing its colossal performance advantage, the zipchain has reduced the block size to that of a single transaction, thereby transforming the chain of blocks into a highly compact, thin, and smooth thread (ray) of "atomic" thickness, in which transactions — inseparably linked pairs of the "zipper" — act as "atoms".
Every active dia$par produces its own zip-ray inside itself.
Any required level of physical reliability (which is also adequate, unlike the fatally excessive redundancy of a blockchain for the majority of practical applications) is achieved in a transparent, guaranteed, and cost-effective manner by increasing the number of standby servers (which can be geographically distributed, if appropriate) that mirror the state of the central data container of the system in real time.
As a result, a redundancy model consisting of just one mirrored standby server guarantees no more than one dia$par (zipchain local cluster) failure in a million years.
In the zipchain model, each transaction between your dia$par and the dia$par of suppliers and clients is an intersection between zip-rays.
Many interacting dia$pars form the global meta-structure of Сyberspace.
You'll remember from geometry that a point where two rays intersect belongs to both of them. In the zipchain abstraction, the intersection of zip-rays is possible only when many parameters, which are calculated independently by at least two separate dia$pars, meet mathematically.
Exactly as person A meets person B only if four parameters match (three dimension coordinates and one chronological).
To execute even the most primitive transaction between two dia$pars, several hundred independently calculated parameters must match. For example, the balance of mutual settlements, all previous mutual deliveries and payments, should match for a linear sale.
If even one parameter does not match, the transaction cannot be executed, just like if person A cannot meet person B at the agreed point if they arrive a thousand years later. Or, if at the right time, but three miles higher.
Thus, the more nodes in Cyberspace and the more transactions completed in it, the higher the mathematical validity of the data in every dia$par.
In addition, the computational work created by processing transactions in Cyberspace does not influence zipchain's excellent performance at processing transactions; all processes that create a heavy drain on resources continue to be processed locally, inside each dia$par.
Based on the example of a real user (an e-commerce retailer with ~$1billion in turnover and ~30,000 orders a day), the speed that the zipchain-ray grew at, measured by the local proto-dia$par, was around 40 million zip-transactions every day.
Writing all of these using the classic accounting method of A4 paper would create a stack 30 stories tall (daily).
Processing a similar number of transactions using Bitcoin's blockchain (a world wide network) would take 6 months.
Controlling the meeting of parameters between Cyberspace nodes is extremely primitive (element-by-element comparisons in linear arrays) and happens practically instantaneously.
What happens if some of hundred parameters don't match?
The transaction cannot be concluded. A red light.
Because of the multi-leveled complexity of the meta-system's architecture and the guaranteed uniqueness of each installation's cybernetic model, it is generally impossible to take control of dia$par.
It would require physical access to all servers plus the skills from a team of professionals, including developers, administrators for operating systems, servers, and databases. In fact, all of the conspirators should be all of the above.
Nevertheless, a low probability does not equal zero.
The zip-ray, calculated by dia$par, would automatically lose its relevance if it fell under the control of hackers. This is because the transaction registered in the zip-ray of the compromised dia$par by the hacker would not be matched in the zip-ray of the counter-agent.
"Ray", in the zipchain model, differs from our day-to-day understanding of the term, but matches with the definition in Euclidean geometry: rays intersect once or not at all.
This is because, from a mathematical point of view, the Internet of Enterprises is an example of "finite geometry" (a set with a limited number of points). Obviously, the local dia$pars are the points in the projected set of the Cyberspace.
The rank of the IoE space is a function of the number of dia$par points and the heterogeneity of the individual cybernetic models' internal structures; it quickly increases with the growth in the number of IoE nodes at first, and slows down to a logarithmic function at later stages.
The compromised dia$par loses its ability to conclude transactions; thus, falling outside of the IoE's set, defeating the purpose of the hack.
The described self-defense mechanism of the Internet of Enterprises, built on the distributed verification of nodes, is the cybernetic analog of biological organisms' innate immunity.