Efficient secure multi-party computation for proof of custody in Ethereum sharding

Abstract

Ethereum, one of the most prominent and widely deployed blockchain systems, is undergoing a significant upgrade that adopts sharding for capacity expansion and secure multi-party computation (MPC) to enable distributed validator technology (DVT). However, it faces a data availability problem, where an adversary can cheat honest-but-lazy validators to propagate invalid blocks, thereby exposing Ethereum Sharding to vulnerabilities. To address this issue, proof of custody (PoC) was proposed. Regrettably, no practically effective MPC protocol is designed to securely and distributively compute PoC. In this paper, we present a concrete and efficient MPC protocol that enables the secure computation of PoC in the dishonest-majority malicious setting. First, we construct an efficient conversion protocol to convert secret sharings in two different prime fields using the doubly authenticated bits (daBits) technique. Second, an efficient MPC protocol is designed to compute scalar multiplication over an elliptic-curve group without requiring MPC to compute branching programs. Furthermore, we employ affine coordinates to compute group operations over an elliptic curve, leading to significant performance boosts compared to other coordinate systems. Finally, a concrete end-to-end implementation of the protocol is built, and its performance is evaluated. When the operations of a validator are collaboratively performed by seven parties, the online (resp., total) running time to generate one proof of custody is 0.02 s (resp., 559.6 s) in LAN and 0.39 s (resp., 7904.2 s) in WAN. The results demonstrate the practicality of the proposed protocol for Ethereum Sharding over a long period of time, such as 73 days.

Appendices

Appendix A A2B protocol

This section discusses the A2B protocol that implements bit decomposition. For $a \in \mathbb {F}_p$, the A2B protocol computes its bitwise sharings $([a_0]_p,\ldots ,[a_{(m-1)}]_p)$ from $[a]_p$, where $a=\sum _{i=0}^{m\!-\! 1} a_i\cdot 2^i$ and $a_i\in \{0,1\}$. We use the bit decomposition protocol proposed in [41], which simplifies the bit decomposition protocol in [19].

According to [19], the A2B protocol involves three high-level sub-protocols: SOLVED-BITS, BIT-ADD, and BIT-LT. SOLVED-BITS is used to generate the sharings of a uniformly random element $b \in \mathbb {F}_p$ and its bits, i.e. $([b_0]_p,\ldots ,[b_{(m-1)}]_p,[b]_p)$. BIT-ADD implements bitwise sum. Given two bitwise sharings $([a_0]_p,\ldots ,[a_{(m-1)}]_p)$, $([b_0]_p,\ldots ,[b_{(m-1)}]_p)$, BIT-ADD computes the bitwise sharing $([d_0]_p,\ldots ,[d_{(m-1)}]_p)$ such that $d=a+b$ over the integers. Given two bitwise sharings $([a_0]_p,\ldots ,[a_{(m-1)}]_p)$, $([b_0]_p,\ldots ,[b_{(m-1)}]_p)$, BIT-LT computes $[a<b]_p$ without revealing $(a<b)$ itself. The A2B protocol in [41] requires one call each of SOLVED-BITS, BIT-ADD, and BIT-LT.

Unlike [41] and [19], we utilize non-constant round protocols to implement the SOLVED-BITS, BIT-ADD, and BIT-LT sub-protocols for lower communication overhead. SOLVED-BITS and BIT-LT call the logarithmic round Prefix-Or protocol [17, 46] and thus require $\log (m)$ rounds and $\frac{m}{2}\log (m)$ invocations of multiplication. Besides, we implement the BIT-ADD according to the formula in work [46], which requires $3m\!-\!2$ rounds and $3m\!-\!2$ invocations of multiplication. Therefore, the A2B protocol used here requires 1 round and m invocations of the RBit command, $3m+2\log (m)-2$ rounds and $3m+m\log (m)-2$ invocations of the Multiply command and 2 rounds and 2 invocations of the Open command.

Appendix B ECC group operations in MPC

1.1 B.1 Addition over ECC group

We describe the addition operation over $\mathcal {G}_2$ as follows.

