DAPPCON 2019: Process and Toolkit for Layer 2 Mechanism Design - Brandon Ramirez (Graph Protocol)

Transcript

[Music] so I'm brain Ramirez a lot of this is informed by my learnings and experience from leading research at the graph and you know for a little context like early on in our company's life we had a lot of conviction that solving Aquarion for blockchain was an important problem to solve and we had strong conviction that it should be decentralized in line with the vision of web 3 but aside from that we didn't really have an idea at the outset for how we would get there but we did have some skills on the team that I think we're well suited to the project for like my own experience I have you know about a decade working in tech on data intensive products I've had a degree in electrical engineering in

control systems which I'll get to later how that's becoming relevant in the blockchain space and studied a little bit of economics but you'll see there's a lot of stuff that I'd like I'm not an expert in like I you know I took micro econ in college but didn't do grad grad school for that I'm not a cryptographer I think that's something that all of us deal with coming into this space is kind of drinking from the fire hose of like the interdisciplinary nature of what we're doing so this was like an example an email that I got shortly after we fundraised from like an analyst at one of our investors trying to be helpful and and he's just talking about like you know how we can cut down on like modular exponentiations on bulletproof by removing some of the blinding vectors and getting like the performance

criteria better and so like this was kind of that this like oh moment of like men or you know we're drinking from the fire hose and a lot of domains that you know maybe you know no one person can be deep in all of them and furthermore you know right away looking at other projects there's all these decision points that people kind of throw at you and like hundreds and hundreds of different you know decision points and it can be overwhelming to be like kind of hit in the face with you know all these different decision points you know without a framework for for really tackling them so that's a lot for a 20-minute talk so my goals are gonna be a little bit more modest than trying to answer all those these questions for you first and foremost what I'd like to do is grow

your anti library so I know you guys are familiar with that concept but it's basically this idea that what you know you don't know is actually in many contexts more valuable than what you do know right it's kind of this index that you have of like when you're presented with a certain problem knowing the right tool to reach for i'd like to advocate a process for a designing for doing mechanism design at layer two and kind of managing the complexity of you know this vast toolkit that's at our disposal and i'd like to share some tactics and considerations along the way that i think make the process work better so a quick recap of what we're what I say or what I mean when I say you know building that layer to we're specifically focused on service layer so

not the scaling layer at layer two and so a lot of the protocols and in that layer kind of have some commonalities you know having service providers and consumers interacting in some form of marketplace and your goal is to get that service top rate in a trust minimized fashion and there's some nice benefits for working at layer two so there's things I won't talk about in this talk because we kind of benefit from some of the properties of building on layer 1 so we inherit security is probably the most important one this allows layer 2 services and protocols to prioritize performance another really important one is that we inherit logical centralization so like a challenge for you know a lot of layer one projects is like you know how are you gonna

bootstrap the network how do you you know build the p2p networking layer you know the nice thing about being at layer 2 is like we already have this logically centralized layer where we can put registries we can do service discovery stuff like that so I guess I did touch on it but that's kind of stuff that we sort of get for free at layer 2 so starting with the toolkit this is by no means comprehensive but I came up with a set of categories for like the different tools that are at our disposal and they branched out and they quickly become pretty overwhelming and so this is one it's kind of for the youtubers like my hope is that you know people will screen grab this come back to it use it as a jumping-off point for their own research one thing I'll mention here also is like

you know a decision point that a lot of technology leaders are faced with you know regularly it's kind of just build or by decision and I think in crypto we sort of have this kind of like an invent or like black box decision right like there's a ton of complexity where we're building on a platform that's still shifting really quickly so like I would identify the mechanisms that are like the most core to the your protocols delivering and then like really piggyback on like the great work that other teams are doing into space you know so like if you're not a sidechain you know project like don't try and do that research for yourself like if you're not a governance project like you know work with the teams in the space that are focusing full-time on you know those problems and I hope to convince

