Keywords

1 Introduction

Never before has a digital cash system been able to capture the attention of major retailers, the media, and governments as Bitcoin [30], Ethereum [18], and the many other alt-coin variants. Crypto-currencies became very appealing with their promise of programmable money [9]. However, their true value is in their enabling technologies, the blockchain and smart-contracts. These technologies made it possible to design systems that could transact given a set of business logic. In 2021, Blockchain funding grew 713% YoY to reach 25.5Bn USD [8]. Such rapid influx of funding has led to the emergence of new concepts such as Decentralized Finance (DeFi) [33] and Web3.0 [39].

DeFi alone has well over 113Bn USD in funds locked by smart-contracts [33], this means, programmable money locked by different applications running on various blockchain platforms. This includes items such as Non-Fungible Tokens [14], crypto-exchanges, crypto-lending, etc. Web 3.0 on the other hand intends to remove the middle man from most interactions, making most applications true peer-to-peer and fully decentralized.

Meanwhile, the Bitcoin network has shown to be highly resilient, provides high availability and trust in its immutable ledger thanks to its proof-of-work consensus mechanism [16, 17]. The Ethereum network [18] does not fall behind and provides more complex smart contracts. Blockchain at its core leverages several concepts in the crypto community, from one-way hash chains [23, 34], to forward security [6], signature aggregation [29], as well as concepts from game theory [28].

Though they have their limitations, Bitcoin and Ethereum proved the viability of decentralization at scale and their success motivated the next generation of blockchain technologies [2, 10, 12, 19].

Besides high availability, immutability, and the ability to run business logic, decentralized applications benefit from the transparency of the logic running within their blockchain networks. This means that we can verify what code is running, and what data is being fed to the business logic. This makes it ideal for scenarios where parties need to collaborate and guarantee that the intended logic runs. Moreover, in the event something happens, blockchains are fully auditable and code execution can be replayed. This enables us to design systems that leverage blockchain technology to manage systems where multiple parties need to participate without having to fully trust eachother.

This paper explores the use of blockchain in the context of multi-cloud/hybrid-could environments. We present a storage tiering system that relies on smart contracts to manage volume tiering and migration policies across various cloud providers.

2 Background

2.1 Bitcoin Blockchain

Fig. 1.
figure 1

Blockchain diagram

Full size image

Bitcoin is structured as a peer-to-peer (P2P) network architecture on top of the Internet. Each full node in the blockchain contains a full copy of the entire blockchain, which contains all transactions dating back to the original Genesis block (Fig. 1). This allows blocks to validate new blocks/transactions, while at the same time, provide a high-degree of redundancy. Each full node requires several tens of GBs of storage in order to maintain a full copy of the block chain. Blocks are added to the network via consensus, which can be as energy-hungry as Bitcoin’s proof-of-work, to more traditional approaches such as Hyperledger Fabric’s Kafka-based ordering service [1, 12].

2.2 Decentralized Applications

Decentralized applications (dApps) were first introduced by Bitcoin [30]. Applications such as Namecoin or Colored coins used the ledger as a secure data store, where they used the OP_RETURN operator/instruction to store encoded data that could be publically verifiable. Ethereum further improved on the idea of smart contracts by introducing the Ethereum Virtual Machine (EVM) and its own programming language called Solidity [18]. The EVM allowed for more complex programming models and implementations, thus becoming the de-factor ledger of choice for most dApps. HLF [1, 12] introduced the concept of chaincode (smart-contracts) running within their own containers, which enables environment reproducibility. Unline the EVM, which requires code written in Solidity, HLF supports golang natively, and has added support for other languages such as Java and NodeJS.

