DAPPCON 2018: Second Layer Execution Markets - Logan Saether (ChronoLogic)

Transcript

so I'll be presenting on execution markets I'm from chronologic where we are finding solutions for scheduling transactions so this is kind of something that came out of our research into scheduling transactions and then having a market to execute those transactions and some patterns we've seen emerge from our project and from some other projects in the space so - to people I can intro to this so what we're talking about when we talk about an execution market is the idea of delegated execution so what what this

means is either you are signing a message which indicates your intent to execute a transaction that you sign or you deploy a smart contract which holds the parameters that will be executed at a later date so when you have this idea of a delegated execution you also need the other side of that transaction so you need someone to come in there and execute that for you so it's kind of a one-layer abstraction on top of the gas market so instead of paying for the gas to get your transaction including a block you're paying someone else to pay

your gas and this has a lot of interesting use cases so the one we're all about at chronologic is scheduled transactions so we rebooted the etherium alarm clock project and we're working on Kronos which is a second-generation scheduling protocol on ethereum so there's also transaction real layers so some examples of these are if like adapt wants to have new users but expects those users to be new to

cryptocurrency in general the the DAP can relay the transactions on behalf of users and so can pay the gas costs for those new users who might not have cryptocurrency yet there's also the idea that you can pay the gas costs in tokens instead of ether there is an EIP 1077 which kind of details a standard for these delicated executions and there will be a talk on that later today by Alex van de santé so that could be a good one to attend if

you're kind of interested in these delegated executions and then a surprising example is the mixing miss zero-knowledge mixer so it involves sending an ether ether to a smart contract and then publishing a zero knowledge proof the the the reason an execution market comes in for this is because to publish that zero knowledge proof on chain you have some ether and an account and sending either to an account could potentially link that account to to your identity and if you're using a mixer you kind of want to

anonymize yourself so using an execution market you can publish the zero knowledge proof and have a third party execute that in a decentralized way and then a kind of a similar thing are the watchtowers with state channels these are a little different but they were worth mentioning um so I'll go into some more examples with what we're working on in chronologic specifically with the schedulers um so on the on the left here I have a the way the theorem alarm clock

works which is by having this delegated transaction on chain and on the right I show how it looks like when it's off chain so just to go through this so when a user uses the ethereal alarm clock they send a transaction to the smart contracts this transaction has all the data for the transaction that they want sent later and and then we have the executors which we call time notes which are watching the theorem alarm clock contracts and they keep track of each of

these new scheduled transactions and when those reach the execution window they sent the execution and this transaction gets forwarded as it was set by the user the off chain way looks similar except you don't actually send anything on chain until you actually execute it so you can get the same security guarantees by just signing a message with your private key that contains all the parameters of the transaction and then publishing that to this network of executors and then they

will execute that on chain through a contract which will verify that signature um so to get a little bit closer to the topic of the execution markets so in the context of the etherium alarm clock we have the time notes which are the ones which are watching the contract and executing but we have a a kind of a market where they all compete with each other to send this execution because they will get rewarded a bounty payout when they execute so we have in this

example we have five time nodes they all want the bounty and they all send the transaction at the same time because this transaction can only be executed once we come with this situation where there's a race condition and only the first transaction which is mined in the block will actually be successful and I give the time note the bounty payout well the rest of the nodes who sent the transaction will end up reverting and this might not seem like a too big of a problem from a user perspective because the user still gets the transaction sent

that they scheduled so so from a user they're happy because they got what they wanted but from the perspective of the time notes all the ones who weren't successful and got reverted will end up paying gas costs for that River revert while only one of them will get the bounty so these are just numbers for illustration but the idea is that if there is the five nodes in this network and one out of every five times is successful but the other four out of five will cost the money you see a overall net loss in the network versus a

net gain so there the incentive of providing the bounty actually starts to disappear if we have this race condition so the kind of the major like design we're looking at is to find a way for the time nodes which are these layer two clients which interact with the chain and watch the chain the theory on main chain but um don't actually exist at smart contracts they exist off the chain we need to find a way for them to coordinate and not not try to race each other to the execution so I'll go into a

few of the kind of design ideas that were thinking about and a couple of the mechanisms that that we're thinking about so so the three major kind of topics that we have are the problem of incentivization communication and coordination so the incentive is necessary to having an execution market that will execute the transaction because without any kind of incentive they have they have no reason to be running a client it'll cost them money

and they won't do it pro bono so incentive can be either tokens or it might be more intangible things such as adapt that wants new users might execute the transactions on new users behalf because it'll help out with their growth rate rate for example but the main idea is that there needs to be some kind of incentive in place the next major problem we see is how do the nodes in this market communicate with each other

or sorry this one is how does the user communicate their transaction to the notes so with using the term alarm-clock we this problem isn't it's solved by just omitting events on chain so the nodes just watched the chain and the the user when they scheduled the nodes will be alerted but if we have an off chain scheduling system where the user just signs the message that doesn't hit the chain so there is no way for the nodes to watch the chain in that instance so we need some other kind of communication

between the user and the nodes in this execution market amen and these this is can be for the most part any kind of communication channel it could be a peer-to-peer network it is used for example like PCP communication channel I could use whisper potentially but there needs to be some way for the user to publish the transaction and for the nodes to become aware of it and another thing is a way potential way that is preferably censorship resistance as well

and then the final issue is the coordination between the nodes so this is the this goes back to the race condition so to prevent the race condition we need some way for the nodes to decide which one will be the one that is sending the execution transaction so there is a potentially on chain kind of coordination solution and this is kind of a similar to like a proof of state kind of thing where the time node will stake some token or some ether and then they specify what kind of transactions that they're willing to

execute so this would be a transaction that's not at some time Delta in the future as well as some bounty payout and then when user schedules a transaction the time node will get assigned to that transaction and then they will be there a stake will kind of be attached to that transaction until they execute and then look at the stake back and if they fail to execute another time though it can come in and execute and get some of their stake instead and so this is like a non change solution and it works if we have the on change scheduling but if we have the off change scheduling which is

the direction that we want to go in because we can essentially move all this off chain and save all the gas costs this we can't use this kind of mechanism and the off chain coordination is a problem that is a little bit harder because so the the properties of the time nodes in the execution market is a lot similar to like nodes in like a blockchain network it's a permission that this network where we expect some kind of peer-to-peer communication and coordination so it leads to essentially needing some kind of consensus between

these time notes and this is something that we're still thinking about and trying to find the best way for an off chain consensus to be reached and yeah so that's about it we have some links here to our github repos I