@GFXlabs team, thank you very much for your replies. We want to summarize and supplement some of our answers to your questions.
It does have a multisig owner that can upgrade the contract logic. However, for Uniswap’s use case, the upgradability won’t pose a risk because even if a fraudulent message is passed to the destination chain somehow (be that due to a malicious contract upgrade or validator consensus failure), the App Guardian will be able to stop that message from being executed.
Celer has a total of 21 validators, which are highly reputable PoS validators securing chains such as Binance Chain, Avalanche, Cosmos and more, such as Binance, Everstake, Infstone, Ankr, Forbole, 01Node, OKEX, HashQuark, RockX and more. Many of them are shared validators with Wormhole.
For the simple governance contract used to upgrade smart contract, the signers are InfStone, Binance Staking, OKEX and Celer Foundation. We will add that to our documentation section.
Apologies that we forgot to follow up on this. For the most direct reference, please see the reference implementation of the “optimistic-rollup-style” security model that is running for Uniswap testnet and updated doc on how to run an App Guardian.
This is correct. However, this is only for the cBridge use case. For Uniswap’s use case, the app guardian set can be different.
There might be a misunderstanding. The vendor-lock-in-free architecture is relevant in this case because it applies whenever a new chain is added to Uniswap’s supported chains. For this BSC deployment, multiple bridges can be used simultaneously to achieve much better decentralization and security.
To @Kydo team,
Thank you for your review and comments.
We 100% agree. deBridge, Celer and you all raised the same point. That is half of the active participants in this discussion. This is not hard to do. In addition, we offered to make an implementation available within 72 hours.
Unfortunately, despite all the above, an option to build a vendor lock-in-free architecture was still not made available in the recent temperature check for the Binance Chain deployment.
There might be a strong and valid reason to push the deployment of a less open architecture under an extremely tight deadline.
If you still would like to support this open architecture for an open dex like Uniswap, please vote for Celer. Regardless of the outcome of the temperature check, we will implement the architecture in a vendor-lock-in-free way in 72 hours and conduct audits with community-approved firms to make it readily available as a contribution to the Uniswap community.
Even if it is too late for Binance Chain, we sincerely hope that future Uniswap expansion can be done using this open and flexible model and the value of Uniswap community can remain open and decentralized.
We hope our push for open and decentralized architecture can be heard in this community.
Could you please elaborate on this concern?
Celer is run by 21 validators who are all renowned PoS providers, such as Binance, Everstake, Infstone, Ankr, Forbole, 01Node, OKEX, HashQuark and RockX, many of which overlap with Wormhole’s validators. In addition, Celer contains built-in slashing mechanisms. Wormhole does not have any economic security or slashing built in the protocol. If there is any other centralized/off-chain agreement, we hope wormhole can make them known to the community. Just by looking at this comparison, a reasonable level of economic security in protocol >> 0 economic security in the protocol.
Of course, Celer is also working towards building additional zero-knowledge-succinct-proof-based cross-chain message-passing mechanisms that remove the responsibility of message correctness/security from the validators altogether and only rely on them for liveness.