Namecoin [32] was one of the first projects to leverage the Bitcoin blockchain to build a decentralized version of a critical legacy system (DNS). Namecoin’s DNS service was built around the Bitcoin blockchain, where entries were to be stored as metadata within the blockchain using the OP_RETURN operator. Due to the limitations of the Bitcoin blockchain, Namecoin decided to do a full fork plus some additions of the Bitcoin code base. The blockchain allows DNS entries to be registered within the Namecoin blockchain, making domain ownership immutable and agreed upon a large number of parties. Each Namecoin record consists of a key and a value which can be up to 520 bytes in size. Each key is actually a path, with the namespace preceding the name of the record. The key d/example signifies a record stored in the DNS namespace d with the name example and corresponds to the record for the example.bit website. The content of d/example is expected to conform to the DNS namespace specification [31].

Several approaches have looked at using the blockchain as a means to store data. One of the most popular approaches is the Inter-Planetary File System (IPFS) [7], which is growing in popularity among the community. IPFS allows for truly decentralized storage. Filecoin [27] is yet another up and coming project that incentivices parties to provide storage in exchange of filecoins. Blockstore [36], keeps block metadata in the Bitcoin blockchain, while storing the actual block data in a Kademlia-like DHT (see Fig. 2). Similarly, Storj [38] and MetaDisk [37] follow a similar concept, where block metadata is stored in a traditional blockchain with a modified proof-of-work, while the data is erasure coded and distributed among storage nodes in their network.

Decentralized identity [4, 5, 15, 22, 24, 25] is yet another hot topic in the Blockchain world, as it relies on granting users unrestricted access to the network. For a more comprehensive survey on decentralized applications please see [3].

Fig. 2.
figure 2

Blockstore architecture

Full size image
Fig. 3.
figure 3

dApp sample architecture

Full size image

Most decentralized applications rely on a front-end application (UI/UX) that allows users to interact with the blockchain. These UI/UX systems either talk to some RESTFul APIs in the form of gateways, that serve as entry points to ledgers, or they rely on a wallet type client that directly interacts with their respective blockchains via some discoverable peers. Figure 3 shows an example of a typicaldApp, where the user is shown accessing the same blockchain via a light-weight client (also known as a wallet), and through a web interface. One key difference between the two approaches is that the wallet may have access to the user’s keys, which control which assets he/she owns. In this model, assets are user owned/user controlled. The second approach does key management on behalf of the user, thus, not really user controlled nor user owned as the keys that own the assets belong to the party providing the web portal. This is very common in Cryptocurrency Exchanges.

2.3 Permissioned Ledgers

