search

dewi-alliance / grants

Details of the DeWi Alliance Grant Program
41 stars 15 forks source link

Helium to Solana Bridge #24

Open anthonyra opened 2 years ago

anthonyra commented 2 years ago

Grant Proposal: Helium and Solana Bridge Testnet

Name of Project: Project Agate (HNT|mHNT)

Proposer: @anthonyra#2034

Do you agree to open source all work you do on behalf of this grant?: To be determined, not sure what all can be open sourced since it's more along the lines of infrastructure and how they communicate. Can be discussed in length during application process.

Project Description

The future of the Helium ecosystem heavily depends on its capability for market growth and trustless actions not currently possible with its layer 1 blockchain. To assist with this, a foundation must be built to support the portability of HNT or an equivalent onto a Virtual Machine capable blockchain. Ethereum, Solana, and Cardano are three such blockchains that could assist with "bridging" the gap.

Ethereum

Solana

Cardano

Solana is the ideal candidate for the initial propagation of HNT due to its high throughput, low-cost transactions; A bridge between Solana and Ethereum exists; utilizing Rust eliminates the need for community support of a new programming language and aligns with light gateways.

High Level Overview

Helium doesn't have a native virtual machine on chain, because of this we will be standing up a sidechain (codename Agate) using Hyperledger Fabric. Using Fabric will allow peer nodes (validators) to join with a "majority vote in" to perform the bridging orchestration. This greatly decentralizes the bridge.

For the proof of concept used on Testnet, the Fabric Network will consist of only two Organizations. The first being Mycelium Networks and the other being DeWi, both of which can have max of 2 peer nodes. The peer nodes will be used to validate the transactions performed on either blockchain and return a signature that will be used to authorize the completion of the bridging of the tokens. For this structure to work Helium needs to have burn and mint transactions for HNT. These transactions will be all atomic in nature.

The user will sign a transaction to burn the token being moved across the bridge and a transaction for Agate to watch for that burn on the originating blockchain. The Agate transaction adds the burn to the pending transactions for the associated smart contract. The peers then constantly monitor the originating blockchain "watching" for the burn to settle. Once settled, the peer will sign the resulting transaction for validation. When the majority of the peers agree on seeing the burn being settled the resulting transaction and signature then authorizes the mint request on the destination blockchain.

Each blockchain will have a "watcher" contract and a minting contract on Agate.

Sending HNT to Solana

Diagram 📊

Withdrawing HNT from Solana

Diagram 📊

Dapp

To use the bridge the user needs to be able to interact with Agate, Helium, and Solana. To provide this the Dapp will have integration support for Phantom Wallet (Solana) and Laser Wallet (Helium). It'll also have the capability to use QR codes or deep linking with the new Helium App.

The Dapp will also provide the client access needed to submit the required Agate transactions to trigger the "watcher" contracts and subsequent mint request.

NOTE In the unlikely chance that a bridge cannot be completed automatically there will be a dispute process in place that can be initiated to ensure that all funds are accounted for after any bridge operations.

Deliverables

Provide a Helium bridge to Solana. With the capability to do gateway reward splits in the future.

Timeline/Roadmap

Milestone + Date Deliverable Summary Cost
MS1, Week 1-4 L1 Blockchain Preparations
  • Solana Token Contract (mHNT) passing audit
  • Hyperledger Fabric Infrastructure for Organizations$ (via terraform)
  • Threshold Secret Sharing Implemented For Bridge Authority
 $30k (Upfront)
MS2, Week 5-8 Testnet Launch
  • Agate is Launched
  • Dapp
  • Security Audit completed and reviewed by Dewi
 $60k
MS3, Week 9-12 Open Testnet Bridge to Public Open the bridge to users for load testing and performance checks. Final product will be able to Bridge TNT (Helium Testnet Token) to Solana via Phantom Wallet. $60K

$ Provide infrastructure as code via Terraform to spin up an Organization used with the Hyperledger Fabric Agate network. This script will spin up a Helium Node (blockchain-node) and a Solana RPC validator with PrivateLink communication to the Peer Node operating within Hyperledger Fabric.

