As you have seen in the forum, new information on the bridge selected in the Temp Check proposal (Celer) has been made available since the Temp Check took place. Additionally, two new bridges – Wormhole and Layer Zero – have raised their hands to be the provider for the BNB deployment (in addition to deBridge, the initial bridge selected prior to Celer).
For cross-chain deployment proposals, we believe it is most important to optimize for protocol security — specifically, for community members to be able to make informed decisions based on all available information on risks to bridge security. Secondary to that is clarity of process for all governance stakeholders. In order to satisfy both of those conditions, we propose the following next steps for this BNB proposal:
For this BNB proposal only, we have an additional Temperature Check for the community to vote on the four bridges which have been discussed in the forum or this proposal: deBridge, Celer, Wormhole, and LayerZero.
At that point, the winning bridge with the most UNI votes will be used in the final governance vote for the BNB deployment.
Link to the forum discussion.
As you have seen in the forum, new information on the bridge selected in the Temp Check proposal (Celer) has been made available since the Temp Check took place. Additionally, two new bridges – Wormhole and Layer Zero – have raised their hands to be the provider for the BNB deployment (in addition to deBridge, the initial bridge selected prior to Celer).
For cross-chain deployment proposals, we believe it is most important to optimize for protocol security — specifically, for community members to be able to make informed decisions based on all available information on risks to bridge security. Secondary to that is clarity of process for all governance stakeholders. In order to satisfy both of those conditions, we propose the following next steps for this BNB proposal:
For this BNB proposal only, we have an additional Temperature Check for the community to vote on the four bridges which have been discussed in the forum or this proposal: deBridge, Celer, Wormhole, and LayerZero.
At that point, the winning bridge with the most UNI votes will be used in the final governance vote for the BNB deployment.
Link to the forum discussion.
Full comments provided here: https://gov.uniswap.org/t/rfc-update-deploy-uniswap-v3-1-0-3-0-05-0-01-on-bnb-chain-binance/19734/77?u=kydo
Full comments provided here: https://gov.uniswap.org/t/rfc-update-deploy-uniswap-v3-1-0-3-0-05-0-01-on-bnb-chain-binance/19734/77?u=kydo
for sure LI . FI is huge player on crypto field, technology is very fresh and crypto community need it YES! :)
Jesse here, commenting both on behalf of Variant and separately, in my role as a delegate.
I and Variant decided to vote “no” on the Uniswap v3 deployment to BSC.
Jesse here, commenting both on behalf of Variant and separately, in my role as a delegate.
I and Variant decided to vote “no” on the Uniswap v3 deployment to BSC.
Earlier I commented that it’s suboptimal for communities to be voting on singular bridges, and that the v3 BSC discussion has highlighted a valuable opportunity to rethink deployment design from first principles. Luckily, the ball is already rolling:
Uniswap is a leader within the broader ecosystem, and the process here has the potential to set a standard for new chain deployments. There’s good progress in the works for building more modular deployment solutions, and I think it’s better for the protocol to fully explore those – and other emerging solutions – before finalizing a v3 BSC deployment.
Disclaimer: Variant is an investor in UNI tokens and Hyperlane. Disclosures – Variant
It's a yes for me, sir. Thanks a bunch, sir
The urgency of the Uniswap governance making a decision on launching Uniswap V3 and incentivizing LP to migrate from PancakeSwap on BSC should be the overriding factor in this discussion - not bridge choices. With PancakeSwap detailing plans to launch their V3 model on the same day as the expiration of Uniswap's V3 BSL licence, it is crucial for the Uniswap governance to act swiftly and make a decision to remain competitive in light of PancakeSwap's dominance in BSC decentralized exchange market. PancakeSwap already owns the largest liquidity depth in their V2 system, and having PancakeSwap launch a V3+ V2 router would only result in further lowering slippage within their ecosystem. Failure to accept the on-chain vote as-is could not only result in a failure of Uniswap V3 garnering enough liquidity to be competitive over PancakeSwaps V2 model, but also hinder Uniswap V3 as a second-tier decentralized exchange on BSC.
See: https://twitter.com/PancakeSwap/status/1620427176356216835?ref_src=twsrc^tfw
Over the past few months, LI.FI (a bridge aggregator supporting 13 bridges) has been closely monitoring the development in Uniswap’s Forum related to the BNB Chain Deployment Proposal, its subsequent Snapshot Poll which ended on Jan 31, and the current on-chain vote in favor of implementing Wormhole.
that's a good idea and can help the Crypto
Hey All. Sergey from the Axelar Network here.
It’s great to see Uniswap expanding! We note that choosing a cross-chain provider is a highly technical and delicate question that requires careful planning, resource allocation, and coordination for a successful deployment. We support pursuing the Cross-Chain Assessment Process outlined by @devinwalsh to better benchmark the pros and cons of each proposal and will post answers on that thread.
for sure LI . FI is huge player on crypto field, technology is very fresh and crypto community need it YES! :)
Jesse here, commenting both on behalf of Variant and separately, in my role as a delegate.
I and Variant decided to vote “no” on the Uniswap v3 deployment to BSC.
Jesse here, commenting both on behalf of Variant and separately, in my role as a delegate.
I and Variant decided to vote “no” on the Uniswap v3 deployment to BSC.
Earlier I commented that it’s suboptimal for communities to be voting on singular bridges, and that the v3 BSC discussion has highlighted a valuable opportunity to rethink deployment design from first principles. Luckily, the ball is already rolling:
Uniswap is a leader within the broader ecosystem, and the process here has the potential to set a standard for new chain deployments. There’s good progress in the works for building more modular deployment solutions, and I think it’s better for the protocol to fully explore those – and other emerging solutions – before finalizing a v3 BSC deployment.
Disclaimer: Variant is an investor in UNI tokens and Hyperlane. Disclosures – Variant
It's a yes for me, sir. Thanks a bunch, sir
The urgency of the Uniswap governance making a decision on launching Uniswap V3 and incentivizing LP to migrate from PancakeSwap on BSC should be the overriding factor in this discussion - not bridge choices. With PancakeSwap detailing plans to launch their V3 model on the same day as the expiration of Uniswap's V3 BSL licence, it is crucial for the Uniswap governance to act swiftly and make a decision to remain competitive in light of PancakeSwap's dominance in BSC decentralized exchange market. PancakeSwap already owns the largest liquidity depth in their V2 system, and having PancakeSwap launch a V3+ V2 router would only result in further lowering slippage within their ecosystem. Failure to accept the on-chain vote as-is could not only result in a failure of Uniswap V3 garnering enough liquidity to be competitive over PancakeSwaps V2 model, but also hinder Uniswap V3 as a second-tier decentralized exchange on BSC.
See: https://twitter.com/PancakeSwap/status/1620427176356216835?ref_src=twsrc^tfw
Over the past few months, LI.FI (a bridge aggregator supporting 13 bridges) has been closely monitoring the development in Uniswap’s Forum related to the BNB Chain Deployment Proposal, its subsequent Snapshot Poll which ended on Jan 31, and the current on-chain vote in favor of implementing Wormhole.
that's a good idea and can help the Crypto
Hey All. Sergey from the Axelar Network here.
It’s great to see Uniswap expanding! We note that choosing a cross-chain provider is a highly technical and delicate question that requires careful planning, resource allocation, and coordination for a successful deployment. We support pursuing the Cross-Chain Assessment Process outlined by @devinwalsh to better benchmark the pros and cons of each proposal and will post answers on that thread.
Over the past few months, LI.FI (a bridge aggregator supporting 13 bridges) has been closely monitoring the development in Uniswap’s Forum related to the BNB Chain Deployment Proposal, its subsequent Snapshot Poll which ended on Jan 31, and the current on-chain vote in favor of implementing Wormhole.
While we applaud the interest shown by key stakeholders of the crypto ecosystem in finding a suitable bridging solution for Uniswap’s Cross-Chain Governance, we strongly recommend that Uniswap not select one bridge provider for its BNB Chain Deployment Proposal. Specifically, we do not believe the BNB Chain Deployment Proposal should move forward before more research can be done, even if this may come as a letdown to many community members – be it bridge builders or other individuals.
Instead, we urge the Uniswap Foundation and the Uniswap community to fully immerse themselves in the Cross-Chain Assessment Process outlined by @devinwalsh. While the sprint to move to BNB Chain before the business license expires is important, we believe finding a long-term solution for cross-chain governance to be far more important than the short-term win of deploying V3 code first. There will be new chains, new versions of Uniswap, but there will never be another chance to expand governance safely and securely on the first try. Uniswap is a market leader in design (AMMs), token structure (airdrops), and overall competency, and LI.FI believes that the model Uniswap chooses for cross-chain governance has a high chance of becoming industry standard. We – as members of the crypto industry – want to see this done the correct way, and from the start.
Bridges, specifically arbitrary messaging bridges (AMBs), are in the nascent stages of development. Short-term, Wormhole, LayerZero, Celer, Axelar and deBridge are certainly viable solutions for cross-chain governance and have received substantial traction in terms of volume at the liquidity layer and development by dApps at the messaging layer.
That being said, we at LI.FI have done the research on AMBs (Navigating Arbitrary Messaging Bridges) and have delved deeply into the pros and cons of eight different AMB solutions. Our conclusion is simple: no single AMB is tested enough to be considered a robust and secure solution that a project of Uniswap’s size can solely rely on at this point. If there was a single, obvious AMB solution that could be trusted by Uniswap, then this forum post would not be necessary. Lest it be forgotten, two major AMBs were exploited in the past twelve months (Nomad and Wormhole), while LayerZero has also come under fire recently for its security model (Prestwich, L2Beat). We do not say this as condemnation, rather, we point this out to highlight just how difficult it is to build secure AMBs and the subsequent risks a dApp is exposed to by choosing a single bridging solution. In addition to this sentiment, we believe AMBs like Axelar, Synapse, Hyperlane, Multichain, Connext Amarok, and Hop deserve to be considered by Uniswap and the deadline of two and half weeks is too short for them to be formally introduced, debated, and voted upon again.
To summarize, LI.FI stands staunchly behind the concerns previously raised by @Kydo, @AlexSmirnov, and @modong. LI.FI believes that a multi-bridge, agnostic approach is best suited for Uniswap cross-chain governance because of the following reasons:
So, where do we go from here?
More research is in order, which we believe should be two-pronged.
1. Cross-Chain Bridge Assessment Framework
We would like to add our own feedback to Devin’s framework and add an additional step to the process.
The MMA solution or any other multi-bridge solution is built on the idea of Uniswap choosing multiple bridges as “adapters.” The first thing to do, therefore, is to determine which bridges meet Uniswap standards, as outlined by @devinwalsh.
We believe that Uniswap should first build a unique framework to both quantitatively and qualitatively measure and allow for the ranking of different bridge solutions by the engineering team. This would decrease the workload of the engineering team by letting them focus on stress-testing bridge solutions without having to create the parameters of such a test themselves.
As one of the largest players in DeFi, Uniswap has the chance to create the de facto bridge assessment criterion.
By our estimation, there are four bridge framework solutions currently in the ether.
Uniswap has the chance to build upon, combine, and quantify the works of four major research pieces without having to start from scratch.
With that in mind, we recommend that Devin’s initial Cross Chain Bridge Assessment make room for four researchers, who can help build this framework to assist the engineering team, who can then test out different bridging solutions based on the criteria mentioned in the framework and select which bridges make the cut to become a part of the multi-bridge solution.
The researchers will then explain the decision of the team through easy to digest articles, which can be used by other builders to assess bridges for their own dApps and by users to expand their knowledge of bridges and make more informed decisions when it comes to choosing a bridging solution for their needs. To this end, collaborations with other public good infrastructure projects like L2BEAT, Ethereum.org, among others, should also be considered to spread awareness and educate the public about bridges.
As Devin laid out, these individuals should be available for 10-15 hours per week over the next few weeks to participate in the assessment process, and to write up their findings in a report to share with the community.
To this end, we recommend Peter Robinson, Arjun Chand, Ermyas Abebe, and Bartek Kiepuszewski (though we believe Uniswap should have the final call here).
We believe the current timeframe is aggressive but doable. However, if the list of bridges were to expand, we would recommend pushing back the March 27th date.
2. Consideration of Making the Universal Governance Model an EIP
Uniswap pushing for a cross-chain governance EIP would be net positive for the industry, in our opinion, specifically in the context of a multi-bridge solution. Such an EIP would give dApps a shared template for creating safe, secure governance modules, while also giving flexibility for dApps to choose different bridging solutions based on their security, time, and cost preferences.
To that end, we believe that Uniswap should create and propose a new cross-chain EIP based on the design outlined by Mo Dong from Celer and Alex from deBridge (with, of course, any tweaks recommended by the engineering and research team).
Additionally, there are two EIPs and one forum post that Uniswap should consider learning from and building upon in addition to the framework above.
In our estimation, none of these solutions have captured enough mindshare to become industry standard. However, they have all pushed the envelope in what can be done in standardizing messaging, and Uniswap could learn much from it.
We recommend that Uniswap employ the same four-engineering team to standardize the MMA solution as an EVM-compatible EIP.
Given Uniswap’s position and influence in the ecosystem, it has the power to push an EIP that can potentially become the de-facto solution for any project indulging in cross-chain governance.
Conclusion
A multi-bridge, agnostic solution that the community invests resources into is a win-win-win for all the parties involved (Uniswap, bridging solutions, and the dApps that will implement this solution for cross-chain governance in the future).
As Devin said, the developments as a result of the proposed deployment on BNB Chain are net-positive for the ecosystem. Open discussions about bridge designs and frameworks for assessing security risks associated with them are exactly what we need to fast-forward the maturity of the bridging solutions and enable the development of secure bridges.
We look forward to the feedback of the UF and the community on our proposal.
Hey All. Sergey from the Axelar Network here.
It’s great to see Uniswap expanding! We note that choosing a cross-chain provider is a highly technical and delicate question that requires careful planning, resource allocation, and coordination for a successful deployment. We support pursuing the Cross-Chain Assessment Process outlined by @devinwalsh to better benchmark the pros and cons of each proposal and will post answers on that thread.
The Axelar network is built from the ground up using Cosmos SDK and already connects over 30 chains including Ethereum, Cosmos chain, Arbitrum, Polygon, Avalanche, and others (see https://axelarscan.io), and new chains are added regularly. The Axelar network has been running on mainnet since Jan 2022 and has processed over $1.75 billion of volume in >350k transactions. Axelar’s ecosystem has thousands of builders using our decentralized and permissionless infrastructure, creating hundreds of unique cross-chain applications. Multiple connectivity paths can be connected to the Axelar network, leveraging its many-to-many transport and routing properties, improving the security of individual connections. Applications built on top can benefit from these improvements without additional changes.
We propose to instantiate interoperability for Uniswap by leveraging the Axelar decentralized network, powered by Proof of Stake consensus and many safety features, and augment it with an additional Uniswap-specific validator set. The Uniswap-specific validator set may be elected via UNI governance, and be instantiated based on Proof-of-Stake, Proof-of-Authority, or any other validator selection rule deemed needed. A custom policy can be instantiated to authorize messages of different value/importance. See our recent blog post for how to instantiate deployments based on different validation logic using Axelar. We’ll post full answers to the questions asked in Cross-Chain Assessment Process shortly and look forward to continuing the discussion with the Uniswap community.
On Monday, I posted a few thoughts which amounted to my decision to abstain from a voting on which bridge Uniswap should use in its deployment of v3 to BNB.
I want to take the opportunity to expand and point to areas for development where I’m excited to see progress. I also wanted to more explicitly commend Devin and UF for their work in stewarding the process here and on other issues, which in sum, has resulted in a lot more momentum in community governance.
On Monday, I posted a few thoughts which amounted to my decision to abstain from a voting on which bridge Uniswap should use in its deployment of v3 to BNB.
I want to take the opportunity to expand and point to areas for development where I’m excited to see progress. I also wanted to more explicitly commend Devin and UF for their work in stewarding the process here and on other issues, which in sum, has resulted in a lot more momentum in community governance.
Process-wise, the Uniswap Foundation holding a temperature check on which bridge to use in the BSC deployment served both to generally highlight the issue of bridge selection in cross-chain deployment, and advance the decision in this particular instance. Action begets action, and continued forward movement is critical in decentralized governance.
The discussion around the merits of each bridge being considered here was absolutely better than leaving that discussion unconsidered at all. Was it comprehensive? No. That is why I abstained from voting. Was it forward progress? Yes, and I am glad to see that.
Even more importantly this Snapshot highlighted the need for more bridging research - both on existing solutions for future deployments, and so that a single bridge selection doesn’t need to be bundled to new deployments going forward (for example, as Martin proposes here.) That this came up as a result of this Snapshot is a win in my eyes.
Coming on the back of this Snapshot, the focus moving forward is on improving the cross-chain deployment process from first principles. Encourage folks to follow and contribute to the new Cross-Chain Bridge Assessment discussion as a first step there.
There’s already good discussion emerging around multi-bridge deployment designs, as well as the merits of individual bridges. My view stands that the best outcome is for new chain dapp deployments to be bridge agnostic, and to embrace modular standards that foster more competition. Im looking forward to more forthcoming research / commentary on this topic.
Disclaimer: Variant is an investor in the UNI tokens. https://variant.fund/disclosures/
We’re excited to see the support behind deploying Uniswap v3 to Binance Smart Chain prior to the expiry of the Business Source License. At Spartan Group, we believe LayerZero’s bridge will be the most secure and decentralized solution for Uniswap, and will be voting to support their solution. We reviewed the different proposals, and believe LayerZero’s approach is the most thoughtful, and appreciate their willingness to engage with the community. Disclosure: we are investors in LayerZero (for the above reasons) and we are also significant holders of UNI tokens.
To be totally unambiguous, we at a16z would have voted 15m tokens toward LayerZero if we were technically able to. And we will be able in future Snapshot votes. So, for the purposes of a "temperature check", please count us this way.
Hey all, cross-posting a few thoughts from Twitter.
1/ great to see the snapshot driving attention/clarity on bridging's role in cross-chain protocol deployments
2/ I'm abstaining from the vote as I don't think the list of options on offer is comprehensive or deeply researched
Hey all, cross-posting a few thoughts from Twitter.
1/ great to see the snapshot driving attention/clarity on bridging's role in cross-chain protocol deployments
2/ I'm abstaining from the vote as I don't think the list of options on offer is comprehensive or deeply researched
3/ zooming out, my view is that its suboptimal for communities to be voting on singular bridge choices, effectively king-making solutions.
protocol design needs to adapt for a multi-chain world, to reap the benefits of competition through standardization, not voting.
4/ closing thought: glad the convo is moving forward , and hope this proposal will kick off more efforts to dig deeper into bridge research and protocol design to enable multiple choices.
There’s been a lot of back and forth in the thread around immutability, decentralization, trusted entities, and degrees of control by cross-chain messaging protocols. We wanted to clarify these discussion points by calling out the two ways Uniswap would integrate a messaging layer and comparing the guarantees of both Wormhole and LayerZero under each scenario.
There’s been a lot of back and forth in the thread around immutability, decentralization, trusted entities, and degrees of control by cross-chain messaging protocols. We wanted to clarify these discussion points by calling out the two ways Uniswap would integrate a messaging layer and comparing the guarantees of both Wormhole and LayerZero under each scenario.
Simply put, the two scenarios are:
LayerZero suggests that integrators can either use their “default” configuration, a low-security option or run infrastructure via a “custom” configuration.
The latter model is proposed as the method by which the application developer (in this case Uniswap) can avoid collusion risk between the default Oracle and Relayer infrastructure operators within LayerZero. Additionally, in this model, Uniswap or its delegates would need to run infrastructure such as a “gasless Oracle” (which has not been released yet), which the LayerZero Relayer would pick up and deliver to the destination. Relayers in LayerZero are always permissioned and are required for liveness and security, thus Uniswap would also have to run Relayer infrastructure. The Relayer source code is currently not open-source, so Uniswap would need to implement a bespoke untested solution or run LayerZero’s proprietary implementation.
However, this may still be problematic. Due to the Proof Library requiring ongoing mitigation with each chain, a non-default config is **insufficient until the issue above is addressed. The LayerZero team can add a new default chain config, register a default proof handler, and exploit an application in a single atomic transaction. The application cannot mitigate this using configuration. Applications can only mitigate via a custom relayer and potentially an “approved chains” list in the application itself. The flagship application on LayerZero, Stargate, itself is semi-immutable and will have a difficult time mitigating this issue, and would need to make a custom Proof Library to implement the approved chains list.
TL;DR — if Uniswap does not want to trust LayerZero’s current default configuration, it needs to run its own infrastructure. Even when doing so, there are underlying issues that necessitate further action from LayerZero’s team to truly make any custom infrastructure setup truly trustless.
We want to clarify that if Uniswap wants to run its own infrastructure with Wormhole, it can achieve the same level of customization that LayerZero touts, as no protocol has a monopoly on deploying bespoke infra. If desired, Uniswap can configure a deployment of Wormhole, which improves upon the security guarantees of LayerZero’s default while also ensuring sovereign security relative to the canonical Wormhole deployment. Wormhole’s contracts are designed so that the Guardian set is customizable on initial deployment (see here: Setup.sol) and can further be rotated via an in-protocol governance mechanism whereby the current guardian set can vote on the next guardian set. Should Uniswap delegates decide to run their own infrastructure, they may run their own oracle nodes by following instructions at Operations.md. In this model, Uniswap oracles produce signed observations (VAAs) which can be submitted permissionlessly on the target chain (BNB), so no relayer infra is needed, and therefore no need to manage gas funds. However, relayers can very easily be made permissioned if desired, which would allow Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
From a security and operational load perspective, however, we could offer Uniswap to layer their signers on top of Wormhole i.e. extend the already robust Guardian set with their additional validators. This option surpasses the level of flexibility and security of LayerZero’s oracle (in this case Wormhole) and Relayer (chosen by Uniswap) mode in which Uniswap benefits from Wormhole’s significantly more robust signer set but is safe as long as the signer set does not collude with the Uniswap chosen signers. We start from the far stronger base of 19 signers and can arbitrarily increase security beyond that with additional Uniswap-affiliated validators. The easiest way to produce these additional signatures is for the Uniswap DAO signers to download and run the existing, open-source, and in-production Wormhole oracle software. After verifying the Wormhole signatures, the Uniswap governance contract can verify these additional signatures from the selected Uniswap DAO signers. Additionally, relayers can very quickly be permissioned, allowing Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
While the proxy contract can point to different implementations, the Wormhole implementation contract is immutable. Thus it is trivial to verify governance messages against a specified implementation. While there are multiple ways to accomplish this, the most straightforward is just including the pinned implementation as an external library in your deployment.
This deployment can be done in a fully permissionless manner without having to trust (or ever interact) with the 19 Guardians that operate the default Wormhole deployment.
The security assumption of LayerZero’s default configuration is that the default Oracle and Relayer are independent. Uniswap would have to trust a 2/2 multisig of these two components. The relayer is unverified, but LayerZero claims that this is not an issue:
“It is common practice to not open source or verify Oracle and Relayer smart contracts. *These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library. […] *****These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.”
This statement contradicts with the LayerZero whitepaper, which claims the following:
“Given two entities that do not collude, if (1) one entity can produce a block header for the block containing tA on chain A, (2) the other entity can independently produce the proof for tA on that block (transaction proof), and (3) the header and transaction proof in fact agree, then the communication protocol can deliver m to the client on chain B with the guarantee that tA is stably committed on chain A.”
The Oracle is responsible for producing the block headers, and the Relayer is responsible for the inclusion proofs — these responsibilities are far beyond on-chain gas quoting.
“LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).”
At this point, it’s unclear if there are other Oracle/Relayer options available to choose from outside of the default. In any case, if the Oracle and Relayer collude, they can forge messages.
Contract upgradeability is a critical discussion point. It’s true that bugs can be introduced in upgrades, but upgrades can (and do) fix existing bugs. Presenting only one side of this coin is misleading at best. If any bugs are discovered in LayerZero’s contracts, patching them would be a significant task. Such a scenario would involve the proof validation code being implemented with a patch, and then all affected user applications would have to change their configurations to the patched implementation.
The 19 Guardians that operate Wormhole’s default deployment are the largest PoS validator companies. The safety assumption is that of an honest superminority (at least 7 of them are honest) or, conversely, that there are no 13 colluding entities. The equivalent assumption under LayerZero’s setup is that the 2 entities do not collude. The contracts are upgradeable via a governance mechanism that requires the approval of 2/3+ of the Guardians. Importantly, the Wormhole cross-chain governance solution has already been tested (see above) and implemented on testnet and is ready for production.
Happy to answer any additional questions.
We know we're late to the party, but we wanted to throw our hat in the ring as well. We understand it's too late to be formally considered in the temp check vote, but we'd love to have Hyperlane (fka Abacus) considered in future votes. We were previously involved in the RFP process, and chosen by several well known delegates alongside Axelar, which is also conspicuously missing from this vote! You can read more about that here: https://gov.uniswap.org/t/rfc-uniswap-universal-governance-module/16829/21
We'll be submitting our case formally through the Cross Chain Bridge Assessment process, in that thread, using the template provided.
Yup 100%! Just want to make sure there is clarity
Over the past few months, LI.FI (a bridge aggregator supporting 13 bridges) has been closely monitoring the development in Uniswap’s Forum related to the BNB Chain Deployment Proposal, its subsequent Snapshot Poll which ended on Jan 31, and the current on-chain vote in favor of implementing Wormhole.
While we applaud the interest shown by key stakeholders of the crypto ecosystem in finding a suitable bridging solution for Uniswap’s Cross-Chain Governance, we strongly recommend that Uniswap not select one bridge provider for its BNB Chain Deployment Proposal. Specifically, we do not believe the BNB Chain Deployment Proposal should move forward before more research can be done, even if this may come as a letdown to many community members – be it bridge builders or other individuals.
Instead, we urge the Uniswap Foundation and the Uniswap community to fully immerse themselves in the Cross-Chain Assessment Process outlined by @devinwalsh. While the sprint to move to BNB Chain before the business license expires is important, we believe finding a long-term solution for cross-chain governance to be far more important than the short-term win of deploying V3 code first. There will be new chains, new versions of Uniswap, but there will never be another chance to expand governance safely and securely on the first try. Uniswap is a market leader in design (AMMs), token structure (airdrops), and overall competency, and LI.FI believes that the model Uniswap chooses for cross-chain governance has a high chance of becoming industry standard. We – as members of the crypto industry – want to see this done the correct way, and from the start.
Bridges, specifically arbitrary messaging bridges (AMBs), are in the nascent stages of development. Short-term, Wormhole, LayerZero, Celer, Axelar and deBridge are certainly viable solutions for cross-chain governance and have received substantial traction in terms of volume at the liquidity layer and development by dApps at the messaging layer.
That being said, we at LI.FI have done the research on AMBs (Navigating Arbitrary Messaging Bridges) and have delved deeply into the pros and cons of eight different AMB solutions. Our conclusion is simple: no single AMB is tested enough to be considered a robust and secure solution that a project of Uniswap’s size can solely rely on at this point. If there was a single, obvious AMB solution that could be trusted by Uniswap, then this forum post would not be necessary. Lest it be forgotten, two major AMBs were exploited in the past twelve months (Nomad and Wormhole), while LayerZero has also come under fire recently for its security model (Prestwich, L2Beat). We do not say this as condemnation, rather, we point this out to highlight just how difficult it is to build secure AMBs and the subsequent risks a dApp is exposed to by choosing a single bridging solution. In addition to this sentiment, we believe AMBs like Axelar, Synapse, Hyperlane, Multichain, Connext Amarok, and Hop deserve to be considered by Uniswap and the deadline of two and half weeks is too short for them to be formally introduced, debated, and voted upon again.
To summarize, LI.FI stands staunchly behind the concerns previously raised by @Kydo, @AlexSmirnov, and @modong. LI.FI believes that a multi-bridge, agnostic approach is best suited for Uniswap cross-chain governance because of the following reasons:
So, where do we go from here?
More research is in order, which we believe should be two-pronged.
1. Cross-Chain Bridge Assessment Framework
We would like to add our own feedback to Devin’s framework and add an additional step to the process.
The MMA solution or any other multi-bridge solution is built on the idea of Uniswap choosing multiple bridges as “adapters.” The first thing to do, therefore, is to determine which bridges meet Uniswap standards, as outlined by @devinwalsh.
We believe that Uniswap should first build a unique framework to both quantitatively and qualitatively measure and allow for the ranking of different bridge solutions by the engineering team. This would decrease the workload of the engineering team by letting them focus on stress-testing bridge solutions without having to create the parameters of such a test themselves.
As one of the largest players in DeFi, Uniswap has the chance to create the de facto bridge assessment criterion.
By our estimation, there are four bridge framework solutions currently in the ether.
Uniswap has the chance to build upon, combine, and quantify the works of four major research pieces without having to start from scratch.
With that in mind, we recommend that Devin’s initial Cross Chain Bridge Assessment make room for four researchers, who can help build this framework to assist the engineering team, who can then test out different bridging solutions based on the criteria mentioned in the framework and select which bridges make the cut to become a part of the multi-bridge solution.
The researchers will then explain the decision of the team through easy to digest articles, which can be used by other builders to assess bridges for their own dApps and by users to expand their knowledge of bridges and make more informed decisions when it comes to choosing a bridging solution for their needs. To this end, collaborations with other public good infrastructure projects like L2BEAT, Ethereum.org, among others, should also be considered to spread awareness and educate the public about bridges.
As Devin laid out, these individuals should be available for 10-15 hours per week over the next few weeks to participate in the assessment process, and to write up their findings in a report to share with the community.
To this end, we recommend Peter Robinson, Arjun Chand, Ermyas Abebe, and Bartek Kiepuszewski (though we believe Uniswap should have the final call here).
We believe the current timeframe is aggressive but doable. However, if the list of bridges were to expand, we would recommend pushing back the March 27th date.
2. Consideration of Making the Universal Governance Model an EIP
Uniswap pushing for a cross-chain governance EIP would be net positive for the industry, in our opinion, specifically in the context of a multi-bridge solution. Such an EIP would give dApps a shared template for creating safe, secure governance modules, while also giving flexibility for dApps to choose different bridging solutions based on their security, time, and cost preferences.
To that end, we believe that Uniswap should create and propose a new cross-chain EIP based on the design outlined by Mo Dong from Celer and Alex from deBridge (with, of course, any tweaks recommended by the engineering and research team).
Additionally, there are two EIPs and one forum post that Uniswap should consider learning from and building upon in addition to the framework above.
In our estimation, none of these solutions have captured enough mindshare to become industry standard. However, they have all pushed the envelope in what can be done in standardizing messaging, and Uniswap could learn much from it.
We recommend that Uniswap employ the same four-engineering team to standardize the MMA solution as an EVM-compatible EIP.
Given Uniswap’s position and influence in the ecosystem, it has the power to push an EIP that can potentially become the de-facto solution for any project indulging in cross-chain governance.
Conclusion
A multi-bridge, agnostic solution that the community invests resources into is a win-win-win for all the parties involved (Uniswap, bridging solutions, and the dApps that will implement this solution for cross-chain governance in the future).
As Devin said, the developments as a result of the proposed deployment on BNB Chain are net-positive for the ecosystem. Open discussions about bridge designs and frameworks for assessing security risks associated with them are exactly what we need to fast-forward the maturity of the bridging solutions and enable the development of secure bridges.
We look forward to the feedback of the UF and the community on our proposal.
Hey All. Sergey from the Axelar Network here.
It’s great to see Uniswap expanding! We note that choosing a cross-chain provider is a highly technical and delicate question that requires careful planning, resource allocation, and coordination for a successful deployment. We support pursuing the Cross-Chain Assessment Process outlined by @devinwalsh to better benchmark the pros and cons of each proposal and will post answers on that thread.
The Axelar network is built from the ground up using Cosmos SDK and already connects over 30 chains including Ethereum, Cosmos chain, Arbitrum, Polygon, Avalanche, and others (see https://axelarscan.io), and new chains are added regularly. The Axelar network has been running on mainnet since Jan 2022 and has processed over $1.75 billion of volume in >350k transactions. Axelar’s ecosystem has thousands of builders using our decentralized and permissionless infrastructure, creating hundreds of unique cross-chain applications. Multiple connectivity paths can be connected to the Axelar network, leveraging its many-to-many transport and routing properties, improving the security of individual connections. Applications built on top can benefit from these improvements without additional changes.
We propose to instantiate interoperability for Uniswap by leveraging the Axelar decentralized network, powered by Proof of Stake consensus and many safety features, and augment it with an additional Uniswap-specific validator set. The Uniswap-specific validator set may be elected via UNI governance, and be instantiated based on Proof-of-Stake, Proof-of-Authority, or any other validator selection rule deemed needed. A custom policy can be instantiated to authorize messages of different value/importance. See our recent blog post for how to instantiate deployments based on different validation logic using Axelar. We’ll post full answers to the questions asked in Cross-Chain Assessment Process shortly and look forward to continuing the discussion with the Uniswap community.
On Monday, I posted a few thoughts which amounted to my decision to abstain from a voting on which bridge Uniswap should use in its deployment of v3 to BNB.
I want to take the opportunity to expand and point to areas for development where I’m excited to see progress. I also wanted to more explicitly commend Devin and UF for their work in stewarding the process here and on other issues, which in sum, has resulted in a lot more momentum in community governance.
On Monday, I posted a few thoughts which amounted to my decision to abstain from a voting on which bridge Uniswap should use in its deployment of v3 to BNB.
I want to take the opportunity to expand and point to areas for development where I’m excited to see progress. I also wanted to more explicitly commend Devin and UF for their work in stewarding the process here and on other issues, which in sum, has resulted in a lot more momentum in community governance.
Process-wise, the Uniswap Foundation holding a temperature check on which bridge to use in the BSC deployment served both to generally highlight the issue of bridge selection in cross-chain deployment, and advance the decision in this particular instance. Action begets action, and continued forward movement is critical in decentralized governance.
The discussion around the merits of each bridge being considered here was absolutely better than leaving that discussion unconsidered at all. Was it comprehensive? No. That is why I abstained from voting. Was it forward progress? Yes, and I am glad to see that.
Even more importantly this Snapshot highlighted the need for more bridging research - both on existing solutions for future deployments, and so that a single bridge selection doesn’t need to be bundled to new deployments going forward (for example, as Martin proposes here.) That this came up as a result of this Snapshot is a win in my eyes.
Coming on the back of this Snapshot, the focus moving forward is on improving the cross-chain deployment process from first principles. Encourage folks to follow and contribute to the new Cross-Chain Bridge Assessment discussion as a first step there.
There’s already good discussion emerging around multi-bridge deployment designs, as well as the merits of individual bridges. My view stands that the best outcome is for new chain dapp deployments to be bridge agnostic, and to embrace modular standards that foster more competition. Im looking forward to more forthcoming research / commentary on this topic.
Disclaimer: Variant is an investor in the UNI tokens. https://variant.fund/disclosures/
We’re excited to see the support behind deploying Uniswap v3 to Binance Smart Chain prior to the expiry of the Business Source License. At Spartan Group, we believe LayerZero’s bridge will be the most secure and decentralized solution for Uniswap, and will be voting to support their solution. We reviewed the different proposals, and believe LayerZero’s approach is the most thoughtful, and appreciate their willingness to engage with the community. Disclosure: we are investors in LayerZero (for the above reasons) and we are also significant holders of UNI tokens.
To be totally unambiguous, we at a16z would have voted 15m tokens toward LayerZero if we were technically able to. And we will be able in future Snapshot votes. So, for the purposes of a "temperature check", please count us this way.
Hey all, cross-posting a few thoughts from Twitter.
1/ great to see the snapshot driving attention/clarity on bridging's role in cross-chain protocol deployments
2/ I'm abstaining from the vote as I don't think the list of options on offer is comprehensive or deeply researched
Hey all, cross-posting a few thoughts from Twitter.
1/ great to see the snapshot driving attention/clarity on bridging's role in cross-chain protocol deployments
2/ I'm abstaining from the vote as I don't think the list of options on offer is comprehensive or deeply researched
3/ zooming out, my view is that its suboptimal for communities to be voting on singular bridge choices, effectively king-making solutions.
protocol design needs to adapt for a multi-chain world, to reap the benefits of competition through standardization, not voting.
4/ closing thought: glad the convo is moving forward , and hope this proposal will kick off more efforts to dig deeper into bridge research and protocol design to enable multiple choices.
There’s been a lot of back and forth in the thread around immutability, decentralization, trusted entities, and degrees of control by cross-chain messaging protocols. We wanted to clarify these discussion points by calling out the two ways Uniswap would integrate a messaging layer and comparing the guarantees of both Wormhole and LayerZero under each scenario.
There’s been a lot of back and forth in the thread around immutability, decentralization, trusted entities, and degrees of control by cross-chain messaging protocols. We wanted to clarify these discussion points by calling out the two ways Uniswap would integrate a messaging layer and comparing the guarantees of both Wormhole and LayerZero under each scenario.
Simply put, the two scenarios are:
LayerZero suggests that integrators can either use their “default” configuration, a low-security option or run infrastructure via a “custom” configuration.
The latter model is proposed as the method by which the application developer (in this case Uniswap) can avoid collusion risk between the default Oracle and Relayer infrastructure operators within LayerZero. Additionally, in this model, Uniswap or its delegates would need to run infrastructure such as a “gasless Oracle” (which has not been released yet), which the LayerZero Relayer would pick up and deliver to the destination. Relayers in LayerZero are always permissioned and are required for liveness and security, thus Uniswap would also have to run Relayer infrastructure. The Relayer source code is currently not open-source, so Uniswap would need to implement a bespoke untested solution or run LayerZero’s proprietary implementation.
However, this may still be problematic. Due to the Proof Library requiring ongoing mitigation with each chain, a non-default config is **insufficient until the issue above is addressed. The LayerZero team can add a new default chain config, register a default proof handler, and exploit an application in a single atomic transaction. The application cannot mitigate this using configuration. Applications can only mitigate via a custom relayer and potentially an “approved chains” list in the application itself. The flagship application on LayerZero, Stargate, itself is semi-immutable and will have a difficult time mitigating this issue, and would need to make a custom Proof Library to implement the approved chains list.
TL;DR — if Uniswap does not want to trust LayerZero’s current default configuration, it needs to run its own infrastructure. Even when doing so, there are underlying issues that necessitate further action from LayerZero’s team to truly make any custom infrastructure setup truly trustless.
We want to clarify that if Uniswap wants to run its own infrastructure with Wormhole, it can achieve the same level of customization that LayerZero touts, as no protocol has a monopoly on deploying bespoke infra. If desired, Uniswap can configure a deployment of Wormhole, which improves upon the security guarantees of LayerZero’s default while also ensuring sovereign security relative to the canonical Wormhole deployment. Wormhole’s contracts are designed so that the Guardian set is customizable on initial deployment (see here: Setup.sol) and can further be rotated via an in-protocol governance mechanism whereby the current guardian set can vote on the next guardian set. Should Uniswap delegates decide to run their own infrastructure, they may run their own oracle nodes by following instructions at Operations.md. In this model, Uniswap oracles produce signed observations (VAAs) which can be submitted permissionlessly on the target chain (BNB), so no relayer infra is needed, and therefore no need to manage gas funds. However, relayers can very easily be made permissioned if desired, which would allow Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
From a security and operational load perspective, however, we could offer Uniswap to layer their signers on top of Wormhole i.e. extend the already robust Guardian set with their additional validators. This option surpasses the level of flexibility and security of LayerZero’s oracle (in this case Wormhole) and Relayer (chosen by Uniswap) mode in which Uniswap benefits from Wormhole’s significantly more robust signer set but is safe as long as the signer set does not collude with the Uniswap chosen signers. We start from the far stronger base of 19 signers and can arbitrarily increase security beyond that with additional Uniswap-affiliated validators. The easiest way to produce these additional signatures is for the Uniswap DAO signers to download and run the existing, open-source, and in-production Wormhole oracle software. After verifying the Wormhole signatures, the Uniswap governance contract can verify these additional signatures from the selected Uniswap DAO signers. Additionally, relayers can very quickly be permissioned, allowing Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
While the proxy contract can point to different implementations, the Wormhole implementation contract is immutable. Thus it is trivial to verify governance messages against a specified implementation. While there are multiple ways to accomplish this, the most straightforward is just including the pinned implementation as an external library in your deployment.
This deployment can be done in a fully permissionless manner without having to trust (or ever interact) with the 19 Guardians that operate the default Wormhole deployment.
The security assumption of LayerZero’s default configuration is that the default Oracle and Relayer are independent. Uniswap would have to trust a 2/2 multisig of these two components. The relayer is unverified, but LayerZero claims that this is not an issue:
“It is common practice to not open source or verify Oracle and Relayer smart contracts. *These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library. […] *****These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.”
This statement contradicts with the LayerZero whitepaper, which claims the following:
“Given two entities that do not collude, if (1) one entity can produce a block header for the block containing tA on chain A, (2) the other entity can independently produce the proof for tA on that block (transaction proof), and (3) the header and transaction proof in fact agree, then the communication protocol can deliver m to the client on chain B with the guarantee that tA is stably committed on chain A.”
The Oracle is responsible for producing the block headers, and the Relayer is responsible for the inclusion proofs — these responsibilities are far beyond on-chain gas quoting.
“LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).”
At this point, it’s unclear if there are other Oracle/Relayer options available to choose from outside of the default. In any case, if the Oracle and Relayer collude, they can forge messages.
Contract upgradeability is a critical discussion point. It’s true that bugs can be introduced in upgrades, but upgrades can (and do) fix existing bugs. Presenting only one side of this coin is misleading at best. If any bugs are discovered in LayerZero’s contracts, patching them would be a significant task. Such a scenario would involve the proof validation code being implemented with a patch, and then all affected user applications would have to change their configurations to the patched implementation.
The 19 Guardians that operate Wormhole’s default deployment are the largest PoS validator companies. The safety assumption is that of an honest superminority (at least 7 of them are honest) or, conversely, that there are no 13 colluding entities. The equivalent assumption under LayerZero’s setup is that the 2 entities do not collude. The contracts are upgradeable via a governance mechanism that requires the approval of 2/3+ of the Guardians. Importantly, the Wormhole cross-chain governance solution has already been tested (see above) and implemented on testnet and is ready for production.
Happy to answer any additional questions.
We know we're late to the party, but we wanted to throw our hat in the ring as well. We understand it's too late to be formally considered in the temp check vote, but we'd love to have Hyperlane (fka Abacus) considered in future votes. We were previously involved in the RFP process, and chosen by several well known delegates alongside Axelar, which is also conspicuously missing from this vote! You can read more about that here: https://gov.uniswap.org/t/rfc-uniswap-universal-governance-module/16829/21
We'll be submitting our case formally through the Cross Chain Bridge Assessment process, in that thread, using the template provided.
Yup 100%! Just want to make sure there is clarity
Did anyone consider Axelar?
With Osmosis opting for it over Wormhole in their search for a canonical Ethereum bridge, which some might argue was more thorough, I think it's worth considering.
I would say that's one of the least objective posts of all time. I responded to it here albeit in not a very formal tone and I'd like to state clearly that it's both wrong, misleading, and has absolutely 0 impact on the proposed Uniswap architecture because as discussed in the proposal Uniswap would not be using the defaults and would be selecting their own oracle, relayer, and VL.
I believe it's too early to pick any solution. Because all these solutions are early, Uniswap is way too important for this ecosystem's health, and we still haven't fully understood each provider's implications and loopholes.
Would love to provide some insightful links, but don't have the permissions.
Hi raz from LayerZero.
So I want to first say we’ve never spoken to GFX Labs (despite reaching out) and although we now have time scheduled tomorrow (Monday), this analysis was written without a single question sent to us. I’ve gone through and done a line-by-line response to everything above but wanted to tl;dr some of the obvious mistakes in the analysis in case they get lost below in the broader post.
Hi raz from LayerZero.
So I want to first say we’ve never spoken to GFX Labs (despite reaching out) and although we now have time scheduled tomorrow (Monday), this analysis was written without a single question sent to us. I’ve gone through and done a line-by-line response to everything above but wanted to tl;dr some of the obvious mistakes in the analysis in case they get lost below in the broader post.
Firstly, GFX Labs missed the _getAppConfig() function which is the very first line of validateTransactionProof() with comments “Retrieve UA’s configuration using the _dstAddress from arguments.”
Taking a look at this function, you can clearly see that the first thing that it does is retrieve the User Application’s config and the default config.
Then it goes through each config item and if and only if the configurations are not set, the contract sets it to the default config item.
The crux of the GFX Labs argument seems to be centered around the perceived ability for the LayerZero ULN owner to be able to modify application parameters, however this is clearly not possible and enforceable in the immutable base layer of the code.
Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we're supportive of the Foundation's move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.
GFX Labs has cast our vote for Wormhole in the current snapshot, and while we've made our concerns about Celer clear in the forum thread, we haven't done the same for Layerzero.
Our primary resources for researching Layerzero
For context, Layerzero messages are sent from the local Endpoint. Oracles are responsible for moving block headers from the source to the destination. Upon delivery, Relayers can deliver the transaction's proof to the destination Endpoint. This model, in its current implementation, is a 2-of-2 msig.
This seems clearly misleading as the two parties (oracle and relayer) are abstracted accounts with arbitrary implementation e.g. a fully decentralized network, not to mention the current proposal which I had assumed GFX Labs had reviewed extensively prior to this is for a new architecture with a number of major Uniswap delegates participating within the validation set.
Messages are sent to a verifying library. The verifying library (VL) manages oracles and Relayers on behalf of the application. The Ultra Light Node (ULN) is a VL. The Endpoint manages the relationship between the user application (UA) and the VL (the ULN, in practice). The UA selects a VL via the Endpoint. The UA may also configure that VL directly (e.g. by selecting a Relayer in the VL). Relayers submit proofs to the VL (the ULN, in practice), and the VL chooses how to validate these. In the ULN, the owner chooses proof validation libraries and may choose any contract.
The owner of the ULN contract cannot choose proof libraries on behalf of the user application. The owner can only add new proof libraries (i.e. append-only registry) of which the user application can select from.
Applications are intended to choose their own VL & Relayer since they can configure which library to use in the Endpoint contract. The Endpoint owner sets a default VL. However, the ULN is the only verifying library that exists, so all apps must use it.
The ULN can hold multiple validation libraries within itself for applications to choose from (ex. A zk-Validation Library could be added to the ULN V2 as a different method for verifying messages). This is an explicit design decision; LayerZero’s architecture supports the evolution of best cryptographic security practices. These libraries and the ULN itself are immutable and only by selection of the user application.
Most other bridges and messaging protocols offer blanket validation techniques and only upgradeable smart contracts. Many notable hacks have occurred due to a buggy upgrade forced upon applications built on top of a bridge’s infrastructure, including two identical instances from Wormhole resulting in a $10m bug bounty paid and then later reducing their bug bounty from $10m to only $2.5m.
To be clear, both of these issues are completely separate from the $325m hack Wormhole suffered.
We believe critical infrastructure should be immutable, open source, and always owned by user applications.
It is common practice to not open source or verify Oracle and Relayer smart contracts. These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library. In a competitive marketplace of Oracles and Relayers, unique pricing mechanisms are often the proprietary edge for providers. These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.
The governance section of our documentation is in reference to the upcoming open source governance module we proposed in this forum thread (see above).
The Endpoint Contracts are for setting default configurations for developers to be able deploy and test easily. It is recommended that applications desiring more control over their security opt to set their own configuration settings. Default configuration cannot override user application configured settings; this is an explicit design decision and a feature of a true protocol.
The UltraLightNodeV2 settings are a combination of default configurations and one-time setters for adding new chains and proof libraries. The multisig owner cannot change any existing configurations set by the user or modify any existing validation libraries.
onlyOwner functions on the UltraLightNodeV2 contract:
The ULN's owner can set the oracle, relay, proof systems, and other security parameters. It appears that the owner can entirely bypass the oracle/relay system in their current implementation.
This statement is both entirely verifiably false and addressed in the opening part of the post.
Through this process, we arrived at the conclusion that Layerzero is not ready to be integrated with Uniswap. However, as developers ourselves, do we realize that the development process is fluid and that research is ongoing. Our vote reflects the current state of development and available information.
I hope the line by line was helpful. I know we haven’t gotten to speak yet but looking forward to speaking to GFX Labs tomorrow and addressing any outstanding concerns and walking through the proposed security configuration in detail.
-raz
Adding my own two cents here, for context we provide security audits to both LayerZero and Wormhole.
The security models are quite fundamentally different, but both bridges - as far as we can tell - care very deeply about security. In my opinion, the primary question voters should evaluate is which security model/assumptions they think is more suitable for Uniswap, as opposed to the implementation risks which are relatively minimal.
We’ve recently had open discussions with many of the delegate groups around the security features and fundamental architecture of LayerZero and its fitness for secure and scalable omnichain governance for the Uniswap protocol. The following are key topics and outcomes from the discussion shared publicly for the community’s awareness:
—LayerZero’s omnichain governance executor (complete open source code here) is designed to enable Uniswap governance to add, remove, or swap validation layer components directly from on-chain votes via GovernorBravo.
We appreciate deBridge being included as one of the solutions proposed in the temperature check, but we’d also like to support points raised by @Kydo and @modong and express concern that the current temperature check process seems rushed in the sense there are options proposed by participants of the discussion that have not been explored. Moreover, we agree with Kydo and Mo that Uniswap should not lock in one vendor when the possibility of choosing multiple exists with a similar level of complexity to the proposed single-bridge solution.
We appreciate deBridge being included as one of the solutions proposed in the temperature check, but we’d also like to support points raised by @Kydo and @modong and express concern that the current temperature check process seems rushed in the sense there are options proposed by participants of the discussion that have not been explored. Moreover, we agree with Kydo and Mo that Uniswap should not lock in one vendor when the possibility of choosing multiple exists with a similar level of complexity to the proposed single-bridge solution.
Uniswap must consider several key objectives — to achieve a decentralized and resilient solution with no one point of failure, and to enact a solution that is consistent with the stated goals and objectives of the Uniswap community. In order to achieve this, Uniswap must avoid reliance on any one bridge/interoperability protocol.
Thus, we present a bridge-agnostic approach for Uniswap Cross-chain Governance which suggests leveraging multiple bridges for passing Governance Actions to secondary chains, and executing such Actions only whenever each was delivered by at least a given number of trusted bridges.
At its core, we propose using a set of permissionless smart contracts on both chains (the master chain — Ethereum in this case — where Governance resides, and any secondary chain — BNB Chain in this case, though there can be more) which together form a permissionless multibridge transport protocol on top of existing battle-tested governance model for secured delivering and executing cross-chain governance actions.
The first layer of this approach is a permissionless Uniswap Multibridge Sender contract, which is directly controlled by the Governor contract. This contract is responsible for keeping the whitelist of trusted bridges Governance decided to use for message passing, and their corresponding permissionless Bridge Adapter contracts. Whenever there is a necessity to execute a Governance Action in a secondary chain, a Proposal to call a Uniswap Multibridge Sender contract is published using the existing workflow.
When a Uniswap Multibridge Sender Contract receives a Governance Action from a Governor contract, it triggers permissionless Bridge Adapter contracts for every corresponding trusted bridge. These Bridge Adapter contracts are needed to unify interfaces and behavior that are typically different across cross-chain bridges’ contracts. When the Bridge Adapter is triggered, it calls its bridge’s Gate/Relayer contract, passing the Governance Action as a message and specifying the address of the corresponding trusted permissionless adapter on the other chain as a receiver.
Every time the message is successfully broadcasted to the destination chain by any of the trusted bridges, it actually lands on the corresponding destination Bridge Adapter (as specified upon sending). This message is here transformed into a unified structure with technical metadata taken from the bridge’s gate/relayer. This metadata may include the address that actually initiated a cross-chain call.
The unified structure is then passed to the Uniswap Multibridge Receiver Contract, which authenticates the message by checking that it was sent by and received by trusted Bridge Adapters. Then, the actual Governance Action is extracted from the message and is passed to the Delegated Governor contract along with a bridge ID it was sent through for a staging phase.
A Uniswap Delegated Governor Contract accepts Governance Actions from the Uniswap Multibridge Receiver Contract it trusts, grouping them by their hashes and by the bridge IDs they were broadcasted through. Whenever the number of messages coming from different trusted bridges and shipping the same proposal reach the consensus (for example, ⅔ of delivered messages), this proposal is allowed to be executed normally, as it happens within the existing governance framework used by Uniswap.
The beauty of this approach lies not only in the fact that it is completely bridge-agnostic and thus won’t get stuck due to a third-party failure, but also in fact this approach and any of its underlying components may be governed the same way Uniswap is governed: whenever there is a necessity to disable a specific bridge, or add another one, or change the expected threshold of delivered messages — a Governance votes for Proposals on Ethereum which emit cross-chain Governance Actions, which are then broadcasted and executed as prescribed.
In conclusion, this bridge-agnostic approach will better prevent message forgery while increasing the durability and deliverability of messages, creating a more secure solution that is consistent and compatible with the governance logic of Uniswap. Crucially, this design allows for flexibility and fault-tolerance in the event any participating bridge fails without recovery.
A lot of good business shapes for this approach are described in @modong's comment
Finally, this generic framework is more scalable than the single-bridge framework — it can be replicated for additional chains, enabling Uniswap to integrate new chains efficiently and safely while having full control over bridge-selection (useful in the scenario the chosen bridge does not support a new chain).
If deBridge is chosen for the temperature check and further governance voting, the Uniswap-deBridge integration will be built in the context of this bridge-agnostic framework and thus, will enable other bridges to participate.
Did anyone consider Axelar?
With Osmosis opting for it over Wormhole in their search for a canonical Ethereum bridge, which some might argue was more thorough, I think it's worth considering.
I would say that's one of the least objective posts of all time. I responded to it here albeit in not a very formal tone and I'd like to state clearly that it's both wrong, misleading, and has absolutely 0 impact on the proposed Uniswap architecture because as discussed in the proposal Uniswap would not be using the defaults and would be selecting their own oracle, relayer, and VL.
I believe it's too early to pick any solution. Because all these solutions are early, Uniswap is way too important for this ecosystem's health, and we still haven't fully understood each provider's implications and loopholes.
Would love to provide some insightful links, but don't have the permissions.
Hi raz from LayerZero.
So I want to first say we’ve never spoken to GFX Labs (despite reaching out) and although we now have time scheduled tomorrow (Monday), this analysis was written without a single question sent to us. I’ve gone through and done a line-by-line response to everything above but wanted to tl;dr some of the obvious mistakes in the analysis in case they get lost below in the broader post.
Hi raz from LayerZero.
So I want to first say we’ve never spoken to GFX Labs (despite reaching out) and although we now have time scheduled tomorrow (Monday), this analysis was written without a single question sent to us. I’ve gone through and done a line-by-line response to everything above but wanted to tl;dr some of the obvious mistakes in the analysis in case they get lost below in the broader post.
Firstly, GFX Labs missed the _getAppConfig() function which is the very first line of validateTransactionProof() with comments “Retrieve UA’s configuration using the _dstAddress from arguments.”
Taking a look at this function, you can clearly see that the first thing that it does is retrieve the User Application’s config and the default config.
Then it goes through each config item and if and only if the configurations are not set, the contract sets it to the default config item.
The crux of the GFX Labs argument seems to be centered around the perceived ability for the LayerZero ULN owner to be able to modify application parameters, however this is clearly not possible and enforceable in the immutable base layer of the code.
Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we're supportive of the Foundation's move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.
GFX Labs has cast our vote for Wormhole in the current snapshot, and while we've made our concerns about Celer clear in the forum thread, we haven't done the same for Layerzero.
Our primary resources for researching Layerzero
For context, Layerzero messages are sent from the local Endpoint. Oracles are responsible for moving block headers from the source to the destination. Upon delivery, Relayers can deliver the transaction's proof to the destination Endpoint. This model, in its current implementation, is a 2-of-2 msig.
This seems clearly misleading as the two parties (oracle and relayer) are abstracted accounts with arbitrary implementation e.g. a fully decentralized network, not to mention the current proposal which I had assumed GFX Labs had reviewed extensively prior to this is for a new architecture with a number of major Uniswap delegates participating within the validation set.
Messages are sent to a verifying library. The verifying library (VL) manages oracles and Relayers on behalf of the application. The Ultra Light Node (ULN) is a VL. The Endpoint manages the relationship between the user application (UA) and the VL (the ULN, in practice). The UA selects a VL via the Endpoint. The UA may also configure that VL directly (e.g. by selecting a Relayer in the VL). Relayers submit proofs to the VL (the ULN, in practice), and the VL chooses how to validate these. In the ULN, the owner chooses proof validation libraries and may choose any contract.
The owner of the ULN contract cannot choose proof libraries on behalf of the user application. The owner can only add new proof libraries (i.e. append-only registry) of which the user application can select from.
Applications are intended to choose their own VL & Relayer since they can configure which library to use in the Endpoint contract. The Endpoint owner sets a default VL. However, the ULN is the only verifying library that exists, so all apps must use it.
The ULN can hold multiple validation libraries within itself for applications to choose from (ex. A zk-Validation Library could be added to the ULN V2 as a different method for verifying messages). This is an explicit design decision; LayerZero’s architecture supports the evolution of best cryptographic security practices. These libraries and the ULN itself are immutable and only by selection of the user application.
Most other bridges and messaging protocols offer blanket validation techniques and only upgradeable smart contracts. Many notable hacks have occurred due to a buggy upgrade forced upon applications built on top of a bridge’s infrastructure, including two identical instances from Wormhole resulting in a $10m bug bounty paid and then later reducing their bug bounty from $10m to only $2.5m.
To be clear, both of these issues are completely separate from the $325m hack Wormhole suffered.
We believe critical infrastructure should be immutable, open source, and always owned by user applications.
It is common practice to not open source or verify Oracle and Relayer smart contracts. These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library. In a competitive marketplace of Oracles and Relayers, unique pricing mechanisms are often the proprietary edge for providers. These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.
The governance section of our documentation is in reference to the upcoming open source governance module we proposed in this forum thread (see above).
The Endpoint Contracts are for setting default configurations for developers to be able deploy and test easily. It is recommended that applications desiring more control over their security opt to set their own configuration settings. Default configuration cannot override user application configured settings; this is an explicit design decision and a feature of a true protocol.
The UltraLightNodeV2 settings are a combination of default configurations and one-time setters for adding new chains and proof libraries. The multisig owner cannot change any existing configurations set by the user or modify any existing validation libraries.
onlyOwner functions on the UltraLightNodeV2 contract:
The ULN's owner can set the oracle, relay, proof systems, and other security parameters. It appears that the owner can entirely bypass the oracle/relay system in their current implementation.
This statement is both entirely verifiably false and addressed in the opening part of the post.
Through this process, we arrived at the conclusion that Layerzero is not ready to be integrated with Uniswap. However, as developers ourselves, do we realize that the development process is fluid and that research is ongoing. Our vote reflects the current state of development and available information.
I hope the line by line was helpful. I know we haven’t gotten to speak yet but looking forward to speaking to GFX Labs tomorrow and addressing any outstanding concerns and walking through the proposed security configuration in detail.
-raz
Adding my own two cents here, for context we provide security audits to both LayerZero and Wormhole.
The security models are quite fundamentally different, but both bridges - as far as we can tell - care very deeply about security. In my opinion, the primary question voters should evaluate is which security model/assumptions they think is more suitable for Uniswap, as opposed to the implementation risks which are relatively minimal.
We’ve recently had open discussions with many of the delegate groups around the security features and fundamental architecture of LayerZero and its fitness for secure and scalable omnichain governance for the Uniswap protocol. The following are key topics and outcomes from the discussion shared publicly for the community’s awareness:
—LayerZero’s omnichain governance executor (complete open source code here) is designed to enable Uniswap governance to add, remove, or swap validation layer components directly from on-chain votes via GovernorBravo.
We appreciate deBridge being included as one of the solutions proposed in the temperature check, but we’d also like to support points raised by @Kydo and @modong and express concern that the current temperature check process seems rushed in the sense there are options proposed by participants of the discussion that have not been explored. Moreover, we agree with Kydo and Mo that Uniswap should not lock in one vendor when the possibility of choosing multiple exists with a similar level of complexity to the proposed single-bridge solution.
We appreciate deBridge being included as one of the solutions proposed in the temperature check, but we’d also like to support points raised by @Kydo and @modong and express concern that the current temperature check process seems rushed in the sense there are options proposed by participants of the discussion that have not been explored. Moreover, we agree with Kydo and Mo that Uniswap should not lock in one vendor when the possibility of choosing multiple exists with a similar level of complexity to the proposed single-bridge solution.
Uniswap must consider several key objectives — to achieve a decentralized and resilient solution with no one point of failure, and to enact a solution that is consistent with the stated goals and objectives of the Uniswap community. In order to achieve this, Uniswap must avoid reliance on any one bridge/interoperability protocol.
Thus, we present a bridge-agnostic approach for Uniswap Cross-chain Governance which suggests leveraging multiple bridges for passing Governance Actions to secondary chains, and executing such Actions only whenever each was delivered by at least a given number of trusted bridges.
At its core, we propose using a set of permissionless smart contracts on both chains (the master chain — Ethereum in this case — where Governance resides, and any secondary chain — BNB Chain in this case, though there can be more) which together form a permissionless multibridge transport protocol on top of existing battle-tested governance model for secured delivering and executing cross-chain governance actions.
The first layer of this approach is a permissionless Uniswap Multibridge Sender contract, which is directly controlled by the Governor contract. This contract is responsible for keeping the whitelist of trusted bridges Governance decided to use for message passing, and their corresponding permissionless Bridge Adapter contracts. Whenever there is a necessity to execute a Governance Action in a secondary chain, a Proposal to call a Uniswap Multibridge Sender contract is published using the existing workflow.
When a Uniswap Multibridge Sender Contract receives a Governance Action from a Governor contract, it triggers permissionless Bridge Adapter contracts for every corresponding trusted bridge. These Bridge Adapter contracts are needed to unify interfaces and behavior that are typically different across cross-chain bridges’ contracts. When the Bridge Adapter is triggered, it calls its bridge’s Gate/Relayer contract, passing the Governance Action as a message and specifying the address of the corresponding trusted permissionless adapter on the other chain as a receiver.
Every time the message is successfully broadcasted to the destination chain by any of the trusted bridges, it actually lands on the corresponding destination Bridge Adapter (as specified upon sending). This message is here transformed into a unified structure with technical metadata taken from the bridge’s gate/relayer. This metadata may include the address that actually initiated a cross-chain call.
The unified structure is then passed to the Uniswap Multibridge Receiver Contract, which authenticates the message by checking that it was sent by and received by trusted Bridge Adapters. Then, the actual Governance Action is extracted from the message and is passed to the Delegated Governor contract along with a bridge ID it was sent through for a staging phase.
A Uniswap Delegated Governor Contract accepts Governance Actions from the Uniswap Multibridge Receiver Contract it trusts, grouping them by their hashes and by the bridge IDs they were broadcasted through. Whenever the number of messages coming from different trusted bridges and shipping the same proposal reach the consensus (for example, ⅔ of delivered messages), this proposal is allowed to be executed normally, as it happens within the existing governance framework used by Uniswap.
The beauty of this approach lies not only in the fact that it is completely bridge-agnostic and thus won’t get stuck due to a third-party failure, but also in fact this approach and any of its underlying components may be governed the same way Uniswap is governed: whenever there is a necessity to disable a specific bridge, or add another one, or change the expected threshold of delivered messages — a Governance votes for Proposals on Ethereum which emit cross-chain Governance Actions, which are then broadcasted and executed as prescribed.
In conclusion, this bridge-agnostic approach will better prevent message forgery while increasing the durability and deliverability of messages, creating a more secure solution that is consistent and compatible with the governance logic of Uniswap. Crucially, this design allows for flexibility and fault-tolerance in the event any participating bridge fails without recovery.
A lot of good business shapes for this approach are described in @modong's comment
Finally, this generic framework is more scalable than the single-bridge framework — it can be replicated for additional chains, enabling Uniswap to integrate new chains efficiently and safely while having full control over bridge-selection (useful in the scenario the chosen bridge does not support a new chain).
If deBridge is chosen for the temperature check and further governance voting, the Uniswap-deBridge integration will be built in the context of this bridge-agnostic framework and thus, will enable other bridges to participate.
We’ve recently had open discussions with many of the delegate groups around the security features and fundamental architecture of LayerZero and its fitness for secure and scalable omnichain governance for the Uniswap protocol. The following are key topics and outcomes from the discussion shared publicly for the community’s awareness:
—LayerZero’s omnichain governance executor (complete open source code here) is designed to enable Uniswap governance to add, remove, or swap validation layer components directly from on-chain votes via GovernorBravo.
What this means: Security of the protocol’s cross-chain governance can scale with the protocol over time. Governance always maintains the ability to propose and vote to change parameters which, if passed, are executed on-chain via GovernorBravo and amended in the smart contracts owned by Uniswap.
—LayerZero created and deployed a gasless oracle for applications to participate easily in their own security
—Major Uniswap delegates and top stakeholders (such as the most strongly incentivized investors of the protocol, L1/L2 Foundations, and major security and infrastructure platforms) can run a gasless oracle as part of the network.
To provide additional context, several of these organizations are already actively involved in the ongoing decentralization of LayerZero’s validation layer.
What this means: We’ve implemented a gasless signing mechanism to allow a group of ad hoc parties to easily manage an ad hoc oracle network between them. The gasless oracle is a brand new feature we had planned to announce in late February; documentation will be completed shortly. The LayerZero Labs team will commit dedicated human capital and technical resources to assist teams to fully run the node; estimated set-up time is less than 2 hours from end-to-end per team.
We propose that Uniswap utilize a gasless oracle of at least 5+ signers. We recommend a consensus grouping of the most respected industry entities and aligned parties with Uniswap (which Uniswap has already done an amazing job attracting via its Delegates) which will provide the most secure and aligned security structure to the protocol itself.
—We propose that at launch, Uniswap chooses to pair a gasless oracle run by a minimum of 5+ significant Uniswap delegates and the LayerZero Labs relayer as their validation layer within the broader LayerZero security model.
In the future, governance may choose to update these hyperparameters via an on-chain governance process enabling robust, flexible, and governance driven security.
We thank the delegate groups who reached out to us for their time and commitment to Uniswap governance and look forward to conversations with more stakeholders over the coming days.
great information about cross-chain
Hello! Chiming in on behalf of Blockchain at Berkeley:
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
Hello! Chiming in on behalf of Blockchain at Berkeley:
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
Given the ongoing scrutiny and cooperation with the bridge providers, we believe that a temperature check for specific bridges at this stage may not be the most effective approach.
Currently, it is difficult to make a point-to-point comparison between the proposals from the four main contenders, since there is not enough detailed information on the proposals. Providing detailed, finalized proposal summaries from the bridges is essential for the community to decide on the best providers to move forward with.
It is important to note that there are some concerns regarding all the existing bridge providers and their ability to fully meet the needs of Uniswap's governance message passing. While we recognize that each provider has its own unique strengths and weaknesses, it is essential that a thorough evaluation of all proposals is conducted to ensure that the best solution is chosen for the community. In particular, issues such as decentralization, economic incentives, and transparency of operations should be carefully considered before making a final decision.
Furthermore, we suggest that it may be beneficial to consider an alternative approach, such as outlining specific requirements for the ideal Uniswap bridge and choosing a vendor based on their ability to meet those specifications. This could help to avoid the "lesser of two evils" problem and ensure that the best solution is selected for the community.
Thrilled to see the community support for expanding Uniswap v3 to BNB Chain. BNB has long been a thriving part of the LayerZero ecosystem as BNB Chain was one of our initial launch chains and Binance was our first investor leading our seed round.
The BNB Chain team and the Uniswap Foundation recently reached out to LayerZero Labs about this opportunity and connected us to Ilia at Plasma to submit a proposal. Backed by a16z, Sequoia, Uniswap Labs, and Binance to name a few, LayerZero is supported by thousands of cross-chain builders with over 2,000 contracts deployed on mainnet, ~700 unique applications, ~2M total messages, ~$5B transactional volume, and billions of dollars in TVL. Builders include SushiSwap, PancakeSwap, BTC.b, Pudgy Penguins, Radiant, Stargate, Kanpai Pandas and many more unannounced integrations. Notable bridges built with LayerZero include the rebooted Harmony Bridge, CoreDAO bridge, and the Aptos Bridge.
Thrilled to see the community support for expanding Uniswap v3 to BNB Chain. BNB has long been a thriving part of the LayerZero ecosystem as BNB Chain was one of our initial launch chains and Binance was our first investor leading our seed round.
The BNB Chain team and the Uniswap Foundation recently reached out to LayerZero Labs about this opportunity and connected us to Ilia at Plasma to submit a proposal. Backed by a16z, Sequoia, Uniswap Labs, and Binance to name a few, LayerZero is supported by thousands of cross-chain builders with over 2,000 contracts deployed on mainnet, ~700 unique applications, ~2M total messages, ~$5B transactional volume, and billions of dollars in TVL. Builders include SushiSwap, PancakeSwap, BTC.b, Pudgy Penguins, Radiant, Stargate, Kanpai Pandas and many more unannounced integrations. Notable bridges built with LayerZero include the rebooted Harmony Bridge, CoreDAO bridge, and the Aptos Bridge.
Since our last proposal, we have built a fully functional governance implementation for Uniswap based on specs provided by the community and feedback from delegates and university groups, which is currently under audit with Zellic and Ottersec. These audits will be complete with fully tested code ready to be deployed within the next 2 weeks.
Uniswap v3 was approved by the community for deployment on both Moonbeam and Gnosis Chain last year. With this implementation, Uniswap can swiftly deploy Uniswap v3 to BNB Chain, Moonbeam and Gnosis maintaining a unified multi-audited governance model for interacting with all cross-chain deployments of Uniswap v3. With the community’s support, Uniswap v3 can expand to all three ecosystems in as soon as 2 weeks!
The complete omnichain governance module for Uniswap can be found here.
How It Works
LayerZero is a lightweight universal messaging interface that allows developers to seamlessly interact with contracts across dozens of blockchains. LayerZero Endpoints rely on an innovative architecture leveraging Ultra Light Nodes and independent Oracles and Relayers to securely relay messages between chains.
Communication flow in a single LayerZero crosschain transaction.
In a single call, paying only source gas, users and protocols can send a message (or a bundle of messages) to contracts on any supported chain. Thus, users are able to create a single contract that is capable of interacting simultaneously across multiple chains via our arbitrary messaging primitive.
LayerZero is currently live on 25+ chains including BNB Chain, Ethereum, Polygon, Arbitrum, Optimism, Avalanche, Gnosis, Metis, Aptos, Celo, Moonbeam and Fantom, and on testnet and undergoing audit on 6+ chains including Solana among other non-EVM chains. With a fully functional governance implementation, Uniswap can quickly deploy Uniswap v3 to all chains that LayerZero supports without compromising on security or introducing the complexity of multiple cross chain messaging protocols and services.
Security FAQ
Does the bridge support arbitrary message passing?
LayerZero enables smart contracts in disparate blockchains to communicate via arbitrary message passing of bytes payloads.
Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?
The current recommended configuration is secured by Chainlink as an oracle entity (currently securing tens of billions of dollars) and the LayerZero Labs (currently securing billions in TVL) operated relayer entity. All applications building on LayerZero have the choice to opt-in to default security or select a set of oracles and relayers. The architecture is entirely modular to allow Uniswap to run any portion of this validation layer if they so choose i.e. additional relayers and/or oracles.
LayerZero is a true protocol comprised entirely of immutable smart contracts and is not dependent on LayerZero Labs to be leveraged by applications in perpetuity.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?
LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
LayerZero provides the most secure solution for communication and puts control directly into the applications hands. It is worth noting that it is technically impossible to enable communication between blockchains in a fully trustless manner. Via the LayerZero protocol, the only way a fraudulent message may be passed to the destination chain is if both the Oracle entities and Relayer entities – selected by Uniswap - actively collude together and against the application to approve a fraudulent message.
Additionally, LayerZero is secured by a Pre-Crime, the proprietary security layer which has successfully secured the protocol and applications like Stargate since May 2022. Pre-Crime takes an outbound transaction and makes sure that it’s legitimate by running it against a set of application-defined invariants before the delivery of each message. Pre-Crime first forks every chain locally then it runs the state transaction locally to make sure the resulting state meets the list of defined invariants the application sets. Once this is confirmed Pre-Crime then provides an attestation that this is a legitimate transfer and the message is delivered.
What are the ramifications of fraud to the malicious actor?
Applications own all their smart contracts and maintain the ability to swap out Oracles and Relayers and/or expand their sets at their community’s discretion. Participating entities, including Chainlink, in the LayerZero network are thoroughly tested and vetted against rigorous standards in order to be supported in LayerZero documentation and are subject to re-evaluation at any time. Refer to an overview of Pre-Crime above for the additional security layer designed to prevent malicious actors from successful message delivery.
We designed LayerZero to be censorship resistant. Oracles and Relayers cannot censor messages without censoring all messages due to the sequential nonce ordered enforcement on the receiving chain. As a result, if an attacker obtained control of the Uniswap-selected Oracles or Relayers, and succeeded in censoring a message, every subsequent message would also be censored and the vote would stop. Uniswap could then expediently resolve the issue by updating configurations and messaging would resume.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
LayerZero Labs has commissioned 35+ audits with the most recent audits on Github here. Nearly all code written by LayerZero Labs since inception have been immutable smart contracts audited externally and rigorously reviewed internally at least 3+ times each. LayerZero is the only major cross-chain messaging protocol to have secured significant transaction volume (~$5B) over time without any exploit, compromise of key infrastructure, or loss of user funds. Additionally, LayerZero has the largest live bug bounty across the industry at up to $15m.
Our sole focus at LayerZero Labs is building best-in-class cross-chain infrastructure. We have infinite runway and are building for the developer community. Learn more at https://layerzero.network/developers.
We had the chance to connect with @ilia_0x yesterday over Telegram — we’ve answered the questions you’ve posed to us! The Wormhole community is excited to throw our hat in the ring, and we look forward to engaging with the Uniswap community more broadly 🙂
Hi everyone —We’re Wormhole, a leading arbitrary message passing protocol that connects 22 heterogeneous chains. Today, the Wormhole community includes several independent core contributing teams as well as a network of 19 industry leading Validators securing the network. The Wormhole community is investing deeply in a fully trustless future and is working on a Zero-Knowledge (ZK), light client based, backend designed to deprecate the Guardian software. Once enabled, chains can trustlessly validate other connected chains.
We had the chance to connect with @ilia_0x yesterday over Telegram — we’ve answered the questions you’ve posed to us! The Wormhole community is excited to throw our hat in the ring, and we look forward to engaging with the Uniswap community more broadly 🙂
Hi everyone —We’re Wormhole, a leading arbitrary message passing protocol that connects 22 heterogeneous chains. Today, the Wormhole community includes several independent core contributing teams as well as a network of 19 industry leading Validators securing the network. The Wormhole community is investing deeply in a fully trustless future and is working on a Zero-Knowledge (ZK), light client based, backend designed to deprecate the Guardian software. Once enabled, chains can trustlessly validate other connected chains.
Does the bridge support arbitrary message passing? a) Yes, Wormhole is one of the first and longest serving arbitrary messaging protocols. Since launching on mainnet in August 2021, 185 million messages have been transmitted, with 2 million messages currently generated daily between asset transfers and messaging through organic usage.
Is the bridge secured by a trusted entity, by a multi-sig, or a protocol/set of incentivized nodes? a) Wormhole is secured by 19 validators (aka: Guardians) who jointly attest to messages. Each message must be attested by at least 13 of the 19 Guardians. Our Guardian set comprises the leading PoS validators, including Staked, Figment, Chorus One, P2P, and more. The complete set of current validators can be found here: https://wormhole.com/network/ b) As mentioned above Wormhole is making significant progress in developing ZK-based light clients to facilitate completely trustless message-passing.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity? a) Wormhole message security waits for both consensus to be reached on the source chain as well as additional safety features provided by the bridge. Additionally, Guardians run full nodes to protect the protocol against consensus-level exploits in the connected chains and further reduce contagion risk.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
a) All messages passing through Wormhole require a minimum of observation and signing by a majority of the Wormhole Guardian set (13 of 19).
b) While there is currently no out-of-the-box recall mechanism for messages, a minority (7 of 19) Guardians may refuse to sign a fraudulent message and thwart an attack.
c) Simple yet customized message recall functions can be built by individual integrators. An integrator would simply build “edge contracts” to introduce a time delay on message acceptance, providing an integrator with an opportunity to recall the message before it becomes effective.
What are the ramifications of fraud to the malicious actor? a) Wormhole’s Guardians are leading PoS validators and some of the most respected names within the validator community. They collectively represent tens of billions in value staked and carry valuable reputations in the communities where they serve. Should they act maliciously (such as sign or forge fraudulent messages), they risk reputational consequences, external PoS businesses, and ejection from the Wormhole Guardian set. b) There is little incentive for an individual Guardian to act maliciously. Even if a Guardian were to succeed in forging a fraudulent message, it would not affect the network state because a single signature isn’t enough to establish the super-majority required to gain quorum. Finally, a fraudulent message would be immediately attributable to the offending Guardian to the rest of the Guardian network.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied? a) The bridge has been audited 25+ times by leading audit firms, including Certik, Trail of Bits, and OtterSec, and the cohort of auditors continues to grow. You can see the complete list of auditors and publicized findings here. Those 25 audits are in addition to Wormhole’s already rigorous internal auditing standards, where a team of 6 experienced security engineers regularly perform review the protocol’s security.
As these 3rd party audits are completed and issues are sufficiently addressed, we make those audits public.
We feel Wormhole is well-qualified to support Uniswap’s cross-chain messaging between ETH and the BNB PoS Chain, and we appreciate GFX Labs’s proposed solution. If anyone has additional questions, we would be happy to answer them.
Wormhole Resources:
Repeating what I posted in Discord:
Is Uniswap aware/worried about the possibility of a security issue regarding repairing hashes with Beacon Chain?
Repeating what I posted in Discord:
Is Uniswap aware/worried about the possibility of a security issue regarding repairing hashes with Beacon Chain?
If this thing is not really a blockchain it means whoever is repairing these hashes is operating the system. We can debate how and to what degree Bitcoin, Ethereum and other blockchains are decentralized. But nobody there is repairing hashes looking backwards whereas here things look decidedly less like Satoshi’s vision. datafinnovation[dot]medium[dot]com[slash]bnb-beacon-chain-not-a-blockchain-3230dda7172c
(I know nothing about "datafinnovation" except they were mentioned in an Arthur Hayes blog post and many of their posts seemed prescient of later issues being revealed.)
Aave, for example, will go on a chain and then remove support if there is security risk (i.e. a reliance on a single bridge, pre-or-post that bridge being compromised). This post suggests serious security risks. I know BSC is attractive considering its TVL, but this could have serious implications, no?
Hi Mo, I love the tech that you’re building at Celer, but I think that the Uniswap community may misinterpret a number of your points, so these need to be clarified.
Hi Mo, I love the tech that you’re building at Celer, but I think that the Uniswap community may misinterpret a number of your points, so these need to be clarified.
When you say a “Cosmos-consensus Security Model” or “L1-PoS-blockchain security mode,” someone may interpret that Celer inherits the security model from the Cosmos chain or from the layer-1 where the message was initiated — both of these statements are not the case. Instead, it is accurate to say that with this model, the Celer network is using Tendermint and Cosmos SDK as a set of ready-to-use tools and technologies for implementing consensus and networking layers for the project.
The PoS consensus implementation allows anyone with ⅔ of the voting power (i.e. ⅔ of the amount of staked tokens) to have full control over the consensus and validation of cross-chain messages.
The current total stake is 2,587,158,380 CELR and thus, if nodes with more than 2/3 of the total stake act maliciously, they can forge any message. 7 nodes currently have enough stake to control consensus.
⅔ of the total current stake is 1,724,772,247.33 CELR ≈ $25M at current market price. This is the approximate cost that would allow an attacker to withdraw liquidity from all Celer liquidity pools and forge any message to extract value from any Apps built using Celer Network, and, importantly, I assume the potential value extracted by an attack on Uniswap may be higher than the cost of attack.
The only staked asset is the CELR governance token, which means that validators’ collateral directly correlates with the protocol’s performance. This is why an attacker could open a large short perpetual futures position before attacking the protocol, and recover/hedge the cost of their acquired stake.
Having more than 2/3 of the protocol voting power would allow a malicious entity to control the consensus process and make arbitrary decisions about which blocks to add to the blockchain, forge cross-chain messages, reverse and censor transactions, create fake transactions, and create their own set of validation nodes.
Correct me if I’m wrong, but this attack can be performed by any single whitelisted Celer validator now.
You may say that the described problem can be solved through an Optimistic rollup-like security model which is the second alternative provided by Celer. My guess is that this wouldn’t add any additional security to the validation layer for a few reasons:
I’m not trying to attack a competitor here, I want to make sure that all trust assumptions and risks are made clear for the Uniswap community, as Celer has been endorsed in the temperature check.
I explained above that since BNB Chain doesn't have a canonical bridge, any interoperability solution will inevitably have a validation layer and Uniswap governance will still have to bear the risk that participants of the validation layer will not collude.
zk, optimistic — are just different implementations of the validation layer. As an example, here is an article from L2Beat with an interesting experiment that shows that "oracle and relayer" implementation of the validation layer is a 2/2 consensus mechanism, where validation of headers/proofs doesn't add any security guarantees, but only gas costs since oracle and relayer can always collude.
I explained above that since BNB Chain doesn't have a canonical bridge, any interoperability solution will inevitably have a validation layer and Uniswap governance will still have to bear the risk that participants of the validation layer will not collude.
zk, optimistic — are just different implementations of the validation layer. As an example, here is an article from L2Beat with an interesting experiment that shows that "oracle and relayer" implementation of the validation layer is a 2/2 consensus mechanism, where validation of headers/proofs doesn't add any security guarantees, but only gas costs since oracle and relayer can always collude.
https://medium.com/l2beat/circumventing-layer-zero-5e9f652a5d3e
I think the best way to move forward for Uniswap is to have a framework for bridges so that instead of relying on a single solution, Governance decisions are sent from Ethereum to other chains (e.g. BNB Chain), my multiple bridges. The passed decision is executed on the destination chain only in case the content of the messages sent by all bridges participating in the framework is matching.
deBridge team can help to prepare this framework so that Uniswap governance can have an established process for adding any new chains in the future
We’ve recently had open discussions with many of the delegate groups around the security features and fundamental architecture of LayerZero and its fitness for secure and scalable omnichain governance for the Uniswap protocol. The following are key topics and outcomes from the discussion shared publicly for the community’s awareness:
—LayerZero’s omnichain governance executor (complete open source code here) is designed to enable Uniswap governance to add, remove, or swap validation layer components directly from on-chain votes via GovernorBravo.
What this means: Security of the protocol’s cross-chain governance can scale with the protocol over time. Governance always maintains the ability to propose and vote to change parameters which, if passed, are executed on-chain via GovernorBravo and amended in the smart contracts owned by Uniswap.
—LayerZero created and deployed a gasless oracle for applications to participate easily in their own security
—Major Uniswap delegates and top stakeholders (such as the most strongly incentivized investors of the protocol, L1/L2 Foundations, and major security and infrastructure platforms) can run a gasless oracle as part of the network.
To provide additional context, several of these organizations are already actively involved in the ongoing decentralization of LayerZero’s validation layer.
What this means: We’ve implemented a gasless signing mechanism to allow a group of ad hoc parties to easily manage an ad hoc oracle network between them. The gasless oracle is a brand new feature we had planned to announce in late February; documentation will be completed shortly. The LayerZero Labs team will commit dedicated human capital and technical resources to assist teams to fully run the node; estimated set-up time is less than 2 hours from end-to-end per team.
We propose that Uniswap utilize a gasless oracle of at least 5+ signers. We recommend a consensus grouping of the most respected industry entities and aligned parties with Uniswap (which Uniswap has already done an amazing job attracting via its Delegates) which will provide the most secure and aligned security structure to the protocol itself.
—We propose that at launch, Uniswap chooses to pair a gasless oracle run by a minimum of 5+ significant Uniswap delegates and the LayerZero Labs relayer as their validation layer within the broader LayerZero security model.
In the future, governance may choose to update these hyperparameters via an on-chain governance process enabling robust, flexible, and governance driven security.
We thank the delegate groups who reached out to us for their time and commitment to Uniswap governance and look forward to conversations with more stakeholders over the coming days.
great information about cross-chain
Hello! Chiming in on behalf of Blockchain at Berkeley:
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
Hello! Chiming in on behalf of Blockchain at Berkeley:
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
Given the ongoing scrutiny and cooperation with the bridge providers, we believe that a temperature check for specific bridges at this stage may not be the most effective approach.
Currently, it is difficult to make a point-to-point comparison between the proposals from the four main contenders, since there is not enough detailed information on the proposals. Providing detailed, finalized proposal summaries from the bridges is essential for the community to decide on the best providers to move forward with.
It is important to note that there are some concerns regarding all the existing bridge providers and their ability to fully meet the needs of Uniswap's governance message passing. While we recognize that each provider has its own unique strengths and weaknesses, it is essential that a thorough evaluation of all proposals is conducted to ensure that the best solution is chosen for the community. In particular, issues such as decentralization, economic incentives, and transparency of operations should be carefully considered before making a final decision.
Furthermore, we suggest that it may be beneficial to consider an alternative approach, such as outlining specific requirements for the ideal Uniswap bridge and choosing a vendor based on their ability to meet those specifications. This could help to avoid the "lesser of two evils" problem and ensure that the best solution is selected for the community.
Thrilled to see the community support for expanding Uniswap v3 to BNB Chain. BNB has long been a thriving part of the LayerZero ecosystem as BNB Chain was one of our initial launch chains and Binance was our first investor leading our seed round.
The BNB Chain team and the Uniswap Foundation recently reached out to LayerZero Labs about this opportunity and connected us to Ilia at Plasma to submit a proposal. Backed by a16z, Sequoia, Uniswap Labs, and Binance to name a few, LayerZero is supported by thousands of cross-chain builders with over 2,000 contracts deployed on mainnet, ~700 unique applications, ~2M total messages, ~$5B transactional volume, and billions of dollars in TVL. Builders include SushiSwap, PancakeSwap, BTC.b, Pudgy Penguins, Radiant, Stargate, Kanpai Pandas and many more unannounced integrations. Notable bridges built with LayerZero include the rebooted Harmony Bridge, CoreDAO bridge, and the Aptos Bridge.
Thrilled to see the community support for expanding Uniswap v3 to BNB Chain. BNB has long been a thriving part of the LayerZero ecosystem as BNB Chain was one of our initial launch chains and Binance was our first investor leading our seed round.
The BNB Chain team and the Uniswap Foundation recently reached out to LayerZero Labs about this opportunity and connected us to Ilia at Plasma to submit a proposal. Backed by a16z, Sequoia, Uniswap Labs, and Binance to name a few, LayerZero is supported by thousands of cross-chain builders with over 2,000 contracts deployed on mainnet, ~700 unique applications, ~2M total messages, ~$5B transactional volume, and billions of dollars in TVL. Builders include SushiSwap, PancakeSwap, BTC.b, Pudgy Penguins, Radiant, Stargate, Kanpai Pandas and many more unannounced integrations. Notable bridges built with LayerZero include the rebooted Harmony Bridge, CoreDAO bridge, and the Aptos Bridge.
Since our last proposal, we have built a fully functional governance implementation for Uniswap based on specs provided by the community and feedback from delegates and university groups, which is currently under audit with Zellic and Ottersec. These audits will be complete with fully tested code ready to be deployed within the next 2 weeks.
Uniswap v3 was approved by the community for deployment on both Moonbeam and Gnosis Chain last year. With this implementation, Uniswap can swiftly deploy Uniswap v3 to BNB Chain, Moonbeam and Gnosis maintaining a unified multi-audited governance model for interacting with all cross-chain deployments of Uniswap v3. With the community’s support, Uniswap v3 can expand to all three ecosystems in as soon as 2 weeks!
The complete omnichain governance module for Uniswap can be found here.
How It Works
LayerZero is a lightweight universal messaging interface that allows developers to seamlessly interact with contracts across dozens of blockchains. LayerZero Endpoints rely on an innovative architecture leveraging Ultra Light Nodes and independent Oracles and Relayers to securely relay messages between chains.
Communication flow in a single LayerZero crosschain transaction.
In a single call, paying only source gas, users and protocols can send a message (or a bundle of messages) to contracts on any supported chain. Thus, users are able to create a single contract that is capable of interacting simultaneously across multiple chains via our arbitrary messaging primitive.
LayerZero is currently live on 25+ chains including BNB Chain, Ethereum, Polygon, Arbitrum, Optimism, Avalanche, Gnosis, Metis, Aptos, Celo, Moonbeam and Fantom, and on testnet and undergoing audit on 6+ chains including Solana among other non-EVM chains. With a fully functional governance implementation, Uniswap can quickly deploy Uniswap v3 to all chains that LayerZero supports without compromising on security or introducing the complexity of multiple cross chain messaging protocols and services.
Security FAQ
Does the bridge support arbitrary message passing?
LayerZero enables smart contracts in disparate blockchains to communicate via arbitrary message passing of bytes payloads.
Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?
The current recommended configuration is secured by Chainlink as an oracle entity (currently securing tens of billions of dollars) and the LayerZero Labs (currently securing billions in TVL) operated relayer entity. All applications building on LayerZero have the choice to opt-in to default security or select a set of oracles and relayers. The architecture is entirely modular to allow Uniswap to run any portion of this validation layer if they so choose i.e. additional relayers and/or oracles.
LayerZero is a true protocol comprised entirely of immutable smart contracts and is not dependent on LayerZero Labs to be leveraged by applications in perpetuity.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?
LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
LayerZero provides the most secure solution for communication and puts control directly into the applications hands. It is worth noting that it is technically impossible to enable communication between blockchains in a fully trustless manner. Via the LayerZero protocol, the only way a fraudulent message may be passed to the destination chain is if both the Oracle entities and Relayer entities – selected by Uniswap - actively collude together and against the application to approve a fraudulent message.
Additionally, LayerZero is secured by a Pre-Crime, the proprietary security layer which has successfully secured the protocol and applications like Stargate since May 2022. Pre-Crime takes an outbound transaction and makes sure that it’s legitimate by running it against a set of application-defined invariants before the delivery of each message. Pre-Crime first forks every chain locally then it runs the state transaction locally to make sure the resulting state meets the list of defined invariants the application sets. Once this is confirmed Pre-Crime then provides an attestation that this is a legitimate transfer and the message is delivered.
What are the ramifications of fraud to the malicious actor?
Applications own all their smart contracts and maintain the ability to swap out Oracles and Relayers and/or expand their sets at their community’s discretion. Participating entities, including Chainlink, in the LayerZero network are thoroughly tested and vetted against rigorous standards in order to be supported in LayerZero documentation and are subject to re-evaluation at any time. Refer to an overview of Pre-Crime above for the additional security layer designed to prevent malicious actors from successful message delivery.
We designed LayerZero to be censorship resistant. Oracles and Relayers cannot censor messages without censoring all messages due to the sequential nonce ordered enforcement on the receiving chain. As a result, if an attacker obtained control of the Uniswap-selected Oracles or Relayers, and succeeded in censoring a message, every subsequent message would also be censored and the vote would stop. Uniswap could then expediently resolve the issue by updating configurations and messaging would resume.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
LayerZero Labs has commissioned 35+ audits with the most recent audits on Github here. Nearly all code written by LayerZero Labs since inception have been immutable smart contracts audited externally and rigorously reviewed internally at least 3+ times each. LayerZero is the only major cross-chain messaging protocol to have secured significant transaction volume (~$5B) over time without any exploit, compromise of key infrastructure, or loss of user funds. Additionally, LayerZero has the largest live bug bounty across the industry at up to $15m.
Our sole focus at LayerZero Labs is building best-in-class cross-chain infrastructure. We have infinite runway and are building for the developer community. Learn more at https://layerzero.network/developers.
We had the chance to connect with @ilia_0x yesterday over Telegram — we’ve answered the questions you’ve posed to us! The Wormhole community is excited to throw our hat in the ring, and we look forward to engaging with the Uniswap community more broadly 🙂
Hi everyone —We’re Wormhole, a leading arbitrary message passing protocol that connects 22 heterogeneous chains. Today, the Wormhole community includes several independent core contributing teams as well as a network of 19 industry leading Validators securing the network. The Wormhole community is investing deeply in a fully trustless future and is working on a Zero-Knowledge (ZK), light client based, backend designed to deprecate the Guardian software. Once enabled, chains can trustlessly validate other connected chains.
We had the chance to connect with @ilia_0x yesterday over Telegram — we’ve answered the questions you’ve posed to us! The Wormhole community is excited to throw our hat in the ring, and we look forward to engaging with the Uniswap community more broadly 🙂
Hi everyone —We’re Wormhole, a leading arbitrary message passing protocol that connects 22 heterogeneous chains. Today, the Wormhole community includes several independent core contributing teams as well as a network of 19 industry leading Validators securing the network. The Wormhole community is investing deeply in a fully trustless future and is working on a Zero-Knowledge (ZK), light client based, backend designed to deprecate the Guardian software. Once enabled, chains can trustlessly validate other connected chains.
Does the bridge support arbitrary message passing? a) Yes, Wormhole is one of the first and longest serving arbitrary messaging protocols. Since launching on mainnet in August 2021, 185 million messages have been transmitted, with 2 million messages currently generated daily between asset transfers and messaging through organic usage.
Is the bridge secured by a trusted entity, by a multi-sig, or a protocol/set of incentivized nodes? a) Wormhole is secured by 19 validators (aka: Guardians) who jointly attest to messages. Each message must be attested by at least 13 of the 19 Guardians. Our Guardian set comprises the leading PoS validators, including Staked, Figment, Chorus One, P2P, and more. The complete set of current validators can be found here: https://wormhole.com/network/ b) As mentioned above Wormhole is making significant progress in developing ZK-based light clients to facilitate completely trustless message-passing.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity? a) Wormhole message security waits for both consensus to be reached on the source chain as well as additional safety features provided by the bridge. Additionally, Guardians run full nodes to protect the protocol against consensus-level exploits in the connected chains and further reduce contagion risk.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
a) All messages passing through Wormhole require a minimum of observation and signing by a majority of the Wormhole Guardian set (13 of 19).
b) While there is currently no out-of-the-box recall mechanism for messages, a minority (7 of 19) Guardians may refuse to sign a fraudulent message and thwart an attack.
c) Simple yet customized message recall functions can be built by individual integrators. An integrator would simply build “edge contracts” to introduce a time delay on message acceptance, providing an integrator with an opportunity to recall the message before it becomes effective.
What are the ramifications of fraud to the malicious actor? a) Wormhole’s Guardians are leading PoS validators and some of the most respected names within the validator community. They collectively represent tens of billions in value staked and carry valuable reputations in the communities where they serve. Should they act maliciously (such as sign or forge fraudulent messages), they risk reputational consequences, external PoS businesses, and ejection from the Wormhole Guardian set. b) There is little incentive for an individual Guardian to act maliciously. Even if a Guardian were to succeed in forging a fraudulent message, it would not affect the network state because a single signature isn’t enough to establish the super-majority required to gain quorum. Finally, a fraudulent message would be immediately attributable to the offending Guardian to the rest of the Guardian network.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied? a) The bridge has been audited 25+ times by leading audit firms, including Certik, Trail of Bits, and OtterSec, and the cohort of auditors continues to grow. You can see the complete list of auditors and publicized findings here. Those 25 audits are in addition to Wormhole’s already rigorous internal auditing standards, where a team of 6 experienced security engineers regularly perform review the protocol’s security.
As these 3rd party audits are completed and issues are sufficiently addressed, we make those audits public.
We feel Wormhole is well-qualified to support Uniswap’s cross-chain messaging between ETH and the BNB PoS Chain, and we appreciate GFX Labs’s proposed solution. If anyone has additional questions, we would be happy to answer them.
Wormhole Resources:
Repeating what I posted in Discord:
Is Uniswap aware/worried about the possibility of a security issue regarding repairing hashes with Beacon Chain?
Repeating what I posted in Discord:
Is Uniswap aware/worried about the possibility of a security issue regarding repairing hashes with Beacon Chain?
If this thing is not really a blockchain it means whoever is repairing these hashes is operating the system. We can debate how and to what degree Bitcoin, Ethereum and other blockchains are decentralized. But nobody there is repairing hashes looking backwards whereas here things look decidedly less like Satoshi’s vision. datafinnovation[dot]medium[dot]com[slash]bnb-beacon-chain-not-a-blockchain-3230dda7172c
(I know nothing about "datafinnovation" except they were mentioned in an Arthur Hayes blog post and many of their posts seemed prescient of later issues being revealed.)
Aave, for example, will go on a chain and then remove support if there is security risk (i.e. a reliance on a single bridge, pre-or-post that bridge being compromised). This post suggests serious security risks. I know BSC is attractive considering its TVL, but this could have serious implications, no?
Hi Mo, I love the tech that you’re building at Celer, but I think that the Uniswap community may misinterpret a number of your points, so these need to be clarified.
Hi Mo, I love the tech that you’re building at Celer, but I think that the Uniswap community may misinterpret a number of your points, so these need to be clarified.
When you say a “Cosmos-consensus Security Model” or “L1-PoS-blockchain security mode,” someone may interpret that Celer inherits the security model from the Cosmos chain or from the layer-1 where the message was initiated — both of these statements are not the case. Instead, it is accurate to say that with this model, the Celer network is using Tendermint and Cosmos SDK as a set of ready-to-use tools and technologies for implementing consensus and networking layers for the project.
The PoS consensus implementation allows anyone with ⅔ of the voting power (i.e. ⅔ of the amount of staked tokens) to have full control over the consensus and validation of cross-chain messages.
The current total stake is 2,587,158,380 CELR and thus, if nodes with more than 2/3 of the total stake act maliciously, they can forge any message. 7 nodes currently have enough stake to control consensus.
⅔ of the total current stake is 1,724,772,247.33 CELR ≈ $25M at current market price. This is the approximate cost that would allow an attacker to withdraw liquidity from all Celer liquidity pools and forge any message to extract value from any Apps built using Celer Network, and, importantly, I assume the potential value extracted by an attack on Uniswap may be higher than the cost of attack.
The only staked asset is the CELR governance token, which means that validators’ collateral directly correlates with the protocol’s performance. This is why an attacker could open a large short perpetual futures position before attacking the protocol, and recover/hedge the cost of their acquired stake.
Having more than 2/3 of the protocol voting power would allow a malicious entity to control the consensus process and make arbitrary decisions about which blocks to add to the blockchain, forge cross-chain messages, reverse and censor transactions, create fake transactions, and create their own set of validation nodes.
Correct me if I’m wrong, but this attack can be performed by any single whitelisted Celer validator now.
You may say that the described problem can be solved through an Optimistic rollup-like security model which is the second alternative provided by Celer. My guess is that this wouldn’t add any additional security to the validation layer for a few reasons:
I’m not trying to attack a competitor here, I want to make sure that all trust assumptions and risks are made clear for the Uniswap community, as Celer has been endorsed in the temperature check.
I explained above that since BNB Chain doesn't have a canonical bridge, any interoperability solution will inevitably have a validation layer and Uniswap governance will still have to bear the risk that participants of the validation layer will not collude.
zk, optimistic — are just different implementations of the validation layer. As an example, here is an article from L2Beat with an interesting experiment that shows that "oracle and relayer" implementation of the validation layer is a 2/2 consensus mechanism, where validation of headers/proofs doesn't add any security guarantees, but only gas costs since oracle and relayer can always collude.
I explained above that since BNB Chain doesn't have a canonical bridge, any interoperability solution will inevitably have a validation layer and Uniswap governance will still have to bear the risk that participants of the validation layer will not collude.
zk, optimistic — are just different implementations of the validation layer. As an example, here is an article from L2Beat with an interesting experiment that shows that "oracle and relayer" implementation of the validation layer is a 2/2 consensus mechanism, where validation of headers/proofs doesn't add any security guarantees, but only gas costs since oracle and relayer can always collude.
https://medium.com/l2beat/circumventing-layer-zero-5e9f652a5d3e
I think the best way to move forward for Uniswap is to have a framework for bridges so that instead of relying on a single solution, Governance decisions are sent from Ethereum to other chains (e.g. BNB Chain), my multiple bridges. The passed decision is executed on the destination chain only in case the content of the messages sent by all bridges participating in the framework is matching.
deBridge team can help to prepare this framework so that Uniswap governance can have an established process for adding any new chains in the future
Does anyone think about the risks?
Does anyone think about the risks?
This is a brilliant proposal. It's about time to get this rolling.
Kromatika is built on Uniswap V3 and Kromatika's premium product - Limit Orders (also called FELO - Fees Earning Limit Orders - by Kromatikans) has automated UniV3.
Kromatika supports this proposal and want to contribute in its implementation.
Would be happy to work alongside @ilia_0x and 0xPlasma.
Thank you @ilia_0x for this proposal. Speaking on behalf of BNB Chain foundation side, we are welcoming this idea and are humbled by this proposal.
We will also be happy to provide all the necessary support for a successful deployment on the chain if the vote pass.
Hi everyone, I’m Alex — co-founder of deBridge
Since BNB Chain doesn’t have any canonical/trust-minimized bridge, I’d like to suggest using deBridge as a secure solution to execute and relay any Uniswap governance decisions from Ethereum to BNB Chain.
Hi everyone, I’m Alex — co-founder of deBridge
Since BNB Chain doesn’t have any canonical/trust-minimized bridge, I’d like to suggest using deBridge as a secure solution to execute and relay any Uniswap governance decisions from Ethereum to BNB Chain.
deBridge is a secure cross-chain infrastructure enabling seamless interoperability between blockchains, powering transfers of any messages and liquidity with zero slippage and zero locked liquidity at risk.
A transaction through deBridge’s architecture passes through two key layers:
Protocol Layer (on-chain) – a set of on-chain smart contracts deployed on all deBridge-supported chains. The parameters of the smart contracts, such as fees, chains, and list of validators, are managed by deBridge governance.
Infrastructure Layer (off-chain) – nodes run by validators elected via deBridge’s governance. These validators also run full nodes on all the blockchains supported by deBridge.
According to the cross-chain Deployment Proposals Framework, here are answers to the Bridge Security questions in the context of deBridge:
Does the bridge support arbitrary message passing?
Yes, deBridge infrastructure supports any message transfers and has delivered 126,000+ messages since its launch in February 2022. Details of any cross-chain transfer through deBridge’s infrastructure can be accessed by anyone on deExplorer
Is the bridge secured by a trusted entity, by a multi sig, or by a protocol/set of incentivized nodes?
Validation of any cross-chain transactions goes down to social consensus around forks. That’s why canonical or trust-minimized bridges based on light or full clients are possible only between two blockchain ecosystems (normally L1 and L2) as if there is a fork in L1, then there is a fork in L2 and users can always pick which of the forks to use.
Non-canonical interoperability layers and bridges can’t be fully trustless by their nature, due to the need to have a validation layer that should at least determine which of the forks is valid and supported by the community, so it’s all a matter of how this validation layer is implemented.
Different protocols have different implementations, such as:
deBridge validation layer uses a “delegated staking and slashing” with a set of validation nodes, optimizing for security and speed. All validators are elected by and work for deBridge governance. To be confirmed, a transaction must be signed by at least ⅔ of the validators, i.e., 8 out of 12. The validators are disincentivized to act maliciously as they bear financial risks through a delegated staking and slashing module.
deBridge plans to scale its validator set, increasing the threshold of signatures required for message validation, and thus enhancing the protocol’s overall security.
Thanks to off-chain validation, the validators don’t need to communicate with each other, thus their IP addresses are never exposed, increasing the overall security of the infrastructure.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is the security provided by another third-party entity?
As described in the previous paragraph, any bridges and interoperability layers (except canonical ones) have to rely on the validation layer. deBridge leverages professional infrastructure providers to validate cross-chain messages passing through deBridge protocol.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
In order to forge a message, ⅔ of deBridge validators would need to collude and each one would need to provide a signature of the malicious message identifier. deBridge validators are professional infrastructure providers that validate many other protocols and blockchains. All validators bear reputational and financial risks
What are the ramifications of fraud to the malicious actor?
The validators are disincentivized to act maliciously as they bear financial risks for their service as per the delegated staking and slashing module.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
Security has always been the top priority for our team. deBridge and its’ periphery modules have been audited 17 times by Halborn, Zokyo, Ackee Blockchain, and Neodyme. Additionally, deBridge offers a $200,000 bounty program on Immunefi. All the findings and remediations can be seen in the published security audit reports available in the public Github repository
Additional resources: Documentation portal Developers portal deBridge explorer
deBridge team will be glad to facilitate the development and security audit of all smart contracts needed to relay and execute Uniswap governance decisions from Ethereum to BNB Chain. If deBridge is chosen as messaging provider, our team will cover costs for the security audit, performed by our long-term security partner Halborn
We welcome any questions about deBridge in the comments below
This is a good one! To enable Quadrat Strategies to BNB via uniswap!
That's good idea! huge market potential
This is a brilliant proposal. It's about time to get this rolling.
Kromatika is built on Uniswap V3 and Kromatika's premium product - Limit Orders (also called FELO - Fees Earning Limit Orders - by Kromatikans) has automated UniV3.
Kromatika supports this proposal and want to contribute in its implementation.
Would be happy to work alongside @ilia_0x and 0xPlasma.
Thank you @ilia_0x for this proposal. Speaking on behalf of BNB Chain foundation side, we are welcoming this idea and are humbled by this proposal.
We will also be happy to provide all the necessary support for a successful deployment on the chain if the vote pass.
Hi everyone, I’m Alex — co-founder of deBridge
Since BNB Chain doesn’t have any canonical/trust-minimized bridge, I’d like to suggest using deBridge as a secure solution to execute and relay any Uniswap governance decisions from Ethereum to BNB Chain.
Hi everyone, I’m Alex — co-founder of deBridge
Since BNB Chain doesn’t have any canonical/trust-minimized bridge, I’d like to suggest using deBridge as a secure solution to execute and relay any Uniswap governance decisions from Ethereum to BNB Chain.
deBridge is a secure cross-chain infrastructure enabling seamless interoperability between blockchains, powering transfers of any messages and liquidity with zero slippage and zero locked liquidity at risk.
A transaction through deBridge’s architecture passes through two key layers:
Protocol Layer (on-chain) – a set of on-chain smart contracts deployed on all deBridge-supported chains. The parameters of the smart contracts, such as fees, chains, and list of validators, are managed by deBridge governance.
Infrastructure Layer (off-chain) – nodes run by validators elected via deBridge’s governance. These validators also run full nodes on all the blockchains supported by deBridge.
According to the cross-chain Deployment Proposals Framework, here are answers to the Bridge Security questions in the context of deBridge:
Does the bridge support arbitrary message passing?
Yes, deBridge infrastructure supports any message transfers and has delivered 126,000+ messages since its launch in February 2022. Details of any cross-chain transfer through deBridge’s infrastructure can be accessed by anyone on deExplorer
Is the bridge secured by a trusted entity, by a multi sig, or by a protocol/set of incentivized nodes?
Validation of any cross-chain transactions goes down to social consensus around forks. That’s why canonical or trust-minimized bridges based on light or full clients are possible only between two blockchain ecosystems (normally L1 and L2) as if there is a fork in L1, then there is a fork in L2 and users can always pick which of the forks to use.
Non-canonical interoperability layers and bridges can’t be fully trustless by their nature, due to the need to have a validation layer that should at least determine which of the forks is valid and supported by the community, so it’s all a matter of how this validation layer is implemented.
Different protocols have different implementations, such as:
deBridge validation layer uses a “delegated staking and slashing” with a set of validation nodes, optimizing for security and speed. All validators are elected by and work for deBridge governance. To be confirmed, a transaction must be signed by at least ⅔ of the validators, i.e., 8 out of 12. The validators are disincentivized to act maliciously as they bear financial risks through a delegated staking and slashing module.
deBridge plans to scale its validator set, increasing the threshold of signatures required for message validation, and thus enhancing the protocol’s overall security.
Thanks to off-chain validation, the validators don’t need to communicate with each other, thus their IP addresses are never exposed, increasing the overall security of the infrastructure.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is the security provided by another third-party entity?
As described in the previous paragraph, any bridges and interoperability layers (except canonical ones) have to rely on the validation layer. deBridge leverages professional infrastructure providers to validate cross-chain messages passing through deBridge protocol.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
In order to forge a message, ⅔ of deBridge validators would need to collude and each one would need to provide a signature of the malicious message identifier. deBridge validators are professional infrastructure providers that validate many other protocols and blockchains. All validators bear reputational and financial risks
What are the ramifications of fraud to the malicious actor?
The validators are disincentivized to act maliciously as they bear financial risks for their service as per the delegated staking and slashing module.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
Security has always been the top priority for our team. deBridge and its’ periphery modules have been audited 17 times by Halborn, Zokyo, Ackee Blockchain, and Neodyme. Additionally, deBridge offers a $200,000 bounty program on Immunefi. All the findings and remediations can be seen in the published security audit reports available in the public Github repository
Additional resources: Documentation portal Developers portal deBridge explorer
deBridge team will be glad to facilitate the development and security audit of all smart contracts needed to relay and execute Uniswap governance decisions from Ethereum to BNB Chain. If deBridge is chosen as messaging provider, our team will cover costs for the security audit, performed by our long-term security partner Halborn
We welcome any questions about deBridge in the comments below
This is a good one! To enable Quadrat Strategies to BNB via uniswap!
That's good idea! huge market potential
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind… The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind… The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
Good news is that it does not actually take months to figure out a multi-bridge solution as there is already one running on testnet that can integrate deBridge, Celer and Wormhole all together. This solution is being audited as we speak.
I was in the Layer Zero camp due to their straightforwardness with technical information and documentation. The risks were presented clearly to me vs the other bridges. However, it is important to expand Uniswap into other ecosystems.
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind.... The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
I was in the Layer Zero camp due to their straightforwardness with technical information and documentation. The risks were presented clearly to me vs the other bridges. However, it is important to expand Uniswap into other ecosystems.
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind.... The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
Clarity on deploying cross-chain with no bridge, and changing the bridge used for a chain
Devin's comments resolved my worries about bridge flexibility. My priorities for this proposal are expanding to BSC first, and the bridge is secondary. Once passed there is time to test out the multi bridge tooling without rushing to simultaneously launch on BSC. Wormhole's history shows that it has been battled tested through failures; and will suit the purpose of a temporary bridge for BSC. My biggest concern with DAO governance is the inability to make actions in a timely manner.
A testnet deployment is done.
Setup:
The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.
A testnet deployment is done.
Setup:
The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.
Test results:
Happy to answer any questions!
It is now quite clear that the initial concern raised by the community about Celer's upgradability contract, which we addressed here and plan to deprecation soon, is absolutely not bigger concerns comparing to many of the issues revealed and discussed in the forum.
It is now quite clear that the initial concern raised by the community about Celer's upgradability contract, which we addressed here and plan to deprecation soon, is absolutely not bigger concerns comparing to many of the issues revealed and discussed in the forum.
While we have a lot to say about the ongoing debates in the forum and CT, we refrain from doing so and instead now deliver a multi-bridge Uniswap governance solution that is vendor-lock-in-free for Uniswap community to consider.
For Uniswap community who has not casted votes yet, please vote for Celer to express your support for this kind of multi-bridge solution.
This solution is strictly better than choosing a single bridge in terms of security and availability. In addition, it also retains the strongest bargaining power in the hands of Uniswap community to always receive the best services. See this for more context.
The implementation combines both Celer and Wormhole and is open-sourced here https://github.com/celer-network/sgn-v2-contracts/blob/multibridge/contracts/message/apps/multibridge/
All other bridges/cross-chain solutions such as LayerZero can be added easily via adapters.
We are setting up a testnet transaction to demonstrate this end-to-end. @Wormhole team we hope that you can help to set up a relayer for this because otherwise the only easy way would be deploying on Avalanche and BSC testnet where Wormhole generic relayers are available to our knowledge. Feel free to DM!
Now let's get to the solution specification.
This is a solution for cross-chain message passing without vendor lock-in and with enhanced security beyond any single bridge. A message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges.
The current solution are designed for messages being sent from one source chain to multiple destination chains. It also requires that there is only one permitted sender on the source chain. This would be the use case for Uniswap governance contract on Ethereum calling remote functions of contracts on other EVM chains.
To send a message to execute a remote call on the destintion chain, sender on the source chain should call remoteCall() of MultiBridgeSender, which invokes sendMessage() of every bridge sender apdater to send messages via different message bridges.
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Source chain │
│ │
│ ┌─────────────────┐ ┌───────────────────┐ │
│ ┌──►│ Bridge1 Adapter ├──►│ Bridge1 Contracts │ │
│ │ └─────────────────┘ └───────────────────┘ │
│ │ │
│ ┌────────┐remoteCall()┌───────────────────┐sendMessage()│ ┌─────────────────┐ ┌───────────────────┐ │
│ │ Caller ├───────────►│ MultiBridgeSender ├─────────────┼──►│ Bridge2 Adapter ├──►│ Bridge2 Contracts │ │
│ └────────┘ └───────────────────┘ │ └─────────────────┘ └───────────────────┘ │
│ │ │
│ │ ┌─────────────────┐ ┌───────────────────┐ │
│ └──►│ Bridge3 Adapter ├──►│ Bridge3 Contracts │ │
│ └─────────────────┘ └───────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────┘
On the destination chain, MultiBridgeReceiver receives messages from every bridge receiver adapter. Each receiver adapter gets encoded message data from its bridge contracts, and then decode the message and call receiveMessage() of MultiBrideReceiver.
MultiBridgeReceiver maintains a map from bridge adapter address to its power. Only adapter with non-zero power has access to receiveMessage() function. If the accumulated power of a message has reached the a threshold, which means enough number of different bridges have delivered a same message, the message will be executed by the MultiBrideReceiver contract.
The message execution will invoke a function call according to the message content, which will either call functions of other contracts, or call the param adjustment functions of the MultiBridgeReceiver itself. Note that the only legit message sender is the trusted dApp contract on the source chain, which means only that single dApp contract has the ability to execute functions calls through the MultiBridgeReceiver contracts on different other chains.
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Destination chain │
│ │
│ ┌───────────────────┐ ┌─────────────────┐ │
│ │ Bridge1 Contracts ├──►│ Bridge1 Adapter ├──┐ │
│ └───────────────────┘ └─────────────────┘ │ │
│ │ │
│ ┌───────────────────┐ ┌─────────────────┐ │receiveMessage()┌─────────────────────┐ call() ┌──────────┐ │
│ │ Bridge1 Contracts ├──►│ Bridge2 Adapter ├──┼───────────────►│ MultiBridgeReceiver ├────────►│ Receiver │ │
│ └───────────────────┘ └─────────────────┘ │ └─────────────────────┘ └──────────┘ │
│ │ │
│ ┌───────────────────┐ ┌─────────────────┐ │ │
│ │ Bridge2 Contracts ├──►│ Bridge3 Adapter ├──┘ │
│ └───────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Below are steps to add a new bridge (e.g. Bridge4) by the dApp community.
sendMessage() call from MultiBridgeSender.receiveMessage() of MultiBridgeReceiver for each valid message.Caller) on the source chain adds the new Bridge4 sender adapter to MultiBridgeSender on the source chain by calling the addSenderAdapters() function of MultiBridgeSender.Caller) on the source chain adds the new Bridge4 receiver adapter to MultiBridgeReceiver on the destination chain by calling the remoteCall() function of MultiBridgeSender, with arguments to call updateReceiverAdapter() of the MultiBridgeReceiver on the destination chain.Updating quorum threshold is similar to configure a new bridge receiver adapter on destination chain. It requires a remoteCall() from the source chain Caller with calldata calling updateQuorumThreshold() of the MultiBridgeReceiver on the destination chain.
Use case: contract A on Goerli send message to contract B on BSC Testnet in order to call enableFeeAmount() for state change. Apply a 2-of-3 messages governance model with message bridge C, D and E.
MultiBridgeSender on Goerli, set address of A as allowed caller.MultiBridgeReceiver on BSC Testnet.SenderAdapter and ReceiverAdapter, named with a prefix of their bridge name. Take preparation of CSenderAdapter and CReceiverAdapter as an example.
CSenderAdapter on Goerli, set address of MultiBridgeSender as multiBridgeSender.CReceiverAdapter on BSC Testnet, set address of MultiBridgeReceiver as multiBridgeReceiver.CSenderAdapter, set address of CReceiverAdapter on BSC Testnet(chain id 97) as a valid ReceiverAdapter.CReceiverAdapter, set address of CSenderAdapter on Goerli(chain id 5) as a valid SenderAdapter.CSenderAdapter and CReceiverAdapter to address(0).MultiBridgeSender with an address array of CSenderAdapter, DSenderAdapter and ESenderAdapter.initialize() of MultiBridgeReceiver, with an address array of CReceiverAdapter, DReceiverAdapter and EReceiverAdapter, and power threshold 2.Prepare a calldata for contract B for calling enableFeeAmount(), then somehow let contract A call remoteCall() of MultiBridgeSender with _dstChainId = 97, _target = <address of contract B> and _callData = <calldata you prepared>.
Imagine that the messages sent via C, D and E received by MultiBridgeReceiver on BSC Testnet in an order of 1.C 2.D 3.E. During receiving message sent via D, accumulated power reaches power threshold 2, which result in message execution(the calldata will be sent to contract B).
We are more than happy to answer any questions, help with tests, collaborate with similar-minded builders like @AlexSmirnov, iterate based on feedbacks and provide audits from community selected firms.
Although Celer, being a 2018-vintage project, does not have the backing of large UNI-holding investors at this moment, we do trust the integrity and intelligence of all the Uniswap delegates to choose this positive-sum path that ensures the highest level of security and service quality for Uniswap's multi-blockchain expansion.
We will update this post with testnet transactions once we worked through the small integration work using @Wormhole .
a16z voted against Proposal 31. We voted this direction for two reasons:
As many others have commented on, the selection of a bridge provider for cross-chain governance messaging should be a comprehensive, structured process that allows for equal comparative analysis between each option. While that didn’t fully occur for this vote, @devinwalsh’s new cross-chain bridge assessment process can help to solve this moving forward. Given the number of possible upcoming bridge deployments, we agree that it’s important to have an independent third party weigh in with their relevant experience and expertise. Consequently, our vote against this proposal is to reset the Binance Uniswap v3 deployment process until the formal assessment is completed.
Second, we do not believe Wormhole offers the most secure or decentralized bridging option. The Wormhole bridge suffered a $326M exploit last year. The bridge then had another critical vulnerability that put all $1.8B TVL at risk. Wormhole has since reduced their maximum bug bounty from $10M to $2.5M. Additionally, the Uniswap DAO will not have the ability to run and control the bridge independently if Wormhole is selected as the provider. We believe this is an equally important factor to consider.
a16z voted against Proposal 31. We voted this direction for two reasons:
As many others have commented on, the selection of a bridge provider for cross-chain governance messaging should be a comprehensive, structured process that allows for equal comparative analysis between each option. While that didn’t fully occur for this vote, @devinwalsh’s new cross-chain bridge assessment process can help to solve this moving forward. Given the number of possible upcoming bridge deployments, we agree that it’s important to have an independent third party weigh in with their relevant experience and expertise. Consequently, our vote against this proposal is to reset the Binance Uniswap v3 deployment process until the formal assessment is completed.
Second, we do not believe Wormhole offers the most secure or decentralized bridging option. The Wormhole bridge suffered a $326M exploit last year. The bridge then had another critical vulnerability that put all $1.8B TVL at risk. Wormhole has since reduced their maximum bug bounty from $10M to $2.5M. Additionally, the Uniswap DAO will not have the ability to run and control the bridge independently if Wormhole is selected as the provider. We believe this is an equally important factor to consider.
As Uniswap token holders, we are ultimately interested in the long-term success of the Uniswap protocol. We hope to see the Binance deployment process restarted so that all bridge providers can participate in a formal assessment process. We will evaluate all bridge providers in good faith and subsequently vote in the best interest of the Uniswap protocol’s future growth and success.
This will be our (Stanford Blockchain) final post here in this thread. More posts revolving around this issue can be found at Cross-Chain Bridge Assessment Process.
We would love to discuss further around other protocols in the thread above.
Hey all, we've (a16z) reviewed the various bridge proposals, evaluated each, and strongly support LayerZero. We're unable to vote in the current Snapshot due to infrastructure limitations with the custodian on short notice, but we will be participating in the on-chain vote when it goes live, in addition to any new Snapshot votes that may come up. We just wanted to put this out before the vote ends tomorrow morning for clarity on the process from our end.
I like the new governance flow, but it is difficult to find the snapshot post/link in this thread. Have to keep scrolling up to find this post, when checking on the vote status.
A suggestion if possible: have a "snapshot is live" button under the thread scroller on the right side where the "reply to thread" and "notifications" buttons are.
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind… The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind… The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
Good news is that it does not actually take months to figure out a multi-bridge solution as there is already one running on testnet that can integrate deBridge, Celer and Wormhole all together. This solution is being audited as we speak.
I was in the Layer Zero camp due to their straightforwardness with technical information and documentation. The risks were presented clearly to me vs the other bridges. However, it is important to expand Uniswap into other ecosystems.
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind.... The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
I was in the Layer Zero camp due to their straightforwardness with technical information and documentation. The risks were presented clearly to me vs the other bridges. However, it is important to expand Uniswap into other ecosystems.
From my understanding, any of the bridges proposed in this forum would be only a temporary solution until a multi bridge solution is figured out. This tooling could take months to figure out. With this in mind.... The important component is getting the liquidity kickstarted on BSC before april; regardless of the temporary bridge.
Clarity on deploying cross-chain with no bridge, and changing the bridge used for a chain
Devin's comments resolved my worries about bridge flexibility. My priorities for this proposal are expanding to BSC first, and the bridge is secondary. Once passed there is time to test out the multi bridge tooling without rushing to simultaneously launch on BSC. Wormhole's history shows that it has been battled tested through failures; and will suit the purpose of a temporary bridge for BSC. My biggest concern with DAO governance is the inability to make actions in a timely manner.
A testnet deployment is done.
Setup:
The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.
A testnet deployment is done.
Setup:
The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.
Test results:
Happy to answer any questions!
It is now quite clear that the initial concern raised by the community about Celer's upgradability contract, which we addressed here and plan to deprecation soon, is absolutely not bigger concerns comparing to many of the issues revealed and discussed in the forum.
It is now quite clear that the initial concern raised by the community about Celer's upgradability contract, which we addressed here and plan to deprecation soon, is absolutely not bigger concerns comparing to many of the issues revealed and discussed in the forum.
While we have a lot to say about the ongoing debates in the forum and CT, we refrain from doing so and instead now deliver a multi-bridge Uniswap governance solution that is vendor-lock-in-free for Uniswap community to consider.
For Uniswap community who has not casted votes yet, please vote for Celer to express your support for this kind of multi-bridge solution.
This solution is strictly better than choosing a single bridge in terms of security and availability. In addition, it also retains the strongest bargaining power in the hands of Uniswap community to always receive the best services. See this for more context.
The implementation combines both Celer and Wormhole and is open-sourced here https://github.com/celer-network/sgn-v2-contracts/blob/multibridge/contracts/message/apps/multibridge/
All other bridges/cross-chain solutions such as LayerZero can be added easily via adapters.
We are setting up a testnet transaction to demonstrate this end-to-end. @Wormhole team we hope that you can help to set up a relayer for this because otherwise the only easy way would be deploying on Avalanche and BSC testnet where Wormhole generic relayers are available to our knowledge. Feel free to DM!
Now let's get to the solution specification.
This is a solution for cross-chain message passing without vendor lock-in and with enhanced security beyond any single bridge. A message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges.
The current solution are designed for messages being sent from one source chain to multiple destination chains. It also requires that there is only one permitted sender on the source chain. This would be the use case for Uniswap governance contract on Ethereum calling remote functions of contracts on other EVM chains.
To send a message to execute a remote call on the destintion chain, sender on the source chain should call remoteCall() of MultiBridgeSender, which invokes sendMessage() of every bridge sender apdater to send messages via different message bridges.
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Source chain │
│ │
│ ┌─────────────────┐ ┌───────────────────┐ │
│ ┌──►│ Bridge1 Adapter ├──►│ Bridge1 Contracts │ │
│ │ └─────────────────┘ └───────────────────┘ │
│ │ │
│ ┌────────┐remoteCall()┌───────────────────┐sendMessage()│ ┌─────────────────┐ ┌───────────────────┐ │
│ │ Caller ├───────────►│ MultiBridgeSender ├─────────────┼──►│ Bridge2 Adapter ├──►│ Bridge2 Contracts │ │
│ └────────┘ └───────────────────┘ │ └─────────────────┘ └───────────────────┘ │
│ │ │
│ │ ┌─────────────────┐ ┌───────────────────┐ │
│ └──►│ Bridge3 Adapter ├──►│ Bridge3 Contracts │ │
│ └─────────────────┘ └───────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────┘
On the destination chain, MultiBridgeReceiver receives messages from every bridge receiver adapter. Each receiver adapter gets encoded message data from its bridge contracts, and then decode the message and call receiveMessage() of MultiBrideReceiver.
MultiBridgeReceiver maintains a map from bridge adapter address to its power. Only adapter with non-zero power has access to receiveMessage() function. If the accumulated power of a message has reached the a threshold, which means enough number of different bridges have delivered a same message, the message will be executed by the MultiBrideReceiver contract.
The message execution will invoke a function call according to the message content, which will either call functions of other contracts, or call the param adjustment functions of the MultiBridgeReceiver itself. Note that the only legit message sender is the trusted dApp contract on the source chain, which means only that single dApp contract has the ability to execute functions calls through the MultiBridgeReceiver contracts on different other chains.
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Destination chain │
│ │
│ ┌───────────────────┐ ┌─────────────────┐ │
│ │ Bridge1 Contracts ├──►│ Bridge1 Adapter ├──┐ │
│ └───────────────────┘ └─────────────────┘ │ │
│ │ │
│ ┌───────────────────┐ ┌─────────────────┐ │receiveMessage()┌─────────────────────┐ call() ┌──────────┐ │
│ │ Bridge1 Contracts ├──►│ Bridge2 Adapter ├──┼───────────────►│ MultiBridgeReceiver ├────────►│ Receiver │ │
│ └───────────────────┘ └─────────────────┘ │ └─────────────────────┘ └──────────┘ │
│ │ │
│ ┌───────────────────┐ ┌─────────────────┐ │ │
│ │ Bridge2 Contracts ├──►│ Bridge3 Adapter ├──┘ │
│ └───────────────────┘ └─────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Below are steps to add a new bridge (e.g. Bridge4) by the dApp community.
sendMessage() call from MultiBridgeSender.receiveMessage() of MultiBridgeReceiver for each valid message.Caller) on the source chain adds the new Bridge4 sender adapter to MultiBridgeSender on the source chain by calling the addSenderAdapters() function of MultiBridgeSender.Caller) on the source chain adds the new Bridge4 receiver adapter to MultiBridgeReceiver on the destination chain by calling the remoteCall() function of MultiBridgeSender, with arguments to call updateReceiverAdapter() of the MultiBridgeReceiver on the destination chain.Updating quorum threshold is similar to configure a new bridge receiver adapter on destination chain. It requires a remoteCall() from the source chain Caller with calldata calling updateQuorumThreshold() of the MultiBridgeReceiver on the destination chain.
Use case: contract A on Goerli send message to contract B on BSC Testnet in order to call enableFeeAmount() for state change. Apply a 2-of-3 messages governance model with message bridge C, D and E.
MultiBridgeSender on Goerli, set address of A as allowed caller.MultiBridgeReceiver on BSC Testnet.SenderAdapter and ReceiverAdapter, named with a prefix of their bridge name. Take preparation of CSenderAdapter and CReceiverAdapter as an example.
CSenderAdapter on Goerli, set address of MultiBridgeSender as multiBridgeSender.CReceiverAdapter on BSC Testnet, set address of MultiBridgeReceiver as multiBridgeReceiver.CSenderAdapter, set address of CReceiverAdapter on BSC Testnet(chain id 97) as a valid ReceiverAdapter.CReceiverAdapter, set address of CSenderAdapter on Goerli(chain id 5) as a valid SenderAdapter.CSenderAdapter and CReceiverAdapter to address(0).MultiBridgeSender with an address array of CSenderAdapter, DSenderAdapter and ESenderAdapter.initialize() of MultiBridgeReceiver, with an address array of CReceiverAdapter, DReceiverAdapter and EReceiverAdapter, and power threshold 2.Prepare a calldata for contract B for calling enableFeeAmount(), then somehow let contract A call remoteCall() of MultiBridgeSender with _dstChainId = 97, _target = <address of contract B> and _callData = <calldata you prepared>.
Imagine that the messages sent via C, D and E received by MultiBridgeReceiver on BSC Testnet in an order of 1.C 2.D 3.E. During receiving message sent via D, accumulated power reaches power threshold 2, which result in message execution(the calldata will be sent to contract B).
We are more than happy to answer any questions, help with tests, collaborate with similar-minded builders like @AlexSmirnov, iterate based on feedbacks and provide audits from community selected firms.
Although Celer, being a 2018-vintage project, does not have the backing of large UNI-holding investors at this moment, we do trust the integrity and intelligence of all the Uniswap delegates to choose this positive-sum path that ensures the highest level of security and service quality for Uniswap's multi-blockchain expansion.
We will update this post with testnet transactions once we worked through the small integration work using @Wormhole .
a16z voted against Proposal 31. We voted this direction for two reasons:
As many others have commented on, the selection of a bridge provider for cross-chain governance messaging should be a comprehensive, structured process that allows for equal comparative analysis between each option. While that didn’t fully occur for this vote, @devinwalsh’s new cross-chain bridge assessment process can help to solve this moving forward. Given the number of possible upcoming bridge deployments, we agree that it’s important to have an independent third party weigh in with their relevant experience and expertise. Consequently, our vote against this proposal is to reset the Binance Uniswap v3 deployment process until the formal assessment is completed.
Second, we do not believe Wormhole offers the most secure or decentralized bridging option. The Wormhole bridge suffered a $326M exploit last year. The bridge then had another critical vulnerability that put all $1.8B TVL at risk. Wormhole has since reduced their maximum bug bounty from $10M to $2.5M. Additionally, the Uniswap DAO will not have the ability to run and control the bridge independently if Wormhole is selected as the provider. We believe this is an equally important factor to consider.
a16z voted against Proposal 31. We voted this direction for two reasons:
As many others have commented on, the selection of a bridge provider for cross-chain governance messaging should be a comprehensive, structured process that allows for equal comparative analysis between each option. While that didn’t fully occur for this vote, @devinwalsh’s new cross-chain bridge assessment process can help to solve this moving forward. Given the number of possible upcoming bridge deployments, we agree that it’s important to have an independent third party weigh in with their relevant experience and expertise. Consequently, our vote against this proposal is to reset the Binance Uniswap v3 deployment process until the formal assessment is completed.
Second, we do not believe Wormhole offers the most secure or decentralized bridging option. The Wormhole bridge suffered a $326M exploit last year. The bridge then had another critical vulnerability that put all $1.8B TVL at risk. Wormhole has since reduced their maximum bug bounty from $10M to $2.5M. Additionally, the Uniswap DAO will not have the ability to run and control the bridge independently if Wormhole is selected as the provider. We believe this is an equally important factor to consider.
As Uniswap token holders, we are ultimately interested in the long-term success of the Uniswap protocol. We hope to see the Binance deployment process restarted so that all bridge providers can participate in a formal assessment process. We will evaluate all bridge providers in good faith and subsequently vote in the best interest of the Uniswap protocol’s future growth and success.
This will be our (Stanford Blockchain) final post here in this thread. More posts revolving around this issue can be found at Cross-Chain Bridge Assessment Process.
We would love to discuss further around other protocols in the thread above.
Hey all, we've (a16z) reviewed the various bridge proposals, evaluated each, and strongly support LayerZero. We're unable to vote in the current Snapshot due to infrastructure limitations with the custodian on short notice, but we will be participating in the on-chain vote when it goes live, in addition to any new Snapshot votes that may come up. We just wanted to put this out before the vote ends tomorrow morning for clarity on the process from our end.
I like the new governance flow, but it is difficult to find the snapshot post/link in this thread. Have to keep scrolling up to find this post, when checking on the vote status.
A suggestion if possible: have a "snapshot is live" button under the thread scroller on the right side where the "reply to thread" and "notifications" buttons are.
This will be our (Stanford Blockchain) final post here in this thread. More posts revolving around this issue can be found at Cross-Chain Bridge Assessment Process.
We would love to discuss further around other protocols in the thread above.
First at foremost, we enjoyed chatting with different bridge providers and their advocates. We believe as contentious as this vote is, this will not be the end for the cross-chain (x-chain for shorthand) governance discussion but the beginning.
We believe regardless of who will win the vote, this result should be temporary and should be immediately changed/updated when the Cross-Chain Bridge Assessment Process concludes. Our vote only convenes that we support the following protocol for a period of fewer than three months. In long term we believe Multi-Message-Aggregation (MMA) is the solution.
We have voted for LZ as the current preferred bridge provider. However, our vote is contingent on a few criteria. If LZ cannot fulfill these criteria, we wish to withdraw our support.
If LZ fails to deliver on ANY of the criteria above, Stanford Blockchain Club will NOT support LZ being the bridge provider for Uniswap governance.
We want to say that although the current snapshot will only have one "winner," it does not mean the work other bridge providers did is wasted. In the next three weeks (laid out in the Cross-Chain Bridge Assessment Process), we would love to continue these conversations and find a long-term and more sustainable solution for x-chain governance.
As we have briefly mentioned in our previous posts (1,2), none of these solutions fits all our requirement and all of them poses serious governance risk to Uniswap; therefore we should not just decide once and move on from this issue. Instead, we should take UF's proposal seriously and contribute more if not less time and energy to it.
Some key risks: Both WH and LZ's oracle/relayer networks lack a slashing mechanism for malicious oracles. WH's contract can be upgraded (can be patched with workarounds). LZ's relayer is currently just LZ's core team.
At Stanford Blockchain Club, we understand the difficulties of building bridges and more importantly, the current security gap between any bridge and the Ethereum network. We also recognize how early bridging technologies are and the security assumptions for these bridges might be drastically different from traditional blockchains.
We are not making statements about future designs of these bridges or what they could be; we are stating what we are seeing right now.
LZ and WH on a high level are both multisig bridges. WH is a 1/1 multisig, with the 1 being 19 validators forming a 13/19 multisig. LZ is a 2/2 multisig, with 1 being 5 Uniswap members, and the other 1 being LayerZero Lab.
If Ethereum's current security level is 100, what would you assign to LZ and WH?
Therefore, we would not choose either of them to be the sole message-relaying solution for Uniswap long term. However given we have to make a decision now, we believe the LZ solution is the marginally better one.
From our conversation with bridge providers and other delegates, we believe this is the most logical next step for x-chain governance in Uniswap.
We have proposed an in-depth design on the other thread, but this graph captures it well.
The governance flow is as follows:
dst, BSC in this case.Message Selection Contract.multisig decides which message payload to execute.Security analysis and design trade-offs are discussed more in the post.
Thank you for posting this updated proposal, LayerZero.
We believe this proposal addresses a lot of the questions we have raised before. And their ability to change Chainlink with a set of Uniswap-aligned oracle validators is very promising.
For total transparency, LayerZero reached out to us and addressed most of our technical concerns.
Thank you for posting this updated proposal, LayerZero.
We believe this proposal addresses a lot of the questions we have raised before. And their ability to change Chainlink with a set of Uniswap-aligned oracle validators is very promising.
For total transparency, LayerZero reached out to us and addressed most of our technical concerns.
One thing we believe we undervalued, in our initial assessment, is the immutability of the bridge. Many hacks happen because of simple upgrades. Under LayerZero's design, the underlying infrastructure (LayerZero protocol) is immutable. The changeable parts, the Oracle (header sync) and Relayer (MIP), can only be changed by Uniswap governance.
Given the immutability and LayerZero's new proposed Oracle, we would like to signal to the community that we have tentatively moved LayerZero as our preferred bridge provider for BNB.
We would also love to see more documentation provided from LayerZero's side, especially around the oracle and relayer services.
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
Thank you Blockchain at Berkeley team. As promised, we will be providing a reference implementation very soon for this. The difficulty level of implementing a multi-bridge solution is not really harder than implementing a single-bridge solution.
Hey everyone,
Porter and Guy writing from a16z. Given the expiration of Uniswap V3’s BUSL license in early April, we’re generally in favor of deploying Uni V3 to other chains before that date to avoid the copy-paste rush that will likely ensue otherwise. This has the added benefit of ensuring there’s an official deployment cycle so users on those chains can trust they’re using the original code base – preempting possible bad actors or just carelessness. Deploying Uni V3 obviously won’t forestall forks from occurring, but at least it offers an official version to users seeking that forum.
Hey everyone,
Porter and Guy writing from a16z. Given the expiration of Uniswap V3’s BUSL license in early April, we’re generally in favor of deploying Uni V3 to other chains before that date to avoid the copy-paste rush that will likely ensue otherwise. This has the added benefit of ensuring there’s an official deployment cycle so users on those chains can trust they’re using the original code base – preempting possible bad actors or just carelessness. Deploying Uni V3 obviously won’t forestall forks from occurring, but at least it offers an official version to users seeking that forum.
Additionally, as @devinwalsh’s comments suggest, we would also be in favor of a more formal process for choosing third party service providers or integrations for Uniswap going forward.
In our eyes, it’s important that Uniswap is able to create a level, objective playing field for all parties wanting to build or aid in its development. The community remains the ultimate decider once those conditions are set, but it’s key to foster a structured process that enables outside parties to fairly compete on the merits of their proposal. Like anything else, this competition benefits Uniswap long-term as a credibly neutral, market-based platform. It should receive the best services, at the best prices (if pricing is included) by choosing from the widest selection of parties given the same set of operating instructions. A structured process allows time for appropriate due diligence, weighing of pros and cons for each provider, and a comparative analysis that is difficult to conduct otherwise.
For transparency and timing, and because an end-to-end process has not fully occurred for this particular vote, the second part of this post outlines our preferred choice for Uniswap’s bridge provider.
To that end, we believe that LayerZero offers the best bridging solution – for transparency, we invested in them. We believe they are the most secure, decentralized, and philosophically aligned partner for Uniswap. Full investment disclosures can be found here. You can read our original investment thesis here for historical context.
LayerZero uniquely offers the capability for Uniswap to own its own immutable smart contract, while also enabling Uniswap to change or upgrade the security model of the bridge at the community’s discretion in the future. They’ve also delivered: LayerZero built out an omnichain governance module for Uniswap, found here.
Our support in LayerZero’s offering stems from its:
(1) Immutability - Uniswap can deploy LayerZero’s contracts and own them without having a dependency on LayerZero. Other bridge deployments can be changed by the bridging provider, but Uniswap could choose to be the only one with the capability of upgrading its bridge.
(2) Open and permissionless nature - LayerZero is open source, modular, and ownable by the applications that integrate it. Please see LayerZero’s implementation for a Uniswap governance executor open source here. Uniswap can future proof its deployment by choosing the oracle, relayer, validation library, and blockchain confirmation parameters in its deployment.
(3) Creation of extendible immutable validation libraries - LayerZero is building multiple validation libraries and provides the most modular bridging architecture we’ve seen. Uniswap could choose to implement a new validation library (a ZK light client for example) when it becomes battle tested. Importantly, this upgrade could only be done by Uniswap itself. LayerZero enables Uniswap to own and run its own bridge.
To highlight a critical point, LayerZero alone offers the ability for Uniswap to run its own Oracle or Relayer network using the LayerZero architecture, providing the most secure and modular message delivery system because Uniswap itself is participating in its execution. If the Uniswap community sets its oracle, relayer, validation library, and block confirmations in the endpoint settings, there is nothing anyone else can do to change it – it is immutable and only in the hands of the Uniswap community. This embeds flexibility to also take advantage of future cryptographically secure validation layers.
Others have brought up the core concern of security considerations. To date, LayerZero has processed over $5B in transactions with over 700 applications deploying 2,000 contracts without a single hack. Other bridge providers cannot point to this track record. Past performance is not an absolute guarantee of future success, but it is a strong indicator. To @GFXlabs’ first evaluation criteria, “How long has the system been running, and how much value has it been responsible for?” In our opinion, LayerZero has a demonstrated track record of success at scale that is unique amongst bridge providers.
In this vein, cross-chain Uniswap deployments should not compromise the decentralization of the protocol unduly, or introduce unnecessary risk without careful consideration. We do not believe that arbitrarily upgradable contracts owned by the underlying bridging provider or controlled by an external third party are in line with the ethos of community-centric, decentralized governance. LayerZero offers a credible alternative to that reality for the Uniswap community.
While we currently believe LayerZero is the best option, we will evaluate any other proposals in good faith and ultimately vote for what we think is best for Uniswap.
We appreciate everyone’s time and consideration.
@GFXlabs team, thank you very much for your replies. We want to summarize and supplement some of our answers to your questions.
@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.
Separately, to address your latest post, “A Vender-lock-in-free Universal Governance Mechanism,” this forum thread is only regarding the BSC deployment.
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 should not lock in one vendor when the possibility of choosing multiple exists.
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.
The steps laid out here provide a promising path forward for a successful deployment on BNB sc & future cross-chain deployments.
Special thanks to all the community members who brought research to the forum to aid in the DAO decision-making process. Especially the efforts of @GFXlabs, who worked diligently to review and test various providers.
The steps laid out here provide a promising path forward for a successful deployment on BNB sc & future cross-chain deployments.
Special thanks to all the community members who brought research to the forum to aid in the DAO decision-making process. Especially the efforts of @GFXlabs, who worked diligently to review and test various providers.
Regarding future work into bridge diligence, we commend @devinwalsh and the Foundation's efforts and will assist wherever possible.
In this sub-proposal, we present a vendor-lock-in-free Universal Governance Mechanism (UGM) for Uniswap that utilizes multiple cross-chain protocols simultaneously. This architecture significantly enhances the security of Uniswap UGM and, at the same time, eliminates any potential alignment risks down the road.
In this sub-proposal, we present a vendor-lock-in-free Universal Governance Mechanism (UGM) for Uniswap that utilizes multiple cross-chain protocols simultaneously. This architecture significantly enhances the security of Uniswap UGM and, at the same time, eliminates any potential alignment risks down the road.
While we believe that Celer alone can effectively solve the Uniswap UGM use case, as a long-time advocate for open protocols, we propose this solution with the best interest of the Uniswap community in mind.
It may seem that Uniswap's delegates and community must make a choice to select a single cross-chain messaging protocol for Uniswap's multi-blockchain expansion.
However, if we go down this path, it will be a TRAGIC day for Uniswap community because Uniswap, the most open dex in the world, will be vendor-lock-in to a single cross-chain protocol.
Vendor lock-in carries a multitude of risks, most notably:
But are we asking the right question?
Does Uniswap have to choose one single solution between different ones or can it utilize multiple solutions to achieve a better outcome for the community?
Cross-chain governance use cases have the following properties:
With these properties, it is a perfect use case to utilize multiple cross-chain messaging solutions simultaneously.
We propose utilizing multiple cross-chain solutions simultaneously through the use of a "MessageProcessor" contract that acts as the executor for UGM calls to Uniswap contracts on the Binance Chain. This contract would have the following functionalities:
This architecture ensures that even if a single bridge is compromised, Uniswap's governance process remains intact. Additionally, the Uniswap community can continuously evaluate participating cross-chain protocols with all bargaining power on their side.
We believe this architecture should be implemented to avoid vendor lock-ins, even if the Uniswap community decides to use a single cross-chain solution for now. Celer is committed to a vendor-lock-in-free future and is more than happy to implement this vendor-lock-in-free UGM for Uniswap.
I appreciate all the information about the different bridge solutions. I am not familiar with bridges or the security vulnerablilities. I have only heard of the Wormhole bridge from it's $320 million bridge exploit.
How would an exploit like this impact Uniswap on BSC? Would all LP's be vulerable?
I appreciate all the information about the different bridge solutions. I am not familiar with bridges or the security vulnerablilities. I have only heard of the Wormhole bridge from it's $320 million bridge exploit.
How would an exploit like this impact Uniswap on BSC? Would all LP's be vulerable?
Is the $320 million that was exploited still an issue that could impact protocols using Wormhole's bridge solution in the future?
@modong what are the risks related to validator's using Celer native token as stake to be slashed?
If Celer token prices get low enough, could there be malicious actor's/validator's that see more opportunity in the value of the bridge assets vs being slashed in Celer?
Would be good to have a combination of bridges, but due to my unfamilarity in this area I am unsure what is possible.
Hi GFX Labs team,
Just a gentle reminder that we have replied to all of your concerns. Since you have done an evaluation of multiple solutions using the criteria you mentioned and are now championing one single solution, could you please post the evaluation matrix with facts for all the criteria?
Hi GFX Labs team,
Just a gentle reminder that we have replied to all of your concerns. Since you have done an evaluation of multiple solutions using the criteria you mentioned and are now championing one single solution, could you please post the evaluation matrix with facts for all the criteria?
With this, different solution providers can clarify if needed, and the Uniswap community and delegates can do a peer review and make informed decisions. Many community members and delegates may reach different conclusions by looking at all the facts.
In addition, we would add the following criteria to the evaluation matrix:
However, we feel that we may be having the wrong discussion here. Cross-chain governance is a unique use case and it can be built as a vendor-lock-in-free architecture where multiple cross-chain solutions can co-exist to serve Uniswap with super-charged security properties.
Hi Wormhole team,
While we are looking at the 2M message per day stats you stated, we noticed that 99.97% of those messages are from a network called Pythnet. If we exclude Pythnet, there are 719 message per day in the last 7 days on Wormhole. To put it into perspective, Celer processes 1958 messages per day during the same period of time.
Hi Wormhole team,
While we are looking at the 2M message per day stats you stated, we noticed that 99.97% of those messages are from a network called Pythnet. If we exclude Pythnet, there are 719 message per day in the last 7 days on Wormhole. To put it into perspective, Celer processes 1958 messages per day during the same period of time.
In addition, we could not find any contract address deployed on Pythnet based on your documentation section describing contracts deployed on supported networks.
With the lack of information and significantly skewed volume, could you please elaborate on the Pythnet use case so everyone in the Uniswap community has a clear understanding on the usage level of Wormhole?
With 2M messages processed per day, one would imagine that there are a lot of unique wallet addresses interacting with Wormhole. Could you please share that data too? This way we can have a more complete comparison.
Hey Alex, thank you for your comments. Always great to have discussions with fellow builders in the space. Here are some quick replies:
Hey Alex, thank you for your comments. Always great to have discussions with fellow builders in the space. Here are some quick replies:
When we say L1-PoS-blockchain security model, we mean that the consensus algorithm is essentially acting like any other PoS blockchain. The closest in terms of consensus algorithm/mechanism is Cosmos-SDK/Tendermint chains such as Polygon PoS, BNB Chain or Sei Network. This is to stress that Celer uses a time-tested consensus engine and economic security engine, unlike some other multi-sig solutions or solutions with untested economic security models. We are not saying in any way that Celer's shares the exact same PoS setup with any other blockchain.
Unfortunately, you are not correct in stating that if the PoS consensus fails (2/3 stake colluding to behave maliciously), all liquidity in Celer's Bridge can be withdrawn. This is precisely where the model of optimistic rollup-like security model shines. cBridge is built with this model from day 1 and even if the majority stake is acting maliciously, large fund withdrawing (in a cumulative sense) transactions can be canceled by any Celer validator plus a group of app guardians from security firms such as Peckshield and others. So what you described won't happen. From a more practical point of view, Celer validators are highly reputable validators from the Cosmos community and incidentally share many with deBridge we believe.
Implementing an optimistic rollup security model can be done in the application domain and in the protocol at the same time. They are not mutually exclusive. For Celer, every single validator can cancel messages that are maliciously passed by the consensus protocol if the message is sent through an OR model. This enhances the security from trust majority to trust-any validators.
In addition, application builders, governance bodies or security firms independent from application builders can run app guardians for specific applications even if they don't trust any validators in Celer. For example, Certik, Trial of Bits and other security firms that are independent of both Celer and application builders can run app guardians for applications to offer "external security firms certified" services. The architecture is highly flexible with a high level of redundancy.
Kydo from Stanford Blockchain here. We would love to chime in on the bridging part of this discussion.
Message passing is hard. So please do not take the rest of this as criticism.
Kydo from Stanford Blockchain here. We would love to chime in on the bridging part of this discussion.
Message passing is hard. So please do not take the rest of this as criticism.
No amount of dollars can help you forge a digital signature. So, we believe in the future, when cryptographically-secured message passing exists, Uniswap should heavily prioritize it (not choosing it straightaway since the complexity could also increase attack surfaces).
Does required stake/slash make it significantly unprofitable to exploit bridge
This is an important question to answer explicitly with data (this behavior -> this slash amount, etc). Moreover, we would add that the provider should lay out how to become a validator in the network. This demonstrates how easy it is to collude across your validator set.
We should not lock in one vendor when the possibility of choosing multiple exists.
The recency of the audits is very important. These unaudited features, especially the delay mechanism, should not be implemented by Uniswap before a formal audit is complete.
Does their documentation clearly explain how their system works, not just in concept but, most importantly, in execution?
Moreover, if your system requires honest interactions with external third parties, you should clearly explain how the external third parties work or link to their technical documentation (in another thread).
We believe the best way forward, especially after the Nomad hack, is to use multiple bridge providers for message passing. We do not believe this is theoretically hard but would require significant engineering hours. We would love to see more discussion surrounding this topic.
We do not have the expertise to analyze the actual implementations and understand the complexity levels of each codebase; so we made our decision based on the assumption that all these implementations (up to the most recent audit) are equally secure/insecure.
Our ranking is subject to change, based on answers provided by the service providers.
Our tentative ranking is as follows:
To us, all these providers pose significant risks (relative to native L2 bridges or light client bridges). So, the ranking should not be taken at face value that any provider is "better" than another. Note: we are talking about using this for governance instead of a simple bridge transfer. So the evaluation criteria are a lot stricter.
We ranked wormhole as number 1 because of its diverse validator set. However, we would love to understand how does Wormhole penalize malicious validators? Does Wormhole have legally binding agreements with each validator? If so, what actions can Wormhole pursue?
We ranked Celer and LayerZero second. Celer has a decently sized validator set but the economic guarantee behind them is much weaker. I do not see that being a fixable problem, therefore I placed them (Celer) second.
LayerZero depends heavily on Chainlink's oracle relay service. However, I was not able to find any information with regard to Chainlink's implementation on their documentation or your website. Can you share more with regard to how does this specific chainlink oracle work? And if it is similar to Chainlink's price feed, who are the multisig signers (providers) for it? With regard to the relayer, other than LayerZero, is there any other entity running a relayer? If Uniswap wants to run our own relayer, can LayerZero commit human capital to assist us in running it?
We believe the best course forward is the Multi-Provider-Aggregation method. I would love to hear thoughts from other technical delegates on the difficulties of the design and a potential timeline.
If the above method is infeasible, I would recommend using Wormhole at this point. However, BNB Uniswap should have the ability to switch the message-passing provider at a later date through governance.
We hope @devinwalsh could open a new thread specifically for x-chain messaging outside this one since this discussion is going to be important for future and past x-chain developments.
Edit 2: Add clarification around ranking.
GFX Labs team, thank you again for your questions. We would love to provide some responses to your questions.
GFX Labs team, thank you again for your questions. We would love to provide some responses to your questions.
First, we would like to elaborate a bit on our security audits and track records. We respect that different people may have different opinions about security firms, but we believe that both Peckshield and Slowmist are well-regarded security audit firms. Peckshield, in particular, has been consistently the first to report many security incidents and coordinate major security investigations with top security researchers and firms such as banteg, samczsun, and others. If you have any specific concerns about the quality of these firms, we would be happy to relay them and invite these firms to answer or clarify.
Regarding the audit dates, we built Celer's system in such a way that our optimistic rollup-like security model can be securely and easily added to dApps as a design pattern. The capability to do so has been available before Feb 2022, and we only began talking about it proactively later when we realized that some teams were marketing it as a unique feature.
In addition to security audits, Celer also has a standing $2M bug bounty on ImmuneFi since November 2021, which has not been claimed yet.
In terms of our security track record, Celer's cross-chain system is the ONLY ONE that has processed a meaningfully large volume (bigger than $1 billion in asset bridging volume) without any critical security issues being reported or exploited. Additionally, throughout Celer's development history since 2018, none of the systems or products built by Celer, including the world's first Generalized State Channel Network, have been exploited in any way. Celer has a security operation team that is active 24/7 to monitor the public blockchain transactions for any anomalies related to Celer's systems and respond to any reports from security firms and independent security researchers with a 3-minute SLA. Of course, we know blockchain is a dark forest and our flawless record does not automatically guarantee future security, but we hope that the information provided gives you more confidence from a comparative perspective.
The security model of the optimistic rollup-like system has two components: 1) a two-phase commit pattern in the smart contract, and 2) an off-chain App Guardian that can halt the execution of a message during the delay between commit and confirmation.
We would be happy to explain this in more detail using the DelayedTransfer example you mentioned. DelayedTransfer is related to the optimistic-rollup-like security model used in cBridge, an asset bridge built on the Celer Network. When an asset bridge transaction is initiated and the message is relayed to the destination chain, the message is placed in a DelayedTransfer queue on the destination chain, where it must wait a set delay before funds are released with a confirm transaction.
During this delay, an App Guardian cross-checks the source chain to verify the presence of a corresponding bridge transaction. If a match is found, the App Guardian takes no action and the confirm transaction is executed as normal. However, if a matching transaction is not found (indicating a problem with the bridge), the App Guardian can halt the asset bridge smart contract, preventing any malicious transactions from executing and safeguarding funds. The App Guardian is operated by every validator of SGN and can also be run by additional parties, such as the Uniswap foundation, for their own dApps.
The above security model will be applied to Uniswap's governance use case. We hope this explanation has provided clarity, but we are available for further discussion via a call or in a Twitter space.
We have recently taken down some of the documentation and reference implementation for the dApp side of the optimistic-rollup-like security model, in order to make it more adaptable for various application use cases. We will follow up with links to the updated documentation and App Guardian repositories within the next two days.
You are correct in noting that the MessageBus contract is upgradeable through a governance multisig. Our governance process involves a community voting process, and the execution of governance decisions for on-chain contract upgrades is carried out by a subset of validators including InfStone, Binance Staking, OKEX and Celer Foundation.
We made the MessageBus upgradeable with the goal of making it easier to address any potential security issues just in case and add must-have features. However, we approach this process with care and continually evaluate and improve our governance process. We welcome additional active contributors such as GFXLabs to be more involved.
We hope the above clarifies the concerns to some degree and we are always happy to answer any further questions!
This will be our (Stanford Blockchain) final post here in this thread. More posts revolving around this issue can be found at Cross-Chain Bridge Assessment Process.
We would love to discuss further around other protocols in the thread above.
First at foremost, we enjoyed chatting with different bridge providers and their advocates. We believe as contentious as this vote is, this will not be the end for the cross-chain (x-chain for shorthand) governance discussion but the beginning.
We believe regardless of who will win the vote, this result should be temporary and should be immediately changed/updated when the Cross-Chain Bridge Assessment Process concludes. Our vote only convenes that we support the following protocol for a period of fewer than three months. In long term we believe Multi-Message-Aggregation (MMA) is the solution.
We have voted for LZ as the current preferred bridge provider. However, our vote is contingent on a few criteria. If LZ cannot fulfill these criteria, we wish to withdraw our support.
If LZ fails to deliver on ANY of the criteria above, Stanford Blockchain Club will NOT support LZ being the bridge provider for Uniswap governance.
We want to say that although the current snapshot will only have one "winner," it does not mean the work other bridge providers did is wasted. In the next three weeks (laid out in the Cross-Chain Bridge Assessment Process), we would love to continue these conversations and find a long-term and more sustainable solution for x-chain governance.
As we have briefly mentioned in our previous posts (1,2), none of these solutions fits all our requirement and all of them poses serious governance risk to Uniswap; therefore we should not just decide once and move on from this issue. Instead, we should take UF's proposal seriously and contribute more if not less time and energy to it.
Some key risks: Both WH and LZ's oracle/relayer networks lack a slashing mechanism for malicious oracles. WH's contract can be upgraded (can be patched with workarounds). LZ's relayer is currently just LZ's core team.
At Stanford Blockchain Club, we understand the difficulties of building bridges and more importantly, the current security gap between any bridge and the Ethereum network. We also recognize how early bridging technologies are and the security assumptions for these bridges might be drastically different from traditional blockchains.
We are not making statements about future designs of these bridges or what they could be; we are stating what we are seeing right now.
LZ and WH on a high level are both multisig bridges. WH is a 1/1 multisig, with the 1 being 19 validators forming a 13/19 multisig. LZ is a 2/2 multisig, with 1 being 5 Uniswap members, and the other 1 being LayerZero Lab.
If Ethereum's current security level is 100, what would you assign to LZ and WH?
Therefore, we would not choose either of them to be the sole message-relaying solution for Uniswap long term. However given we have to make a decision now, we believe the LZ solution is the marginally better one.
From our conversation with bridge providers and other delegates, we believe this is the most logical next step for x-chain governance in Uniswap.
We have proposed an in-depth design on the other thread, but this graph captures it well.
The governance flow is as follows:
dst, BSC in this case.Message Selection Contract.multisig decides which message payload to execute.Security analysis and design trade-offs are discussed more in the post.
Thank you for posting this updated proposal, LayerZero.
We believe this proposal addresses a lot of the questions we have raised before. And their ability to change Chainlink with a set of Uniswap-aligned oracle validators is very promising.
For total transparency, LayerZero reached out to us and addressed most of our technical concerns.
Thank you for posting this updated proposal, LayerZero.
We believe this proposal addresses a lot of the questions we have raised before. And their ability to change Chainlink with a set of Uniswap-aligned oracle validators is very promising.
For total transparency, LayerZero reached out to us and addressed most of our technical concerns.
One thing we believe we undervalued, in our initial assessment, is the immutability of the bridge. Many hacks happen because of simple upgrades. Under LayerZero's design, the underlying infrastructure (LayerZero protocol) is immutable. The changeable parts, the Oracle (header sync) and Relayer (MIP), can only be changed by Uniswap governance.
Given the immutability and LayerZero's new proposed Oracle, we would like to signal to the community that we have tentatively moved LayerZero as our preferred bridge provider for BNB.
We would also love to see more documentation provided from LayerZero's side, especially around the oracle and relayer services.
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.
Thank you Blockchain at Berkeley team. As promised, we will be providing a reference implementation very soon for this. The difficulty level of implementing a multi-bridge solution is not really harder than implementing a single-bridge solution.
Hey everyone,
Porter and Guy writing from a16z. Given the expiration of Uniswap V3’s BUSL license in early April, we’re generally in favor of deploying Uni V3 to other chains before that date to avoid the copy-paste rush that will likely ensue otherwise. This has the added benefit of ensuring there’s an official deployment cycle so users on those chains can trust they’re using the original code base – preempting possible bad actors or just carelessness. Deploying Uni V3 obviously won’t forestall forks from occurring, but at least it offers an official version to users seeking that forum.
Hey everyone,
Porter and Guy writing from a16z. Given the expiration of Uniswap V3’s BUSL license in early April, we’re generally in favor of deploying Uni V3 to other chains before that date to avoid the copy-paste rush that will likely ensue otherwise. This has the added benefit of ensuring there’s an official deployment cycle so users on those chains can trust they’re using the original code base – preempting possible bad actors or just carelessness. Deploying Uni V3 obviously won’t forestall forks from occurring, but at least it offers an official version to users seeking that forum.
Additionally, as @devinwalsh’s comments suggest, we would also be in favor of a more formal process for choosing third party service providers or integrations for Uniswap going forward.
In our eyes, it’s important that Uniswap is able to create a level, objective playing field for all parties wanting to build or aid in its development. The community remains the ultimate decider once those conditions are set, but it’s key to foster a structured process that enables outside parties to fairly compete on the merits of their proposal. Like anything else, this competition benefits Uniswap long-term as a credibly neutral, market-based platform. It should receive the best services, at the best prices (if pricing is included) by choosing from the widest selection of parties given the same set of operating instructions. A structured process allows time for appropriate due diligence, weighing of pros and cons for each provider, and a comparative analysis that is difficult to conduct otherwise.
For transparency and timing, and because an end-to-end process has not fully occurred for this particular vote, the second part of this post outlines our preferred choice for Uniswap’s bridge provider.
To that end, we believe that LayerZero offers the best bridging solution – for transparency, we invested in them. We believe they are the most secure, decentralized, and philosophically aligned partner for Uniswap. Full investment disclosures can be found here. You can read our original investment thesis here for historical context.
LayerZero uniquely offers the capability for Uniswap to own its own immutable smart contract, while also enabling Uniswap to change or upgrade the security model of the bridge at the community’s discretion in the future. They’ve also delivered: LayerZero built out an omnichain governance module for Uniswap, found here.
Our support in LayerZero’s offering stems from its:
(1) Immutability - Uniswap can deploy LayerZero’s contracts and own them without having a dependency on LayerZero. Other bridge deployments can be changed by the bridging provider, but Uniswap could choose to be the only one with the capability of upgrading its bridge.
(2) Open and permissionless nature - LayerZero is open source, modular, and ownable by the applications that integrate it. Please see LayerZero’s implementation for a Uniswap governance executor open source here. Uniswap can future proof its deployment by choosing the oracle, relayer, validation library, and blockchain confirmation parameters in its deployment.
(3) Creation of extendible immutable validation libraries - LayerZero is building multiple validation libraries and provides the most modular bridging architecture we’ve seen. Uniswap could choose to implement a new validation library (a ZK light client for example) when it becomes battle tested. Importantly, this upgrade could only be done by Uniswap itself. LayerZero enables Uniswap to own and run its own bridge.
To highlight a critical point, LayerZero alone offers the ability for Uniswap to run its own Oracle or Relayer network using the LayerZero architecture, providing the most secure and modular message delivery system because Uniswap itself is participating in its execution. If the Uniswap community sets its oracle, relayer, validation library, and block confirmations in the endpoint settings, there is nothing anyone else can do to change it – it is immutable and only in the hands of the Uniswap community. This embeds flexibility to also take advantage of future cryptographically secure validation layers.
Others have brought up the core concern of security considerations. To date, LayerZero has processed over $5B in transactions with over 700 applications deploying 2,000 contracts without a single hack. Other bridge providers cannot point to this track record. Past performance is not an absolute guarantee of future success, but it is a strong indicator. To @GFXlabs’ first evaluation criteria, “How long has the system been running, and how much value has it been responsible for?” In our opinion, LayerZero has a demonstrated track record of success at scale that is unique amongst bridge providers.
In this vein, cross-chain Uniswap deployments should not compromise the decentralization of the protocol unduly, or introduce unnecessary risk without careful consideration. We do not believe that arbitrarily upgradable contracts owned by the underlying bridging provider or controlled by an external third party are in line with the ethos of community-centric, decentralized governance. LayerZero offers a credible alternative to that reality for the Uniswap community.
While we currently believe LayerZero is the best option, we will evaluate any other proposals in good faith and ultimately vote for what we think is best for Uniswap.
We appreciate everyone’s time and consideration.
@GFXlabs team, thank you very much for your replies. We want to summarize and supplement some of our answers to your questions.
@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.
Separately, to address your latest post, “A Vender-lock-in-free Universal Governance Mechanism,” this forum thread is only regarding the BSC deployment.
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 should not lock in one vendor when the possibility of choosing multiple exists.
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.
The steps laid out here provide a promising path forward for a successful deployment on BNB sc & future cross-chain deployments.
Special thanks to all the community members who brought research to the forum to aid in the DAO decision-making process. Especially the efforts of @GFXlabs, who worked diligently to review and test various providers.
The steps laid out here provide a promising path forward for a successful deployment on BNB sc & future cross-chain deployments.
Special thanks to all the community members who brought research to the forum to aid in the DAO decision-making process. Especially the efforts of @GFXlabs, who worked diligently to review and test various providers.
Regarding future work into bridge diligence, we commend @devinwalsh and the Foundation's efforts and will assist wherever possible.
In this sub-proposal, we present a vendor-lock-in-free Universal Governance Mechanism (UGM) for Uniswap that utilizes multiple cross-chain protocols simultaneously. This architecture significantly enhances the security of Uniswap UGM and, at the same time, eliminates any potential alignment risks down the road.
In this sub-proposal, we present a vendor-lock-in-free Universal Governance Mechanism (UGM) for Uniswap that utilizes multiple cross-chain protocols simultaneously. This architecture significantly enhances the security of Uniswap UGM and, at the same time, eliminates any potential alignment risks down the road.
While we believe that Celer alone can effectively solve the Uniswap UGM use case, as a long-time advocate for open protocols, we propose this solution with the best interest of the Uniswap community in mind.
It may seem that Uniswap's delegates and community must make a choice to select a single cross-chain messaging protocol for Uniswap's multi-blockchain expansion.
However, if we go down this path, it will be a TRAGIC day for Uniswap community because Uniswap, the most open dex in the world, will be vendor-lock-in to a single cross-chain protocol.
Vendor lock-in carries a multitude of risks, most notably:
But are we asking the right question?
Does Uniswap have to choose one single solution between different ones or can it utilize multiple solutions to achieve a better outcome for the community?
Cross-chain governance use cases have the following properties:
With these properties, it is a perfect use case to utilize multiple cross-chain messaging solutions simultaneously.
We propose utilizing multiple cross-chain solutions simultaneously through the use of a "MessageProcessor" contract that acts as the executor for UGM calls to Uniswap contracts on the Binance Chain. This contract would have the following functionalities:
This architecture ensures that even if a single bridge is compromised, Uniswap's governance process remains intact. Additionally, the Uniswap community can continuously evaluate participating cross-chain protocols with all bargaining power on their side.
We believe this architecture should be implemented to avoid vendor lock-ins, even if the Uniswap community decides to use a single cross-chain solution for now. Celer is committed to a vendor-lock-in-free future and is more than happy to implement this vendor-lock-in-free UGM for Uniswap.
I appreciate all the information about the different bridge solutions. I am not familiar with bridges or the security vulnerablilities. I have only heard of the Wormhole bridge from it's $320 million bridge exploit.
How would an exploit like this impact Uniswap on BSC? Would all LP's be vulerable?
I appreciate all the information about the different bridge solutions. I am not familiar with bridges or the security vulnerablilities. I have only heard of the Wormhole bridge from it's $320 million bridge exploit.
How would an exploit like this impact Uniswap on BSC? Would all LP's be vulerable?
Is the $320 million that was exploited still an issue that could impact protocols using Wormhole's bridge solution in the future?
@modong what are the risks related to validator's using Celer native token as stake to be slashed?
If Celer token prices get low enough, could there be malicious actor's/validator's that see more opportunity in the value of the bridge assets vs being slashed in Celer?
Would be good to have a combination of bridges, but due to my unfamilarity in this area I am unsure what is possible.
Hi GFX Labs team,
Just a gentle reminder that we have replied to all of your concerns. Since you have done an evaluation of multiple solutions using the criteria you mentioned and are now championing one single solution, could you please post the evaluation matrix with facts for all the criteria?
Hi GFX Labs team,
Just a gentle reminder that we have replied to all of your concerns. Since you have done an evaluation of multiple solutions using the criteria you mentioned and are now championing one single solution, could you please post the evaluation matrix with facts for all the criteria?
With this, different solution providers can clarify if needed, and the Uniswap community and delegates can do a peer review and make informed decisions. Many community members and delegates may reach different conclusions by looking at all the facts.
In addition, we would add the following criteria to the evaluation matrix:
However, we feel that we may be having the wrong discussion here. Cross-chain governance is a unique use case and it can be built as a vendor-lock-in-free architecture where multiple cross-chain solutions can co-exist to serve Uniswap with super-charged security properties.
Hi Wormhole team,
While we are looking at the 2M message per day stats you stated, we noticed that 99.97% of those messages are from a network called Pythnet. If we exclude Pythnet, there are 719 message per day in the last 7 days on Wormhole. To put it into perspective, Celer processes 1958 messages per day during the same period of time.
Hi Wormhole team,
While we are looking at the 2M message per day stats you stated, we noticed that 99.97% of those messages are from a network called Pythnet. If we exclude Pythnet, there are 719 message per day in the last 7 days on Wormhole. To put it into perspective, Celer processes 1958 messages per day during the same period of time.
In addition, we could not find any contract address deployed on Pythnet based on your documentation section describing contracts deployed on supported networks.
With the lack of information and significantly skewed volume, could you please elaborate on the Pythnet use case so everyone in the Uniswap community has a clear understanding on the usage level of Wormhole?
With 2M messages processed per day, one would imagine that there are a lot of unique wallet addresses interacting with Wormhole. Could you please share that data too? This way we can have a more complete comparison.
Hey Alex, thank you for your comments. Always great to have discussions with fellow builders in the space. Here are some quick replies:
Hey Alex, thank you for your comments. Always great to have discussions with fellow builders in the space. Here are some quick replies:
When we say L1-PoS-blockchain security model, we mean that the consensus algorithm is essentially acting like any other PoS blockchain. The closest in terms of consensus algorithm/mechanism is Cosmos-SDK/Tendermint chains such as Polygon PoS, BNB Chain or Sei Network. This is to stress that Celer uses a time-tested consensus engine and economic security engine, unlike some other multi-sig solutions or solutions with untested economic security models. We are not saying in any way that Celer's shares the exact same PoS setup with any other blockchain.
Unfortunately, you are not correct in stating that if the PoS consensus fails (2/3 stake colluding to behave maliciously), all liquidity in Celer's Bridge can be withdrawn. This is precisely where the model of optimistic rollup-like security model shines. cBridge is built with this model from day 1 and even if the majority stake is acting maliciously, large fund withdrawing (in a cumulative sense) transactions can be canceled by any Celer validator plus a group of app guardians from security firms such as Peckshield and others. So what you described won't happen. From a more practical point of view, Celer validators are highly reputable validators from the Cosmos community and incidentally share many with deBridge we believe.
Implementing an optimistic rollup security model can be done in the application domain and in the protocol at the same time. They are not mutually exclusive. For Celer, every single validator can cancel messages that are maliciously passed by the consensus protocol if the message is sent through an OR model. This enhances the security from trust majority to trust-any validators.
In addition, application builders, governance bodies or security firms independent from application builders can run app guardians for specific applications even if they don't trust any validators in Celer. For example, Certik, Trial of Bits and other security firms that are independent of both Celer and application builders can run app guardians for applications to offer "external security firms certified" services. The architecture is highly flexible with a high level of redundancy.
Kydo from Stanford Blockchain here. We would love to chime in on the bridging part of this discussion.
Message passing is hard. So please do not take the rest of this as criticism.
Kydo from Stanford Blockchain here. We would love to chime in on the bridging part of this discussion.
Message passing is hard. So please do not take the rest of this as criticism.
No amount of dollars can help you forge a digital signature. So, we believe in the future, when cryptographically-secured message passing exists, Uniswap should heavily prioritize it (not choosing it straightaway since the complexity could also increase attack surfaces).
Does required stake/slash make it significantly unprofitable to exploit bridge
This is an important question to answer explicitly with data (this behavior -> this slash amount, etc). Moreover, we would add that the provider should lay out how to become a validator in the network. This demonstrates how easy it is to collude across your validator set.
We should not lock in one vendor when the possibility of choosing multiple exists.
The recency of the audits is very important. These unaudited features, especially the delay mechanism, should not be implemented by Uniswap before a formal audit is complete.
Does their documentation clearly explain how their system works, not just in concept but, most importantly, in execution?
Moreover, if your system requires honest interactions with external third parties, you should clearly explain how the external third parties work or link to their technical documentation (in another thread).
We believe the best way forward, especially after the Nomad hack, is to use multiple bridge providers for message passing. We do not believe this is theoretically hard but would require significant engineering hours. We would love to see more discussion surrounding this topic.
We do not have the expertise to analyze the actual implementations and understand the complexity levels of each codebase; so we made our decision based on the assumption that all these implementations (up to the most recent audit) are equally secure/insecure.
Our ranking is subject to change, based on answers provided by the service providers.
Our tentative ranking is as follows:
To us, all these providers pose significant risks (relative to native L2 bridges or light client bridges). So, the ranking should not be taken at face value that any provider is "better" than another. Note: we are talking about using this for governance instead of a simple bridge transfer. So the evaluation criteria are a lot stricter.
We ranked wormhole as number 1 because of its diverse validator set. However, we would love to understand how does Wormhole penalize malicious validators? Does Wormhole have legally binding agreements with each validator? If so, what actions can Wormhole pursue?
We ranked Celer and LayerZero second. Celer has a decently sized validator set but the economic guarantee behind them is much weaker. I do not see that being a fixable problem, therefore I placed them (Celer) second.
LayerZero depends heavily on Chainlink's oracle relay service. However, I was not able to find any information with regard to Chainlink's implementation on their documentation or your website. Can you share more with regard to how does this specific chainlink oracle work? And if it is similar to Chainlink's price feed, who are the multisig signers (providers) for it? With regard to the relayer, other than LayerZero, is there any other entity running a relayer? If Uniswap wants to run our own relayer, can LayerZero commit human capital to assist us in running it?
We believe the best course forward is the Multi-Provider-Aggregation method. I would love to hear thoughts from other technical delegates on the difficulties of the design and a potential timeline.
If the above method is infeasible, I would recommend using Wormhole at this point. However, BNB Uniswap should have the ability to switch the message-passing provider at a later date through governance.
We hope @devinwalsh could open a new thread specifically for x-chain messaging outside this one since this discussion is going to be important for future and past x-chain developments.
Edit 2: Add clarification around ranking.
GFX Labs team, thank you again for your questions. We would love to provide some responses to your questions.
GFX Labs team, thank you again for your questions. We would love to provide some responses to your questions.
First, we would like to elaborate a bit on our security audits and track records. We respect that different people may have different opinions about security firms, but we believe that both Peckshield and Slowmist are well-regarded security audit firms. Peckshield, in particular, has been consistently the first to report many security incidents and coordinate major security investigations with top security researchers and firms such as banteg, samczsun, and others. If you have any specific concerns about the quality of these firms, we would be happy to relay them and invite these firms to answer or clarify.
Regarding the audit dates, we built Celer's system in such a way that our optimistic rollup-like security model can be securely and easily added to dApps as a design pattern. The capability to do so has been available before Feb 2022, and we only began talking about it proactively later when we realized that some teams were marketing it as a unique feature.
In addition to security audits, Celer also has a standing $2M bug bounty on ImmuneFi since November 2021, which has not been claimed yet.
In terms of our security track record, Celer's cross-chain system is the ONLY ONE that has processed a meaningfully large volume (bigger than $1 billion in asset bridging volume) without any critical security issues being reported or exploited. Additionally, throughout Celer's development history since 2018, none of the systems or products built by Celer, including the world's first Generalized State Channel Network, have been exploited in any way. Celer has a security operation team that is active 24/7 to monitor the public blockchain transactions for any anomalies related to Celer's systems and respond to any reports from security firms and independent security researchers with a 3-minute SLA. Of course, we know blockchain is a dark forest and our flawless record does not automatically guarantee future security, but we hope that the information provided gives you more confidence from a comparative perspective.
The security model of the optimistic rollup-like system has two components: 1) a two-phase commit pattern in the smart contract, and 2) an off-chain App Guardian that can halt the execution of a message during the delay between commit and confirmation.
We would be happy to explain this in more detail using the DelayedTransfer example you mentioned. DelayedTransfer is related to the optimistic-rollup-like security model used in cBridge, an asset bridge built on the Celer Network. When an asset bridge transaction is initiated and the message is relayed to the destination chain, the message is placed in a DelayedTransfer queue on the destination chain, where it must wait a set delay before funds are released with a confirm transaction.
During this delay, an App Guardian cross-checks the source chain to verify the presence of a corresponding bridge transaction. If a match is found, the App Guardian takes no action and the confirm transaction is executed as normal. However, if a matching transaction is not found (indicating a problem with the bridge), the App Guardian can halt the asset bridge smart contract, preventing any malicious transactions from executing and safeguarding funds. The App Guardian is operated by every validator of SGN and can also be run by additional parties, such as the Uniswap foundation, for their own dApps.
The above security model will be applied to Uniswap's governance use case. We hope this explanation has provided clarity, but we are available for further discussion via a call or in a Twitter space.
We have recently taken down some of the documentation and reference implementation for the dApp side of the optimistic-rollup-like security model, in order to make it more adaptable for various application use cases. We will follow up with links to the updated documentation and App Guardian repositories within the next two days.
You are correct in noting that the MessageBus contract is upgradeable through a governance multisig. Our governance process involves a community voting process, and the execution of governance decisions for on-chain contract upgrades is carried out by a subset of validators including InfStone, Binance Staking, OKEX and Celer Foundation.
We made the MessageBus upgradeable with the goal of making it easier to address any potential security issues just in case and add must-have features. However, we approach this process with care and continually evaluate and improve our governance process. We welcome additional active contributors such as GFXLabs to be more involved.
We hope the above clarifies the concerns to some degree and we are always happy to answer any further questions!
Thank you for the comments and questions. I wanted to reply here first to acknowledge the receipt of your comments. However, since today is the Lunar New Year and many of our team is on family or religious holidays, a detailed reply with technical documentation updates might be a bit delayed. Apologies for this and we will reply as soon as we can.
What is the status on the temperature check? we should have a vote as soon as possible. I will be delegating to GFXlabs. Bridges discussion can be held seperate.
That would not be a problem at all. In addition, we are actively working on a zk succinct proof based solution that will further enhance security for use cases like governance.
All great questions.
When building cross-chain dApps in the optimistic-rollup-style security, all SGN nodes will run the app guardian process for this dApp. In addition, any application developer whitelisted entity can run an app guardian for this app. In this case, we can run an additional app guardian for Uniswap's cross-chain governance use case and talk to our long-term security partners, such as Peckshield, to run one for Uniswap. Of course, Uniswap foundation can also run an app guardian for this use case.
All great questions.
When building cross-chain dApps in the optimistic-rollup-style security, all SGN nodes will run the app guardian process for this dApp. In addition, any application developer whitelisted entity can run an app guardian for this app. In this case, we can run an additional app guardian for Uniswap's cross-chain governance use case and talk to our long-term security partners, such as Peckshield, to run one for Uniswap. Of course, Uniswap foundation can also run an app guardian for this use case.
So to answer your question, yes, there will undoubtedly be multiple app guardians for Uniswap and quite a decentralized group of guardians. It is straightforward to run an app guardian as it is a simple deployment process.
Exciting proposal for sure. Mo from Celer Network here. I would love to introduce Celer and also respond to the questions listed here.
Exciting proposal for sure. Mo from Celer Network here. I would love to introduce Celer and also respond to the questions listed here.
Celer is a generalized blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, and more across multiple chains. Developers can build inter-chain-native dApps using the Celer Inter-chain Message (IM) SDK 1 to gain access to efficient liquidity utilization, coherent application logic, and shared states. There are 10+ cross-chain applications live today that are built with Celer IM on various use cases including governance and liquidity network protocols. cBridge, a cross-chain asset bridge solution, has processed $12.2b transaction volume across 31 chains for 200K users.
Celer IM based cross-chain governance is already live in production with FutureSwap since the end of April 2022 and has been operating flawlessly since. The reference implementation of cross-chain governance is very straightforward and we describe the high level flow here based on the application design pattern.
When a governance decision is made on Ethereum, the governance contract will call sendMessage of a “send box” contract which takes in the destination chain ids, message to be passed and destination contract addresses. The message will contain the serialized bytes of the governance decision.
This message will be synced with State Guardian Network, which is a Cosmos SDK based blockchain. Validators in SGN will witness the message and reach consensus on the Cosmos layer that this message indeeded exists and generate a stake-weighted multisignature attestation that is stored on the chain.
A message executor (can be run by Uniswap or run by validators of Celer Network) will collect this message and call executeMessage of a “receive box” contract. After necessary on-chain validation of the message, the message will be eventually relayed to the destination contract.
The validation, except for the generic checking of the validity of the signatures, also has two security models available to determine when the target contract will receive the message. The first security model is to directly pass the message on and rely fully on PoS security of the Cosmos chain.
However, in the case of low-frequency applications like cross-chain governance, we recommend using the second security model: an optimistic rollup-like security model. In this security model, every message that is passed onto the destination chain will be first put into a “quarantine zone” for a configurable period of time. During that quarantine period, every single validator in the SGN and the application executor (collectively, App Guardians) can monitor and cross-check the message arrived on the destination chain vs sent on the source chain. If there is any mismatch, the message path will be cut off immediately and the message will not be executed. This changes the security assumption from “trust majority stake” to “trust any” with app developers capable of running one of the “any” App Guardians themselves. This is how FutureSwap implemented their cross-chain governance module.
Once the quarantine clock times out, the message will be executed by calling a standard interface on the destination governance contract. This will complete the cross-chain governance process.
Next, we answer the questions raised in the post.
Of course, this is the core of Celer, and all the cross-chain applications are built on top of this functionality. Celer currently supports arbitrary message passing on all EVM-based chains. For non-EVM chains, Celer supports Aptos, Sui, Flow and Cosmos-based blockchains.
This is briefly discussed in the previous walkthrough. Here, we provide a more detailed description.
As discussed above, Celer’s generalized message cross-chain solution comes with two security models and we recommend using the optimistic rollup solution here. More context on Celer’s security models:
Celer comes with two security models that each app and users are free to choose from on a per-tx basis.
By default, inter-chain dApps rely on the security of the State Guardian Network (a Cosmos Chain) by processing messages routed from another chain without delay. The SGN offers L1-blockchain level security just like Cosmos or Polygon with it being a Proof-of-Stake (PoS) blockchain built on Tendermint with CELR as the staking asset. If a guardian acts maliciously, its staked CELR will be slashed by the consensus protocol. This level of economic security is something that grows with the staked CELR’s value and is simply not available in simple Multi-signature or MPC/PoA-based solutions.
So, what happens if more than two thirds (in staked value) of the validators behave maliciously in the State Guardian Network? Although this is highly unlikely given the economical security and distributed nature of the validators in Celer Network, Celer does have a second security model, inspired by the Optimistic Rollup design, that works securely even under this worst-case scenario.
Instead of instantly processing a message routed by the SGN, a two-phase commit-confirm pattern is used to process any inter-chain message. Before any application consumes the message, the message has to be “committed” to the blockchain by SGN into a “quarantine zone” for a period of time. Only after the delay has passed, can this message be “confirmed” and pushed to the final destination application.
During this delay buffer, a dApp can run an App Guardian service to double-validate the message on the source chain and check the authenticity of the message committed in the quarantine zone. If the App Guardian detects any inconsistency, it can prevent the message from being processed before the time buffer expires. For application developers who cannot run an App Guardian themselves, they can commission the SGN nodes to undertake the task of an App Guardian. In that case, the security model is strengthened to a trust-any model for the SGN. Therefore, even under the worst-case scenario of the SGN consensus failure, inter-chain dApps built on top of Celer’s construct will still maintain safety property without any concern.
When operating in the model of Optimistic-rollup-style model, the security is dependent on the source chain and on the “trust-any” model as described in the security model section. It does not depend on any single third-party entity or a majority of decentralized parties. As long as one single app guardian is still working in a trustworthy way, the system is secure.
When operating in the model of Optimistic-rollup-style model, as long as there is still one app guardian that is trustworthy, it is not possible to have any fraudulent message to be passed to the destination chain.
This is very different from other models where when a majority (often 2/3) of validators/MPC signers are compromised, a fraudulent message can be passed to the destination chain.
Their CELR stake will be slashed.
Celer was audited by Certik, Slowmist and Peckshield. No vulnerabilities were identified in any of the audits. We also have a $2M standing bug bounty on Immunefi that is not claimed yet. Celer is the only cross-chain system that has processed more than $1b with no vulnerability exploited or identified.
Just wanted to quickly drop my thoughts on bridge providers for Uniswap v3 deployments.
This is a governance bridge, and the Uniswap treasury is held on L1, so the main risk is a malicious governance proposal pointing the fee switch to a malicious address. This would siphon off funds while L1 governance deploys a new proposal to turn off the fee switch and de activate compromised bridge.
Just wanted to quickly drop my thoughts on bridge providers for Uniswap v3 deployments.
This is a governance bridge, and the Uniswap treasury is held on L1, so the main risk is a malicious governance proposal pointing the fee switch to a malicious address. This would siphon off funds while L1 governance deploys a new proposal to turn off the fee switch and de activate compromised bridge.
zk, optimistic, and light client "conanical" bridges are what we should be shooting for.
Even then, I'm personally not fully convinced on Optimistic Fraud proofs but many in this community are. While I think while they aren't ideal, this is an acceptable risk tolerance for the governance use case.
Network of Validator bridges are glorified multisigs and should have a high level of scrutiny applied to them.
cryptographic security >>> crypto-economic incentives
I don't think Network of Validator bridges are inherently unacceptable for Uniswap, but it's important to realize they come in all shapes and sizes. It is important to ask a lot of questions such as:
I mostly worry that many networks may have a single entity managing a large set of the validators, and a single phishing email could compromise a large set of the signing keys.
Uniswap is not ready to adopt a single bridge provider (and therefore, in my opinion not ready to expand its cross-chain ventures beyond governance), and therefore this risk is only relevant to the governance problem. The above scrutiny on network of validator bridges are not specific to any of the providers mentioned in this thread- just want to make sure community analyzes risk appropriately.
Thank you for the comments and questions. I wanted to reply here first to acknowledge the receipt of your comments. However, since today is the Lunar New Year and many of our team is on family or religious holidays, a detailed reply with technical documentation updates might be a bit delayed. Apologies for this and we will reply as soon as we can.
What is the status on the temperature check? we should have a vote as soon as possible. I will be delegating to GFXlabs. Bridges discussion can be held seperate.
That would not be a problem at all. In addition, we are actively working on a zk succinct proof based solution that will further enhance security for use cases like governance.
All great questions.
When building cross-chain dApps in the optimistic-rollup-style security, all SGN nodes will run the app guardian process for this dApp. In addition, any application developer whitelisted entity can run an app guardian for this app. In this case, we can run an additional app guardian for Uniswap's cross-chain governance use case and talk to our long-term security partners, such as Peckshield, to run one for Uniswap. Of course, Uniswap foundation can also run an app guardian for this use case.
All great questions.
When building cross-chain dApps in the optimistic-rollup-style security, all SGN nodes will run the app guardian process for this dApp. In addition, any application developer whitelisted entity can run an app guardian for this app. In this case, we can run an additional app guardian for Uniswap's cross-chain governance use case and talk to our long-term security partners, such as Peckshield, to run one for Uniswap. Of course, Uniswap foundation can also run an app guardian for this use case.
So to answer your question, yes, there will undoubtedly be multiple app guardians for Uniswap and quite a decentralized group of guardians. It is straightforward to run an app guardian as it is a simple deployment process.
Exciting proposal for sure. Mo from Celer Network here. I would love to introduce Celer and also respond to the questions listed here.
Exciting proposal for sure. Mo from Celer Network here. I would love to introduce Celer and also respond to the questions listed here.
Celer is a generalized blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, and more across multiple chains. Developers can build inter-chain-native dApps using the Celer Inter-chain Message (IM) SDK 1 to gain access to efficient liquidity utilization, coherent application logic, and shared states. There are 10+ cross-chain applications live today that are built with Celer IM on various use cases including governance and liquidity network protocols. cBridge, a cross-chain asset bridge solution, has processed $12.2b transaction volume across 31 chains for 200K users.
Celer IM based cross-chain governance is already live in production with FutureSwap since the end of April 2022 and has been operating flawlessly since. The reference implementation of cross-chain governance is very straightforward and we describe the high level flow here based on the application design pattern.
When a governance decision is made on Ethereum, the governance contract will call sendMessage of a “send box” contract which takes in the destination chain ids, message to be passed and destination contract addresses. The message will contain the serialized bytes of the governance decision.
This message will be synced with State Guardian Network, which is a Cosmos SDK based blockchain. Validators in SGN will witness the message and reach consensus on the Cosmos layer that this message indeeded exists and generate a stake-weighted multisignature attestation that is stored on the chain.
A message executor (can be run by Uniswap or run by validators of Celer Network) will collect this message and call executeMessage of a “receive box” contract. After necessary on-chain validation of the message, the message will be eventually relayed to the destination contract.
The validation, except for the generic checking of the validity of the signatures, also has two security models available to determine when the target contract will receive the message. The first security model is to directly pass the message on and rely fully on PoS security of the Cosmos chain.
However, in the case of low-frequency applications like cross-chain governance, we recommend using the second security model: an optimistic rollup-like security model. In this security model, every message that is passed onto the destination chain will be first put into a “quarantine zone” for a configurable period of time. During that quarantine period, every single validator in the SGN and the application executor (collectively, App Guardians) can monitor and cross-check the message arrived on the destination chain vs sent on the source chain. If there is any mismatch, the message path will be cut off immediately and the message will not be executed. This changes the security assumption from “trust majority stake” to “trust any” with app developers capable of running one of the “any” App Guardians themselves. This is how FutureSwap implemented their cross-chain governance module.
Once the quarantine clock times out, the message will be executed by calling a standard interface on the destination governance contract. This will complete the cross-chain governance process.
Next, we answer the questions raised in the post.
Of course, this is the core of Celer, and all the cross-chain applications are built on top of this functionality. Celer currently supports arbitrary message passing on all EVM-based chains. For non-EVM chains, Celer supports Aptos, Sui, Flow and Cosmos-based blockchains.
This is briefly discussed in the previous walkthrough. Here, we provide a more detailed description.
As discussed above, Celer’s generalized message cross-chain solution comes with two security models and we recommend using the optimistic rollup solution here. More context on Celer’s security models:
Celer comes with two security models that each app and users are free to choose from on a per-tx basis.
By default, inter-chain dApps rely on the security of the State Guardian Network (a Cosmos Chain) by processing messages routed from another chain without delay. The SGN offers L1-blockchain level security just like Cosmos or Polygon with it being a Proof-of-Stake (PoS) blockchain built on Tendermint with CELR as the staking asset. If a guardian acts maliciously, its staked CELR will be slashed by the consensus protocol. This level of economic security is something that grows with the staked CELR’s value and is simply not available in simple Multi-signature or MPC/PoA-based solutions.
So, what happens if more than two thirds (in staked value) of the validators behave maliciously in the State Guardian Network? Although this is highly unlikely given the economical security and distributed nature of the validators in Celer Network, Celer does have a second security model, inspired by the Optimistic Rollup design, that works securely even under this worst-case scenario.
Instead of instantly processing a message routed by the SGN, a two-phase commit-confirm pattern is used to process any inter-chain message. Before any application consumes the message, the message has to be “committed” to the blockchain by SGN into a “quarantine zone” for a period of time. Only after the delay has passed, can this message be “confirmed” and pushed to the final destination application.
During this delay buffer, a dApp can run an App Guardian service to double-validate the message on the source chain and check the authenticity of the message committed in the quarantine zone. If the App Guardian detects any inconsistency, it can prevent the message from being processed before the time buffer expires. For application developers who cannot run an App Guardian themselves, they can commission the SGN nodes to undertake the task of an App Guardian. In that case, the security model is strengthened to a trust-any model for the SGN. Therefore, even under the worst-case scenario of the SGN consensus failure, inter-chain dApps built on top of Celer’s construct will still maintain safety property without any concern.
When operating in the model of Optimistic-rollup-style model, the security is dependent on the source chain and on the “trust-any” model as described in the security model section. It does not depend on any single third-party entity or a majority of decentralized parties. As long as one single app guardian is still working in a trustworthy way, the system is secure.
When operating in the model of Optimistic-rollup-style model, as long as there is still one app guardian that is trustworthy, it is not possible to have any fraudulent message to be passed to the destination chain.
This is very different from other models where when a majority (often 2/3) of validators/MPC signers are compromised, a fraudulent message can be passed to the destination chain.
Their CELR stake will be slashed.
Celer was audited by Certik, Slowmist and Peckshield. No vulnerabilities were identified in any of the audits. We also have a $2M standing bug bounty on Immunefi that is not claimed yet. Celer is the only cross-chain system that has processed more than $1b with no vulnerability exploited or identified.
Just wanted to quickly drop my thoughts on bridge providers for Uniswap v3 deployments.
This is a governance bridge, and the Uniswap treasury is held on L1, so the main risk is a malicious governance proposal pointing the fee switch to a malicious address. This would siphon off funds while L1 governance deploys a new proposal to turn off the fee switch and de activate compromised bridge.
Just wanted to quickly drop my thoughts on bridge providers for Uniswap v3 deployments.
This is a governance bridge, and the Uniswap treasury is held on L1, so the main risk is a malicious governance proposal pointing the fee switch to a malicious address. This would siphon off funds while L1 governance deploys a new proposal to turn off the fee switch and de activate compromised bridge.
zk, optimistic, and light client "conanical" bridges are what we should be shooting for.
Even then, I'm personally not fully convinced on Optimistic Fraud proofs but many in this community are. While I think while they aren't ideal, this is an acceptable risk tolerance for the governance use case.
Network of Validator bridges are glorified multisigs and should have a high level of scrutiny applied to them.
cryptographic security >>> crypto-economic incentives
I don't think Network of Validator bridges are inherently unacceptable for Uniswap, but it's important to realize they come in all shapes and sizes. It is important to ask a lot of questions such as:
I mostly worry that many networks may have a single entity managing a large set of the validators, and a single phishing email could compromise a large set of the signing keys.
Uniswap is not ready to adopt a single bridge provider (and therefore, in my opinion not ready to expand its cross-chain ventures beyond governance), and therefore this risk is only relevant to the governance problem. The above scrutiny on network of validator bridges are not specific to any of the providers mentioned in this thread- just want to make sure community analyzes risk appropriately.
IMHO: Uniswap is already deployed on all major chains. The UNI community needs to restructure its strategy to start developing on-chain relationships with major protocols and tokens.
IMHO: Uniswap is already deployed on all major chains. The UNI community needs to restructure its strategy to start developing on-chain relationships with major protocols and tokens.
Thank you for your feedback and insight. We will note that to help the Uniswap Community evaluate future deployment proposals
Hello, the Deployment Accountability Committee understands that there was no specific commitment your team has made to support the Uniswap Ecosystem. However, we do want to discuss some assumptions and explore with the community how to better improve such expectations.
Hello, the Deployment Accountability Committee understands that there was no specific commitment your team has made to support the Uniswap Ecosystem. However, we do want to discuss some assumptions and explore with the community how to better improve such expectations.
In reality, TVL for Uniswap on BSC is only $13.17m at the moment and unlikely that it gathered 1-2M new users. What do you think were the issues that hindered meeting initial expectations? Note that this information is being sought in an effort to provide a collective update to the community that will be publicly available.
This is the only reason you needed to give, tbh. We get it.
Greetings @Doo_StableLab To reach the anticipated figures, extensive business development is crucial for the chain's protocols and operations. Simply deploying the protocol is insufficient. This approach can be adapted for any other chain deployment.
GFX Labs voted for proposal 31 to deploy Uniswap v3 on BSC. Setting aside the bridge provider discussion after the completion of the Snapshot vote, we would like to elaborate upon our reasoning for voting to deploy on BSC, which some view to be controversial.
Revisiting our post from December, it is evident that Pancake Swap has significant trading volume and utilization. For those who are not familiar, PancakeSwap is a direct Uniswap v2 fork. If Uniswap v3 were to be deployed to BSC, we could significantly reduce PancakeSwap's position in the DEX market and reduce the incentive for PancakeSwap to fork Uniswap v3 when the BSL expires in April.
This will be our (FranklinDAO/Penn) last post here seeing the impending 3 hour deadline for votes. Since we last posted here a few hours ago where we expressed our opinions regarding how we believe future bridging solutions should go, we are currently abstaining from a vote.
For some background, this has certainly been the #1 most lobbied vote on Uniswap that we have ever partaken in. Our opinions expressed above should be coupled with this thought: no matter the outcome, this should be a short term victory for either party. In the very near future, we would like to once again enforce that we think a multiple bridge multisig should be used to give us the best of both worlds.
Hi all. Following the community discussion on this proposal over the past week, the UF is posting here to answer some open questions and draw attention to next steps.
Next Steps on the BNB Proposal
Hi all. Following the community discussion on this proposal over the past week, the UF is posting here to answer some open questions and draw attention to next steps.
Next Steps on the BNB Proposal
Timeframe and Context on Bridge Selection Temperature Check
Cross-Chain Bridge Assessment Process
Clarity on deploying cross-chain with no bridge, and changing the bridge used for a chain
General Comments
Blockchain@Columbia’s Uniswap governance team has considered this temperature check with great importance. We appreciated @jkol 's reference to our post the RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia shared by @jason_of_cs. For anyone who hasn’t, we encourage you to read the post where we proposed a “synergy between Axelar and Hyperlane[previously Abacus] inheriting the PoS validator-set model of Axelar (AXL tokens, which could potentially in an application-specific setting be just the UNI tokens) with the application-customizability of Abacus as having the ideal model for Uniswap’s current purposes, with UNI token holders freely participating in the system (this can be implemented in a variety of ways).” We took extensive time to consider various bridging providers including LayerZero, Wormhole, Nomad, Axelar, and Hyperlane (Abacus), which wouldn’t have been possible without @jason_of_cs a prominent researcher in the AMM space.
As we know, Axelar and Hyperlane weren’t considered for this temperature check, and it raises questions on the hast at which the community is coming to a decision. @pennblockchain, as well as other university organizations, have provided sound commentary on this debate, and we agree with @devinwalsh from the UF team that “assessments of bridge security are time intensive and require significant technical expertise and context.” As of the time of writing this post, it’s clear that LayerZero and Wormhole are the two competing players to win this temperature check, and we’re fortunate to have discussions with both LayerZero and Wormhole
The only question I have as a contract deployer is who will run Infra for Uniswap and custom LayerZero, and how we will manage it.
Thanks for the clarification, Bryan!
Just to be completely objective when we are choosing a bridge for Uniswap v3, I ask all community members also to read the report published today by James Prestwich, regarding the potential vulnerabilities in LayerZero contracts.
@GFXlabs @pennblockchain @AbdullahUmar @Kydo @Porter
❗️Full article: https://prestwich.substack.com/p/zero-validation
Throwing in some comments here. We'll preface by saying that considering how "unexpected" this discussion arose, we appreciate the UF team for their quick thinking and on the feet decisions.
When looking at the main debate surrounding L0 and Wormhole, we're still internally conflicted on which is ultimately the best, and think each has benefits of their own. Ultimately, we don't think this proposed structure of finding a bridge partner is ideal and sets a bad precedence. We propose:
Thanks to all for actively participating in our discussion regarding the infrastructure of the bridges. I think these tech assessments and proposals could be better posted on this thread.
My only question to the Uniswap community: are we ready to lose now a market share of the protocol on many new chains forever, or will we take a chance to speed up the deployment with current conditions and solve a bridge dilemma with the next proposal, when the solution will be found?
Thank you for your feedback and insight. We will note that to help the Uniswap Community evaluate future deployment proposals
Hello, the Deployment Accountability Committee understands that there was no specific commitment your team has made to support the Uniswap Ecosystem. However, we do want to discuss some assumptions and explore with the community how to better improve such expectations.
Hello, the Deployment Accountability Committee understands that there was no specific commitment your team has made to support the Uniswap Ecosystem. However, we do want to discuss some assumptions and explore with the community how to better improve such expectations.
In reality, TVL for Uniswap on BSC is only $13.17m at the moment and unlikely that it gathered 1-2M new users. What do you think were the issues that hindered meeting initial expectations? Note that this information is being sought in an effort to provide a collective update to the community that will be publicly available.
This is the only reason you needed to give, tbh. We get it.
Greetings @Doo_StableLab To reach the anticipated figures, extensive business development is crucial for the chain's protocols and operations. Simply deploying the protocol is insufficient. This approach can be adapted for any other chain deployment.
GFX Labs voted for proposal 31 to deploy Uniswap v3 on BSC. Setting aside the bridge provider discussion after the completion of the Snapshot vote, we would like to elaborate upon our reasoning for voting to deploy on BSC, which some view to be controversial.
Revisiting our post from December, it is evident that Pancake Swap has significant trading volume and utilization. For those who are not familiar, PancakeSwap is a direct Uniswap v2 fork. If Uniswap v3 were to be deployed to BSC, we could significantly reduce PancakeSwap's position in the DEX market and reduce the incentive for PancakeSwap to fork Uniswap v3 when the BSL expires in April.
This will be our (FranklinDAO/Penn) last post here seeing the impending 3 hour deadline for votes. Since we last posted here a few hours ago where we expressed our opinions regarding how we believe future bridging solutions should go, we are currently abstaining from a vote.
For some background, this has certainly been the #1 most lobbied vote on Uniswap that we have ever partaken in. Our opinions expressed above should be coupled with this thought: no matter the outcome, this should be a short term victory for either party. In the very near future, we would like to once again enforce that we think a multiple bridge multisig should be used to give us the best of both worlds.
Hi all. Following the community discussion on this proposal over the past week, the UF is posting here to answer some open questions and draw attention to next steps.
Next Steps on the BNB Proposal
Hi all. Following the community discussion on this proposal over the past week, the UF is posting here to answer some open questions and draw attention to next steps.
Next Steps on the BNB Proposal
Timeframe and Context on Bridge Selection Temperature Check
Cross-Chain Bridge Assessment Process
Clarity on deploying cross-chain with no bridge, and changing the bridge used for a chain
General Comments
Blockchain@Columbia’s Uniswap governance team has considered this temperature check with great importance. We appreciated @jkol 's reference to our post the RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia shared by @jason_of_cs. For anyone who hasn’t, we encourage you to read the post where we proposed a “synergy between Axelar and Hyperlane[previously Abacus] inheriting the PoS validator-set model of Axelar (AXL tokens, which could potentially in an application-specific setting be just the UNI tokens) with the application-customizability of Abacus as having the ideal model for Uniswap’s current purposes, with UNI token holders freely participating in the system (this can be implemented in a variety of ways).” We took extensive time to consider various bridging providers including LayerZero, Wormhole, Nomad, Axelar, and Hyperlane (Abacus), which wouldn’t have been possible without @jason_of_cs a prominent researcher in the AMM space.
As we know, Axelar and Hyperlane weren’t considered for this temperature check, and it raises questions on the hast at which the community is coming to a decision. @pennblockchain, as well as other university organizations, have provided sound commentary on this debate, and we agree with @devinwalsh from the UF team that “assessments of bridge security are time intensive and require significant technical expertise and context.” As of the time of writing this post, it’s clear that LayerZero and Wormhole are the two competing players to win this temperature check, and we’re fortunate to have discussions with both LayerZero and Wormhole
The only question I have as a contract deployer is who will run Infra for Uniswap and custom LayerZero, and how we will manage it.
Thanks for the clarification, Bryan!
Just to be completely objective when we are choosing a bridge for Uniswap v3, I ask all community members also to read the report published today by James Prestwich, regarding the potential vulnerabilities in LayerZero contracts.
@GFXlabs @pennblockchain @AbdullahUmar @Kydo @Porter
❗️Full article: https://prestwich.substack.com/p/zero-validation
Throwing in some comments here. We'll preface by saying that considering how "unexpected" this discussion arose, we appreciate the UF team for their quick thinking and on the feet decisions.
When looking at the main debate surrounding L0 and Wormhole, we're still internally conflicted on which is ultimately the best, and think each has benefits of their own. Ultimately, we don't think this proposed structure of finding a bridge partner is ideal and sets a bad precedence. We propose:
Thanks to all for actively participating in our discussion regarding the infrastructure of the bridges. I think these tech assessments and proposals could be better posted on this thread.
My only question to the Uniswap community: are we ready to lose now a market share of the protocol on many new chains forever, or will we take a chance to speed up the deployment with current conditions and solve a bridge dilemma with the next proposal, when the solution will be found?
GFX Labs voted for proposal 31 to deploy Uniswap v3 on BSC. Setting aside the bridge provider discussion after the completion of the Snapshot vote, we would like to elaborate upon our reasoning for voting to deploy on BSC, which some view to be controversial.
Revisiting our post from December, it is evident that Pancake Swap has significant trading volume and utilization. For those who are not familiar, PancakeSwap is a direct Uniswap v2 fork. If Uniswap v3 were to be deployed to BSC, we could significantly reduce PancakeSwap's position in the DEX market and reduce the incentive for PancakeSwap to fork Uniswap v3 when the BSL expires in April.
The best example of Uniswap v3 competing with a Uniswap v2 fork is Polygon's QuickSwap. Before Uniswap v3's deployment on Polygon, QuickSwap had the majority of Polygon DEX market share. Within two months of Uniswap v3's deployment, it took over most of Polygon DEX's market share.
Planning beyond proposal 31, we believe Uniswap should be deployed on other popular and up-and-coming EVM chains to reduce the incentive for forks to be launched post-BSL.
There are currently five deployments of Uniswap v3 and one pending deployment (zkSync). In addition to BSC, we expect at least 2-5 more deployments before April 1st, approximately ten deployments by the end of April, and 20-30 by year-end. The question we should be working to solve now is what should Uniswap be doing to make certain it maintains its market share domiance post-BSL?
This will be our (FranklinDAO/Penn) last post here seeing the impending 3 hour deadline for votes. Since we last posted here a few hours ago where we expressed our opinions regarding how we believe future bridging solutions should go, we are currently abstaining from a vote.
For some background, this has certainly been the #1 most lobbied vote on Uniswap that we have ever partaken in. Our opinions expressed above should be coupled with this thought: no matter the outcome, this should be a short term victory for either party. In the very near future, we would like to once again enforce that we think a multiple bridge multisig should be used to give us the best of both worlds.
At the end of the day, taking away our opinions regarding the jurisdiction of this vote, if we were forced to choose on this proposal, our team is genuinely split right down the center with our decision. In short, we believe Wormhole’s council of 19 at face value is more appealing to us, however, custom solutions that L0 have promised @Kydo bring them back up to pretty much par in our eyes if not slightly the edge, given proper execution, which is a whole another story.
Ultimately, this has definitely been a pretty “stressful” day as we’ve been trying to digest information in real time (while trying to grind for the Starknet Hackathon lol). Truly, to everyone who reached out to us, thanks for your time and please understand that this “fence-sitting” by us is not one of inactivity and irresponsibility, but one of careful thought, debate, ultimate stalemate. We’d also like to note that as an organization, we’ll look to continuously improve our internal governance decisions and poise ourselves to better tackle similar situations like this in the future.
Finally, we’d once again like to thank the UF team for their constant communication these past few weeks, the BD teams of both LayerZero and Wormhole who we’re sure have both lost many hours of sleep, and other participants who have either reached out to us or been very responsive with help (@GFXlabs, @Kydo & other schools, VCs, and other interested projects and protocols). We truly are impressed with the activity around this and hope to see it stay around.
PS: Seeing that there’s a good chance this vote might come down to a16z’s verbal communication on the forums, but no vote on Snapshot (custody hurdles?), we’re interested in how this situation will be handled, is there a precedent set here yet?
Blockchain@Columbia’s Uniswap governance team has considered this temperature check with great importance. We appreciated @jkol 's reference to our post the RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia shared by @jason_of_cs. For anyone who hasn’t, we encourage you to read the post where we proposed a “synergy between Axelar and Hyperlane[previously Abacus] inheriting the PoS validator-set model of Axelar (AXL tokens, which could potentially in an application-specific setting be just the UNI tokens) with the application-customizability of Abacus as having the ideal model for Uniswap’s current purposes, with UNI token holders freely participating in the system (this can be implemented in a variety of ways).” We took extensive time to consider various bridging providers including LayerZero, Wormhole, Nomad, Axelar, and Hyperlane (Abacus), which wouldn’t have been possible without @jason_of_cs a prominent researcher in the AMM space.
As we know, Axelar and Hyperlane weren’t considered for this temperature check, and it raises questions on the hast at which the community is coming to a decision. @pennblockchain, as well as other university organizations, have provided sound commentary on this debate, and we agree with @devinwalsh from the UF team that “assessments of bridge security are time intensive and require significant technical expertise and context.” As of the time of writing this post, it’s clear that LayerZero and Wormhole are the two competing players to win this temperature check, and we’re fortunate to have discussions with both LayerZero and Wormhole
In light of the commentary published by James Prestwich, reading forum responses, and our belief that there are many strong contenders in the bringing space not mentioned in this vote. We find it difficult to choose between, LayerZero and Wormhole, and if an abstain/wait option existed, we’d prefer to vote that way. However, as this is a temperature check, with a deadline of tomorrow, we will be voting for Wormhole.
With more time to assess the technicalities of each bridging option, perhaps we will revise our decision and vote differently for LayerZero or other providers.
Just to be completely objective when we are choosing a bridge for Uniswap v3, I ask all community members also to read the report published today by James Prestwich, regarding the potential vulnerabilities in LayerZero contracts.
@GFXlabs @pennblockchain @AbdullahUmar @Kydo @Porter
❗️Full article: https://prestwich.substack.com/p/zero-validation
We are very much looking forward to the comments from the LayerZero team @raz , as our snapshot bridge poll is coming to an end tomorrow.
Throwing in some comments here. We'll preface by saying that considering how "unexpected" this discussion arose, we appreciate the UF team for their quick thinking and on the feet decisions.
When looking at the main debate surrounding L0 and Wormhole, we're still internally conflicted on which is ultimately the best, and think each has benefits of their own. Ultimately, we don't think this proposed structure of finding a bridge partner is ideal and sets a bad precedence. We propose:
Overall, this reasoning stems from: 1) we believe there are multiple valid bridges/solutions to this question. 2) Combining L0 & Wormhole & maybe other bridges with a majority rules outcome will present the best security 3) Puts incentives with bridges and "x-chain" better in our opinion to market compete in each situation.
Thanks to all for actively participating in our discussion regarding the infrastructure of the bridges. I think these tech assessments and proposals could be better posted on this thread.
My only question to the Uniswap community: are we ready to lose now a market share of the protocol on many new chains forever, or will we take a chance to speed up the deployment with current conditions and solve a bridge dilemma with the next proposal, when the solution will be found?
For me, the answer is obvious: now or never ❗️
Hi Raz,
We devoted a chunk of time to reviewing and researching a bit over the last few days. The questions and concerns raised in our message come from our good-faith efforts to review the resources available. To recap, as part of our review of Celer’s system, we identified significant differences between what was advertised and what is actually happening. Since then, we’ve been attempting to verify anything we read on the forum as part of our own due diligence process.
Hi Raz,
We devoted a chunk of time to reviewing and researching a bit over the last few days. The questions and concerns raised in our message come from our good-faith efforts to review the resources available. To recap, as part of our review of Celer’s system, we identified significant differences between what was advertised and what is actually happening. Since then, we’ve been attempting to verify anything we read on the forum as part of our own due diligence process.
We have made efforts to review each bridge with the limited knowledge and resources we have available. While we have a pre-relationship with Wormhole, GFX only works with projects that we believe in and have first-hand knowledge about. Our primary duty, however, is to advocate for Uniswap’s success. While our post might, in hindsight, contain some inaccuracies, it was made with good intentions after reviewing publicly available documentation and included an open offer to utilize your technology — importantly, many of the core criticisms remain.
Regarding the only owner functions. We’ll edit our prior post to reflect that change. Thank you for the clarification.
This seems clearly misleading as the two parties (oracle and relayer) are abstracted accounts with arbitrary implementation e.g. a fully decentralized network, not to mention the current proposal which I had assumed GFX Labs had reviewed extensively prior to this is for a new architecture with a number of major Uniswap delegates participating within the validation set.
LayerZero is running the Relayer, and Chainlink is running the Oracle. While these are independent entities of which multiple could theoretically exist to process messages, only two exist at this time. This is functionally a 2/2 multisig, both parties must agree; otherwise, the message will not be processed. We were able to find information on how to run an oracle, but as you said, the existing relayer is currently closed source, and we cannot find an MVP example for a full relayer setup (both on and off-chain components).
As for the unique signing model proposed, we’ve discussed with a few delegates about utilizing a multisig for UniV3 deployments over a bridge and came to the rough conclusion that delegates would not be comfortable being on that multisig due to the perceived legal risks. Our intent is not to need additional signers. Thus our efforts have been put toward finding a bridge partner. The recommendation of additional signers seems to speak to the lack of parties participating in Layerzero 0.
Suppose Uniswap was to consider the signer method. Would it not make the most sense to utilize Chainlink’s Oracle system directly, with the Uniswap signers filling the role as the relayer? It seems that would be the strongest combination because the alternative would be to remove the most secure component (Chainlink) from the stack and replace it with the least secure solution (Uniswap Signers).
The current recommended configuration is secured by Chainlink as an oracle entity (currently securing tens of billions of dollars) and the LayerZero Labs (currently securing billions in TVL) operated relayer entity.
To make sure we are on the same page - is this also the only current possible configuration, assuming that Uniswap does not take charge of the Oracle or Bridge duties?
In a competitive marketplace of Oracles and Relayers, unique pricing mechanisms are often the proprietary edge for providers. These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.
If this is the case, then what is the true cost of using L0 as a relayer? Assuming that Uniswap will not move to run its own relayer, is there any other mechanism to prevent a monopolistic relayer from price-gouging messages through an upgrade? If not, how quickly would Uniswap be able to modify its cross-chain infrastructure such that it could continue performing cross-chain messaging at a reasonable price?
Thank you for the clarification.
While that makes sense, we think it would have saved a lot of time for everyone if the owner functionality was better documented.
I hope the line by line was helpful. I know we haven’t gotten to speak yet but looking forward to speaking to GFX Labs tomorrow and addressing any outstanding concerns and walking through the proposed security configuration in detail.
Thank you for the prompt answers. We appreciate the clarification, and I’m sure the other delegates reading the thread do as well.
As a final request for now, can you please deploy your proposed system on testnet and link the relevant transactions as we have done with Wormhole? We don’t want to delay the BSC deployment any further than necessary.
We're happy to lead this off and vote to deploy Uniswap on BNB Chain. Thanks to everyone who contributed to the process for the hard work to get this over the line.
Update with rationalehere.
Posting here that I fall into camp that Leighton and Jesse do above.
I abstained from the vote, as I think the process here was unclear and not a comprehensive look at solutions. I also think that singular bridge choices are worse for the ecosystem. Agree with Jesse that competition and choice are best for everyone.
Posting here that I fall into camp that Leighton and Jesse do above.
I abstained from the vote, as I think the process here was unclear and not a comprehensive look at solutions. I also think that singular bridge choices are worse for the ecosystem. Agree with Jesse that competition and choice are best for everyone.
Based on everything above I'd probably lean Layer Zero, but my perspective on the process here is more important to me.
Hi Everyone,
Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we're supportive of the Foundation's move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.
Hi Everyone,
Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we're supportive of the Foundation's move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.
GFX Labs has cast our vote for Wormhole in the current snapshot, and while we've made our concerns about Celer clear in the forum thread, we haven't done the same for Layerzero.
Our primary resources for researching Layerzero
For context, Layerzero messages are sent from the local Endpoint. Oracles are responsible for moving block headers from the source to the destination. Upon delivery, Relayers can deliver the transaction's proof to the destination Endpoint. This model, in its current implementation, is a 2-of-2 msig.
Messages are sent to a verifying library. The verifying library (VL) manages oracles and Relayers on behalf of the application. The Ultra Light Node (ULN) is a VL. The Endpoint manages the relationship between the user application (UA) and the VL (the ULN, in practice). The UA selects a VL via the Endpoint. The UA may also configure that VL directly (e.g. by selecting a Relayer in the VL). Relayers submit proofs to the VL (the ULN, in practice), and the VL chooses how to validate these. In the ULN, the owner chooses proof validation libraries and may choose any contract.
Applications are intended to choose their own VL & Relayer since they can configure which library to use in the Endpoint contract. The Endpoint owner sets a default VL. However, the ULN is the only verifying library that exists, so all apps must use it.
We tried to review how the Relayer worked, but according to the docs the Relayer is not open-source at this time, which seems to line up with L2Beat's concern of the Relayer contract being unverified.
Additionally, the only info we found in the governance section was "info coming soon!" This was not the answer we were expecting since there is an owner on the Ethereum Endpoint and UltraLightNodev2 contracts. The owner appears to be a 2/5 Gnosis Multisig. While the Endpoint isn't a traditional proxy contract, it does rely upon referenced contracts for core logic and operation. The below owner controllable functions appear to be able to alter the functionality significantly.
onlyOwner functions on the EndPoint contract:
onlyOwner functions on the UltraLightNodeV2 contract:
The ULN's owner can set the oracle, relay, proof systems, and other security parameters. It appears that the owner can entirely bypass the oracle/relay system in their current implementation.
Through this process, we arrived at the conclusion that Layerzero is not ready to be integrated with Uniswap. However, as developers ourselves, do we realize that the development process is fluid and that research is ongoing. Our vote reflects the current state of development and available information.
I'm voting for LayerZero because based on my reading of the thread & professional experience I believe that is the best option.
I would note though, if there was an abstain / wait option I would've chosen that. I do not believe this is the type of decision that is well suited for a token vote. I'm a big fan of @devinwalsh's plan to form a committee to evaluate options in depth and I would follow the recommendations there.
I'm voting for LayerZero because based on my reading of the thread & professional experience I believe that is the best option.
I would note though, if there was an abstain / wait option I would've chosen that. I do not believe this is the type of decision that is well suited for a token vote. I'm a big fan of @devinwalsh's plan to form a committee to evaluate options in depth and I would follow the recommendations there.
I also question if a bridge is even strictly needed right now. Since its only bridging governance commands presumably this could be added later? I'd prefer that option.
Hi all, note that the Snapshot poll on which bridge to use for the BSC deployment is live now: https://snapshot.org/#/uniswap/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852
Hey all, it's Abdullah from Blockchain at Michigan
Firstly, we are glad to see the community's ability to coordinate an unorthodox approach for deciding the Uni<>BNB bridge via an extra temp check. In an instance like this, it is imperative that we derive a quantitative measure for what the community is feeling as opposed to a soft metric like forum-based sentiment.
Hey all, it's Abdullah from Blockchain at Michigan
Firstly, we are glad to see the community's ability to coordinate an unorthodox approach for deciding the Uni<>BNB bridge via an extra temp check. In an instance like this, it is imperative that we derive a quantitative measure for what the community is feeling as opposed to a soft metric like forum-based sentiment.
To that end, we believe that instead of prolonging the bridge discussion beyond necessary means, it is important for us to efficiently decide on a single messaging system. After one solution is implemented, we can focus on a multi-bridge system. The primary reason for this haste, as @Porter mentioned, is the limited amount of time we have to deploy Uni v3 prior to the license expiring on April 1st of this year. Perhaps this urgency is not warranted for other L1s--but for BNB Chain, quick deployment is necessary due to the BNB community's hankering to quickly deploy forked code (the BNB ecosystem is very much quantity over quality at the moment) and capture much of the present user activity.
As of now, we are inclined to side with LayerZero for handling cross-chain governance. We put Wormhole and Celer in a similar bucket due to their reliance on a validator set, emblematic of a proof of authority mechanism. Naturally, such designs are less decentralized and subject to collusion.
Potentially, Celer's current total stake is not large enough from a dollar-value standpoint to be secure. Over time, this should resolve since the ability of an entity to buy up 2/3 of staking dominance will become harder--granted the SGN system proves viable over time and the CELR token remains strong. As for Wormhole, they have stood the test of a major exploit and have since made their system more robust, with a continual promise to prevent future exploits via a large bug bounty program and a multitude of audits. However, our main contention with Wormhole is, again, the limited 19-entity validator set. We realize the credibility of the guardians and how much stake they have to lose from a reputation perspective. But when the going gets tough, entities often focus on doing whatever they can to merely survive, forgoing their pristine reputation.
We are not limiting the merits of Wormhole or Celer; however, we feel that when the option to select a system that allows for a higher degree of control over the messaging stack is present, we should select that method. LayerZero would allow the Uni community to control its parameters (oracle and relayer) however it deems fit without the risk of collusion between a handful of validators. Yes, the risk assumption for LZ is that the relayer and oracle are themselves uncorrupted--Uniswap is not likely to face this issue. Unlike other applications using LZ, Uniswap has a robust, distributed governance base. The alteration of the relayer and oracle would require the community to collectively decide parameters, making malicious activity very difficult. That is, unless a hacker alters the parameters by subverting the governance process somehow.
We will cast our vote later tonight after our final discussions with Jump and LayerZero.
We're supportive of this plan of action (new snapshot soonish, gov vote close behind) for this particular case. Also very much into pursuing both a formal review process for bridge providers and investigating a multi-bridge solution as @AlexSmirnov lays out in a subsequent comment as a separate endeavor following the BNB Chain. I think each of those subsequent actions require some thought around the resources that'll be required for their implementation and we'd be better served considering them in isolation rather than as a component of another proposal.
Hi all! Thank you for your comments and discussion over the past few days. As you have seen in the forum, new information on the bridge selected in the Temp Check proposal (Celer) has been made available since the Temp Check took place. Additionally, two new bridges -- Wormhole and Layerzero -- have raised their hands to be the provider for the BNB deployment (in addition to deBridge, the initial bridge selected prior to Celer).
For cross-chain deployment proposals, we believe it is most important to optimize for protocol security — specifically, for community members to be able to make informed decisions based on all available information on risks to bridge security. Secondary to that is clarity of process for all governance stakeholders. In order to satisfy both of those conditions, we propose the following next steps for this BNB proposal:
Hi all! Thank you for your comments and discussion over the past few days. As you have seen in the forum, new information on the bridge selected in the Temp Check proposal (Celer) has been made available since the Temp Check took place. Additionally, two new bridges -- Wormhole and Layerzero -- have raised their hands to be the provider for the BNB deployment (in addition to deBridge, the initial bridge selected prior to Celer).
For cross-chain deployment proposals, we believe it is most important to optimize for protocol security — specifically, for community members to be able to make informed decisions based on all available information on risks to bridge security. Secondary to that is clarity of process for all governance stakeholders. In order to satisfy both of those conditions, we propose the following next steps for this BNB proposal:
Looking forward, it is clear that cross-chain proposals can be improved for all governance stakeholders. Assessments of bridge security are time intensive and require significant technical expertise and context. Tomorrow morning in a new forum post, we plan to propose an initiative which aims to provide the community with an independent technical assessment of bridge risk for the community’s benefit. We plan to move this initiative forward ASAP so the results may be leveraged in upcoming cross-chain proposals.
Hi @modong,
While we appreciate your reply to questions and concerns, we do not feel as though you sufficiently addressed them.
From our post we raised the following concerns and questions:
Hi @modong,
While we appreciate your reply to questions and concerns, we do not feel as though you sufficiently addressed them.
From our post we raised the following concerns and questions:
The Message Bus contract has an owner which can upgrade the contract implementation, thereby changing the logic.
We don't know who the EOAs are on the SimpleGovernance contract.
You did not share any further documentation on your "optimistic-rollup-style" security model.
You did not share any further documentation regarding running an app guardian.
In your reply to said the following:
However, if a matching transaction is not found (indicating a problem with the bridge), the App Guardian can halt the asset bridge smart contract, preventing any malicious transactions from executing and safeguarding funds.
If we are understanding this correctly, the App Guardian has the ability to pause the bridge contract autonomously if no matching transaction is found. Can you please confirm this point or point us toward documentation?
Also, the current cBridge contract on BSC appears to have six Pausers. Of which, all but one are also on the governance contract.
0x1a0aec0fc48f1b5cc538be74a90e340b278189e4
0x2fb8783c14a71c08bfc1de8fc3d715dd93039bf2
0x9f6b03cb6d8ab8239cf1045ab28b9df43dfcc823
0x34dfa1226f8b3e36fe597b34eea809a2b5c0bbf9
0xdfe4f07d1f36b8d559b25082460a4f6a72531de2
0x1b9dfc56e38b0f92448659c114e2347bd803911c
Our governance process involves a community voting process, and the execution of governance decisions for on-chain contract upgrades is carried out by a subset of validators including InfStone, Binance Staking, OKEX and Celer Foundation.
Do you have some documentation you could share on the above quote?
Separately, to address your latest post, "A Vender-lock-in-free Universal Governance Mechanism," this forum thread is only regarding the BSC deployment.
Thanks for the deep analytics and numbers, but I think we as a Uniswap community should evaluate and compare first the security part of different solutions.
I also do not rule out that the following proposals for BNB and other chains may use different cross-chain solutions and not rely on a single point of failure.
Hi Everyone,
In light of our concerns with Celer, we thought we should propose a solution to the Uniswap Community. To effectively but quickly evaluate cross-chain messaging protocols, we came up with a few key criteria to asses protocols.
Hi Everyone,
In light of our concerns with Celer, we thought we should propose a solution to the Uniswap Community. To effectively but quickly evaluate cross-chain messaging protocols, we came up with a few key criteria to asses protocols.
It's a mix of subjective and objective items that have helped us navigate the space. Through this process, Wormhole stood out to us, so we decided to see how the rubber met the road. To best understand the technology, we deployed a copy of Uniswap v3 onto BSC's testnet and developed a message sender and receiver contract.
Deployed Contract Addresses
Transactions
The current flow:
consistencyLevel to 1, it will wait for finality. Once the Verified Action Approval (VAA) is published, then we may proceed.There are three key points. First, the Uniswap Message Receiver must verify the sender is the Uniswap Message Sender. Second, the content received must be the content sent. Third, the message must not have been previously executed.
We would love it if the community reviewed our work. We believe utilizing this configuration for the BSC deployment makes the most sense. If we proceed with this implementation, we'll conduct an additional test to verify this works with the Uniswap Governance system and coordinate with Ilia.
On a related note, from having spoken with the Wormhole team, it's our understanding that Wormhole is also preparing a forum post with additional information.
I plan to do a temperature check this week!
Thank you - this is helpful.
As for the number and identity of the SGN of validators - looks like there are 21, who are identified here? https://sgn.celer.network/#/staking
So all 21 of these validators would also be running the App Guardian software for Uniswap. I'm definitely interested in potentially having an additional App Guardian run on Uniswap's behalf so will follow up with you on that.
Hi Everyone,
We've been doing a bit of research on the testnet deployment. Below is a list of the immediately relevant contracts:
Test use of the Celer Messaging system:
Thank you! In this case, would Uniswap have to commission SGN to run an App Guardian? I don't know of anyone running one for Uniswap today.What would the process be to do that?
And, in that case, would there only be 1 App Guardian confirming messages against Ethereum during the delay period? How many Guardians are deployed for other apps - would it be wise to commission multiple?
Thank you! In this case, would Uniswap have to commission SGN to run an App Guardian? I don't know of anyone running one for Uniswap today.What would the process be to do that?
And, in that case, would there only be 1 App Guardian confirming messages against Ethereum during the delay period? How many Guardians are deployed for other apps - would it be wise to commission multiple?
Correct me if I'm misunderstanding anything here.
Here is some background of the 0xPlasma Labs Team:
DAILY ACTIVE USERS BY BLOCKCHAIN
Thank you @ilia_0x for this post! The UF is in support of this proposal generally, and believe launching on BSC would be beneficial for the Uniswap ecosystem.
I do have a few questions I'd like to ask to benefit Uniswap delegates.
GFX Labs voted for proposal 31 to deploy Uniswap v3 on BSC. Setting aside the bridge provider discussion after the completion of the Snapshot vote, we would like to elaborate upon our reasoning for voting to deploy on BSC, which some view to be controversial.
Revisiting our post from December, it is evident that Pancake Swap has significant trading volume and utilization. For those who are not familiar, PancakeSwap is a direct Uniswap v2 fork. If Uniswap v3 were to be deployed to BSC, we could significantly reduce PancakeSwap's position in the DEX market and reduce the incentive for PancakeSwap to fork Uniswap v3 when the BSL expires in April.
The best example of Uniswap v3 competing with a Uniswap v2 fork is Polygon's QuickSwap. Before Uniswap v3's deployment on Polygon, QuickSwap had the majority of Polygon DEX market share. Within two months of Uniswap v3's deployment, it took over most of Polygon DEX's market share.
Planning beyond proposal 31, we believe Uniswap should be deployed on other popular and up-and-coming EVM chains to reduce the incentive for forks to be launched post-BSL.
There are currently five deployments of Uniswap v3 and one pending deployment (zkSync). In addition to BSC, we expect at least 2-5 more deployments before April 1st, approximately ten deployments by the end of April, and 20-30 by year-end. The question we should be working to solve now is what should Uniswap be doing to make certain it maintains its market share domiance post-BSL?
This will be our (FranklinDAO/Penn) last post here seeing the impending 3 hour deadline for votes. Since we last posted here a few hours ago where we expressed our opinions regarding how we believe future bridging solutions should go, we are currently abstaining from a vote.
For some background, this has certainly been the #1 most lobbied vote on Uniswap that we have ever partaken in. Our opinions expressed above should be coupled with this thought: no matter the outcome, this should be a short term victory for either party. In the very near future, we would like to once again enforce that we think a multiple bridge multisig should be used to give us the best of both worlds.
At the end of the day, taking away our opinions regarding the jurisdiction of this vote, if we were forced to choose on this proposal, our team is genuinely split right down the center with our decision. In short, we believe Wormhole’s council of 19 at face value is more appealing to us, however, custom solutions that L0 have promised @Kydo bring them back up to pretty much par in our eyes if not slightly the edge, given proper execution, which is a whole another story.
Ultimately, this has definitely been a pretty “stressful” day as we’ve been trying to digest information in real time (while trying to grind for the Starknet Hackathon lol). Truly, to everyone who reached out to us, thanks for your time and please understand that this “fence-sitting” by us is not one of inactivity and irresponsibility, but one of careful thought, debate, ultimate stalemate. We’d also like to note that as an organization, we’ll look to continuously improve our internal governance decisions and poise ourselves to better tackle similar situations like this in the future.
Finally, we’d once again like to thank the UF team for their constant communication these past few weeks, the BD teams of both LayerZero and Wormhole who we’re sure have both lost many hours of sleep, and other participants who have either reached out to us or been very responsive with help (@GFXlabs, @Kydo & other schools, VCs, and other interested projects and protocols). We truly are impressed with the activity around this and hope to see it stay around.
PS: Seeing that there’s a good chance this vote might come down to a16z’s verbal communication on the forums, but no vote on Snapshot (custody hurdles?), we’re interested in how this situation will be handled, is there a precedent set here yet?
Blockchain@Columbia’s Uniswap governance team has considered this temperature check with great importance. We appreciated @jkol 's reference to our post the RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia shared by @jason_of_cs. For anyone who hasn’t, we encourage you to read the post where we proposed a “synergy between Axelar and Hyperlane[previously Abacus] inheriting the PoS validator-set model of Axelar (AXL tokens, which could potentially in an application-specific setting be just the UNI tokens) with the application-customizability of Abacus as having the ideal model for Uniswap’s current purposes, with UNI token holders freely participating in the system (this can be implemented in a variety of ways).” We took extensive time to consider various bridging providers including LayerZero, Wormhole, Nomad, Axelar, and Hyperlane (Abacus), which wouldn’t have been possible without @jason_of_cs a prominent researcher in the AMM space.
As we know, Axelar and Hyperlane weren’t considered for this temperature check, and it raises questions on the hast at which the community is coming to a decision. @pennblockchain, as well as other university organizations, have provided sound commentary on this debate, and we agree with @devinwalsh from the UF team that “assessments of bridge security are time intensive and require significant technical expertise and context.” As of the time of writing this post, it’s clear that LayerZero and Wormhole are the two competing players to win this temperature check, and we’re fortunate to have discussions with both LayerZero and Wormhole
In light of the commentary published by James Prestwich, reading forum responses, and our belief that there are many strong contenders in the bringing space not mentioned in this vote. We find it difficult to choose between, LayerZero and Wormhole, and if an abstain/wait option existed, we’d prefer to vote that way. However, as this is a temperature check, with a deadline of tomorrow, we will be voting for Wormhole.
With more time to assess the technicalities of each bridging option, perhaps we will revise our decision and vote differently for LayerZero or other providers.
Just to be completely objective when we are choosing a bridge for Uniswap v3, I ask all community members also to read the report published today by James Prestwich, regarding the potential vulnerabilities in LayerZero contracts.
@GFXlabs @pennblockchain @AbdullahUmar @Kydo @Porter
❗️Full article: https://prestwich.substack.com/p/zero-validation
We are very much looking forward to the comments from the LayerZero team @raz , as our snapshot bridge poll is coming to an end tomorrow.
Throwing in some comments here. We'll preface by saying that considering how "unexpected" this discussion arose, we appreciate the UF team for their quick thinking and on the feet decisions.
When looking at the main debate surrounding L0 and Wormhole, we're still internally conflicted on which is ultimately the best, and think each has benefits of their own. Ultimately, we don't think this proposed structure of finding a bridge partner is ideal and sets a bad precedence. We propose:
Overall, this reasoning stems from: 1) we believe there are multiple valid bridges/solutions to this question. 2) Combining L0 & Wormhole & maybe other bridges with a majority rules outcome will present the best security 3) Puts incentives with bridges and "x-chain" better in our opinion to market compete in each situation.
Thanks to all for actively participating in our discussion regarding the infrastructure of the bridges. I think these tech assessments and proposals could be better posted on this thread.
My only question to the Uniswap community: are we ready to lose now a market share of the protocol on many new chains forever, or will we take a chance to speed up the deployment with current conditions and solve a bridge dilemma with the next proposal, when the solution will be found?
For me, the answer is obvious: now or never ❗️
Hi Raz,
We devoted a chunk of time to reviewing and researching a bit over the last few days. The questions and concerns raised in our message come from our good-faith efforts to review the resources available. To recap, as part of our review of Celer’s system, we identified significant differences between what was advertised and what is actually happening. Since then, we’ve been attempting to verify anything we read on the forum as part of our own due diligence process.
Hi Raz,
We devoted a chunk of time to reviewing and researching a bit over the last few days. The questions and concerns raised in our message come from our good-faith efforts to review the resources available. To recap, as part of our review of Celer’s system, we identified significant differences between what was advertised and what is actually happening. Since then, we’ve been attempting to verify anything we read on the forum as part of our own due diligence process.
We have made efforts to review each bridge with the limited knowledge and resources we have available. While we have a pre-relationship with Wormhole, GFX only works with projects that we believe in and have first-hand knowledge about. Our primary duty, however, is to advocate for Uniswap’s success. While our post might, in hindsight, contain some inaccuracies, it was made with good intentions after reviewing publicly available documentation and included an open offer to utilize your technology — importantly, many of the core criticisms remain.
Regarding the only owner functions. We’ll edit our prior post to reflect that change. Thank you for the clarification.
This seems clearly misleading as the two parties (oracle and relayer) are abstracted accounts with arbitrary implementation e.g. a fully decentralized network, not to mention the current proposal which I had assumed GFX Labs had reviewed extensively prior to this is for a new architecture with a number of major Uniswap delegates participating within the validation set.
LayerZero is running the Relayer, and Chainlink is running the Oracle. While these are independent entities of which multiple could theoretically exist to process messages, only two exist at this time. This is functionally a 2/2 multisig, both parties must agree; otherwise, the message will not be processed. We were able to find information on how to run an oracle, but as you said, the existing relayer is currently closed source, and we cannot find an MVP example for a full relayer setup (both on and off-chain components).
As for the unique signing model proposed, we’ve discussed with a few delegates about utilizing a multisig for UniV3 deployments over a bridge and came to the rough conclusion that delegates would not be comfortable being on that multisig due to the perceived legal risks. Our intent is not to need additional signers. Thus our efforts have been put toward finding a bridge partner. The recommendation of additional signers seems to speak to the lack of parties participating in Layerzero 0.
Suppose Uniswap was to consider the signer method. Would it not make the most sense to utilize Chainlink’s Oracle system directly, with the Uniswap signers filling the role as the relayer? It seems that would be the strongest combination because the alternative would be to remove the most secure component (Chainlink) from the stack and replace it with the least secure solution (Uniswap Signers).
The current recommended configuration is secured by Chainlink as an oracle entity (currently securing tens of billions of dollars) and the LayerZero Labs (currently securing billions in TVL) operated relayer entity.
To make sure we are on the same page - is this also the only current possible configuration, assuming that Uniswap does not take charge of the Oracle or Bridge duties?
In a competitive marketplace of Oracles and Relayers, unique pricing mechanisms are often the proprietary edge for providers. These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.
If this is the case, then what is the true cost of using L0 as a relayer? Assuming that Uniswap will not move to run its own relayer, is there any other mechanism to prevent a monopolistic relayer from price-gouging messages through an upgrade? If not, how quickly would Uniswap be able to modify its cross-chain infrastructure such that it could continue performing cross-chain messaging at a reasonable price?
Thank you for the clarification.
While that makes sense, we think it would have saved a lot of time for everyone if the owner functionality was better documented.
I hope the line by line was helpful. I know we haven’t gotten to speak yet but looking forward to speaking to GFX Labs tomorrow and addressing any outstanding concerns and walking through the proposed security configuration in detail.
Thank you for the prompt answers. We appreciate the clarification, and I’m sure the other delegates reading the thread do as well.
As a final request for now, can you please deploy your proposed system on testnet and link the relevant transactions as we have done with Wormhole? We don’t want to delay the BSC deployment any further than necessary.
We're happy to lead this off and vote to deploy Uniswap on BNB Chain. Thanks to everyone who contributed to the process for the hard work to get this over the line.
Update with rationalehere.
Posting here that I fall into camp that Leighton and Jesse do above.
I abstained from the vote, as I think the process here was unclear and not a comprehensive look at solutions. I also think that singular bridge choices are worse for the ecosystem. Agree with Jesse that competition and choice are best for everyone.
Posting here that I fall into camp that Leighton and Jesse do above.
I abstained from the vote, as I think the process here was unclear and not a comprehensive look at solutions. I also think that singular bridge choices are worse for the ecosystem. Agree with Jesse that competition and choice are best for everyone.
Based on everything above I'd probably lean Layer Zero, but my perspective on the process here is more important to me.
Hi Everyone,
Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we're supportive of the Foundation's move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.
Hi Everyone,
Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we're supportive of the Foundation's move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.
GFX Labs has cast our vote for Wormhole in the current snapshot, and while we've made our concerns about Celer clear in the forum thread, we haven't done the same for Layerzero.
Our primary resources for researching Layerzero
For context, Layerzero messages are sent from the local Endpoint. Oracles are responsible for moving block headers from the source to the destination. Upon delivery, Relayers can deliver the transaction's proof to the destination Endpoint. This model, in its current implementation, is a 2-of-2 msig.
Messages are sent to a verifying library. The verifying library (VL) manages oracles and Relayers on behalf of the application. The Ultra Light Node (ULN) is a VL. The Endpoint manages the relationship between the user application (UA) and the VL (the ULN, in practice). The UA selects a VL via the Endpoint. The UA may also configure that VL directly (e.g. by selecting a Relayer in the VL). Relayers submit proofs to the VL (the ULN, in practice), and the VL chooses how to validate these. In the ULN, the owner chooses proof validation libraries and may choose any contract.
Applications are intended to choose their own VL & Relayer since they can configure which library to use in the Endpoint contract. The Endpoint owner sets a default VL. However, the ULN is the only verifying library that exists, so all apps must use it.
We tried to review how the Relayer worked, but according to the docs the Relayer is not open-source at this time, which seems to line up with L2Beat's concern of the Relayer contract being unverified.
Additionally, the only info we found in the governance section was "info coming soon!" This was not the answer we were expecting since there is an owner on the Ethereum Endpoint and UltraLightNodev2 contracts. The owner appears to be a 2/5 Gnosis Multisig. While the Endpoint isn't a traditional proxy contract, it does rely upon referenced contracts for core logic and operation. The below owner controllable functions appear to be able to alter the functionality significantly.
onlyOwner functions on the EndPoint contract:
onlyOwner functions on the UltraLightNodeV2 contract:
The ULN's owner can set the oracle, relay, proof systems, and other security parameters. It appears that the owner can entirely bypass the oracle/relay system in their current implementation.
Through this process, we arrived at the conclusion that Layerzero is not ready to be integrated with Uniswap. However, as developers ourselves, do we realize that the development process is fluid and that research is ongoing. Our vote reflects the current state of development and available information.
I'm voting for LayerZero because based on my reading of the thread & professional experience I believe that is the best option.
I would note though, if there was an abstain / wait option I would've chosen that. I do not believe this is the type of decision that is well suited for a token vote. I'm a big fan of @devinwalsh's plan to form a committee to evaluate options in depth and I would follow the recommendations there.
I'm voting for LayerZero because based on my reading of the thread & professional experience I believe that is the best option.
I would note though, if there was an abstain / wait option I would've chosen that. I do not believe this is the type of decision that is well suited for a token vote. I'm a big fan of @devinwalsh's plan to form a committee to evaluate options in depth and I would follow the recommendations there.
I also question if a bridge is even strictly needed right now. Since its only bridging governance commands presumably this could be added later? I'd prefer that option.
Hi all, note that the Snapshot poll on which bridge to use for the BSC deployment is live now: https://snapshot.org/#/uniswap/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852
Hey all, it's Abdullah from Blockchain at Michigan
Firstly, we are glad to see the community's ability to coordinate an unorthodox approach for deciding the Uni<>BNB bridge via an extra temp check. In an instance like this, it is imperative that we derive a quantitative measure for what the community is feeling as opposed to a soft metric like forum-based sentiment.
Hey all, it's Abdullah from Blockchain at Michigan
Firstly, we are glad to see the community's ability to coordinate an unorthodox approach for deciding the Uni<>BNB bridge via an extra temp check. In an instance like this, it is imperative that we derive a quantitative measure for what the community is feeling as opposed to a soft metric like forum-based sentiment.
To that end, we believe that instead of prolonging the bridge discussion beyond necessary means, it is important for us to efficiently decide on a single messaging system. After one solution is implemented, we can focus on a multi-bridge system. The primary reason for this haste, as @Porter mentioned, is the limited amount of time we have to deploy Uni v3 prior to the license expiring on April 1st of this year. Perhaps this urgency is not warranted for other L1s--but for BNB Chain, quick deployment is necessary due to the BNB community's hankering to quickly deploy forked code (the BNB ecosystem is very much quantity over quality at the moment) and capture much of the present user activity.
As of now, we are inclined to side with LayerZero for handling cross-chain governance. We put Wormhole and Celer in a similar bucket due to their reliance on a validator set, emblematic of a proof of authority mechanism. Naturally, such designs are less decentralized and subject to collusion.
Potentially, Celer's current total stake is not large enough from a dollar-value standpoint to be secure. Over time, this should resolve since the ability of an entity to buy up 2/3 of staking dominance will become harder--granted the SGN system proves viable over time and the CELR token remains strong. As for Wormhole, they have stood the test of a major exploit and have since made their system more robust, with a continual promise to prevent future exploits via a large bug bounty program and a multitude of audits. However, our main contention with Wormhole is, again, the limited 19-entity validator set. We realize the credibility of the guardians and how much stake they have to lose from a reputation perspective. But when the going gets tough, entities often focus on doing whatever they can to merely survive, forgoing their pristine reputation.
We are not limiting the merits of Wormhole or Celer; however, we feel that when the option to select a system that allows for a higher degree of control over the messaging stack is present, we should select that method. LayerZero would allow the Uni community to control its parameters (oracle and relayer) however it deems fit without the risk of collusion between a handful of validators. Yes, the risk assumption for LZ is that the relayer and oracle are themselves uncorrupted--Uniswap is not likely to face this issue. Unlike other applications using LZ, Uniswap has a robust, distributed governance base. The alteration of the relayer and oracle would require the community to collectively decide parameters, making malicious activity very difficult. That is, unless a hacker alters the parameters by subverting the governance process somehow.
We will cast our vote later tonight after our final discussions with Jump and LayerZero.
We're supportive of this plan of action (new snapshot soonish, gov vote close behind) for this particular case. Also very much into pursuing both a formal review process for bridge providers and investigating a multi-bridge solution as @AlexSmirnov lays out in a subsequent comment as a separate endeavor following the BNB Chain. I think each of those subsequent actions require some thought around the resources that'll be required for their implementation and we'd be better served considering them in isolation rather than as a component of another proposal.
Hi all! Thank you for your comments and discussion over the past few days. As you have seen in the forum, new information on the bridge selected in the Temp Check proposal (Celer) has been made available since the Temp Check took place. Additionally, two new bridges -- Wormhole and Layerzero -- have raised their hands to be the provider for the BNB deployment (in addition to deBridge, the initial bridge selected prior to Celer).
For cross-chain deployment proposals, we believe it is most important to optimize for protocol security — specifically, for community members to be able to make informed decisions based on all available information on risks to bridge security. Secondary to that is clarity of process for all governance stakeholders. In order to satisfy both of those conditions, we propose the following next steps for this BNB proposal:
Hi all! Thank you for your comments and discussion over the past few days. As you have seen in the forum, new information on the bridge selected in the Temp Check proposal (Celer) has been made available since the Temp Check took place. Additionally, two new bridges -- Wormhole and Layerzero -- have raised their hands to be the provider for the BNB deployment (in addition to deBridge, the initial bridge selected prior to Celer).
For cross-chain deployment proposals, we believe it is most important to optimize for protocol security — specifically, for community members to be able to make informed decisions based on all available information on risks to bridge security. Secondary to that is clarity of process for all governance stakeholders. In order to satisfy both of those conditions, we propose the following next steps for this BNB proposal:
Looking forward, it is clear that cross-chain proposals can be improved for all governance stakeholders. Assessments of bridge security are time intensive and require significant technical expertise and context. Tomorrow morning in a new forum post, we plan to propose an initiative which aims to provide the community with an independent technical assessment of bridge risk for the community’s benefit. We plan to move this initiative forward ASAP so the results may be leveraged in upcoming cross-chain proposals.
Hi @modong,
While we appreciate your reply to questions and concerns, we do not feel as though you sufficiently addressed them.
From our post we raised the following concerns and questions:
Hi @modong,
While we appreciate your reply to questions and concerns, we do not feel as though you sufficiently addressed them.
From our post we raised the following concerns and questions:
The Message Bus contract has an owner which can upgrade the contract implementation, thereby changing the logic.
We don't know who the EOAs are on the SimpleGovernance contract.
You did not share any further documentation on your "optimistic-rollup-style" security model.
You did not share any further documentation regarding running an app guardian.
In your reply to said the following:
However, if a matching transaction is not found (indicating a problem with the bridge), the App Guardian can halt the asset bridge smart contract, preventing any malicious transactions from executing and safeguarding funds.
If we are understanding this correctly, the App Guardian has the ability to pause the bridge contract autonomously if no matching transaction is found. Can you please confirm this point or point us toward documentation?
Also, the current cBridge contract on BSC appears to have six Pausers. Of which, all but one are also on the governance contract.
0x1a0aec0fc48f1b5cc538be74a90e340b278189e4
0x2fb8783c14a71c08bfc1de8fc3d715dd93039bf2
0x9f6b03cb6d8ab8239cf1045ab28b9df43dfcc823
0x34dfa1226f8b3e36fe597b34eea809a2b5c0bbf9
0xdfe4f07d1f36b8d559b25082460a4f6a72531de2
0x1b9dfc56e38b0f92448659c114e2347bd803911c
Our governance process involves a community voting process, and the execution of governance decisions for on-chain contract upgrades is carried out by a subset of validators including InfStone, Binance Staking, OKEX and Celer Foundation.
Do you have some documentation you could share on the above quote?
Separately, to address your latest post, "A Vender-lock-in-free Universal Governance Mechanism," this forum thread is only regarding the BSC deployment.
Thanks for the deep analytics and numbers, but I think we as a Uniswap community should evaluate and compare first the security part of different solutions.
I also do not rule out that the following proposals for BNB and other chains may use different cross-chain solutions and not rely on a single point of failure.
Hi Everyone,
In light of our concerns with Celer, we thought we should propose a solution to the Uniswap Community. To effectively but quickly evaluate cross-chain messaging protocols, we came up with a few key criteria to asses protocols.
Hi Everyone,
In light of our concerns with Celer, we thought we should propose a solution to the Uniswap Community. To effectively but quickly evaluate cross-chain messaging protocols, we came up with a few key criteria to asses protocols.
It's a mix of subjective and objective items that have helped us navigate the space. Through this process, Wormhole stood out to us, so we decided to see how the rubber met the road. To best understand the technology, we deployed a copy of Uniswap v3 onto BSC's testnet and developed a message sender and receiver contract.
Deployed Contract Addresses
Transactions
The current flow:
consistencyLevel to 1, it will wait for finality. Once the Verified Action Approval (VAA) is published, then we may proceed.There are three key points. First, the Uniswap Message Receiver must verify the sender is the Uniswap Message Sender. Second, the content received must be the content sent. Third, the message must not have been previously executed.
We would love it if the community reviewed our work. We believe utilizing this configuration for the BSC deployment makes the most sense. If we proceed with this implementation, we'll conduct an additional test to verify this works with the Uniswap Governance system and coordinate with Ilia.
On a related note, from having spoken with the Wormhole team, it's our understanding that Wormhole is also preparing a forum post with additional information.
I plan to do a temperature check this week!
Thank you - this is helpful.
As for the number and identity of the SGN of validators - looks like there are 21, who are identified here? https://sgn.celer.network/#/staking
So all 21 of these validators would also be running the App Guardian software for Uniswap. I'm definitely interested in potentially having an additional App Guardian run on Uniswap's behalf so will follow up with you on that.
Hi Everyone,
We've been doing a bit of research on the testnet deployment. Below is a list of the immediately relevant contracts:
Test use of the Celer Messaging system:
Thank you! In this case, would Uniswap have to commission SGN to run an App Guardian? I don't know of anyone running one for Uniswap today.What would the process be to do that?
And, in that case, would there only be 1 App Guardian confirming messages against Ethereum during the delay period? How many Guardians are deployed for other apps - would it be wise to commission multiple?
Thank you! In this case, would Uniswap have to commission SGN to run an App Guardian? I don't know of anyone running one for Uniswap today.What would the process be to do that?
And, in that case, would there only be 1 App Guardian confirming messages against Ethereum during the delay period? How many Guardians are deployed for other apps - would it be wise to commission multiple?
Correct me if I'm misunderstanding anything here.
Here is some background of the 0xPlasma Labs Team:
DAILY ACTIVE USERS BY BLOCKCHAIN
Thank you @ilia_0x for this post! The UF is in support of this proposal generally, and believe launching on BSC would be beneficial for the Uniswap ecosystem.
I do have a few questions I'd like to ask to benefit Uniswap delegates.
Hi Everyone,
We've been doing a bit of research on the testnet deployment. Below is a list of the immediately relevant contracts:
Test use of the Celer Messaging system:
At a high level, we can see the Uniswap v3 protocol has been deployed on testnet and that Celer successfully passed a message from an EOA on Goerli, which implemented an additional fee tier on the BSC testnet deployment.
Overall, we're pleased with the work that Ilia and his team have performed.
However, in reading through Celer's deployed contracts and documentation, we have a few concerns and questions we would like addressed.
The Message Bus contracts on Ethereum and BSC mainnet have an owner role. The owner controls access to the following functions: setFeePerByte, setFeeBase, setLiquidityBridge, setPegBridge, setPegVault, setPegBridgeV2, setPegVaultV2, and transfer ownership. In addition to this access, since the contract is upgradable, the owner is able to upgrade the implementation of the contract, which means anything is possible. The owner on the Message Bus contracts is the "SimpleGovernance" contract. However, the governance contract functions akin to a multisig since it has five voters with equal voting power. We were unable to find information regarding the five EOAs on the contract, however they appear to be active.
After reading through the contracts, we tried to find more information on how their "Optimistic-rollup-style" security model works. We were able to find this blog post & doc page, but it only had the same information from the forum post. We did find this reference to a "DelayedTransfer", but it is unclear how this is "optimistic-like" rather than a simple delay.
We were also unable to find documentation or implementation instructions for running an app guardian. If the Celer team could please share the technical documentation and implementation of their proposed security model, we would appreciate it.
While the messaging contract appears to have been audited, their audits are from PeckShield & Slow Mist which do not inspire a high degree of confidence. Both audits were conducted in February 2022, before the addition of the delay mechanism.
We continue to be supportive of a Uniswap v3 deployment on BSC; however, the Celer team controlling ownership of the Message Bus and limited information on the security model makes it hard for us to support the proposal.
Additional Resources:
Here is some background of the 0xPlasma Labs Team:
0xPlasma Labs past commitments for Uniswap:
0xPlasma Labs current commitments:
Thank you @ilia_0x for this post! The UF is in support of this proposal generally, and believe launching on BSC would be beneficial for the Uniswap ecosystem.
I do have a few questions I'd like to ask to benefit Uniswap delegates.
I have a few questions on the Hyperloop bridge as well, below.
When will Hyperloop be deployed - how much has it been tested?
Can you provide more detail on this comment "Bridge Executors can’t pass an incorrect message or change the content. Importantly, we’ll be building out additional safety functionality and monitoring off & on-chain activity. ". It sounds like due to the existence of WatchTowers, that it is possible for Executors to pass incorrect (or potentially malicious) messages. What are the conditions under which a malicious/incorrect message could be passed to the BSC deployment?
How many Executors and WatchTowers are there today, and who are they?
Thank you again for pushing this proposal forward. Again, we are in favor of a BSC deployment, but first think the community would benefit from more detail on the points above.
Based on the new governance process, we think you need to wait seven days, and then you can make the temperature check. The temperature check needs to reach 10m For votes to advance to an on-chain vote.
As for us, we're going to research some options for the cross-chain governance piece and will follow up next week.
Thank you for participating in our conversation and for your feedback on the bridge topic of this proposal.
I believe the Uniswap community understands and evaluates the risks of cross-chain governance messaging using the current bridge infrastructure. As many chains, where Uniswap v3 will be deployed in 2023, don't have a zk or optimistic bridges, we have to rely on other trusted providers of bridge infrastructure. That's why I proposed a list of the potential bridges (deBridge, Celer, Stargate, Layer Zero) to proceed with the feather governance voting on a new chain.
Thank you for participating in our conversation and for your feedback on the bridge topic of this proposal.
I believe the Uniswap community understands and evaluates the risks of cross-chain governance messaging using the current bridge infrastructure. As many chains, where Uniswap v3 will be deployed in 2023, don't have a zk or optimistic bridges, we have to rely on other trusted providers of bridge infrastructure. That's why I proposed a list of the potential bridges (deBridge, Celer, Stargate, Layer Zero) to proceed with the feather governance voting on a new chain.
Also, the bridge risk can only arise on subsequent votes regarding fees in the protocol, and potential financial risk can only be expressed in a maximum of a couple of hundred thousand dollars not earned by liquidity providers in a short period of time. Ultimately, this risk cannot affect the liquidity allocated in the protocol. And also this bridge risk is not affecting the initial protocol deployment for this proposal.
The initial Uniswap v3 protocol deployment to BNB chain (or to any other chain) will include all fee tiers (1, 0.3, 0.05, 0.01) so probably the governance won't touch the protocol for the entire year or two. This period will be more than enough to explore the most trusted bridge infrastructure until the next on-chain proposal for Uniswap on BNB chain.
Looking forward to further discussion.
Thank you for the information and feedback. What do you think we need to review and prepare regarding BNB<>Uni before we move to the temperature check stage?
While GFX Labs isn't a BSC user, we agree that BSC has a significant number of funds and users, so it is worth considering a Uni v3 deployment to BSC.
DeFi Llama has the overall TVL of DeFi at $41B, of which $24B is on Ethereum. The second largest is BSC at $4.5B. Pancake Swap has $2.35B in TVL. Dune reports BSC as having 753k weekly users. Even if that is off by 90%, that is still a significant number of users Uniswap should be pursuing.
While GFX Labs isn't a BSC user, we agree that BSC has a significant number of funds and users, so it is worth considering a Uni v3 deployment to BSC.
DeFi Llama has the overall TVL of DeFi at $41B, of which $24B is on Ethereum. The second largest is BSC at $4.5B. Pancake Swap has $2.35B in TVL. Dune reports BSC as having 753k weekly users. Even if that is off by 90%, that is still a significant number of users Uniswap should be pursuing.
The top pairs on Pancake Swap by 7 day volume:
| Pair | 7 day volume | Liquidity |
|---|---|---|
| WBNB/BUSD | $122m | $160m |
| USDT/WBNB | $111m | $117m |
| TIME/USDT | $35m | $9m |
| USDT/BUSD | $21m | $94m |
| CAKE/WBNB | $16m | $189m |
| ETH/WBNB | $16m | $50m |
| BNX/BUSD | $15m | $18m |
| BTCB/WBNB | $10m | $41m |
| BTCB/BUSD | $10m | $50m |
| CAKE/BUSD | $8m | $14m |
Uniswap v3 is positioned to compete significantly with Pancake Swap because their pools are Uniswap v2 which aren't as capital efficient. For example, Quickswap's market share on Polygon has almost been totally eroded since Uniswap v3 was deployed.
Overall, we think a deployment would make sense, but we will conduct more research and talk with other voters before formally supporting the proposal. Perhaps the protocol can target an on-chain vote in early January.
Relevant Dune dashboards:
Ethereum vs Binance Smart Chain by beliefanx
Messari: Polygon Uniswap by Messari
PancakeSwap v2 Swap Metrics by hsc
Polygon - Uniswap vs. Quickswap by wanxin
0xPlasma Labs has already deployed and tested Uniswap v3 Protocol on BNB testnet. You can find all contracts using BNB testnet explorer: https://testnet.bscscan.com/
Here is a deployment log:
0xPlasma Labs has already deployed and tested Uniswap v3 Protocol on BNB testnet. You can find all contracts using BNB testnet explorer: https://testnet.bscscan.com/
Here is a deployment log:
Step 1 complete [
{
message: 'Contract UniswapV3Factory deployed',
address: '0x36fc68cd9D7fbD5d1C8Fb2c5920696108ee870E9',
hash: '0xfa5a826e1c97e8a5d0f0202678b5b2238af368f35e3891001dffbd2e7e66329c'
}
]
Step 2 complete [
{
message: 'UniswapV3Factory added a new fee tier 1 bps with tick spacing 1',
hash: '0xf16f757ef3121ff949812a370ebef3ca28a05c0f3f203fe97de1cc9c8cc18222'
}
]
Step 3 complete [
{
message: 'Contract UniswapInterfaceMulticall deployed',
address: '0x343F50D46A779aF57E4148396A53CFe4578aAc52',
hash: '0xd44a4703d5b0d3b746990919838937f26647a05867d6c22e35f5518ee307085f'
}
]
Step 4 complete [
{
message: 'Contract ProxyAdmin deployed',
address: '0x186b19053d23C90C79E9E1651a1E3C6A9cEC182A',
hash: '0x7435f897beb8eb1b8c74d122913baaeefe008c285568c364defe5f2b2353eba3'
}
]
Step 5 complete [
{
message: 'Contract TickLens deployed',
address: '0x6f7676394DfBE14983Add5D637572c5aaA3D3fec',
hash: '0x0d579eba7fe99e3a8c3c47d36b0f0553244a02fce97da65f6e050b619514442b'
}
]
Step 6 complete [
{
message: 'Library NFTDescriptor deployed',
address: '0x6482212a7DBf4619FD3cb0c904b032C1Fa249052',
hash: '0x937b093fc5b2f1e161167966bbd9fbe12c1a9382507eac1d9e1f1a2cb168ddb6'
}
]
Step 7 complete [
{
message: 'Contract NonfungibleTokenPositionDescriptor deployed',
address: '0x4b6aA5198362A6CBFd41952CCc751005C8E01A2B',
hash: '0xd0ab37b493abb859d39d021eece18ca8dbbdb1e3e0b93e58193431fe86712130'
}
]
Step 8 complete [
{
message: 'Contract TransparentUpgradeableProxy deployed',
address: '0x3072c436626d66442ba17A6a2f4A35c7020691d1',
hash: '0xb16d218559b11cf22a75fd63e09db4bc1b90a43374898f1ecd74d25321ac7039'
}
]
Step 9 complete [
{
message: 'Contract NonfungiblePositionManager deployed',
address: '0xF235795E939A2A6076E82B8434649f5BcF9B9637',
hash: '0x7ce1d2286cfc6fb7602d3b4165dacfb8ffce2ce0eddc10843ecc4eb2d1c73e08'
}
]
Step 10 complete [
{
message: 'Contract V3Migrator deployed',
address: '0x0c2F7954138C4b4EBa07d4570F13Fd9ACF5125b0',
hash: '0x45aa608893dbee97f7e1138b9e4a32271252135605f96c91775667b7176e804b'
}
]
Step 11 complete [
{
message: 'UniswapV3Factory owned by 0xf41da34fe2839959013480AD81D982638840A6D6 already'
}
]
Step 12 complete [
{
message: 'Contract UniswapV3Staker deployed',
address: '0xAf589B83EDE930400c3Ff6D629cf1DA325dD2907',
hash: '0xe205a92bcc4464c16aeae9154d4f2eeb61019a0512470861463a579d0db5793e'
}
]
Step 13 complete [
{
message: 'Contract QuoterV2 deployed',
address: '0x4db0186D8d9E424e8FcBf25c575087EBb08e0332',
hash: '0x3243c301e760b26a8425fcf21a7b4a8d9e28019d3b8fcc5f0b978867b446602f'
}
]
Step 14 complete [
{
message: 'Contract SwapRouter02 deployed',
address: '0xdc1Ad7d941334CcbF3CAcd2ae667D54019395C9a',
hash: '0x8e0eb57880da4f05216bd1b88a0f99ccf688d1f56c95ef34b46dcb37777473f7'
}
]
Step 15 complete [
{
message: 'ProxyAdmin owned by 0xf41da34fe2839959013480AD81D982638840A6D6 already'
}
]
Deployment succeeded
Let's schedule a community call on Discord and Twitter Space for Uni and BNB community?
Hi Everyone,
We've been doing a bit of research on the testnet deployment. Below is a list of the immediately relevant contracts:
Test use of the Celer Messaging system:
At a high level, we can see the Uniswap v3 protocol has been deployed on testnet and that Celer successfully passed a message from an EOA on Goerli, which implemented an additional fee tier on the BSC testnet deployment.
Overall, we're pleased with the work that Ilia and his team have performed.
However, in reading through Celer's deployed contracts and documentation, we have a few concerns and questions we would like addressed.
The Message Bus contracts on Ethereum and BSC mainnet have an owner role. The owner controls access to the following functions: setFeePerByte, setFeeBase, setLiquidityBridge, setPegBridge, setPegVault, setPegBridgeV2, setPegVaultV2, and transfer ownership. In addition to this access, since the contract is upgradable, the owner is able to upgrade the implementation of the contract, which means anything is possible. The owner on the Message Bus contracts is the "SimpleGovernance" contract. However, the governance contract functions akin to a multisig since it has five voters with equal voting power. We were unable to find information regarding the five EOAs on the contract, however they appear to be active.
After reading through the contracts, we tried to find more information on how their "Optimistic-rollup-style" security model works. We were able to find this blog post & doc page, but it only had the same information from the forum post. We did find this reference to a "DelayedTransfer", but it is unclear how this is "optimistic-like" rather than a simple delay.
We were also unable to find documentation or implementation instructions for running an app guardian. If the Celer team could please share the technical documentation and implementation of their proposed security model, we would appreciate it.
While the messaging contract appears to have been audited, their audits are from PeckShield & Slow Mist which do not inspire a high degree of confidence. Both audits were conducted in February 2022, before the addition of the delay mechanism.
We continue to be supportive of a Uniswap v3 deployment on BSC; however, the Celer team controlling ownership of the Message Bus and limited information on the security model makes it hard for us to support the proposal.
Additional Resources:
Here is some background of the 0xPlasma Labs Team:
0xPlasma Labs past commitments for Uniswap:
0xPlasma Labs current commitments:
Thank you @ilia_0x for this post! The UF is in support of this proposal generally, and believe launching on BSC would be beneficial for the Uniswap ecosystem.
I do have a few questions I'd like to ask to benefit Uniswap delegates.
I have a few questions on the Hyperloop bridge as well, below.
When will Hyperloop be deployed - how much has it been tested?
Can you provide more detail on this comment "Bridge Executors can’t pass an incorrect message or change the content. Importantly, we’ll be building out additional safety functionality and monitoring off & on-chain activity. ". It sounds like due to the existence of WatchTowers, that it is possible for Executors to pass incorrect (or potentially malicious) messages. What are the conditions under which a malicious/incorrect message could be passed to the BSC deployment?
How many Executors and WatchTowers are there today, and who are they?
Thank you again for pushing this proposal forward. Again, we are in favor of a BSC deployment, but first think the community would benefit from more detail on the points above.
Based on the new governance process, we think you need to wait seven days, and then you can make the temperature check. The temperature check needs to reach 10m For votes to advance to an on-chain vote.
As for us, we're going to research some options for the cross-chain governance piece and will follow up next week.
Thank you for participating in our conversation and for your feedback on the bridge topic of this proposal.
I believe the Uniswap community understands and evaluates the risks of cross-chain governance messaging using the current bridge infrastructure. As many chains, where Uniswap v3 will be deployed in 2023, don't have a zk or optimistic bridges, we have to rely on other trusted providers of bridge infrastructure. That's why I proposed a list of the potential bridges (deBridge, Celer, Stargate, Layer Zero) to proceed with the feather governance voting on a new chain.
Thank you for participating in our conversation and for your feedback on the bridge topic of this proposal.
I believe the Uniswap community understands and evaluates the risks of cross-chain governance messaging using the current bridge infrastructure. As many chains, where Uniswap v3 will be deployed in 2023, don't have a zk or optimistic bridges, we have to rely on other trusted providers of bridge infrastructure. That's why I proposed a list of the potential bridges (deBridge, Celer, Stargate, Layer Zero) to proceed with the feather governance voting on a new chain.
Also, the bridge risk can only arise on subsequent votes regarding fees in the protocol, and potential financial risk can only be expressed in a maximum of a couple of hundred thousand dollars not earned by liquidity providers in a short period of time. Ultimately, this risk cannot affect the liquidity allocated in the protocol. And also this bridge risk is not affecting the initial protocol deployment for this proposal.
The initial Uniswap v3 protocol deployment to BNB chain (or to any other chain) will include all fee tiers (1, 0.3, 0.05, 0.01) so probably the governance won't touch the protocol for the entire year or two. This period will be more than enough to explore the most trusted bridge infrastructure until the next on-chain proposal for Uniswap on BNB chain.
Looking forward to further discussion.
Thank you for the information and feedback. What do you think we need to review and prepare regarding BNB<>Uni before we move to the temperature check stage?
While GFX Labs isn't a BSC user, we agree that BSC has a significant number of funds and users, so it is worth considering a Uni v3 deployment to BSC.
DeFi Llama has the overall TVL of DeFi at $41B, of which $24B is on Ethereum. The second largest is BSC at $4.5B. Pancake Swap has $2.35B in TVL. Dune reports BSC as having 753k weekly users. Even if that is off by 90%, that is still a significant number of users Uniswap should be pursuing.
While GFX Labs isn't a BSC user, we agree that BSC has a significant number of funds and users, so it is worth considering a Uni v3 deployment to BSC.
DeFi Llama has the overall TVL of DeFi at $41B, of which $24B is on Ethereum. The second largest is BSC at $4.5B. Pancake Swap has $2.35B in TVL. Dune reports BSC as having 753k weekly users. Even if that is off by 90%, that is still a significant number of users Uniswap should be pursuing.
The top pairs on Pancake Swap by 7 day volume:
| Pair | 7 day volume | Liquidity |
|---|---|---|
| WBNB/BUSD | $122m | $160m |
| USDT/WBNB | $111m | $117m |
| TIME/USDT | $35m | $9m |
| USDT/BUSD | $21m | $94m |
| CAKE/WBNB | $16m | $189m |
| ETH/WBNB | $16m | $50m |
| BNX/BUSD | $15m | $18m |
| BTCB/WBNB | $10m | $41m |
| BTCB/BUSD | $10m | $50m |
| CAKE/BUSD | $8m | $14m |
Uniswap v3 is positioned to compete significantly with Pancake Swap because their pools are Uniswap v2 which aren't as capital efficient. For example, Quickswap's market share on Polygon has almost been totally eroded since Uniswap v3 was deployed.
Overall, we think a deployment would make sense, but we will conduct more research and talk with other voters before formally supporting the proposal. Perhaps the protocol can target an on-chain vote in early January.
Relevant Dune dashboards:
Ethereum vs Binance Smart Chain by beliefanx
Messari: Polygon Uniswap by Messari
PancakeSwap v2 Swap Metrics by hsc
Polygon - Uniswap vs. Quickswap by wanxin
0xPlasma Labs has already deployed and tested Uniswap v3 Protocol on BNB testnet. You can find all contracts using BNB testnet explorer: https://testnet.bscscan.com/
Here is a deployment log:
0xPlasma Labs has already deployed and tested Uniswap v3 Protocol on BNB testnet. You can find all contracts using BNB testnet explorer: https://testnet.bscscan.com/
Here is a deployment log:
Step 1 complete [
{
message: 'Contract UniswapV3Factory deployed',
address: '0x36fc68cd9D7fbD5d1C8Fb2c5920696108ee870E9',
hash: '0xfa5a826e1c97e8a5d0f0202678b5b2238af368f35e3891001dffbd2e7e66329c'
}
]
Step 2 complete [
{
message: 'UniswapV3Factory added a new fee tier 1 bps with tick spacing 1',
hash: '0xf16f757ef3121ff949812a370ebef3ca28a05c0f3f203fe97de1cc9c8cc18222'
}
]
Step 3 complete [
{
message: 'Contract UniswapInterfaceMulticall deployed',
address: '0x343F50D46A779aF57E4148396A53CFe4578aAc52',
hash: '0xd44a4703d5b0d3b746990919838937f26647a05867d6c22e35f5518ee307085f'
}
]
Step 4 complete [
{
message: 'Contract ProxyAdmin deployed',
address: '0x186b19053d23C90C79E9E1651a1E3C6A9cEC182A',
hash: '0x7435f897beb8eb1b8c74d122913baaeefe008c285568c364defe5f2b2353eba3'
}
]
Step 5 complete [
{
message: 'Contract TickLens deployed',
address: '0x6f7676394DfBE14983Add5D637572c5aaA3D3fec',
hash: '0x0d579eba7fe99e3a8c3c47d36b0f0553244a02fce97da65f6e050b619514442b'
}
]
Step 6 complete [
{
message: 'Library NFTDescriptor deployed',
address: '0x6482212a7DBf4619FD3cb0c904b032C1Fa249052',
hash: '0x937b093fc5b2f1e161167966bbd9fbe12c1a9382507eac1d9e1f1a2cb168ddb6'
}
]
Step 7 complete [
{
message: 'Contract NonfungibleTokenPositionDescriptor deployed',
address: '0x4b6aA5198362A6CBFd41952CCc751005C8E01A2B',
hash: '0xd0ab37b493abb859d39d021eece18ca8dbbdb1e3e0b93e58193431fe86712130'
}
]
Step 8 complete [
{
message: 'Contract TransparentUpgradeableProxy deployed',
address: '0x3072c436626d66442ba17A6a2f4A35c7020691d1',
hash: '0xb16d218559b11cf22a75fd63e09db4bc1b90a43374898f1ecd74d25321ac7039'
}
]
Step 9 complete [
{
message: 'Contract NonfungiblePositionManager deployed',
address: '0xF235795E939A2A6076E82B8434649f5BcF9B9637',
hash: '0x7ce1d2286cfc6fb7602d3b4165dacfb8ffce2ce0eddc10843ecc4eb2d1c73e08'
}
]
Step 10 complete [
{
message: 'Contract V3Migrator deployed',
address: '0x0c2F7954138C4b4EBa07d4570F13Fd9ACF5125b0',
hash: '0x45aa608893dbee97f7e1138b9e4a32271252135605f96c91775667b7176e804b'
}
]
Step 11 complete [
{
message: 'UniswapV3Factory owned by 0xf41da34fe2839959013480AD81D982638840A6D6 already'
}
]
Step 12 complete [
{
message: 'Contract UniswapV3Staker deployed',
address: '0xAf589B83EDE930400c3Ff6D629cf1DA325dD2907',
hash: '0xe205a92bcc4464c16aeae9154d4f2eeb61019a0512470861463a579d0db5793e'
}
]
Step 13 complete [
{
message: 'Contract QuoterV2 deployed',
address: '0x4db0186D8d9E424e8FcBf25c575087EBb08e0332',
hash: '0x3243c301e760b26a8425fcf21a7b4a8d9e28019d3b8fcc5f0b978867b446602f'
}
]
Step 14 complete [
{
message: 'Contract SwapRouter02 deployed',
address: '0xdc1Ad7d941334CcbF3CAcd2ae667D54019395C9a',
hash: '0x8e0eb57880da4f05216bd1b88a0f99ccf688d1f56c95ef34b46dcb37777473f7'
}
]
Step 15 complete [
{
message: 'ProxyAdmin owned by 0xf41da34fe2839959013480AD81D982638840A6D6 already'
}
]
Deployment succeeded
Let's schedule a community call on Discord and Twitter Space for Uni and BNB community?