I Feel Like I'm on Top Again Baby

thousand

With the growing interest in blockchain technology, software developers are looking into integrating smart contracts into their applications. The end-to-stop multi-step procedure of deploying a smart contract and integrating information technology into a Web application is adequately cumbersome. Project BlockHead takes advantage of the Open up Service Broker API specification to build a service broker layer placed between the Web awarding and the blockchain network. The broker controls management of the smart contract past automating cosmos and deployment of smart contracts and so exposing the required set of information to the Spider web applications.

@ nimak

Nima Kaviani

Senior Cloud 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 equanimous of ii parts:

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

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

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

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

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

However, when it comes to a deployment to the main Ethereum network (mainnet) or a examination network (testnet), developers still demand to manually go through the process of provisioning a blockchain node to ensure successful deployment and integration of their contracts with their applications.

Every bit open up source platform engineers, we strive to simplify the process of application evolution for software engineers. Platform-as-a-Service (PaaS) exists on the premise of making it easier for developers to deploy, scale, and manage their applications; and platforms like Kubernetes and Cloud Foundry have come up a long way in simplifying application lifecycle management. Following the same premise, we believe PaaS platforms tin 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 projection BlockHead was born.

Project BlockHead takes advantage of the Open Service Broker API specification to build a service broker layer placed between the Web application and the blockchain network. Doing so, the banker controls management of the smart contract by automating creation and deployment of smart contracts and so exposing the required set of information 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 can easily bind and utilize services through the exposed APIs. Service brokers are responsible for ad 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 resource on a service as an instance. In the context of the BlockHead banker, the service instance represents a blockchain node continued to the blockchain network. What a binding represents may besides vary by service. Cosmos of a binding provides the service instance with smart contract information for it to exist compiled and deployed and become bachelor to the application using the service. A platform marketplace may expose services from i or many service brokers, and an individual service broker may support i or many platform marketplaces using unlike URL prefixes and credentials. Picture to a higher place shows an example of interaction with the service broker API to provision a service."

More details on how to interact with a service broker tin can exist institute beneath:

BlockHead Service Banker

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

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

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

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

one. Deploying the Banker

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

In this blogpost we have the BlockHead service broker deployed alongside a Deject Foundry deployment. This allows u.s. 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 below.

Once you lot accept a BOSH deployment environment with Deject Foundry deployed on it, deploying the BlockHead banker is every bit uncomplicated as running the post-obit script:

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

2. Service Marketplace and Contract MarketPlace

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

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

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

Further to this, we have as well developed a simple contract marketplace that would permit us to list contracts and then refer to them using their URL when bounden an application to an Ethereum node. To take the contract marketplace deployed, you can add your smart contracts to the marketplace, build the docker image, push information technology upward to a docker registry and and then use a command like to the following to download and use it:

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

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

In our case the market place is bachelor at the accost beneath and navigating to the address nosotros can find the website:

Observe on top of each contract definition in that location is a hyperlink reference to the code for the contract. This contract URL is what nosotros employ to demark the service to the application and deploy the contract. Note that deploying the contract marketplace is optional and if you have other ways to supply a smart contract URL to the Ethereum service, it would totally piece of work as well.

3. Provision the Service Instance

When a asking to provision a service instance is issued, the banker starts up an Ethereum node. The Ethereum node exposes its Remote Procedure Call (RPC) api for interactions and makes the endpoints available through a given address and port number.

For the node cosmos to occur, you need to first deploy a Web3 application that is intended to use the smart contract. For the instance of this weblog post, we will be using our simple-node-awarding that simply 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 exercise not showtime the app when pushing it otherwise the deploy will fail.

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

Adjacent, nosotros create the Ethereum service for the deployed application:

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

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

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

four. Create Service Bounden

When binding to the service, the location of a smart contract in the course of a URL is passed to the broker. The broker downloads the contract, compiles information technology, 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 marketplace provides the link to the given contract, so we can simply go the URL location of the contract and bind it to the awarding.

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

With the service binding going through successfully, we can issue a cf env control to see the updated listing of surroundings variables for the awarding.

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

Going back to the sample node application referenced before, yous encounter that the code in the application uses these surroundings variables to exist able to demark to the smart contract and employ it.

And VOILA! with that information, yous tin define routes for you node.js application to get and prepare values into the ledger using the smart contract:

5. Delete Service Binding

When unbinding the service, the banker assumes that the contract used during the demark phase is no longer required, as a result, upon receiving an unbind request, the banker detaches the service from the awarding and removes the injected contract data from VCAP_SERVICES, but keeps the node around for it to possibly have other contracts deployed to it. Newly deployed contracts volition use the same Ethereum node with the aforementioned account created during the service cosmos phase.

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

cf unbind-service nora simple

6. Deprovision Service Example

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

Challenges and Future Comeback Plans

1. Syncing the Ledger

Similar many other blockchain networks, nodes in Ethereum crave the total ledger to exist present for subsequent transactions to take effect. This implies that the docker container created past the BlockHead service broker either needs to include the full ledger at the time information technology gets created or to sync the ledger later the container is created. The latter is very fourth dimension intensive. The ledger size for the mainnet Ethereum is around 600GB and growing. Given the ledger size, it would take considerable amount of time for the provisioned Ethereum node to sync its ledger and exist ready, making the integration impractical.

An alternative solution is for the service banker to maintain a warm docker prototype with a fairly up-to-appointment re-create 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 image.

Currently, the service broker launches the Ethereum node in programmer mode which implies starting with a fresh ledger. This helps us quickly bring upwards a development surroundings to test Web3 applications confronting while avoiding the long wait for ledger syncup. We programme to implement techniques that would allow quick startup of an Ethereum node against the mainnet or testnet for production purposes every bit well.

2. Memory footprint

Syncing the ledger involves reading transaction blocks from other peers in the network, validating them, and so calculation 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 earlier writing the new blocks to the deejay. This constrains memory usage on the VMs deploying Ethereum nodes and puts an upper jump to the number of containers that can be run and managed by the broker.

3. Account Management

As mentioned earlier, Ethereum nodes demand to bind to an Ethereum business relationship before being capable of deploying contracts. This implies that the broker either needs to manage Ethereum accounts by both internally creating and then exposing them to the awarding developers or past allowing the developers to import their own accounts to employ with the banker.

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

Summary

In this web log post we discussed the implementation of Project BlockHead as a service broker to be 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 nosotros described the end-to-end procedure of deploying and using the broker, application developers need to just care well-nigh Steps three to 6 of the process described above. This involves creating a smart contract service and binding it to an application. Steps i and two of deploying the service broker and the contract marketplace would potentially be done merely once and typically managed by platform engineers and operations engineers, simplifying the overall process.

Project BlockHead came about as a hackathon project during Cloud Foundry Summit 2018 in Boston and as y'all might accept noticed almost of the repositories we shared in this weblog post are personal github repositories of our team participating in the hackathon. Luckily the project has received good amount of involvement from the customs and hopefully in the near time to come information technology will find a new habitation as an incubated project and be properly CI/CD-ed. So come dorsum to this blog postal service for further announcements as to where you tin find the official project repository. It is an open up source projection and we certainly welcome any contribution to make information technology better.

Tags

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

Related Stories

hamiltonhentwonce.blogspot.com

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

Share this post