Blockchain as auditors

Follow our discussion at issue-151.

CONIKS requires an auditing protocol to detect server's equivocation. CONIKS servers broadcast STRs to auditors to validate the hash chain while clients ensure the STRs consistency by querying those auditors. To prevent a malicious server colluding with auditors, the client needs to query STRs from multiple auditors. Thus, we need to maintain a network of auditors who continuously validate every server's STRs and answer query from clients.

We propose an alternative approach to auditing CONIKS's server by using Ethereum.

#Architecture

EthIKS proposed implementing CONIKS server as an Ethereum smart contract. If we consider Ethereum blockchain as an immutable log, there is no need for auditing protocol since the malicious server cannot equivocate transactions in the blockchain log.

However, we think that maintaining the whole CONIKS server inside the blockchain is very costly. It also makes the system depends too much on Ethereum (what if Ethereum collapses in the future).

Instead, we think publishing only the STR to the blockchain is enough for the auditing purpose. Thus, a CONIKS server architecture now becomes

Where

• Geth is the official Ethereum wallet written in GO
• STR is the CONIKS server's Signed Tree Root
• Smart Contract is the code that stores all server's STRs while allows CONIKS clients to efficiently lookup only the STRs they are interested in.

Thus, the client architecture is as follow:

• Where Geth Light is Geth running in light client mode, which only download Ethereum block headers instead of the whole blockchain.
• Unlike full client, Geth Light client does not download the whole blockchain asks Ethereum P2P network for transactions related to interested STRs. The light client downloads only block headers (~ per block)
• CONIKS client monitors users' keys by querying CONIKS server then cross checking with Geth Light.

#Security We want to make sure the blockchain scheme offers no less security than the original proposal where CONIKS client queries STRs from multiple auditors.

CONIKS server publishes its STR by executing the smart contract function, creating a transaction and sending to the Ethereum P2P network (via Geth). The transaction is confirmed by miners running POW algorithm on a given block Difficulty where:

• Block Difficulty is calculated purely on timestamp and Difficulty of parent's block.
• Miners run Proof-of-work function to confirm the transaction. In short, the function works as follow:
  1. There is a seed for each block. The first is the hash of a series of 32 bytes of zero. Each block seed is the hash of the previous block seed.
  2. Each client computes a small pseudo-random cache from the (~ 16MB)
  3. Miner generates a large (around 1GB) dataset from the cache. Each slice (64 bytes) of the dataset is generated from pseudo-randomly selected cache nodes.
  4. Miner calculates a block header hash which contains all metadata of a block (difficulty, transactions, etc.). The miner then chooses a random 8 bytes nonce and mixes together with the block header hash and a random slices of the dataset. The process repeats with different nonces until the output is smaller than a target which is inversely proportional to the block difficulty. The first miner who finds the nonce will includes it into the block and broadcast to the whole Ethereum network.
  5. Other miners validate the broadcast block by calculating the POW output against the difficulty in the header. If the block is valid, these miners move on to the next block.
  6. Light client does not generate the dataset, instead, the light client takes the nonce from the header, calculates the corresponding dataset slice from the cache and validates the output with the difficulty target.

Ethereum client will switch to whichever chain which has the same genesis block with it and has the highest total difficulty (accumulated from the genesis to the newest block). The motive is that the higher total difficulty the chain has (longer), the more computational power (to find the nonce) the whole network has to spent and therefore it is less likely the block can be revoked.

Ethereum light client does not download the whole blockchain and transactions.