Decentralize Your dApp’s Secret Off Chain Backend w/EigenLayer

Transcript

it I think I should be straight forward um rock and [Music] roll all right thank you again for joining us for our next talk at 100 p.m. uh we are continuing with Wes West Floyd he will be talking about decentralizing your D secret of chain backend with Ian layer so please join me welcome Wes the stage is yours he thanks cheers hello good morning can everybody hear me okay awesome all right uh well thanks for having me this talk is specifically

focused on your service your Dow your project um and particularly finding talking about the areas of your project that may not be as decentralized as you would like and how ier can help you on that path and that road map to decentralization so a little bit of backround for me I'm a part of the devil team at Igan layer and previously uh worked on decentralized compute projects at protocol Labs with fcoin and ipfs used to be a ethereum minor back in the day and then uh also had had a background in web 2 with decentralized systems uh database systems and Cloud systems and so that's like a lot of the motivation of why I'm trying to kind of combine the two uh for the talk and also just Ian Lair generally and also um this

is our broader team for the Devo folks if you want to follow us on build at igen uh build on igen you'll get some updates about hackathons developer news and all those sorts of things so that's a great way to stay in touch with what we're up to okay so this talk will cover your Project's road map to decentralization the reasons the economic benefits the philosophical benefits architectures examples I'm going to go through a demo at the end of a sample project that I took of a centralized backend service and made it a decentralized service with Ian layer unfortunately I cannot get into Ian token details uh in case anyone was curious throw that out there um and it won't cover as much this new concept of

inter subjectivity but I will strongly recommend if you have time to go to the white paper for igen Lair this new igen token white paper which covers a very interesting topic we'll cover it briefly but there's more development work so it's a bit future out we're going to cover today more uh deterministic objective uh examples of um of attributable events SL and how that plays into your decentralization okay so your challenge the setup for for your team is um you've got a great you know Wonderful uh you know decentralized ecosystem it's web 3 it's ethereum but there's a couple backend Services maybe there's a demon that's doing some aggregation that's occasionally posting a proof somewhere

and even though most of your project is a decentralized protocol there's a couple relian you might have on an AWS service or other things that are just you know you had to do with it or you're busy or whatever reason and so so these just kind of focusing on those things and the reason it's valuable to think about decentralizing your entire project is uh a couple things one um your project is paying for those services in Fiat which is very strange because you're a crypto project you have your own token um that makes your organizational aspects more centralize uh your your corporation you kind of relies on who owns the actual service from a security perspective as well um you have a road map for decentralization probably that you're

posting to your team and maybe you have some centralized Services now but you've committed to your community this is our road map for decentralization more recently especially in the US the regulatory environment uh the United States uh legislature passed a bill that said uh if your project is less than 20% owned by an individual then you're considered a commodity which is beneficial so like even uh from a political perspective dcent calization is becoming more valued and so there's a premium just in general and this this talk is really meant to help you on that path all right and so the solution I want to talk about today to these problems is taking your existing app where it is your existing binary as much as as you know limited

amount of work as possible maximum benefit but bringing the benefits of shared security permissionless innovation as an AVS on IG layer uh ABS stands for actively validated service and so um before we get into abss let's talk just about shared Security in general and what this looks like before IG lay and then with shared security and Ian lir traditionally you know your service your blockchain your protocol has its own set of operators like if you look at networks like render or fcoin or any of these really successful web 3 projects a lot of times they have their own operators their own token associated with it the challenge is the security or the degree of decentralization the

economic security the Capital behind it is often siloed and so if you're thinking I'm going to maybe decentralize my network of operators you're going to have to raise Capital you're going to have to bootstrap a network of operators there's friction there's time associated with that in the new shared Economic Security model you have this Capital that's pulled you bring into a larger group of of of capital on ethereum particularly you have a network of operators that are available and ready to run and so your service operates on this existing Network and also takes advantage of your tokens so you don't have to give up the benefits of your uh economic aspects of your token so when we talk about building a service or an ABS porting your existing Services as an ABS and IG

layer it's really trying to get the benefits of all these economic benefits um so reduce marginal cost for your folks and this is kind of the name of the company and how we got it to Ian your own your own layers this is your layer on shared security um in the actively validated servic is effectively taking in this case whatever was your centralized service today and what we're going to do is we're going to add a a small demon a small service that will validate it it will distribute amongst your operators and it will write on chain some proof some evidence that it's operating the way you expect it to and that's how we'll bootstrap the trust now there's aspects of slashing in case those operators misbehave there's

