posted

0 Comments

The following post came from Bertrand Siridot from the Dell Technologies Office of the CTO explaining his experience migrating an application from Ethereum to the VMware Blockchain.


I have an application, that a colleague of mine and I developed a few years ago, which was written for Ethereum. It is leveraging a web frontend and a smart contract written in Solidity for its backend.

A few months ago, I was given access to a sandbox on the VMware Blockchain as a Service infrastructure. After doing some testing and enjoying the performance of the VMware Blockchain, I decided to try migrating my application to that sandbox.

I mean, how hard can it be, right? The VMware Blockchain supports Solidity and the web3.js library and my application is written in Solidity and leverages the web3.js library, so should be a piece of cake, right? To be honest, it wasn’t super hard to get it migrated over. What made it difficult is that it required leveraging features in the web3.js library that are not super well documented, hence why I decided to write this blog to help other folks do the same thing.

First thing first: I was able to run my Solidity smart contract on the VMware Blockchain without having to make any change. That was goodness, as I was able to take the code I had deployed on my Ethereum nodes and deploy it as-is on the VMware Blockchain, meaning that anybody should be able to deploy their contract there with no issues.

Without getting into the nitty-gritty of the VMware Blockchain, one of its difference with native Ethereum is the fact that it is a permissioned Blockchain and thus you need to authenticate in order to connect to it. This happened to be my first big road block.

In my application, this is how I was connecting to my Ethereum private network:

var Web3 = require(‘web3’);

var web3 = new Web3();

web3.setProvider(new web3.providers.HttpProvider(‘http://<hostname>’));

with <hostname>being either the IP address or the hostname of my Ethereum node.

When I tried this, it didn’t work because of the permission required for the VMware Blockchain. After some research and lots of google kung-fu, I had to change the last line to this:

var Web3 = require(‘web3’);

var web3 = new Web3();

provider = new web3.providers.HttpProvider(<hostname>, 5000, <username>, <password>);

web3.setProvider(provider);

with <hostname>being the URL of the VMware Blockchain API endpoint, <username>being the username I was using to authenticate on the VMware Blockchain and <password>being the username’s password. I should also mentioned that I had to upgrade my web3.js library to version 0.20.7 to leverage the new HttpProvider.

Once I got this done, I thought I was done, but it turned out that I was _almost_done, as I ran into my second issue: CORS, aka Cross-Origin Resource Sharing. Because my application connects to the Blockchain using client-side Javascript, the browser doesn’t like the response it is getting from the VMWare Blockchain, as it responds with a value of “*” to “Access-Control-Allow-Origin” in the HTTP header. For security reasons, browsers don’t allow that value, and this was preventing my application from properly authenticating to the VMware Blockchain.

The solution?? Leveraging a reverse-proxy, ie. have all the blockchain connections and communication go through a reverse-proxy and have the reverse-proxy talk to the VMware Blockchain instead of my browser. Here is the communication flow:

Based on this, the code to connect to the VMware Blockchain is the same as above:

var Web3 = require(‘web3’);

var web3 = new Web3();

provider = new web3.providers.HttpProvider(<hostname>, 5000, <username>, <password>);

web3.setProvider(provider);

but <hostname>points to the reverse-proxy and not to the VMware Blockchain and the reverse-proxy is configured to point to the VMware Blockchain. In my case, <hostname>is http://blockchainproxy.com/blockchain/api/concord/ethand here is my nginx-based reverse-proxy configuration:

     location /blockchain {

proxy_buffering off;

proxy_pass https://<VMwareBlockchain URL>/;

if ($request_method = ‘OPTIONS’) {

add_header ‘Access-Control-Allow-Origin’ ‘http://blockparty.cfapps.io’;

add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;

add_header ‘Access-Control-Allow-Credentials’ ‘true’;

add_header ‘Access-Control-Allow-Headers’ ‘Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With,DNT,User-Agent,If-Modified-Since,Cache-Control,Range’;

add_header ‘Access-Control-Max-Age’ 1728000;

add_header ‘Content-Type’ ‘text/plain; charset=utf-8’;

add_header ‘Content-Length’ 0;

return 204;

}

Where <VMware Blockchain URL>is the URL provided by VMware for the Blockchain sandbox. Once I got the reverse-proxy going and configured my blockchain traffic to go through it, it all worked like a charm!!!

For applications that don’t use client-side Javascript, then there is no need to use a reverse-proxy and <hostname>can point directly to the VMware Blockchain URL.

Those 2 changes were all that were needed for me to migrate my application from native Ethereum to the VMware Blockchain and are the only difference between developing a blockchain-based application leveraging the VMware Blockchain versus native Ethereum.

The promise of better performance and better stability has definitely been realized. In my Ethereum environment, I had to hack the source files to keep the difficulty constant so the response time from the back-end was deterministic and predictable, but with the VMware Blockchain, I didn’t have to do anything, and the application feels snappier. The VMware Blockchain also gives me the ability to update the smart contract on the fly without having to deploy a new contract, with a new address, that would have forced me to update the source code of the application and redeploy it. All in all, my experience so far with the VMware Blockchain has been extremely positive.