Hey everyone, reporting back from the Hyperlane team as promised in the above post. Here are answers to the UF’s questionnaire. Before we get started, we want to be clear, we are not proposing that Hyperlane should be picked as a standalone option, and only proposing it be considered as either an implementation option for the MMA design, or one of the options through an MMA design.
-
List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
a. Hyperlane was designed to support customization of security models, including aggregating multiple third party bridges. No protocol changes are needed in order to support this. Any advancements in the field of interchain security can be easily incorporated into a Hyperlane deployment through an Interchain Security Module.
b. As a core team, Hyperlane is very philosophically and ideologically aligned with the Uniswap ethos. We have opted for a design that maximizes permissionless-ness. We work in public. We open-source every bit of our protocol. Utilizing Hyperlane guarantees Uniswap will be choosing a partner that is truly aligned with its mission and values.
Don’t take our word for it, join our discord and see for yourself!c. Hyperlane’s Permissionless Interoperability and overall design means future deployments, even those on non-evm chains, can happen without any need for intervention by Hyperlane core developers.
-
How long has the system been running on mainnet?
V2 has been launched on mainnet for roughly 4 weeks. A similar version of the protocol, V1, has been running for upwards of 6 months.
-
How much value has the system secured? (Current TVL, total transaction volume)
V2 is still fairly new, and a dedicated token bridge product has not yet been launched. Hyperlane’s take on token bridging, Warp Routes, was just launched today. The system has secured over 50k messages on mainnet, and over 300k messages in total.
-
Provide a background on your team.
On the whole, we are a group of crypto natives. >85% of the team has been in crypto for 4-6 years, with the latest additions having 1+ year of crypto experience on average. Our team includes experience from like Gauntlet, Google, Celo, Uniswap, Amazon, Nethermind, Kyve and more. The team is mission driven and is solely focused on expanding the crypto-economy by providing technology to connect blockchains permissionlessly. We believe that by doing so we increase to limits of what is possible, growing the overall potential of the entire industry.
Team founders—
Nam Chu Hoai - Prior to working on Hyperlane, Nam was an early engineer at Celo where he worked on all levels of the stack, from the protocol to the application layer. Prior to Celo he’d been a senior engineer at Wellframe, an enterprise healthcare technology provider. As a teenager, Nam was one of the first developers to build iphone applications via Cydia, prior even to the creation of the appstore! Nam studied Computer Science at Boston University.
Asa Oines - Prior to working on Hyperlane Asa was the first engineer at Celo and the Protocol Lead. At Celo he was the first to write a POS design implemented fully in smart contracts, and played a vital role in all protocol design and architecture decisions. Prior to his work on the Celo protocol, he was an engineer at Google where he worked on Natural Language Processing systems. Asa studied Computer Science at MIT.
Jon Kol - Prior to working on Hyperlane Jon co-lead the investment team at Galaxy Digital, a firm with a wide array of operating businesses within the Crypto industry. In addition to his duties on the investment team he spearheaded a number of the firms operating initiatives, particularly those on the bleeding edge of Crypto. Prior to Galaxy he was a Crypto investor at Passport Capital, and a bond trader at Morgan Stanley. Jon studied Economics at UC Berkeley.
-
Please link your developer documentation.
- Main docs page https://docs.hyperlane.xyz/docs/
- Quickstart guides https://docs.hyperlane.xyz/docs/build-with-hyperlane/quickstarts
- Deploy Hyperlane to your chain of choice https://docs.hyperlane.xyz/docs/deploy/deploy-hyperlane
- Hyperlane Github https://github.com/hyperlane-xyz
- Hyperlane Explorer https://explorer.hyperlane.xyz/
- Hyperlane Discord https://discord.gg/hyperlane
-
Does the bridge support arbitrary message passing?
Yes. You can try it out for yourself and send your first message in minutes!
-
Has the current deployed bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
Yes, V2 has been audited by Hacken, a report is to be published shortly. V1 was previously audited by Hacken and FYEO.
Issues identified by Hacken in the audit were remedied as part of the audit process.
-
Is there a bug bounty program?
Yes, an ImmuneFi program sporting one of the largest bounties on ImmuneFi (6th largest), at $2.5m. The program can be found here: https://immunefi.com/bounty/hyperlane/
-
List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
The Mailbox contract logic is currently upgradeable using the transparent proxy pattern as implemented by Open Zeppelin. Upgradability will be delayed by a [1 week] timelock.
-
Do any contracts have an owner or owner-like entity? If so, what can the owner do?
The Mailbox contracts are owned by a 3/6 multisig with signers from Abacus Works. The owner can change the default ISM. If users do not specify their own ISM, the default ISM will be used to validate inbound messages. The Mailbox proxy contract is also owned by this multisig, which allows the multisig to arbitrarily change the Mailbox bytecode.
-
What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?
Hyperlane’s security model is encoded in Interchain Security Module (ISM) smart contracts. Hyperlane users can specify their own ISM, which encodes their desired trust assumptions. At present, Hyperlane only supports Multisig ISMs, allowing Hyperlane users to specify their own validator set. In the short term, additional ISMs will allow Hyperlane users to mix and match ISMs (e.g. require 5/9 signatures from set A AND 3/3 signatures from set B OR require 9/9 signatures from set A). In the medium term, Hyperlane will support staking and slashing of validators, adding economic security. In the long term, ISMs will be developed for additional security models, including an optimistic ISM and light-client ISMs.
-
How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
In order to pass a fraudulent message from Ethereum to Alice’s smart contract on the destination chain, that adversary would need to compromise the security model specified by Alice’s ISM. If, for example, that ISM specified “require 5/9 signatures from set A AND 3/3 signatures from set B OR require 9/9 signatures from set A”, the adversary would need to compromise 5/9 validators from set A AND 3/3 validators from set B OR 9/9 validators from set A. This could be done by compromising key credentials (typically AWS KMS keys) or convincing validators to run a modified version of the Hyperlane Validator binary that signs a fraudulent Mailbox merkle root. Alternatively, if Alice’s smart contract contains logic to change the ISM, if an adversary were able to assume control of Alice’s contract, they could change to an ISM that they have control over (e.g. require 1/1 signatures from the adversary) and use that to pass fraudulent messages. Finally, if the Abacus Works multisig was compromised, an adversary could upgrade the Mailbox contract on the destination chain to allow passing of fraudulent messages.
-
How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
In order to withhold a valid governance message from Ethereum to Alice’s smart contract on the destination chain, that adversary would need to be able to impact the liveness of the security model specified by Alice’s ISM. If, for example, that ISM specified “require 5/9 signatures from set A AND 3/3 signatures from set B OR require 9/9 signatures from set A”, the adversary would need to be able to censor 5/9 validators from set A OR 1/3 validators from set B. Since Hyperlane validators are not networked with each other, and simply read smart contract state and write to S3 buckets, this would be exceedingly difficult without compromising the machine (or credentials, if run in the cloud) being used to run a validator. If the adversary controls one or more validators, they can withhold signatures, but because validators sign merkle roots, signatures can only be withheld globally. In other words, it is impossible for validators cannot censor some messages but not others without signing a fraudulent merkle root, which in the short term will be grounds for slashing. Finally, the Abacus Works multisig has the ability to pause and unpause the Mailbox contract. When the Mailbox is paused on a destination chain, interchain messages are not deliverable to that chain.
-
What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.
Hyperlane does not yet implement staking, and therefore does not yet implement slashing. Verifying fraud proofs is fairly straightforward, as the Mailbox smart contract on each chain maintains a commitment to the entire history of messages.
-
Provide any additional information you would like here.
- Hyperlane will support the MMA design regardless of whether Hyperlane is chosen as an implementation option for it or not. We believe firmly reliance on a single provider for security is against the best interests of the protocol, and hope that delegates and voters can see this to be true. Uniswap must optimize only for security. Safety over every parameter in this case. Latency or cost are completely meaningless in the realm of governance, and the MMA approach is most likely to reduce security risks and maximize safety.
- Hyperlane will be implementing Proof of Stake to provide economic security to users of the protocol. Hyperlane’s design provides strong guarantees regarding the ability to permissionlessly slash without the need for governance, and provides for verifiable fraud proofs.
- The Hyperlane core team is happy to expand on any of the above questions or additional ones at any time. Our public discord is the best place to reach us, alternatively Twitter, or email work just as well.