Apr 2, 2019
Using the Ethereum Alarm Clock To Decentralize Reputation Models
2key Network is a blockchain-based referral network intended to reward referrers through smart contracts. Referrals progress through the network thanks to people sharing them and opening them in their regular web browsers.
Therefore, 2key generates off-chain cryptographically signed links, which propagate among users without reaching the blockchain. Upon conversion, a user submits the signed link to the smart contract. The smart contract rewards the chain of referrers as represented in the signed link. The smart contract is deployed per referral campaign by the campaign initiator, depositing a referral reward, as an amount of cryptocurrency, from which the smart contract will later pay the referrers. Otherwise, if the conversion event entails the converter purchasing something and inputting funds, the referral rewards are taken from the acquisition funds per conversion.
The Influence Graph
A campaign conducted over the 2key network starts from the campaign initiator, called the contractor. The contractor starts the campaign by spreading the word to an initial group of people, called the source seeding. From the source seeding, the campaign proceeds through referrals. The graph of referrals from the source seeding is called the influence graph. Each node in the graph is called a referrer. The node which makes an actual conversion, such as purchasing a product, is called a converter. A referrer leading to conversion is to be rewarded from the campaign budget. Not only the referral leading to the conversion is rewarded but also referrals that had some impact on anyone leading to the conversion. The reason is that it is well known the accumulation of referrals at some point in time moves the needle towards actual conversion.
The Reputation Model
2key Network is building a reputation model of influencers, contractors, and converters. The reputation model is initialized with information from social networks. Along time, as campaigns are executed, information on the performance of referrals, on conversions, and the worthiness of campaigns, will be incorporated into the reputation model.
The reputation model will measure the degree of influence of individuals in general and with respect to particular other individuals. Moreover, the degree of influence is measured relative to a taxonomy of categories such as the IBM Watson taxonomy of categories.
The reward to be assigned to an influencer in a campaign is based on the influence graph of the campaign and the reputation model.
The Lack of an Active Timer in Ethereum
Blockchains such as Ethereum are immutable and have no internal timer. There are timestamps of blocks, but there is no active timer in the blockchain that would schedule events. No equivalent of the JavaScript setTimeout and setInterval exists in Ethereum.
If you want something to expire at a certain time, you need some server to look after it. The server will send a blockchain transaction to your smart contract, and the method will check if the current blockchain time is beyond the preset timeout. If indeed we passed the time, an action will be executed. Usually, the code looks like this:
require(block.timestamp > start + 30 days);This is fine if you have a server that will babysit for you, or you would not get anything. Certainly, this is not a decentralized mode of operation. It is not a fire and forget operation.
Why Reputation Models Need Timers?
Reputation is not a stationary thing, it comes and goes according to what is happening in our campaigns. In fact, any social reputation model which is realistic has to allow for both increasing and decreasing reputation moves along time. After all, we are all too familiar with the aging lead phenomena, where your usual leads lose their appeal and are no longer effective.
So it is clear we need to periodically update our reputation models. And with standard Ethereum methods, this periodic update is just not possible in a decentralized mode of operation.
Sure, you can recompute your reputation on every update to the information, but it is not effective in terms of gas and transaction time. On top of that, the basic concept of reputation is really a derivative of time. How many referrals did you do over a time unit is a more accurate measure than the total referrals you have done. And computing the derivative with a moving update window is hard to do accurately.
Campaign KPIs Need Timers Too
As 2key Network campaigns pay rewards continuously, we naturally want to adjust the rewards to the progress of the campaign. This implies we need a time signal to be sent to the campaign contract.
Ethereum Alarm Clock
The Ethereum Alarm Clock is a protocol for scheduling future execution of a transaction on the Ethereum blockchain. ChronoLogic is a startup incorporating the Ethereum Alarm Clock into a fully operational scheduling system, including periodic executions. A user stakes a payment in order to schedule a transaction. Such scheduling can be done via the well known MyCrypto.
The Decentralized Network
Ethereum Alarm Clock operates using special TimeNodes that are rewarded for future scheduling of Ethereum transactions. The network of TimeNodes is a decentralized architecture of off-chain nodes. TimeNodes are incentivized with user pre-set bounties. Users never need to know about the TimeNode protocol or the smart contracts, they just pay a small fee for the scheduling.
Using the Ethereum Alarm Clock for 2key Reputation Model
What we really need is a periodic time signal, to be sent to our smart contracts so that they compute whatever time derivatives and KPI they need for the period. This will make the whole operation fully decentralized and transparent. No longer will we have a central server calling the time.
But we need more than just periodic, we want one-time timers, that call the shots and terminate a campaign in time.
For both these time signals, the Ethereum Alarm Clock would serve us well. While scheduling through MyCrypto is good for a user, we would like an API based operation of the alarm clock in order to generate timeouts from our campaign generation web application.
Conclusion
We observed we need to make our timers, both timeout type, and interval type, decentralized to make 2key Network decentralized in the temporal sense. We believe the Ethereum Alarm Clock is a good approach for us. We need to explore how to integrate it via an API.