Bitcoin, Ethereum, and most crypto-currency variants are known as public permissionless blockchains. Public permissionless blockchains are meant to be used by anyone who wishes it; the only requirement for participating on the network is having a client that adheres to the blockchain’s protocol, and is able to discover peers associated with the ledger. Users in these networks interact via the use of public/private keys. Ideally, in such scenario, users will own the devices they use to interact with the blockchain, as well as the device that has access to the keys. As all assets owned on these blockchains are managed by their respective keys. Thus, when a Alice needs to send Bob a bitcoin, all that she needs is \(Bob's\) Bitcoin address, which is derived from its public key. Her wallet then constructs the transaction saying Alice sends \(coin_i\) to Bob, signs it, and broadcasts it over the network. Bitcoin nodes then process the transaction by verifying that the owner of the \(coin_i\) is indeed Alice by verifying against the public key provided by Alice.

Bitcoin’s smart contract engine is stack based, so there is very limited what it can do, in this case, a simple payment verification script is computed and validated. Ethereum further enhanced its smart contract engine and made it Turing-complete, thus, Ethereum became the blockchain of choice for most parties looking to deploy smart contract based applications. In this scenario, a smart contract is compiled, and its bytecode is deployed. Users then invoke the smart contract with the necessary data to execute the contract, while providing a small fee called gas. Peers then pickup the invocation request, execute it, and agree on the result via consensus. If something goes wrong, consensus will fail, however, in the event of failure, users are still charged the corresponding gas amount. Bitcoin miners charge a small fee to process the transaction, Ethereum does the same via its gas concept. This is necessary as all transactions submitted to the network must be processed, which takes up resources. Requiring transaction fees is a mechanism that incentivices nodes to provide validation/transaction processing services, as well as deterrents against possible denial of service attacks. You can further limit resources spent on a smart contract by requiring higher gas fees.

The freedom in public permissionless blockchains comes at the cost of higher transactional fees, longer transaction validation times, lower transactions processed per second, etc. The latter is due to the fact that these blockchains have to perform resource-intensive consensus protocols, that may rely on brute-force hashing. There are ledgers that try to minimize this as they move towards other types of consensus mechanisms (e.g., proof-of-stake [10, 11]). Other types of blockchains include private permissionless (e.g., LTO Network), public permissioned (e.g., Sovring [20] and Ripple [13]) and private permissioned blockchains (e.g., Hyperledger Fabric [12, 19]).

We choose to work with permissioned blockchains at the enterprise-level as they give us most blockchain features without the horrors of the wild-west that are present in Bitcoin or Ethereum, moreover, since permissioned blockchains require nodes to be authenticated, there is a certain amount of trust on the participants, thus, the consensus mechanism can be easier on the wallet. Moreover, since consensus can be lighter, this means that transaction throughput may be higher in permissioned blockchains.

Hyperledger Fabric (HLF) supports a plug-in based architecture for various components, including consensus. The default scheme uses Apache Kafka as its ordering service, which simple orders transactions on a per-channel basis. The idea of having separate channels allows for higher transactional throughput, as peers can process transactions for multiple channels natively.

Fig. 4.
figure 4

Ordering service in hyperledger fabric [12]

Full size image

Furthermore, HLF for example relies on the idea that a chaincode/smart contract can be packaged, and deployed on the ledger. When the chaincode is deployed and initialized, a container instance is created on each peer participating (subscribed) to the given channel (topic). This means that HLF is not a single blockchain, but rather, composed of multiple individual chains (called channels). Another benefit of the channel architecture is the data segregation, so only peers who join the same channel can see the same data. A high-level diagram of HLF’s ordering service is shown in Fig. 4.

2.4 Cloud Computing

With a projected revenue of US$397.90Bn in 2022 [35], worldwide adoption of Public Cloud continues to increase YoY with an expected CAGR 2022–2027 of 15.97%. Cloud computing allows companies to reduce their overhead as they can purchase compute and storage resources on the fly based on their demans. This means that many companies may save money by adopting public offerings over hosting their own services in their own data centers, where companies need to pay for servers, IT departments, electricity, cooling, premises, etc. Rather, for some companies it is more cost effective to run lean IT departments and rely heavily on the cloud. In some scenarios such move to the cloud may not be cost effective or feasible. For example, companies with strict data compliance policies may not be allowed to export data outside of their premises/geo locations. Another reason is that some companies may prefer to optimize their own IT environments in order to achieve better cost. This is why sometimes cloud-heavy companies choose to move back from the cloud and run their own IT infrastructures. Some companies may choose to take a hybrid approach, where they host some critical/sensitive services on premise, while hosting other public cloud friendly services in the cloud.

Though cloud computing has many pros, they are multi-tenant in nature, thus, when a company uses cloud resources, they are actually sharing said resources with other companies. In a sense, as cloud providers grow, they continue to centralize (from a service perspective) compute and storage services. This means that in the event of a failure, unlike the old days, when a server fails, the disruption was more or less contained to the company hosting the service. In this case, when there is a cloud service disruption, it can affect hundreds or thousands of companies [21].

Finally, cloud computing in general is the future of computing, thus, many companies have joined its competitive landscape. This enables companies looking for better service level agreements (SLAs) and better fault-tolerance, as well as competitive pricing, to explore spreading their services across various providers, and in many applications, support for multi-cloud deployments.

3 Smart-Contracts in the Cloud

One of the benefits of having competition in the cloud space besides pressured innovation and better pricing, is the ability to spread application deployments across various clouds, be it multiple public clouds, or hybrid-cloud environments. This means that applications have to talk different languages (e.g., different cloud APIs) as well as different SLAs. Such ecosystem is composed of multiple parties that need to trust in a programmable way, where business logics can map to policies and SLAs. These types of deployments are low-hanging fruit opportunities for Blockchain. Blockchain, would privide a trusted common platform for multi-cloud applications to deploy business logic that is agreeable across various parties. It is transparent, auditable, and highly available. All qualities of outmost importance in today’s rapid evolving IT world.

This section will explore one such use case that leverages the concept of multi-cloud in conuction with blockchain technology in order to provide a common platform for the management and deployment of common IT service technologies such as Information Life Cycle Management, Storage Tiering, Change Management, etc.

3.1 Storage Tiering

Overview. Storage tiering helps organizations strike a balance between performance and cost by moving data around different tiers to cope with swings in demand. Tiering ensures that data sits on the most appropriate storage fabric according to the application’s needs, be it latency or throughput. Most research efforts have focused on traditional storage systems and tiering across different disk types. For instance, hot data residing in Tier 2 (high endurance, high capacity, 10K RPM HDs) can be migrated to high performance, high cost SSDs. This process is called up-tiering, where you go from a lower class tier to a higher class tier. Similarly, you can migrate cold data from a high tier (T1) to a colder tier (T2). There are many types of tiers. There are usually several rules of thumb with respect to how to map data to the right tier. For this, one of the main metrics dynamic tiering systems use is IO density, which is a function of IO/second/GB. Based on IO density we might decide to up-tier or down-tier storage. Tiering can be done for object storage, file storage, and of course, the most popular, block storage. For Object/File storage you would look primarily at access rate, whereas block storage you look primarily at IO density.

Table 1. Tier/IO density mapping for block storage
Full size table

Table 1 shows a traditional rule-of-thumb mapping between a tier and its applicable IO Density. System administrators/automated systems will use these metrics to decide where a particular volume should be mapped. Up/Down-tiering a volume involves copying and moving a volume across tiers, these tiers could be within a data center (traditionally), across data centers (same organization/cloud), and across different organizations (e.g., a hybrid-cloud model). Tiering has many great benefits, but if not done right (e.g., not using the right policy), there are many things that could go wrong, from a simple mistake like putting a volume on the wrong tier, to more serious problems where the volume is lost in-transit with no one to hold accountable. For instance, if a volume is pushed to a tier in a remote organization (e.g., third party cloud), and the volume never makes it to the remote organization, the question is then, what happened? Who is accountable? The third party that provides the block storage service? The system administrator that defined the tiering policy? The engine that executed the policy and did not check that the volume had made it to the third party cloud (new tier)? What if an error in a policy resulted in massive losses for a client, and in order to avoid consequences, the responsible party tampers with the policy? Can they then deny any wrongdoing?

Our approach tries to solve these issues by providing a way to execute policies in an automated fashion, while at the same time providing the means to have accountability for such scenarios. We build on the concept of smart contracts, where we have a fabric that will execute a policy (a smart contract), that has been agreed upon and signed by multiple parties (the system administrator, management, the third party storage provider, etc.), with the goal of introducing accountability into the tiering process.

Storage Volume Tiering. Figure 5 shows a high level diagram of a traditional tiering solution. Storage is allocated and pooled into different tiers, in this example, three tiers, Gold, Silver, and Bronze. When a file system is created/mounted, you then request to place the file system on a particular tier based on business needs, performance needs, etc. This process follows simple rules developed by system administrators. Similar to the block storage scenario, what tier to choose is left to the system administrator, or an automated system guided by a set of policies/rules designed by the system administrator. Automated tiering solutions like IBM’s Easy Tier, EMC’s Fully Automated Storage Tiering, and HP/3PAR’s Adaptive Optimization, all rely on policies and best practices for tiering. These polices are executed by a centralized server/manager, and pre-defined. Often pre-agreed on, however, when you start engaging other parties, the question then becomes, what policy should be implemented given that in a multi-service provider environment, different best practices may be followed, thus ending in scenarios where the end result deviates from what each party involved in the tiering transaction expected. For instance, consider a scenario where we follow Provider A’s guidelines for tiering based on best practices defined by our architects, but once we start using tiers provided by third parties, which may have their own policies for tiering, if our expectations are that IO density of 0.1–0.5 (exclusive) should go to Tier2, but the third party storage provider says 0.1–0.5 (inclusive) is Tier1. We want to down-tier, they want to up-tear, thus leading to problems with respect to where data should reside. If something were to happen where we cause downtime due to a tiering issue, the question then arises, who is at fault? Both parties are following their own guidelines and best practices. For example, our policy says Inactive and unmapped volumes (not associated with a host - orphan) can be reclaimed, but a third party says such volumes are just inactive, thus must be kept in Tier3. Or vice versa. Let’s say a volume is deleted/reclaimed, who is to blame? What policy was followed? This is particularly important when dealing with information life cycle management (ILM) as a whole as it can be applied to tiering as well as backup and retention policies.

Fig. 5.
figure 5

Traditional tiering solution [26]

Full size image
Fig. 6.
figure 6

Smart-contract based tiering

Full size image

Leveraging Smart Contracts. In this work we propose the use of smart-contracts to solve the best practices, policy mismatch, and provenance problem inherent in today’s storage tiering and ILM solutions. Our work can be extended to object, file, and block storage as our engine is technology agnostic. Similarly, we could extend this work to incorporate other aspects of ILM such as backup, recovery, and retention policies. Figure 6 shows a high-level diagram of our approach. The blockchain fabric will be used to serve two purposes: 1) Provide provenance of tiering/ILM actions by recording events in the form of provenance metadata (e.g., hashes of what data is tiered, how much data, time, etc.), this data is immutable, so there is no way to tamper with it. 2) We will use HLF [1] for executing policies in the form of chaincode. In our multi-cloud environment we assume each cloud provider is represented as an organization, and each organization can have any number of peers. Our chaincode endorsement policies require at least one peer per organization to agree for consensus. We use leveldb for a richer world state in order to support dynamic tiering look-up tables.