aspects of rewards and payments for those operators when they behave well uh that's actually what we're rolling out on testnet right now is that kind of final component but that's what makes the uh the trust turns it to more of a trustless service than a trusted service so to give you a a slightly different perspective on ABS is this is a very like protocol ethereum Centric view where in the ecosystem there are stakers people that stake um restak eth lsts Native resters there are people that stake your token uh particularly in the igen layer protocol and then there's operators operators have to register their metadata they have to opt in to be an operator and and IG layer we've got I think 250 approximately uh operators today and then there's AVS service that

we're going to talk about building today and the ABS service operates both as an onchain service and as an offchain service and then the consumers could be whomever they could be your community who's already using those services today which is really the goal of this support them to become ABS consumers uh they could be other abss like you may have a backend service that does some simple check the date time or check of a server is available and it turns out other people also need to benefit that uh from that so there's like a bit of a SAS uh you know Lego block building uh uh mentality there as well so there's a lot of folks building a variety of different abss and I won't get into all of them today but I will just say that there's a ton of stuff going on Bridges you know

traditional like rollup oriented Services igda is one ABS that we're building in house is sort of a prototype an example of of a large scale AV abs but then there's other things that you might be benefiting as you're building your abs like if you need transparent um trusted uh encryption environment those are available there's lots of other in improving services and things like that so please kind of consider it as a bit of an ecosystem that you can build on so we talked a little bit about why shared security um one thing in particular here is is allowing you to choose the degree of decentralization that fits your needs I used to work in the decentralized science space uh particularly a lot of year ago

and these folks were very interested in running their own protein folding but they wanted their own um community members within their Dow to actually run the hardware and services you may want that for your folks as well so your decentralization could be amongst your token holders it could be people across different geographies it could be economic aspects of what you care about decentralization you just want solo validators versus large institutions lots of lots of customization there a second really important innovation in igen layer is this dual staking model so in order for anyone to be an operator for your service they have to stake they have to put up some skin in the game and previously prior to this past few weeks when we launched it for IG da U they would stake eth they

would stake uh rocket pool eth or Lio eth or native eth but what we're enabling now is this dual staking and dual core model so that in order for them to be operators they have to have a component of eth and also a component of your token which has tremendous benefits for your community from an economic perspective if you have a new token with low liquidity and and low float it helps bootstrap the growth of your token but it also just it brings it brings the payment of those Services more native to your own Service as well so it makes your your token more of a real utility that your folks can use to fund operations on your network so we've got a ton of operators today when you build the service you could have it just

your community members be running the service as operators or you could reach out to these existing operators and they're very eager to run your service they would love to run your service because they're professional they've got these system set up to run your abs uh in a very uh very high uptime Manner and uh they would love to to participate as well all right so how to get started so I want to kind of condense this process into easy bite-sized pieces whether you're the technical architect in your project or even if you're a Community member and you want to propose a project that could get a grant to help decentralize your favorite uh crypto project right a couple simple steps so first just Identify some lwh hanging fruit a simple centralized service it's easy to

decentralize something that exists today maybe it's a backend service running on a Lambda function in AWS or something simple to start with uh number one check to see if someone's already built it because a lot of these services are being built as a as abss today so some portion of that may already exist second is start thinking about the trust model need to support your service so really fun aspect because in the centralized world everything is effectively trusted you trust that a AWS will run your service properly and they won't be any uh any issues in an ABS world we have to start thinking about what are the aspects of your service that we need to prove it does not have to be a binary decision such that every component in

your architecture when it's an ABS has to be ZK proven and fully verified um it can be a a progressive decentralization you could start by let's just at least create some checkpoints of what's going on in the Serv and post those because those can then be slashed and they can be rewarded and etc etc and so you're moving in a direction of decentralization and then lastly is to uh to build a proof of concept uh take that example here and deploy it on a developer Network on your machine which we're going to do today or deploy it on testnet and start building it out and kind of get a sense for yourself of what's involved um I'm trying to call this an MVA it's a new word so if you like it please start using it we'll make it a thing I don't I don't know if it'll

catch but give it some consideration NBA um all right so uh Step One is anyone building this go to app. .xyz Slavs to see if anyone's building it also we have a repo called awesome abs which lists a bunch of existing abss please check out that GitHub repo um and then think about the the trust model so um today the trust model itself really needs to be things that are objective and provable on chain so for IG da example IG da is a data availability layer IG da is ensuring trust that all the operators in the igda network for that service have received the uh The Blob and they're actually storing that given blob themselves they

