From Cloud to Web3

Intrinsec · Monday, May 2nd, 2022

By Jonathan Baier

Disclaimer: None of this is financial advice, always remember to do your own research.

It is both a fascinating and daunting time to be in technology. The rapid pace of change continues to dwarf the scale and scope of what was possible in the past. If you are in technology today you have to be committed to learning and growing. But, even if you love learning it is still a gargantuan task to keep up today.

Many folks (and organizations) are still adjusting and learning the way of cloud computing. (Shameless plug: I’ll be teaching a Cloud Security Alliance CCSK course next month course next month for folks in APAC time zones). Those further along are also trying to wrangle containers and microservices. But in the past few months we’ve seen everyone from New York Times to the IMF talk about the next wave of technology brewing in blockchain and Web3.

For simplicity sake we will focus on the decentralized technology of Web3, but AI, IoT, and the Metaverse are part of the new architecture being built with Web3. Those areas deserve their own series of articles, but we will focus on the aspect of distributed trust in this set.

Read, Write, Own

You may have already heard about blockchain through discussions on Bitcoin, a virtual cryptocurrency, but what is evolving in the Web3 world takes the same distributed ledger and cryptographic technology one step further. Through Ethereum and what is called “Layer 2” solutions, Smart Contracts and essentially code can be run on-top of these chains. This creates a world where we can execute logic, code, and have those computations verified with the same assurances and transparency that Blockchain first made possible with Bitcoin.

This is an entirely new type of infrastructure that will give way to a new Web where creators and consumer own, and in theory decide, how their data and creations are used. You may have heard of the NFT craze as of late. This is just one application of the layer 2 world. Essentially giving creators a way of capturing more of the royalties for the sale, and in some cases resale, of their art.

The possibilities for this new type of compute are quite vast and still being built. Many challenges still exist such as speed and scalability. The high level of security provided by the “Layer 1” blockchain also means it is slow and can handle only a small number of transactions. This is where you will start to hear of “off-chain” solutions that can process more transactions at a faster pace and simply do the verification on a set (or block) of transactions before rolling it up to the more secure Layer 1 chain.

One note, this article is not meant to be an in-depth tutorial on the Web3 technologies, but I will provide some links (here, here, and here) on articles that may be helpful as background. Rather I wanted to explore how guidance and technology practices could evolve as we start this new chapter.

If you are familiar with Cloud, Cloud Security Alliance (CSA), or are at least studying those areas, I thought it would be interesting to take a glimpse into how the domains of CSA guidance (and cloud security broadly speaking) relate to some of the changes that Web3 will bring in the coming years. After all they say that the human brain learns by connecting to things we already know.

Cloud Computing Concepts and Architecture (i.e. Domain 1)

I’ll start the series in the first domain of the CSA guidance. It is a broad domain, but for simplicity sake I’ll mostly look at the deployment model which CSA defines as “how technologies are deployed and consumed”.

The guidance is rooted in the Web 2.0 world and as such still centralized, but it is worth considering the evolution. Before cloud applications and services were housed in data centers owned by one organization. Of course you had some outsourcing and co-location but IT was quite centralized from an ownership perspective. This means governance and trust was centralized as well. In the private cloud deployment model this need not change that much, though new partners could certainly be introduced.

The public deployment model itself is only a small departure from this centralization. After all one could argue that the big public cloud providers simply take the place of data center partners of the past. The scope of involvement, and therefore delegated trust, expands as the cloud services may provide and/or manage more pieces of our core infrastructure.

Most large enterprises in cloud today are not purely on public cloud and instead use what’s called a Hybrid deployment. Hybrid can represent many different mixes of private, public, and community, but ultimately expands the trust circle, i.e. parties involved, by a small number.

Community deployment expands our circle the furthest and denotes a model that CSA describes as:

“shared by several organizations and supports a specific community that has shared concerns (e.g. mission, security requirements, policy, or compliance considerations). It may be managed by the organizations or by a third party and may be located on-premises or off-premises.”

In this context you may have a larger number of organizations involved. We are also extending trust to varying degrees. While it may be a small community with a few organizations and partners, it can also grow quite large and encompass a much larger set of organizations and vendors.

Distributed Decentralized Applications

Ok so trust has expanded and the number of parties involved had increased a tad, but this feels more incremental and less like an “evolution” towards decentralization. While I think it’s a meaningful move, the more drastic change has been what is possible for the application and infrastructure architecture.

First, we are able to give more freedom and trust to individual business units. Each unit can use the tools and services it needs to compete best in their market. But even more impactful is the capabilities with regards to resiliency. Teams can now deploy applications across multiple zones (i.e. data centers) and also entire regions (coasts, countries, even continents). Of course there are challenges to deploying this way using the same designs that ran in the data center. Thus much refactoring has commenced in the years since cloud adoption started.

“Design for failure” is the new paradigm. As we look at a more distributed architecture, with different business units enjoying the ability to tailor their design for their market, an obvious draw to technologies such as containers and micro-services emerges. I’m tempted to expand further into those subjects but I will refrain as we are trying to get to the Web3 world.

Instead I want to summarize the direction things have taken in three areas that are key to the next phase:

Broader circles of trust
Finer Grained Independence Within the Organization (i.e. Business Units or Development Teams)
Departure (albeit small) from centralization and central control.

To be clear the new distributed world has its share of challenges. Many organizations are not running applications across regions and large geographic spans, but cases exist. It’s still difficult and expensive and, spoiler alert, it’s still challenging in Web3. Web3 does not magically make these concerns go away, but there are some very interesting starts underway.

So, when are we going to talk about Web3?

