Home > Unitalks > Articles

【UNITALK】Logan Saether: A “self-trade” smart contract, Ethereum Alarm Clock

Introduction:

 DApps have become a global phenomenon, Innovative projects in various industries have been rapidly attracting public interest. In 2017, the Alarm clock project has started to develop as a solution to the inconvenient investment delays during ICO process.  It is a temporal innovation which alerts token buyers to keep an eye on a timetable of specific future ICO developments. Basically, it is a simple smart contract to optimize the process for investors. It enables to set in advance transaction time and volume letting a smart contract to trade authomatically. Undoubtedly, it is an upgraded 2.0 version of the smart contract. Today, we have a privilege to interview Logan Saether, the smart contract engineer of ChronoLogic, letting us investigate this future application together: Ethereum Alarm Clock.

UNITALK AMA:

1. How did you learn about Blockchain technology? Why did you choose ChronoLogic, in the first place?  From personal perspective, what does blockchain mean to you?

I discovered blockchain technology during my last year of college. I was majoring in something completely different from computer science (English Literature), but I did programming as a hobby and was active in the computer science club at my university. So computers were always something I was doing in the background of my university studies and I was interested in security and pen-testing. Anyway – about how I discovered blockchain – I’m not completely sure how but I ended up hearing about Ethereum and looking into it and just getting totally and utterly fascinated by this concept of a world computer that was trustless and decentralized. This was around mid-2016. I was definitely more interested in the programming side than trading or the economic side at first. I wanted to build my own tokens so I started learning solidity right away.

ChronoLogic came a bit later after I had already gone through my knowledge-accumulation phase. I was doing some work with a startup in New York City that wasn’t quite working out the way I wanted, so I was looking for new opportunities. I interviewed with a few of the big names but ChronoLogic caught my eye because of their job-post about rebooting the Ethereum Alarm Clock service. Every developer in the Ethereum space knew about the project because it’s a use case people always ask for and need: scheduling transactions. I reached out and worked with a team.

From my perspective, a blockchain is a data structure that has the function of creating a history of states through the consensus of an open network of peer to peer nodes.

2. Why did ChronoLogic choose to develop Alarm Clock in the first place in 2017? Why Ethereum?

So it’s probably fair for me to mention that I came in after the decision about ChronoLogic working on the Ethereum Alarm Clock project. As far as I know, it was simply because ChronoLogic realized that it was a use case that they not only had with their Debt Smart Contract Dapp, but a need that spanned the whole ecosystem, so it was decided to fund its development.

Why Ethereum is an easy answer. It’s because Ethereum is the only blockchain platform with developer tools and a network that is mature enough to launch a decentralized application with a relatively low amount of hassle of running architecture. Specifically for the Ethereum Alarm Clock project, it’s because scheduling transactions is a gap at the protocol level of Ethereum that needed to be filled at the application layer.

3. Will Alarm Clock use IPFS technology to solve database problem?

The Ethereum Alarm Clock will not use IPFS technology, as it stores all the data it needs directly on the Ethereum blockchain in smart contracts. However, one thing about the EVM is that it costs high amounts of gas to store data which translates directly to costs to the person making scheduled transactions. It is one of the problems we’re solving in what we’re calling the next generation of the Ethereum Alarm Clock, the Chronos protocol. Chronos protocol uses a model which stores only the minimum amount of data needed to verify correctness on a chain, the hash of the transaction parameters. For this, we’ve discussed using IPFS to act as the storage layer for the actual parameters and we constructed the hash to be compatible with IPFS today. However, in recent iterations I’m less convinced we will actually need to use IPFS since we can send the parameters as an event, so that it’s stored in the logs, without actually making storage calls. I can’t say for sure if the final version of Chronos will be using IPFS or not.

4. When will Alarm Clock go to the mainnet? What’re your expectations for the project? Is there any other project that Chronologic is working on now?