Budget

Total
$150,000

The cost breakdown above will cover all development costs to include hardware and infrastructure costs for the bridge.

Maintenance

There will be a fee collected on the Helium side of the bridge transaction in order to cover the cost associated with such a service.

Team

Members

Relevant Experience

wlidosman commented 2 years ago

Ok

syuan100 commented 2 years ago

Thanks for submitting the grant application! Good to see some bridge building around here. A few points to address:

  1. Lambda functions from an infra perspective are more centralized than standalone programs that can be run anywhere. Is there a reason why we're using FaaS here? I'm wary of vendor lock-in and even though I like the ethos of "trustless" code, having the repo be public should be enough IMO. Additionally, I'm not sure what incremental benefit there is to having infrastructure code be publicly accessible, as this could be another vector of attack.

  2. While I can understand the assets being hosted on Mycelium Networks to start, in the spirit of decentralization I would like to see this proposal modified so that this bridge can be run under any organization's infrastructure of choice (provided that they have the authoritative key(s)). An example being: making the ETL endpoint configurable. I would imagine having a non-profit like DeWi or a variety of organizations in a Multisig setup holding custody of the vault to be the end goal.

  3. Could you number the different steps for Lucid chart diagram you sent? I can infer the application flow, but would like to see something explicit so I'm not interpreting things wrong.

  4. MS8 should probably be a different grant application (reward splitting). Could you remove that from the scope?

anthonyra commented 2 years ago
  1. Lambda functions from an infra perspective are more centralized than standalone programs that can be run anywhere. Is there a reason why we're using FaaS here? I'm wary of vendor lock-in and even though I like the ethos of "trustless" code, having the repo be public should be enough IMO. Additionally, I'm not sure what incremental benefit there is to having infrastructure code be publicly accessible, as this could be another vector of attack.

This is one of the centralizing aspect of this project however it was thoughtfully considered for a couple of reasons; 1) I'm familiar with using Lambda functions and controlling validators with them therefore controlling a blockchain-node will be almost second nature to facilitate quick development. 2) Being serverless, allows me to focus more on the code and not the underlying hardware 3) I decided that making the infrastructure code public (github repo) along with the access to the Lambda function source code is a happy middle ground due to the centralization described. Any PII or API related information is redacted. I have no intentions on making a step by step tutorial on setting up a bridge currently. Just for v1 of course. There's been some work performed circa 2019 on running Lambda duplicates on IPFS and would be the next phase of making this truly decentralized.

2. While I can understand the assets being hosted on Mycelium Networks to start, in the spirit of decentralization I would like to see this proposal modified so that this bridge can be run under any organization's infrastructure of choice (provided that they have the authoritative key(s)). An example being: making the ETL endpoint configurable. I would imagine having a non-profit like DeWi or a variety of organizations in a Multisig setup holding custody of the vault to be the end goal.

This is being written in Terraform utilizing the AWS provider. Porting the terraform code to other VPS providers supported by Terraform would be relatively easy for those familiar with them. Even then someone could build each server by hand and use the build scripts to boilerplate this in the future if they so desire.

3. Could you number the different steps for Lucid chart diagram you sent? I can infer the application flow, but would like to see something explicit so I'm not interpreting things wrong.

I'll get to that right after this and I'll update this post when complete. Thank you for the input on making the diagrams "more" human friendly!

4. MS8 should probably be a different grant application (reward splitting). Could you remove that from the scope?

I can remove this Milestone however I built the infrastructure in the intensions of implementing this. Meaning that with MS7 the bridge will be able to support however Helium (the blockchain) will require some blockchain-core updates to activate the functionality.

timfong888 commented 2 years ago

Hi @anthonyra I have been studying Chainlink Cross Chain Interoperability Protocol and would like to participate in the requirements gathering and architecture while accessing their reference implementation.

We have to make a request to learn about it but it should support non-EVM and supports decentralization using their oracle nodes.

Open to chat to see at least if we could look at their reference together?