Now You Know I'm the Best

m

With the growing interest in blockchain engineering science, software developers are looking into integrating smart contracts into their applications. The terminate-to-end multi-stride procedure of deploying a smart contract and integrating it into a Web awarding is fairly cumbersome. Projection BlockHead takes reward of the Open Service Broker API specification to build a service broker layer placed between the Web application and the blockchain network. The broker controls direction of the smart contract by automating cosmos and deployment of smart contracts and then exposing the required set of information to the Web applications.

@ nimak

Nima Kaviani

Senior Deject Engineer

Project BlockHead: An Ethereum Smart Contract Service Broker for Kubernetes and Cloud Foundry

This blogpost is co-authored past Swetha Repakula , morgan bauer , and Jonathan Berkhahn

With the growing interest in blockchain applied science, software developers are looking into integrating smart contracts into their applications. Applications developed and integrated with blockchain are typically composed of 2 parts:

• A smart contract deployed to the blockchain network
• A Web application that binds to the deployed contract and uses it.

A smart contract can be idea of as a snippet of lawmaking available at a given address in the blockchain network which is capable of receiving and processing input data, retrieving or updating ledger land, and returning results to the requesting party. The web applications using the contract are commonly referred to every bit Web3 applications.

Despite all the excitement in using blockchain, the end-to-end multi-step process of deploying a smart contract and integrating it into a Web application is fairly cumbersome. An awarding developer requires to:

1. develop or reuse a smart contract
2. compile the contract lawmaking
3. retrieve the executable binary and the application binary interface (ABI)
4. bring up a blockchain node (e.chiliad., Ethereum)
5. create or import an account (i.e. Wallet) into the node
6. use the business relationship to deploy the binary lawmaking into the blockchain network
7. verify deployment and retrieve the contract address
8. and finally utilize the combination of the account address, the contract address, and the contract ABI in a Web application to bind to the contract and use it

There accept been efforts to simplify the process of developing smart contracts. Truffle, for example, offers a development framework that brings up a local Ethereum network and allows developers to test-bulldoze development of their smart contract applications.

Still, when information technology comes to a deployment to the main Ethereum network (mainnet) or a test network (testnet), developers notwithstanding need to manually go through the procedure of provisioning a blockchain node to ensure successful deployment and integration of their contracts with their applications.

As open source platform engineers, nosotros strive to simplify the process of awarding development for software engineers. Platform-as-a-Service (PaaS) exists on the premise of making information technology easier for developers to deploy, scale, and manage their applications; and platforms like Kubernetes and Cloud Foundry accept come a long fashion in simplifying awarding lifecycle management. Following the same premise, we believe PaaS platforms can and should simplify evolution of smart contract applications and make it integral to the lifecycle of smart contract applications deployed to PaaS. This is why project BlockHead was born.

Projection BlockHead takes advantage of the Open Service Broker API specification to build a service broker layer placed betwixt the Web application and the blockchain network. Doing then, the broker controls management of the smart contract by automating creation and deployment of smart contracts and then exposing the required set of data to the Web application.

Open Service Broker API

The Open up Service Broker API (OSB API) specification offers a common interface for the cosmos and integration of a service marketplace into cloud applications in such a way that services can be maintained and managed independently from the applications and yet applications tin can hands bind and use services through the exposed APIs. Service brokers are responsible for advertising a catalog of service offerings and service plans to the marketplace, and acting on requests from the marketplace for provisioning, binding, unbinding, and deprovisioning.

Borrowing from the specification of the OSB API, provisioning reserves a resources on a service as an case. In the context of the BlockHead banker, the service instance represents a blockchain node connected to the blockchain network. What a binding represents may likewise vary by service. Creation of a binding provides the service example with smart contract information for information technology to exist compiled and deployed and become available to the application using the service. A platform marketplace may expose services from ane or many service brokers, and an individual service broker may support ane or many platform marketplaces using different URL prefixes and credentials. Pic to a higher place shows an example of interaction with the service broker API to provision a service."

More than details on how to interact with a service broker can be found beneath:

BlockHead Service Banker

With project BlockHead, we aim to translate each OSB API phone call to a series of steps in the lifecycle of the smart contract and thus hide the complication of interaction with a blockchain away from awarding developers.

The commencement version of the broker is built on pinnacle of the Container Service Broker, a Cloud Foundry community project. By utilizing the container service broker, blockchain nodes can be run inside an isolated Docker container and operate independently when deploying and binding smart contracts.

