Ortege application

[HariSeldon23]

Project Abstract

Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs).

If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[keeganquigley]

Thanks for the application @HariSeldon23 looks interesting. A couple of initial questions/comments:

• When you say ink! based chains, I'm assuming you mean parachains that support WASM contracts?
• I see that you will use the same mailbox system as Hyperlane. Will you use the same DPOS system as well? Will the agent keys be the same, where validators read merkle roots from the mailbox contract and use the key to sign it?
• How about other features such as watchtowers? Just curious, I know it's likely out of scope of this PoC.
• It appears that Hyperlane has already been deployed on Moonbeam, a parachain that supports EVM contracts. Since many smart-contract chains are Solidity based, can you briefly explain the benefits of having an ink! version?
• When it comes to cross-chain communication between ink! to ink! contracts, I believe in future ink! releases it should be possible to send messages using chain extensions to hook into the XCM pallet. But if I understand correctly, you want to focus on WASM to EVM chain communication and vice versa?
• In the milestone tables, can you expand a bit on what the tests will consist of? For example, perhaps a way to mock a message transfer by calling the mailbox contract dispatch function, and then a way to verify that the recipient received the message (like this Hyperlane messaging test).

Thanks!

[HariSeldon23]

Thanks @keeganquigley for the feedback. Please find my responses below.

When you say ink! based chains, I'm assuming you mean parachains that support WASM contracts? With ink! you can write smart contracts in Rust for blockchains built with Substrate that include pallet-contracts. So any Substrate chain that uses pallet-contracts

I see that you will use the same mailbox system as Hyperlane. Will you use the same DPOS system as well? Will the agent keys be the same, where validators read merkle roots from the mailbox contract and use the key to sign it? We will make sure that we align with Hyperlane. So any changes we do, we will submit back to their main repository to be merged back into their codebase. As such we will adjust their Agents in the backend and we will use the same agent keys.

How about other features such as watchtowers? Just curious, I know it's likely out of scope of this PoC. We want to make sure that all of Hyperlane's features are supported so that a developer using ink! will have the same functionality as on any supported Hyperlane chain. We're happy providing this functionality at a later date or else since the code is open source, anyone from the community will also be able to add features to ensure parity with Hyperlane.

It appears that Hyperlane has already been deployed on Moonbeam, a parachain that supports EVM contracts. Since many smart-contract chains are Solidity based, can you briefly compare to this and how the ink! version would be superior? Native Integration with Substrate: Parachains running Solidity need to run precompiles to have access to Substrate features and Primitives. This results in introducing potential new security vulnerabilities and compromosing on safety. This was evident with Moonbeam with the white hat bug found here https://moonbeam.network/blog/urgent-security-patch-for-custom-precompiles/ So having this functionality in ink! over Solidity would mean Substrate chains would have access to Substrate level functionality and upgrades without sacrificing on safety and extra complexity in introducing precompiles

In the milestone tables, can you expand a bit on what the tests will consist of? For example, perhaps a way to mock a message transfer by calling the mailbox contract dispatch function, and then a way to verify that the recipient received the message (like this Hyperlane example). We will include those same tests but adjust them for the ink! based implementation. Specifically we will include the tests for GasRouter, Messaging, ValidatorAnnounce, ConnectionClient, Mailbox, Merkle, Message, testSendReceiver, testRecipient and potentially others

In terms of adjusting the milestone table within the PR, I was thinking it might be easier to adjust and then update the PR once you're happy with everything. This will prevent me from having to squash commits everytime an uipdate is required. Is that ok?

[keeganquigley]

Thanks @HariSeldon23 for educating me on the Moonbeam precompiles. Sounds like a good use case for ink! I will go ahead and mark your application as ready for review and ping the rest of the committee.

So if I understand correctly, you want to contribute directly to Hyperlane codebase rather than create Ortege as a standalone project? Also, the committee may have issue with the relatively high price tag before we see a working PoC.

[HariSeldon23]

In terms of Hyperlane, we want all our integrations to go directly to their codebase. We will build products such as Ortege Data Feeds and Ortege Warp on top of Hyperlane's underlying codebase and infrastructure. Where Hyperlane doesn't support an ecosystem such as ink! we will look to build out the integration and then work together with the Hyperlane team to merge it into their main codebase. While we work with Hyperlane to have it merged, we will host the underlying infrastructure to enable interconnectivity. Important to note that the infrastructure is decentralized and anyone else could also run infrastructure if they wanted to.

[Noc2]

Thanks for the application. You say you want to contribute to Hyperlane and not develop an independent version. However, at the same time, you replaced the word Hyperlane with Ortege here: Ortege-xyz/ortege-monorepo@3c9d762 Which is quite funny because "Hyperlane v2" immediately became "Ortege v2". Could you explain this? It also seems you mostly focus on the additional Chainlink integration as an ink! Smart contract. Could you provide more details regarding this?

[HariSeldon23]

