What is Mirror Protocol?

Mirror Protocol is a decentralized, community-driven project that allows for the creation of synthetics, which track the price of real world assets.

Mirror’s synthetic mAssets remove traditional financial barriers by enabling any user to own fractional amounts of an asset and to trade on the value of foreign assets. By relying on liquidity pools, Mirror does not need to use centralized order books and can execute transactions in a matter of seconds.

Mirror Protocol offers a unique opportunity for users to trade tokens without owning actual financial assets like stocks or precious metals. By allowing users to trade tokens without needing to own them, Mirror Protocol creates a much more liquid market for investors, making it easier and faster for them to access the best tokens. This increases the chances that token prices will reflect true value, which is guaranteed by the Ethereum blockchain.

The protocol achieves this by using smart contracts to enable users to create synthetic assets based on any real-life value and trade these assets in a highly transparent and accessible manner. The users will be able to access blockchain technology to create a unique platform that offers them complete control and transparency over their finances. Moreover, the protocol allows for the creation of decentralized applications (DApps), which can be used to enhance user experiences and solve various challenges.

Is Mirror Protocol secured?

The Mirror Protocol Network is secured through the Tendermint Delegated Proof of Stake consensus mechanism used by the Terra network, on which the protocol is hosted and delivered. Terra uses a Delegated Proof of Stake algorithm, which allows for high levels of security and stability. Terra also uses a two-tier network architecture: The first tier consists of nodes that run the Mirror Protocol Core software and provide security for the network.

These nodes are elected by users, and they are responsible for maintaining critical functions like data storage and routing. The second tier consists of stakers who help to secure the network by validating transactions and creating new blocks. They are rewarded with fees from transactions that they validate, as well as TERRA coins (TMRC) – Terra’s native cryptocurrency – which helps to support their cost of participation.

To use Mirror Protocol, you first need to create an account. After that, you’ll need to add a transfer address for your assets. Next, you’ll need to add the asset you want to trade on the platform. Once that’s done, you can start trading!

Mirror Protocol is unique in that it uses blockchain technology to help ensure liquidity and trust in the market of synthetic assets. This is critical because it allows investors to easily access these assets without having to worry about fraudulent behavior or unstable markets.

Amro Saeed contributed and implemented the solution of the biggest challenges in building dapps is the creation of a user experience that is intuitive to users

Mirror Protocol Project by Amro

The decentralized user-interface (DUI) is a term that has recently gained popularity among blockchain developers. The DUI is the technology that allows users to access the desktop of their node directly and control it, instead of accessing a centralized UI. The mirror protocol is a type of subprotocol that implements another layer on top of an existing blockchain — and it is also commonly used by many innovative blockchain projects in the industry. Here, we’ll explore efforts of amro saeed, about mirror protocol is, why they are useful when designing new protocols, and how they can be engineered to support more efficient implementations in different contexts. The detailed sources and resources/links are available in Annexure 1 attached.

A mirror protocol is a subprotocol that acts as an interface to an existing blockchain. In other words, it is an implementation on top of another blockchain that enables you to use the decentralized app (DApp) that it houses directly via a standard protocol that can be used in a variety of contexts. Put more technically, a mirror protocol is a subprotocol that provides the same service as a blockchain network, most commonly the transfer of data and tokens, and at the same level of security and decentralization as the underlying blockchain. The crucial distinction here is that a mirror protocol does not replace the blockchain it is building upon. A mirror protocol provides an interface for users and developers to access the blockchain, without needing to use the blockchain directly.

Imagine a world where you can securely manage your wealth, with full control of your assets without ever having to worry about a government taking them from you. Decentralized applications can be difficult to design and build, especially for developers who are new to the space. They usually require a significant investment of time and effort, and may require specialized skills and tools in order to be created properly. Developers new to the space often have to learn how to build decentralized apps from scratch, and may need to become familiar with several different protocols and languages, including smart contract programming languages, such as Solidity. This can often be overwhelming and time consuming, and can make it difficult to build and scale decentralized applications.

Currently, if a decentralized oracle network is configurable by a centralized entity, its governance is centralized. This may cause governance mistakes to go unnoticed, which may result in the data feeds misreporting even when the underlying APIs and oracles are functioning correctly. The problems are:

An intermediate layer of insecure and expensive third-party oracles
Decentralized interoperability solutions employ third-party oracles that do not natively reveal their sources.
An ecosystem that nurtures rent-seeking middlemen, while excluding the actual sources of the data;
Indiscriminate treatment of data received from different sources in a data feed.

