Obviously, the reason why we’ve been taking our time with our assessment and feedback is precisely the dire need for careful evaluation of all the available options, both from a theoretical model-based and a practical implementation-wise standpoint. Before reaching our informed opinion, we consulted with the bridge teams, conducting interviews with them, and asking for clarifications on many aspects of their design, implementation, and future roadmap choices. In this way, we believe we are fit to weigh in with our feedback for the protocols, and our view on what might best serve Uniswap’s diverse set of needs.
TL;DR: Having universal validators, and not specific to the community served by the bridge provider, is not a good idea for a protocol with as large TVL as Uniswap. On the other hand, optimistic solutions with “fraud proof” designs are riddled with largely ad-hoc “optimistic intervals” which are at the danger of being violated at periods of high gas demand when provers might be priced out of the opportunity to prove fraud, and arbitrary “Watcher griefing” disconnecting communication channels could pose large issues when Watchers are allowed to be fully decentralized (as they should), i.e., everyone (this has been proposed to be mitigated through economic incentives, but with an unclear and unspecified mechanism at work). We propose a synergy between Axelar and 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).
Before we report on our feedback and assessment, it is crucial to highlight that how the concept of “cross-chain governance” will evolve over time may vitally affect our present choice (thanks to Steven Yin for his contributions to the whole discussion). Currently, cross-chain governance is understood as “reflecting the governance decisions on Ethereum on all the other chains”. One possible future is where the voting process itself can be distributed among different chains. This will inevitably require some concept of governance tokens to exist across chains. There are at least two possible approaches to this: 1. bridging existing governance tokens from Ethereum to other chains using a generic bridge, or 2. Creating native governance tokens on each chain. The second approach will require Uniswap to implement its own logic for managing the burn and minting of UNI tokens on different chains, and use a generic message-passing layer to relay the messages. The first approach relegates the control of the minting/burning process to the bridge provider. Since existing bridge providers have more experience with this process, being audited several times, their smart contract code is likely to be more secure than the second approach. Note that the risk of having smart contract vulnerabilities is high, judging from the frequencies of bridge hacks, and the significant TVL of Uniswap. However, there are two downsides to the first approach: a) Uniswap has less control over the token creation/burning process (thus harder to create custom logic in the future), and b) It is harder to migrate to a different setup, essentially enhancing the degree of vendor lock-in that should already be a parameter in our bridge selection thought process, even without expanded cross-chain governance. The aforementioned points are worth considering and deliberating upon, because the present choice will necessarily directly affect the ease (or hardness) of this potential future ability to expand.
Now that we’ve clarified the cross-chain messaging aspect and weighed in on how the current choice might affect future capabilities, before choosing a bridge provider and/or the technology behind it —which is, in our view, the most important aspect of this decision, as also delineated by Other Internet, in their thought process— we should keep in mind that Uniswap has a massive TVL, which significantly affects the economic incentives that are ingrained (directly or indirectly) in the bridging mechanism.
Implementation-wise, we believe that there is an important gap that needs to be addressed in order for any of the current bridge providers to be adopted into a fully-fledged cross-chain Uniswap governance parameter update mechanism. It is not clear to us which organization is the one that should assist with this; should this be the bridge provider itself, as implied by Other Internet’s RFC? There’s benefits for and arguments against both; in short, requiring the bridge provider to perform a significant part of this development could draw from critical resources that sustain the security and other features of the bridge: this might not be fair (for bridge providers whose methodologies are still in various phases of development, with meritorious models but not mainnet implementation-ready) or efficient. On the other hand, if someone outside of the bridge provider is tasked with this, it would be expected that there should be some kind of offer solicitation for this specific task, along with auditing of the final solution. As mentioned in the post above, this is where it is most beneficial for a potential legal agreement to kick in, and we will leave it up to further discussion from the community.
For our model-based analysis, which we believe to be the rather significant part of the feedback we give (given that no solution is requested to be “plug-and-play”; c.f., Implementation above, and there has been already Other Internet’s analysis of funding, reputability, and audits for the various protocols), we will begin with a general principle which we deem crucial not to be violated: Stakeholders should participate in the validator set, to make sure that the incentives are correctly aligned. Another way to make sure that this could happen is, as Other Internet suggested, to have an optimistic solution, where again every stakeholder of the community would potentially be able to provide fraud claims, shall a malicious message be found in the network. Nevertheless, the issues with the optimistic window length, along with the possibility of censoring, make this, in our view, an inferior solution to providing a solid validator-based approach.
We begin with LayerZero, which we deem to be a generic message-passing framework. Their model is all-powerful, allowing the specification of custom Oracle/Relayer combinations for each protocol by themselves (or adopt the default configuration, which then becomes a central validator set). For the reasons delineated above, the default configuration should be ruled out for protocols with massive TVL, i.e., Uniswap. The custom configuration with the ability to have major UNI holders acting as a collective Oracle in a custom-designed system would be our proposal. However, this maximum configurability in terms of message validation specifics (which includes choosing the setup of an oracle-relayer system at a protocol-specific level), security parameters, and utilized libraries of the ecosystem, comes potentially at the expense of ease of use and out-of-the-box setup (again, only given the custom desired configuration). This configurability, of course, has immense advantage on security guarantees in separating different risk entities (participating protocols in the cross-chain communication system), in case of corruption/malice of some validating entity/ies. Similar guarantees can be achieved via including an appropriately diverse set of validating entities (see Generic Principle above). As noticed, though, we believe that the complexity of an appropriate design to achieve the guarantees evidenced above may not be within the current scope of Uniswap’s abilities.
We continue with Wormhole, which has a large team due to Jump and as a result, has implemented, staged for production, and is actively developing a wide variety of features with robust guarantees. There is a central set of 19 validators, which is a significantly large value contributing to decentralization compared to other central-validator-based bridges. One of the core trust assumptions of Wormhole’s model is the attributability of the message attestations of Guardians by means of their signatures in the (currently multi-sig) scheme. Due to this characteristic, the Guardians have their reputation as well as ownership of protocol shares at stake. Without this attributability, further research is definitely needed to correctly incentivize participants. There is also a governance-controlled per-message fee, whose change is unpredictable in unforeseen circumstances, and whose interplay with potential cross-chain vendor lock-in needs to be taken into account. In summary, we think that Wormhole is the most implementation-ready out of many providers we examined, but in terms of the model, it isn’t there just yet (because of adjustments before its model passes our checks and balances). We would suggest that they add various customizable per-application aspects to lower the systemic risk, and in particular add the ability for a protocol to have a Custom Guardian Set.
For Nomad, and in general optimistic-based solution approaches (we will not deal here with the necessarily dire implications of the recent hack but only examine the general model), we believe they are clearly surpassed by appropriate validator-based PoS systems, by virtue of their safety guarantees. Here, we disagree with Other Internet that the optimistic model has better security/safety guarantees than the latter. Such a statement would generally hold for a Layer-1/2 on the same chain implementing fraud proofs that can be verified in an austere way (absolutely verifiable by virtue of only on-current-chain elements). Let’s delve into some definitions to further analyze that: the term “optimism” generally confounds two different desiderata which shouldn’t be confounded: 1. vanilla optimism would be that “transactions are always considered valid, unless otherwise indicated,” and 2. the “otherwise indicated”, i.e., when a fraud proof is furnished, means that the fraud proof needs to be an actually true proof (i.e., verifiable by an honest observer who can prove this only on one chain) of the fact that the signed transaction doesn’t correspond to the current state of the (other) chain. However, critically, Nomad’s Watchers can arbitrarily decide to “grief”, closing the communication channel, and the 2nd part of the above desiderata is not being fulfilled (there has been a proposal by Nomad team contributors to integrate economic incentives in order to override that, but to this day, no specific mechanisms which would need to also be analyzed). There is certainly interesting research to improve upon this (sadly, research shows this might end up being very chain-consensus-specific), but the practical system currently implemented doesn’t satisfy the generic claim that same-chain optimistic mechanisms (e.g., L2s) enjoy.
For Abacus, we believe that the idea of application-specific sovereign consensus is a very good idea matching our General Principle above. In accordance to this, sovereign consensus would necessarily be utilized by Uniswap’s implementation, and the protocol would be able to combine the benefits of both a default setup with trusted nodes (the 4/5 configuration, e.g.) along with a custom setup of UNI stakeholders as a custom validator set. This application-specific set makes sure that the future of the Uniswap ecosystem is safeguarded from actors which could turn potentially malicious or adversely affected by central decisions (systemic risk). Our suggestion for what we would like to see in this protocol before we say that its model is theoretically robust is to integrate potential weighting of the custom validators in the custom validator set for sovereign consensus in an efficient way, as well as allow to easily change the custom validator set dynamically in real-time. Because we believe that this is served 100% by adding a PoS permissionless system for the custom validators, we continue this below inside our Axelar analysis.
For Axelar, which is the only true permissionless validator-set system, we think that the PoS consensus system to verify any message is truly the state-of-the-art, subject to the General Principle above, i.e., that the stakeholders of an ecosystem with large TVL would participate in this PoS scheme. When this happens, then the system would effectively engage the underlying stakeholders (if needed; if not, then the default PoS participants can provide the consensus), who have no economic incentive to override and lie about their own decisions. What we are lacking currently from this system, and we highly suggest to the team that it be integrated, is application-specificity tightly integrated with default characteristics, akin to the Abacus ones: applications (certainly Uniswap) should be able to, if needed, provide a supermajority of actual protocol governance stakeholders as the consensus mechanism; but under normal conditions, a supermajority of the normal PoS scheme might suffice. We can see the helpfulness of a default configuration with a truly permissionless system of validators (as is currently guaranteed by the AXL token) towards smaller protocols bootstrapping their cross-chain messaging, but also recognize that this default alone might be somewhat inadequate for a protocol with massive TVL at stake.
Lastly, a generic comment on gas costs/efficiency: since the Uniswap community is currently intending to use cross-chain community solely for message-passing the parameter updates (see paragraph on what cross-chain governance means above), it is not necessary to wait for the adoption of either threshold signature schemes or more sophisticated zero-knowledge proofs. While altogether it’s not clear whether zk would provide any benefit whatsoever (in fact, in some of the threat models above, according to our theoretical analysis, zk would even constitute a violation of certain trust assumptions, and might misincentivize validating entities), gas efficiency might be more desirable shall the Uniswap community decide to move on to voting governance proposals on-chain in a multi-chain environment.
We are definitely looking forward to seeing more open discussion in the community!