iExec Dev Letter #22: Summer Workerdrops and Infrastructure Testing
What is a Workerdrop?
iExec is a decentralized marketplace for cloud computing resources. When public worker pools are be implemented, anyone will be able to earn RLC tokens from sharing computing resources. In order to prepare for this release, iExec is organizing a series of Summer Workerdrops.
The goal of these workerdrops is to guide workers (or CPU power providers) through the process of providing computing power and to test, validate and scale the iExec network on Ethereum’s Mainnet.
What was very successful
- Our workerdrop strategy of taking things gradually was a good idea that allowed us to proceed carefully and solve issue before the next workerdrop wave. In respect to the agile delivery process, iExec is deploying step by step. During workerdrops 1 and 2, we have learnt a lot of things that we couldn’t have learnt any other way.
- We were pleased by the overall number of participants: over 310 different machines from multiple countries participated (China couldn’t make it to the WD1 but was able to engage in WD2).
- Around 170 work orders were made available, resulting in over 2,400 RLC being distributed over 24 hours.
- Most of the issues that arose had to do with the synchronisation of our Ethereum node or parameter calibration. This gives us confidence in our capacity to improve the performance of our middleware and to significantly reduce the percentage of work orders that don’t go through.
What was less successful
- Our testing infrastructure reached the point where it was not sufficient enough to carry out our repertoire of tests, which is why workerdrops well timed, leading off tests on Mainnet. Typically, one of the cases we were eager to test is the synchronisation/desynchronisation of Ethereum nodes. During WD2, there were many transactions lost due to the desynchronisation of our Ethereum node or to transaction delays on the Ethereum blockchain. These parameters — synchronisation and delays- are difficult to test because they are totally different from one blockchain to another (between testnets and between testnet and mainnet).
- The afternoon, towards the end of the Workerdrop, highlighted the significance of worker count on the scheduler’s performance. We observed problems arise after the pool exceeded 250 workers. iExec’s schedulers are totally configurable and we can increase their worker handling capacity. We did do that, but without success. We later understood that such a move didn’t bear results because increasing the scheduler capacity only makes sense when the OS of the machine running the scheduler can follow. We will now explore the topic of scheduler parameters versus OS, in order to come up with a solution to this.
- The desynchronisation of Ethereum nodes is an issue we have been coming across more often. Nodes are extremely sensitive. We will always need the latest version and to continuously monitor to ensure that desynchronisation does not occur. We will therefore implement a continuous integration workflow for our Ethereum nodes to overcome this issue.
2,000 RLC airdrop for workerdrop participants
We would like to thank all of you for helping us test and scale the iExec infrastructure. To do so, we have decided to airdrop the remaining 2,000 RLC from WD2 to all our workerdrop participants. The airdrop will take place this week.
There was 311 unique wallets, each representing different workers, and the 2,000 RLC will be equally distributed among them. This will also serve as a reimbursement of gas fees paid when subscribing to our public worker pool.
About Workerdrop 3
Armed with precious feedback and after collecting valuable data, the iExec team are now able to improve its product and prepare for the next workerdrop. Overall, we are happy with our strategy for the workerdrop, taking things gradually, allowing for us to introduce concepts step by step. All issues raised during WD1 & 2 will be addressed before WD3. The final workerdrop of the series will take place in the beginning of September, before the official release of our public worker pools.
Workerdrop FAQ: Your most asked questions
- Why do I see ‘Server gave no work to compute’?
This confirms your worker is correctly connected to the scheduler, but no work has yet been delivered to you.
- Why do I read ‘Server timeout error’?
This was a result of the issue previously mentioned relating to scheduler and worker count. These timeout errors had no effect on worker reputation.
- How is my worker reputation calculated and how can I check it?
For each valid contribution, the worker score increases by an increment of 1. For an invalid worker contribution (a purposely falsified result), the score is reduced by 50 or set to 0 if score is <50.
Score adjustment for a worker contribution (+1 or -50) is triggered only if the work order status is “Completed”. In case of incomplete work, the reputation score is not changed.
You can view your reputation score under ‘8. m_scores’ here:
https://etherscan.io/address/0x0d5ef019ca4c5cc413ee892ced89d7107c5f424d#readContract
- How are rewards distributed according to reputation?
Tokens rewards are distributed proportionally according to reputation score. This means that, for example, if there are 3 workers and the price of a task is 45 RLC, there will be cases where the reward is not equally distributed (i.e: 15/15/15).
A logarithm function is used to weigh Worker’s rewards according to their reputation score. Weight increases with the logarithm of the score, the higher the reputation, more difficult to gain weight. So anyone with a lower reputation can try and catch up. The reward log function can be seen in the smart contract here:
https://github.com/iExecBlockchainComputing/PoCo/blob/master/contracts/WorkerPool.sol#L416
- I executed tasks and earned tokens. Where are my RLC?
Each actor (workers, schedulers and buyers) have an ethereum address and their account state is stored on the ‘iExecHub’ smart contract. Payments and rewards, according to users actions, will update the balance in those accounts.
There are two methods to check your balance:
- Check balance within iExec via Etherscan :
https://etherscan.io/address/0x0d5ef019ca4c5cc413ee892ced89d7107c5f424d#readContract
Paste the wallet address (eg. 0x……) under ‘7. checkBalance’
2. Check balance within the Worker VM
Open the VM, go to Desktop > iExec
Right click > Open in terminal
Then input the following:
iexec account show — chain mainnet
You will notice 2 differents lines for the account balance. ‘Stake’ and ‘Locked’.
Stake balance can be withdrawn from marketplace and received as ERC20 RLC as you know it. This ‘Stake’ balance can be used either to stake or to pay for executions and is the balance increased when you make a deposit.
When workers place their stake to execute a task, ‘Stake’ balance decreases and ‘Locked’ balance increases accordingly.
These funds are locked until the work order is complete. When the work order is completed (and PoCo consensus is achieved), ‘Locked ’balance of the user is seized and the stake balance of contributors (workers) is increased, according to smart contract rewards distributions rules.
https://github.com/iExecBlockchainComputing/PoCo/blob/master/contracts/WorkerPool.sol#L416)
Why is 0.2 ETH required in my account to start a worker?
0.2 ETH is required in order for the Web3 client controls to not fail. This is due to a minimum amount needed to make gas fee estimates. Note that these funds were not and will not be used or taken as fees. It only needs to be held in a wallet in order to pass the control for this estimate before joining a workerpool.
How can I participate in Workerdrop 3?
Stay tuned, we will publish a tutorial very soon!
Follow Us
Website • Blog • Slack • Telegram • Reddit • Twitter • Facebook • LinkedIn• Youtube • Github • Kakao • Instagram • Steemit • Katacoda • Docs