First, consider the problem we face in Infrastructure-as-a-Service in multi-Service provider environments, where storage architects have designed best practices and policies to best serve their client’s needs. As stated before, different teams may come up with different solutions, as a result, there will be a mismatch with respect to how to manage storage resources. For example, tiering, Provider A may choose to define fine grained policies for tiering, where each tier (Tier0-Niactive as shown in Table 1) has well defined IO densities, while Provider B may choose to define a coarser grained set of policies for tiering, where each tier is mapped to a premium level (a more abstract Gold, Silver, Bronze model as shown in Fig. 5). In this scenario, the question then comes, a volume with 0.5 IO density is mapped to Tier1b, Tier2, or Gold or Silver? This mapping needs to be agreed on, and represented in an abstract model so that we can represented in a generic, simple, yet auditable and error-proof contract that can be executed. And in the event of an error with respect to where a volume is mapped, the contract can be audited and there is non-repudiation as the storage architects/administrators involved in the transaction signed off on the contract. Once a mapping is agreed upon, the next step is to define the logic that will simply tiering across organization boundaries. For instance, take Fig. 7, when a volume enters provider B’s boundaries, the logic within Fig. 7 applies. If the volume’s IO density is high, the volume will reside within GOLD TIER. Provider A would have agreed to set the threshold of> 0.5 as GOLD TIER, so that in the event that a volume goes through up-tiering/down-tiering, we will be able to assign it to the right tier. Similarly, if a volume crosses Provider A’s boundary, there should be a clear distinction in IO load between GOLD, BRONZE, and SILVER. This is because each provider charges different premiums for the different tiers. For instance, Tier0-Tier2 in Provider A is equivalent the Gold tier in Provider B, with respect to IO load but pricing is much different. For instance, Provider A’s premium fee for Tier0 is much higher than Tier1, while Provider B’s premium for the Gold tier is equivalent to Tier1b/Tier2. As a result, in the event volumes going from Provider B to Provider A, Provider B might want to state that for his/her Gold tier volumes, they should be mapped to Tier1b/Tier2 in order to respect the SLA guarantees offered to the consumer without incurring extra cost due to tiering. Now, smart contracts can go beyond simple thresholds and incorporate things like aggressive/conservative policies (last 45 historical, spike, up/down tier) and the window-throttle for tiering (sync-rate).