you during this talk that those are actually like pretty deep deep problems that are worth containing that complexity so there's a lot of theory behind this toolkit as well from academia as I said before it's a very cross-disciplinary domain there's a few I want to call out just cuz I don't hear them mentioned often enough things like social choice theory public choice theory from economics complexity theory which is this budding cross-domain discipline in and of itself that's like pioneered by places like this and if they Institute system dynamics user experience behavioral psychology so these are kind of the domains that I see missing and a lot of the conversation so hopefully we can get more those skillsets represented

in the work that we're doing so the process for tackling this in my mind actually starts with a step from another process called customer development which is focused you know entrepreneurs have used for decades at this point to build products that people want like we just heard about that and the last talk how important it is to like not just solve the technical aspects but actually build a product that people want so for us that started with getting problem market fit that's gonna look very different for a lot of teams but basically are just trying to validate like before you do all the hard work like are we solving a problem that people actually want to see solved so for us that looked like you know during our consulting business we saw big projects spending tens of thousands of

dollars trying to solve the problem as a one-off that we're solving broadly for the space some of our first investors were also actually projects in the space that wanted to use the tech that we're building so that was kind of our like marching orders to say alright we validate the problem well enough to like move on to the next steps so the second step is the technical system design and this actually also proceeds in my mind the incentive and like other you know kind of classical mechanism design and this is just like okay you've identified the problem can you build even in like web 2.0 and can you build a architecture system that solves that problem right and I think a good principle here is that like there's nothing new Under the Sun you know a lot of what we're

doing is we're kind of adapting this like you know a lot of these legacy services and products and to like this kind of new paradigm and so there's a lot of learning that we can do by analogy you know so for us for example you know we have a lot of our protocols allow similarities to like distributed caching layers distributed databases big data products so like the first step for us was to look at like you know how are all these products architected and like what stuff can we adapt to you know our design that we're trying to bring to the web 3 ecosystem so once you have your first pass of the technical design the next step is to actually start doing the qualitative steps of the mechanism

design so I separated into two parts qualitative and quantitative and you'll hopefully become obvious why in a sec so the qualitative mechanism design is actually pretty straightforward the very first thing you want to do is you want to look at the technical system or architecture that you've come up with and identify what are all the key roles and behaviors that are required to make this system architecture function right like people are just gonna show up and run nodes for the hell of it like figure out okay for every piece of infrastructure in your stack like who's gonna do what and why and go find you know as as we did that once you identify those primary incentive mechanisms there's all these secondary incentive mechanisms that fall out of that that like make the primary ones efficient so

like a great example would be like if you you know have a marketplace you know as your primary mechanism you might have these like auxilary mechanisms like curation markets that help make that primary mechanism more efficient and there's all sorts of like common actors now that are becoming sort of standard players and a lot of these protocol designs so you can kind of look into these later at your leisure so this is a stripped down version of the toolkit we looked at earlier I'm not gonna dive too much in any of these right now but these are the ones that are kind of more related specifically to like incentive mechanisms a lot of market mechanisms here micro payment solutions different token distribution mechanisms kind of dovetailing off the last talk

again was talking about like user experience and like how important that is I would actually consider that like a core part of the mechanism design process as well I think one of the fallacies like a lot of projects early in this space was kind of just this assumption that if we apply a token incentive to something that like people will just do it right like this idea that like okay like we're gonna invent a TCR and like there's some like micro incentive for participating and people are gonna just sit at their computer all day just like voting on TC arts and I think that ignores a lot of research and like behavioral psychology that's been kind of developed in like the user experience space over the last you know couple decades so this is a model I like a lot this is called the Fogg behavioral

model and basically it says that a new behavior is the product of the user's motivation to engage in that behavior times their ability to carry out that behavior combined with a trigger to instigate that behavior I think a lot of projects tend to focus too much on motivation and not enough unlike the abilities and the triggers to do the behaviors that you want them to engage in another really useful tool for kind of getting like the qualitative sense of how your system works is this tool from system dynamics is a diagram and tool called causal loop diagrams and it's a pretty simple visual language basically what you're identifying is for like

