Proof Protocol : Building trust between interchain dapps in cryptographically decentralized fashion.

Demo

About

The problem it solves Below are challenges which Proof Protocol solves: 1. Trust: It brings trust between two dapps running on different chain. Trust is achieved because any data or value on one dapp can be cryptographically presented and verified on other chain. In its core, it uses EVM merkle proof concept which is secure and difficult to forge. 2. Fast transaction: As protocol consumes EVM storage off chain, it doesn’t overload network with transaction and makes verification process cheaper and faster. 3. Incentives: The protocol is fully decentralized. Proof Verifiers contributing in the network get incentives from transaction fees paid by proof requester. 4. Open Network: Any proof verifier nodes can join the network by staking some amount, which makes the network open and transparent.

How it's made

Challenges we ran into 1. EVM internals: One of the major module in the solution was to generate merkle storage proof to verify data of one dapp on the request of other dapps. Generation of storage proof is really tricky for struct type of variable due to EVM design. It requires deep understanding of EVM internal and merkle patricia tree. 2. Geth LevelDB access: Geth uses level db to store ethereum state data. Only one process can access leveldb at a time. If geth is syncing latest chain data, proof verifier process can’t access leveldb. We have solved this problem using rsync, which syncs level db data to other location. 3. Random behavior of event handler module(Block scanner) on ropsten: Proof verifiers nodes need to continuously listen to few events like proofRequested etc. But On ropsten, event handler module behaved inconsistently and wasn’t able to listen to event. The possible cause for this can be fluctuating websocket connection to geth on infura. 4. Implementing POS Reward and Punishment Logic: To grow the community, its important to reward the good proof verifiers and punish bad proof verifiers. For rewarding, we plan to use POS “Coin Age Based Selection” algorithm in which Users who have staked older and larger sets of coins have a greater chance of being assigned to forge the next block. We are still in progress to establish how to punish the bad proof verifiers. One approach is to partially destroy deposits of proof verifiers that make mistakes. This ensures that validators lose all of their deposits in the event of an actual attack, but only a small part of their deposits in the event of a one-off mistake.