Fig. 7.
figure 7

Tiering chaincode pseudocode

Full size image

Once the policy has been abstracted, it is represented in chaincode as shown in Fig. 7. All parties involved in managing the storage backend (e.g., our data center admin, the third-party storage provider) will review and agree on the chaincode to be executed. This chainode will exist within a common repository where we have version tracking, users can push code/comments, and do audits. The idea is that there will be full transparency in the process. Now, once the chaincode is agreed upon, all parties (e.g., Party A and Party B) sign the code, and the code is deployed within the blockchain fabric. The idea is that once code is agreed upon, parties cannot deny reviewing it in case something goes wrong. This will give us non-repudiation, so parties are forced to review and sign on any commonly agreed policy. Because without the signatures (acknowledgement from parties), the policy will not execute. Moreover, since this goes into an automated system, whenever a volume’s IO exceeds a tier’s threshold, the data/volume is then submitted to the blockchain fabric, where the chaincode to evaluate the volume information is invoked, and the policy is executed by the fabric. Once tiering is done, in the event somethings goes wrong, auditors can go back in time and see when tiering was triggered, and what policy was executed (e.g., what chaincode was invoked). This also points to the repository that contains the policy, all of it being immutable so no single party can tamper with the policy or deny on agreeing on a particular policy.

Fig. 8.
figure 8

