-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Conversation
Adds the web3 grant proposal for Spacewalk, a bridge between Stellar and Substrate-based chains.
Thanks for the application, Torsten. We will look into it as soon as possible. |
There was a problem hiding this 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 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"). |
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. |
@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.
Yes, some of the Spacewalk design will be based on XCLAIM. We'll certainly keep a close eye on Interlay's updates to XCLAIM. |
There was a problem hiding this 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?
There was a problem hiding this 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.
applications/spacewalk-bridge.md
Outdated
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
applications/spacewalk-bridge.md
Outdated
|
||
- **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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
applications/spacewalk-bridge.md
Outdated
|
||
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. |
There was a problem hiding this comment.
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"?
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.
I totally agree. We will update our proposal accordingly and will make it more clear how it is different from interBTC bridge. |
@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. |
ae86d20
to
5b7e614
Compare
There was a problem hiding this 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.
Thanks @Noc2, I will add more details regarding the oracle. |
@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: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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? |
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. |
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? |
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. |
Thanks a lot, it will be just a few weeks. |
Hi @TorstenStueber how is M3 coming along? |
@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). |
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! |
@keeganquigley Thanks for the message. I will get back to you as soon as possible. |
Hi @TorstenStueber any updates? |
Hi @TorstenStueber do you still plan to submit an amendment? |
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. |
@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? |
pinging @TorstenStueber |
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. |
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? |
@keeganquigley understood, we will deliver this milestone by the end of this month. |
Hi @TorstenStueber do you plan to submit the delivery in a couple weeks? |
@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. |
Adds the web3 grant proposal for Spacewalk, a bridge between Stellar and Substrate-based chains.
Project Abstract
For which grant level are you applying?
Application Checklist
project_name.md
) and updated.