EthVigil — API gateway for Ethereum

Published in

BlockVigil

5 min readFeb 27, 2018

EthVigil is an offering from a broader vision of our project named BlockVigil that aims to provide a familiar interface for developers, organizations and medium-to-large scale projects to harness the power of Blockchain and its application in diverse fields that are poised to take off any time soon. EthVigil specifically focuses on the Ethereum platform and ecosystem.

A quick review is in order regarding the existing and upcoming standards in terms of how we use the internet and applications on it.

All code written for the internet has primarily been to enable a not-so-computationally-massive “client” requesting a “server”(stand alone/mainframe/cloud) for information and uploading changes to that information if required and authenticated by the server. Regardless of slight deviations in this model, the central axiom is:

There is one universally true version of the information that is to be trusted implicitly, and that resides on the server. It is not even thought of that a client should have a means to enforce and verify a different version of the “truth”.

If any operations were to be done on a set of data, the transformed data is sent back to the server. This cycle continues, but it all begins and ends at the version of truth presented unilaterally, from the server. The “truth” is modified only by “root access” that concentrates power and authority in the hands of a few, and at the same time, creates extreme vulnerability risks with disastrous consequences.

As you can see we can move into philosophy, economics, governance, AI and other cross-disciplinary, meta issues when we begin asking questions to what’s accepted as the canonical truth. We will let them rest for this article.

The client programming standard for the above model

Step 1 [optional] gain privileges to read and write data from/to the server

Step 2 Read current version of information from server, trust it to be always true

Step 3 [In case of modification] Write modifications to the information, send it to the server and after ensuring acknowledgement from it, rest easy. If the server says so, all is good.

Interfaces that enable this model

1. IPC (Inter process communication)

2. TCP (Socket programming)

3. Protocols atop TCP (For eg. HTTP, WebSocket)

4. Protocols and standards atop HTTP (For eg. REST, JSON-RPC)

Established software engineering patterns within this model

You can create complex, interactive applications based on the fundamental patterns of read and write, secure in the assertion that there is one version of information to be presented and operated on.

So far, so good…

Coming to the decentralized, distributed model of computing that defines the core of blockchain technology, it also presents unique challenges to the programmer who is used to the previously explained model of client-server relations.

· Your (You are an app, or d(istributed)App to be specific) interface to the blockchain network is to connect any of the “nodes” that make up the network. You can run your own node, or connect to public nodes like Infura.

· There is NO server that holds a uniform, authorized version of the global information state!

· Each node is a peer that runs a software to implement the specific protocol of Blockchain accepted by the consensus algorithm on the network. The node software is completely responsible to maintain synchronization with other peers regarding the state of blockchain, pool and send out transactions and continue the cycle of continuous validation with other connected peers on the latest, accepted version of the blockchain.

· So the “truth” becomes shared. What are the implications of such a model?

In a single sentence, your application logic becomes more responsible, thorough, deliberately redundant. Coming from a minimalist, efficient driven background in programming, this is really hard to grasp for many developers, architects and project managers while adopting blockchain tech.

Reads: You can NOT be sure that the data you read is up-to-date and will not be subject to revisions in the future. What you do have is the information from the node about its state of synchronization and pending transactions, if any.

Writes: Your writes are sent out as transactions signed with your private key to guarantee you as the source of it. Depending upon factors of:

· setting the gas limit on your transaction

· network load

· correct encoding of function data,

…even after firing off the transaction to the node you are connected to, you have to specify in your application logic to check for the final acceptance of the transaction into the canon of the chain of blocks or the possibility of it being discarded, failed execution owing to badly compiled code. You get the hint.

Also, once data is written on to the blockchain, it is there forever. There is no “rollback” in the conventional sense of the word.

These also give rise to the challenges of concurrency and atomicity. Your application when production-ready has to be aware of computational costs and fees (for eg. Gas on the Ethereum network) and be fault-tolerant to respect the factthat on a blockchain, every bit of computation and storage comes with a cost.

This is where EthVigil steps in.

We provide a familiar API to encapsulate redundant, anti-fragile application logic expected from dApp’s.

Blockchain, and Ethereum, being a distributed ledger system, there is zero lock in of any of your data.

You can focus on coding “business logic” without worrying about the “protocol logic”.

Rely on our in-built smart caching, monitoring and fault-tolerant logic that powers the API.

We are currently in invite only Alpha and open to all possible feedback and criticism from coders, hackers and pretty much anyone who is serious about adopting and/or porting their products and applications on to the Ethereum platform. Signup on ethvigil.com to get early access.