Thanks for the application. You say you want to contribute to Hyperlane and not develop an independent version. However, at the same time, you replaced the word Hyperlane with Ortege here: Ortege-xyz/ortege-monorepo@3c9d762 Which is quite funny because "Hyperlane v2" immediately became "Ortege v2". Could you explain this? It also seems you mostly focus on the additional Chainlink integration as an ink! Smart contract. Could you provide more details regarding this?

Thanks for response. This comes down to a few issues. Hyperlane doesn't have the bandwidth to support every chain. So they allow permissionless deployments. So what we do is we maintain a branch that is always up to date with theirs and then deploy our own backend on a different branch. This is what it looks like:

The main reasons we do this is:

• We need our own independent npm packages in order for us to publish the new chain's smart contract addresses (both for deployed contracts and our own hosted backend agents). See here as an example https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/typescript/infra/config/environments/mainnet2/validators.ts
• The Hyperlane Explorer doesn't work with newly added permissionless deployments (at least not seamlessly in my attempts) https://explorer.hyperlane.xyz/ so we need our own Explorer to show chains outside of Hyperlane's core supported chains.

There are some other reasons, but those are the main ones. So we had to decide how to handle our own deployments. We ultimately chose to have our own npm packages under ortege which then has our own sdk which points to the chains we permissionlessly add to Hyperlane. This may be a temporary solution, as Hyperlane is working on a way for other projects to add their details. However that's a work in progress and we are working with Hyperlane to determine what that will look like. As soon as they adopt a stable path forward we'll align with that.

In terms of the ChainlinkISM, the main bulk of the work is replicating Hyperlane's core functionality via the Mailbox, Interchain Security Model, GasPaymaster and MerkleTrees. So we'd need to rewrite all those contracts in ink!. The Interchain Security Model allows us to plug in different modular types of security modules as well as aggregate them. This piece of work is sending Chainlink Price feeds from an existing EVM chain that supports Chainlink and uses this ISM https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/isms/ccip-read/AbstractCcipReadIsm.sol in order to then utilise CCIP for security and then send the message to any ink! supported chain.

Another important part of this development is the adjustment of the validators in order to validate different MerkleTrees. As an example, Solidity uses keccak, whereas ink! uses blake. See here for some context hyperlane-xyz/hyperlane-monorepo#2399

I do believe it's important to take into consideration, this is just one piece of functionality to showcase the power and flexibility of Hyperlane. By enabling this, other developers can also enable Warp Routes as well as asynchronous cross chain messaging solutions.

[semuelle]

Thank you for the application, @HariSeldon23, and sorry for the long wait. We have a bit of a backlog in terms of applications.

• Could you elaborate in the current status of Ortege as a whole? I tried to find any kind of discussion or documentation of its deployments, e.g. on Moonbeam, but couldn't find anything. Also, the developer docs are largely empty. EDIT: I just noticed that the Development Status section is about Ortege. Could you add something about what work has been done towards the ink!/Kusama integration?
• It seems that Kusama is the first non-EVM chain you are targeting. Could you expand on why you chose ink!/Substrate and how it fits into your long-term roadmap. Are you working on other non-EVM integrations?
• Do you have any indication of whether there is interest to support/integrate ink!-related work on their side or if they have done any work towards integrating non-EVM chains in the past?

  Where Hyperlane doesn't support an ecosystem such as ink! we will look to build out the integration

• I don't see any transactions on your explorer that's not also shown on the Hyperlane explorer. Are the non-Hyperlane deployments not integrated or is there currently no activity?
• The APIs you are listing are the same as Hyperlane's. Perhaps you could expand a bit more on what your contribution to these APIs is?

[semuelle]

There is no need to publish an article for each milestone, but if you do, please specify the contents and medium in which you are planning to publish.

[HariSeldon23]

We have a blog on our website https://ortege.io but we're also thinking about having a complementary Substack

[takahser]

@HariSeldon23 could you incorporate that info:

a blog on our website https://ortege.io/

..as well as a brief description of contents you're planning to cover for each article.

[semuelle]

Please modify the deliverable spec to include this information and ideally the contents of the articles.

[takahser]

This still hasn't been addressed.

[semuelle]

The total costs and FTEs don't match the sum of the milestones.

[HariSeldon23]

Good catch. I'll adjust this.

Do you want me to adjust everything and then squash commit to update the PR?

[takahser]

Do you want me to adjust everything and then squash commit to update the PR?

For follow-up commits it doesn't really matter if you create multiple commits or squash them as we're going to squash them anyway when merging the PR.

The total costs and FTEs don't match the sum of the milestones.

In addition to that, the milestones seem to have different per-person rates: 6k for M1, 5.5k for M2 and 5k for M3.
Why is that?

[semuelle]

This still isn't addressed.

[HariSeldon23]

• Could you elaborate in the current status of Ortege as a whole? I tried to find any kind of discussion or documentation of its deployments, e.g. on Moonbeam, but couldn't find anything. Also, the developer docs are largely empty. EDIT: I just noticed that the Development Status section is about Ortege. Could you add something about what work has been done towards the ink!/Kusama integration?

