Decentralized Escrow service between the Internet and Ethereum.
An automatic system to be used as a guarantor for the fulfillment of terms for a wide range of online transactions.
Please review the concept of the service:
The system kernel is the automatic confirmation and validation of the https request.
In a large number of transactions the fact of fulfillment of obligations by the party can be verified by a single request.
For example, upon payment with fiat money of crypto currency it is sufficient to make a request for the payment receipt and verify the required fields.
Another example, upon domain transfer a single request is also sufficient to make sure that the seller has transferred the domain to the buyer.
The released system will offer various contracts for typical online transactions and enable adding of own contracts.
The contract will stipulate blocking of the buyer's funds for the period agreed by the parties.
If the seller fulfills the terms, as confirmed by the system, the funds are transferred to the seller, otherwise they are returned to the buyer.
The system operation is detailed below on the example of exchange dollars/Ethereum:
Alice (the buyer of dollars) and Bob (the seller of dollars) agree to conclude a transaction using PayPal.
An arbitrator is a user who confirms the request. He/she shall make a large deposit in the system’s currency so that to avoid cheating (POS like system).
Alice creates a contract, transfers her Ethereum and blocks it for some time. The same contract specifies the necessary data for execution thereof.
Bob transfers dollars, and if Alice denies the receipt of funds, he can use the services of an arbitrator to complete the contract in his favor.
If the transaction terms are honestly fulfilled, it is not necessary to pay for the arbitrator’s services, in case a dispute arises, the arbitrator receives the fee for his/her work.
In the simplified form, the arbitrator’s work is as follows:
Bob provides the arbitrator with the link to the payment receipt, and the arbitrator verifies that the link corresponds to the scheme specified in the contract.
To confirm the fact of funds transfer, the arbitrator makes a request through the buyer to the PayPal server. The verification of the certificate makes us confident that the answer is really provided from PayPal.
Using regular expressions, the arbitrator verifies that the funds were actually transferred to the necessary account (all data for verification are reflected in the original contract) and makes a decision in favor of one of the parties.
The solution is similar to that used with Oracles, but it allows verifying even the requests that require authentication data of one of the parties without disclosing them.
In this case, the authorization data shall be protected from the arbitrator so that to prevent their misuse.
In the beginning, we plan to implement the support of the most common TLS 1.2 with AES GCM symmetric encryption.
When encrypted, the data are divided into small blocks, and the seller can disclose only the blocks that are required to confirm the transaction.
The request is validated (confirmation that the disclosed blocks remain unchanged) by partial calculation of AuthTag by the arbitrator.
The collusion of the seller and the arbitrator is prevented by the fact that the buyer can request in the contract for the confirmation not from a single arbitrator but from N arbitrators, and each arbitrator shall make a large security deposit.
For the convenience of the mass user, browser extensions will be created to facilitate the interaction with the arbitrator (confirmation with a few clicks on the right page).
The idea in the system kernel can be extended not only to confirmation of the transaction, but, for example, to the validation of the identity.
In this case, the user makes a request to the data source (state system, client-bank), and the system validates the response.
If you are interested in this concept, please do not hesitate to ask your questions.