# Volunteer Down: How COVID-19 Created the Largest Idling Supercomputer on Earth
## 2 Review on Volunteer Computing
### Open Problems in Volunteer Computing  
The COVID-19 case (Folding@home), recent reviews [5; 64], and the critical discussion of the current state of VC turned up the following (not necessarily complete) shortcomings of current VC platforms.  
* **Heterogeneity [64]:** Different VC devices have different power, memory and processing capabilities, as well as different communication interfaces, making it hard to classify, design, and assign device optimized work units.
* **Result verification [64]:** Volunteers perform their required computation and send data results back to the master. The master then verifies data results and discards inadequate or erroneous results. In this way, massive computation (several hours or even days are not unlikely) is wasted as result verification is done at the end of processing. Intermediate result verification mechanisms or smaller chunks could minimize this waste.
* **Project exclusiveness:** Currently, for most VC platforms, projects are organizations (usually academic research groups) that need computational power. Each project runs on project-dedicated master servers. On the one hand, this enables trust, but hinders sharing of devices across different projects. This exclusiveness can result in situations that the Folding@home project faced in March and April 2020 due to the massive COVID-19 scale-out. In this situation, all of the unused CPU  
Figure 6: Common master worker model used by many VC projects.  
cycles (see Figure 2) could have been provided with ease to other VC projects dedicated to further respectable motives. Thus, in March and April 2020, plenty of possible computations for cancer, climate change, and further research projects could have been processed without disadvantage COVID-19 research. The COVID-19 pipelines were almost empty in that phase because there were more devices than tasks. There was nothing to process.  
* Good security is multi-layered. For instance, the BOINC system maintains reasonable security practices at several levels ([[https://boinc.berkeley.edu/trac/wiki/SecurityIssues](https://boinc.berkeley.edu/trac/wiki/SecurityIssues)]([https://boinc.berkeley.edu/trac/wiki/SecurityIssues](https://boinc.berkeley.edu/trac/wiki/SecurityIssues))). Let us investigate them from a best-practice point of view. All VC systems require that donators have to run executables provided by a third party--the company or institution running the project. Thus, these third party executables are highly suspicious from a security point of view. The following counter-measures are combined to mitigate corresponding risks.
* Overall **project security*
* measures very often include security audits of project code, enforcing SSL communication with project infrastructure, and virus scanning of project files.
* **Code signing*
* can be used to provide valid official builds and to detect code injection attacks on the client-side.
* **Result verification*
* is used on the master side to verify that malicious clients have not manipulated results.
* can limit the risk for donators from malicious or insecure project code. However, sandboxing must be very client operation system-specific. However, most VC projects are operated by domain-matter experts and not by IT-security experts. It would be a benefit for the VC projects (reduced efforts) and the donators (improved security) if both sides could rely on proven security infrastructures.
* **Scalability and elasticity [5]:** VC systems can have millions of volunteer nodes connected to them. Moreover, this amount of nodes can grow exponentially and quickly as COVID-19 taught us. Thus, more scalable and elastic approaches are required to handle this significant number of volunteer nodes coupled with their intermittent availability. Using more decentralized architectures has already been proposed and implemented [13]. However, the Folding@home project still could not scale-out fast enough to handle all of the COVID-19 volunteers (see Figure 2).