The creative convergence of Off-chain Streaming Data and On-chain Cryptographic Randomness to build Cyber Physical Systems powered by Decentralised Data Oracles deployed on Matic Network

Carousel Gallery Item: 1
Carousel Gallery Item: 2
Carousel Gallery Item: 3
Carousel Gallery Item: 4
Carousel Gallery Item: 5

Last updated: 25 September 2020 06:31 PM

Updated the Project Repository and Project Description

The problem ConcertNet solves

Lack of a secure and scalable end to end integrated frameworks in smart contract-based blockchain protocols and platforms to integrate Cryptographically Verified Ranomness powered Oracles and DAOs into Tokens, Token Swaps, and DApps. Thus our FusionLedger framework is designed for On-chain and Off-chain interaction between real work data and digital world institutions. FusionOracles will represent the real-world data and FractalDAOs represent the digital world institutions like Banks, Treasuries, Markets, etc.

We have demonstrated an on-chain ZK Rollup together with Onchain Randomness of VDF for Random Oracles Proof of Concept and Random DAOs. This is the first implementation of RANDAO + VDF as per the Justin Drake model. We have also implemented an Atomic Token Swap between two Tokens - Fusion Token and Fractal Token. Fusion Ledger is thus a combination of Fusion Oracles and Fractal DAOs.

Our approach is a workflow from Fusion Oracles to Fractal DAOs. We are tokenizing Fusion Oracles. We are also tokenizing Fractal DAO. We have tokenized Oracles by applying VDF. Thus they are technically random oracles in the cryptographic sense. We have also tokenized DAOs by applying VDF. We can term them Random DAOs.

Now we would like to demonstrate how an Auction App powered by Portis SDK can benefit from this Fractal DAO and Fusion Oracles. We also would like to convert the Fusion Rollup Contract to a Matic Child Chain demonstrating the combined scalability architecture of ZK RollUps and Matic Network.

Challenges we ran into

We initially faced issues in selecting a uniform solidity compiler version as VFDs were written in 0.5 incremental versions and Open Zeppelin contracts were written in 0.6 incremental versions. Hence we had to migrate some of the contracts from VDF. Likewise, we also faced some issues in implementing Token Swap as the Atomic Swap framework was in a legacy version of Solidity. We also faced some issues in creating an oracle contract from time-series data. We have overcome the solidity version issues by migration techniques. We have finally used the Truffle framework customized for the solidity version 0.6.2 to compile and deploy all the contracts.