Soroban services (bridges, event streaming nodes) crate(s): feedback and opinions

[pallid junco]

Asking here if there would be community interest/sdf interest for a liquidity-efficient decentralized bridge allowing atomic swaps (change of ownership of one asset in a chain implies the change of ownership of the other asset in the other chain) between soroban and other smart contract chains. I might have half of an idea but before starting to think about the implementation I'd like to know if you all think it's something that would benefit Soroban considering that there already are bridges on stellar classic and SACs. Leaving this here, anyways, if we decide to go forward with this, development won't likely start in the next couple of weeks since we need to finish up a few things on xycloans, but any feedback is welcome!

Also, I'm not sure this is the correct discussions channel for this kind of thing, dev looks like a better fit than help but I'll create the discussion in another channel if needed.

[rigid marsh]

My two cents is that bridges appear a nightmare to maintain with nearly infinite risks. I'd probably question whether this is worth taking on instead of focusing resources on other areas.

I'll also never use a decentralized bridge so that probably makes my opinion less important.

[pallid junco]

this is a good point of view. The design I have in mind is pretty primitive meaning that it would guarantee the user safety of their funds without using schemes that are too complex. This might be limiting for some features but it does the job for swaps, so it appears to me that it wouldn't be much of a job to keep it updated. Curious though about why you'd never use a decentralized bridge, is it only a security aspect or there are also other things?

[hexed ibex]

I think this is a cool idea and it can be useful in many cases.

Cross-chain swap's advantage is that it is doing what bridges cannot. It can be very helpful to active users, market makers, etc.

You are one step ahead compared to someone who would need to use the bridge first and then swap a token.

If you implement it with Soroban it will be the first project on Stellar using Soroban for atomic swaps. I would personally support it

[rigid marsh]

Curious though about why you'd never use a decentralized bridge, is it only a security aspect or there are also other things?

Yeah purely a security decision. I've seen too many bridges exploited that have been maintained by well capitalized teams of world class engineers.

My opinion on bridges is probably unpopular but I think we have enough evidence that they just can't be trusted.

CEXs work fine.

[hexed ibex]

Yeah it is a good point that we have seen many bridges exploited before. I don't have the technical knowledge to tell what makes a bridge more or less secure. Can Soroban somehow help with the security problem? What can make this one any different than others? What can reduce the possible risks? Is there a way to insure a decentralized bridge, if not can this be the first one? Answer to security related questions can be the unique selling point for this product.

[pallid junco]

@rigid marsh @hexed ibex first of all thank you both for the feedback. Bridge security is indeed a delicate topic because you have a larger attack surface, which is also partly off-chain. When talking about security on the smart contract's side it's the same as talking about security in any defi protocol. The majority of bridge hacks I've looked at over the time are mostly because of faulty code in the contracts or in proof verifications rather than on the offchain code (arbitrum bridge, bnb bridge, nomad bridge, etc). Proof verification should be out of the way in my design since instead of using actual cryptographic proofs I'd be using a cryptographic hash commitment to be later revealed (so a much simpler approach yet very straightforward and not prone to exploits such as forging proofs, even though it might not be as smooth as using proof verifications). The part of the code I'm mostly worried about is consensus (not sure I'm going to use consensus since the nodes act as oracles) between nodes but it's also something that every distributed system goes through, the important part here is to use the right algos.

Anyways, I might probably end up working on this anyways out of fun 😅

[vivid helm]

@pallid junco I think that axelar are the only ones building a soroban specific generalized message passing bridge. Though others, such as allbridge, have an asset transfer bridge that builds on stellar classic. I personally would love to see more innovation in the space. It's dangerous but important. This is a great talk on the potential dangers on bridges (and somewhat ironic because it's by the nomad folks a few months before nomad got hacked): https://youtu.be/9moHHWZUbXU

[wary onyx]

I looked at this and contacted layerZero some time ago. They work with a messaging system, too. I proposed a POC but at this time soroban was not mature enough on the authentication part. This could be another candidate.

