Reactive Key-Loss Protection in Blockchains

Abstract

We present a novel approach for blockchain asset owners to reclaim their funds in case of accidental private-key loss or transfer to a mistyped address. Our solution can be deployed upon failure or absence of proactively implemented backup mechanisms, such as secret sharing and cold storage. The main advantages against previous proposals is it does not require any prior action from users and works with both single-key and multi-sig accounts. We achieve this by a 3-phase $Commit() \rightarrow Reveal() \rightarrow Claim() - or - Challenge()$ smart contract that enables accessing funds of addresses for which the spending key is not available. We provide an analysis of the threat and incentive models and formalize the concept of reactive KEy-Loss Protection (KELP).

P. Chatzigiannis—Did part of this work during an internship at Novi Financial/Facebook Research.

A KELP Implementation in Diem Blockchain

In this appendix, we present an implementation of the KELP protocol for the Diem Framework v1.2. The code is mostly a straightforward, but has a few Diem-specific features that we will explain here:

Automatic Challenges Using Sequence Numbers. Like many other blockchains, Diem accounts have sequence numbers that are incremented each time a transaction is sent from the account. Our implementation timestamps each reveal on $address_c$ with the sequence number of $address_c$. In the code for , we check that no transactions have been sent from $address_c$ since the reveal. This ensures that any transaction sent from $address_c$ is implicitly a challenge.

Reclaiming Entire Accounts with . Diem accounts support key rotation. Each account has a unique resource whose holder has the permission to rotate the authentication key for . An account that opts in to KELP recovery must give its to the KELP resource. KELP then uses this resource to rotate the key for in the logic for . This allows the claiming party to completely regain control of the account, not just its funds.

Using the Type To Avoid Some Uses of $address_r$. The Move language has a type called ³ that represents an authenticated user with a specific address. Our implementation leverages this type to omit some uses of $address_r$ from the protocol. For example: we don’t need to include $address_r$ in the $\mathsf {Commit}$ message because we use to ensure that a commit and reveal transaction originate from the same address.