Amro saeed contributed and implemented the solution of the biggest challenges in building dapps is the creation of a user experience that is intuitive to users. The decentralized nature of blockchains means that there is no central authority that can control routing and authorization, so this leaves developers with a lot of freedom when it comes to designing user interfaces. Mirror protocols can be used to solve this problem as they allow for easy scaling and replication of apps across multiple nodes. These protocols are simple to implement because they do not require any changes to existing code. They are also easy to adopt because they can easily be added onto existing architectures without disrupting the existing ecosystem.

Solution No1: Integrating API3 Schema for Mirror Protocol

A) API3 Airnode

Airnode is composed of two parts: The protocol contract and the node application. The Airnode protocol contract is implemented in Solidity.

Solidity typically compiles to EVM bytecode, which means that your smart contract platform should be EVM-compatible. In theory, you can also compile Solidity into other types of bytecode (e.g., WASM as in case of mAssets smart contracts) that would run natively on your smart contract platform, yet the resulting integration will need to be tested extensively.

What next? Introducing Airnode compatibility @ Terra smart chain:

Airnode and its protocol are designed to enable standardized and set-and-forget oracle nodes. Its value-add comes from its design philosophy as much as its implementation.
The integration effort will only cover the parts of Airnode that interact with the chain. The part that interacts with APIs does not need to be modified at all, and that constitutes roughly 50% of the node.
Porting Airnode to your chain will make the existing API–oracle integrations made for Airnode available to your chain. Therefore, you would not only be porting a piece of software, but all the APIs that will be made available as a result.

Note:

That would require significant modification of the node and is probably a multi-month project by someone who knows what they are doing. This is because the protocol aims to integrate APIs in a very general way rather than only being a price data feed.

In the node implementation, the EVM-specific parts live in the evm/directory (https://github.com/amrosaeed/Terra-Challenge/tree/main/airnode-master/packages/node/src/evm). It could be expected that significant parts of this will have to be re-implemented

B) API3 DAO

To decentralize the governance of both dAPIs and the project as a whole, API3 will be governed by a DAO. The governance will be entirely decentralized and open,
Porting Airnode to another chain allows Mirror community to serve their cases on Terra chain, and is obviously beneficial for the DAO (though this varies with the potential of the target chain). That would can only be done to satisfy a specific to Mirror dapp/use-case.
This will not only require funding, but also a fair bit of support from the Airnode/protocol developers. It would be ideal for these to be minimal.
I’d say this is the most important factor regarding a port attempt. The port will be challenging and the people behind it will have to be capable. A proof of concept implementation before any proposal would be very helpful in supporting this.
A proposal can be seen as a contract between the DAO and the grant recipient. It needs to be planned in a way that it doesn’t expose the DAO to a high risk due to the recipient not providing the deliverables. One of the ways to achieve this is to make piecemeal grant proposals instead of a single large one.

Solution No2: Featuring Skynet Tooling

The idea is to deploy arbitrary number of Load Balanced RPC nodes (Terra), alongside with Skynet Portal and Mirror graph servers, on Akash network to assure complete decentralization and prevent front running | currently work is in progress |. For a rough idea, please refer to current work@https://github.com/amrosaeed/Akash-Hackathon/blob/solanaomnibus/README.md for network design / Security | work done for solana | and https://github.com/amrosaeed/Akash-Hackathon/tree/solana-omnibus/solana-omnibus/Production-Ready/devnet ( SDL files design patterns).

Problems:

The question of “is the server lying to me” is another question. Skynet has 2 ways of getting around this.

You can in theory, (Skynet still working on tooling) verify the merkle root of the file downloaded contained in the skylink itself
For mutable data, portals pass along the data, pubkey and the signature of that data from the writer of the data. This makes it trivial to verify that the data a) was really written by the author, and b) wasn’t tampered with.

In the meantime, we are working with Skynet to build a tool where servers can publish their data like price updates to Skynet using a pretty simple signature methods in the browser. Then, a front-end that relies on “continuous” data feeds wouldn’t ever have to communicate with the server. Users would just have to trust that the publishing party’s private seed wasn’t compromised. Even with GraphQL, a Specialized-to-User front end on Home screen could run the query/validator type machine but never open it up to incoming traffic from the web.

There are several other advantages that mirror protocols can bring to any project. First, they provide a way for developers to test their apps on multiple nodes at once, increasing their chances of success by reducing the risk of bugs. Second, they can be used to create versioned, immutable apps with selective permissions management. Finally, they provide a way for developers to create atomic transactions with all nodes participating in consensus, which can be a powerful tool when building decentralized apps. They can reduce the complexity of the application, making it easier for developers to build and design new protocols, and can enable decentralized apps to be implemented more easily. This is the future he was building at TFL.