SmartContract-based tiering and information life cycle management for storage infrastructure-as-a-service in a multi-service provider environment

Full size image

Architecture. Figure 8 shows the steps involved in generating and executed smart contracts for the tiering/ILM context:

  1. 1.

    All parties define their tiering policies

  2. 2.

    The policy generation engine consolidates those policies and represents them as a smart contract

  3. 3.

    The smart contract goes through a review process following a devops process and gets deployed on the blockchain fabric

  4. 4.

    The monitoring engine tracks Volume IO (File IO, Object Reads/Writes, etc.), and periodically invokes the policy chaincode based on a tunable window. Furthermore, the monitor is responsible for validating the state of the system, and check if it does indeed reflect the state in the blockchain. When volumes are down/up-tiered, the world state of the system changes within the blockchain fabric itself. So outside parties cannot modify the state of the system without the monitor finding out.

  5. 5.

    The monitoring engine invokes the policy chaincode via its hash

  6. 6.

    The chaincode validates signatures and executes in the different peer-nodes, running consensus on wether to tier, not tier (backup or not, migrate or not, etc.)

  7. 7.

    Finally, the chaincode invokes the tiering engine to execute the up/down-tier operation for the particular volume (or file/object).

In the above model, the monitor and the tiering engine are oracles outside of the blockchain, however, nothing would prevent us from running monitoring chaincode that validate the state of the system. Similarly, the tiering engine logic could also run within the blockchain fabric. This would also allow us to provide a high-availability service, so even if one node goes done, the rest of the network can still operate, and tiering/ILM functionality is not lost. Although we focus on storage tiering/ILM, we can extend this process to many other storage management techniques. Each component in our infrastructure writes provenance data onto the blockchain describing the different actions each component took. Be it executing a tier policy, or how much data/number objects/number files and tier source/destinations, or which chaincode was deployed by which parties. This will allow us to have full transparency and provide auditing logic.

Each participating cloud provider could run a number of peers, thus, they could fully monitor all the events in the tiering ecosystem, to make sure that their SLAs are being respected, while performing the proper analytics and event monitoring to provide optimal SLAs.

4 Conclusion and Future Work

In this paper we discussed the use of smart contracts in an enterprise scenario. We showed a simple implementation of a storage tiering engine that allows volume tiering across multi-cloud environments with the assistance of a private permissioned fabric. Future work includes exploring the use of dynamic pricing for volume migration across cloud providers.