I Want You All to Myself Baby I'm Selfish

m

With the growing involvement in blockchain technology, software developers are looking into integrating smart contracts into their applications. The finish-to-end multi-step process of deploying a smart contract and integrating it into a Spider web application is fairly cumbersome. Projection BlockHead takes advantage of the Open Service Broker API specification to build a service banker layer placed betwixt the Web application and the blockchain network. The broker controls direction of the smart contract by automating cosmos and deployment of smart contracts so exposing the required set of information to the Spider 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 by Swetha Repakula , morgan bauer , and Jonathan Berkhahn

With the growing interest in blockchain technology, software developers are looking into integrating smart contracts into their applications. Applications adult and integrated with blockchain are typically composed of ii parts:

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

A smart contract tin can exist thought of every bit a snippet of code bachelor at a given address 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 cease-to-end multi-step process of deploying a smart contract and integrating it into a Spider 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.g., Ethereum)
5. create or import an account (i.e. Wallet) into the node
6. use the account to deploy the binary lawmaking into the blockchain network
7. verify deployment and retrieve the contract address
8. and finally use the combination of the account address, the contract accost, and the contract ABI in a Spider web application to bind to the contract and utilize it

At that place have 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 exam-drive development of their smart contract applications.

However, when information technology comes to a deployment to the main Ethereum network (mainnet) or a test 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 source platform engineers, nosotros strive to simplify the process of awarding development for software engineers. Platform-every bit-a-Service (PaaS) exists on the premise of making information technology easier for developers to deploy, scale, and manage their applications; and platforms similar Kubernetes and Cloud Foundry take come a long way in simplifying application lifecycle direction. Following the same premise, we believe PaaS platforms can and should simplify development of smart contract applications and make it integral to the lifecycle of smart contract applications deployed to PaaS. This is why projection BlockHead was built-in.

Project BlockHead takes advantage of the Open Service Broker API specification to build a service banker layer placed between the Web application and the blockchain network. Doing and then, the broker 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 Service Broker API (OSB API) specification offers a mutual interface for the cosmos and integration of a service marketplace into deject applications in such a manner that services tin be maintained and managed independently from the applications and even so applications can easily bind and use services through the exposed APIs. Service brokers are responsible for advertisement a catalog of service offerings and service plans to the marketplace, and interim on requests from the market place 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 broker, the service case represents a blockchain node connected to the blockchain network. What a binding represents may likewise vary by service. Creation of a bounden provides the service instance with smart contract information for it to be compiled and deployed and become bachelor to the application using the service. A platform market may betrayal services from one or many service brokers, and an individual service banker may support one or many platform marketplaces using dissimilar 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 exist found below:

BlockHead Service Broker

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 complexity of interaction with a blockchain abroad from application developers.

The commencement version of the broker is congenital on top of the Container Service Broker, a Deject Foundry customs projection. 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 need. Each step 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 architecture for how the Blockhead service banker provisions Ethereum nodes and integrates with the Cloud Foundry applications:

The overall interaction model between the BlockHead service banker and Deject 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 take the BlockHead service broker deployed aslope a Cloud Foundry deployment. This allows us to benefit from capabilities in Cloud Foundry to push Web3 applications and demark them to the contract service. For instructions on how to deploy Deject Foundry consult the documentation below.

Once you have a BOSH deployment environs with Cloud Foundry deployed on it, deploying the BlockHead broker is as simple equally running the following script:

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

two. Service Market place and Contract Market

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

                bosh run-errand -d docker-broker broker-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, nosotros accept too adult a simple contract market that would allow us to listing contracts and and then refer to them using their URL when binding an awarding to an Ethereum node. To have the contract marketplace deployed, you lot can add together your smart contracts to the marketplace, build the docker prototype, button it up to a docker registry and and so apply a command like to the following to download and use it:

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

You can verify that the application is upward and running past checking cf apps:

In our example the marketplace is available at the address below and navigating to the address we can observe 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 employ to bind the service to the application and deploy the contract. Note that deploying the contract marketplace is optional and if yous have other means to supply a smart contract URL to the Ethereum service, it would totally work too.

iii. Provision the Service Example

When a request to provision a service instance is issued, the broker starts up an Ethereum node. The Ethereum node exposes its Remote Procedure Phone 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 case of this blog mail, we volition be using our simple-node-application that but writes and reads a single value to and from the ledger. Annotation that since the app does not have the contract continued to it yet, nosotros do not start the app when pushing information technology otherwise the deploy will fail.

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

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

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

This tin can be verified with BOSH past connecting to the docker VM in the broker deployment and looking at the list of docker containers it 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 bounden to the service, the location of a smart contract in the form 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 marketplace provides the link to the given contract, so we tin can only get the URL location of the contract and bind it to the application.

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

With the service binding going through successfully, we can outcome a cf env command to see the updated listing of environment variables for the application.

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

Going dorsum to the sample node application referenced earlier, you see that the code in the application uses these environment variables to be able to bind to the smart contract and apply it.

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

v. Delete Service Binding

When unbinding the service, the broker assumes that the contract used during the bind stage is no longer required, equally a result, upon receiving an unbind asking, the broker detaches the service from the application and removes the injected contract data from VCAP_SERVICES, but keeps the node effectually for it to possibly have other contracts deployed to it. Newly deployed contracts will apply the same Ethereum node with the same business relationship created during the service creation phase.

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

cf unbind-service nora simple

6. Deprovision Service Case

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

Challenges and Hereafter Improvement Plans

1. Syncing the Ledger

Like many other blockchain networks, nodes in Ethereum crave the total ledger to be nowadays for subsequent transactions to have outcome. 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 time 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 be ready, making the integration impractical.

An alternative solution is for the service broker to maintain a warm docker prototype 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 image.

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

two. Retentiveness footprint

Syncing the ledger involves reading transaction blocks from other peers in the network, validating them, and and so 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 retention while performing validation and chaining of the nodes earlier writing the new blocks to the disk. 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 Management

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

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

Summary

In this blog mail service nosotros discussed the implementation of Project BlockHead as a service banker to be used in PaaS platforms such equally 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 finish-to-end process of deploying and using the banker, application developers need to simply care almost Steps 3 to half dozen of the process described above. This involves creating a smart contract service and binding it to an application. Steps i and 2 of deploying the service broker and the contract market would potentially be done only once and typically managed by platform engineers and operations engineers, simplifying the overall process.

Project BlockHead came nearly as a hackathon project during Cloud Foundry Summit 2018 in Boston and every bit you might have noticed almost of the repositories we shared in this blog post are personal github repositories of our squad participating in the hackathon. Luckily the projection has received good corporeality of interest from the community and hopefully in the most futurity it will observe a new dwelling equally an incubated project and be properly CI/CD-ed. So come back to this web log post for further announcements as to where y'all can detect the official project repository. It is an open source project and nosotros certainly welcome any contribution to brand it better.

Tags

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

Related Stories

marchandannital.blogspot.com

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

Share this post