Saranyu: Building a Virtual Services Marketplace with Smart Contracts
Most of the hype around blockchains for cryptocurrency seems to have peaked by now, and the topic seems headed down the Gartner hype cycle curve toward the Valley of Despair. Meanwhile, a community of researchers has been working quietly in the shadows of the Bitcoin circus toward other applications of blockchains, particularly those involving smart contracts and permissioned ledgers.
One particularly interesting application we’ve been investigating is how to construct a marketplace for virtual services using smart contracts running on a blockchain, hosted in a cloud datacenter or in a distributed cloud. Such a marketplace would support matching buyers and sellers of “anything as a service (XaaS)”, or, at least, anything that can be offered on a virtualized platform. In this blog post, we’ll tell you a little about our prototype, named Saranyu after the Hindu goddess of the clouds.
What are Smart Contracts and Permissioned Ledgers?
Smart contracts are pieces of code that run on a distributed ledger platform (aka a blockchain) that utilizes cryptographic and consensus protocols, and they typically codify the actions pertaining to a business agreement. Smart contracts were popularized by the Ethereum public (unpermissioned) ledger, second only to Bitcoin at the peak of its hype curve. The language used for programming on the Ethereum blockchain is Solidity, which was specifically developed for programming smart contracts. Hyperledger Fabric, an open source Linux Foundation-sponsored project, instead uses the general purpose Go language to program what they call “chaincode”, in other words, code that runs on the blockchain. Hyperledger Fabric is also a permissioned blockchain, which means that to read from and write to the blockchain you need to establish an account, just like for any other cloud service, and the entity or consortium controlling the blockchain can set up specific rules for which entities get access and which don’t. Unpermissioned ledgers such as Bitcoin and Ethereum allow access to anyone.
For business applications like setting up a virtual marketplace, there are clear advantages to using a permissioned ledger. Distributed ledgers require a procedure called consensus to determine what records get written and in what order. A centralized database doesn’t require consensus because only one entity is involved in deciding what transactions contain. In a distributed ledger, transaction processors running on multiple nodes are involved, and some procedure must be defined for the nodes to agree on the ordering and content of the transactions. In an unpermissioned blockchain, the consensus algorithms must be designed so that the participants need to somehow invest something to achieve consensus, to hinder a participant from disrupting operations to gain an unfair advantage. For Bitcoin and Ethereum, the “something” that is invested is electricity, through the “Proof of Work (PoW)” algorithm, which is notoriously slow. Bitcoin now achieves only around 4 transactions per second (tps) maximum and Ethereum achieves around 7 tps. In comparison, the Visa network achieves around 1667 tps and even PayPal gets 193 tps. In a permissioned blockchain such as Hyperledger Fabric on the other hand, because the participants are known and trusted, the consensus algorithm can be much faster, and not as wasteful of electricity.
While the advantages of using a permissioned blockchain are clear, the case is less clear with respect to a general-purpose language like Go versus a language specifically developed for programming smart contracts like Solidity. For Saranyu, we used the J.P. Morgan Quorum open source blockchain, which features a port of the Ethereum Virtual Machine running on a permissioned blockchain and programmed the smart contracts in Solidity. Quorum handles checking permissions between transaction processors to ensure a processor can join the network. Just like Ethereum, Quorum has two kinds of accounts, external accounts owned by a person or company and contract accounts which house smart contracts. Quorum also supports a private transaction system, called Constellation, where a subset of parties can conduct transactions that are not visible on the public blockchain. While we didn’t use that feature in Saranyu, we felt it might become important in the future for business negotiations between service providers and between them and customers. Finally, Quorum has been in production use for over two years and J.P. Morgan is actively pursuing building new products on it, meaning that the code should be stable, and support would likely continue.
Saranyu provides five services:
1. Identity management – During enrolment, tenants and services establish an identity in Saranyu that is used in subsequent interactions to match incoming requests for access to accounts or to update service information.
2. Service offering – Services delegate resource bundles to Saranyu, and Saranyu then subdelegates these resources to tenants when tenants subscribe to them. Services can structure their resource offerings according to a variety of payment and quota limitation plans.
3. Authentication – When a tenant attempts to access datacenter services to which they are subscribed, they must prove their identity in an authentication process. The familiar “login with user name and password” that most Web services use today is an example, but because Saranyu is based on blockchain technology, public/private key pairs are used instead. Public keys provide a much more secure authentication method because they are not subject to guessing attacks. Similarly, services must authenticate to access their accounts.
4. Authorization – Tenants subscribe to services through Saranyu and they require authorization to access services. Access to services and resources is constructed as delegations from an owner to a recipient in a smart contract on the blockchain, including a particular tariff. Services and tenants are free to implement customized contracts for service access if desired. Delegations come with either a quota for usage or a charging schedule for payment or both.
5. Charging – Saranyu provides the ability for services to charge for usage when coupled with a metrics system that records usage of service attributes. A variety of charging credentials can be used, and settlement proceeds through a backend payment processor. Cryptocurrency can be one of the settlement techniques but Saranyu itself does not support cryptocurrency.
The figure above illustrates the Saranyu functional model. The steps correspond to the following:
1. A service registers a JSON document describing its resource offerings with Saranyu. The service can structure different resource types however it wants, but in the figure, the service is offering one resource type for individual tenants (silver) and one for enterprise tenants (gold). The resource contains attributes with quota and/or attributes where a charging metric is specified. The service signs the JSON document and delegates the resources to Saranyu, to subdelegate to tenants. Saranyu records the JSON document on the blockchain.
2. Saranyu displays the resource offerings in a Web UI along with other services. The tenant can select an offering and subscribe to it. The tenant countersigns the JSON document, indicating acceptance of the terms (quota and charging). The tenant then receives a JSON Web Token (JWT) allowing them to prove their authentication. JWTs are included in the HTTP authorization header when the tenant clicks on the service URL in the Web UI. The service must additionally check authorization with Saranyu or through a cache of authorization they maintain.
3. The tenant clicks through the service URL and consumes the service attributes in the resource offering to which it subscribed. The service keeps track of the tenant usage and periodically reports it to Saranyu. If any of the attributes have a quota attached, the service ensures that the tenant does not exceed its quota. Saranyu periodically runs a charging cycle to an external payment processor, using credentials provided by the tenant when they first established their account with Saranyu. Usage and charging information is also available in the service’s dashboard for the tenant, accessible through the Web UI.
While the current version of Saranyu having a single external account for the datacenter owner might seem a bit limiting; hence we intend to explore extending the model towards distributed cloud architectures, in which the cloud is made up of federated cloud providers rather than having a single owner. Blockchains are uniquely suited to such situations, where the participants don’t completely trust one another or where they compete in some areas but need to cooperate in others. The current version is just our first prototype, to support the Cloud 3.0 platform we’re building in the Ericsson Research Data Center, and it is now running there providing tenant management for the Nefele compute service. We look forward to extending it in a variety of directions, such as scaling up Saranyu for larger scale, and for provisioning compositions of services.