Plasma and State Channels Inspire Development Team

Philippe, Joseph, Logan, and Sean of the ChronoLogic team attended EDCON 2018 in early May and we had many insightful discussions on how to improve the Chronos Protocol. In addition, we conducted a series of interviews with various attendees such as Matt Spoke and Bob Summerwill to collect their thoughts on the future of blockchain. In this article, we will outline some of the major things we learned and discussed at EDCON that can be applied to ChronoLogic’s work. Please note that more technical and in-depth articles regarding the ideas presented below will be produced over the following months. We will generate these technical articles to properly document the results of our research, share our insights with the greater community, and to invite criticisms in the event that some of our results are incomplete or incorrect.

Summary :

Using an off-chain scheduled transaction claiming mechanism to minimize gas cost. Using a secure source of randomness for the off-chain claiming mechanism. Transitioning our protocols to state-channels or plasma for significant cost reductions and efficiency gains. Destroying past scheduled transactions to get a gas refund and reduce the cost for newly scheduled transactions.

Off-chain Transaction Claiming Mechanism

One of the first topics we discussed while we were at EDCON was the concept of an off-chain claiming mechanism for TimeNodes.

Scheduled Transaction Claiming Mechanism

Currently, when a transaction is scheduled, anyone can execute it when the execution time comes. This leads to a race condition where many people try to execute a scheduled transaction in order to win the bounty associated with it (but only one person can succeed). This means that many nodes will pay gas without receiving anything in return. In general, this additional cost is also bad for users, since it’s more costly to run a TimeNode, the bounties will need to be more expensive.

Ideally, we do not wish to have this race condition which increases the cost for everyone and only benefits the miners. Having a means to choose ‘who can execute which scheduled transaction’ is what we refer to as a claiming mechanism, where a transaction is claimed by a node A and only node A will be able to execute it. Here, I am introducing the concept of an off-chain claiming mechanism and for other approaches that are currently being worked on, please refer to the April 24th & May 1st Webinars.

Off-chain Claiming Mechanism

In order to reduce the costs associated with claiming scheduled transactions, we decided to explore the option of having an off-chain approach. By this we mean that the TimeNodes would reach a consensus on who can claim a given scheduled transaction without interacting directly with the blockchain. Fortunately for us, there has been a lot of research on consensus algorithms over the last 20 years, including the more recent research on Proof of Stake algorithms (see Casper CBC /TFB & Casper FFG as examples).

A general outline of the approach would be as follow ;

TimeNodes stake an amount of DAY tokens before being able to claim and execute scheduled transactions. A claiming queue is generated for each scheduled transaction, where the probability of being at the head of the queue is proportional to DAY tokens staked. For a given transaction, TimeNodes state whether they want to claim the transaction or not, starting from the first node in the queue to the last, until a node states that they will claim the transaction or until the end of the queue is reached. The TimeNode that stated they would claim the transaction goes on-chain to actually claim the scheduled transaction. The TimeNode that claimed the scheduled transaction executes it when the execution time comes.

Obviously, the above outline assumes that TimeNodes are being honest, but we are including slashing conditions for TimeNodes who behave illegally. For instance, if a node went on-chain to claim a transaction without having the consent from the rest of the TimeNodes, then others can prove that this node was behaving illegally and the faulty node would lose part of their stake as a penalty. There are other slashing conditions and optimization approaches that are being investigated, but these will be saved for the more technical post on the off-chain claiming mechanism.

Source of Randomness on Ethereum

Having a source of randomness is intimately linked to the off-chain claiming approach, since we need to fairly generate queues so that the probability of a TimeNode being first in any given queue is proportional to their stake, not more or less. Fair randomness is not a trivial problem when it comes to blockchains, as can be seen by the many articles on the topic (see this article). Sharding researcher Justin Drake from the Ethereum Foundation gave us some good insights at EDCON on random number generation.

One of the simplest approaches is to use the hash of a given block as a source of randomness, however this approach possesses various flaws that makes it unfit for various applications. Fortunately, as will be discussed in a more technical article on randomness for Ethereum, using the blockhash for our claiming mechanism turns out to be secure.

One of the main reasons is that manipulating the blockhash can be very expensive for a miner and is definitely not worth it for the small gains like the scheduled transaction bounties. Another reason is that the TimeNodes don’t actually choose when a given queue is generated, since it’s generated when a user schedules a transaction. Hence they can’t “fish” with a proxy contract for the right blockhash like what could be done for lottery contracts or CryptoKitty.

State-channels

We could extend this idea of having the claiming mechanism off-chain to almost everything involving scheduling transaction and conditional executions. Indeed, in the off-chain claiming approach described above, TimeNodes are effectively in a state-channel, but not the users. The next logical step would be to allow the users to also enter a state-channel with the TimeNodes (or a subset of them). This can lead to some significant improvements such as “free” transaction scheduling and partial privacy.

Indeed, the users would simply send the TimeNodes an off-chain signed message stating that they want to schedule a transaction, which doesn’t cost any gas. They would provide all of the information regarding the transaction to be executed, such as the call data and the bounty size in ETH. In addition, if only the user and the TimeNodes are aware of the scheduled transaction requests, then no-one else will be aware that these transactions were scheduled until they are actually executed (or briefly before for those watching the mempool). This can provide partial privacy which can be important in certain applications.

Liam Horne from L4 Ventures (among others) has been helpful when it comes to migrating our protocols to a state-channel framework and we are thankful for his time.

Gas refund

Storing data on the Ethereum blockchain costs ether for very good reasons, one of which is to make sure that the size of the blockchain does not become infinitely large. However, this cost can be recovered by emptying storage slots that contracts use or by self-destructing a contract directly. In the former case, the refund is 15000 gas and 24000 in the latter. This creates a mild incentive for users to remove unused data stored on the blockchain. Many are now familiar with this concept after gasToken was introduced in 2017 by Lorenz Breidenbach, Phil Daian and Florian Tramèr. This refund process can be used in various other instances and we think it could be useful for Chronologic.

In the current on-chain scheduling transaction approach, a lot of information is being kept on the blockchain after a scheduled transaction has been executed. This is unnecessary since this information will likely never be reused since the transaction has been executed. There could therefore be a way to delete some of the information of already executed transactions to get some gas refunded, which could be used to reduce the cost of scheduling new transactions. We will present this approach in a more in-depth article with some preliminary test results.

Note that using a gas refund is most likely only useful when most of the logic is on-chain. When most of the ChronoLogic protocol is moved off-chain, it’s unlikely that the gas-refund process will offer significant efficiency gains.

Conclusion

The topics presented here are all active areas of research within ChronoLogic, and are not exhaustive. We hope to have some more in-depth articles for the research being done at ChronoLogic over the next few months. In the mean time, if you’re interested in the work we’re doing on the Chronos Protocol and want to collaborate or share ideas, follow the progress on our public GitHub. You can also connect with the Chronologic team directly on our Gitter channel or Telegram.