The Ethereum Alarm Clock is scheduled to go to mainnet soon. We’re basically just waiting on getting back the audit results from ZKLabs and then making any of the recommended fixes and then we’re good to go. My expectations are that it will allow developers to begin to build decentralized applications with the confidence that the scheduling aspect of their idea is covered by the mainnet Alarm Clock contracts. Like I mentioned in my previous answer, we’re currently working on the Chronos protocol which is similar to the Alarm Clock but includes some new features and breaking changes. I like to refer to it as a “smart contract automation platform” more than a “scheduling protocol” like I refer to the Alarm Clock.

5. Will Alarm Clock have any plans for tokens? Any token mechanism? From your perspective, do you think it’s necessary to have a token mechanism for an alarm clock? Why? What type of blockchain project needs tokens?

The Ethereum Alarm Clock will not have any token mechanism and uses; only ETH, Ethereum’s native currency, as a means to transact. However, for Chronos, we’re experimenting with using tokens to solve an interesting problem we could not solve in the Alarm Clock: transaction collisions. Transaction collisions happen in the Alarm Clock flow when two or more of the TimeNodes (the off-chain executing agents that make the Alarm Clock tick) attempt to both claims or execute a transaction at the same time. Only one transaction will actually go through, while the rest will be reverted along with small costs to the TimeNodes which sent the transactions. We’re experimenting in Chronos how to use ChronoLogic’s Day token as a staking token for TimeNodes to sort them into a queue and allow them to execute transactions, so we avoid the free-for-all situation we have now.

Some people view utility tokens as a bad thing but I disagree. I think token mechanism allows for many interesting experiments in using incentives to design behavior in a game-theoretic way. I think creating an interesting use case for a token is enough reason for a blockchain project to have one. I know that’s a vague answer, but it’s really too early to tell which projects will benefit from having tokens or not.

6. Does Alarm Clock have any business model now? What kind of model do you think is best for Alarm Clock? Except for MyCrypto, will Alarm Clock partner/work with other projects? From your point of view, what industry or type of project do you want to co-operate with?

The Ethereum Alarm Clock’s business model currently is to be an open source project without a business model. From ChronoLogic’s point of view, the business model is to integrate the Alarm Clock in as many places as possible to encourage wider adoption. From the beginning, Piper Merriam (the founder of the Alarm Clock project) included the idea of a “fee” which could be a small percentage of the cost to schedule and would go to the project creators which integrated the Alarm Clock. The fee is adjustable for each front-end that integrates the project, and it’s possible to configure the Alarm Clock to turn off that feature completely. I think this is the best way to incentive integrations with an open source project like the Alarm Clock.

ChronoLogic is constantly looking for new partners to work with and integrate scheduling. If you are reading this and your project could benefit from scheduling, please reach out to us. Some of the use cases we are excited about include decentralized exchanges, where we can basically construct complex financial derivatives and trading strategies by scheduling future transactions with the Alarm Clock.

7. If the provided award only attracts fewer people to become timenode, what would you/project do? Any solutions to that problem?

We recently did some investigation, and found that the minimum amount of bounty volume that needs to transact through the network to incentive one TimeNode is $7.00. This number is how much it costs to run our Heroku instance which operates a Kovan TimeNode. What this means is that if you want to schedule a transaction, and there are no TimeNodes operating on the network because, say, you’re the first one ever to schedule, the amount you should offer as the bounty is $7.00. Someone will see this bounty and realize it’s enough to cover the operation costs and launch a TimeNode instance with the open source code. This is possible because it’s a decentralized application and will never stop until the end of time (or the end of Ethereum mainnet).

However, in practice, we’re anticipating that the bounty will never actually need to be this high since we think that there will be sufficient volume in the network to allow for smaller bounties from scheduling parties.

8. What’s your roadmap/expectation for Alarm Clock in 3 years? What kind of project will it be?

