Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add grant proposal for Spacewalk, a Stellar bridge #749

Merged
merged 3 commits into from
Feb 10, 2022

Conversation

TorstenStueber
Copy link
Contributor

@TorstenStueber TorstenStueber commented Dec 20, 2021

Adds the web3 grant proposal for Spacewalk, a bridge between Stellar and Substrate-based chains.

Project Abstract

Please provide a brief description of your project here 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.

For which grant level are you applying?

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

Application Checklist

  • The application template has been copied, renamed ( project_name.md) and updated.
  • A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
  • I have read and acknowledged the terms and conditions.
  • 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.

Adds the web3 grant proposal for Spacewalk, a bridge between Stellar and Substrate-based chains.
@CLAassistant
Copy link

CLAassistant commented Dec 20, 2021

CLA assistant check
All committers have signed the CLA.

@semuelle
Copy link
Member

semuelle commented Dec 21, 2021

Thanks for the application, Torsten. We will look into it as soon as possible.

Copy link
Collaborator

@Noc2 Noc2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the application and sorry for the late response. For some reason, I believe we have already discussed this with you or someone else before in some form. Did you already apply for a grant before? At least I looked at the pendulum prototype some time ago. It’s nice to see that you want to use the xclaim design. Are you aware that https://interlay.io/ is the team behind xclaim and that their implementation is fully open source: https://github.com/interlay? So you are probably able to use some of their code for this project (relayer, oracle) and in general, I recommend to take a look at it, since they also update the original design.

@Noc2 Noc2 self-assigned this Dec 27, 2021
@Noc2 Noc2 added the changes requested The team needs to clarify a few things first. label Dec 28, 2021
@TorstenStueber
Copy link
Contributor Author

@Noc2 we just realized that our bridge has already been added to the Polkadot stack list in this commit. Note that the link in that commit just directs to our simplified prototype of the Stellar bridge, not the complete version. The scope of this web3 grant proposal is the complete version (i.e., "Spacewalk").

@Noc2
Copy link
Collaborator

Noc2 commented Jan 3, 2022

I’m aware of this. The polkadot stack is mostly to keep track of open source tools, that doesn’t say anything about the development status of the project.

@erasmus
Copy link

erasmus commented Jan 4, 2022

@Noc2 Thanks for getting back to us. We did not previously apply for a Web3 grant for Spacewalk. Perhaps you saw the prototype Stellar bridge, which we built while building a proof-of-concept of the Pendulum Substrate-based blockchain? As Torsten mentioned, Spacewalk is planned as a full and generalised implementation of a Stellar<>Substrate bridge, available to the entire Substrate community.

Are you aware that https://interlay.io/ is the team behind xclaim and that their implementation is fully open source: https://github.com/interlay? So you are probably able to use some of their code for this project (relayer, oracle) and in general, I recommend to take a look at it, since they also update the original design.

Yes, some of the Spacewalk design will be based on XCLAIM. We'll certainly keep a close eye on Interlay's updates to XCLAIM.

@Noc2 Noc2 requested a review from Lederstrumpf January 5, 2022 09:18
@Noc2 Noc2 added ready for review The project is ready to be reviewed by the committee members. and removed changes requested The team needs to clarify a few things first. labels Jan 5, 2022
Copy link
Collaborator

@Noc2 Noc2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late response here. I will mark the application already as ready for review to also get additional feedback from others. However, I have a question regarding the “Stellar Oracle” solution. It seems you also want to implement some kind of “consensus” for these oracles “The bridge nodes will find consensus about the state of the Stellar through voting.”. Could you expand on this? Why not simply use relayers plus transaction inclusion proofs?

Copy link
Contributor

@Lederstrumpf Lederstrumpf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, thanks for your application. At this stage, it does not seem conceptually consistent to me (or possibly relies on a few kludges) - please address @Noc2's and my comments.

Our bridge differs from XCLAIM in some details as follows:

- Implementing a full chain relay for Stellar is out of scope of this web3 grant proposal as this requires an update to the Stellar consensus protocol. Instead the Spacewalk protocol assumes that a light Stellar node is co-located for every node of the Substrate-based chain and uses the Stellar nodes as an oracle.
- We will employ a single vault instead of a network of vaults because according to Section V.E. of [Xclaim: Trustless, interoperable, cryptocurrency-backed assets](https://eprint.iacr.org/2018/643.pdf), the latter version leads to non-fungible wrapped tokens which is not a desirable condition.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is no longer how Interlay's bridge works - wrapped tokens can now be redeemed with any vault, not just the issuing one. Check out their docs. A permissionless vault market is preferable to a single (permissioned) vault.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already at the superficial level, simply consider censorability and single-point-of-failure downsides.


- **Bridge accounts**: this is a set of escrow accounts used to lock assets. They are completely and only controlled by the bridge nodes. The Spacewalk bridge potentially requires multiple bridge accounts instead of a single bridge accounts because in Stellar a single account is limited to hold up to 1000 distinct assets. Every bridge account is associated with a maximum of 1000 distinct Stellar assets and will be used whenever one of its associated assets is used in a deposit or withdrawal operation. Stellar users initiate a deposit by sending tokens to the appropriate bridge account, which they request from the bridge pallet prior to the deposit. Likewise bridge nodes will instruct the bridge accounts to unlock and send tokens back the users during a withdrawal.
- **Bridge Pallet**: this is the main component of the Spacewalk bridge that implements all logic on the side of the Substrate-based chain. It is particularly responsible for minting tokens during deposits and burning tokens during withdrawals. The storage of the bridge pallet maintains the complete state that is required for the bridge to work correctly. This state contains (among others): the account ids of the Stellar bridge accounts, the association of bridge accounts to Stellar assets, book keeping information about the state of the Stellar network and assets locked in the bridge accounts. It also maintains the collateral of the bridge nodes and slashes it in case one of the bridge nodes misbehaves.
- **Bridge Nodes**: these are privately owned nodes that watch changes in the storage of the bridge and create, sign and submit Stellar transactions that a) unlock tokens during a withdrawal and b) maintain the set of bridge accounts and its signers. Each bridge nodes contains some secret value. Together these secrets can be used to sign transactions for the bridge accounts. The bridge nodes use a t-out-of-n threshold signing scheme for the bridge accounts. For n ≤ 20 this is achieved through multisignature accounts that are directly supported through the Stellar protocol and for n > 20 this is achieved through key aggregation for Schnorr signatures (see [Maxwell, Gregory, et al. "Simple schnorr multi-signatures with applications to bitcoin"](https://eprint.iacr.org/2018/068.pdf)). Every bridge node needs to lock a certain amount of PEN tokens as a collateral in the bridge pallet. These tokens are slashed in case the bridge node misbehaves.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does "privately owned" mean here - anyone can run a node, or is this permissioned?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and how do you report & prove misbehaviour?


The following aspects are out of scope of the current proposal and subject to future applications:

- Stellar protocol updates that are required to implement a chain relay/light client/simplified payment verification for Stellar as a Substrate pallet
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what protocol updates are required? hasn't this already walked a long stretch of the path?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Lederstrumpf You are referring to Stellar's project slingshot, which is a different architecture from Stellar. For example, slingshot uses unspent outputs whereas Stellar does not. Utreexo is based on architectures that use unspent output but is not directly applicable to Stellar in that sense.

The main reason why Stellar does not allow for SPV is that Stellar blocks don't use Merkle trees. For that reason there are no efficient inclusion proofs (such as Merkle proofs) possible with the current protocol definition of Stellar.


The architecture of the bridge consists of the following components:

- **Bridge accounts**: this is a set of escrow accounts used to lock assets. They are completely and only controlled by the bridge nodes. The Spacewalk bridge potentially requires multiple bridge accounts instead of a single bridge accounts because in Stellar a single account is limited to hold up to 1000 distinct assets. Every bridge account is associated with a maximum of 1000 distinct Stellar assets and will be used whenever one of its associated assets is used in a deposit or withdrawal operation. Stellar users initiate a deposit by sending tokens to the appropriate bridge account, which they request from the bridge pallet prior to the deposit. Likewise bridge nodes will instruct the bridge accounts to unlock and send tokens back the users during a withdrawal.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these escrow accounts / bridge nodes operated by distinct actors? if so, how does this interplay with having "a single vault"?

@Lederstrumpf Lederstrumpf added changes requested The team needs to clarify a few things first. and removed ready for review The project is ready to be reviewed by the committee members. labels Jan 5, 2022
@TorstenStueber
Copy link
Contributor Author

Thanks @Lederstrumpf for your detailed feedback. Interlay's further developments of XCLAIM that allows for multiple vaults without introducing non-fungible tokens is indeed also favorable for Spacewalk.

A permissionless vault market is preferable to a single (permissioned) vault.

I totally agree.

We will update our proposal accordingly and will make it more clear how it is different from interBTC bridge.

@TorstenStueber TorstenStueber changed the title Add grant proposal for Spacewalk, a Stellar bridge [WIP] Add grant proposal for Spacewalk, a Stellar bridge Jan 25, 2022
@TorstenStueber TorstenStueber changed the title [WIP] Add grant proposal for Spacewalk, a Stellar bridge Add grant proposal for Spacewalk, a Stellar bridge Jan 26, 2022
@TorstenStueber
Copy link
Contributor Author

@Noc2 @Lederstrumpf Thanks again for your valuable feedback. We analyzed in what sense Spacewalk can be based on the interBTC implementation. It turns out that we can reuse many concepts and this helped us to greatly simplify this proposal for Spacewalk – please see the changes in our latest commit. We could reduce our proposal to grant level 1.

Noc2
Noc2 previously approved these changes Jan 31, 2022
Copy link
Collaborator

@Noc2 Noc2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late reply. I was ooo last week. Thanks for the update and the reduced price. At this rate I’m willing to support the project. I still see some issues with the oracle component and would love to see more details about how exactly it works and how it can be improved.

@Noc2 Noc2 added ready for review The project is ready to be reviewed by the committee members. and removed changes requested The team needs to clarify a few things first. labels Jan 31, 2022
@TorstenStueber
Copy link
Contributor Author

Thanks @Noc2, I will add more details regarding the oracle.

@TorstenStueber
Copy link
Contributor Author

@Noc2 I added more details about the Stellar oracle. Thanks again for your remark.

@Lederstrumpf Do you have any further change requests?

@@ -41,7 +41,9 @@ The architecture of the bridge consists of the following components:

- **Vaults**: this is a set of escrow accounts used to lock assets in Stellar. Their behavior is defined in XCLAIM and interBTC. In Spacewalk they have an additional property: each vault has an allow list of assets that it can lock and support for bridging operations between Stellar and the Substrate chain. This allow list is implemented through [trustlines](https://developers.stellar.org/docs/issuing-assets/anatomy-of-an-asset/#trustlines) of the Stellar account. There can be at most 1000 supported assets per vault due to limitations in Stellar. Stellar users initiate a deposit by sending tokens to an appropriate vault, which they request from the bridge pallet prior to the deposit. Likewise vaults will unlock and send tokens back to Stellar accounts during a withdrawal. Every vault needs to lock a certain amount of DOT or KSM (or related) tokens as collateral with the bridge pallet. These tokens are slashed in case the vault misbehaves.
- **Bridge Pallet**: this is the main component of the Spacewalk bridge that implements all logic on the side of the Substrate-based chain. Its behavior is based on interBTC. It is particularly responsible for minting tokens during deposits and burning tokens during withdrawals. It is able to support any Stellar asset by employing the [Tokens](https://github.com/open-web3-stack/open-runtime-module-library/tree/master/tokens) and [Currrencies](https://github.com/open-web3-stack/open-runtime-module-library/tree/master/currencies) pallets of the Substrate Open Runtime Module Library. The storage of the bridge pallet maintains the complete state that is required for the bridge to work correctly. This state contains (among others): the account ids of the vaults, the asset allow lists of each vault and book keeping information about the state of the Stellar network.
- **Stellar Oracle**: is a system that provides information about the state of the Stellar network to the bridge pallet. In interBTC this is implemented through a chain relay in the bridge pallet. However, we will aim for a solution where every node of the Substrate-based chain is co-located with a Stellar validator node, which it uses as an oracle.
- **Stellar Oracle**: is a decentralized system that provides information about the state of the Stellar network to the bridge pallet. In interBTC this is implemented through a Bitcoin chain relay. However, for reasons explaned above we cannot implement a chain relay for Stellar in the same way. The Stellar oracle is trustless and reliable and its functionality is based on specific unique aspects of Stellar:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're mixing up things. In interBTC the oracle is a different and unrelated component from the BTC relay. This also goes for the Stellar oracle, what you're describing is not an oracle but a relayer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second look, it's evident you're not confusing the functionality but this is simply an issue with the naming. I'd suggest you consider renaming this component. The term 'oracle' is commonly used to describe any bridge from a blockchain to the real world, and I've never seen it used to mean a bridge to another blockchain or a relayer, light client etc. If you have a reference to anywhere this meaning is accepted feel free to point me to it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should also add that regardless of whether you want to change this or not, I'm happy to accept your proposal.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your feedback. Indeed interBTC requires an oracle for price feeds in order to assess whether vault collaterals are sufficient and to determine that a vault needs to be liquidated. This is also required for our bridge and even at higher complexity level as we support a multitude of assets that the vaults can lock.

I agree that it is confusing that I was talking about a different oracle here. A very general definition of an oracle is a system (consisting of off-chain and on-chain components) that feeds data from the outside world into a pallet or smart contract and the on-chain logic would then verify and aggregate that information and find consensus on it. So in this liberal sense the component I refer to as Stellar oracle is indeed an oracle. I avoided the term relay because our component works differently to typical chain relays for blockchains that use Nakamoto consensus (I explain the differences in our proposals).

If this explanation could not resolve the confusion, I am happy to rename.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, that makes sense and @Noc2 also shared another example of where the term was used in this manner with me. I understand your reasoning and to be honest, I agree that logically it fits perfectly, but found using the same name for a different component in what is otherwise the same system confusing.

Copy link
Collaborator

@Noc2 Noc2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update. I’m still happy to go ahead with it and also think the term oracle is used correctly.

@TorstenStueber
Copy link
Contributor Author

Thanks for the approvals. This proposal has now 2 out of 2 required approvals but merging is blocked by changes requested by another reviewer that I addressed some time ago. What is the standard way to proceed in this case?

@Noc2 Noc2 merged commit ccbde55 into w3f:master Feb 10, 2022
@github-actions
Copy link
Contributor

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

@TorstenStueber
Copy link
Contributor Author

I need to report a delay for the delivery of our first milestone as the onboarding to the interBTC code base and merely restructuring it so that it can be used as a pallet for another substrate chain is more complex than I anticipated.

After completing this restructuring, I can actually implement the changes related to our bridge required to reach the first milestone. I don't expect similar delays for the subsequent milestones as this is a one-time restructuring task.

@Noc2 is it enough to report the delay here or are other steps required?

@Noc2
Copy link
Collaborator

Noc2 commented Mar 11, 2022

delivery of our first milestone as the onboarding to the interBTC code base and merely restructuring it so that it can be used as a pallet for another substrate chain is more complex than I anticipated.

After completing this restructuring, I can actually implement the chan

Thanks a lot for the update and keeping us in the loop. It depends on how long the project is delayed. If it’s delayed for multiple months, the safest is usually to create a PR to amend the original contract. If it’s just a few weeks, it’s not necessary to do this.

@TorstenStueber
Copy link
Contributor Author

Thanks a lot, it will be just a few weeks.

@keeganquigley
Copy link
Contributor

Hi @TorstenStueber how is M3 coming along?

@TorstenStueber
Copy link
Contributor Author

@keeganquigley We are working on M3. We are currently focusing on the launch of our parachain Pendulum which will happen next week. Shortly after we deploy the first version of Spacewalk which is already mostly fully functional and contains a lot features of M3.

Then we will implement the remaining M3 features (multiasset vaults and a Spacewalk version that is generic and can be plugged into other parachains).

@keeganquigley
Copy link
Contributor

Hi again @TorstenStueber if you think the delivery will be delayed significantly, could you please submit an amendment to extend the timeline? That will take the pressure off. Thanks!

@TorstenStueber
Copy link
Contributor Author

@keeganquigley Thanks for the message. I will get back to you as soon as possible.

@keeganquigley
Copy link
Contributor

Hi @TorstenStueber any updates?

@keeganquigley
Copy link
Contributor

Hi @TorstenStueber do you still plan to submit an amendment?

@TorstenStueber
Copy link
Contributor Author

Hey @keeganquigley, after many delays and improvements we are finally rolling out Spacewalk on our Kusama parachain Amplitude. The referendum for the runtime upgrade is currently in being executed.

Once this is completed, we will deliver this final milestone.

@keeganquigley
Copy link
Contributor

@TorstenStueber congrats on the launch of Pendulum Spacewalk! Happy to see it. I'm assuming this means you are planning to resume work on M3 now?

@keeganquigley
Copy link
Contributor

pinging @TorstenStueber

@TorstenStueber
Copy link
Contributor Author

Hey @keeganquigley indeed. We are now ready to submit the last milestone and we are currently working on providing and writing all the necessary documentation. This process takes some more time as Spacewalk is quite complex.

@keeganquigley
Copy link
Contributor

Hi @TorstenStueber unless you plan to submit a delivery soon, an amendment would be required to extend the timeline. Do you still plan to submit one?

@TorstenStueber
Copy link
Contributor Author

@keeganquigley understood, we will deliver this milestone by the end of this month.

@keeganquigley
Copy link
Contributor

Hi @TorstenStueber do you plan to submit the delivery in a couple weeks?

@keeganquigley
Copy link
Contributor

@TorstenStueber unless the delivery will be submitted soon, I think it's best to go ahead and close this grant for now and you can always potentially re-open it should you wish to finish in the future. Please let us know, otherwise we will close it after 2 weeks. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for review The project is ready to be reviewed by the committee members.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants