Byzantine Fault Mitigation using Fuzzy Logic, Schrodinger’s Cat and the Copenhagen Interpretation to deliver a P=NP environment.
A Byzantine fault is any fault presenting different symptoms to different observers. A Byzantine failure is the loss of a system service due to a Byzantine fault in systems that require consensus.[1]
A reliable computer system must be able to cope with the failure of one or more of its components. A failed component may exhibit a type of behaviour that is often overlooked — namely, sending conflicting information to different parts of the system. The problem of coping with this type of failure is expressed abstractly as the Byzantine Generals Problem.[2]
The Byzantine problem can be solved using the Schrodinger Cat paradox which poses a similar situation.
Schrödinger’s cat: a cat, a flask of poison, and a radioactive source are placed in a sealed box. If an internal monitor (e.g. Geiger counter) detects radioactivity (i.e. a single atom decaying), the flask is shattered, releasing the poison, which kills the cat. The Copenhagen interpretation of quantum mechanics implies that after a while, the cat is simultaneously alive and dead. Yet, when one looks in the box, one sees the cat either alive or dead, not both alive and dead. This poses the question of when exactly quantum superposition ends and reality collapses into one possibility or the other.[3]
As you can see, in Schrödinger’s cat, there is a binary situation when applied to information that states the information is both true or untrue.
To counter the virtual state of the cate, the Copenhagen interpretation was instigated, and it states that a system stops being a superposition of states and becomes either one or the other when an observation takes place.[4] However, it goes on to state that once the system is observed, “The act of measurement affects the system, causing the set of probabilities to reduce to only one of the possible values immediately after the measurement. This feature is known as wave function collapse.”[5]
In other words, the state of the cat is not only verified when observed, it is set by the observation.
This is true for the observation of physical systems, but it can also be true and can be applied to the observation of data. Data sits within a physical system, and the physical system is what causes the Byzantine fault. Since the original data set, the first order made by the first general is inputted into the system, we need to create an original data set box or vault that can be used as baseline verifier or observation verifier. The data processed through the system is akin to the Generals message being processed and possibly corrupted, however, unlike the Byzantine fault, where consensus is required, Schrodinger’s Cat and the Copenhagen interpretation come in to nullify the Byzantine fault by adding a baseline data set for verification of truth.
Now let’s take a look at the Byzantine problem using the Copenhagen interpretation of quantum state (Schrödinger’s cat). Information in a system may or may not be true, until it is observed it is either true or untrue. The instance of observation provides us with the real state of the information. In other words, one viewpoint cannot provide different states, since the box has been opened and the state of the information is equal in observation to both. Only when the box is unopened is the information in both states.
The time-independent Schrödinger equation states:
The Byzantine Protocol States:
At the end of a phase users agree on which secrets were properly shared, the secrets are then opened and each player Pi is assigned the value and an encryption protocol is put into place to assure that the “bad” users or “lying generals” cannot intervene with the data. This is stated as:
To prevent bad users from doing so we encode the state using the Quantum verifiable secret sharing (QVSS) and send each player their share of the secret. Here again the verification requires Byzantine Agreement but replacing the agreement by the grade-cast protocol is enough.
In the Byzantine fault we know that the information is the cat. We also know that the cat can be either dead or alive, which is equal to being correct or incorrect information. The box is essentially the construct in which the information is placed, and with a computer system, while there may be only one location for an original bit of information stored, that bit can be replicated, processed and sent to different locations. What is required, is to define the box. What is the box in which the information is originally stored, and where is the door or window to which an observer me see the original information as it is being processed?
The solution is what we term the primary box status (FuzBox); this is where the information is initially stored, and where the information is initially processed before it is transmitted. This primary box is equal to the original General that made the true decision. This box of information is never touched or deleted, it remains in its original form and copies are used for transmission. Then the transmitted copy can be compared to the original data set. Hence, we have a baseline original box status, and we can compare the observed copy to the actual original bit bypassing consensus requirements for approving true or false situations. Thereby negating the requirement for consensus since we have the original data set to compare against the copied processed data.
Essentially what we have done is provided all our generals with a telescope that can see the original message in the commanding generals’ hands (yippee for technology). Each general may now compare the spy’s information with the original information. A question arises, why would we need to compare if we have the ability to view the original information. The answer is simple, the original information is the command or request. The city is the processors that process the request and the spy is delivering the message after it has been processed through the city. If the processed data is not based on the original command or request the processed data will not match the original data set. Consider this; You receive a request to sell stock, the data is processed through the system and you receive a buy command with a positive not a negative as you would expect from a sell command. Since you don’t know the original request you look it up and presto you immediately perceive the anomaly. You can ignore the processed data and reprocess it using the correct command sequence. However, what do you do with encryption? The same thing you would do with anything, the original encryption is lodged in the Commanding Generals hands facing your telescope, or, the encryption key is stored in a location that you can view. The data reaches you and you can now assess it based on the original encryption key. Basically, you can check the result using the original encryption key…and presto, P=NP. You have not only solved the issue you have validated the solution all at the same time.
P=NP
The P versus NP problem is a major unsolved problem in computer science. It asks whether every problem whose solution can be quickly verified (technically, verified in polynomial time) can also be solved quickly (again, in polynomial time). [6]
The informal term quickly used above, means the existence of an algorithm solving the task that runs in polynomial time, such that the time to complete the task varies as a polynomial function on the size of the input to the algorithm (as opposed to, say, exponential time). The general class of questions for which some algorithm can provide an answer in polynomial time is called “class P” or just “P”.
For some questions, there is no known way to find an answer quickly, but if one is provided with information showing what the answer is, it is possible to verify the answer quickly. The class of questions for which an answer can be verified in polynomial time is called NP, which stands for “nondeterministic polynomial time”. An answer to the P = NP question would determine whether problems that can be verified in polynomial time can also be solved in polynomial time. If it turned out that P ≠ NP, it would mean that there are problems in NP that are harder to compute than to verify: they could not be solved in polynomial time, but the answer could be verified in polynomial time.
Our statement is that P = NP is a binary environment problem. This means that the problem of P = NP is only found where there is only one correct answer. Such as solving a code in cryptography.
However, in a non-binary environment, as in decision-making process’ there is not just one solution, the environment is fuzzy, not binary, therefore there is always a complexity that separates the binary P = NP universe from the fuzzy or non-binary universe.
In other words, P = NP is a binary concept for handling binary problems.
With this in mind, we do accept that P = NP is applicable to everyday life situations, where solving a problem can take longer than validating the solution since there is most probably many viable solutions for one problem.
Therefore, can we reduce the probability of selecting the “wrong” solution, or in most cases the “not most efficient” solution and enable us to select the “correct” solution or “most efficient” solution from a list of validated solutions.
We determined that we need a library of validated solutions to work with. Then we need to apply fuzzy logic to extrapolate these solutions to meet different components that create new problems that are “like” the original problem. If we had all the solutions to all the problems, then the time to solve the problem would be the time it took to look up the solution for the problem.
We have created a fuzzy P = NP environment for supply chain decision making processes. That is why Fuzzy.One has developed the Solutions Library for you to help build a better world with efficient solutions to all conceivable problems.
FuzBox
The FuzBox is an original command sequence of data or a data set, and is held without processing and accessible only to “generals”. Each general has access to the original data set, and therefore there is no need for consensus, since incorrect or disparity between data sets means that data is being corrupted at some location. The “generals” that receive incorrect data can trace the disparity and locate the source of the problem. The actual solution is accessible to all the “generals” once they peer into the box, however they cannot edit the original box, as it is locked to change or deletion. The FuzBox is the original state of the information as and when it was placed into the box and the viewing of it is used to ascertain the real state of the command or request and processing it in comparison to the processed data received.
Combining the P=NP solution with FuzBox.
Since we have determined that a FuzBox will provide the correct directive that can be validated by comparing the end result with the original directive, we surmise that a validated solution to every supply chain and gaming problem can be reached in the same, if not faster time it took to originally solve it. In other words, the first solution to a problem will always be longer than validating the solution, however, since problems occur all the time, and individuals do not have access to all the solutions, our solutions library essentially brings about a P=NP state.
Conclusions
Removing the consensus model from blockchain environments and combining validation processes that assure truthful outputs provides all library users with an immediate solution to a problem without having to solve it in the first place, the solution is ready even before the problem is stated.
[1] https://en.wikipedia.org/wiki/Byzantine_fault
[2] https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf
[3] https://en.wikipedia.org/wiki/Schr%C3%B6dinger's_cat
[4] https://books.google.com.ph/books?id=-4sJ_fgyZJEC&pg=PA2&redir_esc=y#v=onepage&q&f=false