Moderated Redactable Blockchains: A Definitional Framework with an Efficient Construct

Abstract

Blockchain is a multiparty protocol to reach agreement on the order of events, and to record them consistently and immutably without centralized trust. In some cases, however, the blockchain can benefit from some controlled mutability. Examples include removing private information or unlawful content, and correcting protocol vulnerabilities which would otherwise require a hard fork. Two approaches to control the mutability are: moderation, where one or more designated administrators can use their private keys to approve a redaction, and voting, where miners can vote to endorse a suggested redaction. In this paper, we first present several attacks against existing redactable blockchain solutions. Next, we provide a definitional framework for moderated redactable blockchains. Finally, we propose a provable and efficient construct, which applies a single digital signature per redaction, achieving a much simpler and secure result compared to the prior art in the moderated setting.

A An Incorrect and Insecure Construct

In this appendix, we present a construct that is both incorrect and insecure, but helps in understanding the way our definitional framework works. Normal blocks do not include any information about each other (such as the hash of the previous block). Such information, necessary for the secure operation of an ordinary blockchain, is abstracted via the ideal functionality in the model: The adversary is not allowed to make any direct writes to the ledger, and therefore the challenger can keep the ledger blocks in their total order. The redactability is achieved with a signature scheme strongly unforgeable under adaptive chosen-message attack (sUF-CMA), denoted $({{\,\mathrm{\mathsf {GenSig}}\,}}, {{\,\mathrm{\mathsf {Sign}}\,}}, {{\,\mathrm{\mathsf {VerifySig}}\,}})$: The challenger installs a redacted block only if its witness holds the signature of itself and the next block. The reversion attack (Sect. 4) is prevented by introducing version numbers in the block structure: Initially, each block carries version 1. Upon each redaction, the version number is incremented. The verification function of the blockchain checks whether the version of a redacted block is strictly greater than the version of the block being replaced. This way, the adversary cannot reinstall a previously valid block again.

Construction 2 (Insecure and Incorrect)

The redactable blockchain $\mathcal {RBC}_\mathrm {bad}$ is defined as follows. The block structure is $B \overset{\mathrm {\scriptscriptstyle def}}{=}(C, V, W)$, where each block contains content C, version V, and witness W.

• ${{\,\mathrm{\mathsf {Gen}}\,}}(1^\lambda )$ simply calls the generator for the underlying signature scheme to obtain the public and private keys: $(pk, sk) \leftarrow {{\,\mathrm{\mathsf {GenSig}}\,}}(1^\lambda )$. It sets $\mathcal {L}\leftarrow [B_0]$, where $B_0 \leftarrow (\varepsilon , 1, \varepsilon )$.

• ${{\,\mathrm{\mathsf {Create}}\,}}(pk, \mathcal {L}, C)$ returns $B \leftarrow (C, 1, \varepsilon )$.