Ortege is at an MVP stage and can currently deliver Bridging functionality as well as Data Feeds functionality on EVM Chains. We leverage Hyperlane's deployments on all their supported chains and run relayers and validators on those chains. In terms of the work done on the ink! integration, we have started upskilling our engineers to learn ink! and to deploy some rudimentary contracts.

• It seems that Kusama is the first non-EVM chain you are targeting. Could you expand on why you chose ink!/Substrate and how it fits into your long-term roadmap. Are you working on other non-EVM integrations?

We've been a fan of Substrate for a long time and feel that ink! combined with XCM provides a really powerful set of features for dApp developers. I personally feel XCM has a lot of benefits and good design decisions compared to IBC. Having Substrate based chains integrate with the broader ecosystem will help shine a light on this very good piece of technical infrastructure and allow use cases that aren't quite possible within the existing IBC/EVM world.

We are also working on an altVM integration with Stellar's Rust baed VM Soroban.

• Do you have any indication of whether there is interest to support/integrate ink!-related work on their side or if they have done any work towards integrating non-EVM chains in the past?

  Where Hyperlane doesn't support an ecosystem such as ink! we will look to build out the integration

Hyperlane has numerous altVM integrations happening. There is work being done by StrangeLove to integrate Cosmos. They are close to finalizing the Solana integration with the SVM. Our approach is to follow their guidelines and have the integration merged into their main branch once it reaches sufficient maturity.

• I don't see any transactions on your explorer that's not also shown on the Hyperlane explorer. Are the non-Hyperlane deployments not integrated or is there currently no activity?

Hyperlane V3 is about to be audited in the next week, so we're delaying EVM deployments until the V3 contracts are audited. Then in terms of the Soroban integration we are still in development.

• The APIs you are listing are the same as Hyperlane's. Perhaps you could expand a bit more on what your contribution to these APIs is?

We build the functionality into altVM integrations. We also test them and provide early feedback to the Hyperlane team

[takahser]

@HariSeldon23 added some comments, feel free to have a look.

[takahser]

Currently, this sounds like deployment efforts. Please keep in mind that we wouldn't support these. So feel free to remove them or clarify what you will implement.

[HariSeldon23]

Option 1, is deployment. However 2 and 3 involves adjusting the off chain agents Rust code to deal with validation of messages. This is custom development

[takahser]

If that's the case, feel free to update the deliverables accordingly.

[takahser]

What kind of merkle tree will you implement? For example, a patricia merkle tree? Or a MMR? Or a binary tree? What is it going to be used for? Will they be any different from the existing implementations, e.g.:

• binary merkle tree
• MMR
• see also the solidity-merkle-trees repo

[HariSeldon23]

It's an incremental Merkle Tree as can be seen here https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/401b32ddddc6faa281beb050f641afb4f024d905/solidity/contracts/libs/Merkle.sol#L9

[takahser]

What's the reason for using the incremental merkle tree vs.one of the alternatives that already have been implemented?

[HariSeldon23]

It's because it's what Hyperlane use, so we want to be consistent

[takahser]

Here's a rust-based implementation of an incremental merkle tree: https://docs.rs/incrementalmerkletree/latest/incrementalmerkletree/

Is it possible to reuse this one?

[Noc2]

To add here, because I just saw it: OpenBrush no longer maintains its repos. The standardization process can be found here: https://github.com/w3f/PSPs

[semuelle]

pinging @HariSeldon23

[HariSeldon23]

pinging @HariSeldon23

Been travelling. Have just responded now

[semuelle]

Can you elaborate on what these security requirements look like and how they are added/modified/maintained? Hyperlane seems to provide an Interface and several default implementations, will this be the case here? If so, could you add this information?

[HariSeldon23]

We will provide the Interface and as part of this scope of work, the multisig ISM. Will update the application to reflect this

[semuelle]

Do the prices come from the gas oracle provider shown in the diagram, or who is responsible for adding the prices to the contract?

[HariSeldon23]

A bot or user would need to periodically update exchange rates

[semuelle]

How is this different from 0c?

[HariSeldon23]

One is unit tests, the other is integration testing

[github-actions]

CLA Assistant Lite bot: Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. Please submit the following text as a separate comment:

---

I have read and hereby sign the Contributor License Agreement.

---

_{You can retrigger this bot by commenting recheck in this Pull Request}

[HariSeldon23]

Made changes as requested to the PR

[takahser]

The milestones still have different per-person rates: 6k for M1, 5k for M2 and M3.
Why is that?

[takahser]

This still hasn't been addressed.

[takahser]

@HariSeldon23 unfortunately the grants committee has decided to close this application. The reasons are mainly a lack of progress. Let me know if you have any questions in this regard.
We wish you all the best and success for the future of the project. I'd like to add that you're welcome to apply again for another grant in the future.