different properties or variables in your system what kind of causal relationships do they have so like here we're not looking at actors but like this is an example based on maker that like as the stability fee you know increases we would expect to see actually this is mislabeled but we'd expect to see like less locked-in CDP's which is gonna have the you don't want and when you have more 'if locked-in CBP is your minting more dye which is going to have an inverse causation the price of dye and then the maker Dow is gonna look at the price of dye and they're gonna change the stability fee and so this is like one example of like a feedback loop but these things get like really complex my recommendation is to try and like really reduce until you get to like the the

core primitives another thing to do here is when you identify a loop count the amount of inverse cause causations and that's an indicator if this is gonna be a balanced scene or a reinforcing loop and so like a reinforcing loop example would be like a speaker that's just like feeding into a microphone and like giving you runaway feedback or like a stops one that goes to infinity there's also runaway loops that go to zero so like like a collage achill system that's out of balance we're like a predator consumes all the prey in that ecosystem and then population just goes to zero but we generally want our systems that are in equilibrium and so we're generally looking for balancing loops and I'm going to talk about this a

little more later in the quantitative design this is another tool that I'm actually really excited about this is a tool called machinations IO this is developed by some PhD students that were focused on enabling video game economy designers so like things like World of Warcraft and Starcraft and even like board games like monopoly they came up with a visual language for designing these systems and it's heavily influenced by system dynamics as well so you have these like stocks which are like the circles you see how resources flow through the system the triangle is like a source you have the inverted triangle which is a sink so it's like we're minting and burning happens and you have like control signals as well as

your like the dotted lines and this visual language is Turing complete which means you can actually express like any arbitrary like mechanism design system work or you know complex system using this language although it does become like kind of an organ on ik you know if you're trying to get to complex with it all right so that's kind of the qualitative step but I want to make a note here that this is one of the most important steps to iterate so the first time we did the technical system design we're really just focused on making sure that it worked now that you've identified all the incentives that are required to make that sustainable you need to rehash the technical design to like make sure that you can actually implement those

incentives so the analogy I like to use here is that of like commodities exchanges you know they play this really important role that like they let you treat like trade futures on like bushels of wheat for example without really caring if it came from like Nebraska or Tennessee right they kind of standardized the interface for what we're consuming or like that's the standardization is like a core part of like what makes this work another important part is like determinism fault attribution and verifiability but put more succinctly you wanna be able to tell who did what when and there's all sorts of tools for doing this some of these were on the toolkit earlier but I want to hopefully leave time for

questions so we're gonna move through it pretty quick but there are challenges here as well you need to pay attention to some things can't be made deterministic right especially in an asynchronous Network where you don't want to privilege any user over another user you have things like speaker listener fault equivalence you have subjectivity so you have to pay attention the fact that like maybe not everything that you think you want to incentivize it's gonna be possible to incentivize from your mechanism design alright so moving on to the quantitative part so once you've identified these mechanisms like let's say you're using a bonding curve we're using you know some minimum staking amount for like you know a work token model like you still need to decide like what those numbers actually are right like if you have a curation reward like what's that reward what's the inflation rate going to be so

I kind of call all this parameter tuning and there's a bunch of different approaches here some which I think are a lot stronger than others broadly I divide them into open loop versus closed loop control and to build an intuition for what open loop control is it's a type of control theory that's really useful when you have a strong model of how your system works so an example would be like firing a cannon right like it's basically a two-body system we can model it using like classical Newtonian mechanics account for some wind and like we can essentially you know at the time of firing know exactly how this cannonball is gonna land without any future adjustment compare that to like a thermostat which is constantly measuring the temperature against like the target