Once we launch the 1.0.0 stable release of the Alarm Clock to the mainnet, we’re hoping this will be in operation for a while. We’ve spent a lot of time to ensure that it is secure and will continue to run. Almost all of our focus over the next 3 years will likely be on the Chronos protocol, which adds the ability to schedule conditional transactions alongside temporal-based ones. We think this will unlock huge potential for general-purpose smart contract automation. We are also making it so that the new versions of the TimeNodes are backward compatible with the transactions that will be scheduled on the Alarm Clock contracts.

9. What is an unresolved technological problem that Alarm Clock faces now? Do you have any solutions now?

We’re facing two problems that exist on Ethereum at a protocol level: the transaction collisions I mentioned before, and the dynamic gas price changes. For the transaction collisions I mentioned that we were working on a token staking mechanism with TimeNodes to order executions between them, but this is a narrow solution for our own use case and we still consider it less than ideal. As far as the dynamic gas price ranges go, we can’t really offer a solution. The problem is that it’s impossible to predict the gas price at a future time when a transaction should be executed, so the schedule is advised to set the maximum gas price they’re willing to pay in advance to negate any uncertainties in the future. Of course, this may lead to the scheduling party paying more in gas costs than they needed to…

10. You have such a diverse team; could you describe how does your team works every day? How would you evaluate your team in one sentence?

Sure, the team at ChronoLogic consists of the best developers and communications people that I’ve ever had the opportunity to work with. The credit for building the team completely goes to the leaders of ChronoLogic, the ones who hired me and hired everyone else. They have an eye for a talent and know how to find the right people to fill out a team.

Our team is distributed but almost everyone resides in European timezones. So we have normal working hours when everyone is online and we’re in nearly constant communication on Slack. We also have daily stand-ups Monday-Friday in which everyone syncs and gives updates.

To sum up the team in one sentence I would say: We’re all independent and autonomous but united by a singular goal of building the Alarm Clock ecosystem and realizing the vision of providing a base-layer function of scheduling transactions on Ethereum.

11. Recently years you went to multi-conference to promote Alarm Clock, do you have any specific markets to focus on next?

Like I mentioned before, we’re excited by the possibilities the Alarm Clock offers for decentralized exchanges. Besides this, we’re actively trying to spread the message to developers that the Alarm Clock will be something to rely on to build their application. For me, the purpose of delivering all of these talks at conferences and meetups is to encourage developers to take advantage of the work we’ve done in rebooting the Alarm Clock and building a set of tools. I think turning more people on to development on Ethereum in general, will benefit the entire world by creating a future of decentralized applications. 🙂

12. How will the token mechanism help in the success of a project, from your perspective?

Token mechanisms can be a great way to create networks and economies based around a community of similar interests. For example, if we use a token as staking token for the TimeNodes, it will be predominantly in demand from people who want to try making a profit by maintaining infrastructure for executing alarm clock / chronos transactions. I’m interested in tokens with potential emergent value since these can be used as crypto economic incentives.

13. You said that more people on the top will benefit from your work, but not all of them are kind and transparent like you guys are. What if they copy your work/code directly for their self-interests? Although it’s an open source tech, do you or your team have any plan to avoid it?

Someone forking the alarm clock isn’t too much of a concern since we don’t have an economic benefit in it. It’s kind of just a matchmaking protocol between the TimeNodes and people who schedule them. The “fee” part is configurable by developers who create front ends that use the standard contacts on the back end, so there’s no real incentive to deploy the contacts again.

Forking is a bigger concern in Chronos, where we are using a specific token as a staking token. What’s interesting about this though is that the staking mechanism solves one of the core issues of transaction collisions. So someone might come along and fork chronos and take that part out and use ether as the staking currency, if they find that desirable, but because there’s a crypto economic mechanism behind it, there will still need to be some sort of staking token.

Ending:

We would like to thank Logan Saether for supporting Unitimes. If you have any related questions to Logan Saether, please leave your questions below, or send an email to contact@unitimes.media. We will do our best to help link you up with Logan Saether.

Interviewer: Shuyue Yang

Edit: Anna Niemira

【 Declaration: Please contact us at contact@unitimes.media if you want to repost this article and indicate the source. Opinions expressed by Contributors belong to themselves.】