Launching the eth-kvstore

This is a multi-part series that details the business and technical architecture of HUMAN Protocol, a new approach to human-level machine intelligence which allows machines to ask us directly for the data they need to improve.

Have you ever wished you could provably associate arbitrary data with an ethereum address?

We recently open-sourced a simple yet powerful utility service that lets you tie data to your ethereum address. We call it the eth-kvstore. We needed a way to let ethereum address holders publish and rotate public keys and other security-relevant information, but it can be used to associate any arbitrary data with your ethereum address.

This was important for us to securely implement the HUMAN Protocol, which powers hCaptcha.com. For example, it lets requesters of work in our system (who are referenced via ethereum addresses) specify and rotate a PGP key on-chain to use for receiving off-chain information transfers.

Background

Hierarchical Deterministic Wallets (HD Wallets) proposed in BIP32 are based on a child key derivation where the parent key can deterministically compute its private and public keys. Each ethereum address of a wallet is a Keccak-256 (also known as SHA-3) hash of the public key. However, it’s impossible to derive the public key the other way around if the address in question hasn’t signed a transaction before.

Accessing the public key of an address is not only hard but inconvenient as well. Libraries at hand require quite a lot of knowledge of cryptography in advance. A simple public key lookup of an address can easily take a day or two for a senior software engineer to implement, especially if no utility tools such as ethereumjs-util are used.

In addition, using the public key of an ethereum address to sign user-supplied data opens up the potential for known-plaintext and chosen-plaintext attacks. Ethereum has no built-in concept of key rotation, as the ethereum address is simply the last 20 bytes of the hash of the public key.

What About ENS?

Ethereum Name Service (ENS) is a well-known approach to get a human-readable way to address resources. We initially looked at using “reverse ENS” to meet our needs.

While it’s possible to register a public key as your address’ .eth domain in ENS, it is not really what ENS is meant for. The DNS properties of ENS make it inconvenient to use as a key rotation system. What if two different addresses want to tie the same key temporarily to their own addresses in the same registry?

Technically the biggest obstacle is that all ENS libraries have the premise that you need to operate your own node. You can’t use ENS’s library support if you want to sign, build and send your transactions with a local private key. This eliminates the convenience of using http providers such as Infura or Quiknode and requires tremendous expertise in web3 to transact with the contract functions directly.

Solution

With our solution every ethereum address can freely store key-value pairs tied only to their address. In HUMAN Protocol this enables efficient use and rotation of encryption keys.

Here’s the brief API description:

set(key, value): You automatically tie the key-value pair directly to your own ethereum address. Anyone can access the pair but only you can alter it.

get(address, key): You can retrieve a previously stored value of any ethereum address with the correct key.

Get Involved

Our implementation of eth-kvstore is currently running on the Ropsten testnet and is soon to be deployed on the mainnet as HUMAN Protocol advances in its roadmap. More information can be found from our GitHub repository. We welcome all contributions and would like to discuss more about the potential use cases of eth-kvstore.

We’re also looking for website owners to implement hCaptcha, an implementation of HUMAN Protocol, on their sites — if you already serve captchas and would like to be compensated for the effort, sign up at hCaptcha.com.