After becoming more involved with the blockchain space, I ran into the Golem project and read up on the work that they were doing. For the next month or so, I started really getting into the topic of "offloading/distributing computation", and came to realize that this kind of technology has been around for at least 40+ years. At some point, I had conceived of a device that contained no internal hardware of its own (no CPU, GPU, RAM, or hard drive) except for a network card. Everything else -- the display, camera, speakers, etc. -- are those things that the user really only cares about. I figured that if you could find a way to parallelize a whole set of programs (including the web browser. See following paper: https://www.usenix.org/legacy/event/hotpar09/tech/full_papers/jones/jones.pdf), then you might be able to create a device that, again, has no internal hardware of its own but that performs just as well as fully-rigged computers and mobile devices but for substantially cheaper. Why cheaper? Because most of the time, the majority of the hardware resources that exist within our machines are sitting idle, even if that machine is running. With the device that I have described, however, you utilize hardware resources only when you need them, and you pay for their usage in proportion to how much computational resources were used (primary metrics: memory space, cpu time). In addition, seeing how this device consists mostly of a display, it allows us to get more flexible with how we want to design our products, and allows to also take greater advantage of the rapid improvements being made with display technologies. Lastly, a world computer (yes, I took the name from what's mostly used to describe Ethereum) would have increased battery life, since you're powering less hardware.
What it does
The program that I created is quite rudimentary, but serves as a stepping stone into realizing how these technologies work. Coded in python, my program uses the Message Passing Interface to parallelize the task of calculating the area underneath the curve amongst two different computers. The third computer -- the world computer -- queries the other two computers to perform this task, and provides them with basic parameters (function definition, function limits, and number of points used for approximation). When the task is completed, one of the worker nodes sends its half of the answer to the other worker node in order to sum with its own half. That worker node then sends the final result back to the world computer, which then creates and signs a payment transaction to the worker nodes for having shared their computational resources (metrics used were cpu time and memory space of the entire process).
How I built it
After having thought of which program I wanted to parallelize and how, I used an implementation of MPI (a software library) in order to allow for the transfer of data between nodes across the network. Finally, I used the python web3 api and a solidity smart contract in order to allow for transactions on the Ethereum blockchain.
Challenges I ran into
Offloading computation to a distributed network of nodes that exist in separate memory spaces presents a whole new way of thinking about software development. Seeing how most of these technologies were new to me, I was forced to ask questions that I had never asked before, like: how am I going to parallelize my program? What information is appropriate to send between nodes? How am I going to secure my network so that it leads to verifiable results and is impervious to malicious attacks (see secure enclaves)?
Accomplishments that I'm proud of
Since I am new to this space of software development, I am really just happy that my program worked.
What I learned
After having worked on the program and after having met with a few people from the Golem team, I learnt that one of the biggest question marks hanging over the feasibility of what I describe as a world computer is whether the device can perform as well as fully-rigged machines given issues of network latencies and bandwidth. Additionally, although I might be decreasing costs due to users' hardware resources never sitting idle, I am increasing costs with higher traffic/bandwidth over the network. Of course, the answer to these questions depends in large part on our use case, but I need real numbers in order to see whether this kind of product can be viable as a business. It might be the case that this technology can only be fully realized with significant improvements in overall network bandwidths and corresponding infrastructures.
Additionally, the people from the Golem team told me that, as it regards distributed computation over a network of independent, non-homogenous machines, the biggest issue that they faced is validating that those computers that are dedicating their hardware resources do not act in any malign way and produce results that are valid. This delves mostly into the topic of secure enclaves, where we try to answer questions like: how can we make sure that the internals of our program are confidential and non-modifiable? How can we check that the solution is valid without us having to run the program ourselves? Techniques used to answer these questions depends in part on the program/use case itself. One of the methods that I've seen put to use is to compute over encrypted data, and to ensure that the proper data flow is always being followed (see Enigma project).
What's next for World Computer
The next step is to try and parallelize a task that is serial in nature (example: rendering an image). Ideally, this next step will serve as a precursor to accomplishing what I see as a long-term goal: parallelizing the web browser and creating a device that, again, has no internal hardware of its own but that can browse the Internet as well as the most expensive mobile devices but for substantially lower costs. The promising news is that web browser performance is not network-bound, but is CPU-bound (link: https://www.usenix.org/legacy/event/hotpar09/tech/full_papers/jones/jones.pdf). At this point, it's really about trying to figure out what the technical limitations are of this kind of technology given where we are now, and whether it can be feasible as a business.