[pallid junco]

this is a great talk, thanks for sharing. In my case, I think I'm going for a "non-protocol" approach, i.e not directly shipping a protocol but building the foundation to build a self-sustaining protocol. That's because decentralization is tough to achieve on layer 1s , so almost impossible on a l2 (talking about a solution that is decentralized enough), so I think that the best approach for bridges is for them to be completely liquidity provider-controlled (including the selection of nodes / running their own nodes), and to implement a trustless interface for the users. This way the user is always guaranteed to not loose funds, and liquidity providers are entirely in control of their liquidity without relying on a set of nodes they might potentially not approve of.

It would be decentralized within the set of liquidity providers and completely trustless on the user's end, which is how I would envision a safe bridge.

[jovial pond]

Theres definitely interest from the community: #761985725453303841 message

[pallid junco]

that's great to hear! thanks for sharing

[pallid junco]

Hey there, so after working on this for a while I've made the codebase public since there might already be some useful crate(s) and will continue building public. The codeabse is not only about bridges but mainly about services running on Soroban like event streaming nodes and message realaying oracles. Anyways, the whole codebase is partially broken and definitely not stable or near being production ready. The bridge(s) are still missing many parts to be even an MVP, but I'm sharing it since the crate for event streaming nodes works, and while it needs much more work, it can be the a starting point for those building dApps whose frontends (or backends) need to access events data more efficiently.

Besides sharing this, I'd also love some feedback about potentially making this an SCF submission to finish up and make production-ready the core code, bridges soroban-side implementation with a full implementation for at least an ethereum to soroban bridge, and event streaming nodes. We'd like to know if there is interest in applying before drafting up a plan and a submission, you can find more info and also share your thoughts here https://github.com/xycloo/rs-soroban-cortex/discussions.

Here's the codebase https://github.com/xycloo/rs-soroban-cortex.

Soroban services (bridges, event streaming nodes) crate(s): feedback and opinions

[vivid helm]

How does event streaming work under the hood? Is it consuming events from soroban-rpc or ingesting directly from a core instance?

[pallid junco]

currently it consumes events from the rpc to be a more "on the flight" solution (i.e does not require running a core instance). But I also would like to work with core at a low level and see how event streaming would work that way.

What do you think the most complete solution would be? Personally I like the idea of having both implementations, I think that consuming from the rpc is probably cheaper and rate limits shouldn't be an issue given the latency of the queries is per ledger (~5 secs, although configurable by the implementor). Ingestion from core may be needed though for events that are emitted at a very high frequency and scale (for example monitoring events for a large number of SACs), but I haven't poked around the from-rpc solution as much to understand its limitations.

[vivid helm]

In terms of getting stuff done and playing it safe I would just build on soroban-rpc. It's a pretty lightweight process and builds on horizon's tried and tested ingest package to setup and communicate with a captive core node. You could make the case that if all you want to do is stream events then soroban-rpc is an unnecessary complexity. This would mean that you'll need to write your own version of the ingest package in rust. IIRC it's not trivial but also not the end of the world and I'd love to see that in the ecosystem

The go ingest package: https://pkg.go.dev/github.com/stellar/go/ingest

[next yoke]

Just so I'm clear the Soroban RPC doesn't actually support event streaming correct? This is a combination of polling the RPC and providing an event stream wrapper on top of that poll. Right?

Like the Horizon API actually does support Accept: text/event-stream

[pallid junco]

yes, this polls the rpc and builds a stream on top of that.

[pallid junco]

Thanks for the answer, writing the ingestion lib in rust looks mad interesting 👀

[barren folio]

To answer the original question, one component of our framework (go-perun) is cross-chain channels.
We are currently in the process of releasing an atomic swap solution called PerunX to ethereum mainnet that utilizes cross-chain channels to facilitate completely trustless cross-chain atomic swaps between two EVM chains (e.g. Ethereum and Bellecour). We are also currently developing Perun payment channels for soroban. While there is definetly some ways to go before we will be able to do cross-chain channels for chains that use different smart contract backends such as evm and soroban, I think we have an interesting solution for this, as it is completely trustless and can be made P2P. We are currently working and exploring in this direction!
Also we would be able to do full cross chain channels, which is even better than just atomic Swaps.

