*3.2. Vector Commitment*

For a given element e and a sequence number *i*, VC [19] can be used to identify whether *e* is equal to the *i*th element of an ordered set **e** (*<sup>e</sup>*1, ...*en*). In blockchain systems, the transactions in a block form an ordered set of elements, thus VC can be used to identify whether a given transaction is in a block and its position is also correctly provided. VC demonstrates the features of hiding, position binding, conciseness and an ability to be updated. The following six algorithms are used to define VC:

1. Given security parameter *k* and the size *n* of ordered set **e**, the "*KeyGen*" algorithm outputs the public parameters *pp*.

$$pp \leftarrow \mathit{KeyGen}(1^k, n) \tag{1}$$

2. Given the public parameters pp and the ordered set **e**, the "Commitment" algorithm outputs the commitment **C** of **e**.

$$\mathbf{C} \leftarrow \textit{Commitment}\_{PP}(\mathfrak{e}\_1, \dots, \mathfrak{e}\_{\mathcal{U}}) \tag{2}$$

3. The "Open" algorithm is used to generate the proof *πi* for the *i*th element.

$$
\pi\_i \leftarrow \mathcal{Open}\_{pp}(i, e\_1, \dots, e\_n) \tag{3}
$$

4. The "Verify" algorithm is employed to check whether the given element e is equal to *ei* through the proof *πi*. If the proof is accepted, the algorithm outputs 1.

$$\{0, 1\} \leftarrow Verify\_{pp}(\mathbf{C}, i, e, \pi\_i) \tag{4}$$

5. When the *i*th element of **e** needs to be updated with *e* , the "Update" algorithm can be run to output a new commitment *C-* and the update information U.

$$\mathbf{C}', \mathsf{U} \leftarrow \mathsf{U} \\ \mathsf{P} \\ \mathsf{d} \\ \mathsf{e}\_{pp}(\mathbf{C}, \mathsf{e}, \mathsf{e}', \mathsf{i}) \tag{5}$$

6. When the *i*th element of **e** is updated, the proofs of other elements (e.g., *ej*) also need to be updated. The algorithm "ProofUpdate" outputs the updated proof *π- j* of element *ej*.

$$
\pi\_j' \leftarrow \operatorname{Proof} \mathcal{U} \mathcal{I} \mathit{p} \mathit{data}\_{pp}(\pi\_{j'}e', i, \mathcal{U}) \tag{6}
$$

### **4. SASLedger: A Secured, Accelerated Scalable Storage Solution**

To relieve the storage burden for blockchain nodes, we focus on reducing the size of the chain of blocks since it alone is responsible for most of the storage burden of a blockchain node. Figure 2 shows the system architecture of our solution. An off-chain solution within each CU is used to achieve lower network overhead compared to on-chain solutions or solutions without adopting CU [13] or solutions without adopting CU [10–13]:an off-chain remote DB server for each CU is added to store the blocks; VC is used to ensure the integrity of each transaction in a block stored in the remote DB server. Although the blocks are stored in the remote DB server, the nodes still maintain their local databases respectively and still be able to check the data integrity of the blocks that they transmit to the remote DB server, thus the decentralized character and tamper-proof character of blockchain system are retained.

**Figure 2.** System architecture of our solution. The entire blockchain network is divided into multiple Consensus Unit (CU), in which nodes combine their resources to maintain the blockchain data together.

### *4.1. Proving Data Integrity through VC*

To prove the integrity of the data in a block, Jidar [13] attaches a proof for each transaction, which requires extra storage space and generates significant network overhead. Compared to Jidar, in our solution, nodes only store a concise VC of a block, the proof for a transaction is generated and provided by the remote DB server only when the transaction is requested.

A Merkle tree [43] is used to generate VC for the set of transactions in a block and proofs for the transactions. As shown in Figure 3, the hashes of the transactions in a block (*tx*1, ... , *txn*) form the leaf nodes of the Merkle tree, the root of the Merkle tree is considered to be VC ( **C**) of the block (7). When the proof of the *i*th transaction *txi* is requested, the list

which includes adjacent sibling nodes of the corresponding leaf and its ancestor nodes is returned as the proof *π* (8), in Figure 3, the list [*Hash*3, *Hash*12, *Hash*5678] (shown in yellow) is the proof of transaction *tx*4.

**Figure 3.** Merkle tree-based vector commitment. The hashes of the transactions in a block (*tx*1, ... , *txn*) form the leaf nodes of the Merkle tree, the root of the Merkle tree is considered to be VC of the block. The list [*Hash*3, *Hash*12, *Hash*5678] (shown in yellow) is the proof of transaction *tx*4.

When a transaction is requested, the transaction is retrieved from the remote DB server with its proof and verified by calculating the Merkle tree root using the received proof and comparing the root with the previously stored commitment (9). If the root equals the VC, the node can believe that the transaction has not been subject to tampering on the remote DB server. In the case of a block being requested, the node retrieves the block from the remote DB server and validates its integrity by calculating its hash and comparing it with the previously stored hash of the block. The size of a VC is 32 B when SHA256 is used as the hash calculating algorithm while the size of a block with default settings containing 10 transactions is 34 KB [20]. Since the size of a VC is much less than the size of a block, storing its VC instead of the original block can save much storage space.

$$\mathbf{C} \leftarrow \textit{Commitment} \left(\texttt{tx}\_{1}, \dots, \texttt{tx}\_{n}\right) \tag{7}$$

$$\mathbf{x} \leftarrow \text{Open}(\mathbf{i}, \mathbf{t}\mathbf{x}\_1, \dots, \mathbf{t}\mathbf{x}\_n) \tag{8}$$

$$\{0, 1\} \leftarrow Verify(\mathbf{C}, i, \text{tx}, \pi) \tag{9}$$

Since the transactions in a block are fixed, the "Update" and "ProofUpdate" algorithms in conventional VC definition are not applicable. The "KeyGen" algorithm is unnecessary neither since there are no other public parameters to be generated. The algorithms are shown in detail with Algorithms A1–A4 in Appendix A.
