The OpenZeppelin Relayer is an open-source tool that simplifies transaction management for the Stellar network by handling gas fees, sequence numbers, and reliability through automatic retries. To address scalability limitations, the relayer implements a plug-in system using channel accounts that enables parallel transaction processing, allowing multiple transactions to be submitted simultaneously from a single user account. The managed service runs on AWS Fargate with a shared Redis instance for managing the channel account pool, while the SDK allows users to submit transactions with an API key. This architecture enables gasless transactions and high throughput, making it suitable for applications like games and services requiring scalable transaction processing.
Stellar Relayer: OpenZeppelin Plugin & Managed Service Explained
Added:Hello and welcome everyone to this week's Stella developer meeting. This week we are talking to Open Seelin and uh the primary focus of of this week's meeting is the the relayer service. So uh yeah please introduce yourself and um and we'll get get into it.
>> Yeah. Hi thank you. Um thanks for having us. So my name is Dylan Kilkenny. um a software engineer at Open Zeppelin and the past couple of months mainly working on the the relay infrastructure, the plug-in systems and specifically the the stellar integrations.
>> Hi. Hi, my name is Sai. I'm the engineering manager managing relays and monitors at opening.
Hi, my name is Collins um a site reliability engineer supporting the uh relayer u plugins that you are about to present.
>> Great. Thank you. So we already talked a little bit about uh a little bit about relayer uh just very high level overview uh in one of the previous talks we had with open selein. So, I'm I'm excited about diving deeper into what it is, how it works, and and uh and what you can do with it on Stella. So, please uh share your screen and let's get get started.
>> Okay, perfect. Thank you.
One second.
Okay, you can see my screen. Yeah. So what we've been working on the past few months what's kind of worked [clears throat] towards is this manage stellar relayer service and like in a nutshell what this offers is a scalable high throughput transaction service for the stellar network and there are a few components that uh were involved in the making of this and of course the first of all is the open zeppelin reer so I'm just going to go through like a few of the things that got us here and like what it took to to build this um like first of all you've you've mentioned you've already spoken about like the relayer service but just to go over quickly again uh the open zeppelin relayer is an open source tool and it it simplifies the transaction management for multiple different networks including stellar and what that means is like it'll handle the gas it will handle the sequence numbers the reliability like the retries uh if a transaction fails um so like this is useful for a number of reasons um such as gasless transactions or automating transactions or like scalable workloads.
But one of the one of the valuable aspects of this type of tool is uh that it's secure and secure key management is one of the most important features. And uh in the case of Stellar, we support uh KMS signing, turnkey signing, uh or local signers even. Um so yeah a couple of months ago or a few months ago we started working on a stellar integration for this tool and in doing so uh we now offer full sorban smart contract functionality. So it allows users to deploy contracts through the open zeppelin relayer. They can invoke contracts then standard uh stellar xlm payments. Um and like as I mentioned this offers this is included with uh KMS signing and turnkey signing.
Um but there there are some limitations to um how you can send transactions through the stellar network and and one of which would be uh the the sequence number having uh I'm not sure how to put this clearly but causing issues with uh scalability like high throughput transactions. And so we were working towards um developing some features within the relayer that will allow the stellar relayers to scale uh larger. And one of the the features that enabled us to do this was the relayer plug-in system. So in a nutshell what this does is allows us to extend a standard uh relayer with ex with uh further functionality. So from a developer's perspective, what you would do is write some TypeScript code and inside this plug-in, you would have access to the relay system for submitting transactions, signing transactions, uh querying state, etc. And you would still communicate to the to the open zeppelin relayer through the the rest API, but you would be calling this plug-in directly. And in the case of Stellar, we've used this system for developing a channels plug-in. So the channels plug-in allows allows users to submit transactions in parallel and the the key workflow here is that we use channel accounts for building the transaction.
So in this plug-in system in this spec specific plug-in called the channels plug-in we manage a pool of channel channel accounts and the user sends a request and we acquire a channel account. We sign the user's transaction with that channel account and then we submit it to the stellar network uh with a fee bump transaction as well. So it's also gasless. Um so yeah parallel transaction processing automatic fee bumping and this includes uh an SDK client so that users can uh quickly send transactions or pain painlessly and I'll give a demo of that at the end of this anyway but just to walk through the the flow of of what happens here. So from the client the user will send a request.
The request goes to the relayer and the reer invokes the plug-in. The plugin then acquires a channel account. This channel account is managed by the realer that I must say all of these accounts are managed by the realer but the plug-in is able to lock one and then sign a transaction with that channel account. And that transaction is the one that the user sent. And we then wrap that in a fee bump and submit it to the stellar network. Once the transaction confirms, we release the lock and we send the result back to the user. So the the system is is scalable by the number of uh channel accounts that we have to offer. So if we if we if we put 200 channel accounts in the system, you can send 200 transactions in parallel with with one user account. Um and just quickly on the on the account pooling system we have here. So uh the plug-in system behind the scenes is using Reddus to manage the the pool of accounts. So an incoming request comes in, we try to lock the account. If it's available, we can acquire it, process transaction. If it's not, we try again on the next account. So um it's it's it's it's pretty straightforward. Um and just quickly on the SD SDK client itself. So this is what it would look like for sending transaction. Um so we have this channels client and right now the the base URL is pointing at uh channels.openzeppland.com which isn't live yet. We're still working on getting that live either tomorrow or by Monday. But this could also be uh you can also send this these requests to your own self-hosted relay.
Right? So this doesn't have to go through the through the managed service that we provide. So this plug-in is all open source. The open reception relay is open source. So uh anyone can just spin up their own instance and manage their own channel accounts. But we will be offering this as a service and man managing it all uh for you as well. So it's quite simple. um set up the client and to submit a transaction you in this case we're submitting a sorbent transaction so you just provide the the function XDR and the attached XDR and an example of the response would be like so so this is the transaction ID for the relayer and the hash um for the transaction itself so in the case of someone who is running a self-hosted version they would want to manage uh the channel accounts. So there is uh some methods in the SDK that will allow you to list what channel accounts are available on the service and also add new ones. So if you needed to increase the throughput you could you could add more channel accounts or if there's uh some issue you can remove some etc. Um so yeah in a nutshell all of these things have come together and uh we're offering a stellar relays managed service. So this would include the the relayer service itself and the channel accounts plugin the SDK but also uh the cloud infrastructure. So just a bit of a like a peak into um what it takes to to run this on the cloud. So we are we are using AWS Fargate for managing diff v a v various number of tasks running the relayer service and uh a shared reddus instance. So we have the same pool of channel accounts across tasks. Um and the client's SDK goes up through the the Cloudflare proxy sends it down to the load balance balancer which then um distributes it to to whichever task is free. Um so yeah that's pretty much the overview and I can just give you a quick uh demo right now. But first, yes. So like this is just a demo script as we've already seen um how you would instantiate the client and I have a little helper function here for building a sorbent transaction and here we pass the function in a to the client itself.
So just want to point out first though that in order to use the service you need to get a API key. So you can just call uh the domain channels.open.com/gen to get an API key.
And for the sake of this demo, I'm just going to add the API key here and call the demo script.
So this is going through the staging environment that we have for the managed service right now.
Okay. So the transaction is confirmed.
Uh just to double check that yeah transaction was successful. And just to demonstrate the the parallel processing of this I also have a parallel uh demo.
So, this is sending 10 transactions uh at the same time with uh the exact same account that I sent the the demo transaction with previously. It's just one account. And uh yeah, that's pretty much it. Any questions, let me know.
>> Great. So, I'm I'm a little bit curious about the the managed uh service um because it seems like uh of course depending on your use case that uh especially for maybe testing it out, it it it seems like a lot more convenient to just uh try it out with the with the managed service. How how does that work?
How do I get set up with that?
So we are finalizing the the documentation and the the SDK um today. So once we have all of that documentation published on our uh site the your community will be able to access it and it's a pretty straightforward um setup like as as you seen with the demo. Um [snorts] >> yeah.
>> Okay. Great. And and if I want to run this on it is open sourced. I see that I I can run it on my own uh >> environment. Uh what do I need? I saw you mentioned the Reddus Reddus database. Is there anything else I need to to set up to to run it?
>> Yeah, it's a good question. So we in the documentation we actually have all of this listed out and we provided uh in the open zeppelin repo open zeppelin relay repo an example configuration uh using docker. So all with what someone would need to do is go into the repo and run that docker config and it would spin up the service with the channels plugin already installed and everything's ready to go like all you need to do is start sending requests to it. Um but the open zeppelin real air like reddus is required of course you need the real air installed and all the all the various other dependencies but um there are some example configs that get you up and running pretty quickly.
>> Okay, great. Sounds pretty easy though.
Um what are the the use cases where who do you think are going to use this the most? uh any specific DAP types or any any use cases that you have in mind that you think will adopt this?
>> Yeah, look, I think it's it's super good for someone who needs high throughput transaction processing. Um and also the ga the gasless aspect of it is super convenient as well. So users don't have to worry about gas, they don't have to worry about sequence numbers. Um, so you can see apps like games or various other services that might want to use it. But even you someone who wants to self-host this themselves, the the it's open source. So you can extend this any way you want like the core the core uh primitives are there which is gaslessness uh high throughput like sequence number management etc. And you can build on top of that like whatever you need.
>> Great. Do you have any uh I I know you you you mentioned that the the documentation and everything for the the managed service is going to to be available very soon, but do you have any examples of how to use it? I know you showed one, but do you have like a GitHub repo or an example library?
So, we have a plug-in repo up right now. Um just one second.
So there are some examples in this repo.
Um I'm just going to share it in where should I share it?
>> Uh can you share it in the uh post it as a comment?
>> Okay. Comments.
I shared it in the private chat because I don't think I'm logged in.
>> I'll just I'll just copy it over.
So yeah, there's um a pretty extensive overview of in the readme of this um repo of how the plug-in system works for uh the channels the channel account. And once once the service is live in production like it's it's only a case of being of substituting your local um relay local host with the the production URL and also I'm just going to share the examples from the relay repo as well and that should give honestly with just these two things you can get up and running locally uh pretty quickly.
>> Okay, great.
Um, and this is the example in the relay repo. And there's also um a read me in that as well, which is extensive and um it should get people up and running.
>> Yeah, I I have I have actually gone through the the read me and and taking a look at it and it does look it looks like the it's very detailed. Uh, so I just haven't I haven't tried to set it up myself yet.
>> Okay.
>> Looking looking forward to that.
>> Yeah. Well, let me know if you have any feedback. Um, I hope that it's uh it's simple even though I think it is.
>> Yeah. Any any questions from anyone watching then uh feel free to to post it in the comments.
Carson, I just posted uh the documentation uh which should be available on docs.openszprint.com.
So, I just sent the link.
>> Yeah, I posted it.
>> Thanks.
>> Great. Well, if there's no comments or any questions from Let me just check one more time.
doesn't seem to be the case. But it was great to uh to get to get a little bit more information about the the relayer and to see an example of how to use it.
I think it's it's a super helpful tool and and um I think for now uh I think I will I will try using the manage version first u when it goes live. It seems like an easy way for me to test out the the the tool. I I don't necessarily need to to spin up my own infrastructure for this. Uh so I'll look forward to have an opportunity to play with it. And uh thank you everyone for for watching and thank you all three of you for for joining today. And please go check out the links uh take a look look at it and um yeah, thank you all for joining.
Thank you.
>> Okay. Thank you.
Bye. Bye. Bye. Bye.
Up Next

XDC Subnet Deployment: A Step-by-Step Technical Tutorial
@XDCNetwork_TV
46.4K views•2024-10-08

IFS Therapy Demonstration: Complete Session with Unburdening
@IFSCA
95.9K views•2021-01-13

FastAPI vs Flask vs Django: Choosing the Right Python Web Framework
@TechWithTim
302.5K views•2024-05-26

Game of Thrones Opening Credits: A Cinematic Analysis
@gameofthrones
46.3M views•2011-04-18
Related Study Plans & Knowledge Roadmaps
Structured learning paths in General & Interdisciplinary Studies














![Intro to Blockchain Programing [FULL COURSE 2023]](https://i.ytimg.com/vi_webp/cGQHXmCS94M/maxresdefault.webp)
























