## 3 Proposed Methodology
### Overview of Proposed System
#### 3.1.2 Computing and Storage of Open-Source Reputation  
The decentralized reputation is a quantitative metric to measure a user's contribution to open source and plays a role in incentives and references. In the OSCMS, voters can refer to it when electing miners, which is mentioned in Section 3.5. Communities or organizations can also refer to it to give developers varying degrees of privilege and reward.  
The reputation indicator \(R_{T}\) is composed of the quantity of OI submitted by the user to the OIChain and the rating of each submitted OI harvested in the CFChain. The specific process is mentioned in Sections 3.2 and 3.3.  
Each time an OI is submitted to an OIChain, the user's development reputation \(R_{dev}\) will increase by 1 point:  
\[R_{dev}=n_{s}\times 1,\quad n_{s}\in N \tag{3}\]  
Figure 4: The process of user authentication in OSCMS.  
Users are allowed to rate a submitted OI in the CFChain, which can be 1 or \(-1\). The initial OI rating \(r_{OI}\) of an OI is 10 points, and \(r_{OI}\) cannot be lower than 1 point. Then, each \(r_{OI}\) is transformed into an OI reputation \(R_{OI}\) by a logarithmic function. Furthermore, all the \(R_{OI}\) are added up to obtain a user's total reputation \(R_{OItot}\) about an OI rating. Such a design encourages developers to submit high-quality OS projects to obtain a higher rating. For example, if an OI obtains 90 \(r_{OI}\) points, it will be equivalent to the reputation of submitting a new OI.  
\[r_{OI}=\begin{cases}10+\sum_{0}^{n_{p}}1-\sum_{0}^{n_{n}}1&,\quad(10+\sum_{0}^{ n_{p}}1-\sum_{0}^{n_{n}}1)\geqslant 0\\ 1&,\quad(10+\sum_{0}^{n_{p}}1-\sum_{0}^{n_{n}}1)<1\end{cases},\quad n_{p}\in N,n _{n}\in N \tag{4}\]  
\[R_{OI}=log_{10}^{r_{OI}}-1 \tag{5}\]  
\[R_{OItot}=\sum_{0}^{n_{s}}R_{OI},\quad n_{s}\in N \tag{6}\]  
\[R_{T}=R_{dev}+R_{OItot} \tag{7}\]  
where \(n_{s}\) is the quantity of the OI submitted by the user, and \(n_{p}\) and \(n_{n}\) are the positive and negative ratings of an OI, respectively.  
It is necessary to effectively limit the low-cost growth of reputation. Firstly, the OSCMS requires that only the developer can submit the OI of a project stored in the corresponding community, and the same OI cannot be submitted repeatedly. If the project is copied from others or the quality is low, it has a high probability of having a lower rating in the CFChain, offsetting the reputation of submitting the OI. Secondly, one user can rate an OI at most once, and unidentified users cannot rate it. Since a community account can only be bound once in the OSCMS, only by authenticating more community accounts can an OI be rated multiple times, but this process has costs. In the future, it will be possible to detect similar code or low-quality code through enhanced technology. Due to the inherent characteristics of open source, it is recommended to combine the transformed reputation with other factors for reference, such as democratic elections.  
After collection, verification and transformation through related smart contracts and blockchain system codes in the OIChain and CFChain, respectively, the reputation is stored in the form of a Merkle Patricia tree (MPT). The MPT combines the advantages of a Merkle tree and a prefix tree and can compress and store key-value pair data of any length, quickly calculate the hash of the maintained dataset, provide fast state rollback and provide Merkle proof to simply verify data.  
The structure of reputation MPT is shown in Figure 5. The key-value pair is \(\langle Pu_{k}\), \( reputation\rangle\). The time complexity of retrieving, inserting and modifying MPT is \(O(\log(n))\).