We utilise the broker to deploy stateful Ethereum nodes on demand. Each pace in provisioning and bounden or unbinding and deprovisioning are and then modified to evangelize on creation / deletion of smart contracts or nodes. Picture below provides an overall compages for how the Blockhead service broker provisions Ethereum nodes and integrates with the Cloud Foundry applications:

The overall interaction model between the BlockHead service broker and Cloud Foundry applications

1. Deploying the Broker

The initial version of the BlockHead broker is published as a BOSH release. A BOSH release is a versioned drove of configuration properties, configuration templates, startup scripts, source code, binary artifacts, and anything else required to build and deploy software in a reproducible way.

In this blogpost we have the BlockHead service broker deployed alongside a Cloud Foundry deployment. This allows united states to benefit from capabilities in Cloud Foundry to push Web3 applications and bind them to the contract service. For instructions on how to deploy Cloud Foundry consult the documentation beneath.

Once you take a BOSH deployment environment with Cloud Foundry deployed on it, deploying the BlockHead broker is every bit elementary as running the following script:

Since Kubernetes integrates with Open Service Broker API compliant brokers, in case you take a Kubernetes deployment, y'all can hook upwards the deployed BlockHead broker to your Kubernetes platform and bind to deployed smart contracts using Web3 applications deployed to Kubernetes. You tin find out how to do the integration with Kubernetes HERE.

2. Service Market and Contract Marketplace

For the banker to appear in the Deject Foundry marketplace you need to commencement register it using the following command:

                bosh run-errand -d docker-broker broker-registrar              

Once the banker is registered, you can query the marketplace and yous will see the Ethereum service appear in the marketplace:

Further to this, nosotros have likewise adult a uncomplicated contract marketplace that would let us to list contracts and so refer to them using their URL when binding an application to an Ethereum node. To have the contract marketplace deployed, you tin can add your smart contracts to the marketplace, build the docker epitome, button it up to a docker registry and so use a control similar to the post-obit to download and use it:

cf push button contract-marketplace --docker-image nimak/contract-market

You lot can verify that the application is up and running by checking cf apps:

In our example the market place is available at the address beneath and navigating to the accost we can discover the website:

Notice on top of each contract definition there is a hyperlink reference to the code for the contract. This contract URL is what we utilise to bind the service to the application and deploy the contract. Note that deploying the contract market is optional and if you have other means to supply a smart contract URL to the Ethereum service, it would totally work as well.

3. Provision the Service Example

When a request to provision a service instance is issued, the banker starts up an Ethereum node. The Ethereum node exposes its Remote Process Telephone call (RPC) api for interactions and makes the endpoints bachelor through a given address and port number.

For the node cosmos to occur, yous need to outset deploy a Web3 awarding that is intended to apply the smart contract. For the case of this blog post, we will exist using our simple-node-application that merely writes and reads a unmarried value to and from the ledger. Note that since the app does not have the contract connected to it yet, we do not start the app when pushing it otherwise the deploy will fail.

Verify that application nora is pushed to your Cloud Foundry deployment:

Next, nosotros create the Ethereum service for the deployed awarding:

With the asking to create the service, the service broker creates a docker container with an Ethereum node running on it.

This tin can be verified with BOSH by connecting to the docker VM in the broker deployment and looking at the list of docker containers information technology is running (Note that each docker container runs an instance of the Ethereum node that corresponds to the created service).

Yous see that the Ethereum node has its server running on port8545 which is mapped to port32771 externally and on the host vm.

4. Create Service Bounden

When binding to the service, the location of a smart contract in the grade of a URL is passed to the broker. The broker downloads the contract, compiles it, extracts the ABI and pushes the binary to the Ethereum node using the account created at the time of launching the service.

We mentioned earlier that the sample contract market provides the link to the given contract, so we can simply get the URL location of the contract and demark it to the awarding.

Note that when binding the service we pass the contract_url in the form of an inlined JSON configuration to cf demark-service.

With the service binding going through successfully, we tin can issue a cf env command to see the updated list of environs variables for the application.

Under VCAP_SERVICES the configuration for eth involves credentials data for the eth_node such as contract abi, account address, contract accost, transaction hash for the deployed contract, as well as the host address and port mappings for the application to connect to the Ethereum node.

