Flashbots 🛠️ SUAVE Intro and Dev Environment Setup

welcome to the Suave workshop for eth London extremely happy that you are watching this video um and yeah let's let's get into some uh some background on Suave and we'll also have an explainer of how to set up your first Swap and deploy it as well as we have another explainer on how to set up a local testing environment which includes everything from a Suave node and the mevam node to a L1 chain node to mock as well as Mev boost and validators to mock the entire Mev boost pipeline in case you may be trying to experiment with building blocks awesome so at a very high level our goal with Suave is to be an Open Marketplace for Mev applications which we call swaps that stands for Suave applications um some example of existing meev applications or swaps are um private r R PCS orderflow auctions like me share block Builders relays shared sequencers and more if you're looking for ideas here check out the what to build on our docs uh I'll I'll show that at the end and then additionally feel free to hit up anyone on the team we have tons of ideas and our Forum also has many unbuilt ideas that are great candidates for the hackathon so suve what is it at the highest level it's it's a programmable me pool with three key features one Advanced privacy Primitives so from our experience in running Mev share um not all applications have the same privacy requirements but we do think that for many applications privacy is probably one of your top concerns although there are definitely some applications which need no privacy a great example is uh trading on Unis swap if you are to send your Unis swap transaction to an orderflow auction that allows a network of Searchers to back run it you may have different privacy needs based on the application based on the pool you touch excuse me so one example is eth usdc um if you're swapping eth usdc you could actually probably reveal much less information um this is because the pools extremely liquid um so you probably don't need to reveal as much detail about the size you could maybe get away with order of magnitude and as well you don't need to reveal the direction because a Searcher can send in both Direction back the background for both directions but a very a liquid pool it will become crucial for you to reveal the amount and depending on the pool the direction may or may not be needed um anyways this is just to highlight that there's a a vast design um space around revealing intents and preferences in your orderflow auction next we have credible compute capabilities most of the off most of the Mev infrastructure that exists today is offchain as well there's not a lot of observability in the me boost pipeline we do we have created uh the ability to see bids and from which block Builders thanks to relays publishing a relay API bid standard um but aside from that you essentially get no guarantees into what the program that the infrastructure you interacting with is running so credible compute allows you to do this one of the key ways we do this is by allowing a network of sgx nodes to fulfill your compute and upon joining the network they attest to the code hash that they are running and are continuously uh checked against that as well this allows you to have um guarantees that they are running the correct version of the mevum of which you can deploy applications to and be sure that the node is running that compute associated with your contract on top of the Mev and lastly low latency messaging passing this is important because many applications in the Mev infrastructure space um benefit from lower latency and additionally we see many actors pushing things like submitting blocks and transactions as late as possible to the network so that they can incorporate as many signals from um offchain domains as possible so what does it mean to build your application on Swap so at the highest level it's a place to Define your offchain application logic this can include things from protocol rules to data storage um say you're running an orderflow auction then you need to First have the ability to store encrypted intents and second you need to define the logic for how you are actually auctioning off intents and the the second Point mentioned here is consensus so when your application is ready to move past a single node infrastructure you can actually find consensus and have it run across multiple nodes this gives you replication uh and removes a Syle single point of failure on the right you can think of this ball as representing all protocol data and logic next suab is a place to pay a network of te co-processors to run your application similar to the Paradigm of smart contracts on ethereum today um where you can simply submit your program and it just runs autonomously a network of te co-processors allows you to do this as well in this diagram you can see that the co-processors um aggregate around specific protocol data and logic in order to perform your computation so an application on Suave is a cluster of te co-processors we call these kettal acting as a singular protocol defined by the developer some potential food for thought if suab is a place to create mesh or orderflow networks these are uh orderflow layers that are defined between various co-processors right now we only offer te based co- processors processors but in the future you can imagine MPC or per perhaps even distributed key generated um co-processors which live on your phone so what else is swap it's a place to Define multi-domain offchain applications in our previous example we had seen how there protocol data and consensus and storage that are defined as well as rules um but one thing we didn't mention is that you can actually closely link this to a specific node uh on a specific chain so in this example we can see that perhaps there are a few co-processors which are running your application and they are all situated near optimism nodes and then we can also see other co-processors which are situated near ethereum nodes and one co-processor or potentially many in the future which are um serving app which are performing compute for applications on both clusters this would allow you to accept a cross-chain intent on one propagate it to another Network and receive your token on the other chain so the sve programmable men poool stack consists of a few things first we have a chain abstraction SDK this allows you to craft transactions for different chains um as well as even store or a private key that is generated by the te and uh use that you can fund that and use that to sign transactions on other chains of course we do not recommend aggregating extremely large amounts of funds to a private key stored on a te and we also have various measures for how you can ensure safety in the event that there is a network outage um across these tees you can think of it as these te private keys are really good for um sort of session management next we have a confidential storage API this is how you can put encrypted data onto the te and have it propagate across multiple tees as well we have a builder API and this refers the Builder here refers to block building so if you receive a transaction using the Builder API you can actually simulate that transaction on an L1 or L2 node you can build you can even Even build an entire block you can even simulate a transaction and then inspect the state of the chain after simulation if you want to check the results of the pool and much more next native intense so swab supports EIP 712 messages um and eventually this will actually be the native transaction format on Suave and lastly is the mevum which we won't get into details too much today but it is a um slightly modified evm and when I say slightly I mean that you can still compile regular ordinary solidity into um swaps uh but the key difference is that all of these nodes are running a modified interpreter so when they see specific pre-compiled that are required to make like a network call for example then the tees will interpret this differently than a uh L1 node and perform that Network call they will then attest to the results and propagate that to the other nodes and this is how we enable Network calls so Suave is a programmable mempool layer um using these fundamental tools you can build a Searcher or Market maker on top of it uh you could build an orderflow auction you could build any type of trading protocol um many dexes these days have large offchain components and so you can think of encapsulating those components on Swap and improving the trust guarantees you can build block building protocols and if you want to get even more fancy see we even have ai and web 2 capabilities a small secret for those that are listening this far we actually have llms running on tees today let me know if you'd like to use those so with this in mind you can see how this programmable mempool layer can have multiple actors inter interacting with each of these different components and because they're all defined in solidity and if these applications live on similar nodes then you can actually compose them something which is completely impossible in present day offchain infrastructure and at the top you can see they all coales into a block building protocol which can put out a coherent block to a validator So based on this Suave turns the existing Mev supply chain which is the user wallet Searcher Builder validator um Paradigm into a network of decentralized um nodes that are doing the computation for each of these actors this massively improves the scenario we have today where many of these actors we see in the traditional Mev supply chain are just a single AWS server running and uh you know somewhere that you're not even sure of but now we bring more transparency visibility into this supply chain as well as we reduce single points of failure so I'll quickly run through some of the swap design goals the first is that we hope to to be censorship resistance this is of course a never-ending battle um but one of the key ways we achieve this is by allowing encrypted intents into the network and then propagated this blocks the node from being able to filter transactions based on their contents um one key area of research though is that nodes would still be able to set up a filter at their uh Network level in front of their node that could potentially filter out based on IP addresses but this is quite a hard problem and we're actively developing it and hope to have a solution by maintenance next Geographic decentralization we hope to enable these nodes to run in a variety of geographies so that we avoid regulatory capture of a node running in a single data center in some area next low latency so we have worked on optimizing the hot path from receiving your intent to processing it via your specified program and as well reducing the latency between message passing between kettles last programmable privacy as I mentioned we hope to um enable users and all applications the ability to Define their privacy rules as opposed to sticking with just a single predefined privacy primitive defined by your chain multi-domain these nodes are set up to run uh as many domains as possible and we view this as the most scalable infrastructure and architecture possible and oh whoops you weren't supposed to see that awesome now let's see an example hello everyone in this video I'm giving a walk through on how to build your first uh swab application first of all a small tldr on the architecture of suab that you can sort of fill in and get more detailed information from or our documentation suab has two main components you have on one side the swap chain which is a a consensus chain that receives normal traditional ethereum transactions and on the other side you have the kettles which are the offchain components users can send can use the kettles to execute solidity functions from the smart contracts completely offchain with uh privacy since those kettles run on sgx and once those kettles finish this onchain heavy computation a a transaction for the swap chain is created as some sort of callback or receip so that offchain computation produces an onchain computation and that's what we are going to do now so let's start first we're going to create a repo okay and we're going to use Forge as the template for the project so we're going to use the forge template as as a template now here is the this is the contract that comes by default this not let's create a swap here okay so now as I said there are these two components the onchain component and the offchain component and the offchain component executes as a result on chain component so let's write that down we create two functions really really simple and basic functions first the unch function then the op but what the unchain function returns always so let's assume here that the offchain function has some heavy lifting logic to perform here but what the offchain function returns is a function selector it's a function selector to another function inside the swap this other function will be executed on chain okay so if we follow the the the explanation that I gave before any user can use a kettle to call this offchain transaction the kle will perform this logic and once the kettle is done we'll take this function selector we'll wrap a swap transaction and send that execution onchain and eventually that swap transaction will execute this onchain component okay so now we're going to deploy our first Swap and execute the offchain transaction everything in the in a local network so let's start a DX session we're going to use swap gath SG is the official uh currently maintained client for the swapchain it implements both the swapchain and the kettle component so you can download the swab gu client with this SC command that it's this command is in [Music] the in the getting started documentation that we have online now we have installed so you can even check the current installed version in your system that that means that everything is correct swab get installed we are going to run it so we use the swap. dev flag and this creates the um as I mentioned the swapchain plus the kle running in development mode so by default these exposes some uh already predefined private key funded private key that that we can use so first we're going to compile the examples with Forge so sa is fully compatible with first so we have to rename let's remove the test for now so swab is fully compatible with Forge you can compile any swab that you have with with Forge now once that it's compiled let's deploy it so to deploy it we are going to use um helper utility that comes built in inside suab G to that that facilitates deploying and sending confidential request for the dev chain so let's use it this the tool is called spell so you can see here the two commands that it has so we're going to do deploy and then the name of the smart contract so in this case the first swap. soul two points my first swap okay so this this automatically checks the artifacts folder generated by Forge finds the contract and deploys it okay so you can hear that the transaction well the transaction was sent the onchain transaction was sent and the contract was deployed at this address perfect now we're going to use spell command to send the to send a request to this offchain um function so spell confidential request we put the address of the contract and the function signator that we want to call of chain okay so here you see that we are sending an offchain confidential request to this specific Kettle which is the same as the s s client here and that this generated this Suave transaction right here that eventually was mined now I'm going to Showcase how to emit logs inside your offchain computation so let's assume you have an event called offchain event right here this is an event that gets only emitted in the offchain context let see we we want to emit it here right here twice we want toit this event okay so if we were to deploy this again sorry we have to build first we were to deploy these and then execute the aching call again we'll see that there this doesn't show that any logs were were emitted in order to emit logs from your in your from your offchain context you have to modify your unchain function so we're going use this we're going to use susd SD is this utility that we wrote uh that includes helper libraries and functions to to help building swaps so it's it's easy to install just do swab install sorry Forge install flash. suav STD oh we have to commit see it not works okay yeah okay so now Suave STD is being installed now we're going to use this utility from suvd called the swap so swap is a contract that comes with a modifier called let me of chain locks okay so what this modifier does is that when the onchain function gets called all the bands emitted from the offchain function are going to be emitted onchain so again we're going to build with Forge we're going to do the same we're going to deploy again we're going to take the address we're going to run the example again and now you see that as part of the onchain execution not not the offchain execution but as part of the onchain execution two log events were emitted two offchain event logs were emitted and these are the field or or values of the of the events so you can do not only this but many many more things using using the Suave STD Library we have support for multiple uh protocols like CH GPT or the flashboard mure bundle types or flashboot relay bundle types um you have functions to call the Json RPC end point and like utilities to use transactions and call them in rlp and call them in Js and there's a lot of of utilities that it can help you build your own or your own swap hi everyone this is a small video to show you how you could use curtois and Docker to run your local devet for swap development tldr is you need this repository checked out on your machine so so up example from Flash B organization Docker in CTO is installed and then you run make devet app command and then wait until it will do all the magic what happens right now we run this script from this make file and this script spins up curtois stat and after that it will launch the docker compose with the side cars to this stack which are basically s mm node and explorer that relates to you the ethereum stock ethereum devet that will be running on your machine now is configured by this file CTO file you can find the information about this stack on ethereum org website with some details and then there is a GitHub repository where everything is outlined there is a very good documentation there that explains you how you can tweak your local devet to suit your needs essentially our set up right now is very minimalistic the main idea here is just to do the demonstration show how you could do that obviously if you need more if you need different clients if you need some stuff running inside the ethereum chain you might want to use this curtois haml file to configure what you need otherwise you can use this Docker compos file where we we run side cars to the etherium stock in this file we can see that it is using same doer Network as curtois will spin up and then in the same network we will run so have IMM node with parameters that pointed to one of the CTO stack etherum e nodes and and then block Scout which is essentially an explorer to soft chain while the Explorer to etherium chain will be taken care of by cortosis when the script finishes you will see this long output of everything that is running right now in your machine so there is block Scout for ethereum there is gu nodes three of them there is one combination of Builder Plus Lighthouse then there will be M boost side cars m flat relay and so on and so forth quite a long stack and here is the things that our Docker compost has created by default out of the box you will get very basic things very basic ports exposed to you for your use at predefined ports via this uh ngin X configuration file reason why we need that is that curtois when it spins things up it will expose every single port of your application of all the ports that it will be running add random Local Host ports on your machine which is very hard to predict and it's not very convenient when you need for example your application to know where to find the RPC which is why we need this engine x file also same enginex file takes care of the Explorers so let's have a look at them this one is the etherum chain Explorer this one will the sve chain Explorer nothing happens right now it's to completely clean fresh chains these transactions um are result of me flat because initially curtois would spin it up but we would stop it just to stop the noise that it will generate if you need it you can remove this line in your experiment but otherwise it's two completely clean slate chains so quite useful for for example um scripts where you need to know exactly what happens and when and how deterministic basically now when those chains are running let's try to do something example in this repository there is a number of examples the most interesting for our purposes is this one OFA private which essentially creates a bundle with a background and sends it to the relay and it does it not via direct call to the ethereum RPC but via SWA so it sends uh contract call to saaf and saf Noe will contact the etherum node and do all the work to run it it will need two things taken care of it will need to be told where to find the a RPC and point of the ethereum stock so Builder RPC and point in the ethereum stock we just created in our case it will be el4 because first three will be just plain gets and not Builders and it needs to be told also which account to use by default this uh example uses hardcoded account which is different from the one that is founded in cortosis this key comes from cortosis you can actually find it somewhere in the documentation where there is a list of keys that CTO stack will make sure that they have enough e with this we are good to go we can run it and this is the command that we run and to [Music] see that it's working let's do it like this this example will first fund two accounts and then create a bundle where one account sends some e to another account so these two transactions were created by the example but these four are already result of the bundle being landed you can see it on this m boost relay also something that's spun up by curtois you can see here is this bundle so that's how it all works um one small thing though it will start working after block 128 for that it needs some time to get everything into up to speed state so this particular example if you've been faster than me so probably talking less than I then you would probably have everything ready and running at block number 70 or 60 then this example wouldn't work but after 128 it's pretty pretty stable and predictable yes that's the moment when it will work and now when you are done when you don't need it any longer um same command make diff net down will clean everything up from your machine it will stop the containers it will remove the volumes it will stop the cortosis engine so that your Docker locally is completely empty and clean and next time you do the devet app it will be again very clear and empty chains on both sides this is it so thank you very much for your attention um if you have questions you can ask us in all the channels that we maintain in GitHub issues in uh Forum or on Discord channels or if you see this video at the conference if London then there are guys that are there you can ask them questions as well thank you very much