sign a key which becomes an aggregate key that gets proven on chain and for that service that is the right trust model that they needed I'll show you an example of a different uh service later on that has a slightly different trust model so you just need to think about you know in the short term what are the steps that you want to build more trust so you can decentralize over time there's a really interesting component which is called inter subjectively uh agreeable truths which is going to come out with big part of the igen token it's discussed in the white paper which are things that are not necessarily provable on chain but that you can have a consensus of people that hold your token that agree with this so for example if we're all holding a a community token

and there's a service that checks you know is google.com up is it available uh we can have one operator that says no google.com is down you can have a majority of operators say google.com is down but everyone that's only owning the token could say yes google.com is up and available and so you can actually Fork that token as a means to incentivize honest Behavior this is a really exciting area which I think for this particular use case of of porting services to abss is going to be a big unlock so please keep that in mind as uh as you move along all right so here we go building an MVA proof of concept we have a Hello World ABS which I'll show you guys here

in just a second it's a great way to get started um we're going to be building some additional components to make it very easy to templatized Fork from there um you will want to customize the onchain contracts for your abs this is kind of the heart in ethereum of what it means to have an ABS and I'll show you that in a second then you want to build an offchain demon and I have built a very lightweight version in Java scpt to show you an example it's basically something where if you have existing binaries and the goal is to minimize development of those binaries minimize you know the effort required to Port them leave them as they are but create a very lightweight service that can interact with those binaries and bring them onchain and then lastly is package this uh the offchain components into a

service something that your operators can run because these operators are not going to be experts in necessarily what you built they want a package they can just spin up run they want some health metrics is it good is everybody happy so we'll make it as easy as possible for those folks all right and this is a view of the hello world uh um repo um my teammate uh gesh actually put this together uh not long ago and so it's a nice kind of easy basic way to view what's required for a minimum viable abs and from an architecture view here this is restating what we just covered which is on the ethereum side there's going to be the Igan lay contracts that you're going to integrate with there's going to be your contracts that you're going to write as part of your minimum

viable AVS you're going to write an offchain demon for your app and then you're going to have uh some binaries which your existing binaries we'll show you an example of of using some existing Docker binaries here in just a second and so is an example of an ABS I spent a lot of time in the past in the ipfs ecosystem ipfs is a fantastic uh technology particularly for storing decentralized information um however many of the IPS hosting Solutions actually have centralized backends and even though you're uploading and pinning data through ipfs you're relying on cloud storage in the back end and so I thought wouldn't it be nice if there was an ABS that was an

ipfs pinning service um that could be available and could be more decentralized but it's also a really good example of porting your service um so the existing ipfs um service has a binary called Kubo which is a Docker container so what we can do is we can Fork from Hello World we can take that ipfs demon that exists today and then we can write a little bit of lightweight code wrote it in JavaScript because javascript's easy everybody likes JavaScript everybody knows JavaScript you could write it in PHP you could write it in shell script doesn't matter it's entirely flexible um and then a little bit of task management code on chain to communicate with offchain code and the onchain code and uh and you're good to go so let me cut over over to a

quick how are we doing on time do you guys know 5 minutes 15 minutes okay great oh perfect okay um so this is a view of what it looks like here for the demo lightweight code to interact with it off the-shelf Docker container this is minimizing as much work for you guys as possible and then orchestrate with any orchestration technology that you like all right so let's jump to a demo here I want to take you to the code repo blow this up a little bit all right so I've got a a series of shell scripts I'm going to run you guys through this is actually a little bit of a tricky thing to demo because there's so many moving Parts um so what I'm going to just kind of give you a visual walk

through here we're going to spend some time looking at this offchain demon and JavaScript here I'll show you the code for that and for this demo we're going to set up this Kubo binary demon here running in a Docker container in order to test it I also need a remote ipfs server so we're actually going to pin the IPS server remotely then we're going to trigger an onchain interaction the onchain interaction is going to tell my operator to pin that service it's going to be like an example of it so you'll see a couple different Docker containers running and this is basically to prove the the concept that I can have some level of um of a trust model that I write back to my onchain contracts which could be slash so I have to have some evidence I requested this uh item to be

pinned was the item pinned can I verify the item was going to be Pinn and that's where we get kind of more into a design uh exercise for the ABS all right so this is my offchain code here and basically it's just going to interact with the local ipfs demon it's going to call it through uh HTTP restful API and I've got a variety of functions here I'm going to check if it's up I'm going to add an ipfs hash this is all offchain code but then I get into some onchain interaction code where I'm going to be listening for an event that's posted to to my uh igen layer contract and once that event is posted I'm going to pick it up I'm going to do some offchain work here and I'm actually going to pin that c I'm going to write it here uh to um to the local local ipfs

