Router Working Mechanism
-
Router Working Mechanism
Nodes Structure
The relationship between C3Caller-Relayer and MPC can be seen in the above diagram. The C3Caller-Relayer node includes all the functionalities of the message cross-chain. It is highly available and scalable, with stateless nodes that do not communicate with each other. When performance is insufficient, it can be horizontally scaled. Currently, the plan is to deploy two or three nodes to form a cluster, relying on a MySQL database and Redis cache.
It is enhancing the current node services for high availability, scalability, and performance. The proposed system will include stateless nodes in a cluster formation, supported by a MySQL database and Redis cache.
- The C3Caller-Relayer node includes token and message cross-chain functionalities, offering high availability and scalability.
- Nodes are stateless, not communicating with each other, allowing horizontal scalability.
- Planned deployment of a cluster, relying on MySQL and Redis.
- RpcGateway supplies a union-high availability of blockchain RPC when C3Caller-Relayer requests. it always forwards requests to those with the highest Blocknumber of all the RPCs.
Contracts
The contract structure is shown in the above diagram.- C3DappManager is Dapp manager Contract, which handles the pre-stored fees and Dapp register.
- C3CallerDapp is a entry point so if Dapp Contract extends it, it could call the
c3call()method - C3CallerProxy is a Upgradeable contract and holds an instance of IC3Caller so that we could upgrade C3Caller if a new version C3Caller comes.
- C3Caller is a real logic contract which have
c3callc3fallbackandexecute - The management rights of the contracts are generated using the MPC network.
-
This information is also in our docs here :- https://docs.continuumdao.org/ContinuumDAO/RouterWorkingMechanism
The code is on github as a private repository, that will be made public in due course.
-
Some questions need your thoughts:
Since we are launching a brand new MPC architecture, we have the opportunity to make an efficient system, fixing issues from the past. The contracts refer to the public code of MC and make corresponding optimizations.
From the current design of the MPC-network, C3Caller. We have several problems that need to be solved:
- Distinct Node Groups with Varied Functions:
- In the C3 Protocol, the nodes (C3Caller) operate distinctly from CTM-MPC nodes. Each group serves different purposes and utilities. Specifically, C3 Protocol nodes require a team of at least three individuals who can manage them diligently and respond swiftly to any issues.
- Considerations for Launching a CTM Bridge:
- Flexible Fee Structure: The fee system of the upper-level Dapp Router should be adaptable. It must have the capacity to quickly adjust in response to market fluctuations.
- Dedicated Chain-Integration and Support: Establishing a specialized operation team to provide round-the-clock support and integration services is crucial.
- Liquidity Strategies: We need to focus on securing liquidity sources. This includes venture capital and designing incentives around liquidity tokenomics.
-
In terms of scale what will be the mapping of caller nodes to MPC nodes in order to run efficiently? What is the criteria for running the different forms? Do you need a level of expertise to provides the kind of support you mention or can these be learned?
-
@chookz The difference between the MPC nodes and the C3Caller-relayer nodes is as follows:
The MPC nodes are run by a separate protocol (ContinuumDAO), whose only purpose is to guarantee decentralized secure cross-chain signing in an open and transparent way. Members of the DAO will be able to run nodes and be rewarded for doing so. Running a node will be as easy as possible, with no programming knowledge required and with clear instructions. If the community finds it difficult to run the nodes, we will find a way to make it easier.
The C3Caller-relayer nodes are designed to be run by people with more knowledge of Linux. These will be run by selected individuals with the required skill set. The main reason to have more than one these types of node running is to provide redundancy. There is no signature algorithm in these nodes.
In the case where one node goes out of action, the servicing of cross-chain requests will revert to another node. This eliminates a key vulnerability that Multichain had. The C3Caller-relayer nodes will also handle new dApp integration and fee collection. The reason that they will do this is to keep the MPC nodes as simple as possible.We are aiming to make it possible for multiple simultaneous cross-chain signings to take place, using different groups of MPC nodes, being served by C3Caller-relayer nodes. This means that our service can expand, with ever more MPC nodes and C3Caller-relayer nodes as required, with no reduction in speed during times of higher traffic. This flexibility will also ensure that problematic MPC nodes will not halt cross-chain services, as they sometimes did in Multichain, with much heartache.
-
We have learned the lessons from Multichain - No centralization (DAO run), and an open transparent MPC node network, run by the community.
Other pain points from Multichain have also been addressed, such as stuck transactions. These were caused by lagging RPC gateways (we will use the current best from a selection of them at any time), nonce errors (we will implement code in the MPC layer to revert these), faulty MPC nodes (we will allow switching to other better performing nodes and have parallel execution of signing).
Our aim is to be the gold standard for cross-chain interaction.
-
@Selqui what is the security threshold for either type of node? How does it keep bad nodes in check? Is there a way to verify or guarantee decentralization of nodes, and will we have autonomous smart contract nodes that could potentially run on decentralized networks?
-
the threshold is configurable according to different security level, and there exist a reshare scheme to tackle the case where someone offline forever or lost key share.
we'll provide a detailed dashboard to provide more info about the node so as to ensure distributed.
