Technology Behind

Cross-Chain Technology

Cross-chain data exchange is the problem to transfer data from one blockchain (source chain) to another blockchain (target chain). Source chain and target chain could be based on either the same platform (e.g., blockchains that are forked from the Ethereum repository are considered the same platform), or completely different platforms (e.g., Bitcoin and Ethereum).

Among popular names in the cross-chain projects, Cosmos and Polkadot are the two representatives. Cosmos aims to provide SDK to quickly develop blockchains by composing common components (e.g., consensus component) and application-specific components. Since the core components are shared, Cosmos SDK-based blockchains could be able to share data seamlessly. On the other hand, Polkadot aims to link heterogeneous blockchains (e..g, bitcoin, ethereum,…) by treating these existing chains as virtual paralized chains thanks to the relay component inside Polkadot validators.

The key idea of cross-chain data exchange is to employ bridge servers (aka relayer components). A bridge server of two blockchains basically is a combination of nodes in two blockchains. So, a relayer could listen to events happening in both chains, and is able to recreate new transactions in one blockchain that mimic transactions in the other blockchain to forward data (e.g., token transfer) from one chain to another chain. This idea is applied in both Cosmos and Polkadot.

Obviously, depending on the kind of data, additional steps (and components) are developed to complete the exchange process. For example, to transfer tokens from one chain to another chain, the data to broadcast across chain is sender/receiver addresses, and amount of tokens (for account-based chains) or tokens’ IDs to send (for UTXO-based chains)

Decentralization

Decentralization is a very important feature in the blockchain world. Users now no longer need to trust any single entity, but a community. Activities within the Muse.Finance are controlled by decentralized protocols, operated by open source software that removes human interaction while processing transactions, and thus prevents interference from any single entity.

Decentralization in the Muse.Finance is presented by enforcing important events with multisig, in particular. The depositing transactions relayed from the Cardano network are confirmed and signed by at least ⅔ of all Cardano relayers in order to be proceeded.

Another crucial point of decentralization in Muse.Finance is the deposit wallet. The deposit wallet keeps the users’ assets. It therefore should not be controlled by a single entity. Ideally, the deposit wallet should be a fully decentralized wallet that no one could manipulate, but the predefined execution logic.

Such a decentralized wallet is a smart contract that could receive and transfer tokens, for example Ethereum smart contract. However many existing blockchains have not supported this feature thus far. Hence, an in-the-middle solution is a multisig wallet.

The multisig deposit wallet is controlled by a group of parties, called the key management consortium. Operations regarding the deposit wallet (e.g., transfer funds) require at least ⅔ of members to agree and sign on transactions.

Members of the key management consortium are elected at the beginning, but could be changed later e.g., a new member joins, and an old member leaves. In this case the deposit wallet will be updated to revoke the private key of the former members, and incorporate the private keys of new members.

There are some approaches for multisig wallets:

● Native multisig wallet supported by blockchains (e.g., Bitcoin),

● Smart contract,

● Advance cryptography techniques (threshold signature, multi-party computation,…)

The first two approaches require a native support from the blockchain platform. For example, the Bitcoin blockchain supports n-of-m multisig scheme, not smart contract; meanwhile, the Ethereum platform supports smart contract, not native multisig wallets. The last approach, on the other hand, is blockchain independence and thus could be applied for most existing blockchains. However, this approach is complicated and requires more implementation effort.

Data Security

(1) Confidentiality

Assets deposited to the deposit wallet are well protected. No single entity could manipulate the deposited assets, even the administrators of Muse Wrap’s bridges. The minting and redeem processes are controlled by open source smart contracts. This ensures the equivalent of the deposited tokens and liquidity tokens.

● Liquidity tokens are generated only when corresponding tokens are safely stored in the deposit wallet

● Deposited assets are staked in delegation mode, i.e., funds are always kept in the deposit wallet.

● Users could anytime redeem their liquidity tokens. The redeemed tokens are sent directly to the users’ registered wallets. Only users with corresponding private keys could update their registered wallets.

(2) Integrity

The data integrity in Muse Wrap is guaranteed in the asynchronous and distributed manner. Similar to other blockchain platforms, the data consistency and integrity among validators require certain delay to be synchronized. However, thanks to the consensus protocol, the data between nodes of Muse Wrap are synchronized. Any change made to the Muse Wrap requires approval of the majority of validators to proceed.

● Any deposit/redeem transactions in the source/target chain (e.g., Cosmos, Cardano,…) will be eventually relaid to the Muse Wrapping contract, even when all Relayers are temporarily down. When relayers are up, they will be synchronized with deposit transactions from the time they were shut down.

(3) Availability

Availability is considered carefully in the design of the Muse Wrap. There is no single point of failure within the design. The failure of any single component/server will not impact the operation of Muse Wrap.

Every component has multiple instances running on different physical servers at different geographical locations. When an instance shuts down, multiple instances with the same functionality will take over. An alert message will be sent to the administrators to repair and restart the failed instance in the shortest possible time. The restart instance will be synchronized with others and get back to normal operation