Building on the previous identification process, the same mapping functions can be achieved without the party disclosing any non-relevant data to a counterparty - by delegating the mapping functions to unrelated third-party Validators. The statement, supporting evidence and functions, would first have to be fragmented in such a way that third-party validators would be confirming fragments of data that, on their own, cannot be used by any malicious third party. However, together, the sum of confirmations would constitute a complete identification process.
The IAME Identification
Network
The proposed IAME Identification Network would have a core that consists of
1) a client,
2) an allocation server,
3) a validation server,
4) a writeable blockchain, and
5) an identity
server. Each component would carry out specific functions that can be demonstrated in 2
processes - a validation process, and an identification process.
The validation process would be the operation through which the client would have her/his
information validated by third-party validators. The process is as shown below:
-Upon request, statements and their corresponding supporting information would
be fragmented at the client level and encrypted into validation packets to be sent
to the allocation server.
-The allocation server would control the random allocation of validation packets
to third-party validators, who would return the result of their validations to the
validation server.
-Once the above is completed, the validation server would evaluate the validations
from the third-party validators, and hash numeric or boolean confirmations paired
to specific statements on a designated writeable blockchain.
Identification Process
For a counterparty to transact with a client, an identification process has to be completed.
This process is based on the counterparty’s own specific requirements.
-Assuming that the counterparty requires Data 1,2,.. n to be validated for a specific
transaction with a party, the counterparty sends a request to the Identity Server
for the validation status of Data 1,2,.. n.
-The Identity Server reads the blockchain for validation status of Data 1,2,..n for
the party, and returns the validation data to the counterparty, and from thereon
the counterparty can complete the transaction.
Third Party Validation
Pursuant to the concept of the IAME fragmented identification system, there is a requirement
for a system of decentralised third-party validators under the rational that an identification
validation conducted by a multitude of third-party validators is more dependable and less
susceptible to the risk of fraud than an identification validation conducted by a single institution
or party. However, having a system that runs on a for-profit basis, where the third party is
“paid” to validate information, creates a natural tendency for participants to game the system
and collectively approve a validation process to receive a payout. The solution we propose
is a symmetric game model that will encourage truthful validation that is analogous to the
Byzantine Fault Tolerance - the Trial Algorithm.
Aspects of the Trial Algorithm:
1. Each statement and their corresponding supporting information are processed
as fragments ( “Evidence” ).
2. Evidence is validated not by single third-party validators ( “Jury” ), but by a Jury
(a “Tribunal” ).
3. Each jury validates in a designated method on whether the Evidence matches
the statements.
4. The Tribunal validations are counted and a majority rule consensus is reached.
5. If there is a non-majority consensus on an evidence, the evidence is sent through
a second tribunal ( “Appeal” ).
6. . If the appeal jury votes to a majority consensus identical to the initial tribunal,the
decision is upheld, or else the initial tribunal decision is rejected.
The purpose of the trial algorithm is to support truthful validation and, most importantly,
genuine dissent in the event a significant portion of the third-party validators are corrupted in
their validation mechanism. In the proposed technical implementation, it is intended that the
third-party validators are blindly assigned tribunals, appeals, and control tribunals( “Control
Tribunal” ). Control tribunals are an allocation of non-matching statements to evidence, and
to third-party validators, such that the third-party validators are randomly subjected to double
blind procedures.
0 komentar:
Posting Komentar