Btw, regarding soroban, cross-chain channels between two chains that rely on soroban would basically work as soon as we are done with our stellar/soroban payment channel backend (maybe with some tweaking) in a few months.

https://perun.network/

[pallid junco]

that's really interesting, thanks for sharing! I've always been interested in htlcs used in payment channels (I assume you are using something similar if it's a completely trustless solution). One thing that has always concerned me about payment channels for swapping in a solution that is completely trustless and on chain is efficiency in terms of what liquidity swapping should provide (high availability) since channels would require agreement between the two parties and that gets more to an "orderbook" style market.

Of course though a higher availability means having for instance message relaying nodes which introduces some risk (either security of unability of respecting the workflow consistently) on the LPs side.

ah I see that you actually operate building the tx executor offchain

[barren folio]

We don't actually use htlcs. It's much simpler and more generic

We can also do app channels and virtual channels and all that stuff.

Initially it was designed as a scalability solution, but we are working on making it usable as an interop layer

[pallid junco]

So you're planning on becoming an L2 network?

[barren folio]

Our framework is aimed at peer2peer. So just clients opening channels with each other.
Our first approach to cross chain Swaps with Perun X is having a hub as a client with liquidity on both chains that accepts channels for swaps with certain pricing. From a protocol perspective though the hub is just a normal client

[barren folio]

Well channel networks are certainly possible with perun, as we have virtual channels (meaning if A-B have a channel and B-C have a channel, we can use those to build a channel between A-C without going on chain at all and without trust. We only go on-chain if parties behave maliciously).
This gets complex though. I think it's certainly possible, but if u want cross-chain channel networks, we still got a lot of work to do. Also there is always collateral problem with channels.

[barren folio]

We have another project though which is a cross chain layer 2 network based on TEEs. It is also pretty cool and has veeeery much potential IMO. But it is unrelated to channels and also it is only partially open source.
You can check it out though, it's called Erstall:
https://erdstall.dev/

[pallid junco]

interesting, will check it out

[next yoke]

Looking through the code here @pallid junco this doesn’t seem to support pagination so if the events array for a given ledger is > limit you’ll either get stuck looping on the same ledger as the entire poll is filled with the same ledger or miss out on events beyond the limit. I could be missing something though

[pallid junco]

yeah that's something I've been meaning to add some built-in support for but haven't gotten around it yet. I think I could for now just add pagination as a param. I'm also currently exploring streaming directly from core (but am going thorugh some stellar-core issues)

[next yoke]

I’m working on a version of this using typescript on Cloudflare and have had a bit of a time and I’m actually not entirely sure pagination isn’t skipping entries atm. Looking into it though

Using the ledger number though isn’t fool proof especially if you stream diagnostic events as there are a lot of those so you’ll quickly max out the default 100 limit

I’d love to find a way to stream from core though. Does core open a public EventStream?

[pallid junco]

yep, I'm exploring core since it goes around a lot of these and just streams the ledger close meta

[pallid junco]

as of now, the approach I'm using is running core and streaming the metadata but I'm running into corrupt xdr from the archives so I think I might be using the wrong version.

at least, I'm pretty sure it's from archives since starting a node without local state still fails when syncing with the archiver data

What I'd like to end up with eventually is a crate that automatically runs core, pipes metadata structures it and allows the implementor to retrieve/stream it.

[next yoke]

Above my pay grade. Ideally you could run a really light watcher node that could just ingest from some other consensus node and you wouldn’t even need to run core infra

I haven’t tried to run captive core though maybe that’s a lot lighter and simpler than Big Core

[pallid junco]

yep it should be, probably also the best way since I would only need the meta