Going back to the sample node application referenced earlier, you run into that the code in the awarding uses these environment variables to be able to demark to the smart contract and utilize information technology.

And VOILA! with that information, you tin ascertain routes for you node.js awarding to get and set up values into the ledger using the smart contract:

5. Delete Service Bounden

When unbinding the service, the broker assumes that the contract used during the bind phase is no longer required, as a upshot, upon receiving an unbind request, the banker detaches the service from the application and removes the injected contract information from VCAP_SERVICES, just keeps the node around for it to possibly take other contracts deployed to it. Newly deployed contracts will use the same Ethereum node with the aforementioned account created during the service cosmos stage.

In case of our running example, the following command would unbind the contract:

cf unbind-service nora uncomplicated

6. Deprovision Service Instance

When a request is issued to deprovision the service, the service broker proceeds to delete the docker container:

Challenges and Futurity Improvement Plans

i. Syncing the Ledger

Like many other blockchain networks, nodes in Ethereum crave the full ledger to exist nowadays for subsequent transactions to take consequence. This implies that the docker container created by the BlockHead service banker either needs to include the full ledger at the fourth dimension it gets created or to sync the ledger subsequently the container is created. The latter is very time intensive. The ledger size for the mainnet Ethereum is around 600GB and growing. Given the ledger size, it would take considerable corporeality of fourth dimension for the provisioned Ethereum node to sync its ledger and be ready, making the integration impractical.

An alternative solution is for the service banker to maintain a warm docker image with a fairly upwards-to-date copy of the ledger to use when creating a service. This requires the broker to run a side node that constantly syncs its ledger with the ledger for the Ethereum network and to periodically create and publish an Ethereum node docker epitome.

Currently, the service banker launches the Ethereum node in developer mode which implies starting with a fresh ledger. This helps us speedily bring up a evolution environs to exam Web3 applications against while fugitive the long wait for ledger syncup. We plan to implement techniques that would let quick startup of an Ethereum node confronting the mainnet or testnet for production purposes likewise.

2. Retentivity footprint

Syncing the ledger involves reading transaction blocks from other peers in the network, validating them, and then adding them to the local copy of the ledger. Since writing to the disk is I/O intensive, an Ethereum node maintains a subset of the ledger in memory while performing validation and chaining of the nodes before writing the new blocks to the deejay. This constrains memory usage on the VMs deploying Ethereum nodes and puts an upper bound to the number of containers that tin can be run and managed by the broker.

3. Account Direction

As mentioned earlier, Ethereum nodes need to demark to an Ethereum business relationship before beingness capable of deploying contracts. This implies that the broker either needs to manage Ethereum accounts by both internally creating and so exposing them to the application developers or by assuasive the developers to import their own accounts to utilise with the broker.

Currently accounts go discarded upon deleting the smart contract service and the respective Ethereum node. This will be revised for the accounts to be exportable / downloadable.

Summary

In this web log mail we discussed the implementation of Projection BlockHead every bit a service broker to exist used in PaaS platforms such as Cloud Foundry and Kubernetes. The goal of Project BlockHead is to simplify how smart contracts are deployed and used in Web3 applications by taking away the complexity of deploying and managing blockchain nodes.

While we described the end-to-end procedure of deploying and using the broker, application developers need to only care nearly Steps 3 to vi of the process described to a higher place. This involves creating a smart contract service and binding it to an awarding. Steps i and 2 of deploying the service banker and the contract marketplace would potentially be done merely one time and typically managed by platform engineers and operations engineers, simplifying the overall process.

Projection BlockHead came most every bit a hackathon projection during Cloud Foundry Summit 2018 in Boston and as you might have noticed most of the repositories we shared in this blog mail service are personal github repositories of our squad participating in the hackathon. Luckily the project has received skilful amount of involvement from the customs and hopefully in the near future information technology will find a new home as an incubated project and be properly CI/CD-ed. And then come up back to this web log mail for further announcements as to where you lot can notice the official project repository. It is an open source project and we certainly welcome any contribution to make it better.

Tags

# ethereum# project-blockhead# smart-contract-broker# smart-contracts# kubernetes

Related Stories

gosswhishatell.blogspot.com

Source: https://hackernoon.com/project-blockhead-an-ethereum-smart-contract-service-broker-for-kubernetes-and-cloud-foundry-88390a3ac63f

Share this post