For $P,Q\in \mathcal {G}_2$, we consider the case of $P\ne \mathcal {O}$, $Q\ne \mathcal {O}$, $P\ne Q$ and $P\ne -Q$. For $P,Q\in \mathcal {G}_2$ with affine coordinate $X_P = (x_{11}+y_{11}i,x_{12}+y_{12}i)$ and $X_Q = (x_{21}+y_{21}i,x_{22}+y_{22}i)$, define the $F^2_{\textsf{add}}(X_P,X_Q) = (x_{31}+y_{31}i, x_{32}+y_{32}i)$, where $(x_{31}+y_{31}i, x_{32}+y_{32}i)$ is the affine coordinate of $P+Q$ and $x_{jk}+y_{jk}i\in \mathbb {F}_{q^2}$, $x_{jk},y_{jk}\in \mathbb {F}_q$ $(j\in \{1,2,3\},k\in \{1,2\})$. The computation formula of point addition over $\mathcal {G}_2$ is as follows.

$$\begin{aligned} x_{31}&=(G^2-H^2)-x_{11}-x_{21} \pmod {q} \\ y_{31}&=2GH-y_{11}-y_{21} \pmod {q} \\ x_{32}&=GI-OH-x_{12} \pmod {q} \\ y_{32}&=GO+IH-y_{12} \pmod {q} \end{aligned}$$

where $G=l(JE-WS),\ H=l(JS+WE), \ l=(E^2+S^2)^{-1},\ J=x_{12}-x_{22},\ W=y_{12}-y_{22},\ E=x_{11}-x_{21},\ S=y_{21}-y_{11},\ I=x_{11}-x_{31},\ O=y_{11}-y_{31}$ and $-1$ represents the inverse of an element over $\mathbb {F}_{q^2}$.

1.2 B.2 Efficiency under different coordinates

We evaluate the efficiency of ECC operation using different coordinates. We focus on the efficiency of point addition and double operations. There are three representations of elements in the group: affine coordinate, projective coordinate, and jacobian coordinate. Figure 14 shows the transformation relationship between these three coordinates.

Fig. 14

The transformation relationship of three coordinates

According to the conversion relationship shown in Fig. 14, the computation formula of point addition and double on $\mathcal {G}_1$ using projective coordinate and jacobian coordinate can be obtained by substituting corresponding values into the formula using affine coordinate. Similar to affine coordinate, the computation formula of point addition and double on $\mathcal {G}_2$ using projective coordinate and jacobian coordinate can be obtained by substituting complex coordinates.

Table 3 describes the cost of each coordinate in the BLS curve groups. From the data in the table, we can know that in the traditional implementation without MPC, projective coordinate or jacobian coordinate are better, because the cost of inversion in $\mathbb {F}_q$ dominates the whole ECC operation. For example, we test the operations in $\mathbb {F}_q$ with GMP library and get that $I \approx 20M$ and $S \approx 0.6M$.

Table 3 The cost of ECC operation in different coordinates

Table 4 The cost of ECC operation under different coordinates in MPC

However, things changed in the MPC setting. One interesting point is that, with secret sharing, one could implement inversion using very few basic operations [1]. A standard way shows that it could be achieved with at most one multiplication and one square, which leads to $I=M+S$. One could also set that $S \approx 0.7M$ (note that we abuse the notation of with or without MPC). Therefore, we can get the comparison results in Table 4. It can be seen that using affine coordinate for point addition on $\mathcal {G}_2$ is about 3.4$\times$ faster than projective coordinate in MPC. Therefore, the affine coordinate is the best choice in the MPC setting.

Appendix C Computation of legendre PRF

Figure 15 shows the computation protocol of Legendre PRF, which directly references the protocol $\Pi _{\textsf{Legendre}}$ in [36]. The correctness and security of protocol $\Pi _{\textsf{Legendre}}$ can refer to [36].

Fig. 15

Protocol $\Pi _{\textsf{Legendre}}$

Appendix D Performance of sub-protocols

Tables 5 and 6 show the time cost of computing elliptic curve multiplication and daBits in LAN and WAN respectively. The bandwidth and latency in the LAN setting are 10 Gbps and 0.045 ms. The bandwidth and latency in the WAN setting are 100 Mbps and 46 ms. In the LAN environment, when the number of parties is 7, the scalar multiplication on $\mathcal {G}_1$ takes 30.303 s, the scalar multiplication on $\mathcal {G}_2$ takes 81.696 s, and the generation of a single daBit takes 0.159 s. In the WAN environment, when the number of parties is 7, the scalar multiplication on $\mathcal {G}_1$ takes 297.527 s, the scalar multiplication on $\mathcal {G}_2$ takes 807.521 s, and the generation of a single daBit takes 3.841 s.

Table 5 The time cost of sub-protocols in LAN (s)

Table 6 The time cost of sub-protocols in WAN (s)