• ${{\,\mathrm{\mathsf {Verify}}\,}}(pk, \mathcal {L}, i, B)$ returns 1 if and only if all of the following conditions hold:

  • $\bullet$ B has correct structure, and $i \le \ell + 1$ is a positive integer.

  • $\bullet$ $\mathrm {\Phi }(\mathbf {V}, i, V)$ returns 1: This happens if and only if $(i=\ell +1) \wedge (V=1)$ (the block is being appended and has version 1), or $(i\le \ell ) \wedge (\mathbf {V}[i] < V)$ (an existing block is being redacted, and the new version is greater than the existing one to foil reversion attacks).

  • $\bullet$ $\mathrm {\Psi }(pk, \mathcal {L}^*)$ returns 1: This happens if and only if for every pair $(B,B')$ of subsequent blocks in $\mathcal {L}^*$, if ${{\,\mathrm{\mathsf {Version}}\,}}(B) > 1$ (i.e., if B is redacted), then

    

    (7)

    where $W \overset{\mathrm {\scriptscriptstyle def}}{=}{{\,\mathrm{\mathsf {Witness}}\,}}(B)$, and (i.e., block B except W). Put simply, this means that W is a valid signature on $C \mathbin {||}V \mathbin {||}C' \mathbin {||}V' \mathbin {||}W'$.

• ${{\,\mathrm{\mathsf {Redact}}\,}}(sk, \mathcal {L}, i, C)$: Creates $B \leftarrow (C, V, W)$ using content C, where $V \leftarrow {{\,\mathrm{\mathsf {Version}}\,}}(\mathcal {L}[i]) + 1$ and W is a signature on the current block except W itself (denoted ), as well as the next block $\mathcal {L}[i+1]$:

  

  Notice that incrementing the version number, as well as the computation of witness by signing the current and next blocks, are consistent with the requirements of ${{\,\mathrm{\mathsf {Verify}}\,}}$.

• ${{\,\mathrm{\mathsf {Install}}\,}}(pk, \mathcal {L}, i, B)$: Works exactly as specified in Definition 3.

Correctness Issues. A series of valid actions can put the ledger in a state that block creation for appending is no longer possible, violating the first requirement of Definition 4. For instance, let $C_1$, $C_1'$ and $C_2$ be any valid contents, and consider the following actions, following $(pk, sk, \mathcal {L}) \leftarrow {{\,\mathrm{\mathsf {Gen}}\,}}(1^\lambda )$:

The first line creates and appends a block, the second line redacts it, and the third line tries to append a new block. The last ${{\,\mathrm{\mathsf {Install}}\,}}$ fails as it calls ${{\,\mathrm{\mathsf {Verify}}\,}}$, which in turn calls $\mathrm {\Psi }$: Since the version of $B_1'$ is greater than 1, $\mathrm {\Psi }$ requires it to hold a signature containing information about the next block, as per Eq. (7), which is not the case.

The underlying reason is that, in this particular construct, it is meaningless for the last block of the ledger to be redacted, as there is no next block to sign. It is possible not to increase version number for redacting the last block, or disallow such redaction by requiring $i \ne \ell$ in designing ${{\,\mathrm{\mathsf {Redact}}\,}}$.

One can violate the second requirement of Definition 4 as well, by following a series of valid actions that put the ledger in a state where redaction of some blocks are impossible. Let $\mathcal {L}\leftarrow [B_0, B_1, B_2, B_3]$ be a ledger constructed by appending three blocks, and $C_1'$ and $C'_2$ be valid contents. Consider the following actions:

Again, the last install fails: For the pair $(B_1', B_2')$, algorithm $\mathrm {\Psi }$ requires $B_1'$ to hold a signature on (see Eq. (7)). However, $B_1'$ is redacted prior to $B_2'$: As a result, $B_1'$ holds a signature on , which becomes invalid after $B_2$ is redacted. Consequently, the second requirement of Definition 4 is violated.

The underlying reason is the indifference in the verification algorithms as to which block is newer. The next section shows how using unique versions can resolve this issue.

Security Issues. On the surface, it seems that the adversary cannot succeed in Experiment 2. An informal (and false) argument is as follows: We use an adversary who succeeds in the game as a subroutine, to forge a valid signature on an arbitrary message. The forger simulates the challenger. It gives the public key of the signature scheme to the adversary, and answers all redaction queries by using the signing oracle. When the adversary outputs a successful redaction (i, B), the witness W is a valid signature on the message . The forger outputs (m, W) as a valid message-signature pair.

The fallacy in the above argument is that the forger must output a new pair (m, W), as required by sUF-CMA signature forgery. However, the informal proof does not show that this pair is new. In fact, as is explained below, it is easy for an adversary to succeed in the game without forging any signature.

Adversary $\mathcal {A}$ proceeds as follows: It creates a block $B \leftarrow (\texttt {"original"}, 1, \varepsilon )$, and appends it three times by calling the ${{\,\mathrm{\mathtt {INST}}\,}}$ interface of the challenger on queries (1, B), (2, B) and (3, B), respectively. At this point, $\mathcal {L}= [B_0, B, B, B]$.

Next, $\mathcal {A}$ queries the ${{\,\mathrm{\mathtt {REDC}}\,}}$ interface of the challenger on $(1, \texttt {"modified"})$, and receives $B' \leftarrow (\texttt {"modified"}, 2, W)$, where W is a signature on , where is $\texttt {"modified"} \mathbin {||}2$.

While the redaction was requested for position 1, the adversary uses position 2: She outputs $(2, B')$, and halts.

At this point, ${{\,\mathrm{\mathsf {Hist}}\,}}= \{ (1,B') \}$, and therefore $(2, B')$ is new. Furthermore, $B'$ is a valid redaction for position 2, since $\mathcal {L}[3] = \mathcal {L}[2] = B$. We conclude that the adversary breaks the security by outputting a successful reduction, without forging a new signature. The underlying reason for this attack is duplicate blocks in the ledger. Construct 1 in Sect. 6 resolved this issue by incorporating unique versioning.