Signer Control+Proxy Smart Contract: A look at EthVigil’s latest offering

This is an overview of the powerful feature we are pushing live in stages on our Alpha instances. The next post will be a deep dive and take a look at the workflows that this feature brings to the table and allows the development lifecycle of a web application to be consistent, even when developed for blockchain.

Sign up on https://blockvigil.com/ to request an early access to our platform and begin building on the web application ideas that can leverage the design patterns of blockchain. We are open to any kind of feedback/criticism/guidance.

Proxy patterns have become a well known approach to manage security and upgradeability of smart contracts on Ethereum and other EVM-compatible blockchain platforms.

This post is not a detailed foray into the world of proxying patterns. It is recommended to read into some of the patterns made available in ZeppelinOS 1.0 and 2.0. ([1] and [2])

Sending transactions to a contract via EthVigil

One of the primary functions of the EthVigil API gateway is to expose smart contract methods as REST API endpoints. (More details on our introductory blog post here)

The following is an example of calling a smart contract method via an API endpoint exposed by EthVigil.

$ curl -X POST “https://rinkeby-api.ethvigil.com/v0.1/contract/0x3f1192dbd5a4f9d6be143cd141eeef229a277a1b/addPost" 
-H “accept: application/json” 
-H “X-API-KEY: blacked-out-key” 
-H “Content-Type: application/json” 
-d “{\”title\”:\”NewPost2\”,\”body\”:\”NewBody2\”,\”url\”:\”http://url\",\"photo\":\"http://cdnimg.url/photo\"}"

It’s an HTTP POST that sends a “signed” Ethereum transaction to the contract behind the scenes. ([3] and [4])

On the Ethereum platform, an account address (160-bits long) is derived from a 256-bit private key. 
A transaction data that is signed with this 256-bit private key is verified by, for example, the ecrecover() function in Solidity that can be accessed through a smart contract present at the fixed memory address 3000 in the EVM. 
The ecrecover() function extracts the Ethereum account, basically the public key, corresponding to the private key and verifies that this transaction was indeed sent from the expected account.

But signed with whose private key?

With EthVigil, you are supposed to stop worrying about managing your own node infrastructure, ethereum addresses and their corresponding private keys, amongst a host of other grunt work that’s best left to us.

We offer the option to our clients to control the private keys that sign transactions sent to specific business logic contracts. This is achieved through what we term a signer control+proxy contract.

• It accepts signed transactions only from Ethereum account addresses that have been whitelisted by the client (from hereon referred as signers).
• It extracts the actual transaction payload data specific to the business logic contract and routes the method call to it

There are two ways on EthVigil to assign signer addresses allowed for specific business logic contract instances:
(a) the client can specify these signers by uploading their private keys to our secure store
or,
(b) the client can choose from a pool of pre-populated signer addresses supplied by EthVigil

• The signing of the transaction is handled by a microservice that extracts private keys securely (yes, even EthVigil doesn’t have access to these keys)
• The client is granted powers to takeover the proxy contract to enable
  * revoking of whitelisted signer addresses for their specific contract instances
  * a killswitch to suspend all transactions routed through this proxy contract
  * provision emergency access by configuring the contract to allow access through cold wallets

BlockVigil is hiring for the role of a Lead Backend Engineer in Bangalore, India who would love to work on tough challenges in building distributed systems that power our API gateway. Go ahead and express your interest in the position over here or kindly share it with those in your network who might be looking for such an opportunity.

A walkthrough to enable and use the signer control+proxy feature on EthVigil

The below example is on the rinkeby testnet instance of EthVigil.

1. Click the Proxy via Signer button.

2. Go ahead and click on Upgrade

3. As the signer control+proxy contract (from hereon referred to as ‘proxy contract’ for brevity) gets deployed, you will be able to observe the status change. We will even flash a quick notification (not in screenshot) when the deployment transaction goes through.

4. You can see the deployed proxy contract in your home tab with the name EVSignerControl , available at address0x9e91209891a035042c49a41a116982fa807c0b52 in this example.

5. In this approach we are deploying the proxy contract with a pre-populated signer address (0x3dc7d43d5f180661970387a4f89c7e715b567512 in this example) that is picked from a pool maintained internally by EthVigil. The same signer address will be the originator of the contract deployment transaction. The same can be verified through an Ethereum explorer like Etherscan or you can make your own JSONRPC calls to a 3rd party infrastructure service like Infura.

Check the contract creator address. In this example, the same is added to the proxy contract as an allowed signer address for further business logic contracts for this client on EthVigil. This is automatically taken care of and needs no user intervention.

6. Henceforth, all deployments and transactions will originate from the assigned signer account address 0x3dc7d43d5f180661970387a4f89c7e715b567512. The method calls to the final business logic contracts will be routed through the proxy contract at 0x9e91209891a035042c49a41a116982fa807c0b52
Let us deploy a new contract via the Remixtab. In this example, we have chosen a microblog contract code.

Enter the constructor inputs for this smart contract and hit ‘Deploy’

7. You will be right away redirected to the Swagger API listing for the methods corresponding to this smart contract. Soon you will see a notification when the contract deployment transaction gets mined on the chain. (yes, this is real time and yes, we consume our own websocket solution for this purpose :)

8. On the EthVigil home tab you will see the deployed contract (at address 0x3f1192dbd5a4f9d6be143cd141eeef229a277a1b in this case) show up with a little icon added before it to denote that this is now managed through the proxying mechanism described so far.

9. If you wish to probe deeper, you will observe that the contract creator is now the EVSignerControl, from step #4. The client contract, microblog in this case, is created through an ‘internal transaction’.

10. Let us add a post via the addPost() method on the smart contract. The Swagger UI generated by EthVigil gives a straightforward way to achieve this. Click on Execute.

11. This will generate a transaction and the response to this call shows up below with the transaction hash that has been sent out — 0xc37840f404e273c345c3c5667f045b284d5f80368e9661ab2f36b47fe392acec in this case.

12. If you inspect the transaction further on an explorer, you will observe that the transaction — from the signer address to the proxy contract — generates an EVM call() (aka internal transaction) which finally calls the addPost() method on the client contract instance.

We will go deeper into the smart contract itself in a future post. Meanwhile, sign up on blockvigil.com to get early access.

Reading resources

[1] ZeppelinOS v1.0 Proxy Patterns

[2] ZeppelinOS v2.0 introduction to proxy patterns

[3] Inside an Ethereum transaction

[4] A closer look at Ethereum signatures