New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

EthCC 2: Piotr Kosinski

Ethereum ParisWed, Oct 9, 2019, 12:00 AM

EthCC 2 EthCC, the Ethereum Community Conference is created by the community, for the community. It brings together great minds and forethinkers, and allows the community to grow. Follow us : @AssethFR https://ethcc.io

Transcript

[Applause] hello hello hello I can can we start guys Thanks all right so hey my name is Peter with chronologic so the topic for today is decentralized automation it's something that we kind of you know we work on these kind of topics quite a lot in the past year so we are the team that worked and deployed the etherium alarm clock protocol to the mainland last year so it's it's kind of near the automation the clock is something about the time scheduling I'm gonna tell you a little bit more later on we're gonna talk about the topics and it's gonna be also interesting I think for the meta transactions and three layers and all that stuff okay so let's get started it's gonna be fairly easy at the beginning I'm gonna run to ramp up a bit you know more details later on so we you know let's just start with like a very trivial you know etherium transaction so basically a descending one if to Bob right so what's happening is that you know Ally's signing and then broadcasting the her transaction to know to the etherium network miners takeoff and transaction is getting you know after a few blocks confirmed so essentially bob says like hi I have like 1/8 from Alice right it's like I guess everyone understands it was like a the basics completely complete basics of how it even works and and now we just wanna like add a small ingredient into that whole thing and you might think that's that's fairly simple but actually we will not do now something like hey I wanna send one if to Bob but when for instance my my you know balance is something like to Eve maybe I you know Alice waiting for an incoming transaction from someone else and essentially what I like you know forward to Bob right and I don't know if he I was like pretty surprised when I like you know started with aetherium like few years ago at the beginning that actually there is no way or possibility to schedule a conditional you know transaction or a time-based transaction and such a thing I mean this is pretty straightforward typically like it when you look at the Linux Linux kernels you know this kind of things doesn't live in the kernel space they live like outside in the user space so I can imagine like a tearoom doesn't have the opcode for like you know delayed transaction or like conditional transaction something like that right so let's take a look how we can potentially could like you know build that kind of thing without actually you know changing the way it even works today so you know as I said before Alice wanna send one if the Bob but only when some sort of condition is met right so what she does is like sign and let's say store this transaction along with the a condition so condition in this case is our this balance is like greater than two if right we need to introduce some sort of like a node or agent I'm gonna call it agent the like further on it's not like it theorem notoriety room agent in the in the network so it's something else right but you know on a very high level this is something that is going to you know watch for the condition and if condition is met just publish or you know broadcast the transaction to the network that's like the easiest possible way to do that right or now like a high-level so you may want to ask like why we wanna do that at all and actually there is quite a lot of use cases for such a thing it's you know this is this is pretty much the same the same picture that was on the previous slide but this time you know we wanna send to someone her like a smart Bob is in fact a smart contract right and we are not going to query for my balance for the Alice balance but we're gonna actually set a condition for a smart Bob you know state so we represent that as a smart Bob state is you know greater or equal to two I know it's like fairly high level but we're gonna like you know specialized is a little bit more later on but pretty much the same set up we have an agent going to look for this for this condition like executes and tests the condition on the against the network and then you know execute the transaction to the smart Bob and you might ask who's the smart Bob and you know there is actually quite a lot of you know use cases the smart Bob you can see this like you know maker Dow CDP for instance and you want to build a you know the conditional transaction that is going to be lunch let's say when you are in a liquidation is just nearby so you know you don't want to take a risk and wanna like you know top up your CDP for instance the other use case which is like really like big and that's what we also explore in like recently is all sort of UTC OTC trading and this is because basically you know OTC trading is very often about the future you know assets future tokens and this is like a paper agreement like you know like a legal agreement between some people and if someone gets some tokens go it has to be like you know like forwarding those tokens to the to the destination and this actually you know idea of having this as a conditional transaction it is it's fairly you know relevant for these people and also because you can actually show you know in some ways that this transaction has been scheduled and it's going to be executed when the condition is met it's also like a additional like intent for the person who is waiting for this transaction and obviously another use case is something that we build as well is a scheduling transaction so if the room alarm clock it does actually do the same thing as I showed you but the condition in fact is a time so you know I want to send the transaction but I want this to be executed like tomorrow maybe one year from now so this is essentially that is pretty much the condition the condition is tested against the timestamp on a smart contract or the plot number or what have you right okay CDP monitoring that's already mention yes topless take profit features for the the centralized exchanges that's really interesting thing that we've been you know exploring and actually some of my colleagues delivered some a working working things noted like finalized but you know one of the problems we see with the centralized exchanges is that you can't really do a decentralized way of doing a stoploss functionality because essentially you would need to trust someone to execute their transaction and you know we talk a lot about the decentralization and so why it's centralized certain things right yes and not the last but you know the the one from the list is the state channels watchtowers it's also you know the watchtower is the idea that it helped it is like essentially a availability manager for the state channels right so one of the assumptions of the state channels is that both parties should be online you know in case of any like you know throat or something like that you need to be online to prove that you know the state like submitted by your counterparty is wrong when you are not online then you just hit that hit the timeout and essentially you know you Lou you will lose pass and basically even though you were right so you know the state channel is like a third party service watching the state and just reacting it's like an insurance or data availability provider um so okay let's let's talk a bit about you know how we could build such an agent right so on the previous slides agent was like like a very you know high level thing and you know I'm the engineer so for me was the first idea was like hey let's let's just code the EDM contract that is going to hold the condition and and you know execute the transaction when that time comes or they when they're trying when the condition has been met right it's yes of course that's doable but and that's part of the reasons we also build a theorem on our clock is that you know who is going to execute who is going to trigger this transaction right as you know smart contracts are pretty much reactive so you need to have like external trigger to something to just happen right it's not going to happen like by themselves so the question is that who is going to trigger this at the right time or the when the condition is met right I'm gonna talk quite a lot about that later on this presentation so the other may be issues or or not is you know the contract essentially becomes a message center so kind of the owner of the transaction which means like the the this kind of contract that is relying this transaction is also your identity you know you can imagine that you wanna like sell the cryptokey D okay but the owner of the crypto gate is your private key account and now if you wanna like delegate this and use this through this proxy contract then the transaction is being sent by the proxy contract which is not the owner of the crypto key D which is a a big problem essentially with many many integrations on the interior and I think anyone who actually launched a may net protocol on the theorem knows that even though the coding of the smart contract is not really like I mean it's hard but it's not like the and the world but there's a lot of you know time and things and Trust and everything required to just make people use your smart contracts so you do like you you know old it's like formal verification a lot of stuff essentially what I'm saying like it's very expensive and not everyone basically can just do that right it's like a very very big limiting factor for these smart contracts in the end all right so you know let's say you know what's the other way to kind of build that stuff right let's not use the idiom let's just see how could we build like I call like web 2.0 agent it's not like 2.0 it's not anything about the content but it's just to highlight kind of the way you could build that if there is no like the centralization concerns at all right so that's fairly easy on the other hand because you need like some API a database and some sort of workers that you know on a on a block level or maybe every ten seconds just query the condition and then post the transaction so even though this looks like pretty terrible if you are in the decentralized world is actually pretty convenient because here what happens is that what's going to be stored on the database is actually signed pre-signed transaction and the condition so pre signed transaction is is you know is just like a tearoom transaction like you can imagine this like this wallet sending a transaction to in Fuhrer right so it's pre sent transaction in fewer only bad thing that inferior can do with your transaction is not to execute it not to include into the network but that's probably know a like in most most of the times there is no incentive to do that for that right so pretty much here you have the decentralized in a way of signing and you know publishing transactions and storing what is really centralizing this kind of solution is the execution right so this so our company is responsible for like you know querying the conditions and in the end sending the transaction but we can't do anything with your signed transaction basically it's like immutable right so you know some of these like you know characteristics of this kind approach of building a centralized service that is like kind of glued to the decentralized world is obviously cheap now identity issues you know no fans custody because that your transaction that is being sent yeah but it is it does require trust for the execution part so you know I'm gonna now focus on how to build and how to like design the network of the of those executors so we gain trust and you know I'm gonna show you how we did for the e-team alarm clock as well so you know what we want a descent rise obviously you know we wanna like remove the friction of the trust or the execution accountability it's because if you schedule a conditional transaction it might be like more beneficial for the executor to not execute let's see this is like a very high paying or like you know big big transaction on the decentralized exchange right so maybe someone is you know dumping my tokens so I better not execute that right so here we're gonna talk you know how to bring this accountability and and Trust and also reliability I mean it's not necessarily like I mean the we talked about the peer-to-peer network so it tends to be in theory more reliable than the single networks but in like you know when you use just like AWS and other cloud providers in most of the cases they just work right so it's not like a big concern here so yeah so that's pretty much the same you know the same image what we gonna do we gonna build a network of this kind of executors and it's no longer like one company running the nodes it's like every one of you can run a node and provide these service and I think I mean this obviously is very valid for the current you know meta transaction trends as you as you saw and that was like presented in the previous presentations like at the moment everyone just focus on the UX part no one really focusing on the decentralisation part of the meta transactions enters they just run the node right about as I said the the best best like the bad the baddest thing they could do is just withhold a transaction although method transaction doesn't carry any conditions and and like a time scheduling which is completely different thing you know of what we're doing all right yeah let's let's basically take a look at this so before we kind of start talking about this decentralisation of the relators network we're gonna need to build like some sort of vocabulary so everyone understands you know what I'm talking about basically so delegated execution it's you know the does the pattern or like the idea that someone else is going to execute your transaction in the exchange of some sort of bounty or incentive right so it's like miners including the transactions into the blocks they just get paid your transaction fees on top of a obviously the block reward like in the long run when we just like in in the Bitcoin space when we just mind every single Bitcoin the only incentive for running the network would be the transaction fees right in in theorem that pretty much depends but that's like the idea right and then all the sudden when you have this you know delegation in place so you said like I want my transaction to be executed and I just give you like in a1 Eve for the reward and I don't really care who is going to execute that because you know I don't I don't really care because that that's gonna be from my contractor from my address right so all the sudden you are incentivizing multi parties multiple parties to join this sort of network so the network or the execution market is actually being formed at this time right so you know we have this network because anyone can execute your transaction in this this this idea anyone can join and anyone can run the node so what we essentially ending up with is the a market where you know we have the executing agents we just provide the service and the bounty so so like there rewards are on the demand side of the equations and that's fairly like that's that's pretty important because you know the network won't exist if there is no bounties for the execution and also no one's gonna like wanna delegate the execution if there is no running notes right so that's important to build this kind of network and also if you more into the economics this is pretty much some characteristic of the perfect competition market so you know those executing agents they provide the same service everyone provides the same service everyone have the same access to the information and also that means that only long-run the the probably the the rewards or the likely you know the profits gonna be very marginal because everyone's gonna be competing you know to just run as cheap as possible their note so they can provide as cheap as possible service it's gonna be like reliability versus the cost of running and that's how basically a theorem alarm clock works so we have a community running bunch of nodes they are incentivized by people scheduling transactions yeah and it works without any like without us basically so I think that's really important for the meta transaction in the next step in the few months or whatever you know time that they basically gonna get into a decentralized market so it's gonna be like freely for everyone to run them out and maybe earn money on top of like you know whatever obviously there is like quite a lot of now we talked about the execution markets that's like the centralized and open there's a lot of stuff that you know I have to have to be you know have to be taken into the account so you know let's let's talk about the bounties so is it like one-time bounty or maybe like a subscription or you wanna get paid with either year say 20 token maybe an F key or maybe actually on the biggest biggest abstraction it is just like a you know the pay to code kind of thing so you know I execute their transaction you exit and I then execute the payments transaction so if you abstract this into the code then it can be like you know the reputation boost maybe is more important than like fractional amount of ether you know or maybe like I wanna get paid with NF TS because that means for something for me I don't know so what I'm saying like that's something that we work like you know a few months ago it just tries to capture and generalize the problem of the payments this obviously could be used for there for like you know incentivizing the miners but that's that's really like a huge change so probably not a good idea yes storage just quickly go with the story so if you have the conditional transaction you know one of the problems with that and that's not the problem of the meta transaction because they don't have any conditions right is that you don't know when the condition is going to be met which means that in the bat in the worst case it could be like Hank forever right well you said like I wanted this to be executed when my balance of either is like 10 millions of either right it might never be true hopefully not but maybe so what we you know we gotta store this transaction somewhere so there's like some of the options in DM storage IBM events IBM events is like a really happy way to use the advantage of the storage of the etherium but not really using the EVM if your smart contract doesn't need that I mean you can or ipfs swarm you can just put the payload back to the sender payload with all the queries to the smart contracts and then compute right so it is possible to the agent like almost entirely skip the the storage on IBM in many cases all right conditions so yes you know IBM state and pass testing functions IBM events and obviously like in the long run Oracle's that are delivering some sort of you know information from the outside world that's gonna be really huge you know for for the conditional execution yeah one of the big one one of the biggest problems is that if you have this network is that how you know how we make sure that someone should execute and didn't right so here there is a work that we do on the IBM state probes which means that you know you can have like other Network participants proving that you should execute and you didn't execute so you withholding essentially the transaction and you know you get this like a challenge periods take based slashing conditions all the stuff very similar to the plasma and other constructions yeah obviously last part is going to be about the coordination so one of the problems with this such a nether is that you know to kind of settle or get the consensus who's going to execute your transaction essentially if you just put the let's say the requests out of into the world then unfortunately that's not a zero-sum game so you know if someone want to send that transaction on the on the theorem and then ten other nodes follow the same transaction so only first one's going to be successful and the other ones gonna fail okay so what does it mean that all these like nine remaining transactions gonna take a cost like - whatever amount of money and only the first node is going to be get like you know reward so this is pretty bad because it's not sustainable way of building a network that's why there is quite a lot of you know ideas how you can how you can just build a coordination or consensus essentially in that such a network random election like beacon chain kind of thing auction based so you wanna like do some interaction interactive protocol on you know settling the the amount of reward that you are willing to execute you know and then the whoever is going to asking that can just pick the chip as well or whatever or can look at the reputation you know based so yeah that's pretty much it I mean there is not really like like kind of ending thing I want to show you that going from this centralized to point a web 2.0 agents into the centralized is quite a lot of you know work and and then there is quite a lot of discussions I guess that many people will have whether this is like Wharf to decentralize everything or maybe just do a partial the centralization that's something that's probably you know we get an answer in the future I guess yeah so this is like a little bit you know of the things that we did and you you know the clock is now into might roll that probably released today maybe tomorrow I think they merged our pull requests at night today yeah and other solutions that we work and you know the time of network which might be suitable for the meta transactions as well so yeah thank you there is a bunch of links that you can just follow us and see our work and etcetera okay thank you and questions all right I guess that's it thank you oh one question I mean yes I mean we have the ultimate tool which just automates the execution so actually you can execute any transaction any payload transaction to anything so you can build on top of that like CDP or something like that monitoring if you ask about that okay oh yeah for sure that's one that's definitely one of the attack vectors on such resolutions yeah I mean for sure the font front-running is always like a a threat for this kind of like competition you know between the notes there is there is some sort of like you know what we for instance have in the in the clock is that we give the I window of time for the execution so because in other words if you said like I want this transaction to be executed at block exact block then it is probably not going to happen because it's fairly easy fairly hard to kind of you know snipe this you know good a good time to get included into that given block so you wanna like relax those conditions so in this kind of case the state problem might be like you know valid and that's what we looking at has to be valid for like five blocks or ten blocks you know and then it's good to go and if it's like or actually you can have like additional conditions so it's not exactly a amount but it's like a range of amounts so you know in like 0x idea it's not like I want a stop condition at this this price because it might be hard to invest in decentralize a manner to just you know guarrantee the execution but if you wanna sell like relax that and you allow for some range of the values it's fairly easy than to do that thank you [Applause]

Automatic transcript — names and jargon may be misspelled.