server so let's go through the demo here so first I want to start my Anvil chain I'll get that going for us here okay so I've got my Anvil chain running it's up I've got some keys here good to go and then in my second terminal I am going to add these contracts this is my Forge script here to run my uh igen layer code add that to the chain as well so we get the AVS on the Chain okay that's good there and you can see that the anal chain is picked up now my Ig layer code sits on chain and then we're going to start a couple demons so this is going to be the ipfs demon for my operator now normally this would be packaged uh into Docker

composed it would be more easy for the operator to run for demo purposes we'll just kind of spin it up individually and there's also going to be a remote ipfs container that we're going to use for testing now this remote ipfs container really when I was testing it before I had it running on some other server in the cloud somewhere so you can actually see it communicating across and that's better for integrity but it's not as good for demos because you can't always predict the networking between different systems so if you'll bear with me we're just going to do it all locally for today and then I'm actually going to start the binary for the operator and again this would be ideally um packaged for the operator they just hit a start start script and it runs it automatically but for today's purposes we're just going to run it

manually okay so now let's run a test end to end test first we're going to open up this new window we are going to get some environment variables set up and I'm going to create a message that I want to pin on this uh this remote test server it's going to say hey ipfs is uh today's date Prague is amazing and then we're going to add that to the uh remote ipfs server here and we'll get a CID back the CID is a unique identifier for any data that's stored in ipfs so we know that this C now lives on this remote ipfs server actually let's add it pin and add

to the remote ipfs server and let's just check the contents of that remote ipfs server just to make sure everything's good okay now we're ready to test so now we have the scenario where the remote server does have this ipfs server and I have my code my operator code that's listening for any onchain events and it says if there's an onchain event posted I'm going to pick that up I'm going to store it locally and then I'm going to post back to the i l contract that I stored it so that there can be a decision about should I be slashed should I be paid so let's do that so let's check also my local operator API uh operator I PFS instance okay it does not have this um C yet ending in 28w it just has the

default vanilla nothing stored there whatever like the the standard is for Kubo instance so let's admit the contract on chain let's create this task so I actually want to pay I want to um use my in fact as a real consumer I would use the token of the Inception token or something to pay for this and I would say I care so much about this uh particular piece of data I do I want to use the maximum decentralized way to store it possible and that is this example ABS here so let's write that on chain that gets picked up by our Anvil node here as a transaction and then also our offchain service catches it it says okay wow I heard that there's a new a new job for me to take on a new task task management is the model that we use

um so we're actually going to store that locally and we're going to write it back um to the Iger contracts that we stored this information and so now that that endtoend process is complete let's run a quick check of my operator API to make sure that it's stored it here okay and so it has so now we have this file here it's stored locally on chain and we've kind of done the end to end uh components there for storing it so anyways long story short that is an example of porting um a simple binary that already existed into the IG lay ecosystem now it's more on chain now I'm paying for it my token I get all the benefits of

decentralization uh MVA minimum viable ABS let's make it a thing um all right so just to kind of wrap up the talk uh please do check us out we've got um a fun hackathon going here with lots of prizes for folks to help us build reference architectures and more developer tooling we'd love to get your feedback uh as you're going through this process follow us at build anden and then also please do check out the white paper if you have not already there's a lot of really interesting stuff we're going to be able to do also in the future with these architectures um and that is all I have for today thank you so much appreciate it cheers all right that's a very great talk on decentralizing our DB secret

with egg and layer I don't know do anyone have a question I guess we should have a question here over there okay oh sorry um so uh just a question you spoke about this example where you would sort of have an ipfs sort of output that would be provable back to onchain like what if the offchain computation doesn't actually returns something as in it returns void um how do you prove something that returns void that's a really interesting question if you're saying in this scenario there's some offchain computation that happens y but there's no outcome proof of it yeah like it it

could write to a database or it could do something in the cloud for example but it doesn't necessarily return something to prove that it actually computed that correctly that is the most in my opinion the most interesting design exercise of this whole thing is taking things where in web 2 we had this exist we this default trust model where we didn't have to do these things and in this new world we do have to think about these things so if it just returns void it doesn't do anything then we have to think a little bit creatively about how to create onchain improvable visibility yeah there's a lot of different work going on in this space um so for example there are like I have this one idea where I would like to be able to write all of the event logs from a given server Damon

on chain as a way to prove you know not necessarily always deterministically but sometimes objectively anything right there so I think there like a little bit of engineering that has to happen if you don't have a clear piece of text you know that's coming out that you can write on chain um there's another example I'll think of it in a minute but uh but there's definitely some work to do there yeah it's a good call wow thank you yeah cool no question all right thank you very much so um um we have five more minutes for the next um person so stay around

you