The many emerging faces of Blockchain-as-a-Service
Blockchain is hitting the mainstream and ‘BaaS’ is the buzzphrase. But like most buzzphrases, it’s unhelpfully vague. BaaS can take many forms, and from the point of view of businesses deploying a blockchain project and particularly their end users, they might look very similar.
There’s a lot of interest around Blockchain-as-a-Service (BaaS), which isn’t surprising given the buzz around blockchain or distributed ledger technology (DLT). Like the cloud computing offerings Software-as-a-Service (SaaS), Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS), BaaS promises to provide the features and advantages of the blockchain — such as speed, transparency, efficiency and immutability — without forcing organisations to deal with the technical issues of hosting one themselves. But just what does BaaS mean in practice? Not surprisingly, the shape of that service depends on the needs and capabilities of the organisation in question. In fact, any one of a number of implementations might suit a particular application and look very similar from the outside, as the following case study shows.
BaaS application
My own thinking on BaaS has been informed by several things, including familiarity with different 2.0 cryptocurrency platforms and extensive research into a specific business application. It’s my view that blockchain adoption will be extremely broad in the future, applied to a huge range of different business applications, but that in the short term there will be a relatively small number of obvious use cases. These include remissions, crowd-funding, micropayments/tipping, and loyalty schemes.
I’ve worked on the Incent loyalty scheme with BitScan for over two years now, and in that time the crypto landscape has changed markedly. Whilst we finally partnered with the Waves platform to provide the infrastructure (blockchain-as-a-service), there was no comparable or suitable option when we started out. One of the reasons it’s taken us so long to get here is because the technology to do what we needed to do just didn’t exist. If we were coming to this from scratch today, there still wouldn’t be many options, though a lot more are just around the corner. In the rest of this article I’ll be surveying a few different approaches to BaaS through that lens and exploring some of the differences of each — as well as how any might have produced the same effect had we opted for them.
1) A whole new blockchain
This is a fairly low-level approach to BaaS. At its simplest it’s really no different to the creation of an altcoin, using the bitcoin blockchain as a template. The advantages of this are that the organisation has complete control of its blockchain: it can create it with whatever parameters it requires in terms of consensus system, supply, block time, capacity, and so on, run all the nodes and own all the tokens at the outset. The downsides are that a relatively high degree of technical expertise is needed to create and maintain the network. This places the onus on the organisation itself for running everything: ‘BaaS’ in this instance means little more than delivery of the required client. Whilst it brings a high degree of freedom and control, there are also potentially significant ongoing technical overheads.
2) A child chain on a parent blockchain
In the last few months a set of new options has become available — or is, at least, in development. Sidechains promise much for BaaS. The principle is to have a main or parent chain, on which secondary sub-chains are secured. Anyone can launch a sub-chain or ‘child chain’, subject to paying the required costs, and it may be customised to ensure it is fit for purpose — though perhaps not to the same degree as if you were starting from scratch, as in the case above. Because it is secured on the main chain, the owning organisation does not have to worry about maintaining the network or running nodes. Stratis is taking this approach. The main chain consists of a modified bitcoin clone (written in C#), whilst sub-chains are secured on it. These can be tailored and deployed quickly by any organisation — an off-the-peg approach to blockchain deployment. Nxt 2.0 will take a broadly similar approach with Ardor. Both of these are in development and are expected to launch within the coming months.
This approach has much to commend it for organisations that want to launch their own blockchain without undue concern for its inner workings. Critically, it allows transaction fees to be paid in the token of the child chain — something that was not possible with other approaches. Early iterations of Incent came up against the barrier that although it was easy to create an asset/token on a 2.0 platform like Nxt or Counterparty, transaction fees always had to be paid in the token of the native chain — adding a second currency into the mix and unnecessary friction and complexity to the project. You can circumvent it with an extra piece of software, but it’s awkward. In the event, this was problematic enough to be dealbreakers.
3) A token on a 2.0 blockchain
There’s another approach, and the one we ultimately chose for Incent, which is to launch it as a token on a suitable 2.0 blockchain (in this case, Waves).
For this application, we didn’t need anything particularly fancy. It needed to be possible to send the token to users, following purchase at PoS with the merchant. The user would hold the tokens in their smartphone wallet and pay merchants with them for future purchases. Transaction fees would need to be factored in, and we did not want the additional complexity of end-users having to hold a second currency to pay for transactions, as would have been the case with Nxt or Counterparty (NXT and BTC respectively).
Waves will make it as easy to launch a new token as other 2.0 protocols like Nxt or Counterparty do. There are several important differences between the platforms that lend Waves to Incent’s application, but akey one here is that Waves allows asset-to-asset trading on its decentralised exchange. That means any token can be traded against any other token. Waves’ native currency is the WAVES token, which is required for all transactions. However, this will happen ‘under the hood’ — the end user never has to see it. Asset-to-asset trading means that Incent tokens can be converted to WAVES on the fly, at the point of transaction, so that transaction fees are effectively paid in the asset in question. Put simply, you can send USD and pay USD in fees — you never have to deal with the conversion of a small amount of USD to WAVES tokens.
Three options, one outcome
This is one of the interesting things about BaaS: different solutions can look essentially the same from the perspective of the end user.
We could have achieved what we needed with a totally new blockchain (option 1), or with a child chain (option 2), if a suitable protocol was production ready. In the event, we chose the third option, which was Waves. From the perspective of the end user, there would be very little difference. As far as they’re concerned, they can send and receive the Incent token from their app, without the need for any other currency to act as a transaction token.
In terms of advantages and disadvantages, using an existing blockchain removes significant technical overheads. After that, the child chain and the asset start to look very similar from the end user’s point of view, albeit there’s something completely different going on behind the scenes. For our purposes, it was helpful to be able to trade Incent against a range of different currencies. That, and the reality that no protocol offered viable side-chains, made the decision simple. But it’s worth noting that for many organisations, there will be many ways up the same mountain.
