The Challenges of Composable Smart Contracts with Mark Beylin

the topic is like on the more technical side but like will be based just off of like what I've learned as a developer in the space over the last kind of couple years trying to develop composable smart contracts and so if at any point you guys have any questions like feel free to ask there's not a lot of people in the room so I'm happy to pause and answer cool so yeah Who am I I've been adapt developer since 2016 I'm the co-founder of a project called the boundaries Network we build the standard boundaries protocol which is if you're familiar with git coin the project who presented earlier we powered the bounties on their platform and so the goal since the beginning of 2017 has been for us to build this like standard for bounties on aetherium so that you know if you guys are familiar with a bounty like a request for someone to do work or something that it would be very easy to integrate that with like any other DAP which wanted to like request particular types of work or for different marketplaces to share different work orders so for instance like I could create a bounty on get coin let's say and automatically have it end up on the boundaries network as well and any other marketplace that wanted it so we've been doing that for a long time and generally I love composable smart contracts I think they're really cool I think composability is like one of the most interesting parts about you know like aetherium to give you some more background into like what is composability this is kind of what you asked composability is this concept of computer science and in general with regards to architecting code and it's the ability to combine a series of independent pieces of code into much larger more useful pieces and composable you know code that is like very you know composable is is that which is you know I have a couple things here you know which is like self-contained code which doesn't rely on a large other web of of other pieces of code is much more easily reused as a component of a larger system and also when when code is stateless this makes code very composable again because it's very easy to sort of combined functionality of different kind of calls into much larger much more meaningful calls and so theoria is this like network of composable code right you have these like smart contracts which can all like talk to each other and so composability is something that was possible on a very like local scale on people's machines before atheria but it's not possible on a more global scale because you can have interactions between you know people's code that they didn't write necessarily in a very easy way and so just going on a little bit on why that's so cool on aetherium so this is like one of the most interesting things about aetherium and the evm in particular in my opinion is that code you know each smart contract gets its own address and so can be you know treated as the same as an individual which means that any actor can also be a piece of code which means your code can very easily interact with other pieces of code by by you know being an actor so to speak within that that contract and so the fact that this is like natively available makes it very easy for us to in theory have our code talking to each other in a really nice way we don't see that as much in practice but it's like very possible which is interesting another reason composability here is cool is that the smart contracts can't change if you have like a something you're building and you want to depend on another piece of code you don't have to worry about that piece of code ever changing you can reference it at a particular address and you know you can kind of trust that it'll always be there and so that's pretty valuable pretty important although it becomes a double-edged sword as you'll see later you can automate you can automate complex and valuable transactions by stringing together simpler transactions so this is sort of like what aetherium offers to you know like just you know spaces like defy and stuff where you could have a string of very like individually expensive market transactions or value transfer transactions and you can like batch them together and this means like of course you can do that within one contract but you can integrate many many different contracts that other people are writing rather than having to do it all yourself which is pretty interesting and finally the thing that kind of got me excited about aetherium in the beginning when I was like first getting into the space was this idea of a network effective applications so you know network effects for you guys is like you know when you use like a social network there's a network effect because the value to you as a user goes up with each number of additional users who are and so aetherium has that as well right like the more people who are on aetherium the more people you can transact which with which is like valuable right but it's also valuable for the applications the more applications there are at aetherium in theory the more valuable each of those applications is because it has more other applications it can talk to and so an example of this I'll get to right now is like Dow's and bounties so Dow is I'm sure you guys are familiar with they take in money and they disperse that money doing different things token holders from a Dao can automatically create bounties which I expend the tokens which is kind of like a core part of their mission is like you know allocating capital bounties automatically get surfaced on like one or more different marketplaces kind of like I mentioned with get coin so for instance if like an Aragon Dao creates a bounty it can automatically do that directly in the contract and without even notifying get coin that bounty can automatically end up on get coin because it's like a code bounty and they automatically screen for those and similarly might end up on batteries network as well and then finally the dao can vote to like accept submissions and disperse them which is like very interesting and we see that like for us as like an application the more jobs there are on the network the more that we have like users of the contracts right the more sources there might be for people to create bounties and similarly for for cows the more applications there are like bounties maybe like grants or listings or all these other different transaction primitives the more of those that there are the more valuable it is to have a dowon aetherium because you can now you know do more with it so that's sort of a network effects idea so getting into the problems problem number one of why we see the like composability is like not working and for background like composability is something that we talk about a lot in theory right and this idea of combining projects as like something we can do on a theorem but studying how frequently it actually occurs the answer is that it's like fairly rare the first reason is that it's it's you know the code just lucky isn't very modular people don't write code and reuse their code people are constantly rewriting the same code for instance like the safe math library isn't our ereference in every contract we don't just like have the same functionality there we're reusing it we're redeploying you know these libraries every single time we deploy a new contract same thing with like ERC 20 tokens and stuff and so in general like it's very expensive to write modular code because you're breaking up your code into much sort of like more much like larger subgroup of contracts basically that's like more sprawling and it's almost always more you know modular code is like more generalized and so it's usually much cheaper to write like very specific code for in smart contracts for a given use case for a given set of users for like one particular interaction rather than having to write like code that works for like all types of interactions welcome yeah so in theory it should be less expensive right like in theory reusing code that's already on chain and and not having to redeploy it in theory is less expensive from a gas perspective it's not necessarily less expensive from a time perspective because again like we don't have tooling for people to test contracts against live deployed contracts you know and so like for testing code like wow this is like expensive not just in terms of gas but like and maybe this is probably the bad framing it's actually like also like time expensive but it is also actually just more gas expensive practically speaking like when you see like arrogance dows for instance are like very modular their code is like very very clean but it's much more expensive to deploy a you know the same Maulik dow structure on aragon than it would be in the Maalik dow contra because the volatile contract is like very specific it's like one use case versus when you write modular code it's like self-contained it's usually more generalized which means you're passing in more parameters which means you might be storing more you know state potentially and then right just be more more code so yeah this is kind of expanding on that users you know most apps are modular because in their contracts are March or because they're not this sort of like maximally generalized version of whatever they're doing they're usually more specific and again we talked like that makes sense why they might be more specific it's easier it takes less time it's usually less gas but what it means is that if they're more specific it makes it much harder for them to actually interoperate with each other for four different contracts to talk to each other because you know they they're too opinionated for them to be able to do that and then finally what we see is like people were modularizing their code too early people who believe that there are like certain functional lines with which they should like divide their code bases and this is not based off like what actually should live in different contracts based on like what is changing maybe or different types of plug-in type systems that people might want to have for a different component people just kind of like come up with their own little modularization and little like componentization of their contract and as soon as that's right and often it's not and it ends up being a waste of time and money next we go into like the issues that people run into would actually like combining functionality the first problem is that most of the code on aetherium is very stateful people don't write a lot of functional code and so what it means is that it's like we're using this code is very difficult because all the code that you're running is constantly referencing particular you know memory within the evm state and so what that means is that yeah combining it is like very tricky and requires just like a much more directed view making sure that like a particular thing like let's say a bounty is like you know we're interacting with like just that bounty and doing a series of things with just that bounty versus if we had like very functional code we could like reuse code and combine it in this way that like we just kind of like know it works because the output of one function is the input for the next function and that's how like really good functional code bases work the other thing that's really interesting is that you can't really combine functionality very easily you can like batch transactions on web three kind of they still get sent as you know disparate transactions but really the only way to like combine these like stateful calls is to do it within like a third-party proxy contract and so what you see is like a lot of things require a lot of like functionality requires multiple you know theorem calls where you're like constantly signing transactions and that some people say that that's a wallet problem some people say it's an EVM problem but it nonetheless makes it more difficult to combine things and it seems like there's a missed opportunity there and then finally the interfaces between contracts are really opinionated they're not standardized my favorite example this is like some contracts use bytes for like string information some people use strings and like different teams will tell you there are different reasons why some people use like you int anything that's not like a UN 256 they'll use like a UN 8 or you in 16 whereas most of the time it like is actually less casick it's more gas expensive to do that depending on the functionality so there's just like all of these weird ways in which like these interfaces are not usually configured to talk to each other in really nice ways and so it requires like a ton of like casting and just like very directed view on each of the ways that you're combining for it to work which means it's just like takes more time to combine which means you know it's just like harder for people to do next you can't update the code again this makes it this is kind of something we talked about earlier is like one of the good things about the composability of aetherium is that you know people can't update the code and so you can depend on it and it's always gonna be the same the hard part is that like code still needs to be updated that like we're still not finished a lot of what we're working on is still very beta and so we require the ability to update a code base most of the time it doesn't suffice to be able to like update like a proxy contract or update the contract it points to you see some teams getting kind of shouted at online these days for having the ability to do that because it's a pretty big attack vector to be able to like change the functionality of a particular contract for some third party to be able to do that and so yeah what we're seeing is like software dev cycles are turning into Hardware dev cycles we're basically like software development cycles are supposed to be very short supposed to be able to write code test it immediately and deploy it immediately and so those dev cycles are supposed to be very very tight feedback loops hardware dev cycles are the opposite hardware takes much more time to build to test to implement and so are what we see with smart contracts is that our dev cycles resemble Hardware dev cycles far more than software we don't ship software or we don't ship smart contracts on a regular basis we kind of do the opposite which makes it much more difficult than most software devs don't know how to work under those dev cycles and then finally you can't notify contract authors if you if you do have an update so for instance like for us when we have like new bounty a new version of the standard boundaries protocol we'd like update we redeploy a new registry we don't update the registry we just have a new a new one that we add to it and if we're talking about you know like a company like Eragon for instance that has a native integration with our contracts it needs to know where to point and you know we could update like an ENS name and the address there to notify it there but there's no like automatic way for us to get in contact with them certainly know like and that works for us because we know the Eragon team we can contact them we have their emails but if somebody wanted to sort of like permissionless lee work on our code there's certainly no way we could notify them organic touch with them about the fact that we're changing the code or that something's wrong or anything like that so that makes it very difficult for two teams and two contracts to like collaborate and interoperate with each other and then finally there was like people problems users rarely kind of compose on their own the users of smart contracts usually are devs and so the onus onus usually falls on the components to have the desire to collaborate with other teams and to build those integrations natively which means like you know it better be in their best interest because otherwise they probably won't do it it's also like just generally difficult to collaborate across teams it takes time it takes effort people you know different teams have different norms and different cultures which doesn't always make it easy and then also of course it's it's expensive just to like spend the time figuring out how to do these these inter operations composability makes markets more efficient but also that means usually that there are lower barriers against competitors which isn't always in the best interest of these these projects again when you have like an open you know like marketplace for instance or this like open ability for any doubt to be able to do something whether it's an error gone down or a Dow stack down that lowers their competitive advantage that they have against each other because the markets are sort of more efficient than we're free and so that's like a problem for those those competitors and that's one of the reasons why people don't like collaborating in the space so now what well the good thing is that people are beginning to modularize their code better based on like the way that they've been used a lot of you know things like cows even bounties have been around for a year or two and and people have just like seen what needs to be changed what works what doesn't and so now it's sort of a more appropriate time to start breaking up code until smaller pieces that people can reuse teams are gaining motivation to collaborate you know we see things like the Libra project coming up where we see that Facebook is like very much moving into the crypto space and I think we see an increasing number of teams seeing that they can't build everything on their own they need to collaborate with other teams and so they're they they're like motivated to do that and to spend the resources and the time to do that the ecosystem is evolving you know the way that we do code upgrades which is great and the ability to like test different things is good I think we're still very early in that sense but nonetheless it's getting better and then finally people are writing more contracts this is kind of the most exciting part about aetherium is that our state continues to grow which kind of sucks sometimes but also so does the like design space of aetherium contracts and like interesting ethereal contracts and so you know kind of back to the thesis I started with like we believe that there's this like application network effect that with every application that people build at events like this one it makes all the other applications more valuable and more useful and so you know just by virtue of us like waiting and having more of this happen the network itself already gets better so that's all for me today if you guys want to do some bounties I have to give a shameless plug we have a battery network Waterloo dot boundaries network we have a ton of interesting bounties there if you want to you know some of them just for like your hack projects some of them that are like not related to your actual hack you know you can like write a poem and stuff like that and of course if you want to get in touch with me here's some great licks but yeah if you guys have any questions I'd love to love to answer them thank you