Decentralization: Powered by AWS

One of the biggest elephants in the room with decentralized technologies is the idea of nodes in new decentralized networks are running in the cloud. The reason why I specifically say ‘new’ decentralized networks is that it wouldn’t make economic sense to run nodes for a PoW blockchain in the cloud. However, with these new decentralized networks using things like DPoS where certain nodes are appointed and guaranteed payouts on a regular basis, it becomes much more realistic to turn a profit running a node in the cloud.

But keeping these nodes in the cloud comes at a great cost. Without the proper hardware to secure crypto keys and with multiple other programs running in the same environment, nodes are vulnerable to a number of attacks which could compromise its operation as well as any private information stored on it. And that’s not all...

‍

‍

To my surprise, the majority of the comments were from individuals speaking out against such practices and asserting that many of them were running their own nodes and would never run in a cloud environment. Which is a relief for me to hear, but I am quite sure that this practice is still rampant in the community and that these individuals would never admit to it publicly. So, I’m going to expand on some of the liabilities which they may not have considered when setting up their node in the cloud.

Liabilities

Let me first preface that this sort of information is mainly for those individuals who are accruing a lot of value on their nodes - mainly applicable to protocols whereby the majority of network rewards are accrued by a small set of individuals (ex: EOS, Tezos, Cosmos,...). If you are a small node and running in the cloud, you will likely be less exposed to the risk of someone attempting to hack you or steal your funds.

Multi-tenancy

When you spin up an AWS instance, you’re running on the same server as many, many, others. And while the engineers at Amazon have certainly done a lot over the years to mitigate the ability of programs on one part of the server from being able to deduct information from another part of the server, it’s not foolproof.

Just last year, two major security vulnerabilities, Spectre and Meltdown, were revealed as exploits allowing for processes running within the same machine to learn private information relating to other processes. Spectre did this through the utilization of special processes which left a machine vulnerable to having sensitive data read while Meltdown allowed rogue processes to read all memory, even when not authorized to do so. Oh, and a Meltdown attack is undetectable.

It should be noted that to carry out these attacks in the cloud, the attacker must run a virtual machine on the same physical server as the victim’s virtual machine (which is non-trivial to the tune of requiring the launch of tens of virtual machines) and then exploits a shared physical component (e.g. the processor cache) to steal information (e.g. a private key) from the victim. In this case, the attacker would then be able to retrieve the value of the private key by utilizing vulnerabilities like Spectre and Meltdown in tandem with observing the activity of the processor cache to extract some private information.

While there are efforts to mitigate attacks like these (Intel and others were able to redesign and turn around new chips which address these issues in less than a year), they are incredibly difficult to protect against. And it’s highly likely that there are many more of these attacks which have yet to be revealed to the general public. So, if you are paranoid about security or want to air on the side of caution, you’re better off running a node in isolation by purchasing an entire server in the cloud (which is prohibitively expensive) or paying a fraction of the cost to purchase one and run it in a local datacenter.

They Own You

At this point, the legal contracts that individuals and businesses agree to when using cloud providers like AWS have become so incredibly convoluted. AWS even lampoons this fact by a clause covering a zombie apocalypse.

‍

‍

The fact is that these sorts of complex agreements prevent anyone from fully understanding what they are agreeing to. What does seem evident is that these businesses can roughly do whatever they please when you use their technology.

Spying

Remember that company Ring? You know, the one that got rejected on Shark Tank to then go on and be purchased by Amazon for over $1 billion? If you don’t, it’s a smart doorbell that comes equipped with a camera and microphone - allowing you to see who is at your door and communicate with them. Which was great, until a story broke in early 2019 about how Amazon was allowing its employees to see the camera feeds - completely undermining their users’ privacy. Here’s an excerpt from The Intercept:

Despite its mission to keep people and their property secure, the company’s treatment of customer video feeds has been anything but, people familiar with the company’s practices told The Intercept. Beginning in 2016, according to one source, Ring provided its Ukraine-based research and development team virtually unfettered access to a folder on Amazon’s S3 cloud storage service that contained every video created by every Ring camera around the world. This would amount to an enormous list of highly sensitive files that could be easily browsed and viewed. Downloading and sharing these customer video files would have required little more than a click.

Single Points of Failure

And if the research and development teams have this kind of access and power to private S3 data, imagine the kind of power that members of the actual S3 team must have! Well, we got a taste of that in 2017 -  remember that time when a single engineer brought the Internet to its knees because of a typo?

An authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended.

When a typo can take out thousands and thousands of businesses like (and this is by no means an exhaustive list) Slack, Github, Adobe, Pinterest, Heroku, Airbnb, Expedia, etc... it’s a problem. And people wonder why healthcare and other businesses are so slow to adopt new technology.

Malicious Employees

Lastly, it’s important to recognize that AWS servers do undergo physical maintenance and upkeep - I mean, they certainly upgraded the CPUs in their servers to account for Spectre and meltdown, right? And with a large percentage of businesses completely fail to take adequate measures when discarding hardware, it wouldn’t surprise me if things often slid under the radar with AWS (especially given the size and speed of its operation).

And there’s a reason why we haven’t heard of any such instances - they would be a monolithic blow to the entire cloud computing industry. And while there are a number of procedures put in place to mitigate the chances of this happening, to consider the idea of it having never occurred before is simply unfathomable.

Improvements

There is no silver bullet. All of these issues stem from a centralization of resources - which compromise security in the name of efficiency. The simple fact is that if you have a lot of value which could be lost due to downtime or due to the extraction of a private key, you should be running your resources on your own dedicated hardware located a datacenter with a failover instances in place across other datacenters.

In terms of mitigating the single points of failure faced by applications running in the cloud - while a decentralized AWS does not yet exist, we believe that SKALE Chains can fill that gap in the near future! If you’d like to learn more about these, check them out in our recent article on “The Execution Layer”.

SKALE’s mission is to make it quick and easy to set up a cost-effective, high-performance SKALE Chains that run full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization. Follow us here on Telegram, Twitter, Discord, and sign up for updates via this form on the SKALE website.