Ok with that in mind how might we look at deployments in the Web3 era. Whether you are looking at a Layer 2 computation on something like Ethereum, or you have compute occurring on a “sidechain” and eventually rolling up, you now have a much more decentralized system. Computations will run distributed across potentially thousands of systems that are owned and operated by a larger number and variety of distinct organizations and individuals. In this context the words “Hybrid” or “Community” take on a new meaning that is quite different from what we discussed above.

Trust at Scale

Yet the core principle of trust boundaries remains front and center. Luckily Blockchain and the underlying technologies of Web3 provide some really good tools for ensuring trust at scale. The cryptographic hashes of all previous blocks combined with the replication to thousands (more or less depending on the chain) of nodes help us verify the integrity of the transactions stored therein. In addition each chain has some consensus mechanism that allows the chain to reconcile any discrepancies it might see across nodes.

This is not to say security and integrity are guaranteed. As always, the theory is great, but it comes down to the implementation. Many of the underlying protocols are open-source which does allow broader community inspection. This improves our governance capability by adding some significant transparency. In the previous model we may have had a high level of trust in cloud vendors and partners, but we verified with compliance documentation, such as the Cloud Control Matrix. Web3 may still have a need for this documentation, but we are also being given a deeper view into the implementation and day-to-day inner workings.

There is still a lot of work being done here in Web3 and this will continue to evolve. That said we can start to asses security and integrity by looking at the trust models, strength of the cryptography and consensus algorithms used in each project. It is not so hard to imagine a set of guidance like that in CSA Guidance Domain 11 for Data Security and Encryption though expanded beyond data security alone.

Cryptography

While PKI and Cryptography more generally have been a critical topic for security experts for quite some time now there are important differences here. First being the usage level. In the past Cryptography was relegated to the realm of sensitive data such as password and the proverbial “Crown Jewels”. In the Web3 world we still have plenty of sensitive data and financial value protected by cryptography, but it is also a pillar enabling trust at scale. Every “on-chain” transaction, and related data, will use some cryptographic processing.

It’s worth noting while cryptography is used to ensure validity of transactions it is not itself encrypting the transaction. The contents of the transaction are still available for all to see in many cases today. Indeed crypto projects often incent community members to participate in their projects with related crypto currency rewards. The downside is that those receiving the rewards have their wallet addresses, and by extension financial history, exposed even if an individual name is not known. Simply leaking unnecessary information about parties involved in transactions increases the surface area of our threat model.

The good news is that there is on-going work in what is called “Zero-Knowledge Proof”. Such ZK tech promises to allow verification of an individual having certain information without disclosing that particular information itself.

Where’s your wallet?

However, this data privacy brings us to another area of focus, namely the wallet. Transactions in Web3 rely on wallets to establish identity and even store data (private keys, crypto currency, NFTs, etc.) In some cases this may be a wallet that the user owns, but it could also be managed by a third party. To complicate things more, users wallets will connect to multiple chains that may have very different requirements and cryptographic designs. Finally a concern for larger organizations is that the wallets represents the organization’s activity and identity. An organization may also have individuals with wallets that may or may not represent organizational activity.

A key takeaway here is that we have a much more distributed cryptographic architecture. The core layer 1 block chain will have its own decisions about PKI and cryptographic methods. In general those will align with node operators that mine or validate blocks, but it’s still necessary to evaluate this area itself.

Then you must consider the variety of wallets that may be interacting. It is likely to be built by another third-party and therefore will have its own set of cryptographic designs and decisions. While requiring a particular wallet seems counter-intuitive to the user choice imperative of Web3, I do believe there will be room to make intelligent recommendations or guidance here.

Finally, there is the Layer 2 ecosystem that will exist above the core. We will explore this more in following posts, but the main thing to know is that a rich ecosystem of components will exist to solve scaling and efficiency challenges. While these components will likely reconcile with a Layer 1 at some point there is still a need for cryptographic validation at these higher levels.

Consensus

The last, and perhaps the biggest, new area is the consensus model. In my mind this is a crucial area to expand understanding and develop best practices. In Web3 the design of consensus is a key component in verifying our trust of a system that is operating at a global scale.

Previously, consensus algorithms would be the niche of a specialist in Disaster Recovery or Data Architecture domains. Any modern distributed system that employs replication needs a way of determining the correct state when issues occur and result in a state (i.e. values) that varies across the cluster or application. Consensus algorithms attempt to solve this problem, but many IT organizations have relied on third-parties for this functionality or only have a few specialist in this area. Think here of etcd in Kubernetes or a distributed SQL database as examples. In public cloud the providers use consensus system for recovery their platform services. However, these platforms can be adopted without a deep knowledge of Raft or other consensus algorithms.

What is new here is a need to understand consensus as a core operating principle of the infrastructure. You don’t need to be an expert in Paxos, but it is key to understand how consensus is achieved on the source of truth. What transactions (or operations) occurred, between who, and when? So called 51% attacks can occur in systems that have perfectly functioning cryptography and security controls. At scale this type of data corruption may not be as likely, but projects (or layer 2 components) with smaller networks remain vulnerable.

In Web3 there are a number of consensus algorithms and this is still changing. That said I recommend getting a good understanding of Proof of Work (PoW) and Proof of Stake (PoS). Both algorithms are currently found in many of the more popular blockchains. You can find a general overview of those and other algorithms here: https://www.geeksforgeeks.org/consensus-algorithms-in-blockchain/

Wrapping up…

To wrap up, we see the appearance of new themes in the soundness of a project’s cryptography, security of user wallets and the design of consensus algorithm. There are more themes that will emerge as we tackle the following domains.

Further as Web3 is still nascent, many components are still emerging in “side chains”, ”rollups”, and “oracles”. The last one being key to bring data in from the Web 2.0 world. This will mean there are multiple layers to consider, understand and ultimately verify. Which leads nicely to the next part in this series covering Domain 2 – Governance and Enterprise Risk.