# Ring-Overlap: A Storage Scaling Mechanism for Hyperledger Fabric
## 5 Scheme Analysis
### Security Analysis  
#### 5.2.1 System Reliability  
According to the above analysis, it is clear that the smaller the number \(s\) is in the cluster, the less storage space is occupied by a single node. However, the smaller the \(s\), the lower the reliability of the system, and the failure of a small number of nodes can result in partial data loss in the blockchain, preventing the ledger from being recovered. Therefore, the size of \(s\) is related to the reliability requirements of the system. A larger value of \(s\) is required if the system allows more nodes to fail.  
In the new proposed scheme, the number of nodes in a single cluster is \(n\), and \(1/m\) of the total block data is to be stored. Each block in the cluster is stored repeatedly on \(s\) nodes, which means the overall data are the cluster is divided into \(n\) parts, and each node stores \(s\) part. To simplify the description, only the results after the first round of storage is discussed, and the first \(n\) blocked IDs stored in a cluster are normalized to \(1,2\ldots,n-1,n\). According to the storage rules of the scheme, these \(n\) data can be sequentially arranged as a ring \(R\), \(1{\rightarrow}2\), \(2{\rightarrow}3\), \(\ldots,n-1{\rightarrow}n\), \(n{\rightarrow}1\). Each node in the cluster stores \(s\) consecutive blocks with different starting block ID on \(R\).  
The shard IDs of each node in a cluster are different combinations of \(s\) consecutive IDs selected from \(1\) to \(n\). Any two combinations have at least one element different and at most \(s-1\) elements different, and each combination is only \(n-s\) elements away from completing the entire set of numbers.  
In a cluster, the reliability of the system can be understood as the number of nodes allowed to fail without causing data loss; in other words, the data stored in \(r\) nodes, which are chosen from \(n\) nodes arbitrarily, could cover all blocks. We want to obtain the minimum value of \(r\) taken for a particular \(n\).  
Worst case: among the selected \(r\) nodes, any node \(\alpha\) is selected, there exists another node \(\beta\), and they exist \(s-1\) identical elements. In this case, \(n-(s-1)\) nodes are needed to obtain all the block data. Therefore, if \(n\) nodes, each node stores \(s\) shard according to the rules of this scheme, at most \(s-1\) nodes can be allowed to fail.  
It is known that the system reliability is related to \(s\) when \(n\) is a fixed value. When \(s=1\), each block exists in only one node, and the failure of any node will lead to an unrecoverable blockchain; when \(s=n\), the storage in the cluster degenerates to the Hyperledger Fabric native way, and the full block data can be recovered even if only one node survives.  
Since the underlying design used in this scheme is still the traditional P2P design model, its system reliability can be expressed by Equation (2).  
\[q=\sum_{k=1}^{s-1}C_{n}^{k}\lambda^{n-k}(1-\lambda)^{k} \tag{2}\]  
In Equation (2), \(q\) denotes the system reliability, \(\lambda\) denotes the reliability of a single node, \(s\) denotes the number of single block storage copies within a single cluster, \(n\) denotes the number of nodes within a single cluster, and \(k\) denotes the number of failed nodes. When \(\lambda\) is determined, the system reliability \(q\) corresponding to different values of \(s\) can be found by Equation (2).