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.
• Geth Light asks Ethereum P2P network for transactions related to interested STRs.
• 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