Baby Its Amazing All the Things I'm Facing

m

With the growing interest in blockchain engineering science, software developers are looking into integrating smart contracts into their applications. The end-to-end multi-step process of deploying a smart contract and integrating it into a Web awarding is fairly cumbersome. Project BlockHead takes advantage of the Open Service Banker API specification to build a service broker layer placed between the Web application and the blockchain network. The broker controls management of the smart contract by automating creation and deployment of smart contracts and then exposing the required gear up of information to the Web applications.

@ nimak

Nima Kaviani

Senior Deject Engineer

Project BlockHead: An Ethereum Smart Contract Service Banker for Kubernetes and Deject Foundry

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

With the growing involvement in blockchain engineering, software developers are looking into integrating smart contracts into their applications. Applications adult and integrated with blockchain are typically equanimous of two 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 exist thought of equally a snippet of code available 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 political 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 process of deploying a smart contract and integrating it into a Web awarding is fairly 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 (e.g., Ethereum)
5. create or import an account (i.e. Wallet) into the node
6. utilise the business relationship to deploy the binary code into the blockchain network
7. verify deployment and retrieve the contract accost
8. and finally use 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 have been efforts to simplify the process of developing smart contracts. Truffle, for example, offers a development framework that brings upwards 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 examination network (testnet), developers even so need to manually become through the process of provisioning a blockchain node to ensure successful deployment and integration of their contracts with their applications.

Equally open source platform engineers, nosotros strive to simplify the process of application 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 have come a long style in simplifying application lifecycle management. Post-obit the aforementioned premise, we believe PaaS platforms tin can and should simplify development of smart contract applications and make information technology 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 between the Web application and the blockchain network. Doing so, the banker controls management of the smart contract past automating cosmos and deployment of smart contracts and and then exposing the required set of information to the Web application.

Open up Service Broker API

The Open Service Broker API (OSB API) specification offers a common interface for the creation and integration of a service market into cloud applications in such a way that services can be maintained and managed independently from the applications and all the same applications tin can easily demark and use services through the exposed APIs. Service brokers are responsible for advertising a catalog of service offerings and service plans to the market, 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 every bit an example. In the context of the BlockHead broker, the service case represents a blockchain node connected to the blockchain network. What a binding represents may too vary by service. Cosmos of a binding provides the service instance with smart contract information for information technology to be compiled and deployed and become available to the application using the service. A platform market may betrayal services from one or many service brokers, and an private service broker may support one or many platform marketplaces using different URL prefixes and credentials. Picture above shows an example of interaction with the service broker API to provision a service."

More than details on how to interact with a service banker can be found below:

BlockHead Service Broker

With project BlockHead, we aim to interpret each OSB API 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 showtime version of the banker is congenital on elevation of the Container Service Banker, a Cloud Foundry community 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 demand. Each step in provisioning and binding or unbinding and deprovisioning are and then modified to deliver on cosmos / deletion of smart contracts or nodes. Picture beneath provides an overall architecture for how the Blockhead service broker provisions Ethereum nodes and integrates with the Deject Foundry applications:

The overall interaction model betwixt the BlockHead service broker and Deject Foundry applications

i. Deploying the Broker

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

In this blogpost nosotros have the BlockHead service banker deployed alongside a Cloud Foundry deployment. This allows us 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 have a BOSH deployment surroundings with Deject Foundry deployed on information technology, deploying the BlockHead banker is as elementary as running the post-obit script:

Since Kubernetes integrates with Open Service Broker API compliant brokers, in example you accept a Kubernetes deployment, you lot tin can hook upwards the deployed BlockHead broker to your Kubernetes platform and bind to deployed smart contracts using Web3 applications deployed to Kubernetes. You can find out how to exercise the integration with Kubernetes Hither.

2. Service MarketPlace and Contract MarketPlace

For the broker to appear in the Cloud Foundry market you lot need to start annals information technology using the following command:

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

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

Farther to this, nosotros have likewise developed a unproblematic contract market place that would let united states to list contracts and then refer to them using their URL when binding an application to an Ethereum node. To have the contract market place deployed, you can add your smart contracts to the marketplace, build the docker image, push it up to a docker registry then use a command like to the post-obit to download and utilize it:

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

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

In our instance the marketplace is available at the address below and navigating to the address we tin find the website:

Notice on summit of each contract definition there is a hyperlink reference to the code for the contract. This contract URL is what we use to bind the service to the awarding and deploy the contract. Annotation that deploying the contract market is optional and if you have other ways to supply a smart contract URL to the Ethereum service, it would totally work also.

3. Provision the Service Instance

When a request to provision a service instance is issued, the broker starts upwardly 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 creation to occur, you need to starting time deploy a Web3 application that is intended to apply the smart contract. For the case of this blog post, nosotros will be using our uncomplicated-node-application that but writes and reads a single value to and from the ledger. Note that since the app does not take the contract connected to it yet, we do not start the app when pushing it otherwise the deploy volition neglect.

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 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 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).

You 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 Binding

When binding to the service, the location of a smart contract in the form of a URL is passed to the banker. The banker downloads the contract, compiles information technology, extracts the ABI and pushes the binary to the Ethereum node using the account created at the fourth dimension of launching the service.

We mentioned earlier that the sample contract market place provides the link to the given contract, and so nosotros can simply go the URL location of the contract and bind it to the application.

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

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

Under VCAP_SERVICES the configuration for eth involves credentials data for the eth_node such as contract abi, account accost, contract address, transaction hash for the deployed contract, equally well equally the host address and port mappings for the awarding 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 utilise it.

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

5. Delete Service Binding

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

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

cf unbind-service nora elementary

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

ane. Syncing the Ledger

Like many other blockchain networks, nodes in Ethereum require the full ledger to exist nowadays for subsequent transactions to take effect. This implies that the docker container created by the BlockHead service broker either needs to include the full ledger at the time information technology gets created or to sync the ledger after 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 be ready, making the integration impractical.

An culling solution is for the service broker to maintain a warm docker epitome with a fairly upward-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 development environment to examination Web3 applications against while fugitive the long wait for ledger syncup. Nosotros program to implement techniques that would allow quick startup of an Ethereum node against the mainnet or testnet for production purposes as well.

ii. Memory 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 disk. This constrains retentiveness usage on the VMs deploying Ethereum nodes and puts an upper bound to the number of containers that can exist run and managed by the broker.

3. Account Management

As mentioned earlier, Ethereum nodes need to bind to an Ethereum account before being capable of deploying contracts. This implies that the broker either needs to manage Ethereum accounts past both internally creating and and so exposing them to the application developers or by allowing the developers to import their own accounts to use with the broker.

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

Summary

In this weblog mail we 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 end-to-end process of deploying and using the broker, application developers need to but care nearly Steps 3 to half dozen of the process described to a higher place. This involves creating a smart contract service and binding it to an application. Steps 1 and ii of deploying the service broker and the contract marketplace would potentially exist done only in one case and typically managed by platform engineers and operations engineers, simplifying the overall process.

Project BlockHead came most as a hackathon projection during Cloud Foundry Summit 2018 in Boston and as you might have noticed nearly of the repositories we shared in this blog mail service are personal github repositories of our team participating in the hackathon. Luckily the project has received good amount of interest from the community and hopefully in the near future it will find a new home as an incubated projection and be properly CI/CD-ed. And so come up dorsum to this web log post for farther announcements every bit to where you tin can notice the official projection repository. It is an open source projection and we certainly welcome whatsoever contribution to get in improve.

Tags

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

Related Stories

cansleruply1944.blogspot.com

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

Share this post