Mailbox: Support VMs without keccak/ecrecover

[nambrot]

Some VMs may not have either of those which makes Hyperlane support difficult. While ecrecover can to a certain extent be worked around by having validators sign differently in addition, keccak is pretty entrained in the mailbox contract. In a possible V3 it might be nice to have mailboxes be able to use other hashing algos

[HariSeldon23]

Just checked and Ink (Smart contract language on Dotsama also uses Blake).

So would be good to understand what the preferred approach is. Whether that's a trait or something else

[nambrot]

Yeah, we'll spend some more time speccing what that would look like on the contract, agent and sdk side

[nambrot]

Just checked and Ink (Smart contract language on Dotsama also uses Blake).

Does dotsama not support keccak? I know nothing about dotsama, I had just assumed they would from things like polkadot-js/api#2499

---

On the mailbox though, it's not clear to me how non-keccak should be supported, it seems inherent that if origin and destination chain diverge and do not share hashing function support, then you cannot share the same message ID and thus share a view on a merkle tree, and thus share censorship resistance. I believe most EVM chains do not support blake2

[HariSeldon23]

Dotsama has a very modular design system. So they have runtimes which then parachains can choose pallets that they implement. So for example if you were building a Parachain you'd use Substrate (Similar to Cosmos SDK) in order to build it out. You'd then choose which pallets you want to use. So staking, governance, tokens and then smart contract pallets.

Alot of parachains have chosen the EVM smart contract pallet such as Moonbeam which then would by necessity need to support keccak. However ink is the preferred smart contract language as it natively exposes a lot of substrate calls. Think about how precompiles work on EVM for a general idea. But ink only supports Blake from my understanding https://use.ink/datastructures/storage-in-metadata

Another interesting tidbit is that the both Cardano and Polkadot use Ouroboros https://en.wikipedia.org/wiki/Ouroboros_(protocol) so I know there's another fella doing the Cardano integration. Probably a lot of ways we could work together and save each other some time

[HariSeldon23]

In terms of how we'd get this work, I think it has to be done at the Validator level.

So let's say we send message "Hello World", it then gets hashed to keccak -> Gets sent to Validator -> Validator translates hash to get the string "Hello World", then hashes to blake2 and pushes to mailbox on dotsama/Cardano.

Granted I don't know enough about the Hyperlane architecture to determine whether that introduces crazy latency or other security concerns. For example, one thing I've been thinking alot about is cross chain MEV. If validators are translating hashes and using it like a mempool, they could theoretically do all sorts of wonderful MEV.

[HariSeldon23]

Just checked another potential customer and they use SHA256. So there'd have to be a translation middleware. Don't see any other way around it.

No ways you could wait for chains to adopt all hashing algo's else you'd lose market share

[nambrot]

Yeah for sure, writing something up right now to get a spec for non-keccak VM support right now

[daniel-savu]

To answer the question about keccak support in ink!, it's possible to do so via Chain Extensions as long as the parachain runtime exposes a getter for keccak, which is supported in the standard Substrate library.

Another question would be where to deploy the Hyperlane logic. For ink! to be an option, it may be required to go through governance for the host parachain to expose keccak in the runtime. This is likely the fastest path to a working deployment and requires the least operational overhead. The alternative would be to write Hyperlane logic as Substrate pallets and run as a parathread (which is pay-as-you-go as opposed to the parachain slot auctions), but the timeline for parathreads is unclear (hopefully they will be live by the end of the year) and they require running some software.

[HariSeldon23]

imo, the issue with this is that you're reliant on third parties. You'd need a governance vote to get Chain extensions up on the parachain (unless I've misunderstood). Or you have to wait for Parathreads, which isn't ideal imo.

Optimal solution would be having the mailbox and interchain smart contracts written in ink! and then just work out of the box.

You want to abstract all that away from ink! developers. If you're expecting an ink developer to have to get into the weeds with Substrate and Parathreads then you've lost the DX.

If every time you need to implement a non EVM chain into Hyperlane you need to get buy in from the underlying chain and are beholden to their internal governance and bureaucratic process, then you're going to struggle to get market adoption.

[nambrot]

Can't comment too much on the ink/substrate question, but on the question of whether a chains governance or community having to take an action, I would say it depends a lot on the context. We have a similar question in the cosmos world right now. Obviously, generally, a truly permissionless deployment story is better, and if we can, we should definitely aim for that. That being said, Hyperlane is often most useful for "long-tail" chains, and so far they happen to be very interest-aligned. For a chains community, getting connected is often a no-brainer. You could also imagine two implementations, one with chain extensions (since presumably that makes it easier to do) and one without.

[nambrot]

While many VMs presumably only support one hashing algo (and thus one tree and one message ID), some others may support multiple, and thus it could be useful to have logic that at runtime determines in which tree a message should be enqueued to, to retain the property of using a single mailbox for an application.

This could be related to mailbox hooks (#2381) that do such insertion