temperature using the air and feeding that back into the bike to the control signal to decide whether or not it should be running the furnace and that allows it to account for a lot of uncertainty you like the temperature outside like the size of your home whether the windows are open or not things that would be intractable to model the head of and that's something we can take advantage of in crypto land because we're dealing with a lot of uncertainties so the more we can build these kind of loops and balancing mechanisms into our protocol design like the better we can make our protocols robust against the uncertainty like in our in our ecosystem so within the quantitative space there's analytical methods and a numerical methods I'm not going to touch too much on these but to

say that this is kind of like the realm of classical mechanism design microeconomics game theory a lot of these become computationally intractable once you start working with like more than a couple players so like using like game theoretic analysis for example once you go beyond like a 2x2 matrix of players like you quickly get into computational complexities that are like greater like between P and NPS right so they it becomes less tractable by kind of analytical methods so more increasingly I think we're gonna see projects in the space relying on numerical methods which include simulation there's a lot of literature around like optimal control theory dynamic programming I'm gonna touch on a

couple simulation techniques that are kind of really complementary to one another so staying with the thermostat example this is a block diagram which is used heavily in like complexity theory and system dynamics and you can actually simulate these signals flowing through the system so this feedback loop based on like this sort of block diagram so there's like this come into realm of control theory but there's like classical methods and stage space methods and one thing I want to emphasize is that just because you have a feedback loop like a show here doesn't mean it's a panacea for parameterization even within the feedback loops it's really important to get your parameters right because you can have feedback loops that actually never reaches stable

equilibrium so you can have ones that like if you look at this bottom line here they're like under damped or excuse me they're over damped if you look at this white thing that's just basically I can oscillator like that's under damped and so those are systems that never actually reach like a healthy equilibrium and like an example of what that might look like in a crypto project would be like imagine if the maker doubt team was like constant adjusting its prices unlike outdated price data and then was like over correcting each time they would just be in this perpetual swing of never really reaching their target price of dye right and so delays are a common cause of of oscillations like that one thing you might notice that a difference between actually the maker example one like the thermostat example is that in thermostat

example we're modeling things that are like very predictable through like classical physics so things like you know aggregate temperature and a space electrical signals voltages the control signals in the maker example are a little less clear right like we see this maker doubt governance and we see that the stability fee incentivizes CDP creation discretion and destruction but that's not like an electrical signal that we can model using like physics right like that's like that's based on like incentives and like the individual decisions of many distributed agents that might have their own strategies and different behaviors so this is an inherently top-down approach which is useful but you lose a lot of color and the complementary approaches this

Bottoms Up approach called agent modeling and an agent modeling were similarly planed through the simulation you know one step at a time but instead of defining the signals at the system level up from the top down we're actually defining individual behaviors on the agents we can have different types of agents for example you might have some you know agents that first some reason always one open CDP's regardless of the stability because like there's not rational or maybe they're just enthusiasts and then you might have another agent type that's actually more incentivized by just pure market forces right so we can play with like alright based on the the makeup of those like how is this system going to play forward the final step is that you should remember that all models are wrong but

some are useful so actually after you launch this protocol into the wild like it's important to take a look at your models and reevaluate and see if you can actually get them to fit to the real data that you're seeing you know tune the parameters on it tune the inputs but don't just like leave them to die after you launch your protocol this is something you should coming back to again and again and making sure that they're still useful and then a really hard decision for a lot of teams is how to evolve the product the biggest decision point here is whether you want to use use on chain governance or whether you want to make it upgraded upgrades through Forks and this is where things like public choice theory and social choice Theory come into play a lot of challenges that I think teams should be

aware of before they jump into one solution too quickly things like arrows impossibility theorem some theorems from social choice that show like the impossibility of having like fair elections in certain circumstances Vitalik has this great article on how there's like no stable equilibrium in a lot of cooperative games including voting where there's always gonna be a profitable reason to defect so I think people tend to get really optimistic about where we're at in governance and this is an area where I highly suggest black box seen and like that's some of this complexity be worked out by the teams and the ecosystem focusing on this all right thank you