├── .gitignore
├── BET
├── BET_DPOS_Borda_Count_Voting_Plan.md
└── BET_DPOS波达计数法投票方案.md
├── BOSCoreTechnicalWhitePaper.md
├── BOSCoreTechnicalWhitePaper.pdf
├── BOSCoreTechnicalWhitePaper_zh.md
├── BOSCoreTechnicalWhitePaper_zh.pdf
├── IBC
├── EOSIO_IBC_Priciple_and_Design.md
└── EOSIO_IBC_Priciple_and_Design_zh.md
├── LIB
├── Algorithm_for_improving_EOSIO_consensus_speed_based_on_Batch-PBFT.md
├── BOS_Batch_PBFT_I.md
├── BOS_Batch_PBFT_II.md
├── images
│ ├── BOS_LIB_Acceleration_PART_I
│ │ ├── benchmark_chart.png
│ │ ├── benchmark_example.jpeg
│ │ ├── stats_formular1.jpg
│ │ ├── stats_formular2.png
│ │ └── stats_formular3.png
│ └── BOS_LIB_Acceleration_PART_II
│ │ └── lib_upgrade.jpg
└── 基于PBFT提升EOSIO共识速度的算法.md
├── Oracle
├── BOS_Oracle_Deployment.md
├── BOS_Oracle_Introduction.md
├── BOS_Oracle_入门.md
├── BOS_Oracle_部署文档.md
└── README.md
├── README.md
├── Referendum_WPS
├── BOS Ecosystem Program(Referendum & WPS).md
└── BOS生态基金方案(含公投&WPS).md
└── imgs
├── BOS_Referendum.png
├── BOS_Referendum_CN.png
├── bospbft.png
├── dops_borad_count_math01.png
├── dops_borad_count_math02.png
├── dops_borad_count_math03.png
├── dops_borad_count_math04.png
├── dops_borad_count_math05.png
├── dops_borad_count_math06.png
├── dops_borad_count_math07.png
├── dops_borad_count_math08.png
├── dops_borad_count_math09.png
├── dops_borad_count_math10.png
├── flow_cn.png
├── flow_en.png
├── oralce
├── bosoracle_df_listen_offchain.png
├── bosoracle_df_listen_table.jpg
├── bosoracle_df_offchain1.jpg
├── bosoracle_df_offchain2.jpg
├── bosoracle_df_offchain_detail.png
├── bosoracle_df_table.jpg
├── bosoracle_game_model.png
├── bosoracle_risk_control.png
└── bosoracle_structure.png
└── scale
├── blockstructure.png
├── networktopology.png
└── productverify.png
/.gitignore:
--------------------------------------------------------------------------------
1 | .idea
--------------------------------------------------------------------------------
/BET/BET_DPOS_Borda_Count_Voting_Plan.md:
--------------------------------------------------------------------------------
1 | ## I. Preface:
2 |
3 | Since Daniel Larimer introduced DPoS into EOS, how to better select Block Producers has become the focus of much community debate. In this regard, BOS follows EOS voting mechanism. That is, a one-vote multi-selection (maximum 30 voters) mechanism, but due to the existence of Pareto's law, the voting tends to be concentrated in the hands of a few people, also a one-vote multi-selection mechanism allows token holders to trade votes, which can ultimately lead to the Block Producer rankings being controlled, thereby causing an imbalance in the decentralization of the system, and further leading to an increased gap between the ranks. To this end, in the design of the bet voting system, we try to introduce an improved Borda voting mechanism to alleviate this problem, in order to find a more reasonable means to make a corresponding contribution in ensuring system security and fairness.
4 |
5 | To this end, in the design of the BET voting system, we aim to introduce an improved Borda voting mechanism[^1] to alleviate this problem in order to find a more reasonable means to make a corresponding contribution in ensuring system security and widespread distribution; which ultimately leads to a better and more inclusive distribution of WPS funds.
6 |
7 | ## II. Proof of Stake mechanism and Voting:
8 |
9 | There are many articles about the Proof of Stake mechanism. There is no more detailed discussion here. Only the discussion of Block Producer concentration and security is discussed. For the sake of discussion, we simplify the above.
10 |
11 | 1. We assume that all voting rights are from voters
12 | 2. We simplify the original model as a probability discovery model
13 |
14 | Let‘s make the following assumptions:
15 |
16 | * Token holder's shareholding ratio is Q,
17 | * Secret cheating function H
18 | * Cheating is found after loss function F(Q), maintaining system stability.
19 | * The general return function is X(Q)
20 | * The cheating gain is W
21 |
22 | *Attention:The hypothetical function here is only used for qualitative analysis*
23 |
24 | Ao we can simply get the strategic relationship of the stakeholder:
25 |
26 | Judging the relationship between W+(H-1)*F(Q) and X(Q) and determining the corresponding strategy.
27 |
28 | Because F is a positive correlation function of Q, X is also a positive correlation function of Q, and W is a random parameter with speculation. So it can be concluded that the cheating gain will be significantly reduced with the increase of Q, under the assumption of rational natural person. Choosing to maintain fairness is a dominant strategy. So from this perspective, the POS mechanism is a stable model.
29 |
30 | In fact, when we further analyze the ethical parameters, we can obtain the following relationships and conclusions between the equity structure and the stakeholders' income:
31 |
32 | A) Absolute concentration structure of equity
33 |
34 | If the equity is absolutely concentrated on the network operators, the supervision will be difficult, and the moral value of the network operators will decrease or even become negative.
35 | Operator Responsibility(→min)=Operator Morality(→-)×{1+ Operator Asset Ownership(max)}
36 | Stakeholders' Income(→min)=Operator's Responsibility(→min)×Operator's Ability×Operating Conditions.
37 |
38 | B) Relatively concentrated structure of equity
39 |
40 | The relative concentration of equity can encourage operators, stabilize the backbone team, and generate checks and balances.
41 | Operator Responsibility(→max)=Operator Ethics(→max)×{1+ Operator Asset Ownership(max)}
42 | Stakeholders' Income(→max)=Operator's Responsibility(→max)×Operator's Ability×Operating Conditions.
43 |
44 | C) Equity dispersion structure
45 |
46 | The equity is too scattered, the supervisory motivation is insufficient, and the moral value of the network operators will decrease or even become negative.
47 | Operator Responsibility(→min)=Operator Ethics(→-)×{1+ Operator Asset Ownership(min)}
48 | Stakeholders' Income(→min)=Operator's Responsibility(→min)×Operator's Ability×Operating Conditions.
49 |
50 | From the analysis, we can determine that (B) relative concentration of equity is the preferred equity structure (for detailed knowledge, please refer to the books and papers related to equity structure).
51 |
52 |
53 | Therefore, we can avoid the concentration of large stakeholders taking control by adopting a method of concentration relative to staked weight, on the premise of the stability of the system. So the question remains: is there an ideal voting solution?
54 |
55 | ## Voting and election
56 |
57 | Before discussing this issue in detail, let's try to define the problem:
58 |
59 | We assume that there are N people participating in the election, there are a total of K people to vote,
60 | and there is an arrangement in the satisfaction of each voter in the hearts of the candidates.
61 | Our aim is to develop an election plan that will eventually be "fair" for everyone.
62 | The sequence of voting results.
63 |
64 | So what is fair? Here we use the five rules of Arrow[^2]:
65 |
66 | 1. Every voter has the same influence; further, it is non-authoritarian.
67 | 2. In addition to being unreasonable, voters have no other restrictions on the ordering of their minds.
68 | 3. If all voters think A > B, the election result will also show A > B.
69 | 4. The ranking of the election results for A and B should be determined only by the relative order of A and B within the file, regardless of any third party.
70 | 5. If all voters are rationally sorting the choices and voting honestly, the results of the elections should also show a rational order.
71 |
72 | But unfortunately there are a variety of proof methods[^3][^4][^5] to prove that such "justice" does not exist, which is also the content of the Arrow impossible theorem. Since our system will be modified based on the Borda system, here we give proof of the theorem in the Borda case:
73 |
74 | Let a given k integers m1, m2, ..., mk, let σ(1,2,...,n) be a permutation group of (1,2,...,n), and define the following mapping:
75 |
76 | 
77 |
78 | For any set of numbers t1>t2>...>tn, use the above k permutations to make an n×k matrix:
79 |
80 | 
81 |
82 | Define n numbers in turn:
83 |
84 | 
85 |
86 | Then there are:
87 |
88 | 
89 |
90 | We know that we can find n sets of numbers for the above equation.
91 |
92 | 
93 |
94 | Corresponding
95 |
96 | 
97 |
98 | Satisfy:
99 |
100 | 
101 |
102 | In other words, the Borda Count method is also unstable. So where is the problem? In fact, our assumptions constraints such fairness.
103 |
104 | In his paper, scholar Saari elaborated on the above issues. One of Saari's arguments is that articles 4 and 5 of Arrow's conditions are “offset” with each other, so they have carried out the fourth rule. The amendment is as follows:
105 |
106 | 4'. Election results The ranking of A and B should be determined only by the relative order and distance of A and B in the file, regardless of any third party.
107 |
108 | So under this assumption, Saari proves that:
109 |
110 | the Borda Count election process is "fair" on the premise of more than two candidates!
111 |
112 | For specific technical details, please refer to [Saari's related papers](https://en.wikipedia.org/wiki/Donald_G._Saari#Papers). In other words, the Borda Count election process is better in this sense. Therefore, we try to adapt the BET voting system with the DPOS system under this conclusion.
113 |
114 | ## III.BET voting system.
115 |
116 | Next we will give a general description of the voting system:
117 |
118 | It is assumed that the number of people participating in the election is N, K people vote.
119 |
120 | Our voting rules are as follows:
121 |
122 | 1. For any voter, it is required to give a sequence Ln of the order in which the candidates fit or not.
123 | 2. The voter's voting weight is recorded as the number of tokens held and mortgaged by Pi.
124 | 3. Given a function F(i), the function returns a score for the different sequence numbers of the sequence. The specific function will be given below.
125 | 4. The rules for scoring any candidate are as follows:
126 |
127 | Vk = ∑ F(i,j)*Pi
128 |
129 | 5. Sort all candidates who participated in the election and draw the final selection sequence.
130 |
131 | BET will adapt the following F function:
132 |
133 | F(i) = (N+1-i)/N
134 |
135 | Proof:
136 |
137 | > Suppose that any voter holds the number of Tokens in his hand, that is, the number of votes, and only one vote at a time.
138 | > We limit each voter, assuming that any voter can vote for the number of votes held in their hands, that is, Pi, and only one vote at a time, so we can treat **each voter as a collection of voters** with the same willingness to vote, each with only one vote, further seeing this becomes a model for the Borda count to vote for the Borda count.
139 | > So it has the same theoretical characteristics as the Borda count system.
140 |
141 | Further, for any ticket holder Pi, since he needs to vote (sort) all candidates, that is, he contributes to any candidate, but the degree of contribution is according to function F. To do this, that is to say, set Pi>Pj and F(k)l, then there are:
142 |
143 |
144 | Pi/Pj > (∑F(i) * Pi)/(∑F(j) * Pj)
145 |
146 |
147 | Among them, i, j are ranked in the disadvantage position of the other party's sequence, so the comparison of one vote and more investment scheme obviously weakens the role of the ticket.
148 |
149 | The following is a comparison of the control function with one vote and multiple casts under different F functions.
150 |
151 | > The area below the line is the maximum vote for a voter voter
152 |
153 | 
154 |
155 | > The area below the line is the maximum vote when F is the Borda count system.
156 |
157 | 
158 |
159 | > The maximum area below the line is the voting maximum when F is X^(-σ)
160 |
161 | 
162 |
163 | Although not rigorous, you can intuitively feel the difference between them.
164 |
165 | Next, we will illustrate the features and advantages of the program through a few simple examples:
166 |
167 | ### Example One
168 | Suppose there are three voters A, B, and C. For the sake of discussion, let's assume that the candidates are the same three, and assume that they vote for themselves. Our voting principle is to choose two of the three to win.
169 |
170 | We assume that A, B, and C hold the number of tokens at, bt, and ct, respectively. If we assume conspiracy in A and B, if EOS's current voting system is adopted, C will lose the final right as long as `at+bt>ct`. But under the BET system, you need `at+2bt>2ct` (assume at>bt) to get the corresponding result. In the case where the differences among the candidates are not different, A and C can be elected.
171 |
172 | ### Example Two
173 | Consider another example of bribery. Let's assume that there is a large account A with 20M tokens. The support of other candidates is only between 1M and 6M. If the EOS strategy is adopted, then the other candidates cannot reach consesus. Under the premise, A can control the entire order of the elected person. Due to the strong control of A, many candidates will choose to trade with A, which will eventually lead to the further strengthening of A's control.
174 |
175 | But for the BET system, the situation will be different. For example, we use `(n+1-i)/n` as the F function, and n is assumed to be 25, then for the big user A, it is for the ith support. The contribution value that the account can provide is `(n+1-i)/n*2*10^7`. For example, when i is 20, the contribution value is 4.8 million; that is, when there is a Token held by a voter. When this value is exceeded, then choosing to work with this Token holder is a better strategy than working with A.
176 |
177 | Therefore, this can weaken the control power of A to a certain extent and at the same time ensure the interests of many stakeholders. At the same time, because the plan is aim to a voter must **fill for all 25 slots in order to cast a vote**, the voter is maximizing the profit for the benefit of the rational person. In addition to yourself, the remaining votes will be voted for the most stable candidates for the system, thus ensuring the security and stability of the system.
178 |
179 | ## IV. Summary
180 |
181 | The design is a further exploration of the existing EOS voting system, with the research results of Saari et al., which can make the BET voting system more perfect, but as the Arrow impossible theorem says, when it is limited to certain conditions, the perfect voting plan does not exist. So we hope to better the current model under reasonable assumptions.
182 |
183 |
184 | [^1]: [Borda Count](https://en.wikipedia.org/wiki/Borda_count)
185 |
186 | [^2]: Kenneth J. Arrow: A Difficulty in the concept of social welfare. In Journal of Political Economy
187 | Vol. 58, No. 4 (Aug., 1950), pp. 328-346
188 |
189 | [^3]: B steven j Paradoxes in Politics: An Introduction to the Nonobvious in Political Science
190 |
191 | [^4]: Michel A. Habib and Alexander Ljungqvist Firm Value and Managerial Incentives: A Stochastic Frontier Approach
192 |
193 | [^5]: Charles R. Hadlock. • ”Discrete Mathematical Models: With Applications to Social, Biological, and Environmental. Problems” byFred Roberts. ...... Prentice-Hall, Englewood Cliffs, N.J., 1976.
194 |
195 | [^6]: D.G.Saari Mathematics and Voting
196 |
197 |
--------------------------------------------------------------------------------
/BET/BET_DPOS波达计数法投票方案.md:
--------------------------------------------------------------------------------
1 | ## I. 序言
2 | 自从 BM 将 DPOS 引入 EOS 以来，如何更好的选出超级节点就成了社区争论的焦点，一票多投，一票多投可弃权制，一票一投等等，BOS 沿用了 EOS 的投票机制即一票多投（一票30投，可弃权）机制，然而由于帕累托法则的存在，导致票权会集中在少数人手中，再加上一票多投的机制允许持票人间可以进行换票，从而最终导致超级节点被控制在少数持票人手中，进而加剧筹码的不平衡，进一步导致贫富差距增大。
3 |
4 | 为此在投票方案设计中我们尝试着引入改进的“波达计数法”[^1]投票机制来缓解这一问题。“波达计数法”曾是罗马议会采用的投票制度，BET 将采用基于 DPOS 改进的“波达计数法”来进行选举，并以期找到一个更为合理的投票方案，从而在保证 DPOS 系统安全和公平上能做出积极的改进。
5 |
6 | ## II. 关于股权证明机制和投票选举
7 |
8 | 关于股权证明机制文章有很多这里不再进行原理性的重复论述。本文仅就筹码集中与安全性方面进行讨论。为便于理解，我们将对上述进行简化：
9 |
10 | 1. 假设所有投票所用票权皆来自投票者本人
11 | 2. 将简化原模型为概率发现模型
12 |
13 | 接下来我们假设：
14 |
15 | * 某个持有人持股占比为 Q
16 | * 作弊隐秘度函数 H
17 | * 作弊被发现后损失函数 F(Q）
18 | * 维护系统稳定情形下一般收益函数为 X(Q）
19 | * 作弊收益 W
20 |
21 | *注意：这里假设的函数只用来做定性分析*
22 |
23 | 于是我们可以简单的得到该持股人的策略关系即：
24 |
25 | 根据 W+(H-1)*F(Q) 与 X(Q) 的大小关系进而决定相应的策略
26 |
27 | 因为 F 是 Q 的正相关函数，X 也是 Q 的正相关函数，而 W 是带有投机性的随机参数，因此可以断定随着 Q 的增大其作弊收益会显著降低。在理性自然人假设下其选择维持公正是优势策略，因此从这个角度来看 POS 机制是稳定的模型。
28 | 事实上更进一步的分析时当我们加入道德参数，并将可监督性量化可以的得到股权结构与股东收益之间的如下关系和结论：
29 |
30 | A) 股权绝对集中结构
31 |
32 | 股权绝对集中于经营者，则监督困难，经营者道德值减小乃至变为负值。
33 | 经营者责任心(→min)=经营者道德(→-)×{1+经营者资产所有权(max)}
34 | 股东收益(→min)=经营者责任心(→min）×经营者能力×经营条件
35 |
36 | B) 股权相对集中结构
37 |
38 | 股权相对集中，可以激励经营者，稳定骨干队伍，产生制衡监督。
39 | 经营者责任心(→max)=经营者道德(→max)×{1+经营者资产所有权(max)}
40 | 股东收益(→max)=经营者责任心(→max）×经营者能力×经营条件
41 |
42 | C) 股权分散结构
43 |
44 | 股权过于分散，监督动力不足，经营者道德值也会减小乃至变为负值。
45 | 经营者责任心(→min)=经营者道德(→-)×{1+经营者资产所有权(min)}
46 | 股东收益(→min)=经营者责任心(→min）×经营者能力×经营条件
47 |
48 | 所以，股权相对集中是优先选择的股权结构（详细的知识请参见股权结构相关书籍和论文）。
49 |
50 | 因此我们需要在系统主体稳定的前提下尽量避免大户集权，那么有没有一种选票方案是理想的解决之法呢？
51 |
52 | ### 投票与选举
53 | 在详细讨论这个问题之前我们先来尝试着定义一下问题：
54 |
55 | 假设有 N 个人参加选举，共有 K 个人进行投票，且每个投票者心中对于候选人的满意程度存在着一个排列，
56 | 目的是制定一个选举方案，最终可以得到多数“公正”的投票结果。
57 |
58 | 那么什么是公正的呢？这里我们采用 Arrow 的五条规则[^2]：
59 |
60 | 1. 每一个选民的影响力都一样，更进一步说，就是非独裁的
61 | 2. 选民除了不能不理性之外，没有其他任何关于其心目中排序的限制
62 | 3. 如果所有选民都认为 A>B，则选举结果也要显示 A>B
63 | 4. 选举结果关于 A 和 B 的排序，应该只由卷宗内 A 和 B 的相对顺序决定，与任何第三者无关
64 | 5. 如果所有选民都是理性地将选择对象排序，而且诚实投票，则选举的结果也要显示理性的排序
65 |
66 | 但不幸的是有多种证明方法[^3][^4][^5]可以证明这样的“公正”是不存在的，这也是 Arrow 不可能定理的内容。因为我们的方案会在“波达计数法”的方案基础上进行修改，这里我们对其情形下的定理给出证明：
67 |
68 |
69 | 设给定的 k 个整数 m1、m2、...mk，令 σ(1,2,...,n) 为 (1,2,...,n) 的置换群，定义如下映射：
70 |
71 | 
72 |
73 | 对于任意一组数 t1>t2>...>tn，用上述 k 个置换做一个 n×k 矩阵：
74 |
75 | 
76 |
77 | 依次定义n个数：
78 |
79 | 
80 |
81 | 于是有：
82 |
83 | 
84 |
85 | 我们知道对于上述等式可以找到n组数：
86 |
87 | 
88 |
89 | 使得对应的：
90 |
91 | 
92 |
93 | 满足：
94 |
95 | 
96 |
97 |
98 | 从上面的推导可以看出存在多个解，也就是说“波达计数法”同样是不稳定的。
99 | 那么问题出在哪里呢？事实上是因为我们的假设条件制约了这样的公正性。
100 |
101 | 学者 Saari[^6] 在他的论文中对上述问题进行了详细的论述。Saari 的论点之一就是 Arrow 的第4、5条的条件会互相「抵销」，因此其对上述第四条规则有进行了修正，如下：
102 |
103 | 4'.选举结果关于 A 和 B 的排序，应该只由卷宗内 A 和 B 的相对顺序和距离决定，与任何第三者无关。
104 |
105 | 那么在这样的假设下 Saari 证明了：
106 |
107 | 在多于两个候选人前提下“波达计数法”选举程序是『公正』的
108 |
109 | 具体的技术细节请参考 Saari 的相关论文。也就是说从这个意义上来说“波达计数法”选举程序是更优的。因此我们尝试着在该结论下结合 DPOS 方案进行 BET 投票的适配。
110 |
111 | ## III. BET 投票方案
112 | 接下来我们先给出投票方案的整体描述：
113 |
114 | 设参加选举人数为N，K个人进行投票。我们的投票规则如下：
115 |
116 | 1. 对于任意的投票人要求其给出一个序列 Ln，该序列的顺序即为其心目中候选人适合与否的排列顺序
117 | 2. 投票人投票权重为其所持有并抵押的 Token 数量记为 Pi
118 | 3. 给定一个函数 F(i)，该函数返回对于序列不同序号的打分
119 | 4. 对于任意的候选人其记分规则如下：
120 |
121 | Vk = ∑ F(i,j)*Pi
122 |
123 | 5. 排序所有参加选举候选人，得出最终当选序列。
124 |
125 | BET 将采用如下 F 函数：
126 |
127 | F(i) = (N+1-i)/N
128 |
129 | 证明：
130 |
131 | > 假设任何投票人其手中所持 Token 数⌊Pi⌋即是票数，且每次只能投1票，
132 | > 如此可将**每个投票人**看作是一个具有相同投票意愿投票者的集合。
133 | > 在此假设下，进一步来看这就变成了 ∑⌊Pi⌋ 人进行“波达计数法”投票的模型，
134 | > 因此其具有与“波达计数法”方案相同的理论特性。
135 |
136 | 进一步来看对于任意的持票人 Pi 由于他需要对所有的参选人都进行投票（排序），也就是说其对于任意一个参选人都做了贡献，只不过贡献的程度是按照函数 F 来进行的，也就是说设 Pi>Pj 且对于任意的 k>l 有 F(k) (∑F(i) * Pi)/(∑F(i) * Pj)
139 |
140 | 其中 i，j 分别排在在对方的序列中劣势位置，因此对比一票多投的方案明显的削弱了其票权的作用。
141 |
142 | 下面是不同 F 函数下与一票多投控制力进行的对比。
143 |
144 | > 线下面积为一票多投制投票者的投票最大值
145 |
146 | 
147 |
148 |
149 | > 线下面积为 F 为“波达计数法”时的投票最大值
150 |
151 | 
152 |
153 |
154 | > 线下面积为 F 为 X^(-σ) 方案时的投票最大值
155 |
156 | 
157 |
158 |
159 | 虽然并不严谨但可以直观的感受到它们之间的不同之处。接下来我们通过几个简单的例子来说明该方案的特性与优势。
160 |
161 | ### 案例一
162 | 假设存在三个投票人 A，B，C，为了讨论方便我们假设候选人也是同样的三人，并假设其优先投票给自己，我们的投票准则是在三人中选择两人胜出。
163 |
164 | 我们假设 A，B，C 分别持有 Token 数量为 at，bt，ct，假设在 A 与 B 进行串谋，如果采用 EOS 现行的投票方案，只要 `at+bt>ct` 则 C 将丧失了最终的权利，但在 BET 的方案下需要 `at+2bt>2ct`（这里假设 at>bt ），才能得到相应的结果。在各个候选人相差不悬殊的情形下，可以实现 A，C 当选。
165 |
166 | ### 案例二
167 | 假设有一个拥有2000万 Token 的大户 A，另外的一些候选人的支持者只在100万到600万之间，如果采用 EOS 的策略，那么在其他候选人无法达成一致的前提下，A几乎可以控制整个当选人顺序。由于 A 的强大控制力导致许多候选人会选择和 A 进行交易，最终导致 A 的控制力进一步加强。
168 |
169 | 但对于 BET 方案来说，情况将变得不一样了，例如我们采用`(n+1-i)/n`作为 F 函数，n 这里假设为25，那么对大户 A 来说其对于某第 i 个支持账户所能提供的贡献值为`(n+1-i)/n*2*10^7` ，例如当 i 为20时其贡献值为480万；也就是说当有一个投票者手中持有的 Token 超过该值时，那么选择和这个 Token 持有者合作是比与 A 合作更优的策略。
170 |
171 | 因此这能在一定程度上减弱 A 的控制力同时又能保证尽可能多的利益相关者的利益，同时由于该方案是**必需投满**票方案，在理性人假设下投票者为了利益最大化除了投给自己之外一定会将剩余的票权投给对系统稳定性最大的候选人，进而保证系统的安全和稳定。
172 |
173 | ## IV. 总结
174 | 该方案是对现有 EOS 投票方案的进一步探索，借助 Saari 等人的研究成果，以期能使 BET 投票方案更加完善，该方案相较于现行的 EOS 方案有更强的抗大票权者控制能力，同时又保证委托制的安全性。但正如 Arrow 不可能定理说的那样，当限定在某些条件下时完美的投票方案是不存在的。因此我们希望在合理的假设的前提下能够变得更好。
175 |
176 |
177 | [^1]: [波达计数法，Borda Count](https://en.wikipedia.org/wiki/Borda_count)
178 |
179 | [^2]: Kenneth J. Arrow: A Difficulty in the concept of social welfare. In Journal of Political Economy
180 | Vol. 58, No. 4 (Aug., 1950), pp. 328-346
181 |
182 | [^3]: B steven j Paradoxes in Politics: An Introduction to the Nonobvious in Political Science
183 |
184 | [^4]: Michel A. Habib and Alexander Ljungqvist Firm Value and Managerial Incentives: A Stochastic Frontier Approach
185 |
186 | [^5]: Charles R. Hadlock. • ”Discrete Mathematical Models: With Applications to Social, Biological, and Environmental. Problems” byFred Roberts. ...... Prentice-Hall, Englewood Cliffs, N.J., 1976.
187 |
188 | [^6]: D.G.Saari choice electration Mathematics and Voting
189 |
190 |
191 |
--------------------------------------------------------------------------------
/BOSCoreTechnicalWhitePaper.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/BOSCoreTechnicalWhitePaper.pdf
--------------------------------------------------------------------------------
/BOSCoreTechnicalWhitePaper_zh.md:
--------------------------------------------------------------------------------
1 | # BOSCore 技术白皮书
2 |
3 | ### 区块链自由港，构建可信商业生态。
4 |
5 |
6 | **2018年 9月 V1**
7 | **2019年 11月 V2**
8 |
9 | - [背景](#背景)
10 | - [概述](#概述)
11 | - [共识机制](#共识机制)
12 | - [链间通讯](#链间通讯)
13 | - [预言机](#预言机)
14 | - [扩展方案](#扩展方案)
15 | - [后量子加密方案](#后量子加密方案)
16 | - [基于零知识证明的扩容方案](#基于零知识证明的扩容方案)
17 | - [锚定币](#锚定币)
18 | - [账户](#账户)
19 | - [低保](#低保)
20 | - [红包创建账户](#红包创建账户)
21 | - [ThunderNode](#thundernode)
22 | - [更可用](#更可用)
23 | - [更安全随机数方案](#更安全随机数方案)
24 | - [节点配置上链](#节点配置上链)
25 | - [更多Plugin](#更多plugin)
26 | - [按时区出块](#按时区出块)
27 | - [P2P自发现](#p2p自发现)
28 | - [生态模型](#生态模型)
29 | - [发行方式](#发行方式)
30 | - [开发者激励](#开发者激励)
31 | - [治理模型](#治理模型)
32 | - [经济模型](#经济模型)
33 | - [总结](#总结)
34 | - [参考](#参考)
35 |
36 |
37 | # 背景
38 |
39 | EOS的出现给区块链带来了新的想象力，主网启动短短几个月以来，版本经历了几十次升级，不仅稳定性得到了很大提高，并且新功能也逐步实现，各个节点团队也积极参与建设EOSIO生态。让人更加兴奋的是，EOS已经吸引了越来越多的开发团队，当前已经有数百个DApp在EOS主网上面运行，其交易量和流通市值远超以太坊，可发展的空间愈来愈广阔。
40 |
41 | 在EOS主网逐渐发展的过程中，我们发现了一些偏离期望的地方。作为最有竞争力的第三代公链，大家希望看到的是能够有更多、更丰富的应用能够在EOS上面运行，开发者会将EOS作为自己应用开发的首选平台，但是由于目前EOS的资源模型的限制，导致了很高的使用成本，包括为用户创建更多的账户，以及部署运营DApp需要的较高成本。针对白皮书中要实现的上百万TPS需要的关键技术IBC，一直没有进行推进，主网多次出现CPU计算资源不足的情况，更是加剧了对跨链通讯需求的迫切性。此外，由于EOSIO采用的Pipeline-DPOS共识机制，一个交易需要近三分钟才能保证不可更改，虽然相较比特币、以太坊是有很大的进步，但是这也给EOS的应用场景带来很大限制，快速支付只能聚焦于小额转账，大额转账必须要等待足够长的时间才能保证不可更改，这就限制了链上、链下用户支付体验。
42 |
43 | 除了上面提到的情况，还有很多其他改进想法一直在我们社区进行活跃的讨论，由此，我们觉得应该基于EOS进行更多的尝试，让更多的开发者或者团队来参与到EOSIO生态的建设中来，一起为区块链在不同行业不同场景中的落地做出一份努力。BOS将会成为首个实现去中心化跨链并具有最快共识的DPoS公链，致力于用技术打造可信商业生态。
44 |
45 |
46 | # 概述
47 |
48 | BOS致力于为用户提供方便进入并易于使用的区块链服务，为DApp运营提供更友好的基础设施，为支持更丰富的应用场景努力，为可信商业生态的繁荣进行积极尝试。除了技术改进以外，BOS也会进行其他方面的尝试。比如，为了提高用户投票参与度，可以通过预言机技术来针对符合明确规则的账户进行激励；BOS上面的BP的奖励会根据链上DApp的数量、TPS、市值、流通量等指标进行调整，鼓励每个BP为生态提供更多资源；一项社区公投达成的决议将会尽量被代码化，减少人为的因素在里面，流程上链，保持公正透明。
49 |
50 | BOS链的代码完全由社区贡献并维护，每个生态参与者都可以提交代码或者建议，相关的流程会参考已有开源软件来进行，比如PEP(Python Enhancement Proposals)。
51 |
52 | 为鼓励DApp在BOS的发展，BOS基金会将会为其上的DApp提供Token置换的低成本的资源抵押服务，降低DApp前期的运营成本；此外还会定期对做出贡献的开发者提供BOS激励，以便建立起一个相互促进的社区发展趋势。
53 |
54 |
55 | # 共识机制
56 |
57 | EOSIO采用的是基于流水线的拜占庭容错机制 (Pipelined Byzantine Fault Tolerance)，对于一个Block需要经过Propose、Pre-Commit、Commit、Finalize [1] 几个步骤，最后不可更改的块范围由Last Irreversible Block (LIB) 标明；一笔交易基本上需要约3分钟 (理论最低为325个出块时间，即162.5秒) 才能进入LIB，虽然相比BTC、ETH等其他数字通证的交易可靠时间有很大提高，但是对于很多应用场景来说还是有很大限制。比如支付场景，由于不能立即确定该笔交易最后是否成功，需要等待一段的时间才可完成商品的交易，这就增加了很多限制。
58 |
59 | 造成交易需要较长确认时间的原因是在DPOS BFT共识算法中，所有块同步后的确认信息都只有轮到该节点出块的时候才会被广播出去。举个例子来说，在BP1出块(所出块为BLKn)，BP1 ～ BP21轮流出块的情况下，BP2 ～ BP21会陆续收到并验证BLKn，但所有BP只能等到自己出块的时候才能发出对BLKn的确认信息。
60 |
61 | 在分析过EOSIO共识算法的问题以后，为了缩短一笔交易变成不可更改状态的时间，BOS将采用PBFT (Practical Byzantine Fault Tolerance[2]) 来替代Pipelined BFT，让BP之间实时地对当前正在生产的区块进行确认，能够使整个系统最终达到接近实时的共识速度。
62 |
63 | BOS的共识算法是在 PBFT 理论基础上，结合EOSIO代码进行的改进，在保证实现拜占庭容错的前提下，会进行以下部分的改动：
64 | 1. 保留Pipelined BFT的BP 轮流出块的机制，并且和EOS一样对同步时钟和出块顺序进行强约束
65 | 2. 移除Pipelined BFT共识部分的逻辑，即去掉原本出块时的implicit confirm 和 (explict) confirm 部分，避免在极端情况下与PBFT的共识结果产生冲突
66 | 3. 共识的通讯机制使用现有p2p网络进行，将会使用PBFT机制广播prepare和commit信息，并保证通信成本在可接受范围内。
67 | 4. 采用批量共识替换PBFT中对每个块进行共识的要求，通过一次广播多个块的相关信息，以此来逼近实时BFT的理想状态并减轻网络负载。
68 |
69 | BOS PBFT中状态描述如下：
70 | * **pre-prepare**，指出块节点出块以后，广播给网络里的所有其他中继节点。可以类比为EOSIO中BP出块并广播至全网。
71 | * **prepare**，指中继节点收到请求后向全网广播将要对此请求进行执行。可类比为EOSIO中所有节点收到块并验证成功后广播已收到的信息。
72 | * **commit**，指中继节点收到足够多的对同一请求的prepare消息，向全网广播执行此请求。可以类比为EOSIO中节点收到足够多对同一个块的prepare消息，提出proposed lib消息
73 | * **committed-local**，指中继节点收到足够多对同一请求的commit消息，完成了验证工作。 可以类比为EOSIO中的LIB提升。
74 | * **view change**，指出块节点因为各种原因失去其他节点的信任，整个系统更改出块节点的过程。由于EOSIO采用了Pipelined BFT的算法，所有BP是通过投票的方式提前确定的，在一轮出块中整个系统的出块顺序是完全不变的。当网络情况良好并且出块节点没有发生改变的时候可以认为不存在view change状态。当引入PBFT后，为了避免分叉导致共识不前进的情况，加入view change机制，抛弃所有未达成共识的块进行replay，不断重试直到继续共识。
75 | * **checkpoint**，指在某一个块高度记录共识证据，以此来提供安全性证明。当足够多的中继节点的checkpoint相同时，这个checkpoint被认为是stable的。checkpoint的生成包括两大类：一类是固定k个块生成，另一类是特殊的需要提供安全性证明的点，例如出块BP排名发生变更的块。
76 |
77 | 
78 |
79 | 通过对现有EOS主网进行的观察来看，全球节点之间的网络延迟大部分都在1s以内，按照BOS PBFT的共识机制在绝大多数场景下可以做到3s (pre-prepare, prepare, commit) 不可更改。将一笔交易的可信时间从分钟级缩短成秒级将会让很多应用场景可以在BOS链上面进行实现。
80 |
81 |
82 | # 链间通讯
83 |
84 | EOSIO技术白皮书中把链间通讯作为实现高并发的解决方案，以链间通讯技术构建多条链间的流转通道，通过水平拓展的方式来增加EOSIO整个生态的承载能力。跨链通讯的本质问题是解决对各个链之间交易可信度的证明。异构的区块链系统（例如EOS、ETH）因为区块生成速度、内部数据结构、共识机制等都有很大差异，因此异构去中心化跨链的实现难度相对较高，相比而言而对于以EOSIO为基础的不同链之间的交易验证更具有实际意义。
85 |
86 | 去中心化跨链通信的基础是轻客户端（Light Weight Client）和交易验证技术（SPV/Simple Payment Verification）。轻客户端是由区块头构成的一条链，不包括区块体，所以轻客户端只占用很小的空间；SPV技术使用merkle路径来证明一个交易是否存在于某个区块中[3]。
87 |
88 | BOSCore采用的跨链方案优势有以下几点：
89 | 1. 完全去中心。轻客户端在智能合约中实现，当初始化了正确的起始区块信息，合约就可以完全自主验证后续所有区块的有效性，无需依赖对中继或合约外部信息的信任。
90 | 2. 轻量。轻客户端无需连续同步原链所有区块头，只根据需要同步区块链的一部分片段即可获得可信区块用于验证交易。
91 | 3. 快速的跨链交易。一个跨链交易从产生到在目标链上产生对应交易只需要不到3分钟时间。
92 | 4. 跨链交易并行。不同的跨链交易之间互不影响，可以并行执行，因此支持很大的并发量。
93 | 5. 安全。由于采用了生产者签名效验和严格的逻辑检查，可以保证轻客户端自身的正确性，无法被恶意攻击，因此可以安全的验证交易的真实性。
94 |
95 | BOS基于该IBC方案提供与EOS主链的兑换通道，EOS可以十分方便的在BOS侧链和EOS主链之间流通，包括EOS上面的其他优质数字通证；与此类似，BOS将会推进与其他基于EOSIO技术的侧链建立流通通道，让整个EOSIO生态开始迈进生态网络的建设，BOS将会作为一个核心流通纽带，加速整个EOSIO生态的发展与进化。
96 |
97 |
98 | # 预言机
99 |
100 | 预言机是图灵机模型引入的概念，由于停机问题以及数学不完备性的原因，引入该概念后会得到一些标准图灵机所不能得到结果。在图灵机里它是确定性的，但在区块链中引入的预言机却很难得到理论上定义的特点，究其原因是因为区块链本身就是建立在容错逻辑之上，其本身并不要求输入的确定性，甚至允许存在欺骗行为，这也是区块链建立拜占庭容错结构之上的原因。因此区块链的预言机与传统意义上的预言机有着本质的区别。
101 |
102 | 面对非可信预言者问题，简单的确定性计算模型显然已经无能为力，为此我们尝试着引入博弈的系统模型来解决这些问题。概括的讲，不单纯的将预言机看作是系统的信息提供点，而是将其看作博弈的参与方与信息使用者共同构建博弈模型。并通过引入惩罚机制以及多回合博弈机制来建立可信承诺，通过多信息提供点的信息选取机制达到谢林点，从而提高信息的可信性；此外通过引入检验员并加入连带奖惩机制，构建对信息提供角色的囚徒困境，进一步保证可信性。
103 |
104 | 有些预言机服务的设计是基于可信数据源或者权威数据源这一假设，这样的假设从理论上来说有很大风险，无法保证这种数据源提供数据的真实性。BOS 的预言机系统从构建之初所遵循的原则就是：
105 |
106 | 不依赖于每一个预言机数据提供者一定会提供真实数据，而是承认其不足进而将其作为博弈的参与方加入到系统中来，以期在博弈中达到整体可信
107 |
108 | 这样在博弈过程中只要将参与方与现实世界的角色进行映射，那么不但能得到区块链输入数据的可信性，同时我们还可以向现实世界输出“信任”。事实上这更像是一个基于区块链的可信平台，而它的服务展示形式是预言机。BOS 预言机将会使得区块链的价值从其货币属性延伸到了交易和规则的构建上，这种延伸将会解决或改进许多现实世界的信任问题，从而扩大区块链的应用边界，并最终让区块链技术可以在交易转账以外场景落地。
109 |
110 | 
111 |
112 |
113 | # 扩展方案
114 |
115 | BOS 在积极推动多线程方案的同时也在探索更加广阔的扩容方案。抽象的来看运行在区块链上的智能合约其所关联的上下文环境相对独立是大概率事件，因此从全局角度将不同的智能合约划分出来进行并发执行是可行的，于是提出了基于隔离计算的扩容方案，重新定义网络中节点角色和块结构，可以通过水平扩展来提高BOS链整体负载能力。
116 |
117 |
118 | 
119 |
120 |
121 | 扩展方案中引入“计算区”的概念，每个计算区之间的交易都是并行处理，并且出块和执行是同时进行。BOS主网将会成为“核心计算区”，主要负责账户和通证系统，相关数据更新会同步到各个计算区。
122 |
123 |
124 | 
125 |
126 |
127 | 为了适应大量的数据在 P2P 网络中传输，网络节点会分成三种类型：出块节点、数据节点、广播节点。出块节点负责并发执行交易，广播节点提供数据的加速同步，数据节点可以配置针对那些计算区数据进行验证，这将在保证去中心化的前提下实现共识安全并保持其抗攻击的特性。
128 |
129 | 采用多计算区并行方案以后，需要针对块结构进行调整来达到降低数据传输量以及更快共识的目的。新的区块结构将会包含各计算区块的数据，每个计算区的数据都是各自进行计算并达成共识。
130 |
131 |
132 | 
133 |
134 |
135 | 为保证数据可信，BOS 将引入全新的可信查询功能。概括来说，可信的数据查询不仅需要提供目标数据，还需要提供足够的证据来证明数据的可信性。链上数据记录时采用 MVCC 的记录结构，每次改变会使数据记录的版本号加一，同时会保留以前的数据历史。在这种设计模式下，给出一个交易的高度就可以快速查询出该高度对应的全局状态，再结合当前状态生成基于 Merkle Tree 的数据可信证明。
136 |
137 | BOS计算区水平扩展方案将会和多线程方案同时进行，在保证去中心化和数据安全的同时实现计算资源的水平和纵向扩展，从而为实现十亿级用户覆盖的目标打下坚实基础。
138 |
139 |
140 | # 后量子加密方案
141 |
142 | 随着量子计算机技术的发展以及量子霸权的实现，通用量子计算机已不再是理论上遥不可及的圣杯，在可预见的未来必将带来一系列深刻的变革。基于大数分解和离散对数难题的非对称密码体系的崩塌则是变革中最显著的特征之一。BOS 当前所采用的 ECDSA 签名算法同样难以幸免，为此我们将引入新的抗量子加密体系来应对上述挑战。
143 |
144 | 在众多的抗量子密码体系中，格密码体系将作为 BOS 抗量子密码的主要方案，将采用 NTRU （包括加密和签名）作为主体的加密体系。FrodoKEM 体系以及 Sphincs+ 作为后备密码。考虑到格加密体系并未最终在理论上完备且处于国际后量子密码标准定制阶段，BOS 将会保持多种密码方案的扩展能力。同时基于格的加密签名体系还可以方便的构建量子安全的匿名币，这为 BOS 保留了最大限度的可扩展性，而前期保持对多密码体系的支持也最大限度的降低了由于某一密码体系崩塌所带来的不可挽回的结果。
145 |
146 |
147 | # 基于零知识证明的扩容方案
148 |
149 | 对于区块链来说，TPS 影响到整个区块链系统的承载能力决定了应用的边界，是区块链核心指标之一。除了推动多线程和多计算区扩展方案以外，同时基于对零知识证明方面的研究和积累，BOS也会考虑基于零知识证明的扩展方案。考虑到智能合约的执行是确定和有限步，可以对现有的零知识证明方案进行改进并针对有限步执行的特点进行优化使其能满足实用需求，同时我们会针对不同的合约特点进行区分使得真正的计算密集型合约采用零知识证明的方法，而非计算密集型则采用 VM 执行方案，最终将能最大化的提升计算效率。
150 |
151 |
152 | # 锚定币
153 |
154 | 为了丰富整条链的经济生态，BOS除了使用IBC机制实现与EOSIO主网建立流通渠道以外，还将采用“公证人机制”，联合世界顶级交易所将BTC、ETH映射到BOS链上。通过该可信通道，BTC、ETH都可以在BOS上面轻松进行跨链流通。这意味着对于BOS上面运行的DApp来说，在支持EOSIO生态数字资产的同时，可以将更多其他共识机制的数字资产方便的进行支持。此外，该方案也可以作为提高其他低TPS数字通证流动性的方案。
155 |
156 | BOS将会提供一种机制，可以针对不同的数字通证发行 1 : 1 的锚定币，并且通过BP多签的方式来针对可信中间人的身份进行认证。每个可信中间人都需要抵押一定的BOS作为保证金。具有实力和公信力的组织或公司可以发起“公证人”身份的申请，在通过前30名BP中有25名BP通过以后就可以进行锚定币的发行。
157 |
158 | # 账户
159 |
160 | ## 低保
161 |
162 | 从EOS主网上线以来，对于普通持币人往往都会遇到由于抵押资源不够导致转账失败的情况，这种情况下用户也无法自救，就只能求救于他人，导致了很差的用户体验，提高了使用门槛。
163 |
164 | 对于一条链来说，活跃用户量的增长在促进链发展的同时，更会促进链上DApp的发展，对整个生态都至关重要。为了解决这个问题，BOS链进行了改进，可以通过链的参数来调整分配给每个用户免费的资源额度，相当于BOS链上的“低保”机制。这样大部分用户日常的转账等基本需求都能被满足，无需再为较少的初始资源抵押担心无法使用链上功能。对于更多使用需求的用户，超出低保额度的资源使用仍然需要进行抵押。
165 |
166 | ## 红包创建账户
167 |
168 | 对于EOSIO主网来说，创建账户成本是一个不可忽视的问题。BOS的定位是为丰富链上DApp为目标，所以也提供了解决用户创建账户成本的方案。参考生活场景中发红包的例子，BOS会将社区开发的“红包DApp”进行内置，并且会由BOS基金会持续提供一定量的免费创建账户数量。其他DApp项目方或者组织都可以方便的通过红包的形式给用户免费创建账户。红包DApp相关的功能可以通过官网访问，也可以通过每个BP提供的接入点进行访问。
169 |
170 | # ThunderNode
171 |
172 | 通过改进共识机制，BOS链上的一笔交易的可靠时间可以缩短到3s以内，这个时间相比中心化的系统还是有些差距。所以为了满足这种接近中心化系统的需求，BOS上面会提供一种可以达到毫秒级确认的节点，称之为 ThunderNode。
173 | 类似于闪电网络，ThunderNode 的交易大部分都是在一个局部网络完成，ThunderNode 会保证交易在BOS链上可见并不可更改。使用者一旦决定使用某一ThunderNode就需要锁定部分余额，这部分余额只可以在该ThunderNode进行使用，在决定不使用时可以将剩余BOS解锁，恢复正常使用，用户选择使用那个ThunderNode以及锁定对余额都需要在BOS链上发送注册并等待生效以后才能开始使用。
174 |
175 | ThunderNode的运营者是完全开放竞争的，没有硬性的限制条件，使用者也是可以根据自己的需要来选择，ThunderNode的提供者可以通过收取一定手续费用的方式来获取奖励。
176 |
177 |
178 | # 更可用
179 |
180 | ## 更安全随机数方案
181 |
182 | 目前EOSIO上面已知的随机数方案基本上都是结合可预知的多个字段，比如 blockid、timestamp等作为随机种子的一部分，然后再结合用户端、DApp项目方或者直接由DApp方线下生成。该类方案存在一定的安全风险，无法降低对DApp项目方可信度的依赖，以及无法避免一些重放攻击(比如INLINE_ACTION形式)。针对以上问题，BOS启用了block_extension特性，提供了 bpsig_action_time_seed 方案，bpsig_action_time_seed 不仅可以防止重放攻击，而且还需要BP节点的签名私钥进行签名，并把生成的seed存入block_extension，便于其他节点进行验证。
183 |
184 | 结合 bpsig_action_time_seed 就可以构造出用户、节点、DApp项目方三方参与的更安全的随机数方案。bpsig_action_time_seed 的生成方式如下：
185 |
186 | ```
187 | bpsig_action_time_seed = sign(BP_Sign_Key, F(block_timestamp, 0.5) + global_action_sequence)
188 | ```
189 |
190 | 注：
191 | * BP_Sign_Key : 使用BP私钥签名的目的就是避免他人进行投机计算
192 | * F：将block_timestamp按照0.5向下取整的函数，降低BP调整时间戳来进行投机概率
193 | * global_action_sequence: 全局action自增标识，可以用于防止 INLINE_ACTION 攻击
194 |
195 |
196 | ## 节点配置上链
197 |
198 | EOSIO中一些细节做的不够到位，其中黑白名单的配置就是很好的例子，由于黑白名单配置问题就导致至少两次冻结账户失效。BOS会将黑白名单等此类公共配置信息上链，由BP多签生效，避免由于其他原因导致配置在某些点上失效，进而导致损失。BOS不仅仅会关注重要特性的开发，而且在基础细节上面也会做的更到位。
199 |
200 | ## 更多Plugin
201 |
202 | 对于想要实现监听一个账户具体交易情况，对于现在的EOSIO来说方案比较复杂，往往通过kafka的插件来实现。这个又是对DApp、钱包或者交易所来说很需要的一个功能。对于普遍需求的功能点，BOS就会进行支持。BOS内置 Notify Plugin，提供与History Plugin类似的使用方式，可以低成本、快速的获得账户监听功能。
203 |
204 | 除此之外，BOS还会将社区里面优秀的插件进行集成，降低编译成本，方便开发者使用。
205 |
206 |
207 | ## 按时区出块
208 |
209 | EOSIO当前使用的是按照BP账户名称的字典序进行出块，从实际运行效果来看往往会导致多次的小分叉：最后2-4块不能及时广播到下一个出块BP。为了降低前后BP之间的网络延迟，BOS将会采用按照时区顺序进行出块，尽量降低物理距离以及网络抖动导致小分叉情况的出现。
210 |
211 | BOS有计划在正常的连接网络之外，再搭建一条使用专线互联各个节点的网络，保证块数据更高质量、低延迟的传输。
212 |
213 |
214 | ## P2P自发现
215 |
216 | 在EOSIO的实现中，与那些节点建立连接依赖于配置文件的静态配置，从整体上面来看当一个新的节点加入时，只能通过从其他地方获取到公布的信息，但是这个公布的信息很难保证是全面且是最新的，这就会导致一些节点连接通道是片面的，进而会降低整个网络的联通质量。
217 |
218 | BOS在这点上进行了增强，可以通过配置项决定是否将一个节点设置为可自发现，并且同样受最大连接数的整体限制，这样只要在每个团队节点中有至少1台开启了自发现，都将会帮助BOS链上的节点之间建立起一个更高互通质量的网络。
219 |
220 | 为了降低安全风险，一个节点只会向配置文件中的已有节点获取可连接的节点信息，不是无限制的自动创建连接。
221 |
222 |
223 | # 生态模型
224 |
225 | ## 发行方式
226 |
227 | BOS初始发行量为10亿，分配方式如下：
228 |
229 | - 1亿进行生态空投
230 | - 5千万直接空投EOS主网账户
231 | - 5千万根据DApp和节点的实际情况情况进行空投
232 | - 1亿战略伙伴基金，用于BOS链上项目投资及BOS运营
233 | - 4亿进行生态激励，向在BOS链上产生的支付及BOS交易业务进行补贴
234 | - 2亿进行创始团队激励，分4年解锁
235 | - 2亿进行私募，分四期进行募集每期5千万
236 |
237 | 每年增发量 2%，分配方式如下：
238 | - 节点奖励为 1%
239 | - 开发者奖励 0.8%
240 | - 治理激励 0.2%
241 |
242 | ## 开发者激励
243 |
244 | 增发0.8% 面向BOS生态贡献代码的开发者，由社区提出50名奖励名单，由前50名BP投票选出40名的获奖者获取对应奖励：
245 | - 前10名获取40%
246 | - 11到20名获取30%
247 | - 最后20名均分30%
248 |
249 | 奖励周期3个月一次，每次奖励名额都会进行为期一周的公示，如果有合理异议，将会重新评审，每次奖励名单都会上链记录。
250 |
251 | 随着BOS的不断发展，开发者奖励会适当调整，让社区为BOS的进化提供更多动力。
252 |
253 | ## 治理模型
254 |
255 | 在链上生态不断蓬勃发展的过程中，未来每一条链可以理解为一个“国家”。每条链都将会拥有自己的独一无二治理模型，不同的治理模型将会使得大家走向不同方向，并在链间产生竞争，并通过自由市场模型使得开发者和用户选择最优的模型进行发展。BOS的治理模型崇尚 “Code is the law”。保障DApp的平稳发展将会是BOS的最高准则。
256 | BOS每年增发0.2%用于向帮助BOS持有人发起仲裁的治理组织或志愿者，在BOS中任何人都可以发出仲裁，一个提案获取越多治理组织附议，其可靠性就越高。如果仲裁生效，治理组织或者志愿者可以获得2000 BOS的治理奖励。
257 | BOS的决策或者仲裁达成方式有两种：1. 不少于15个BP同意，2. 社区公投。BOS治理中不会存在唯一的仲裁机构，但是会存在多个中立的治理组织或志愿者，对提出有效方案或者改进建议的组织或都志愿者可以获得社区激励。
258 |
259 | 注：生效标准（例如不少于N个BP同意该仲裁生效）可能会随着BOS链的生态发展而变化，且任何变化也必须遵循当前治理规则投票。
260 |
261 | ## 经济模型
262 |
263 | BOS是一个对区块链世界的自由市场经济十分有意义的尝试。由于中央银行的过度干预市场以及无法保持独立性所带来的问题，以比特币为代表的数字代币以完全自由市场的理念，试图通过理性人假设（hypothesis of rational man）来解决现实经济中无法解决的问题。但当我们回顾现代经济学的历史时，治理和自由，公平与效率始终是处于互相博弈和再平衡的过程。从奉行自由市场的古典学派，到强调政府干预的凯恩斯学派、再到强调回归市场奥地利学派，任何一个方向都不会是一概而论的，一成不变，放之四海而皆准的。
264 |
265 | BOS希望通过以商业发展为导向，通过调和BTC自由市场以及EOS目前过度治理的情况，平衡二者之间的优缺点，同时发挥效率和去中心化的优势将区块链真正实现商业落地。
266 |
267 | BOS支持的链间通讯功能将会影响整个区块链行业的运行方式，各类数字资产均可通过链间通讯将传统孤岛化的数字资产链接成为一个网络。包括BTC、ETH、EOS或者其他通证资产均可以在BOS链上进行交易和划转，进而可以将BOS理解为一个数字货币的自由港，而BOS所带来快速交易系统将会使得BOS 具有十分可观的吞吐量。此外，低廉的账户创建成本将会吸引来自全世界的各类商家和应用入驻，进而繁荣整个BOS生态，进而反哺EOSIO生态。
268 | 当一个用户同时持有ETH、BTC、EOS，用户可以将以上代币通过跨链通道导入BOS链，在链上创建BOS-ETH、BOS-BTC、BOS-EOS，我们将此类资产称之为BOS资产。即用户将资产带入BOS自由港，用户可以在BOS这个自由港进行消费、投资、娱乐等活动，DApp的开发商可以为用户提供各类服务，在服务的过程中，BOS资产可以在不同的BOS账户内在进行交易和转让。BOS资产的持有人可以从链上随时通过跨链通信将资产从BOS链上流通回原有的BTC、ETH、EOS链。
269 |
270 | BOS作为一种资源将会成为整个自由港的计价单位和基础设施平台，当多种资产在BOS链上产生交互的时候BOS将会向英镑和美元一样起到价值媒介的作用。
271 |
272 | 历史上英格兰银行第一次将足额黄金与英镑进行等额的双向兑换，结合以罗马法为基础的法律进而形成良好商业氛围吸引了当时全世界最优秀的资源，并最终确立了伦敦国际金融中心的地位，BOS也将通过完善的基础设施、良好的商业氛围来打造区块链的商业中心。
273 |
274 |
275 | # 总结
276 |
277 | BOSCore 是一个致力于用技术打造可信商业生态，做一条覆盖十亿用户的 DPoS 公链。从区块链的进化角度来看，BOSCore 除了作为商业落地的首选公链以外，还可以作为一个各种异构链通证的流通链，做区块链世界的自由港。BOS来源于社区，也会在社区的维护下更好的发展。
278 |
279 |
280 | # 参考
281 |
282 | [1] [ DPOS BFT— Pipelined Byzantine Fault Tolerance ](https://medium.com/eosio/dpos-bft-pipelined-byzantine-fault-tolerance-8a0634a270ba)
283 | [2] [ Practical Byzantine Fault Tolerance ](http://pmg.csail.mit.edu/papers/osdi99.pdf)
284 | [3] [ Chain Interoperability ](https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/5886800ecd0f68de303349b1/1485209617040/Chain+Interoperability.pdf)
285 |
286 |
287 |
288 |
289 |
290 |
291 |
--------------------------------------------------------------------------------
/BOSCoreTechnicalWhitePaper_zh.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/BOSCoreTechnicalWhitePaper_zh.pdf
--------------------------------------------------------------------------------
/IBC/EOSIO_IBC_Priciple_and_Design.md:
--------------------------------------------------------------------------------
1 | EOSIO IBC Priciple and Design
2 | ---------
3 | *Author:Simon [Github](https://github.com/vonhenry)*
4 |
5 | This paper introduces the technical principle of IBC, the contracts and ibc_plugin developed by boscore team.
6 |
7 | In order to realize the inter-blockchain transfer of token between two EOSIO blockchains, first, we need to
8 | solve two problems: 1. How to realize the lightweight client, 2. How to ensure the integrity and reliability
9 | of inter-blockchain transactions, how to prevent double spend and replay attacks.
10 |
11 | The EOS mainnet and BOS mainnet are illustrated below. However, this document applicable for
12 | any two EOSIO architecture blockchains.
13 |
14 |
15 | ### 1. Terminology
16 | - BOSIBC
17 | IBC contracts and ibc_plugin developed by the BOSCORE technical team.
18 |
19 | ### 2. Key concepts and data structures
20 | - Simple Payment Verification (SPV)
21 | Simple Payment Verification was first proposed in Bitcoin White Paper of Satoshi (https://bitcoin.org/bitcoin.pdf)
22 | to verify that a transaction exists in a blockchain.`SPV client` stores contiguous block headers, but no blocks' body,
23 | so it only takes up a small amount of storage space. When receive a transaction and the `merkle path` of the transaction,
24 | `SPV client` can used to verify whether this transaction exist in the blockchain or not.
25 |
26 | - Lightwight client (lwc)
27 | also called `SPV client', is a lightweight chain composed of block headers.
28 |
29 | - Merkle path
30 | In order to verify whether a transaction exists in a blockchain, only the original data of the transaction
31 | and the transaction's `merkle path` is needed, instead of the whole block. then calculate the merkle root and
32 | compaire with the merkle root of block header, if equal, indicates that the transaction exists in that blockchain.
33 | `merkle path` also known as `merkle branch`.
34 |
35 | - Block Producer Schedule
36 | The `BP Schedule` is a EOSIO architecture blockchain technology, which is used to determine the rights that which
37 | producer can produce blocks. The new version `BP Schedule` comes into effect after passing the validation of
38 | the last batch of `BP Schedule`. In order to ensure strict handover of BP rights, it is a core technology of
39 | IBC system logic, that the lightweight client must follow the corresponding `BP Schedule` with it's mainnet.
40 |
41 | - forkdb
42 | When the EOSIO node runs, there are two underlying DBs used to store block information.
43 | One is `blog`, i.e. `block log`, which is used to store irreversible blocks, and the other is `forkdb`,
44 | which is used to store reversible blocks. Forkdb stores part of the block information at the top of the
45 | current blockchain. A block must be accepted by forkdb before it finally enters the irreversible block.
46 | The lightweight client mainly refers to the logic of forkdb.
47 |
48 | ### 3. Lightweight Client
49 |
50 | In order to solve the cross-chain problem, the first problem to be solved is how to realize the lightweight client.
51 | 1. At where should the lightweight client runs? In the contract or out of the contract, for example, in plugin layer?
52 | 2. If running in contract, is it to synchronize all block header data of the opposite blockchain in real time,
53 | or to synchronize part of block header data to verify transactions according to need, because synchronizing
54 | all block header data will consume a lot of CPU resources of two chains.
55 | 3. If running in contract, how to ensure the credibility of the lightweight client, how to prevent malicious attacks,
56 | how to achieve complete decentralization, does not depend on the trust of any relay node.
57 |
58 |
59 | #### 3.1 Should the Lightweight Client Run in the Contract
60 | Bitcoin's light client was originally run on a single node (such as a personal computer or a decentralized
61 | Bitcoin mobile wallet) to verify the existence of transactions and to see the depth of that block. Specific
62 | implementation can be referred to [breadwallet](https://github.com/breadwallet/breadwallet-core).
63 |
64 | IBC and Decentralized Wallet have different requirements for light clients. Decentralized wallets generally run
65 | on personal mobile apps, providing transaction verification services for individual users, while IBC systems need
66 | light clients that are open, accessible and trustworthy to everyone. From this point of view, a light client that
67 | can gain public trust can only run in the contract, because only the contract data is globally consistent and
68 | can not be tampered with. It is impossible to implement a trusted light client outside the contract, so BOSIBC
69 | run the light client in the contract. See source code of [ibc.chain](https://github.com/boscore/ibc_contracts/tree/master/ibc.chain).
70 |
71 | #### 3.2 Whether to synchronize all block headers
72 | In the light client of Bitcoin and ETH, a starting block and some subsequent verification block will be provided,
73 | and the light client will synchronize the full block headers after that starting block. Bitcoin produces only 4 Mb
74 | of block headers per year. According to the current storage capacity of mobile devices, it can be fully accommodated,
75 | and synchronization of these blocks will not consume a lot of computing resources of mobile devices. However,
76 | the situation of EOSIO is quite different. EOSIO contract consumes 0.5 milliseconds of CPU to add a block header to the contract
77 | and 0.2 milliseconds to deleted a block header, so 0.7 ms of CPU is needed for every block header procession.
78 | Assuming that we want to synchronize all the block headers of the other EOSIO chain, according to the total CPU
79 | time of each block, now is 200ms, that is to say, `0.7ms/200ms = 0.35%` of the whole chain is needed to achieve
80 | real-time full synchronization. According to the actual total amount of delgated token of the whole network is about
81 | 400 million, in order to make the IBC system works when the CPU is busy, the account which push block headers and ibc
82 | transactions needs to be delgate `400 million * 0.35% = 1.4 million` token, which is a large amount. Because EOSIO
83 | advocates multi side-chain ecosystem, let's assumed that there will be multiple side chains and EOSIO main network
84 | to achieve cross-chain in the future, and between side chains and side chains, and it also will realizes one-to-many
85 | cross-chains operation, assuming the one-to-ten situation, each chain needs to maintain 10 light clients,
86 | in order to maintain these light clients, it needs to consume 3.5% of the whole network CPU of a single chain,
87 | this proportion is too high, therefore, we need to find a more reasonable solution.
88 |
89 | The process of designing inter-blockchain communication is a process of finding credible evidence.
90 | Is there a scheme that does not need to synchronize the whole block information, but also can guarantee the credibility
91 | of light clients? The bottom of EOSIO source code has been prepared for this purpose.
92 | Let's assume that if BP schedule never change, then at any time, when the ibc.chain contract obtains a series of
93 | block headers passed by signature verification, such as `n ~ n+336`, and more than two-thirds of the active BP
94 | is producing blocks, we can be sure that the `n`th block is irreversible, and can be used to verify cross-chain transactions.
95 | Later, we need to consider the situation of BP schedule replacement. When BP schedule replacement occurs,
96 | we will not accept transaction verification until the replacement is completed. The relatively complex process
97 | of BP replacement is dealt with, which will be described in more detail below.
98 | Therefore, using this scheme can greatly reduce the amount of block headers that need to be synchronized,
99 | and only when the BP list is updated or cross-chain transactions occured, that it's needed synchronized block headers.
100 |
101 | In order to achieve this goal, the concept of `section` is introduced in ibc.chain.
102 | A section records a batch of continuous block headers. Section does not store block headers, instead,
103 | it records the first block number (first) and the last block number (last) of the block header, block headers are
104 | stored in `chaindb`. Each section has a valid bool value. When there is no BP schedule replacement,
105 | as long as two-thirds of the active BP is producing blocks and `last - first > lib_depth`, then
106 | the block of `first to last - lib_depth` is considered irreversible and can be used to verify cross-chain transactions.
107 | When BP schedule is replaced, the 'valid' of that section becomes false and no transaction validation is accepted
108 | until schedule replacement is finished and 'valid' becomes true, then continue cross-chain transaction validation.
109 |
110 |
111 | #### 3.3 How to Ensure the Reliability of Light Clients
112 | **3.3.1 forkdb**
113 | *1. How to append a new block to forkdb*
114 | A running eosio node maintains two underlying data structures
115 | [blog](https://github.com/EOSIO/eos/blob/master/libraries/chain/include/eosio/chain/block_log.hpp)
116 | and [forkdb](https://github.com/EOSIO/eos/blob/master/libraries/chain/include/eosio/chain/fork_database.hpp),
117 | blog is used to store irreversible block information, its stored data is serialized `signed_block`,
118 | forkdb is used to store reversible block information, and its stored data is `block_state`.
119 | `block_state` contains more block-related information than `signed_block`. A block must first be appended to forkdb
120 | before it can eventually become irreversible and remove from forkdb into blog.
121 | How can the `block_state` information of a block be obtained? It is not thart BP of the production block transfers
122 | `block_state` to other BP nodes and full-nodes, P2P network eos eosio pass only
123 | [signed_block](https://github.com/EOSIO/eos/blob/master/plugins/net_plugin/include/eosio/net_plugin/protocol.hpp#L142),
124 | When a node receives a `signed_block` over P2P network, it uses this `signed_block` to construct `block_state`
125 | then verify the BP signature. [Relevance function](https://github.com/EOSIO/eos/blob/master/libraries/chain/block_header_state.cpp#L144),
126 | The key points should be clarified are: 1. `blockroot_merkle`, 2. `get_scheduled_producer()`, 3. `verify_signee()`.
127 |
128 | The signature verification related function are:
129 | ```
130 | digest_type block_header_state::sig_digest()const {
131 | auto header_bmroot = digest_type::hash( std::make_pair( header.digest(), blockroot_merkle.get_root() ) );
132 | return digest_type::hash( std::make_pair(header_bmroot, pending_schedule_hash) );
133 | }
134 |
135 | public_key_type block_header_state::signee()const {
136 | return fc::crypto::public_key( header.producer_signature, sig_digest(), true );
137 | }
138 |
139 | void block_header_state::verify_signee( const public_key_type& signee )const {
140 | EOS_ASSERT( block_signing_key == signee, wrong_signing_key, "block not signed by expected key",
141 | ("block_signing_key", block_signing_key)( "signee", signee ) );
142 | }
143 | ```
144 |
145 | The first step in verifying signature is to obtain signature digest, i.e. `sig_digest()`,
146 | which uses `header.digest()`, `blockroot_merkle.get_root()` and `pending_schedule_hash`.
147 | The second step is to obtain the signature public key, i.e. `signee()`, which compute the BP public key through
148 | `producer_signature ` and `sig_digest()`.
149 | The third step is to verify whether the public key is correct, i.e. `verify_signee()`, which is called in
150 | `block_header_state:: next()`, after validation, a block is added to forkdb main branch.
151 |
152 | So every block which added to forkdb has undergone a very rigorous and comprehensive verification.
153 | The core logic contains `blockroot_merkle`, `get_scheduled_producer()` and `verify_signee()`.
154 | The ibc.chain contract fully inherits the rigorous validity of forkdb.
155 |
156 | *2. How forkdb handles forks*
157 | When adding a new block, which results in a different head.id for forkdb and head.id for controller_impl, the branch is re-selected.
158 | source code refers to `eosio::chain::controller_impl::push_block()`and `eosio::chain::controller_impl::maybe_switch_forks()`;
159 |
160 | *3. How does LIB determine*
161 | The consensus approach currently used by EOSIO is dpos, also called pipelined bft, which sets `required_confs`
162 | when constructing a block `block_header_state`, which is 2/3+1 of the current number of active BPs.
163 | In the case of 21 BP, `required_confs` is 15. Each block has `header.confirmed`, which is used to confirm
164 | the previous blocks. when a block gets a confirmation,its `required_confs` will be reduced by 1.
165 | When `required_confs` of a block is reduced to zero, the block will be nominated `dpos_proposed_irreversible_blocknum`
166 | by the latest block (head of forkdb). When a block obtains 2/3 BPs nominations, it becomes an irreversible block,
167 | In other words, it enters LIB. Since the confirmation information is passed in block header,
168 | so a block from generation to enter the LIB requires a total of 2 * 2/3 round, that is `12 * (14 * 2) = 336`.
169 | When BP is registered, 12 blocks are continuously produced each time. Only the `header.confirmed` of the first
170 | block is non-zero, so when a BP starts to come out of a block, only the first block will raise the LIB,
171 | so the actual head and LIB gap is between 325 and 336, but in the case of BP loss blocks, the head and LIB gap may be smaller than
172 | 325 to 336.
173 |
174 | *4. How does the BP list change*
175 | In the blockchain of pow, such as bitcoin and ethereum, the fork with the greatest cumulative computing power
176 | is chosen as the main branch. Only when a block contains certain computing power can it be recognized and
177 | eventually become irreversible. In EOS which adope dpos as consensus algorithm, the block's recognized mark
178 | is BP signature, so BP list plays an important role in EOSIO. IBC's light clients also need to maintain
179 | the replacement of BPs lists. Therefore, it is necessary to thoroughly analyze the replacement logic of BP list.
180 |
181 | First, in the `onblock ()` function of the system contract `eosio. system`, the system tries to update the BP list
182 | `update_elected_producers(timestamp)` every minute, this function eventually calls the wasm interface
183 | `set_proposed_producers()`, after a series of checks, the new scheme and the current block number are stored
184 | in the `global_property_object`.
185 |
186 | In the second part, when the block becomes irreversible, a new list of `header.new_producers` will be set in the
187 | current pending block, and the `global_property_object` object will be reset.
188 | The pending block number is recorded to `pending_schedule_lib_num`, at which point a new list can be seen
189 | in the nodeos log; for detailed logic, please refer to `controller:: start_block() // Promote proposed schedule to pending schedule.`
190 | That is to say, the change of the new list from `proposed schedule` to `pending schedule` takes about 325 to 336 blocks.
191 | From here on, the `pending_schedule.version` of the `block_header_state` block will be 1 larger than `active_schedule.version`.
192 |
193 | Third, when `pending_schedule_lib_num` becomes irreversible, `active_schedule` will be replaced by `pending schedule`,
194 | and the whole BPs replacement process is completed. from `pending schedule` to `active_schedule`,
195 | it also takes about 325 to 336 blocks.
196 |
197 | The light client of IBC system also needs to inherit these logic of forkdb in order to realize the trusted light client.
198 | However, the light client is implemented in the contract, and the characteristics and limitations of the contract
199 | need to be fully considered, therefore, many adjustments need to be made in the details of implementation.
200 |
201 | **3.3.2 eosio::table("chaindb"), "forkdb" of ibc.chain contract**
202 |
203 | *1. How to determine the LIB of the Lightweight Client (lwc)*
204 | There are two schemes. One is to maintain a whole set of `confirm_count`, `confirmations` and other `block_header_state`
205 | related information according to the logic of forkdb, calculate LIB every time a block is added
206 | The advantage of this method is that real-time LIB values can be obtained accurately. However, for light client,
207 | it concern is that the blocks are irreversible, rather than real-time LIB values. Is there a simpler solution?
208 | According to the above logic, if more than two-thirds of BPs is active, and the depth of one block exceeds 336,
209 | then the block must be irreversible and can be used to verify cross-chain transactions.
210 | It can simplify the complexity of forkdb in the contract.
211 |
212 | The `lib_depth` of the table `global` in the ibc.chain contract is a depth value. When the depth of a block exceeds
213 | this value in a continuous block headers, it is considered irreversible and can be used to verify the transaction.
214 | This value should be set to 336. When the light client checks that more than 2/3 of BPs is active, the blocks
215 | with depth over 336 is considered irreversible. However, add and delete blocks in the contract
216 | It is very CPU-consuming. The actual test shows that it takes 0.5ms CPU to add a block header and 0.2ms to
217 | delete a block header, so 0.7ms CPU is needed for each block header. Whether there will be a huge fluctuation in
218 | the mainnet, which leading to all the blocks that not entered lib to roll back? This is possible and has actually happened.
219 | Therefore, it is necessary to ensure that a cross-chain transaction enters lib and then start processing it.
220 | Plugins can play a role at this time. In the ibc_plugin developed by BOSCORE technical team, parameters are set
221 | to deal with only a certain depth of cross-chain transactions. Thus, the depth in the ibc_plugin and the depth in
222 | the contract add up to more than 336 is works. This is only the initial practice of BOSIBC, the goal is to avoid
223 | consuming huge CPU. The next upgrade, consideration may be given to setting the depth of the contract to 336,
224 | thus, it does not depend on the depth of relay at all. However, adding depth value in ibc_plugin or ibc.chain
225 | will directly prolong the arrival time of cross-chain transactions, thus affecting the user experience.
226 | Therefore, it is necessary to determine a reasonable value according to the actual situation, so as to ensure
227 | sufficient security without losing a good user experience.
228 |
229 | *2. table chaindb*
230 | Table chaindb is the "forkdb" in ibc.chain contract. There is no blog structure in ibc.chain contract.
231 | Unlike `block_header_state`, which is used in forkdb in eosio, chaindb has done a lot of streamlining, only reserved
232 | `Block_num, block_id, header, active_schedule, pending_schedule, blockroot_merkle, block_signing_key` 7 elements,
233 | because BPs schedule takes up a lot of space, so it stores actual schedule information in another table `prodsches`,
234 | and uses ID reference in chaindb to save memory and wasm CPU consumption.
235 |
236 | *3. Genesis Block Header of Lightweight Client*
237 | The light client needs a credible starting point, which is the genesis block header of the light client.
238 | The verification of all the block headers behind is based on the genesis block header.
239 | Genesis block header need `blockroot_merkle`, `active_schedule` and `header` information in `block_header_state`,
240 | in order to verify block signatures. The source code is `chain::chaininit()`. The most important restriction is
241 | that the `pending_schedule` of the genesis block header must be the same as `active_schedule`,
242 | because its difference means this block is a block of the process of BPs schedule replacement.
243 | If we use the block in the process of BPs schedule replacement, we need to synchronize the subsequent blocks,
244 | Until `active_schedule` is replaced by `pending_schedule`, which increased complexity,
245 | so such a block header is not suitable to be a genesis block header.
246 |
247 | *4. How do lightweight client append new block headers*
248 | The way light clients add headers is very similar to forkdb of eosio. See ibc.chain `pushheader()` for the source code.
249 | The first step is to verify that whether it can connect to the latest section by block number.
250 | The second part is whether it is necessary to deal with fork and delete old branch.
251 | In ibc.chain, multiple branches are not saved at the same time. Instead, the former is replaced by the latter to achieve fork processing.
252 | Third, verify whether it can connect to the latest section by block id.
253 | The fourth part, constructs `block_header_state` and verifies BP signature
254 | The core logic is constructing of `block_header_state`, in which the `BP schedule` replacement is processed
255 | to ensure that more than two-thirds of the active BPs producing block (see `section_type::add()`).
256 |
257 | *5. Section*
258 | Section is the core concept and innovation of chaindb, which means a batch of continuous block headers.
259 | Section management is also the core logic of ibc.chain. The purpose of using section is to reduce CPU consumption,
260 | and only when BP schedule changes or inter-blockchain transactions occur, then it needs to synchronize a batch of
261 | block headers. The starting block header of any section cannot be a block in the process of BPs schedule replacement.
262 | That is to say, the `pending_schedule.version` of the starting block header of any section must be equal to
263 | `active_schedule.version`, and the `active_schedule` of the starting block header of a section must be the
264 | same as the `active_schedule` of the previous section, This ensures that there must be no replacement of
265 | BPs schedules between any two sections, and that the complete process of each replacement of BP schedules must
266 | be completed **in** a section, this ensures the credibility of section data.
267 |
268 |
269 | #### 4. Inter-blockchain Transactions
270 | *1. Inter-blockchain Transaction Trilogy*
271 | A inter-blockchain transaction is divided into three processes. The following is an example of transfer EOS token
272 | from the EOS mainnet to the BOS mainnet. First, the user initiates a inter-blockchain transaction `orig_trx`
273 | on the EOS mainnet, the transaction information is recorded in the `origtrx` table of the `ibc.token` contract
274 | on the EOS mainnet side. When the transaction enters lib, IBC relay on the EOS mainnet side (relay_eos ) will
275 | get the transaction and transaction-related information (block information and Merkle path), then pass it to
276 | the relay of BOS mainnet side (relay_bos); relay_bos constructs 'cash' transaction and calls the **cash**
277 | action of the `ibc.token` contract on the BOS mainnet side. If the call succeeds, in the **cash** function,
278 | the corresponding token will be issued to the target user; when the block contain the **cash** transaction enters lib,
279 | relay_bos will get `cash_trx` and related information (block information and Merkle path), then passing them to
280 | relay_eos, relay_eos constructs the **cashconfirm** transaction and calls the **cashconfirm** action of the `ibc.token`
281 | contract on the EOS mainnet side, which deletes the original transaction record in `ibc.token` contract.
282 | then a complete inter-blockchain transaction has been completed.
283 |
284 | *2. Failed Inter-blockchain Transactions*
285 | Inter-blockchain transactions may fail, for example, the designated account does not exist on the peer chain,
286 | or because of the bad network environment, the call to the cash interface fails,
287 | Failed inter-blockchain transactions will be rolled back, that is to say, the assets of users are returned in the original way.
288 | However, the current IBC system is transaction-driven, and failed IBC transactions need to wait until success
289 | IBC transactions are completed before they can be rolled back.
290 | (Note: Subsequent upgrades will roll back failed transactions as soon as possible)
291 |
292 |
293 | *3. How to prevent replay attacks, i.e. double-flower attacks*
294 | Preventing double-flower attacks can be divided into two stages:
295 | 1. A successful cross-chain transaction can only execute **cash** once, otherwise it will result in repeated cash.
296 | 2. For each **cash** transaction, the relevant information must be sent back to the original chain to execute the
297 | **cashconfirm** in order to remove the original transaction information recorded in the contract,
298 | otherwise, the token will be issued to the user on the destination chain, then the token on the original chain returned to the user.
299 |
300 | The **cash** function is the core logic of ibc.token. The `ibc.token` contract records the original transaction ids `orig_trx_id`,
301 | which recently executed cash, and the block number of `orig_trx` of the new cash must be greater than or equal to
302 | the highest block number of all `orig_trx`, that is to say, cash must be done in the order of blocks in the original
303 | chain according to the original transaction. (When cash is executed, the order of cross-chain transactions
304 | in one same block in the original chain is arbitrarily orderable.)
305 | Combined with trx_id checking, we can ensure that a cross-chain transaction can only execute cash once.
306 |
307 | Similarly, the cashconfirm action checks the cash transaction number `seq_num', which must be incremented one by one
308 | to ensure that all cash transactions on the destination chain delete the original transaction record on the original chain.
309 | This ensures that there will be no double spend.
310 |
311 |
312 | ### 5. ibc_plugin
313 | The role of ibc_plugin is divided into two parts: 1. light client synchronization; 2. inter-blockchain transactions delivery.
314 | For core logic, see `ibc_plugin_impl::ibc_core_checker()`.
315 | ibc_plugin refers mainly to the framework of net_plugin.
316 |
317 |
318 | ### 6. Questions and Answers
319 | *1. Question: relay's authority is used in many actions of IBC contracts, so does the IBC system depend on trust in relays?*
320 | Answer: At present, for the sake of security and fast function iteration, relay privileges are added.
321 | With the gradual improvement and maturity of IBC, BOS IBC will support multiple relay channels to avoid single-point risk.
322 |
323 | There are two considerations in validating relay authority:
324 | first. The ibc.chain contract uses the **section** mechanism, and the current logic does not allow adding blocks to the old section,
325 | it is also not allowed to add a block header before a section. If anyone can call the "pushsection" action,
326 | assuming that the range of blocks that should be pushed is 1000-1300, the deliberate troublemaker may push 1100-1300 first,
327 | as a result, 1000-1100 can not be pushed any more, leading to some cross-chain transactions can not be successful.
328 | (Note, this issue will be considered in future versions of optimization.)
329 | second, Considering that IBC system carries a large number of user assets, and the system has not passed the long-term market test,
330 | so the relay authority is increased to reduce security risks.
331 |
332 |
333 | ### 7. Upgrade plan
334 | *1. Compatible with PBFT consistency algorithm*
335 |
336 | *2. Supporting inter-blockchain transactions between multiple side chains in a more elegant way*
337 |
338 | *3. Supporting inter-blockchain commuincation for more types of data than "token"*
339 |
340 |
341 | ### 8. Reference
342 | [Inter-blockchain Communication via Merkle Proofs with EOS.IO](https://steemit.com/eos/@dan/inter-blockchain-communication-via-merkle-proofs-with-eos-io) *Bytemaster*
343 | [Bitcoin](https://bitcoin.org/bitcoin.pdf) *Satoshi Nakamoto*
344 | [Chain Interoperability](https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/5886800ecd0f68de303349b1/1485209617040/Chain+Interoperability.pdf) *Vitalik Buterin*
345 |
346 |
347 |
348 |
--------------------------------------------------------------------------------
/IBC/EOSIO_IBC_Priciple_and_Design_zh.md:
--------------------------------------------------------------------------------
1 | EOSIO跨链通信原理与设计
2 | -------
3 | *Author:Simon [Github](https://github.com/vonhenry)*
4 |
5 | 本文将介绍IBC技术原理，并对BOSCORE团队开发的IBC合约及插件进行深入介绍。
6 |
7 | 为了实现两条EOSIO体系区块链间token的跨链转移，首先需要解决两个难题，1.轻客户端如何实现，2.如何确保跨链交易的完整性和可靠性，
8 | 如何防止双花和重放攻击。下文均以EOS主网和BOS主网为例进行说明，但本文档适用于任何两条EOSIO体系的区块链。
9 |
10 |
11 | ### 一、术语
12 | - BOSIBC
13 | 是指BOSCORE技术团队开发的IBC合约及插件。
14 |
15 | ### 二、关键概念及数据结构
16 | - Simple Payment Verification (SPV)
17 | 简单支付验证技术最早在中本聪的比特币白皮书中提出[Bitcoin](https://bitcoin.org/bitcoin.pdf)，用于验证一笔交易存在于区块链中。
18 | `SPV client`存储着连续的区块头，但没有区块体，因此只需占用很小的存储空间。当获得一笔交易和这笔交易的`Merkle path`后，可以验证这笔交易是否
19 | 存在于区块链上。
20 | - Lightwight client (lwc)
21 | 轻客户端，即`SPV client`，即由区块头组成的一条轻量的链。
22 | - Merkle path
23 | 默克尔路径。为验证一笔交易是否存在于某个区块中，只需要提供交易原始数据和交易在所在区块的`merkle path`，而无需提供整个区块体，通过计算`merkle path`并和区块头中
24 | 记录的`merkle root`对比，若相等，则说明此交易存在于此区块中。`merkle path`也被称为`merkle branch`
25 | - Block Producer Schedule
26 | `BP Schedule`是基于DPOS机制的EOSIO体系公链用于决定生产区块权利的技术，新的`BP Schedule`是由上一批`BP Schedule`包含的`Block Producers`认证通过后生效
27 | 以此确保严格的BP权利交接，在轻客户端中跟随对应主网的`BP Schedule`是IBC系统逻辑的一项核心技术。
28 | - forkdb
29 | EOSIO节点在运行时，有两个底层的db用于存储区块信息，一个是`blog`即`block log`，用于存储不可逆区块，一个是`forkdb`，用于存储可逆区块。
30 | forkdb存储的是当前区块链最顶端的一部分区块信息，一个区块首先要被forkdb接受才能最终进入不可逆区块，IBC系统在合约实现的轻客户端主要参考了forkdb的逻辑。
31 |
32 | ### 三、轻客户端
33 | 为了解决跨链问题，首先要解决的是轻客户端如何实现的问题。
34 | 1. 轻客户端运行在哪里合理，合约中还是合约外，例如插件中；
35 | 2. 若运行在合约中，是实时同步对方链的全部区块头数据，还是根据需要同步一部分区块数据来验证交易，因为如果同步全部区块数据会消耗两条链大量cpu资源。
36 | 3. 若运行在合约中，如何确保轻客户端的可信性，如何防止恶意攻击，如何做到完全去中心化，不依赖对任何中继节点的信任；
37 |
38 | #### 3.1 轻客户端是否运行在合约中
39 | 比特币的轻客户端最早是运行在单个节点上（如个人电脑或去中心化比特币手机钱包），用于验证交易是否存，并查看交易所在区块深度。具体实现可以参考
40 | [breadwallet](https://github.com/breadwallet/breadwallet-core)。
41 |
42 | IBC和去中心化钱包对轻客户端的需求是不同的，去中心化钱包一般运行在个人的手机App上，为用户个人提供交易验证服务，而IBC系统需要的轻客户端
43 | 要对所有人公开可查可信，从这个角度看，一个能够获得大众信任的轻客户端只能运行在合约中，因为只有合约的数据是全局一致不可篡改的，
44 | 运行在合约外则无法实现一个可信的轻客户端，因此BOSIBC将轻客户端运行在合约中，
45 | 源码请查看[ibc.chain](https://github.com/boscore/ibc_contracts/tree/master/ibc.chain)。
46 |
47 | #### 3.2 是否同步全量区块头信息
48 | 在比特币和以太坊的轻客户端中，会寻找一个起点和后续的一些验证点，轻客户端会同步起点后的全量的区块头信息。比特币每年产生的所有区块的区块头体积仅有4Mb，
49 | 按现在移动设备的存储能力，是完全可以容纳的，并且同步这些区块头也不会消耗移动设备大量计算资源。然而EOSIO的情况却很不同，
50 | EOSIO每0.5秒一个区块，实际测试可知，每添加一个区块头到合约中需要消耗0.5毫秒cpu，每删除一个区块头需要0.2毫秒，因此每处理一个区块头需要0.7ms的cpu。
51 | 假设要同步对方EOSIO公链的全量区块头信息，按现在每个区块总的cpu时间200ms计算，也就是需要一条链全部计算的`0.7ms / 200ms = 0.35%`才能实时全量同步
52 | 另一条链的所有区块头， 按实际全网抵押总量为4亿token计算，如果再cpu繁忙时保证IBC系统正常工作，需要为push区块信息的账户抵押
53 | `4亿 * 0.35% = 140万`token，这是个很大的数目。又因为EOSIO倡导多侧链的生态，假设未来有多条侧链和EOSIO主网实现跨链，并且侧链与侧链间
54 | 也实现了一对多的跨链，按1对10计算，每条链需要维护10个轻客户端，则只为了维护这些轻客户端就需要消耗3.5%的单条链全网cpu，这个比例实在是太高了，
55 | 因此需要寻找更合理的方案。
56 |
57 | 设计跨链通信的过程是一种寻找可信证据的过程，有没有一种方案即不需要同步全量区块信息，又可以保证轻客户端的可信性，EOSIO底层已经为实现这一目的有所准备。
58 | 我们先假设，如果BP schedule自始至终不会变化，那么任何时候，当ibc.chain合约中获得一连串的签名验证通过的区块头，比如第`n ~ n+336`个，
59 | 并且有2/3以上的活跃bp在出块，就可以确信第n个区块已经是不可逆的，可以用于验证跨链交易。
60 | 然后，就是需要考虑有BP schedule更换的情况了，当出现BP schedule更换时，不在接受交易验证，直到更换完成，处理BP更换时相对复杂的过程，后续会更详细介绍，
61 | 因此使用这个方案就可以大大降低需要同步的区块头数量，只有在BP列表更换或有跨链交易时才需要同步区块。
62 |
63 | 为了实现这一目的，在ibc.chain中引入了概念`section`，一个section记录的是一段连续的区块头信息，section结构不存储具体的区块头信息，而是记录这一段
64 | 区块头的第一个区块编号(first)和最后一个区块编号(last)，具体区块头信息在`chaindb`中存储，每个section都有一个valid值，在没有bp schedule更替的时候，
65 | 只要有2/3的活跃BP在出块，并且`last - first > lib_depth`则认为`first ~ last - lib_depth`的区块是不可逆的，可以用于验证跨链交易，
66 | 当遇到BP schedule 更替，section的valid变为false，不再接受交易验证，直到schedule更替完成，valid重新变为true之后，继续验证跨链交易。
67 |
68 |
69 | #### 3.3 如何确保轻客户端的可信性
70 |
71 | **3.3.1 forkdb**
72 |
73 | *1.一个新的区块是如何追加到forkdb的*
74 |
75 | 一个运行的nodeos节点维护着两个底层数据结构[blog](https://github.com/EOSIO/eos/blob/master/libraries/chain/include/eosio/chain/block_log.hpp)
76 | 和[forkdb](https://github.com/EOSIO/eos/blob/master/libraries/chain/include/eosio/chain/fork_database.hpp)，
77 | blog用于存储不可逆的区块信息，其存储的数据是序列化的`signed_block`，forkdb用于存储可逆区块信息，其存储的数据是`block_state`，
78 | `block_state`比`signed_block`包含更多区块相关信息。一个区块首先要被追加到forkdb，才可能最终变为不可逆区块而移除forkdb进入blog，
79 | 一个区块的`block_state`信息是如何获得的呢，并非生产区块的BP将所生产区块的`block_state`通过p2p网络传递给其他bp和全节点，p2p网络
80 | 只传递[signed_block](https://github.com/EOSIO/eos/blob/master/plugins/net_plugin/include/eosio/net_plugin/protocol.hpp#L142),
81 | 当一个节点通过p2p网络接收到一个`signed_block`后，它会使用此`signed_block`构建`block_state`并验证签名
82 | [相关函数](https://github.com/EOSIO/eos/blob/master/libraries/chain/block_header_state.cpp#L144)，
83 | 其中需要说明的几个关键点是，1.`blockroot_merkle`，2.`get_scheduled_producer()`,3.`verify_signee()`。
84 |
85 | blockroot_merkle
86 | EOSIO在`block_state::block_header_state`结构中维护了一个`blockroot_merkle`的`incremental_merkle`数据，`incremental_merkle`实际是
87 | 一个完整的`merkle`树的活跃节点，使用`incremental_merkle`只需维护极少的活跃节点信息即可不断累加并获得`merkle_root`，是`block_state`
88 | 中使用的一个关键技术。BOSIBC的ibc.chain合约同样使用了此数据结构。
89 |
90 | `blockroot_merkle`从创世区块id不断累加，但是`signed_block`和`blog`中并没有这个数据，只有forkdb的每个`block_state`中记录着当前block的
91 | `blockroot_merkle`，并且此值被用于计算区块签名。
92 |
93 | get_scheduled_producer()
94 | 此函数根据一个区块的`header.timestamp`计算出应该生成此区块的`producer_key`（见`block_header_state::next()`），为后续验证签名做准备。
95 |
96 | 验证签名相关函数如下
97 | ```
98 | digest_type block_header_state::sig_digest()const {
99 | auto header_bmroot = digest_type::hash( std::make_pair( header.digest(), blockroot_merkle.get_root() ) );
100 | return digest_type::hash( std::make_pair(header_bmroot, pending_schedule_hash) );
101 | }
102 |
103 | public_key_type block_header_state::signee()const {
104 | return fc::crypto::public_key( header.producer_signature, sig_digest(), true );
105 | }
106 |
107 | void block_header_state::verify_signee( const public_key_type& signee )const {
108 | EOS_ASSERT( block_signing_key == signee, wrong_signing_key, "block not signed by expected key",
109 | ("block_signing_key", block_signing_key)( "signee", signee ) );
110 | }
111 | ```
112 | 验证签名的第一步是获得区块摘要，即`sig_digest()`，此函数中用到了`header.digest()`,`blockroot_merkle.get_root()`和`pending_schedule_hash`；
113 | 第二步是获得签名公钥，即`signee()`，通过区块的`producer_signature`和`sig_digest()`计算BP公钥；
114 | 第三步是验证公钥是否正确，即`verify_signee()`，此函数在`block_header_state::next()`被调用；验证通过后，一个区块被追加的forkdb中的分支中。
115 |
116 | 所以在forkdb中每添加一个区块都经过了非常严格全面的效验，核心是包括`blockroot_merkle`，`get_scheduled_producer()`和`verify_signee()`,
117 | 在ibc.chain合约完全继承了forkdb严格的效验。
118 |
119 |
120 | *2.forkdb如何处理分叉*
121 | 当添加一个新的区块导致fordb的head.id和controller_impl的head.id不同时，则重新选择分支。
122 | 源码参考`eosio::chain::controller_impl`的`push_block()`和`maybe_switch_forks()`;
123 |
124 |
125 | *3.LIB如何确定*
126 | EOSIO目前使用的共识方式是dpos，当构造一个区块的`block_header_state`时会设定`required_confs`，此值为当前活跃BP数量的2/3+1，
127 | 在21个BP的情况下，`required_confs`为15。每个区块头中都有`header.confirmed`，用于对前面的区块进行确认，每个区块得到一个确认，
128 | 其`required_confs`会减1，当某个区块的`required_confs`减少到零时，此区块会被最新区块（即forkdb的head）提名为`dpos_proposed_irreversible_blocknum`，
129 | 当某个区块获得了2/3的BP提名后，其变为不可逆区块，即进入LIB。由于确认的信息是在header中传递的，因此一个区块从产生到进入LIB总共需要
130 | 两个2/3轮，也就是 `12 *（ 14 * 2 ） = 336`才会进入LIB，考录到BP每次都是连续出12个区块，只有第一个区块的`header.confirmed`为非零，
131 | 因此当一个BP开始出块时，只有第一个区块会提升LIB，因此实际head和LIB的差距在325至336之间，但是在有BP丢块的情况下，head和LIB的差距可能出现小于
132 | 325至336。
133 |
134 | *4.BP列表是如何更换的*
135 | 在pow的区块链中，比如比特币和以太坊，是选择算力累加最大的分叉作为主链，一个区块只有包含一定的算力才有可能被认可，最终变为不可逆。
136 | 而在以dpos为共识算法的EOS中，区块被认可的标记是BP签名，因此BP列表在EOSIO中具有至关重要的地位。IBC的轻客户端同样需要维护BP列表和BP列表的更换，
137 | 因此需要透彻分析BP列表的更换逻辑。
138 |
139 | 第一步，在系统合约`eosio.system`的`onblock()`函数中，系统会每分钟一次尝试更新bp列表`update_elected_producers( timestamp )`，此函数最终调用
140 | wasm接口`set_proposed_producers()`，通过一系列检查后，会将新的schedule和当前区块编号存到`global_property_object`对象中。
141 |
142 | 第二部，当此区块变为不可逆之后，会在当前的pending区块中设置新的名单`header.new_producers`，并重置`global_property_object`对象，当前
143 | pending区块编号会被记录到`pending_schedule_lib_num`，此时在nodeos日志中可以看到新的名单；具体逻辑参考`controller::start_block() // Promote proposed schedule to pending schedule.`。
144 | 也就是说新的名单从`proposed schedule`变为`pending schedule`大约需要经历325至336个区块。从这里开始，
145 | 后面区块`block_header_state`的`pending_schedule.version`会比`active_schedule.version`大1.
146 |
147 | 第三步，当`pending_schedule_lib_num`变为不可逆后，`active_schedule`会被`pending schedule`替换，整个的BP更换过程完成。
148 | 从`pending schedule`出现到其变为`active_schedule`同样需要经历约325至336区块。
149 |
150 |
151 | IBC系统的轻客户端同样需要继承forkdb的这些逻辑，才能实现可信的轻客户端。然而，轻客户端是在合约中实现，需要充分考虑合约的特性和限制，
152 | 因此在实现细节上，需要做诸多调整。
153 |
154 | **3.3.2 eosio::table("chaindb"), ibc.chain合约中的forkdb**
155 |
156 | *1.轻客户端(lwc)的LIB如何确定*
157 | 有两种方案，一种是完全按forkdb的逻辑，维护一整套`confirm_count`和`confirmations`等`block_header_state`相关信息，每添加一个区块
158 | 计算一次LIB，这样做的优点是可以准确获得实时LIB值，然而对于轻客户端来说，其关心的是区块已经不可逆，而并非实时的精确LIB值。有没有更简单的方案呢，
159 | 根据上述的逻辑，如果有活跃的2/3以上的BP在出块，并且某个区块的深度超过336，则此区块一定是不可逆的，可以用于验证跨链交易；使用这种方案，
160 | 可以简化合约中forkdb的复杂度。
161 |
162 | ibc.chain合约中表`global`的`lib_depth`是一个深度值，当在一段连续的区块头中，某个区块头的深度超过此值时，则认为不可逆，可以用于验证交易了。
163 | 此值应该设置多少合适呢，可以设置成336，当轻客户端检查到有2/3以上的BP在出块，则认为深度超过了336的区块是不可逆的。然而在合约中添加和删除区块头
164 | 是非常耗cpu的，实际测试可知，每添加一个区块头需要消耗0.5毫秒cpu，每删除一个区块头需要0.2毫秒，因此每个区块头需要0.7ms的cpu。
165 | 是否会出现主网巨大波动，导致没有进lib的区块全部回滚呢，这是有可能的，实际也发生过，因此要必须确保一笔跨链交易所在区块进入lib，再开始处理。
166 | 插件在此时可以起到一定的作用，在BOSCORE技术团队研发的ibc_plugin中，设置了参数，只处理一定深度内的跨链交易，这样，插件中的深度和合约中的深度相加
167 | 超过336即可。这只是BOSIBC初期的做法，目的是避免消耗大量cpu，后续可能会考虑将合约中的深度设置为336，从而完全不依赖中继的深度，然而无论是插件
168 | 还是合约中增加深度值，都会直接延长跨链交易到账时间，从而影响用户体验，因此需要根据实际情况确定一个合理的值，从而即保证足够安全又不失良好的用户体验。
169 |
170 | *2.表chaindb*
171 | 表chaindb是ibc.chain合约中的forkdb，ibc.chain合约中没有blog结构，和eosio中forkdb使用的`block_header_state`不同，chaindb进行了大量精简，只保留了
172 | `block_num、block_id、header、active_schedule、pending_schedule、blockroot_merkle、block_signing_key`7个数据，又因为
173 | bp schedule需要占用大量空间，因此在另外的表`prodsches`中存储实际schedule信息，在chaindb中用id引用，以节省内存占用和wasm cpu消耗。
174 |
175 | *3.轻客户端的创世区块*
176 | 轻客户端需要一个可信的起点，此起点是轻客户端的创世区块头，后面所有区块头的验证都是基于创世区块头的信息。
177 | 创世区块头需要`block_header_state`中的`blockroot_merkle`，`active_schedule`和`header`信息，才能验证区块签名。
178 | 源码为`chain::chaininit()`，最重要一个限制是，创世区块头的`pending_schedule`必须和`active_schedule`相同，因为其不同意味着
179 | 此区块是bp列表更替过程中的一个区块，如果使用更替过程中的区块，需要同步后续的区块，直到`active_schedule`被`pending_schedule`替换，
180 | 增加了复杂度，因此这样的区块不适合作为创世区块。
181 |
182 | *4.轻客户端是如何添加新区块的*
183 | 轻客户端添加header的方式和和eosio的forkdb非常类似。源码见ibc.chain的`chain::pushheader()`。
184 | 第一步，通过区块编号验证是否能够连接到最新的section
185 | 第二部，是否需要处理分叉，删除旧数据。在ibc.chainz中不会同时保存多个分支，而是以后者替代前者的方式实现对分叉的处理。
186 | 第三步，通过区块id验证是否能够连接到最新的section
187 | 第四部，构造`block_header_state`，并验证BP签名
188 |
189 | 其中最核心的是构造`block_header_state`，在这个过程中处理的`BP schedule`的更换，确保有2/3以上活跃BP（见`section_type::add()`）。
190 |
191 | *5. Section*
192 | Section是chaindb的核心概念和创新，意思是一段连续的区块头，Section的管理也是最ibc.chain的核心的逻辑。
193 | 使用section的目的是降低cpu消耗，只有在BP schedule有变化或有跨链交易时才需要同步一部分区块头。
194 | 任何section的起始区块不能是 bp schedule 更换过程中的区块，也就是说，任何一个section的起始区块的`pending_schedule.version`必须等于
195 | `active_schedule.version`，并且一个section的起始区块头的`active_schedule`必须和前一个section最后区块的`active_schedule`相同，
196 | 这样就保证了在任意两个section之间一定不存在BP schedule的更换，每一此BP schedule更换的完整过程必须在某个section中完成，从而确保
197 | section数据的可信性。
198 |
199 | ### 四、跨链交易
200 |
201 | *1. 跨链交易三部曲*
202 | 一笔跨链交易分为三个过程，下面以将EOS从EOS主网跨链转账到BOS主网为例说明，首先用户在EOS主网发起一笔跨链交易`orig_trx`，在EOS侧`ibc.token`合约的
203 | `origtrx`表中会记录此交易信息，当这笔交易所在区块进入lib后，EOS侧IBC中继(relay_eos)将此交易和交易相关信息(区块信息及Merkle路径)
204 | 传递到BOS侧中继(relay_bos)；relay_bos构造cash交易并调用BOS侧`ibc.token`合约的cash接口，如果调用成功，
205 | cash函数中会给目标用户发行对应的token；等cash交易所在的区块进入lib后，relay_bos会将`cash_trx`和此交易相关信息（区块信息及Merkle路径）
206 | 传递到relay_eos，relay_eos构造cashconfirm交易并调用EOS侧`ibc.token`合约的cashconfirm接口，cashconfirm会删除EOS侧`ibc.token`合约
207 | 中对`orig_trx`的记录，至此一笔完整的跨链交易完成。
208 |
209 | *2. 跨链失败的交易*
210 | 跨链交易是可能失败的，比如指定的账户在对方链上不存在，或者由于网络环境恶劣，导致调用cash接口失败，未能成功跨链的交易会被回滚，即原路退还用户的资产，
211 | 然而现在的IBC系统是交易驱动的，失败的IBC交易需要等到有成功的IBC交易完成后才会被回滚。（注：后续版本升级会让失败的交易尽快回滚）
212 |
213 | *3. 如何防止replay攻击，即双花攻击*
214 | 防止双花攻击分为两个阶段：
215 | 1，一笔成功的跨链交易只能执行一次cash，否则会造成重复cash。
216 | 2，对于每一个cash交易，必须将其相关信息传回原链执行cashconfirm，以消除合约中记录的原始交易信息，否则会出现即在目的链上给用户发行了token，
217 | 又将原链的token退还给了用户。
218 |
219 | cash函数是ibc.token的核心逻辑，`ibc.token`合约中记录着最近执行cash的原始交易id，即`orig_trx_id`，并且新的cash的`orig_trx`的区块编号必须
220 | 大于或等于所有`orig_trx`所在的区块编号，也就是说必须按原始交易在原链按区块的顺序进行cash，（执行cash时，原链某个区块内的跨链交易顺序是无关紧要的）
221 | ，再结合trx_id检查，可以确保一笔跨链交易只能执行一次cash。
222 |
223 | 同样，cashconfirm接口会检查cash交易的编号`seq_num`，此编号必须逐一递增，以确保所有在目的链上的cash交易都会删除在原链上的原始交易记录，
224 | 从而确保不会出现双花的情况。
225 |
226 |
227 | ### 五、插件
228 |
229 | 插件的作用分为两部分：1，轻客户端同步；2，跨链交易传递。
230 | 核心逻辑请参考`ibc_plugin_impl::ibc_core_checker()`
231 |
232 | ibc_plugin主要参考了net_plugin的框架。
233 |
234 |
235 | ### 六、问答
236 |
237 | 1. 问：IBC合约的多个action中用到了relay的权限，那么，本IBC系统是否依赖对中继的信任。
238 | 答：目前出于安全以及快速功能迭代的考量，特意添加了中继权限，随着功能逐渐完善 BOS IBC 方案会支持多中继机制，以避免单点风险。
239 |
240 | 验证relay权限处于两种考虑：1，ibc.chain合约使用了section的机制，现在的逻辑不允许为旧的section添加区块，也不允许在一个section前面
241 | 添加区块头，如果任何人都可以调用pushsection接口，假设应该push的区块范围是1000-1300，故意捣乱的人可能会抢先push 1100-1300，
242 | 从而导致1000-1100无法被push，进而导致一些跨链交易无法成功，（注，此问题会在后续版本中考虑优化）；2，考虑到IBC系统承载着
243 | 大量用户资产，并且本系统还未经过长期市场考验，因此增加了relay权限，以降低安全风险。
244 |
245 |
246 | ### 七、升级计划
247 |
248 | *1. 兼容pbft*
249 |
250 | *2. 以更优雅的方式支持多条侧链&EOS主链互相跨链*
251 |
252 | *3. 支持token以外其他类型数据的跨链*
253 |
254 |
255 | ### 八、参考
256 | [Inter-blockchain Communication via Merkle Proofs with EOS.IO](https://steemit.com/eos/@dan/inter-blockchain-communication-via-merkle-proofs-with-eos-io) *Bytemaster*
257 | [Bitcoin](https://bitcoin.org/bitcoin.pdf) *Satoshi Nakamoto*
258 | [Chain Interoperability](https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/5886800ecd0f68de303349b1/1485209617040/Chain+Interoperability.pdf) *Vitalik Buterin*
259 |
260 |
261 |
262 |
263 |
264 |
265 |
--------------------------------------------------------------------------------
/LIB/Algorithm_for_improving_EOSIO_consensus_speed_based_on_Batch-PBFT.md:
--------------------------------------------------------------------------------
1 | # Algorithm for improving EOSIO consensus speed based on Batch-PBFT
2 |
3 | ## 1 Background
4 | #### 1.1 Phenomenon
5 | There is a gap of 325+ blocks between the chain height of the main network and the consensus height, which is equivalent to a time difference of ~3 minutes. In other words, the current submitted trx needs to wait ~3 minutes to confirm whether it is recorded in the chain. This performance is unbearable for many DApps, especially those that require immediate confirmation.
6 |
7 |
8 | #### 1.2 Reasons
9 | * The reason for this phenomenon on the main network is that in EOS's DPOS-based consensus algorithm, all block synchronization and acknowledgment information can only be sent when it is out of the block. That is to say, in the case where the BP1 is out of the block (the block is BLK) and the BP1~BP21 round out block, BP2~BP21 will receive and verify BLK one after another, but all BPs can only send confirmation messages to BLK when they are out of the block. This is also why we see the logs in the nodes. When each BP comes out of the first block in the schedule, `confirmed` is always 240. The fastest speed of DPOS+Pipeline BFT consensus (ie, the smallest gap between head and LIB) is 325.
10 |
11 |
12 | * 240 = (21-1)*12
13 | This is actually the sum of all the blocks in the previous round (in the case of good network conditions). Each node maintains a vector `confirm_count` with a length of up to 240 and an initial value of 14 in `block_header`, corresponding to all blocks received but not agreed upon and the required number of acknowledgments. Whenever more than one BP acknowledges the block, the value of the corresponding block is -1, until the required number of acknowledgments of a block is reduced to 0, the block and all previous blocks enter the consensus ([related code] (https: //github.com/EOSIO/eos/blob/905e7c85714aee4286fa180ce946f15ceb4ce73c/libraries/chain/block_header_state.cpp#L188)).
14 |
15 | * 325 = 12*(13+1+13) + 1
16 | The entire network needs 15 people to confirm to reach a consensus. Everyone by default confirms their own blocks, so each block requires 14 people's implicit confirm and (explicit) confirm. The 14th BP has confirmed that the number of people has reached 15 since it was included in the block, so it will issue implicit confirm and (explicit) confirm. Then ideally, after a block is generated from it, it will not be able to get the consensus of the whole network and enter the LIB until the first block produced by the 28th BP. Therefore, there are the above calculations.
17 |
18 |
19 | * ** We believe that all BPs do not need to wait until the block to confirm other blocks, use PBFT** (Practical Byzantine Fault Tolerance[1])** instead of Pipeline BFT, let The real-time confirmation of the blocks currently being produced between the BPs enables the entire system to eventually reach a near real-time consensus speed. **
20 |
21 | ## 2 Algorithm Core
22 | * Retain the DPOS's BP Schedule mechanism and, like EOS, impose strong constraints on synchronized clock and BP Schedule.
23 |
24 | * Remove the Pipeline BFT part of the consensus in EOS (ie remove the implicit confirm and (explict) confirm part of the original EOS block), because in extreme cases it may conflict with PBFT consensus results.
25 |
26 | * Consensus communication mechanism uses existing p2p networks for communication, but increases communication costs, using the PBFT mechanism to broadcast prepare and commit information.
27 |
28 | * Optimized by batch (replaces the requirement for consensus on each block in PBFT), a batch consensus can be reached to approximate the ideal state of real-time BFT and reduce network load.
29 |
30 |
31 | ## 3 Basic concepts
32 | #### 3.1 The concrete realization of BP change in DPOS
33 | * In the current code, the voting rank is refreshed every 60s (120 blocks) ([related code] (https://github.com/EOSIO/eos/blob/8f0f54cf0c15c4d08b60c7de4fd468c5a8b38f2f/contracts/eosio.system/producer_pay.cpp#L47) ), if the first 21 changes, will issue the `promoting proposed schedule` ([related code] at the next refresh ranking (https://github.com/EOSIO/eos/blob/8f0f54cf0c15c4d08b60c7de4fd468c5a8b38f2f/libraries/chain/controller. Cpp#L909))
34 |
35 | * When a block containing `promoting proposed schedule` enters LIB, BP will update the `pending_schedule` in its own block header.
36 |
37 | * After 2/3 +1 BP nodes have updated the block header, `pending schedule` has reached a consensus. BP will update the `active schedule` to the value of the `pending schedule` at this time, and start to block out according to the new BP combination. The whole process needs to go through at least two rounds of complete outbound.
38 |
39 | * Every new BP combination must be able to reach a consensus to be effective. In other words, if 7 or more nodes in the network are unable to communicate properly, then no new BP can be generated by voting. The LIB of the network will stay at the consensus point where the node crashes.
40 |
41 | * DPOS can effectively avoid some of the fork problems, so the DPOS consensus mechanism for BP elections will still be used. All BP changes will not take effect until the probability schedule enters LIB.
42 |
43 | #### 3.2 Prerequisites for PBFT
44 | * If there are f Byzantine nodes in the network, then the total number of nodes n is required to satisfy n≥3f+1. A Byzantine node is a node that is inconsistent in its external state, including a node with a main action and a node that fails or partially fails due to network reasons.
45 |
46 | * All information is ultimately reachable: All communication information may be delayed/out of order/discarded, but retrying will ensure that the information will eventually be delivered.
47 |
48 |
49 | #### 3.3 The key concepts in PBFT correspond to DPOS
50 | **pre-prepare** means that the primary node receives the request and broadcasts it to all replicas in the network. It can be analogized to BP in DPOS and broadcast to the whole network.
51 |
52 |
53 | **prepare** means that the replica will broadcast the request to the entire network after receiving the request. The analogy is DPOS. All nodes receive the block and verify the success of the broadcast of the received information.
54 |
55 |
56 | **commit** means that the replica receives enough prepare messages for the same request to broadcast the request to the entire network. It can be analogized that the node in DPOS receives enough prepare messages for the same block, and proposes a proposed lib message.
57 |
58 | **committed-local**, which means that the replica receives enough commit messages for the same request and completes the verification. It can be compared to the LIB promotion in DPOS.
59 |
60 |
61 | **view change** means that the primary node loses the trust of the replica for various reasons, and the entire system changes the primary process. Since EOS adopts the DPOS algorithm, all BPs are determined in advance by voting. The order of the whole system is completely unchanged under the same BP schedule. When the network is in good condition and the BP schedule is unchanged, it can be considered. There is no view change.
62 | After the introduction of PBFT, in order to avoid the fork caused the consensus does not advance, join the view change mechanism, discard all unconsented blocks for replay, and continually try again until the consensus is continued.
63 |
64 | **checkpoint**, which refers to the record of consensus evidence at a block height to provide security proof. When enough checkpoints of the replica are the same, the checkpoint is considered to be stable. The checkpoint generation consists of two major categories. One is fixed k block generation; the other is a special point that needs to provide security proof, such as a block with a change in BP schedule.
65 |
66 |
67 | ## 4 Unoptimized version overview
68 |
69 | the term:
70 | * v: view version
71 | * i: BP's name
72 | * BLKn: the nth block
73 | * dn: Consensus message digest corresponding to the nth block digest
74 | * σi: signature of BP named i
75 | * n: height of the block
76 |
77 | All BPs agree on each block in order, using the PBFT mechanism. The following subsections describe:
78 |
79 |
80 | #### **4.1 Under normal circumstances (no BP changes or forks, and the network is in good condition)**
81 | The **pre-prepare** phase is no different from the current logic, that is, the BP broadcasts its signed block.
82 |
83 |
84 | **prepare** stage, BPi receives the block BPKn of the current BP signature, and is verified (PREPARE,v,n,dn,i)σi message, waiting for consensus. When BPi receives a 2/3 node and sends a PREPARE message to BLKn under view v, it is considered that the peer of the block has reached a consensus in the network. The PREPARE message has been sent and cannot be changed.
85 |
86 |
87 | **commit** stage, when BLKn is marked as ***prepared***, BPi is issued (COMMIT,v,n,dn,i)σi. It should be noted that PBFT implements security by guaranteeing strict order, so the consensus on all nodes is also strictly in order, that is, (PREPARE, v, n, dn,i)σi is issued under the premise that BLKn-1 is at least ***committed under the same view *** Status.
88 |
89 |
90 | **LIB promotion under the whole network perspective**, when BPi receives 2/3 nodes, it sends a COMIT message to BLKn, BPi believes that there is a consensus on the commit of this block in the network, that is, the block has reached a consensus, this block is marked as *committed* state, and the LIB is raised to the current height n, and then the next block is prepared. If the height of the block is Hi, the LIB heights of all BPs are arranged in descending order to obtain a vector Vc of length L, from the perspective of the whole network, Vc[2/3L] and below LIB can be considered as ***stable***, Vc[2/3L] is the LIB height of the whole network at this time.
91 |
92 |
93 | ** For the same block, only the sufficient PREPARE message is collected before entering the commit phase. Similarly, only after collecting enough COMMIT messages, will start the prepare for the next block, otherwise it will be resent until the number of messages meets the requirements or the view change (see below). **
94 |
95 | #### **4.2 When BP changes, **
96 | **pre-prepare** phase, no difference from 4.1.
97 |
98 |
99 | In the **prepare** and **commit** phases, due to the timing of the consensus between different BPs on the information of BP changes, there will be an inconsistent state between the BPs for the schedule.
100 | Taking BPi as an example, BPi receives the block BLKn of the current BPc signature, if Most BP's active schedule has been changed to S', and BPi is still S, then BPi will continue to wait for the PREPARE information sent by BP in S, which cannot Enter the commit phase.
101 | However, at this time, most nodes in the network will still reach a consensus with each other, resulting in an increase in the LIB of the entire network. If BPi receives enough commit information under the same view, BPi enters the commit-local state and promotes its own LIB.
102 |
103 |
104 |
105 | #### **4.3 When a fork is generated**
106 | **pre-prepare** phase, no difference from 4.1.
107 |
108 | **prepare** and **commit** phases, when BPi does not collect enough PREPARE or COMMIT messages in timeout=T, that is, the consensus is not promoted during this time period, The VIEW-CHANGE message initiates a view change and no longer receives any messages except VIEW-CHANGE, NEW-VIEW, and CHECKPOINT.
109 |
110 | **view change** stage, BPi is issued (VIEW-CHANGE, v+1, hlib, n, i)σi< /sub> message. When 2/3 +1 v'=v+1 VIEW-CHANGE messages are collected, they are sent by the next BP in the schedule (NEW-VIEW, v+1, n, VC, O)σ< Sub>bp message, where VC is all VIEW-CHANGE messages including BP signatures, and O is all unrecognized PRE-PREPARE messages (between hlib and Between nmax). After other BPs receive and verify that the NEW-VIEW message is valid, discard all blocks that are not currently agreed, and re-prepone the prepare and commit phases based on all PRE-PREPARE messages.
111 | If the view change fails to reach a consensus within timeout=T (there is no correct NEW-VIEW message sent), a new round of v+2 view change is initiated, the wait time is timeout=2T, and so on, until the network status Convergence, the consensus began to improve.
112 |
113 |
114 | **Remarks**: The original PBFT does not have a fork problem, because PBFT will only process the next request after a request has reached a consensus.
115 |
116 |
117 | ## 5 Problems with unoptimized versions:
118 | #### 5.1 Consensus speed
119 | When the consensus speed of a block is less than 500ms, that is, the transmission of two rounds of messages can receive enough confirmation numbers within 500ms, the gap between head and LIB can be stabilized and can approach 1 block, that is, real-time consensus. When the average consensus speed for a block is greater than or equal to 500ms or the network state is extremely poor, resulting in too many retries, the algorithm may be slower than DPOS+Pipeline BFT.
120 |
121 | #### 5.2 Network overhead
122 | Suppose the node in the network is N, the message propagation uses the gossip algorithm, and the block size is B. Then the message that DPOS needs to propagate is N2, and the required bandwidth is BN2.
123 | Assuming that the PREPARE and COMMIT message sizes are p and c, respectively, the number of messages that PBFT+DPOS needs to propagate is (1+rp+rc)N2 , where 1 is the pre-prepare transmission, rm, rc is the number of retries for prepare and commit, and the required bandwidth is (B+pr p+crc)N2. When the p and c optimizations are small enough, the extra bandwidth overhead depends mainly on the number of retries.
124 |
125 | ## 6 Overview of the optimized version
126 | #### 6.1 Implement batch consensus through adaptive granularity adjustment
127 | ##### 6.1.1 batch strategy
128 | The height of LIB is hLIB
129 | The height of the block at the highest point in the fork is hHEAD
130 | The block height involved in the BP schedule change is hs
131 | Batch consensus batch:
132 | * batchmin = 1
133 | * batchmax = min(default_batch_max, hHEAD - hLIB)
134 |
135 | When batchmax does not contain BP Schedule changes, batch = batchmax
136 | Batch = hs - 1 when batchmax contains BP Schedule changes and hLIB < hs
137 | When batchmax contains BP Schedule changes and hLIB == hs, batch = batchmax
138 |
139 | ##### 6.1.2 Batch Consensus Principle
140 | When there is no fork condition, the above construction can be compared with the consensus in the view of PBFT. And based on the basic structure of Merkle Tree, when most nodes can reach consensus on BLKn Hash, all previous blocks should be consensus. The total order of the block is guaranteed here.
141 |
142 | When there is a fork condition, the PREPARE information cannot be changed, otherwise it may appear as a Byzantine error. At this point, it is necessary to continuously resend the current PREPARE message until the network reaches a consensus or triggers a timeout to initiate a view change.
143 |
144 | ##### 6.1.3 Implementation Method
145 | * Whenever a new block is received, BP generates PREPARE information through the batch policy for caching and broadcasting.
146 |
147 | * Each BP maintains a minimum water level h for the block_header, and the highest water level H, corresponding to the lowest point and the highest point that have not yet reached consensus.
148 |
149 | * Maintain two vectors of length (H-h) Vp & Vc at the same time, including the number of PREPARE messages and COMMIT messages required for each block between water levels.
150 |
151 | * Each time a PREPARE message (or COMMIT message) of height n is received, it is verified by the signature and digest of the message and confirmed that he is in the same fork as himself, and then Vp(V< All values in the sub>c) (h ≤ n) -1.
152 |
153 | * Constantly resend the PREPARE message (or COMMIT message) with the height H on the same fork until the consensus is reached or the timeout triggers View Change (based on New View to restart the PBFT consensus, v' = v+1).
154 |
155 | * When a block at height x (h ≤ x ≤ H) collects more than 2/3 +1 PREPARE messages, the block contents from h to x are sequentially executed and all blocks of (h ≤ x) are marked as *prepared* And then automatically issue a COMIT message of height x.
156 |
157 | * When a block at height y (y ≤ H) collects more than 2/3 +1 COMMIT messages, the block contents from h to y are sequentially executed and all blocks of (h ≤ y) are marked as *committed*. At this point, all blocks that think ≤y have reached a consensus and raise their LIB height to y.
158 |
159 | * Generate checkpoints every few blocks to improve performance. When the latest checkpoint of more than 2/3 +1 in the network reaches a certain height c and is on the same fork, the checkpoint is considered stable.
160 |
161 | ##### 6.1.4 view change strategy
162 | * BP becomes the backup of the previous person according to the schedule of the block, ensuring that only one person can be found in the primary after each view change.
163 |
164 | * When the network begins to enter the view change, NEW-VIEW should re-consider the block between the lowest point h and the highest point H seen by 2/3 +1 people.
165 |
166 | * The BP that issued NEW-VIEW should include all VIEW-CHANGE messages in the message, and calculate h and H based on all VIEW-CHANGE messages, and exceed (2/3 +1) in the [h, H] interval. The fork of the person's choice is issued.
167 |
168 | * When BP receives the NEW-VIEW message and verifies it, it repeats the prepare based on the content of NEW-VIEW.
169 |
170 | * If the view change cannot be completed within timeout=T, a new round of view change of v+2 will be initiated until the network has reached a consensus on the choice of fork.
171 |
172 | #### 6.2 Avoid fork risk by always preparing the longest chain and combining view change
173 | * When BP receives multiple forks, it should make a preference for the longest chain that can be seen at present, taking the longest-live-fork principle.
174 |
175 | * BP should stagger the time point of BP switching when making a prepare, so as to avoid choosing a fork supported by a few people.
176 |
177 | * **BP once you make a prepare for a fork, you can no longer change the prepare message, otherwise it may become a Byzantine error, ** BP needs to:
178 | 1) Constantly resend the previous PREPARE message, waiting for the final consensus. Even if this fork is not the longest chain, because there are more people to support, you should choose this fork;
179 | 2) Or wait for timeout=T, initiate a view change, all BP starts a new BPFT consensus based on the fork issued by NEW-VIEW;
180 | 3) Receive a COMMIT message or checkpoint that exceeds (2/3 +1) the same fork, discarding the current state synchronization to the height reached by the majority.
181 |
182 | #### 6.3 Implementing GC and improving synchronization performance through Checkpoint mechanism
183 | * BP continuously broadcasts its current checkpoint status within the network and receives checkpoints from other people.
184 |
185 | * When there are more than (2/3 +1) people on the same branch whose checkpoint is higher than c, it is considered that CHECKPOINTc has been stable, and all caches such as PREPARE and COMMIT messages with a height lower than c are deleted.
186 |
187 | * By verifying the correctness of the checkpoint, you can greatly improve the synchronization speed of the node.
188 |
189 | ## 7 FAQ
190 | DPOS related issues (see 1.2)
191 |
192 | 1. Briefly explain how DPOS works.
193 | Temporary
194 | 2. Why DPOS lib is 12 12 ups
195 | Temporary
196 | 3. Why is the gap between HEAD and LIB of DPOS so large?
197 | Temporary
198 | 4. How does DPOS work when BP changes?
199 | Temporary
200 | 5. How is the data between nodes currently synchronized?
201 | Temporary
202 |
203 | PBFT related issues
204 |
205 | 1. Brief description of PBFT
206 | Temporary
207 |
208 | DPOS-PBFT related issues
209 |
210 | 1. Briefly explain how DPOS-PBFT works
211 | See 5
212 |
213 |
214 | 2. Why can't I only broadcast the information of prepare once?
215 | When there is a fork (or BP change) in the network, if there is only PREPARE information, all nodes cannot respond to the view change of other nodes, which will lead to hard fork. For example: Due to the nature of distributed networks, information can be delayed or disrupted. Suppose now that there are three consecutive blocks of BP A, B, C. If B does not receive the last block of A, then he will continue to block from the second to last block. This causes two forks to choose F1 F2. Assuming that the last block of A contains information about BP changes (the block is in F1), then the node that selected F1 needs a new BP S1 for consensus, and F2 The node needs the original BP S2 for consensus. The consensus group has changed, and it is very likely that both sides will eventually enter a consensus state, which will lead to the overall network bifurcation.
216 |
217 |
218 | 3. How does the prepare and commit retransmission mechanism work?
219 | When a given acknowledgment is not received for a block that is *prepared* or *committed* after a given timeout T, the same message is retransmitted one more time until enough acknowledgments are collected or A view change has occurred.
220 |
221 |
222 | 4. Is there a fork risk when the BP set changes?
223 | See 4.2
224 |
225 |
226 | 6. Do you need to wait for the consensus to complete before you can continue to block
227 | The block can continue, and the consensus only affects the height of the LIB.
228 |
229 |
230 | 7. If the Nth block does not meet the BFT consensus number, but the N+1th block receives enough confirmation, what should I do?
231 | For the optimized algorithm, you can start collecting consensus messages based on N+2 blocks.
232 |
233 |
234 | 8. Will continuous spurs be forked because the consensus is not quickly reached?
235 | No, at least the status of DPOS will eventually lead to consensus on the longest chain.
236 |
237 |
238 | 9. Does the BFT commit information need to be written to the block?
239 | All messages (issued and received) are only local. But they need to be kept for a period of time to provide evidence for peers.
240 |
241 |
242 | 10. What is the extra overhead?
243 | See 5.2
244 |
245 |
246 | 11. Can the speed of consensus really improve? If the BFT consensus average time is >500ms, the height of BFT is lower than DPOS.
247 | See 5.1
248 |
249 |
250 | ## 8 Reference
251 | [1] http://pmg.csail.mit.edu/papers/osdi99.pdf
--------------------------------------------------------------------------------
/LIB/BOS_Batch_PBFT_I.md:
--------------------------------------------------------------------------------
1 | # PART I BOS LIB Acceleration Solution: Batch PBFT
2 | ## 1. LIB Acceleration Introduction
3 | ### 1.1 LIB Introduction
4 | Last Irreversible Block(LIB) describes the finality state of EOS. It is a consensus concept which guarantees immutability of blockchain. There are two major approaches to finality: one is probability-based and the other is signature-based. Bitcoin is a classic probability-based finality example while EOS is signature-based. the difference details are worth another article but one is needed to be mentioned here in order to better understand LIB Acceleration solution: block producers are pre-determined in EOS by DPOS instead of mining lottery in Bitcoin. This also can be understood as: if all/major delegated block producers in EOS agree one LIB proposal, the finality is made accordingly.
5 | ### 1.2 LIB Acceleration
6 | In Pipelined BFT, BPs implicitly prepares/commits a target block by producing a new block and link to the target block. Therefore, each block producer can only do this every 21*6=126 seconds. A full round of consensus requires two rounds (one for prepare, the other for commit) which is 126 * 2 = 252 seconds. One optimization has been made because 1. one block is enough to send the implicit message 2. majority block producers are enough to guarantee LIB and there is no need to wait for a full round for all block producers. Therefore the actual time spend is reduced to 1 + 12 * 14 + 12 * 13 blocks = 325 blocks = 162.5 seconds ( this number is the minimum time required for LIB, however, if some blocks are missing, the block number 325 will be less but the time should remain the same.)
7 |
8 | In LIB Acceleration, the core difference to pipeline BFT is that we changed implicit BFT messages to explicit messages. The philosophy behind is to trade network overhead (space) to LIB efficiency (time).
9 |
10 | In order to achieve the goal, two core optimizations have been made:
11 | 1. **DPOS and PBFT**:
12 |
13 | In order to support the dynamic on-chain vote, DPOS and PBFT need to be integrated. Therefore, BP schedule changes have to be carefully designed and guaranteed correctness. For example, on-chain voting causes a BP schedule change from v10 to v11 and this action happens in block #10000. after block #10000 enters LIB, BPs V11 should take control and start to advance LIB while produce blocks. However, block #10000 can become LIB only if a majority of BPs v10 agrees. Furthermore, in an asynchronized network, there are non-negligible latencies and chances of dropping messages and blocks (such as micro-forks, the situation will be even worse if the block contains BP schedule change is dropped), which makes BP schedule transit even harder.
14 |
15 | 2. **Batch-PBFT**:
16 |
17 | In origin PBFT, every block is processed one by one. This is obviously not efficient when in EOS blocks are produced constantly every half seconds. Therefore, we optimized this part and allows each BP to prepare/commit batch by batch. There is no pre-defined batch size, each BP can batch as many as they can, which means the LIB catches up very fast when recovering from a bad network in certain circumstances.
18 |
19 | ## 2. DPOS Pipeline BFT vs DPOS Batch PBFT
20 |
21 | The highlight features comparison is listed as follows:
22 |
23 | | | **DPOS Pipeline BFT** | **DPOS Batch PBFT** |
24 | |:----|:----|:----|
25 | | **time** | ~162.5 seconds | ~3 seconds |
26 | | **cpu/net overhead** | N.A. (through blocks) | CPU: constant overhead**, estimated around 8-10%
Net: constant overhead**, estimated equivalent to 42 transfer transactions
**The overhead is constant and is not sensitive to other factors such as TPS, network topology and block produce interval. |
27 | | **liveness** | 100%, produce every 0.5 seconds | 100%, produce every 0.5 seconds |
28 | | **safety** | tolerable up to 6 byzantine nodes | tolerable up to 6 byzantine nodes |
29 | | **safety in edge case** | not safe, a hard fork may happen when two separate network exchange one bp each time | safe, prepare and view change mechanism guarantee no hard fork happens |
30 | | **fork choice rule** | longest fork wins | longest fork with greatest supported weightage wins |
31 | | **micro forks** | a single bp can act evil by drop previous bp's blocks | the most accepted block wins, evil bp cannot simply drop previous bp's blocks. |
32 | | **block produce interval** | LIB time doubles if interval changes from 0.5s to 1s | not sensitive to interval value, possible to achieve LIB next block if the interval changes to 1s. it has been validated in private testnet and achieved > 16% TPS enhancement. |
33 |
34 |
35 | ## 3. LIB Acceleration Benchmark
36 |
37 | A benchmark has been made to test the performance of LIB Acceleration solution. An intuitive result description is listed below and detailed analysis is shown later.
38 |
39 | | Head - LIB | Cumulative Disctibution Function |
40 | |----:|----:|
41 | | 5 blocks | 80.17% |
42 | | 6 blocks | 90.40% |
43 | | 7 blocks | 95.51% |
44 | | 8 blocks | 97.49% |
45 | | 9 blocks | 98.49% |
46 | | 10 blocks | 99.03% |
47 |
48 | 
49 |
50 | ### Benchmark Details
51 | **Core Metric**:
52 | d, the difference count of blocks between HEAD and LIB.
53 |
54 | **Benchmark Environment**:
55 | BOS LIB testnet is a public BOS-LIB testnet. The testnet is hosted by more than 16 teams over the world. Till 28 Jan 2019, the testnet has produced 3 million blocks.
56 | The latest implementation is open source and compatible with EOSIO version 1.4.4 and BOS-LIB.
57 |
58 | **How to get raw data**:
59 | Raw data is collected using log when TPS is stable at 300 TPS, and 5 groups of 110k data points are collected.
60 |
61 | **One Sample**:
62 | when TPS=300:
63 | **90.4% blocks enter LIB within 6 blocks**
64 | **95.5% blocks enter LIB within 7 blocks**
65 | **99.03% blocks enter LIB within 10 blocks**
66 |
67 | 
68 |
69 | **Confidence Interval**:
70 | We take 5 groups data and calculate CDF(cumulative distribution function) for 6 blocks and 10 blocks respectively, get the following data:
71 |
72 | | | group 1 | group 2 | group 3 | group 4 | group 5 |
73 | |:----|:----|:----|:----|:----|:----|
74 | | CDF block 6 | 90.03 | 90.08 | 90.04 | 90.65 | 90.16 |
75 | | CDF block 10 | 98.96 | 99.01 | 99.03 | 99.08 | 99.03 |
76 |
77 | calculate the standard deviation and mean:
78 |
79 | 
80 |
81 | 
82 |
83 | then we calculate a 95% confidence interval:
84 |
85 | 
86 |
87 | and get the result:
88 |
89 | | CDF block 6 | 90.192 ± 0.2 % (95% CI) |
90 | |:----|:----|
91 | | CDF block 10 | 99.022 ± 0.034 % (95% CI) |
92 |
93 |
94 | **Conclusions**:
95 | When TPS = 300, we have 95% confidence to predicate that
96 | 90.192 ± 0.2% blocks enter LIB within 6 blocks
97 | 99.022 ± 0.034% blocks enter LIB within 10 blocks
98 |
99 | **That means**:
100 | In 24 hours, most of the time(21.6 hours) blocks enter LIB within 3 seconds, while almost all the time (23.76 hours) blocks enter LIB within 5 seconds.
101 |
102 |
103 |
104 |
105 | ## 3. Future Improvements
106 | 1. upgrade compatible version to v1.6.x
107 | 1. system upgrade solution (discuss in part II)
108 | 1. optimize network message model, now is flooding mode.
109 |
110 | ## Reference
111 |
112 | - [BOS Technical White Paper](https://github.com/boscore/Documentation/blob/master/BOSCoreTechnicalWhitePaper.md)
113 | - [LIB Acceleration Design Document](https://github.com/eosiosg/dpos-pbft/blob/master/documentation/Algorithm%20for%20improving%20EOS%20consensus%20speed%20based%20on%20PBFT.md)
114 |
--------------------------------------------------------------------------------
/LIB/BOS_Batch_PBFT_II.md:
--------------------------------------------------------------------------------
1 | # PART II BOS Batch-PBFT Upgrade Solution
2 | ## 1. System Upgrade is Fundamental
3 | Change is the nature of software. The only thing that keeps unchanged, in software engineering, is change. In modern software engineering, maintainability makes sure that we are not suffering too much when making changes. For example, programming languages are evolving, new language features are added and deprecated features are removed. Software products follow the rule of agile development and lean startup to evolve. Blockchain technology is no exception. For example, Bitcoin doesn't have a smart contract, then Ethereum supports immutable smart contracts, and now EOS supports upgradable smart contracts. Upgradable smart contracts make a big step towards upgradable DApp services.
4 |
5 | the compatibility issue is a real-world problem when new features are introduced or when existing features are upgraded. For example:
6 | - In console games, PS4 is not compatible with PS3 games.
7 | - In the programming language, python 3 is not compatible with python 2.
8 | - In iPhone hardware, iPhone XR doesn't support 3D force touch.
9 |
10 | It is not uncommon to break the compatibility when necessary.
11 |
12 | EOS, Enterprise Operating System, is designed to behave like an operating system. It should be able to upgrade as frequently as possible, and an indirect proof is that EOSIO version has been upgraded from 1.0 to 1.6 in past 6 months. Since blockchain technology is a new category of software, therefore, it should follow the general rule of software and have special features. In traditional software/operation system, there is no hard fork problem because they are isolated and work alone. The hard fork is a special compatibility issue introduced in the blockchain.
13 |
14 | We can categories the severity of system upgrade into different compatibility levels:
15 | 1. **backward compatible**
16 | Most upgrades fall into this category, for example, virtual machine upgrade to WABT, signature validation optimization.
17 | 2. **soft fork**
18 | In most cases, it is related to the system contract.
19 | 3. **hard fork**
20 | Usually, this happens when a very fundamental behavior changes and it does not act backward compatible. For example, Rex upgrade, DPOS-Batch-PBFT consensus protocol upgrade.
21 |
22 |
23 | ## 2. System Upgrade Solution
24 | We will discuss the possible solution to upgrade the consensus protocol,`from Pipeline BFT to Batch PBFT`, in BOS. We also want to discuss a general approach to make system upgrade process smoother.
25 |
26 | ### Terms:
27 |
28 | **GB-2nd** - Second Genesis Block
29 | Genesis block is the first block of blockchain and provides the source of trust. As time goes, Merkle tree and node network work together to provide the trust of the blockchain. GB-2nd is the second genesis block, for example in block #1,000,000, to re-build the source of trust point. it is critical to the trust chain especially when consensus rule has changed. A similar approach could take place during 3rd, 4th and x-th system upgrade.
30 |
31 | **Maintenance Mode**:
32 | It has a boolean value ON/OFF to indicate the maintenance status of system contract. If the value is on, system contract is in maintenance mode and BP schedule is frozen; If the value is off, system contract is functioning normally.
33 |
34 | ### Possible Solution:
35 |
36 | The brief idea is that all nodes and BPs switch to use Batch PBFT when GB-2nd enters LIB. In order to ensure the liveness, only function related to the BP schedule update is frozen temporarily.
37 |
38 |
39 | **PREPARE PHASES:**
40 |
41 | **prepare phase 0**: off-chain agreement on upgrade solution
42 |
43 | **prepare phase 1**: decide GB-2nd block number, for example block #1,000,000
44 |
45 | **prepare phase 2**: all related BPs and full nodes upgrade to new version node and system contract
46 |
47 | **prepare phase 3**: use multi-sig to set GB-2nd block number
48 |
49 | **EXECUTION PHASES:**
50 |
51 | `This phase is an automated upgrading process. All functions work normally except BP schedule is frozen for near 3 minutes.`
52 |
53 | **phase 0**: when head block number is less than GB-2nd, Pipeline BFT is chosen.
54 |
55 | **phase 1**: wait until GB-2nd is produced. Maintenance mode should be switched to ON automatically. Thereafter BP schedule is frozen until upgrade finished.
56 |
57 | **phase 2**: wait until GB-2nd enters LIB. Then all BPs and nodes switch to use Batch PBFT. Meanwhile, switch maintenance mode to OFF and unfreeze BP schedule. The upgrade is finished.
58 |
59 |
60 | 
61 |
62 |
63 | When GB-2nd enters LIB, there are 300+ blocks between HEAD and LIB. These blocks hold proof that GB-2nd is valid under the previous consensus algorithm. Therefore, GB-2nd becomes a trusted source. After the switch, BPs start the process of Batch PBFT based on GB-2nd, 300+ blocks mentioned above will go through prepare and commit phases and be kept in chain.
64 |
65 | ## 3. Conclusions
66 | We have discussed why system upgrade is fundamental to software and blockchain. We also discussed a possible solution to upgrade consensus protocol `from Pipeline BFT to Batch PBFT`.
67 |
68 | Consensus protocol upgrade is not the only one need such a solution. Another topic about REX upgrade has also been discussed broadly in the community. If you have any solution or improvements, welcome to share and discuss.
--------------------------------------------------------------------------------
/LIB/images/BOS_LIB_Acceleration_PART_I/benchmark_chart.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/LIB/images/BOS_LIB_Acceleration_PART_I/benchmark_chart.png
--------------------------------------------------------------------------------
/LIB/images/BOS_LIB_Acceleration_PART_I/benchmark_example.jpeg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/LIB/images/BOS_LIB_Acceleration_PART_I/benchmark_example.jpeg
--------------------------------------------------------------------------------
/LIB/images/BOS_LIB_Acceleration_PART_I/stats_formular1.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/LIB/images/BOS_LIB_Acceleration_PART_I/stats_formular1.jpg
--------------------------------------------------------------------------------
/LIB/images/BOS_LIB_Acceleration_PART_I/stats_formular2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/LIB/images/BOS_LIB_Acceleration_PART_I/stats_formular2.png
--------------------------------------------------------------------------------
/LIB/images/BOS_LIB_Acceleration_PART_I/stats_formular3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/LIB/images/BOS_LIB_Acceleration_PART_I/stats_formular3.png
--------------------------------------------------------------------------------
/LIB/images/BOS_LIB_Acceleration_PART_II/lib_upgrade.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/LIB/images/BOS_LIB_Acceleration_PART_II/lib_upgrade.jpg
--------------------------------------------------------------------------------
/LIB/基于PBFT提升EOSIO共识速度的算法.md:
--------------------------------------------------------------------------------
1 | # 基于PBFT提升EOSIO共识速度的算法
2 |
3 | ## 1 背景介绍
4 | #### 1.1 现象
5 | 当前主网的链高度和共识高度之间有325+个块的差距，相当于~3分钟左右的时间差。也就是说，当下提交的trx需要等到~3分钟后才能确认是否被记在链上。这样的表现对于很多DApp来说是不可承受的，尤其是那些需要即时确认的应用。
6 |
7 |
8 | #### 1.2 原因阐述
9 | * 造成主网上这种现象的原因，是EOS基于DPOS的共识算法中，所有块同步和确认信息都只通过出块的时候才能发出。也就是说，在BP1出块（所出块为BLK）、BP1～BP21轮流出块的情况下，BP2～BP21会陆续收到并验证BLK，但所有BP只能等到自己出块的时候才能发出对BLK的确认信息。这也是为什么我们看到nodes的log中，每个BP在schedule中第一次出块的时候，`confirmed`总是240。DPOS+Pipeline BFT理论上共识的最快速度（即head和LIB之间的最小差距）为325。
10 |
11 |
12 | * 240 = (21-1)*12
13 | 这其实是（在网络情况良好的情况下）上一轮所有块数之和。每个节点在`block_header`中维护着一个长度最长为240，初始值为14的vector `confirm_count`，对应所有收到但是未达成共识的块以及尚需的确认数。每当收到多一个BP对这些块的确认，对应块的数值-1，直到某一块所需的确认数减到0，此块及之前的所有块便进入共识（[相关代码](https://github.com/EOSIO/eos/blob/905e7c85714aee4286fa180ce946f15ceb4ce73c/libraries/chain/block_header_state.cpp#L188)）。
14 |
15 | * 325 = 12*(13+1+13) + 1
16 | 整个网络需要15个人确认才能达成共识。每个人默认会对自己出的块进行确认，所以每个块需要14个人的implicit confirm和（explicit）confirm。第14个BP在出块时由于包括自己在内确认人数已经达到15人，所以它会同时发出implicit confirm和（explicit）confirm。那么理想情况下，一个块从它产生后，要到之后的第28个BP所产出的第一个块时才能得到全网共识，进入LIB。因此有以上计算。
17 |
18 |
19 | * **我们认为，所有BP不需要等到出块的时候才对其他块进行确认，用PBFT**（Practical Byzantine Fault Tolerance[1]）**来替代Pipeline BFT，让BP之间实时地对当前正在生产的区块进行确认，能够使整个系统最终达到接近实时的共识速度。**
20 |
21 | ## 2 算法核心
22 | * 保留DPOS的BP Schedule机制,和EOS一样对synchronized clock和BP Schedule进行强约束。
23 |
24 | * 去掉EOS中的Pipeline BFT部分共识（即去掉原本EOS中出块时的implicit confirm和(explict) confirm部分），因为在极端情况下可能与PBFT的共识结果有冲突。
25 |
26 | * 共识的通讯机制使用现有p2p网络进行通信,但增加通信成本,使用PBFT机制广播prepare和commit信息。
27 |
28 | * 通过batch方式优化(替换掉PBFT中对每个块进行共识的要求), 能够达成批量共识，以此来逼近实时BFT的理想状态并减轻网络负载。
29 |
30 |
31 | ## 3 基础概念
32 | #### 3.1 DPOS中BP变更的具体实现
33 | * 当前代码中，每60s（120个块）刷新一次投票排名（[相关代码](https://github.com/EOSIO/eos/blob/8f0f54cf0c15c4d08b60c7de4fd468c5a8b38f2f/contracts/eosio.system/producer_pay.cpp#L47)），如果前21名发生变化，会在下一次刷新排名的时候发出`promoting proposed schedule`（[相关代码](https://github.com/EOSIO/eos/blob/8f0f54cf0c15c4d08b60c7de4fd468c5a8b38f2f/libraries/chain/controller.cpp#L909)）
34 |
35 | * 当包含`promoting proposed schedule`的块进入LIB后，BP会陆续更新自己block header中的`pending_schedule`
36 |
37 | * 等到2/3 +1个BP节点都已经更新block header后，`pending schedule`达成共识。BP会陆续将`active schedule`更新为此时`pending schedule`的值，并按照新的BP组合开始出块，整个过程需要至少经过两轮完整的出块。
38 |
39 | * 每一次新的BP组合，一定要能够达成共识才能真正生效。换句话说，如果网络中7个或更多节点无法正常通信，那么无论如何不能通过投票的方式产生新的BP。网络的LIB会一直停留在节点崩溃的那个共识点。
40 |
41 | * DPOS这样的做法可以有效的避免一部分分叉问题，所以仍会沿用DPOS关于BP选举部分的共识机制，即所有的BP变动，需要等到propose schedule进入LIB后才真实生效。
42 |
43 | #### 3.2 PBFT的前提
44 | * 如果网络中的拜占庭节点为f个，那么要求总节点数n满足n≥3f+1。拜占庭节点是指对外状态表现不一致的节点，包括主动作恶的节点和因为网络原因导致失效或部分失效的节点。
45 |
46 | * 所有信息最终可达: 所有通信信息可能会被延迟/乱序/丢弃, 但通过重试的方式可以保证信息最终会被送达。
47 |
48 |
49 | #### 3.3 PBFT中的关键概念对应DPOS
50 | **pre-prepare**，指primary节点收到请求，广播给网络里的所有replica。可以类比为DPOS中BP出块并广播至全网。
51 |
52 |
53 | **prepare**，指replica收到请求后向全网广播将要对此请求进行执行。可类比为DPOS重所有节点收到块并验证成功后广播已收到的信息。
54 |
55 |
56 | **commit**，指replica收到足够多的对同一请求的prepare消息，向全网广播执行此请求。可以类比为DPOS中节点收到足够多对同一个块的prepare消息, 提出proposed lib消息
57 |
58 | **committed-local**, 指replica收到足够多对同一请求的commit消息, 完成了验证工作. 可以类比为DPOS中的LIB提升.
59 |
60 |
61 | **view change**，指primary节点因为各种原因失去replica信任，整个系统更改primary的过程。由于EOS采用了DPOS的算法，所有BP是通过投票的方式提前确定的，在同一个BP schedule下整个系统的出块顺序是完全不变的，当网络情况良好并且BP schedule不变的时候可以认为不存在view change。
62 | 当引入PBFT后，为了避免分叉导致共识不前进的情况，加入view change机制，抛弃所有未达成共识的块进行replay，不断重试直到继续共识。
63 |
64 | **checkpoint**, 指在某一个块高度记录共识证据, 以此来提供安全性证明. 当足够多的replica的checkpoint相同时, 这个checkpoint被认为是stable的. checkpoint的生成包括两大类,一类是固定k个块生成; 另一类是特殊的需要提供安全性证明的点,例如BP schedule发生变更的块.
65 |
66 |
67 | ## 4 未优化版本概述
68 |
69 | 术语:
70 | * v: view version
71 | * i: BP的名字
72 | * BLKn: 第n个块
73 | * dn: 对应第n个块的共识消息摘要digest
74 | * σi: 名为i的BP的签名
75 | * n: 区块的高度
76 |
77 | 所有BP针对每一个块按顺序进行共识, 采用PBFT机制. 以下分情况进行描述:
78 |
79 |
80 | #### **4.1 在正常的情况下（不涉及BP变更也没有分叉，且网络状况良好）**
81 | **pre-prepare**阶段，与现行逻辑没有区别，即BP广播其签名的块。
82 |
83 |
84 | **prepare**阶段，BPi收到当前BP签名的块BLKn，经过验证后发出 (PREPARE,v,n,dn,i)σi 消息，等待共识。当BPi收到了2/3的节点发出view v下对BLKn的PREPARE消息，认为网络中对此块的prepare已达成共识。已发出的PREPARE消息，不可更改。
85 |
86 |
87 | **commit**阶段，当BLKn标记为 ***prepared*** 后，BPi发出(COMMIT,v,n,dn,i)σi。需要注意的是，PBFT是通过保证严格顺序来实现安全性的，所以对所有节点对块的共识也是严格的按照顺序进行，也就是说，(PREPARE,v,n,dn,i)σi发出的前提条件是在同一个view下，BLKn-1至少已经处于 ***committed*** 状态。
88 |
89 |
90 | **全网角度下LIB提升**，当BPi收到了2/3的节点发出v下对BLKn的COMMIT消息，BPi认为网络中对此块的commit已达成共识，即此块已达成共识，此块标记为 *committed* 状态，并将LIB提升到当前高度n，然后开始对下一个块进行prepare。若此区块高度为Hi，所有BP的LIB高度进行降序排列后得到长度为L的向量Vc, 从全网角度来看Vc[2/3L]及以下的LIB可以被认为 ***stable*** ，Vc[2/3L]即此时全网的LIB高度。
91 |
92 |
93 | **对于同一个块而言，只有收集足够的PREPARE消息，才会进入commit阶段。同理，只有收集足够的COMMIT消息，才会开始对下一个块开始prepare，否则就一直重发直到消息数满足要求或进行view change（见后文）。**
94 |
95 | #### **4.2 当BP产生变化的时候**
96 | **pre-prepare**阶段，与4.1无区别。
97 |
98 |
99 | **prepare**和**commit**阶段，由于不同BP间对于BP变动的信息达成共识的时间有先后，此时便会出现BP之间对于schedule的不一致状态。
100 | 以BPi为例，BPi收到了当前BPc签名的块BLKn，如果此时多数BP的active schedule已改为S'，而BPi仍是S，那么BPi便会持续等待S中的BP发送的PREPARE信息，从而无法进入commit阶段。
101 | 但此时网络中的多数节点仍会相互达成共识，致使全网的LIB提升。如果BPi收到足够的同一个view下的commit信息, BPi会进入commit-local状态,提升自己的LIB。
102 |
103 |
104 |
105 | #### **4.3 当产生分叉的时候**
106 | **pre-prepare**阶段，与4.1无区别。
107 |
108 | **prepare**和**commit**阶段，当BPi 在timeout=T内没有收集足够的PREPARE或COMMIT消息，即共识没有在这个时间段内提升，此时发出VIEW-CHANGE消息，发起view change 并不再接收除VIEW-CHANGE、NEW-VIEW和CHECKPOINT外的任何消息。
109 |
110 | **view change**阶段，BPi 发出 (VIEW-CHANGE,v+1,hlib,n,i)σi消息。当收集到 2/3 +1 个v'=v+1的VIEW-CHANGE消息后，由schedule中的下一个BP发出 (NEW-VIEW,v+1,n,VC,O)σbp消息，其中VC是所有包括BP签名的VIEW-CHANGE消息，O是所有未达成共识的PRE-PREPARE消息（介于hlib和nmax之间）。当其它BP收到并验证NEW-VIEW消息合法后，丢弃掉所有当前未达成共识的块，基于所有的PRE-PREPARE消息重新进行prepare和commit阶段。
111 | 若view change未能在timeout=T内达成共识（没有正确的NEW-VIEW消息发出），即发起新一轮v+2的view change，等待时间timeout=2T, 依次类推不断重试，直到网络状态收敛，共识开始提升。
112 |
113 |
114 | **备注**: 原始的PBFT不存在分叉的问题, 因为PBFT只有在一个请求达成共识后才会开始处理下一个请求。
115 |
116 |
117 | ## 5 未优化版本存在的问题:
118 | #### 5.1 共识速度
119 | 当对一个块的共识速度小于500ms，即两轮消息的发送可以在500ms内收到足够的确认数，head和LIB的差距稳定后可以趋近于1个块，即实时共识。而当对一个块的平均共识速度大于等于500ms或网络状态极差导致重试次数过多，本算法表现可能慢于DPOS+Pipeline BFT。
120 |
121 | #### 5.2 网络开销
122 | 假设网络中的节点为N，消息传播使用gossip算法，块大小为B，那么DPOS需要传播的消息为N2，所需带宽为BN2。
123 | 假设PREPARE和COMMIT消息大小分别为p和c，PBFT+DPOS所需要传播的消息数为 (1+rp+rc)N2，其中1 是pre-prepare的传输,rm，rc为prepare和commit的重试次数，所需带宽为(B+prp+crc)N2。当p、c优化的足够小后，额外的带宽开销主要取决于重试次数。
124 |
125 | ## 6 优化后的版本概述
126 | #### 6.1 通过自适应粒度调整,实现批量共识
127 | ##### 6.1.1 batch 策略
128 | LIB的高度为hLIB
129 | fork中最高点的块的高度为 hHEAD
130 | 涉及到BP schedule变动的块高度为 hs
131 | 批量共识batch:
132 | * batchmin = 1
133 | * batchmax = min(default_batch_max, hHEAD - hLIB)
134 |
135 | 当batchmax中不包含BP Schedule变动时, batch = batchmax
136 | 当batchmax中包含BP Schedule变动且hLIB < hs 时, batch = hs - 1
137 | 当batchmax中包含BP Schedule变动且hLIB == hs 时, batch = batchmax
138 |
139 | ##### 6.1.2 批量共识原理
140 | 当未出现分叉情况时, 以上构筑可类比PBFT中view不变情况下的共识. 并且基于Merkle Tree的基本结构，当多数节点可以对BLKn的Hash达成共识，那么之前的所有块都应该是共识的. 此处保证了块的total order.
141 |
142 | 当出现分叉情况时, PREPARE 信息不能变动，否则可能对外表现为拜占庭错误。此时需要不断重发当前的PREPARE消息直到网络达成共识或触发timeout 后发起view change。
143 |
144 | ##### 6.1.3 实现方法
145 | * 每当收到新的块时, BP 通过batch的策略生成PREPARE信息, 进行缓存及广播
146 |
147 | * 每个BP为block_header维护一个最低水位h，和最高水位H，分别对应自己还没有达成共识的最低点和最高点。
148 |
149 | * 同时维护两个长度为（H-h）的向量 Vp & Vc，包括水位间每一个块所需要的PREPARE消息数和COMMIT消息数。
150 |
151 | * 每收到一个高度为n的PREPARE消息（或COMMIT消息），通过消息的签名和digest进行验证并确认他与自己处于相同的fork后，依次将Vp（Vc）中（h ≤ n）的所有数值-1。
152 |
153 | * 不断重发同一个fork上高度为H的PREPARE消息（或COMMIT消息），直到达成共识或超时后触发View Change（基于New View重新开始PBFT共识，此时v' = v+1）。
154 |
155 | * 当某一个处于高度x（h ≤ x ≤ H）的块收集超过2/3 +1个PREPARE消息，依次执行从h～x的块内容并标记所有（h ≤ x）的块为 *prepared*，然后自动发出高度为x的COMMIT消息。
156 |
157 | * 当某一个处于高度y（y ≤ H）的块收集超过2/3 +1个COMMIT消息，依次执行从h～y的块内容并标记所有（h ≤ y）的块为 *committed*。此时认为≤y的所有块已达成共识，将自己的LIB高度提升至y。
158 |
159 | * 每隔若干块生成checkpoint以提高性能。当网络内超过2/3 +1的最新的checkpoint 都达到某一高度c，并且处于同一fork上，则认为此checkpoint稳定。
160 |
161 | ##### 6.1.4 view change策略
162 | * BP依据出块的schedule依次成为前一人的backup，确保每一次view change后的primary只可能有一人。
163 |
164 | * 当网络开始进入view change后，NEW-VIEW应该重新对2/3 +1人看到的最低点h和最高点H之间的块进行重新共识。
165 |
166 | * 发出NEW-VIEW的BP应该在消息内包括所有VIEW-CHANGE消息，并根据所有的VIEW-CHANGE消息计算出h和H，并将[h, H]区间内超过（2/3 +1）的人选择的fork一并发出。
167 |
168 | * 当BP收到NEW-VIEW消息并进行验证后，基于NEW-VIEW的内容重新进行prepare。
169 |
170 | * 若在timeout=T内无法完成view change，便开始发起v+2的新一轮view change，直到网络对fork的选择达成共识。
171 |
172 | #### 6.2 通过始终prepare最长链并结合view change，避免分叉风险
173 | * 当BP收到多个fork的时候，应该对当前所能看到的最长链进行prepare, 采取longest-live-fork原则.
174 |
175 | * BP在进行prepare的时候，应该错开BP切换的时间点，从而避免选择少数人支持的fork。
176 |
177 | * **BP一旦对某个fork进行prepare，就不能再对prepare消息进行更改，否则可能成为拜占庭错误，** BP需要：
178 | 1）不断重发之前的PREPARE消息，等待最终达成共识。即使这个fork不是最长链, 因为有更多人支持，也应该选择这个fork；
179 | 2）或等待timeout=T后，发起view change，所有BP基于NEW-VIEW发出的fork开始新的BPFT共识；
180 | 3）收到超过（2/3 +1）同一fork的COMMIT消息或checkpoint，抛弃当前状态同步至多数人达成共识的高度。
181 |
182 | #### 6.3 通过Checkpoint机制实现GC并提升同步性能
183 | * BP不断网络内广播自己当前的checkpoint状态，并且接收来自其他人的checkpoint。
184 |
185 | * 当同一分支上有超过（2/3 +1）人的checkpoint已经高于c，认为CHECKPOINTc已经stable，删除高度低于c以前所有PREPARE、COMMIT消息等cache。
186 |
187 | * 通过验证checkpoint的正确性，可以大幅提升节点的同步速度。
188 |
189 | ## 7 FAQ
190 | DPOS相关问题（见1.2）
191 |
192 | 1. 简单说明DPOS是如何工作的
193 | 暂略
194 | 2. 为什么DPOS的lib是12个12个的涨
195 | 暂略
196 | 3. 为什么DPOS的HEAD和LIB差距这么大
197 | 暂略
198 | 4. 当BP变动时, DPOS是如何工作的
199 | 暂略
200 | 5. 目前节点间的数据是如何同步的
201 | 暂略
202 |
203 | PBFT相关问题
204 |
205 | 1. 简单说明PBFT
206 | 暂略
207 |
208 | DPOS-PBFT相关问题
209 |
210 | 1. 简单说明DPOS-PBFT是如何工作的
211 | 见5
212 |
213 |
214 | 2. 为什么不能只广播一次prepare的信息
215 | 当网络出现分叉（或BP变动）的时候，如果只有PREPARE信息，所有节点是无法对其它节点的view change进行响应的，会导致硬分叉。 举例说明: 因为分布式网络的特性, 信息会被延迟或打乱。假设现在有三个连续出块的BP A,B,C 如果B没有收到A的最后一个块, 那么他会继续从倒数第二个块开始出块。这样造成了两个fork选择F1 F2. 假定A的最后一个块里包含了BP变动的信息(该块在F1里), 那么选择了F1的节点需要一个新的BP S1来进行共识, 而F2的节点需要原有的BP S2 进行共识。 共识的群体发生了变化, 很有可能会两边最终都进入共识状态, 进而导致整体网络发生分叉。
216 |
217 |
218 | 3. prepare和commit重发机制是如何工作的
219 | 当超过给定的timeout T后仍然没有对某一个处于 *prepared* 或者 *committed* 的块收集到足够多的确认，就对同一个消息进行多一次的重发，直到收集到足够多的确认或发生view change。
220 |
221 |
222 | 4. 当BP集合变动的时候,是否存在分叉风险
223 | 见4.2
224 |
225 |
226 | 6. 是否需要等待共识完成才能继续出块
227 | 出块可以持续进行，共识只影响LIB的高度
228 |
229 |
230 | 7. 如果第N个块未满足BFT共识个数,但第N+1个块收到了足够多的confirm,该如何处理
231 | 对于优化后的算法，可以直接开始基于N+2个块开始收集共识消息
232 |
233 |
234 | 8. 持续出块是否会因为共识未迅速达成而分叉
235 | 不会，至少表现为DPOS的状态，最终会共识在最长链上
236 |
237 |
238 | 9. BFT的commit信息是否需要写入块中
239 | 所有消息（发出的和收到的）都只存在本地. 但需要保留一段时间, 用以为peer提供共识的证据
240 |
241 |
242 | 10. 额外增加的开销有多少
243 | 见5.2
244 |
245 |
246 | 11. 共识的速度真的能提升吗,如果BFT共识平均时间>500ms,BFT的高度是低于DPOS的
247 | 见5.1
248 |
249 |
250 | ## 8 参考
251 | [1] http://pmg.csail.mit.edu/papers/osdi99.pdf
--------------------------------------------------------------------------------
/Oracle/BOS_Oracle_Deployment.md:
--------------------------------------------------------------------------------
1 | BOS Oracle Deployment
2 | ----------
3 |
4 | # 1. Create Oracle Contract Account `oracle.bos`
5 |
6 | ## 1.1. Export the basic info the account
7 | oracle.bos.json
8 | ```
9 | ["eosio", "oracle.bos", {
10 | "threshold": 1,
11 | "keys": [],
12 | "accounts": [{
13 | "permission": {
14 | "actor": "eosio",
15 | "permission": "active"
16 | },
17 | "weight": 1
18 | }
19 | ],
20 | "waits": []
21 | }, {
22 | "threshold": 1,
23 | "keys": [],
24 | "accounts": [{
25 | "permission": {
26 | "actor": "eosio",
27 | "permission": "active"
28 | },
29 | "weight": 1
30 | },{
31 | "permission": {
32 | "actor": "oracle.bos",
33 | "permission": "eosio.code"
34 | },
35 | "weight": 1
36 | }
37 | ],
38 | "waits": []
39 | }]
40 | ```
41 |
42 | ## 1.2. Create `newaccount` ACTION
43 |
44 | ```
45 | cleos push action eosio newaccount ./oracle.bos.json -sdj -p eosio > oracle.trx
46 | ```
47 | ## 1.3. Generate `buyram` ACTION
48 |
49 | ```
50 | cleos system buyram -k eosio oracle.bos 3000 -sdj > oracle-ram.trx
51 | ```
52 | ## 1.4. Create `delegatebw` ACTION
53 |
54 | ```
55 | cleos system delegatebw eosio oracle.bos "2 BOS" "2 BOS" -sdj > oracle-delegate.trx
56 | ```
57 | ## 1.5. Combine ACTIONs into `neworacle.json`，create proposal
58 |
59 | ```
60 | cleos multisig propose_trx createtest bppermission.json neworacle.json bostesterter
61 | ```
62 | neworacle.json：
63 | ```
64 | {
65 | "expiration": "2019-04-27T01:43:42",
66 | "ref_block_num": 33447,
67 | "ref_block_prefix": 2283537730,
68 | "max_net_usage_words": 0,
69 | "max_cpu_usage_ms": 0,
70 | "delay_sec": 0,
71 | "context_free_actions": [],
72 | "actions": [{
73 | "account": "eosio",
74 | "name": "newaccount",
75 | "authorization": [{
76 | "actor": "eosio",
77 | "permission": "active"
78 | }
79 | ],
80 | "data": "0000000000ea3055000000bdf79eb1ca0100000000010000000000ea305500000000a8ed32320100000100000000010000000000ea305500000000a8ed3232010000"
81 | },{
82 | "account": "eosio",
83 | "name": "buyrambytes",
84 | "authorization": [{
85 | "actor": "eosio",
86 | "permission": "active"
87 | }
88 | ],
89 | "data": "0000000000ea3055000000bdf79eb1ca00240000"
90 | },{
91 | "account": "eosio",
92 | "name": "delegatebw",
93 | "authorization": [{
94 | "actor": "eosio",
95 | "permission": "active"
96 | }
97 | ],
98 | "data": "0000000000ea3055000000bdf79eb1ca102700000000000004424f5300000000102700000000000004424f530000000000"
99 | }
100 | ],
101 | "transaction_extensions": [],
102 | "signatures": [],
103 | "context_free_data": []
104 | }
105 | ```
106 | # 2. Set contract
107 | ## 2.1 Create `set contract` ACTION
108 | ```
109 | cleos set contract oracle.bos bos.oracle/ -p oracle.bos -s -j -d > setcontract.json
110 | ```
111 | ## 2.2 Create MSIG
112 | ```
113 | cleos multisig propose_trx setcontract bppermission.json setcontract.json -p bostesterter
114 | ```
115 | ## 2.3 BPs `approve` MSIG
116 | ```
117 | cleos multisig approve bostesterter updatasystem '{"actor":"${BP_NAME}","permission":"active"}' -p ${BP_NAME}
118 | ```
119 | ## 2.4 `exec` execute MSIG
120 | ```
121 | cleos multisig exec bostesterter setcontract -p bostesterter@active
122 | ```
123 | ## 2.5 Initialize Oracle
124 | ```
125 | cleos push action ${contract_oracle} setparameter '{"version":1,"parameters":{"core_symbol":"BOS","precision":4,"min_service_stake_limit":1000,"min_appeal_stake_limit":200,"min_reg_arbitrator_stake_limit":10000,"arbitration_correct_rate":60,"round_limit":3,"arbi_timeout_value":86400,"arbi_freeze_stake_duration":259200,"time_deadline":86400,"clear_data_time_length":10800,"max_data_size":256,"min_provider_limit":1,"max_provider_limit":100,"min_update_cycle":1,"max_update_cycle":8640000,"min_duration":1,"max_duration":8640000,"min_acceptance":1,"max_acceptance":100}}' -p ${contract_oracle} -s -j -d > setconfig.json
126 |
127 | cleos multisig propose_trx setconfig bppermission.json setconfig.json -p ${account}
128 |
129 | cleos multisig approve ${account} setconfig '{"actor":"${account}","permission":"active"}' -p ${account}
130 |
131 | cleos multisig exec ${account} setconfig -p ${account}
132 | ```
133 |
134 | _Note: the meanings of parameters: [Configurations](./BOS_Oracle_Introduction.md#27-configurations)
135 |
136 |
137 | # 3. Import Arbitrators
138 | ## 3.1 Create `importwps` ACTION
139 | ```
140 | cleos push action oracle.bos importwps '[["arbitrator11","arbitrator12","arbitrator13","arbitrator14","arbitrator15","arbitrator21","arbitrator22","arbitrator23","arbitrator24","arbitrator25", "arbitrator31", "arbitrator32","arbitrator33", "arbitrator34", "arbitrator35", "arbitrator41", "arbitrator42", "arbitrator43", "arbitrator44", "arbitrator45"]]' -p oracle.bos -s -j -d > importwps.json
141 | ```
142 | ## 3.2 Create MSIG
143 | ```
144 | cleos multisig propose_trx insertwps bppermission.json importwps.json -p bostesterter
145 | ```
146 | ## 3.3 BPs `approve` MSIG
147 | ```
148 | cleos multisig approve bostesterter insertwps '{"actor":"bostesterter","permission":"active"}' -p bostesterter
149 | ```
150 |
151 | ## 3.4 `exec` MSIG
152 |
153 | ```
154 | cleos multisig exec bostesterter insertwps -p bostesterter@active
155 | ```
156 |
157 |
--------------------------------------------------------------------------------
/Oracle/BOS_Oracle_Introduction.md:
--------------------------------------------------------------------------------
1 | BOS.Oracle Introduction: Witness and Changes
2 | ----------
3 |
4 | # I, Background
5 |
6 | The blockchain technology has evolved tremendously over the past few years and is widely known by public now, however there are not many use cases. The main reason is that the blockchain is in a closed system and cannot communicate with external world in a **trusted manner**. If we can solve this trust problem, there will be much more use cases for the blockchain technology.
7 |
8 | In the real world, if a merchant is not sure that he can receive the money, he will not sell the product. If the consumer cannot determine the authenticity of the product, he will not purchase it. "
9 |
10 | "Trusted" is the most basic condition of trading in the real world. If we can't foster trust, then we can't complete the transaction. Trust can either rely on the credibility of both parties (which is essentially based on past transaction history, making probabilistic estimates) or rely on a certain The third party of the letter (whether it is really trustworthy, where does the basis of trust come from?). In complex real-world, foster allows us to take on risks and consume energy and resources significantly. How to solve this problem? Can we combine blockchain technology to change this situation? BOS's oracle (Oracle) service is our answer, hoping to serve as a data bridge between the blockchain and the real world.
11 |
12 | Some oracles are designed based on the assumption of a trusted data source or an authoritative data source. however this hypothesis is theoretically very risky and cannot guarantee the authenticity of the data source. The principles that BOS's oracle system follows from the beginning of its construction are:
13 |
14 | BOS Oracle does not rely on each oracle provider's 100% credibility of the data they provided.
15 | BOS Oracle treats each oracle provider as a participant in the game, in order to achieve overall credibility in the game.
16 |
17 | In this way, as long as the participants and the real world roles are mapped in the game, not only we can obtain the trustworthiness of the blockchain input data , but also we can output "trust" to the real world. In fact, this is more like a trusted platform based on blockchain, and its service is a predictor. The BOS oracle will extend the value of the blockchain from its monetary attributes to the construction of transactions and rules. This extension will solve or improve many real-world trust problems, thereby expanding the application boundaries of the blockchain and ultimately let blockchain technology real-world scenarios other than transaction transfers.
18 |
19 | # II. Introduction
20 |
21 | ## 2.1 System Components
22 | 
23 |
24 | In order to cope with various situations and conflicts from different levels of oracle service, BOS Oracle use “**two-way proof**” to obtain final arbitration results through mechanisms such as “**different arbitrators**” and “**multiple rounds of arbitration**”. In the arbitration, the mortgage mechanism is adopted as the final penalty anchor, the appeal system and the prosecution system are carried out simultaneously, mutual supervision; the arbitrator is stimulated by means of income sharing and punishment as a reward, and the credit system is introduced to realize the model under the non-one-time game. Stable and trustworthy.
25 |
26 | **Service:** Provide Data, Fetch Data, Arbitration
27 |
28 | **Role:** Provider, User, DAPP, Arbitrator
29 |
30 | **Features**: Comprehensive arbitration, holistic check and balance, systematic incentive, wide-range of application
31 |
32 | ## 2.2 Data Service
33 |
34 | Service Provider can create data services to upload data, and finally, the value of the data will be realized in the end.
35 |
36 | ## 2.3 Use Oracle Service
37 |
38 | The data user can use an existing oracle service according to his own needs, or can participate as an initiator in the corresponding oracle service and obtain the required data from the service.
39 |
40 | Users can easily query and retrieve the corresponding oracle service in the Oracle Store.
41 |
42 | ## 2.4 Arbitration
43 |
44 | The arbitration module is the backbone for fairness. BOS Oracle adopted a number of rounds of arbitration in order to deter bribery, and the number of arbitrators increase will commensurate with each arbitration round. As the size of the arbitrators expand, it will become more difficult to pay bribes, and the cost will increase sharply, which will eventually prevent, and deter corrupt activities.
45 |
46 | The arbitration model of the BOS Oracle is divided into two phases:
47 |
48 | - The "Fulltime Arbitrators" phase, 21 arbitrators in total who must be timely response to the arbitration cases; in this stage, a total of 3 rounds of arbitration can be conducted, with 3, 5 and 9 persons in each round and no repetition in each round;
49 | - The "Mass Arbitrators” phase, the participants in the entire Oracle service will be involved in. Extensive arbitration and random sampling will be conducted, subject to the majority; The number of "Mass Arbitrators" will be well regulated, in case of "Sybil Attack".
50 |
51 | 
52 |
53 | ## 2.5 Intelligent Risk Control
54 |
55 | In order to mitigate risk, “intelligent risk control” always ensures that the data provider has sufficient collateral tokens. DApp user to transfer Token directly to the "smart-controlled" account instead of the DApp project's account.
56 |
57 | When someone initiates arbitration for the oracle service, "Intelligent Risk Control" will calculate fund freezing time and the thawing duration based on historical behaivor and data provide. If there is no anomaly in the entire process, the DApp can extract the funds from the “Intelligent Risk Control” account.
58 |
59 | intelligently based on the historical behavior of the data provider and the current expenditure.
60 |
61 | “Intelligent Risk Control” is an option that depends on whether the DApp project party is adopting it. However, from the perspective of market competition, DApps that provide more protection for users will gain more favor.
62 |
63 | 
64 |
65 | ## 2.6 Variable Name
66 |
67 | - `${contract_oracle}`: BOS Oracle Account
68 | - `${provider_account}`: Data Provider
69 |
70 | ## 2.7 Configurations
71 |
72 | After deployed Oracle contract, Oracle need to be initialized by `setparameter`.
73 |
74 | ```
75 | cleos push action ${contract_oracle} setparameter '{"version":1,"parameters":{"core_symbol":"BOS","precision":4,"min_service_stake_limit":1000,"min_appeal_stake_limit":200,"min_reg_arbitrator_stake_limit":10000,"arbitration_correct_rate":60,"round_limit":3,"arbi_timeout_value":86400,"arbi_freeze_stake_duration":259200,"time_deadline":86400,"clear_data_time_length":10800,"max_data_size":256,"min_provider_limit":1,"max_provider_limit":100,"min_update_cycle":1,"max_update_cycle":8640000,"min_duration":1,"max_duration":8640000,"min_acceptance":1,"max_acceptance":100}}' -p ${contract_oracle} -s -j -d > setconfig.json
76 |
77 | cleos multisig propose_trx setconfig bppermission.json setconfig.json -p ${account}
78 |
79 | cleos multisig approve ${account} setconfig '{"actor":"${account}","permission":"active"}' -p ${account}
80 |
81 | cleos multisig exec ${account} setconfig -p ${account}
82 | ```
83 |
84 | ## 2.7 Oracle Global Parameter
85 |
86 | After the Oracle contract is deployed, system parameter initialization is required.
87 |
88 | ```
89 | cleos push action ${contract_oracle} setparameter '{"version":1,"parameters":{"core_symbol":"BOS","precision":4,"min_service_stake_limit":1000,"min_appeal_stake_limit":200,"min_reg_arbitrator_stake_limit":10000,"arbitration_correct_rate":60,"round_limit":3,"arbi_timeout_value":86400,"arbi_freeze_stake_duration":259200,"time_deadline":86400,"clear_data_time_length":10800,"max_data_size":256,"min_provider_limit":1,"max_provider_limit":100,"min_update_cycle":1,"max_update_cycle":8640000,"min_duration":1,"max_duration":8640000,"min_acceptance":1,"max_acceptance":100}}' -p ${contract_oracle} -s -j -d > setconfig.json
90 |
91 | cleos multisig propose_trx setconfig bppermission.json setconfig.json -p ${account}
92 |
93 | cleos multisig approve ${account} setconfig '{"actor":"${account}","permission":"active"}' -p ${account}
94 |
95 | cleos multisig exec ${account} setconfig -p ${account}
96 | ```
97 |
98 | **Parameters:**
99 |
100 | - `version`: integer, the version must match the parameter order and the number of parameter attributes, initially 1
101 | - `core_symbol`: coin symbol, the default is BOS
102 | - `precision`: currency precision, e.g. 1.0000 BOS, the default is 4
103 | - `min_service_stake_limit`: the minimum amount of service required to provide a mortgage, the default is 1000
104 | - `min_appeal_stake_limit`: the base number of the claimant or respondent who needs to be mortgaged. The amount required for the Nth round is `2^(N-1)*min_appeal_stake_limit`, the default is 200
105 | - `min_reg_arbitrator_stake_limit`: the minimum amount of money required to apply for an arbitrator; the default is 10000.
106 | - `arbitration_correct_rate`: the lower limit of arbitration accuracy for the alternative arbitrator, the default is 60
107 | - `round_limit`: the maximum number of arbitration rounds, the result of this round is the final result, the default is 3
108 | - `arbi_timeout_value`: arbitration timeout period, that is, the timeout period of the arbitration case, the timeout period of the re-appeal, the timeout period of the provider or arbitrator response, the time of uploading the arbitration result, the unit second, the default is 86400
109 | - `arbi_freeze_stake_duration`: during the arbitration process, the length of time the provider deposit is frozen after the complainant has filed the appeal, in seconds, the default is 259200s
110 | - `time_deadline`: the user sends a data request, the duration for data to be timeout, we cannot claim rewards after providing the data; the unit is second, default is 86400.
111 | - `clear_data_time_length`: duration to clear table`oracledata`.he unit is second, the default is 10800
112 | - `max_data_size`: size of all action memo; the unit is byte, default is256
113 | - `min_provider_limit`: a service can be created by at least how many providers, the default is 1
114 | - `max_provider_limit`: a service can be created by at most how many providers, the default is 100
115 | - `min_update_cycle`: minimum update period of data. The unit is seconds, the default is 1
116 | - `max_update_cycle`: maximum data update cycle, the unit is second, the default is 8640000.
117 | - `min_duration`: minimum data collection period, the unit is second, the default is 1.
118 | - `max_duration`: maximum data collection period, the unit is second, the defaults to 8640000
119 | - `min_acceptance`: deterministic data can show the minimum number of data providers; if the value is 5, there must be 5 data providers to provide the same data at the same time; the data will appear in the oracledata table, the default is 1
120 | - `max_acceptance`: deterministic data service maximum acceptable number of data providers, default is 100
121 |
122 | # III, Data Provider
123 |
124 | _Details will be released on Oracle Store_
125 |
126 |
127 | ## 3.1 Register Service
128 |
129 | Anyone can create a data service and set the service basic parameters by the creator. After the data service is created, anyone can join and become the data provider by transfer pledge. The **mortgage** is required for registration, and **the mortgage is not lower than the service set mortgage** for the data provider to initiate the service.
130 |
131 | “Intelligent Risk Control” is an option that depends on whether the DApp project party is adopting it. However, from the perspective of market competition, DApps that provide more protection for users will gain more favor....
132 |
133 | ```
134 | cleos push action ${contract_oracle} regservice '{"account":"${create_account}","base_stake_amount":"1000.0000 BOS","data_format":"json", "data_type":0, "criteria":"Subject to majority", "acceptance":51, "declaration":"BTC Price", "injection_method":0, "duration":500,"provider_limit":3, "update_cycle":600}' -p ${account}
135 | ```
136 |
137 | **Parameters:**
138 |
139 | - `account`: Account which register the service
140 | - `base_stake_amount`: Minimum stake amount for provider
141 | - `data_format`: Data format: text, json, custom, if the format is json, input should be`{"xxx":"xxxx"}`
142 | - `data_type`: Data type, 0 is deterministic, 1 is non-deterministic
143 | - `criteria`: Service guidelines, when someone lodges a complaint against the service, the arbitrator will refer to the evidence and service guidelines.
144 | - `acceptance`: This number is the threshold for the provider's data to be valid. For example, there are 10 data providers, 51 means that at least 5 provide the same data.
145 | - `declaration`: Service statement and description
146 | - `injection_method`: Injection mode, 0 is written to the table, and subsequent versions implement other methods.
147 | - `duration`: Data Collection Duration, in seconds
148 | - `provider_limit`: The minimum threshold for the number of data providers required to open the data service
149 | - `update_cycle` : Update cycle, next `cycle_number`, in seconds
150 |
151 | ## 3.2 Join Service
152 |
153 | First, find the oracle service
154 |
155 | ```
156 | cleos get table ${contract_oracle} ${contract_oracle} dataservices
157 | ```
158 |
159 | Find Oracle and transfer/stake EOS to register corresponding service
160 |
161 | ```
162 | cleos transfer ${provider_account} ${contract_oracle} "1000.0000 BOS" "0,${service_id}"
163 | ```
164 |
165 | If the creator does not find the service to be registered, you can register the service before joining.
166 |
167 | **Transfer and Stake memo:**
168 |
169 | - `num`:**0 is to join service**
170 | - `service_id`: Service ID
171 |
172 | ### 3.2.1 Service Example
173 |
174 | **Step 1: Check All Services**
175 |
176 | ```
177 | cleos get table ${contract_oracle} ${contract_oracle} dataservices
178 | ```
179 |
180 | Result:
181 | ```
182 | {
183 | "rows": [{
184 | "service_id": 1,
185 | "data_type": 0,
186 | "status": 1,
187 | "injection_method": 0,
188 | "acceptance": 3,
189 | "duration": 3000,
190 | "provider_limit": 3,
191 | "update_cycle": 3600,
192 | "last_update_number": 0,
193 | "appeal_freeze_period": 0,
194 | "exceeded_risk_control_freeze_period": 0,
195 | "guarantee_id": 0,
196 | "base_stake_amount": "1000.0000 BOS",
197 | "risk_control_amount": "0.0000 BOS",
198 | "pause_service_stake_amount": "0.0000 BOS",
199 | "data_format": "json",
200 | "criteria": "Subject to majority",
201 | "declaration": "BTC Price"
202 | },{
203 | "service_id": 2,
204 | "data_type": 0,
205 | "status": 0,
206 | "injection_method": 0,
207 | "acceptance": 3,
208 | "duration": 3000,
209 | "provider_limit": 3,
210 | "update_cycle": 3600,
211 | "last_update_number": 0,
212 | "appeal_freeze_period": 0,
213 | "exceeded_risk_control_freeze_period": 0,
214 | "guarantee_id": 0,
215 | "base_stake_amount": "1000.0000 BOS",
216 | "risk_control_amount": "0.0000 BOS",
217 | "pause_service_stake_amount": "0.0000 BOS",
218 | "data_format": "{\"data\":\"2019-05-07\",\"time\":\"12:22:21\"}",
219 | "criteria": "Subject to majority",
220 | "declaration": "Oil Price",
221 | "update_start_time": "2019-09-19T03:00:00"
222 | }
223 | ],
224 | "more": false
225 | }
226 | ```
227 |
228 | the Oracle Service's `status` can be one of the list:
229 |
230 | - `service_init`，need to initiate
231 | - `service_in`，normal
232 | - `service_cancel`，cancel
233 | - `service_pause`，pause
234 | - `service_freeze`，freeze
235 | - `service_emergency`，emergency
236 | - `service_pause_insufficient_providers`
237 |
238 | **Step 2: Join the service_id 1**
239 |
240 | ```
241 | cleos transfer oracleprovi1 ${contract_oracle} "1000.0000 BOS" "0,1"
242 | ```
243 |
244 | **Step 3: Find `oracleprovi1` through command below**
245 |
246 | ```
247 | cleos get table ${contract_oracle} 1 svcprovision
248 | ```
249 |
250 | Result:
251 | ```
252 | {
253 | "rows": [{
254 | "service_id": 1,
255 | "account": "oracleprovi1",
256 | "amount": "1000.0000 BOS",
257 | "freeze_amount": "0.0000 BOS",der
258 | "service_income": "0.0000 BOS",
259 | "status": 0,
260 | "public_information": "",
261 | "create_time": "2019-09-26T02:30:31"
262 | }
263 | ],
264 | "more": false
265 | }
266 | ```
267 |
268 |
269 | ## 3.3 Provider Reduce Stakes
270 |
271 | Provider can reduce service stakes, but no less than the provider_limit
272 |
273 | ```
274 | cleos push action ${contract_oracle} unstakeasset '{"service_id":${service_id},"account":"${provider_account}","amount":"1.0000 BOS","memo":"unstake mount"}' -p ${provider_account}
275 | ```
276 |
277 | **Parameters:**
278 |
279 | - `service_id`: Service ID
280 | - `provider_account`: Data Provider Account
281 | - `amount`: unstake amount
282 | - `memo`: memo
283 |
284 | ## 3.4 Push Data
285 |
286 | After the oracle machine service is successfully added, the data will be uploaded: upload
287 |
288 | ```
289 | cleos push action ${contract_oracle} pushdata '{"service_id":1,"provider":"${provider_account} ","cycle_number":"3","request_id":0,"data":"1 test data json 3 "}' -p ${provider_account}
290 | ```
291 |
292 | **Parameters:**
293 | - `service_id`: Service ID
294 | - `provider_account`: Provider
295 | - `cycle_number`: the number is calculated according to the `update_cycle` of the service, and the calculation formula `cycle_number=current seconds/update_cycle`; when each round exceeds duration, the data is not allowed to be uploaded.
296 | - `request_id`: The id of the data user when the request is initiated, and the data provider needs to correspond to upload data, in v1.0 `request_id` is 0
297 | - `data`: In order to upload the content of the data, all data providers must upload the data according to the provisions of the service, otherwise the upload will fail.
298 |
299 |
300 | # IV, Dapp
301 |
302 | Dapp can obtain data through `service_id`. If the service is deterministic, we can only obtain one data for each `cycle_number` ; If the service is an non-deterministic data type, each `cycle_number` of the service can see multiple pieces of data, and the user needs to select according to his own needs.
303 |
304 | ```
305 | cleos get table ${contract_oracle} ${service_id} oracledata
306 | ```
307 |
308 | **Parameters:**
309 | - `service_id`: Service ID
310 |
311 | ## 4.1 Deterministic Data:
312 | Take the lottery draw result as an example, Service ID = 5 is the final result
313 | ```
314 | cleos get table ${contract_oracle} 5 oracledata
315 | {
316 | "rows": [{
317 | "record_id": 0,
318 | "request_id": 0,
319 | "cycle_number": 2,
320 | "data": "02 03 01 17 12 04 05",
321 | "timestamp": 1569554558
322 | },{
323 | "record_id": 1,
324 | "request_id": 0,
325 | "cycle_number": 4,
326 | "data": "02 12 34 11 02 04 15",
327 | "timestamp": 1569563694
328 | }
329 | ],
330 | "more": false
331 | }
332 | ```
333 |
334 | ## 4.2 Non-deterministic Data:
335 | Take BTC Price as an example, to find Service ID is 7, and obtain the current BTC price:
336 | ```
337 | cleos get table ${contract_oracle} 7 oracledata
338 | ```
339 |
340 | result:
341 | ```
342 | {
343 | "rows": [{
344 | "record_id": 0,
345 | "request_id": 0,
346 | "cycle_number": 1,
347 | "data": "time:2019-09-27T03:27:33.216857+00:00,price:8901 USDT",
348 | "timestamp": 1569552869
349 | },{
350 | "record_id": 1,
351 | "request_id": 0,
352 | "cycle_number": 1,
353 | "data": "time:2019-09-27T03:29:33.216857+00:00,price:8911 USDT",
354 | "timestamp": 1569552932
355 | },{
356 | "record_id": 2,
357 | "request_id": 0,
358 | "cycle_number": 1,
359 | "data": "time:2019-09-27T03:29:33.216857+00:00,price:8910 USDT",
360 | "timestamp": 1569552965
361 | }
362 | ],
363 | "more": false
364 | }
365 | ```
366 |
367 | # V, Arbitration
368 |
369 | ## 5.1 Arbitrator Registration (mortgage)
370 |
371 | The first round of arbitrators will appointed 21 designated BOS WPS full-time auditors; in the later period, open community registration, in order to ensure that the arbitration is effective and fair, the arbitrators must vote through the community to meet the conditions to be eligible. The minimum deposit at registration is 100000 BOS.
372 |
373 | Transfer Mortgage Registration Arbitrator:
374 |
375 | ```
376 | cleos transfer ${arbitrator_account} ${contract_oracle} "100000.0000 BOS" "4,1" -p ${arbitrator_account}
377 | ```
378 |
379 | **Transfer and Stake memo:**
380 | - `${arbitrator_account}`: Arbitration Account
381 | - `num`:**4 is arbitrator registration**
382 | - `arbitrat_type`: 1 is full-time arbitrator, 2 is public arbitrator
383 |
384 | ## 5.2 Arbitration Commence
385 |
386 | If the user or DAPP party is in use, if there is any problem with the service data, you can apply for arbitration.
387 |
388 | - If the respondent is not accepted, the system will determine that there is no response and the respondent lose the corresponding deposit, and if it is the data provider, the mortgage deposit will be deducted.
389 | - If the arbitrator does not respond, the system will re-select the appropriate number of remaining arbitrators to send the invitation notice.
390 | - The arbitration process will send a notice to the relevant party's account by transfer, and the Oracle Store will also push the notification through the registered channel.
391 |
392 | There are 9 arbitration steps:
393 |
394 | 1. `arbi_init` arbitration initiated
395 | 2. `arbi_choosing_arbitrator` select arbitrator
396 | 3. `arbi_wait_for_resp_appeal` wait for respond
397 | 4. `arbi_wait_for_accept_arbitrate_invitation` wait arbitrator to accept invitation
398 | 5. `arbi_wait_for_upload_result` wait arbitrator to upload result
399 | 6. `arbi_wait_for_reappeal` wait and reappeal
400 | 7. `arbi_resp_appeal_timeout_end` respond timeout
401 | 8. `arbi_reappeal_timeout_end` reappeal timeout
402 | 9. `arbi_public_end` publish the result
403 |
404 |
405 | Query current status through `arbitration_id`:
406 |
407 | ```
408 | cleos get table ${contract_oracle} ${arbitration_id} arbicase
409 | ```
410 |
411 | **Parameter:**
412 |
413 | - `arbitration_id`: Arbitration ID
414 | - `arbi_step`: Status of the Arbitration Case
415 | - `last_round`: Last Round
416 | - `final_result`: 1 claimant win, 2 respondent win
417 | - `arbitrators`: list of available arbitrators
418 | - `chosen_arbitrators`: list of chosen arbitrators
419 |
420 | Check `arbitration_id=4`:
421 |
422 | ```
423 | cleos get table ${contract_oracle} 4 arbicase
424 | ```
425 |
426 | Result:
427 |
428 | ```
429 | {
430 | "rows": [{
431 | "arbitration_id": 4,
432 | "arbi_step": 6,
433 | "arbitration_result": 2,
434 | "last_round": 2,
435 | "final_result": 0,
436 | "answer_arbitrators": [
437 | "arbitrator12",
438 | "arbitrator14",
439 | "arbitrator35",
440 | "arbitrator23",
441 | "arbitrator15",
442 | "arbitrator42",
443 | "arbitrator22",
444 | "arbitrator13"
445 | ],
446 | "chosen_arbitrators": [
447 | "arbitrator12",
448 | "arbitrator35",
449 | "arbitrator14",
450 | "arbitrator23",
451 | "arbitrator15",
452 | "arbitrator42",
453 | "arbitrator22",
454 | "arbitrator13"
455 | ]
456 | }
457 | ],
458 | "more": false
459 | }
460 | ```
461 |
462 | ### 5.2.1 Account Initiate Appeal
463 |
464 | If the data user or data provider finds that someone has cheated and provided false information, they can initiate an appeal; the first mortgage amount must not be less than 200 BOS at the time of appeal, and the subsequent mortgages must not be less than: `200*2^(N-1), N is round number`。
465 |
466 | Transfer mortgage to initiate an appeal:
467 |
468 | ```
469 | cleos transfer ${initiator_account} ${contract_oracle} "200.0000 BOS" "3,${service_id},'evidence','info','reason'" -p ${initiator_account}
470 | ```
471 |
472 | **Transfer and Stake memo:**
473 |
474 | - `initiator_account`: Initiator Account
475 | - `num`:**3 = Appeal**
476 | - `service_id`: Service ID
477 | - `evidence`: Evidence submitted at the time of appeal, recommended as IPFS file address
478 | - `info`: Public information
479 | - `reason`: reason for appeal
480 |
481 | After the appeal order is issued, it will be notified by `transfer` ACTION, and all respondents will be notified. if any account should respond (including accounts other than the notice), and the case will be established.
482 |
483 | ### 5.2.2 Responding to the accounts
484 |
485 | When someone complains, the relevant personnel will receive the notice of the appeal. At this time, the responding order needs to be executed to inform the other party to accept the appeal. At this time, the arbitration process is officially opened; if no one responds, after the timeout, the complainant will be directly judged as the winner. If the data provider is the losing party, all the mortgage payments for the data service will be deducted and distributed to the claimant.
486 |
487 | The first responding mortgage is at least 200 BOS, and the subsequent mortgages must not be less than: 200*2^(N-1), N is the number of rounds.
488 |
489 | ```
490 | cleos transfer ${accept_account} ${contract_oracle} "200.0000 BOS" "5,${arbitrat_id},'evidence'" -p ${accept_account}
491 | ```
492 |
493 | **Transfer and Stake memo:**
494 |
495 | - `accept_account`: respondent account
496 | - `num`: ,**5 is response**
497 | - `arbitrat_id`: Arbitration ID
498 | - `evidence`: Evidence submitted at the time of appeal, recommended as IPFS file address
499 |
500 | ### 5.2.3 Arbitrator Accepts Invitation
501 |
502 | When the data provider responds, it will send an arbitration invitation to the arbitrator. Only `2^N+` arbitrators can accept the invitation before proceeding to the next step: Upload the arbitration result. If an arbitrator accepts the invitation over time, it will re-select from the remaining arbitrators until `2^N+1` arbitrators accept all, `N` is the number of rounds.
503 |
504 | Arbitrator accept invitation:
505 |
506 | ```
507 | cleos push action ${contract_oracle} acceptarbi '["${arbitrator}",${arbitrat_id}]' -p ${arbitrator}@active
508 | ```
509 |
510 | **Parameters:**
511 |
512 | - `arbitrator`: Arbitrator
513 | - `arbitrat_id`: Arbitration ID
514 |
515 | ### 5.2.4 Arbitrator Uploads Result
516 |
517 | Arbitrator upload result:
518 |
519 | ```
520 | cleos push action ${contract_oracle} uploadresult '["${arbitrator}",${arbitrat_id}, ${result},'memo']' -p {arbitrator}@active
521 | ```
522 |
523 | **Parameters:**
524 |
525 | - `arbitrator`: Arbitration Account
526 | - `arbitrat_id`: Arbitration ID
527 | - `result`: 1 is claimant win, 2 is respondent win
528 | - `memo`: include the IPFS address of the arbitration process
529 |
530 | ### 5.2.5 End of Arbitration
531 |
532 | Two ways to end arbitration process:
533 |
534 | - After the arbitration result is uploaded, if no one initiates the appeal again, the arbitration will be closed after 72 hours;
535 | - In version 1.0, only `full-time arbitrators` are supported, claimant can have up to three rounds of arbitration
536 |
537 | After the arbitration is over, the arbitration will result in the final result, and the relevant account will be rewarded/punished.
538 |
539 | ## 5.3 Arbitration stakeholders can claim rewards
540 |
541 | After the arbitration case is over, the relevant personnel involved in the arbitration can be rewarded because the arbitration process involves three different roles. The claimant, the respondent, the arbitrator, and the distribution of income for different roles are also different. To receive the rewards from arbitration, stakeholders should call action `claim` to claim reward
542 |
543 | - Arbitrator: The reward is derived from**loser's mortgage**
544 | - Data users: If successful, all**service mortgage of the data provider** will be distributed equally to all appeal accounts, and the data users' appeal mortgage will be refunded.
545 | - Data provider: If successful, the appeal mortgage will be refunded
546 | - If the data provider sues other data providers, the winner is divided into the other party's**service mortgage**
547 |
548 |
549 | View Arbitration Income:
550 |
551 | ```
552 | cleos get table ${contract_oracle} ${account} arbiincomes
553 | ```
554 |
555 | Claim income:
556 |
557 | ```
558 | cleos push action ${contract_oracle} claimarbi '["${account}","${receive_account}"]' -p ${account}
559 | ```
560 |
561 | **Parameters:**
562 | - `account`: account related to the arbitration
563 | - `receive_account`: account which receive the arbitration rewards
564 |
565 | ## 5.4 Unstaking Arbitration Mortgage
566 |
567 | After the arbitration is over, the winner can query the mortgage amount from table and unstake the mortgage.
568 |
569 | **1. Query the current mortgage number of the arbitration:**
570 |
571 | ```
572 | cleos get table ${contract_oracle} ${arbitrat_id} arbistakeacc
573 | ```
574 |
575 | **Parameters:**
576 |
577 | `arbitrat_id`: Arbitration ID, if the arbitration is end, the value will be `uint64_t(1)<<63 + arbitrat_id`
578 |
579 | **2. Unstaking:**
580 |
581 | ```
582 | cleos push action ${contract_oracle} unstakearbi '{"arbitration_id":${arbitrat_id},"account":"${account}","amount":"100.0000 BOS","memo":"unstake mount"}' -p ${account}
583 | ```
584 |
585 | **Parameters:**
586 | - `arbitrat_id`: Arbitration ID
587 | - `account`: account for unstaking
588 | - `amount`: The number of tokens to be mortgaged(cannot be greater than the number of mortgages)
589 | - `memo`: memo
590 |
591 | # V, Transfer and Stake Memo Explanation
592 |
593 | memo : `"Service Type,Service ID,……."`
594 |
595 | **1. Register Service:**
596 | memo : `"0,Service ID"`
597 |
598 | ```
599 | cleos transfer ${provider_account} ${contract_oracle} "1000.0000 BOS" "0,${service_id}"
600 | ```
601 |
602 | **2. Appeal Service:**
603 | memo : `"3,Service ID,evidence,public info,appeal reason"`
604 |
605 | ```
606 | cleos transfer ${initiator_account} ${contract_oracle} "200.0000 BOS" "3,${service_id},'evidence','info','reason'" -p ${initiator_account}
607 | ```
608 |
609 | **3. Register Arbitrator:**
610 | memo : `"4,Service ID"`
611 |
612 | ```
613 | cleos transfer ${arbitrator_account} ${contract_oracle} "10000.0000 BOS" "4,1" -p ${arbitrator_account}
614 | ```
615 |
616 | **4. Respond to Appeal:**
617 | memo : `"5,Service ID,evidence"`
618 |
619 | ```
620 | cleos transfer ${accept_account} ${contract_oracle} "200.0000 BOS" "5,${service_id},'evidence'" -p ${accept_account}
621 | ```
622 |
623 |
624 | # VII, Oracle tables
625 |
626 | **1. Query all current service information**
627 |
628 | ```
629 | cleos get table ${contract_oracle} ${contract_oracle} dataservices
630 | ```
631 |
632 | **2. Query the details of a service**
633 |
634 | ```
635 | cleos get table ${contract_oracle} ${service_id} svcprovision
636 | ```
637 |
638 | **3. Query all data display of a service**
639 |
640 | ```
641 | cleos get table ${contract_oracle} ${service_id} oracledata
642 | ```
643 |
644 | **4. Query all current data provider information**
645 |
646 | ```
647 | cleos get table ${contract_oracle} ${contract_oracle} providers
648 | ```
649 |
650 | **5. Query all current arbitrator information**
651 |
652 | ```
653 | cleos get table ${contract_oracle} ${contract_oracle} arbitrators
654 | ```
655 |
656 | **6. Query the progress of an arbitration case**
657 |
658 | ```
659 | cleos get table ${contract_oracle} ${arbitrat_id} arbicase
660 | ```
661 |
662 | **7. Query the Arbitration Evidence**
663 |
664 | ```
665 | cleos get table ${contract_oracle} ${arbitrat_id} arbievidence
666 | ```
667 |
668 | **8. Query the mortgage of an ongoing arbitration case**
669 |
670 | ```
671 | cleos get table ${contract_oracle} ${arbitrat_id} arbistakeacc
672 | ```
673 |
674 | **9. Query the information of a closed arbitration case**
675 |
676 | ```
677 | cleos get table ${contract_oracle} ${9223372036854775808+arbitrat_id} arbistakeacc
678 | ```
679 |
680 | **10. View Arbitration Income Statement**
681 |
682 | ```
683 | cleos get table ${contract_oracle} ${account} arbiincomes
684 | ```
685 |
--------------------------------------------------------------------------------
/Oracle/BOS_Oracle_入门.md:
--------------------------------------------------------------------------------
1 | BOS.Oracle 介绍: 见证与变革
2 | ----------
3 |
4 | # 一、背景
5 |
6 | 区块链广为人知，底层技术已经有了比较大的突破，但是应用场景并不多，主要还是链处于一个封闭的系统，无法与外界信息通讯。但是如果能将人类社会中已有的数据通过**可信的方式**上传到链上，打通区块链与现实世界通路，这样就可以大大增加区块链的应用场景。
7 |
8 | 在现实世界中，商家如果不能确定能收到钱就不会将商品出售，消费者如果不能确定商品的真伪就不敢贸然购买。“可信”是现实世界中交易的最基本条件，如果我们无法达成信任那么也就无法完成交易。信任对我们来说是如此的重要，然而很多时候难以达成信任，往往只能依赖于交易双方的信誉（这本质上是依托于以往的交易历史，做概率上的估计）或者依托于某个可信的第三方（它是否真的可信，信任的基础又来自于哪里？）。在复杂的现实环境中，这使得我们承担了更多的风险，耗费了更多的精力和资源。怎样解决这一问题？能否结合区块链技术来改变这一现状？BOS 的预言机（Oracle）服务就是我们的答案，希望能够作为区块链与现实世界的数据桥梁。
9 |
10 | 有些预言机服务的设计是基于可信数据源或者权威数据源这一假设，这样的假设从理论上来说有很大风险，无法保证这种数据源提供数据的真实性。BOS 的预言机系统从构建之初所遵循的原则就是：
11 |
12 | 不依赖于每一个预言机数据提供者一定会提供真实数据，而是承认其不足进而将其作为博弈的参与方加入到系统中来，以期在博弈中达到整体可信
13 |
14 | 这样在博弈过程中只要将参与方与现实世界的角色进行映射，那么不但能得到区块链输入数据的可信性，同时我们还可以向现实世界输出“信任”。事实上这更像是一个基于区块链的可信平台，而它的服务展示形式是预言机。BOS 预言机将会使得区块链的价值从其货币属性延伸到了交易和规则的构建上，这种延伸将会解决或改进许多现实世界的信任问题，从而扩大区块链的应用边界，并最终让区块链技术可以在交易转账以外场景落地。
15 |
16 | # 二、介绍
17 |
18 | ## 2.1 系统组成
19 | 
20 |
21 | BOS 预言机为了应对不同情形、不同级别的预言机服务冲突，采用“**双向举证**”，通过“**不同仲裁员**”和“**多轮仲裁**”等机制来得到最终仲裁结果。在仲裁中采用抵押机制作为最终处罚锚点，申诉制和检举制同时进行，相互监督；用收益分成以及惩罚金作为奖励的方式激励仲裁员，并且引入信用体系以实现非一次性博弈下模型的稳定和可信。
22 |
23 | 预言机服务功能：提供数据、获取数据、仲裁功能
24 |
25 | 预言机服务角色：提供方、使用方、DAPP合约方、仲裁员
26 |
27 | 预言机服务特点：仲裁体系完善、博弈模型完备、正向激励系统化、场景覆盖广
28 |
29 | ## 2.2 提供预言机服务
30 |
31 | 数据提供方可以在 BOS 上创建自己的数据服务上传数据供大家使用，最终将数据价值变现。
32 |
33 | ## 2.3 使用预言机服务
34 |
35 | 数据使用者可以根据自己的需求使用已有预言机服务，也可以作为发起方参与到相应预言机服务当中，并从服务上获取所需的数据。
36 |
37 | 针对丰富的预言机服务，使用者可以方便的在 Oracle Store 查询、检索对应的预言机服务。
38 |
39 | ## 2.4 仲裁功能
40 |
41 | 仲裁模块是系统公平的来源。为了避免行贿的达成，系统采用了多轮仲裁、每一轮仲裁员人数逐级增加的方案。随着仲裁员规模的扩大将使行贿变越来越困难，成本也急剧提高，最终会导致行贿失败。
42 |
43 | BOS 预言机的仲裁模型中会分成两个阶段：
44 |
45 | - “全职仲裁员”阶段，该阶段的仲裁员共 21 名，他们必须对仲裁案件进行及时的响应；这一阶段总共可以进行3轮仲裁，每一轮人数为3、5、9，并且每轮人数不重复；
46 | - “大众仲裁员”阶段，该阶段会让整个预言机系统的参与者加入，大范围进行仲裁，随机选择抽样，以多数为准；“大众仲裁员”的数量会有一定规则，防止女巫攻击。
47 |
48 | 
49 |
50 | ## 2.5 智能风控
51 |
52 | 为最大限度的保证安全，“智能风控”始终能够保证数据提供者有足够的抵押 Token 被锁定来对其进行惩罚。它的主要逻辑是使用基于预言机服务DApp的玩家将 Token 直接转入到“智能风控”的账户而不是 DApp 项目方的账户，当有人针对该预言机服务发起仲裁的时候，“智能风控”将会根据数据提供者的历史行为以及当前支出等信息智能的计算出资金冻结时间以及解冻周期。如果整个过程没有出现异常，DApp 项目方可以正常地从“智能风控”账户提取 Token。
53 |
54 | “智能风控”是一个可选项，取决于 DApp 项目方是否采用。但从市场竞争的角度来看，为用户提供更多保障的 DApp 将会获得更多的青睐。
55 |
56 | 
57 |
58 | ## 2.6 文档变量约定
59 |
60 | 下文出现的变量的含义：
61 |
62 | - `${contract_oracle}`： BOS预言机服务合约账户
63 | - `${provider_account}`： 数据提供方账户
64 |
65 | ## 2.7 预言机全局参数配置
66 |
67 | 在部署完 Oracle 合约以后，需要进行系统参数初始化。
68 |
69 | ```
70 | cleos push action ${contract_oracle} setparameter '{"version":1,"parameters":{"core_symbol":"BOS","precision":4,"min_service_stake_limit":1000,"min_appeal_stake_limit":200,"min_reg_arbitrator_stake_limit":10000,"arbitration_correct_rate":60,"round_limit":3,"arbi_timeout_value":86400,"arbi_freeze_stake_duration":259200,"time_deadline":86400,"clear_data_time_length":10800,"max_data_size":256,"min_provider_limit":1,"max_provider_limit":100,"min_update_cycle":1,"max_update_cycle":8640000,"min_duration":1,"max_duration":8640000,"min_acceptance":1,"max_acceptance":100}}' -p ${contract_oracle} -s -j -d > setconfig.json
71 |
72 | cleos multisig propose_trx setconfig bppermission.json setconfig.json -p ${account}
73 |
74 | cleos multisig approve ${account} setconfig '{"actor":"${account}","permission":"active"}' -p ${account}
75 |
76 | cleos multisig exec ${account} setconfig -p ${account}
77 | ```
78 |
79 | 参数说明：
80 |
81 | - version：整型，版本必须匹配参数顺序和参数属性数目，初始为 1
82 | - core_symbol：币种名称，默认为 BOS
83 | - precision：币种精度，如1.0000 BOS， 默认为 4
84 | - min_service_stake_limit：提供服务需要抵押的最少金额，默认为 1000
85 | - min_appeal_stake_limit：申诉者或应诉者需要抵押的基数 ，第 N 轮需要抵押金额为`2^(N-1)*min_appeal_stake_limit`，默认为 200
86 | - min_reg_arbitrator_stake_limit：申请仲裁员最少需要抵押的金额，默认为 10000
87 | - arbitration_correct_rate：备选仲裁员的仲裁正确率下限，默认为 60
88 | - round_limit：最大仲裁轮数，该轮结果为最终结果，默认为 3
89 | - arbi_timeout_value：仲裁超时时间，即仲裁案件超时时间、再次申诉超时时间、提供者或仲裁员响应超时时间、上传仲裁结果时间，单位秒，默认为 86400
90 | - arbi_freeze_stake_duration：仲裁过程中，申诉者提起申诉受理后，提供者押金被冻结的时长，单位秒，默认为 259200
91 | - time_deadline：使用者发送数据请求，等待数据的超时时间，超时后提供数据无法获取奖励，单位秒，默认为 86400
92 | - clear_data_time_length：数据表oracledata清理时间，单位秒，默认为 10800
93 | - max_data_size：所有action memo的最大长度，单位字节，默认为 256
94 | - min_provider_limit： 一个服务至少有多少提供者才能创建，默认为 1
95 | - max_provider_limit：一个服务至多不能超过多少提供者，默认为 100
96 | - min_update_cycle：数据最少更新周期，单位秒，默认为 1
97 | - max_update_cycle：数据最大更新周期，单位秒，默认为 8640000
98 | - min_duration：数据最少收集期限，单位秒，默认为 1
99 | - max_duration：数据最大收集期限，单位秒，默认为 8640000
100 | - min_acceptance：确定性数据可显示最少数据提供者数，如该值为5，必须有5个数据提供者在期限内同时提供相同数据，数据才会出现在oracledata表，默认为 1
101 | - max_acceptance：确定性数据服务最大可接受数据提供者数，默认为 100
102 |
103 |
104 | # 三、数据提供方相关操作
105 |
106 | _注：文章中以命令讲解，相关功能都可以在 Oracle Store 页面进行操作_
107 |
108 |
109 | ## 3.1 注册服务
110 |
111 | 任何人都可以创建数据服务，并由创建者设置服务基本参数。数据服务创建好后，任何人均可以通过转账质押的方式加入并成为数据提供方，注册时需要**抵押保证金，且保证金不低于服务设置的保证金**才能可成为服务的数据提供方。
112 |
113 | ```
114 | cleos push action ${contract_oracle} regservice '{"account":"${create_account}","base_stake_amount":"1000.0000 BOS","data_format":"json", "data_type":0, "criteria":"以多数人为准", "acceptance":51, "injection_method":0, "duration":500,"provider_limit":3, "update_cycle":600}' -p ${account}
115 | ```
116 |
117 | **参数说明：**
118 |
119 | - `account`：创建服务的账户名
120 | - `base_stake_amount`：服务的最低抵押 Token 的额度 1000
121 | - `data_format`：数据格式，分为：text、json、custom，如果是 json 格式，需要输入`{"xxx":"xxxx"}`
122 | - `data_type`：数据类型，0为确定性，1为不确定性
123 | - `criteria`：服务准则，当有人对服务发起申诉时，仲裁员会根据证据和服务准则进行裁判
124 | - `acceptance`：相同数据提供者所占百分比的最小值，小于该值时数据无效，比如共有10个数据提供者，`51`就意为至少5个提供相同数据
125 | - `injection_method`：注入方式，0为写入表，后续版本实现其他方式
126 | - `duration`：数据收集持续时间，单位为秒
127 | - `provider_limit`：数据服务开启所需数据提供方数量的最低阈值
128 | - `update_cycle` ：更新周期，超过这个周期将进入下一个 `cycle_number`，单位为秒
129 |
130 | ## 3.2 加入服务
131 |
132 | 首先，要查找感兴趣的预言机服务
133 |
134 | ```
135 | cleos get table ${contract_oracle} ${contract_oracle} dataservices
136 | ```
137 |
138 | 发现目标服务，通过转账质押 EOS 注册加入相应服务
139 |
140 | ```
141 | cleos transfer ${provider_account} ${contract_oracle} "1000.0000 BOS" "0,${service_id}"
142 | ```
143 |
144 | 若创建者没有发现要注册的服务，可以先注册服务，然后再加入。
145 |
146 | **转账抵押 memo 说明：**
147 | - `num`：转账抵押类型，**0为加入服务**
148 | - `service_id`：服务 ID
149 |
150 | ### 3.2.1 示例
151 |
152 | **步骤1：查看所有服务信息**
153 |
154 | ```
155 | cleos get table ${contract_oracle} ${contract_oracle} dataservices
156 | ```
157 |
158 | 结果：
159 | ```
160 | {
161 | "rows": [{
162 | "service_id": 1,
163 | "data_type": 0,
164 | "status": 1,
165 | "injection_method": 0,
166 | "acceptance": 3,
167 | "duration": 3000,
168 | "provider_limit": 3,
169 | "update_cycle": 3600,
170 | "last_update_number": 0,
171 | "appeal_freeze_period": 0,
172 | "exceeded_risk_control_freeze_period": 0,
173 | "guarantee_id": 0,
174 | "base_stake_amount": "1000.0000 BOS",
175 | "risk_control_amount": "0.0000 BOS",
176 | "pause_service_stake_amount": "0.0000 BOS",
177 | "data_format": "json",
178 | "criteria": "以多数人为准",
179 | "update_start_time": "2019-09-19T03:00:00"
180 | },{
181 | "service_id": 2,
182 | "data_type": 0,
183 | "status": 0,
184 | "injection_method": 0,
185 | "acceptance": 3,
186 | "duration": 3000,
187 | "provider_limit": 3,
188 | "update_cycle": 3600,
189 | "last_update_number": 0,
190 | "appeal_freeze_period": 0,
191 | "exceeded_risk_control_freeze_period": 0,
192 | "guarantee_id": 0,
193 | "base_stake_amount": "1000.0000 BOS",
194 | "risk_control_amount": "0.0000 BOS",
195 | "pause_service_stake_amount": "0.0000 BOS",
196 | "data_format": "{\"data\":\"2019-05-07\",\"time\":\"12:22:21\"}",
197 | "criteria": "以多数人为准",
198 | "update_start_time": "2019-09-19T03:00:00"
199 | }
200 | ],
201 | "more": false
202 | }
203 | ```
204 |
205 | 一个预言机服务状态`status`有以下几种：
206 |
207 | - `service_init`，初始化
208 | - `service_in`，正常可用
209 | - `service_cancel`，取消
210 | - `service_pause`，暂停
211 | - `service_freeze`，冻结
212 | - `service_emergency`，紧急
213 | - `service_pause_insufficient_providers`，由于提供者不足暂停
214 |
215 | **步骤2：加入 service_id 为1 的服务**
216 |
217 | ```
218 | cleos transfer oracleprovi1 ${contract_oracle} "1000.0000 BOS" "0,1"
219 | ```
220 |
221 | **步骤3：加入成功后，可以通过命令查看到当前服务下有 `oracleprovi1`**
222 |
223 | ```
224 | cleos get table ${contract_oracle} 1 svcprovision
225 | ```
226 |
227 | 结果：
228 | ```
229 | {
230 | "rows": [{
231 | "service_id": 1,
232 | "account": "oracleprovi1",
233 | "amount": "1000.0000 BOS",
234 | "freeze_amount": "0.0000 BOS",der
235 | "service_income": "0.0000 BOS",
236 | "status": 0,
237 | "public_information": "",
238 | "create_time": "2019-09-26T02:30:31"
239 | }
240 | ],
241 | "more": false
242 | }
243 | ```
244 |
245 |
246 | ## 3.3 数据提供方减少抵押
247 |
248 | 数据提供方可减少服务抵押金，但是减少后的抵押金额不能低于服务设置的最低金额。
249 | ```
250 | cleos push action ${contract_oracle} unstakeasset '{"service_id":${service_id},"account":"${provider_account}","amount":"1.0000 BOS","memo":"unstake mount"}' -p ${provider_account}
251 | ```
252 |
253 | **参数说明：**
254 |
255 | - `service_id`：提供方想要解抵押的服务 ID
256 | - `account`：想要解抵押的数据提供方账户
257 | - `amount`：解抵押金额
258 | - `memo`：备注信息
259 |
260 | ## 3.4 上传数据
261 |
262 | 预言机服务加入成功后，即可将数据上传：
263 |
264 | ```
265 | cleos push action ${contract_oracle} pushdata '{"service_id":1,"provider":"${provider_account} ","cycle_number":"3","request_id":0,"data":"1 test data json 3 "}' -p ${provider_account}
266 | ```
267 |
268 | **参数说明：**
269 | - `service_id`：服务 ID
270 | - `provider`：数据提供方
271 | - `cycle_number`：更新编号，编号是根据服务的 `update_cycle` 计算出来的，计算公式`cycle_number=当前秒数/update_cycle`；每一轮超过时间大于 `duration` 时，不允许上传数据
272 | - `request_id`：数据使用者发起请求时的 id，数据提供方上传数据需要对应，1.0 版本 `request_id` 为 0
273 | - `data`：为上传数据的内容，所有的数据提供方需按照服务的规定上传数据，否则将上传失败
274 |
275 |
276 | # 四、Dapp 项目方相关操作
277 |
278 | Dapp 方可根据 `service_id` 通过查询数据表获取数据。如果服务是确定性数据类型，则每个 `cycle_number` 只能看到一条数据；若服务为不确定性数据类型，服务的每个 `cycle_number` 能看到多条数据，用户需要根据自己的需要进行选择。
279 |
280 | ```
281 | cleos get table ${contract_oracle} ${service_id} oracledata
282 | ```
283 |
284 | **参数说明：**
285 | - `service_id`：服务 ID
286 |
287 | ## 4.1 确定性数据：
288 | 以彩票结果为例，服务 ID 5 为彩票结果服务
289 | ```
290 | cleos get table ${contract_oracle} 5 oracledata
291 | {
292 | "rows": [{
293 | "record_id": 0,
294 | "request_id": 0,
295 | "cycle_number": 2,
296 | "data": "02 03 01 17 12 04 05",
297 | "timestamp": 1569554558
298 | },{
299 | "record_id": 1,
300 | "request_id": 0,
301 | "cycle_number": 4,
302 | "data": "02 12 34 11 02 04 15",
303 | "timestamp": 1569563694
304 | }
305 | ],
306 | "more": false
307 | }
308 | ```
309 |
310 | ## 4.2 不确定数据：
311 | 以 BTC 价格为例，先查找到当前的服务 ID，发现对应的服务 ID 为7，获取当前服务所有的 BTC 价格：
312 | ```
313 | cleos get table ${contract_oracle} 7 oracledata
314 | ```
315 |
316 | 结果：
317 | ```
318 | {
319 | "rows": [{
320 | "record_id": 0,
321 | "request_id": 0,
322 | "cycle_number": 1,
323 | "data": "time:2019-09-27T03:27:33.216857+00:00,price:8901 USDT",
324 | "timestamp": 1569552869
325 | },{
326 | "record_id": 1,
327 | "request_id": 0,
328 | "cycle_number": 1,
329 | "data": "time:2019-09-27T03:29:33.216857+00:00,price:8911 USDT",
330 | "timestamp": 1569552932
331 | },{
332 | "record_id": 2,
333 | "request_id": 0,
334 | "cycle_number": 1,
335 | "data": "time:2019-09-27T03:29:33.216857+00:00,price:8910 USDT",
336 | "timestamp": 1569552965
337 | }
338 | ],
339 | "more": false
340 | }
341 | ```
342 |
343 | # 五、如何进行仲裁
344 |
345 | ## 5.1 注册仲裁员（抵押）
346 |
347 | 第一届全职仲裁员由21个指定的 BOS WPS Auditors 来担任；后期开放社区注册，为了保证仲裁有效且公正，仲裁员竞选者需要经过社区的投票，满足条件才有资格当选。注册时最低抵押金为 100000 BOS。
348 |
349 | 转账抵押注册仲裁员：
350 | ```
351 | cleos transfer ${arbitrator_account} ${contract_oracle} "100000.0000 BOS" "${num},${arbitrat_type}" -p ${arbitrator_account}
352 | ```
353 | 例如：
354 | ```
355 | cleos transfer ${arbitrator_account} ${contract_oracle} "100000.0000 BOS" "4,1" -p ${arbitrator_account}
356 | ```
357 |
358 | **转账抵押 memo 说明：**
359 | - `${arbitrator_account}`：仲裁员账户
360 | - `num`：转账抵押类型，4为注册
361 | - `arbitrat_type`：1为全职仲裁员，2为大众仲裁员（后期支持）
362 |
363 | ## 5.2 仲裁
364 |
365 | 如果用户或DAPP方在使用过程中，若发现服务数据有问题，可申请仲裁解决。
366 |
367 | 说明：
368 |
369 | - 如果没有接受应诉，系统会判无响应方定败诉，扣除相应的押金，若为数据提供方则扣除其抵押保证金。
370 | - 如果仲裁员没有应诉，系统会重新从剩余的仲裁员中选择适合的人数发送邀请通知。
371 | - 仲裁过程会通过转账方式发送通知给相关方的账户，Oracle Store 也会通过注册的渠道进行通知推送。
372 |
373 | 一个仲裁案件共有9中状态，用 `arbi_step` 代表，分别如下：
374 | 1. `arbi_init` 仲裁开始
375 | 2. `arbi_choosing_arbitrator` 选择仲裁员
376 | 3. `arbi_wait_for_resp_appeal` 等待应诉
377 | 4. `arbi_wait_for_accept_arbitrate_invitation` 等待仲裁员接受邀请
378 | 5. `arbi_wait_for_upload_result` 等待仲裁员上传结果
379 | 6. `arbi_wait_for_reappeal` 等待再申诉
380 | 7. `arbi_resp_appeal_timeout_end` 应诉超时
381 | 8. `arbi_reappeal_timeout_end` 再申诉超时
382 | 9. `arbi_public_end` 仲裁公布结果
383 |
384 |
385 | 可以根据 `arbitration_id` 仲裁案件 ID 查看仲裁当前的流程以及相关信息：
386 |
387 | ```
388 | cleos get table ${contract_oracle} ${arbitration_id} arbicase
389 | ```
390 |
391 | 字段解释:
392 |
393 | - `arbitration_id`：仲裁案件 ID
394 | - `arbi_step`：案件当前状态
395 | - `last_round`：案件最后进行的轮次
396 | - `final_result`: 1 为申诉者胜利，2 为应诉者胜利
397 | - `arbitrators`: 可用仲裁员列表
398 | - `chosen_arbitrators`: 当前选中仲裁员列表
399 |
400 |
401 | 比如，查看 `arbitration_id` 为4的仲裁情况：
402 |
403 | ```
404 | cleos get table ${contract_oracle} 4 arbicase
405 | ```
406 |
407 | 结果：
408 |
409 | ```
410 | {
411 | "rows": [{
412 | "arbitration_id": 4,
413 | "arbi_step": 6,
414 | "arbitration_result": 2,
415 | "last_round": 2,
416 | "final_result": 0,
417 | "answer_arbitrators": [
418 | "arbitrator12",
419 | "arbitrator14",
420 | "arbitrator35",
421 | "arbitrator23",
422 | "arbitrator15",
423 | "arbitrator42",
424 | "arbitrator22",
425 | "arbitrator13"
426 | ],
427 | "chosen_arbitrators": [
428 | "arbitrator12",
429 | "arbitrator35",
430 | "arbitrator14",
431 | "arbitrator23",
432 | "arbitrator15",
433 | "arbitrator42",
434 | "arbitrator22",
435 | "arbitrator13"
436 | ]
437 | }
438 | ],
439 | "more": false
440 | }
441 | ```
442 |
443 | ### 5.2.1 账户发起申诉
444 |
445 | 数据使用者或者数据提供方发现有人作弊，提供错误的虚假信息，都可发起申诉；申诉时首次抵押金额不得低于200 BOS，后续每轮抵押都不能少于：`200*2^(N-1), N为轮数`。
446 |
447 | 转账抵押发起申诉：
448 |
449 | ```
450 | cleos transfer ${initiator_account} ${contract_oracle} "200.0000 BOS" "3,${service_id},'evidence','info','reason','${role}'" -p ${initiator_account}
451 | ```
452 |
453 | **转账抵押memo说明：**
454 | - `initiator_account`：发起账户
455 | - `num`：转账抵押类型，**3 为申诉**
456 | - `service_id`: 想要申诉的服务 ID
457 | - `evidence`: 申诉时提交的证据，推荐为 IPFS 文件地址
458 | - `info`: 公示信息
459 | - `reason`: 申诉该服务的原因
460 | - `role`：表示发起诉讼的人的身份，1-代表数据使用者，2-代表数据提供者
461 |
462 | 申诉命令发出后，会通过 transfer 发出通知，通知给所有受诉方，任何一个账户应诉（包含通知之外的账户），案件均可以成立。
463 |
464 | ### 5.2.2 受诉账户应诉
465 |
466 | 当有人申诉时，相关人员会接收申诉通知，这时需要执行应诉命令告知对方接受申诉，这时仲裁流程正式开启；如果没有人应诉，超时后，将直接判定申诉者为胜利一方，如果是数据提供方是败诉方，会将该数据服务所有抵押金扣除，分配给申诉者。
467 |
468 | 其中应诉抵押金第一轮至少200 BOS，后续每轮抵押都不能少于：`200*2^(N-1), N为轮数`。
469 |
470 | ```
471 | cleos transfer ${accept_account} ${contract_oracle} "200.0000 BOS" "5,${arbitrat_id},'evidence'" -p ${accept_account}
472 | ```
473 |
474 | **转账抵押memo说明：**
475 | - `accept_account`：应诉者账户
476 | - `num`：转账抵押类型，**5 为应诉**
477 | - `arbitrat_id`：仲裁 ID
478 | - `evidence`：应诉时提交的证据，推荐为 IPFS 文件地址
479 |
480 | ### 5.2.3 仲裁员接受邀请
481 |
482 | 当数据提供方应诉后，会给仲裁员发送仲裁邀请，只有 `2^N+1` 个仲裁员接受邀请后，才能进入下一步：上传仲裁结果。如果有仲裁员超时接受邀请，则会重新从剩余的仲裁员中选择，直至 `2^N+1` 个仲裁员全部接受， N为轮数。
483 |
484 | 仲裁员接受邀请：
485 |
486 | ```
487 | cleos push action ${contract_oracle} acceptarbi '["${arbitrator}",${arbitrat_id}]' -p ${arbitrator}@active
488 | ```
489 |
490 | **参数说明：**
491 |
492 | - `arbitrator`：接收仲裁邀请的仲裁员账户
493 | - `arbitrat_id`：接收邀请的仲裁 ID
494 |
495 | ### 5.2.4 仲裁员上传仲裁结果
496 |
497 | 仲裁员上传仲裁结果：
498 |
499 | ```
500 | cleos push action ${contract_oracle} uploadresult '["${arbitrator}",${arbitrat_id}, ${result},'memo']' -p {arbitrator}@active
501 | ```
502 |
503 | **参数说明：**
504 |
505 | - `arbitrator`：仲裁员账户
506 | - `arbitrat_id`：仲裁 ID
507 | - `result`： 1 为申诉者胜利，2 为应诉者胜利
508 | - `memo`：备注信息，需要包含裁决过程的 IPFS 文件地址
509 |
510 | ### 5.2.5 仲裁结束
511 |
512 | 仲裁结束有两种：
513 |
514 | - 仲裁结果上传后，如果没有人再次发起申诉，72小时后，该仲裁关闭；
515 | - 在 1.0 版本中，只支持`全职仲裁员`参与，最多可进行三轮仲裁。
516 |
517 | 仲裁结束后，本次仲裁得出最终结果，相关账户得奖励/惩罚。
518 |
519 | ## 5.3 仲裁相关者可以领取仲裁案件的收益
520 |
521 | 仲裁案件结束之后，参与仲裁的相关人员可以得到奖励，因为仲裁过程中涉及到三个不同的角色，申诉者、应诉者、仲裁员，针对不同的角色收益的分配方式也不同，仲裁收益需要主动领取。
522 |
523 | - 仲裁员：激励来源于**败诉者抵押金**
524 | - 数据使用者：如果胜利，则数据提供方所有的**服务抵押金**都会被平均分配给所有的**申诉账户**，申诉抵押金会退还
525 | - 数据提供方：如果胜利，申诉抵押金会退还
526 | - 如果是数据提供方起诉其他数据提供方，胜方均分对方的**服务抵押金**
527 |
528 |
529 | 查看仲裁收益：
530 |
531 | ```
532 | cleos get table ${contract_oracle} ${account} arbiincomes
533 | ```
534 |
535 | 领取收益：
536 |
537 | ```
538 | cleos push action ${contract_oracle} claimarbi '["${account}","${receive_account}"]' -p ${account}
539 | ```
540 |
541 | **参数说明：**
542 | - `account`：在仲裁案件中有收益的账户
543 | - `receive_account`：收益的接收账户
544 |
545 | ## 5.4 解除仲裁抵押
546 |
547 | 仲裁结束后，胜诉者可以将自己抵押的 Token 解抵押，通过查表方式查看自己的抵押金额。
548 |
549 | **1. 查询该仲裁当前抵押Token数量：**
550 |
551 | ```
552 | cleos get table ${contract_oracle} ${arbitrat_id} arbistakeacc
553 | ```
554 |
555 | 参数说明：
556 |
557 | `arbitrat_id`：表示想要查询的仲裁案件 ID，若当前仲裁案件已经结束，该值为 `uint64_t(1)<<63 + arbitrat_id`
558 |
559 | **2. 解抵押：**
560 |
561 | ```
562 | cleos push action ${contract_oracle} unstakearbi '{"arbitration_id":${arbitrat_id},"account":"${account}","amount":"100.0000 BOS","memo":"unstake mount"}' -p ${account}
563 | ```
564 |
565 | **参数说明：**
566 | - `arbitrat_id`：仲裁 ID
567 | - `account`：解抵押的账户名
568 | - `amount`：解抵押的 Token 的个数，不能大于抵押的数量
569 | - `memo`：备注
570 |
571 | # 六、转账抵押memo说明汇总
572 |
573 | memo 说明：`"转账质押类型,服务 ID,……."`
574 |
575 | **1. 注册服务：**
576 | memo 说明：`"0,服务 ID"`
577 |
578 | ```
579 | cleos transfer ${provider_account} ${contract_oracle} "1000.0000 BOS" "0,${service_id}"
580 | ```
581 |
582 | **2. 申诉服务：**
583 | memo 说明：`"3,服务 ID,证据,公示信息,申诉原因,角色"`
584 |
585 | ```
586 | cleos transfer ${initiator_account} ${contract_oracle} "200.0000 BOS" "3,${service_id},'evidence','info','reason','${role}'" -p ${initiator_account}
587 | ```
588 |
589 | **3. 注册仲裁员：**
590 | memo 说明：`"4,服务 ID"`
591 |
592 | ```
593 | cleos transfer ${arbitrator_account} ${contract_oracle} "10000.0000 BOS" "4,1" -p ${arbitrator_account}
594 | ```
595 |
596 | **4. 应诉：**
597 | memo 说明：`"5,服务 ID,证据"`
598 |
599 | ```
600 | cleos transfer ${accept_account} ${contract_oracle} "200.0000 BOS" "5,${service_id},'evidence'" -p ${accept_account}
601 | ```
602 |
603 |
604 | # 七、预言机查表汇总
605 |
606 | **1. 查询所有当前服务信息**
607 | ```
608 | cleos get table ${contract_oracle} ${contract_oracle} dataservices
609 | ```
610 |
611 | **2. 查询某个服务的详细信息**
612 | ```
613 | cleos get table ${contract_oracle} ${service_id} svcprovision
614 | ```
615 |
616 | **3. 查询某个服务的所有数据显示**
617 | ```
618 | cleos get table ${contract_oracle} ${service_id} oracledata
619 | ```
620 |
621 | **4. 查询当前所有数据提供方信息**
622 | ```
623 | cleos get table ${contract_oracle} ${contract_oracle} providers
624 | ```
625 |
626 | **5. 查询当前所有仲裁人员信息**
627 | ```
628 | cleos get table ${contract_oracle} ${contract_oracle} arbitrators
629 | ```
630 |
631 | **6. 查询某个仲裁案件的流程进度**
632 | ```
633 | cleos get table ${contract_oracle} ${arbitrat_id} arbicase
634 | ```
635 |
636 | **7. 查询某个仲裁案件上传的证据**
637 | ```
638 | cleos get table ${contract_oracle} ${arbitrat_id} arbievidence
639 | ```
640 |
641 | **8. 查询某个进行中的仲裁案件抵押金信息**
642 | ```
643 | cleos get table ${contract_oracle} ${arbitrat_id} arbistakeacc
644 | ```
645 |
646 | **9. 查询某个已结束的仲裁案件抵押金信息**
647 | ```
648 | cleos get table ${contract_oracle} ${9223372036854775808+arbitrat_id} arbistakeacc
649 | ```
650 |
651 | **10. 查看仲裁收益表**
652 | ```
653 | cleos get table ${contract_oracle} ${account} arbiincomes
654 | ```
655 |
--------------------------------------------------------------------------------
/Oracle/BOS_Oracle_部署文档.md:
--------------------------------------------------------------------------------
1 | BOS Oracle 部署文档
2 | ----------
3 |
4 | # 1. 多签创建预言机相关账户
5 |
6 | ## 1.1. 导出创建账户的基础信息
7 | `oracle.bos.json`
8 | ```
9 | ["eosio", "oracle.bos", {
10 | "threshold": 1,
11 | "keys": [],
12 | "accounts": [{
13 | "permission": {
14 | "actor": "eosio",
15 | "permission": "active"
16 | },
17 | "weight": 1
18 | }
19 | ],
20 | "waits": []
21 | }, {
22 | "threshold": 1,
23 | "keys": [],
24 | "accounts": [{
25 | "permission": {
26 | "actor": "eosio",
27 | "permission": "active"
28 | },
29 | "weight": 1
30 | },{
31 | "permission": {
32 | "actor": "oracle.bos",
33 | "permission": "eosio.code"
34 | },
35 | "weight": 1
36 | }
37 | ],
38 | "waits": []
39 | }]
40 | ```
41 |
42 | ## 1.2. 生成newaccount交易
43 |
44 | ```
45 | cleos push action eosio newaccount ./oracle.bos.json -sdj -p eosio > oracle.trx
46 | ```
47 | ## 1.3. 生成buyram的交易
48 |
49 | ```
50 | cleos system buyram -k eosio oracle.bos 3000 -sdj > oracle-ram.trx
51 | ```
52 | ## 1.4. 生成delegatebw的交易
53 |
54 | ```
55 | cleos system delegatebw eosio oracle.bos "2 BOS" "2 BOS" -sdj > oracle-delegate.trx
56 | ```
57 | ## 1.5. 合并action到neworacle.json，发起提案
58 |
59 | ```
60 | cleos multisig propose_trx createtest bppermission.json neworacle.json bostesterter
61 | ```
62 | neworacle.json：
63 | ```
64 | {
65 | "expiration": "2019-04-27T01:43:42",
66 | "ref_block_num": 33447,
67 | "ref_block_prefix": 2283537730,
68 | "max_net_usage_words": 0,
69 | "max_cpu_usage_ms": 0,
70 | "delay_sec": 0,
71 | "context_free_actions": [],
72 | "actions": [{
73 | "account": "eosio",
74 | "name": "newaccount",
75 | "authorization": [{
76 | "actor": "eosio",
77 | "permission": "active"
78 | }
79 | ],
80 | "data": "0000000000ea3055000000bdf79eb1ca0100000000010000000000ea305500000000a8ed32320100000100000000010000000000ea305500000000a8ed3232010000"
81 | },{
82 | "account": "eosio",
83 | "name": "buyrambytes",
84 | "authorization": [{
85 | "actor": "eosio",
86 | "permission": "active"
87 | }
88 | ],
89 | "data": "0000000000ea3055000000bdf79eb1ca00240000"
90 | },{
91 | "account": "eosio",
92 | "name": "delegatebw",
93 | "authorization": [{
94 | "actor": "eosio",
95 | "permission": "active"
96 | }
97 | ],
98 | "data": "0000000000ea3055000000bdf79eb1ca102700000000000004424f5300000000102700000000000004424f530000000000"
99 | }
100 | ],
101 | "transaction_extensions": [],
102 | "signatures": [],
103 | "context_free_data": []
104 | }
105 | ```
106 |
107 |
108 | # 2. 部署合约
109 | ## 2.1 生成 `set contract` 交易
110 | ```
111 | cleos set contract oracle.bos bos.oracle/ -p oracle.bos -s -j -d > setcontract.json
112 | ```
113 | ## 2.2 发起提案
114 | ```
115 | cleos multisig propose_trx setcontract bppermission.json setcontract.json -p bostesterter
116 | ```
117 | ## 2.3 `approve` 多签
118 | ```
119 | cleos multisig approve bostesterter updatasystem '{"actor":"${BP_NAME}","permission":"active"}' -p ${BP_NAME}
120 | ```
121 | ## 2.4 `exec` 执行
122 | ```
123 | cleos multisig exec bostesterter setcontract -p bostesterter@active
124 | ```
125 | ## 2.5 初始化 Oracle
126 | ```
127 | cleos push action ${contract_oracle} setparameter '{"version":1,"parameters":{"core_symbol":"BOS","precision":4,"min_service_stake_limit":1000,"min_appeal_stake_limit":200,"min_reg_arbitrator_stake_limit":10000,"arbitration_correct_rate":60,"round_limit":3,"arbi_timeout_value":86400,"arbi_freeze_stake_duration":259200,"time_deadline":86400,"clear_data_time_length":10800,"max_data_size":256,"min_provider_limit":1,"max_provider_limit":100,"min_update_cycle":1,"max_update_cycle":8640000,"min_duration":1,"max_duration":8640000,"min_acceptance":1,"max_acceptance":100}}' -p ${contract_oracle} -s -j -d > setconfig.json
128 |
129 | cleos multisig propose_trx setconfig bppermission.json setconfig.json -p ${account}
130 |
131 | cleos multisig approve ${account} setconfig '{"actor":"${account}","permission":"active"}' -p ${account}
132 |
133 | cleos multisig exec ${account} setconfig -p ${account}
134 | ```
135 |
136 | _注：具体参数含义参看：[预言机全局参数配置](./BOS_Oracle_入门.md#27-预言机全局参数配置)
137 |
138 |
139 | # 3. 导入仲裁员
140 | ## 3.1 生成 `importwps` 交易
141 | ```
142 | cleos push action oracle.bos importwps '[["arbitrator11","arbitrator12","arbitrator13","arbitrator14","arbitrator15","arbitrator21","arbitrator22","arbitrator23","arbitrator24","arbitrator25", "arbitrator31", "arbitrator32","arbitrator33", "arbitrator34", "arbitrator35", "arbitrator41", "arbitrator42", "arbitrator43", "arbitrator44", "arbitrator45"]]' -p oracle.bos -s -j -d > importwps.json
143 | ```
144 | ## 3.2 发起提案
145 | ```
146 | cleos multisig propose_trx insertwps bppermission.json importwps.json -p bostesterter
147 | ```
148 | ## 3.3 `approve` 并 `exec` 多签
149 | ```
150 | cleos multisig approve bostesterter insertwps '{"actor":"bostesterter","permission":"active"}' -p bostesterter
151 | cleos multisig exec bostesterter insertwps -p bostesterter@active
152 | ```
153 | ##
154 |
--------------------------------------------------------------------------------
/Oracle/README.md:
--------------------------------------------------------------------------------
1 | BOS.Oracle: Witness and Changes
2 | ----------
3 |
4 | BOS Oracle does not relying on each oracle provider's 100% credibility of the data they provided.
5 | BOS Oracle treat each oracle provider as a participant in the game, in order to achieve overall credibility in the game.
6 |
7 |
8 | ## 2.1 System Components
9 |
10 | 
11 |
12 |
13 | ## Game Model
14 |
15 | 
16 |
17 |
18 | ## Reference
19 |
20 | ### English
21 |
22 | - [BOS Oracle Overview](https://github.com/boscore/bos.contracts/tree/master/contracts/bos.oracle/README.md)
23 | - [BOS Oracle Introduction](./BOS_Oracle_Introduction.md)
24 | - [BOS Oracle Deployment](./BOS_Oracle_Deployment.md)
25 |
26 |
27 | ### 中文
28 |
29 | - [BOS Oracle 概览](https://github.com/boscore/bos.contracts/tree/master/contracts/bos.oracle/README_CN.md)
30 | - [BOS Oracle 入门](./BOS_Oracle_入门.md)
31 | - [BOS Oracle 部署文档](./BOS_Oracle_部署文档.md)
32 |
33 |
34 | ## Code
35 | [BOS Oracle Smart Contract](https://github.com/boscore/bos.contracts/tree/master/contracts/bos.oracle)
36 |
37 |
38 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | BOSCore
2 | ------
3 |
4 | ### BOSCore Technical White Paper
5 | * [English](BOSCoreTechnicalWhitePaper.md)
6 | * [中文](BOSCoreTechnicalWhitePaper_zh.md)
7 |
8 | ### BET docs
9 | * [BET DPOS Borda Count Voting Plan](BET/BET_DPOS_Borda_Count_Voting_Plan.md)
10 | * [BET DPOS波达计数法投票方案](BET/BET_DPOS波达计数法投票方案.md)
11 |
12 | ### IBC docs
13 | * [IBC Principles_and_Design](IBC/EOSIO_IBC_Priciple_and_Design.md)
14 | * [IBC原理及设计](IBC/EOSIO_IBC_Priciple_and_Design_zh.md)
15 | For more documentations, please refer to [docs](https://github.com/boscore/ibc_contracts/tree/master/docs)
16 |
17 | ### BOS Batch-PBFT / LIB Acceleration Solution docs
18 | * [Algorithm for improving EOSIO consensus speed based on Batch-PBFT](LIB/Algorithm_for_improving_EOSIO_consensus_speed_based_on_Batch-PBFT.md)
19 | * [BOS LIB Acceleration Solution: Batch PBFT](LIB/BOS_Batch_PBFT_I.md)
20 | * [BOS Batch-PBFT Upgrade Solution](LIB/BOS_Batch_PBFT_II.md)
21 | * [基于PBFT提升EOSIO共识速度的算法](LIB/基于PBFT提升EOSIO共识速度的算法.md)
22 |
23 | ### Referendum / WPS Contents
24 | * [BOS Ecosystem Program(Referendum & WPS)](Referendum_WPS/BOS%20Ecosystem%20Program(Referendum%20%26%20WPS).md)
25 | * [BOS生态基金方案(含公投&WPS)](Referendum_WPS/BOS%E7%94%9F%E6%80%81%E5%9F%BA%E9%87%91%E6%96%B9%E6%A1%88(%E5%90%AB%E5%85%AC%E6%8A%95%26WPS).md)
26 |
27 | ### BOS Oracle
28 |
29 | * [BOS Oracle Overview](https://github.com/boscore/bos.contracts/blob/master/contracts/bos.oracle/README.md)
30 | * [BOS Oracle 概览](https://github.com/boscore/bos.contracts/blob/master/contracts/bos.oracle/README_CN.md)
31 | * [BOS Oracle Introduction](Oracle/BOS_Oracle_Introduction.md)
32 | * [BOS Oracle 入门](Oracle/BOS_Oracle_入门.md)
33 | * [BOS Oracle Deployment](Oracle/BOS_Oracle_Deployment.md)
34 | * [BOS Oracle 部署文档](Oracle/BOS_Oracle_部署文档.md)
35 | * [Code](https://github.com/boscore/bos.contracts/tree/master/contracts/bos.oracle)
36 |
37 |
--------------------------------------------------------------------------------
/Referendum_WPS/BOS Ecosystem Program(Referendum & WPS).md:
--------------------------------------------------------------------------------
1 | # Executive Summary
2 |
3 | BOSCore is pleased to announce a BOS development incentive program with the goal of releasing 100 million BOS into the EOSIO ecosystem. The program involves a process of checks and balances that begins with a community referendum, by which the community chooses suitable proposals for funding support. If approved proposals can proceed to development and subsequent BOS Core Executive team review, auditing and funding. Other EOSIO ecosystem contributors can also apply for fund support, so that multi-chain, interoperability can realise aligned ecosystem incentives, enabling communities to prosper together.
4 |
5 | # 1. Background
6 |
7 | This proposal is a BOS development incentive program proposed by the founding core teams of BOS. The goal is to continue to support the development of core protocol and the expansion of the entire EOSIO ecosystem.
8 |
9 | BOSCore will set up an environmental fund of 100 million BOS for infrastructure construction, protocol standard setting, code optimization, and ecological partner incentives, etc. Other EOSIO eco-contributors can also apply for fund support, and multi-chain can achieve greater prosperity together.
10 |
11 | After this proposal is approved, BOSCore will deposit 100 million BOS into a designated account, which will be managed by BPs and used according to community referendum.
12 |
13 | # 2. BOS Executive Team
14 |
15 | Founded by several senior members of the EOSIO community, each member is veteran in the blockchain industry, involving wallets, mining pools, exchanges, and many other companies. The members have extensive experience in the field of Bitcoin, Ethereum and EOS. Each member is committed to blockchain technology, improving human productivity and freedom.
16 |
17 | # 3. Program Goals
18 | * Attracting and incentivizing developers or teams
19 | * Letting more communities get involved
20 | * Accelerating the evolution of EOSIO technology
21 | * Prospering the EOSIO Ecosystem
22 |
23 | # 4. Main Missions
24 |
25 | The program is mainly to provide resources for the following work:
26 | * Core code development
27 | * EOSIO Ecosystem Application Tool
28 | * EOSIO's community development and motivation
29 | The program establishes the next form of community-driven collaboration for BOS. These funds will be used to advance the support and incentives required for the development of BOS and other EOSIO infrastructure projects.
30 |
31 | # 5. Proposal method and fund payment
32 | All BOS community participants can submit proposals while staking 100 BOS to submit a proposal to the referendum contract.
33 |
34 | ### The proposal needs to include:
35 | * The name of the task
36 | * Features of the task
37 | * The deadline of task completion will start from the date the referendum is approved (relative to the referendum approved time)
38 | * The amount of the incentives, and receipt account (the account can be changed later)
39 |
40 | ### The conditions for the approved proposal:
41 | * The votes from token holders is not less than 40% of BP votes from token holders when the proposal was initiated.
42 | * The ratio of approved votes/disapproved is greater than 1.5.
43 | * The above conditions last for 20 days.
44 |
45 | ### BOS Auditor:
46 | * Stake 100,000 BOS
47 | * Have an understanding of the major public chain consensus mechanisms
48 | * You must make your BOS account name publicly available and other valid contacts, create your own homepage or social accounts. (Do not disclose personal sensitive information)
49 | * If cheating occurs, the qualification will be immediately submitted for cancellation by BPs. The staked BOS will be transferred to Foundation account and will be returned back after one year locking.
50 | * Votes are counted at the end of each quarter, the top 5 are elected, and up to 20 auditors.
51 | * The auditor has a one-year term and will need re-election after the expiration.
52 |
53 | ### Conditions for being an auditor:
54 | * The votes from token holders is not less than 3% of BP votes from token holders when the proposal was initiated
55 | * The ratio of approved votes/disapproved is greater than 1.5
56 | * The above conditions last for 20 days.
57 |
58 | # 6. Fund payment process points:
59 | 1. The community chooses suitable proposals for fund support by referendum.
60 | 2. The amount of a single proposal incentives cannot exceed 1 Million BOS. Generally, after the deadline expires, the proposal incentives are automatically paid.
61 | 3. 10 days before the deadline, if the BOS Executive Team believes that the task has not been effectively executed, it has the right to temporarily freeze the payment of funds and submit the payment proposal to BP vote. BOSCore Executive Team checkpoints:
62 | * estcase coverage, whether the test passed?
63 | * Whether the coding quality is up to standard?
64 | * Whether the specified functions in the proposal are fully implemented?
65 | * Is there a security bug?
66 | 4. If the fund payment is frozen, the BOS independent auditor needs to publish the review within 7 days, make independent judgment in the contract, and issue a link to the relevant investigation report.
67 | 5. Within two weeks after the auditor’s comments, BP needs to make a decision. If more than 2/3+1 active BPs agree to continue to pay the incentives, it will continue to pay 90% of the incentives; Otherwise the payment will be rejected.
68 | 6. The 10% of the incentives for the proposal are equally divided between the auditors who agree with the majority of the BPs and the BPs who voted.
69 |
70 | 
71 |
72 |
73 | Any questions or enquiries you have, please feel free to contact us:
74 |
75 | Email: support@boscore.io
76 | Telegram group: https://t.me/boscorecommunity
77 | Twitter: https://twitter.com/Boscore_BOS
78 | Facebook: https://www.facebook.com/BOSCoreOfficial
79 |
--------------------------------------------------------------------------------
/Referendum_WPS/BOS生态基金方案(含公投&WPS).md:
--------------------------------------------------------------------------------
1 | ## 1. 背景
2 | BOS创始团队将会设立合计1亿BOS的生态基金用于BOS开发激励方案。
3 | 1亿BOS将会存入指定账户,按照社区公投方式来使用该笔资金。
4 | BOS的基础设施搭建者、协议标准制定者、代码优化者、生态建设者、和其他EOSIO生态的贡献者都可以申请BOS生态基金。
5 | ## 2. BOS项目团队(BET, BOSCore Executive Team)
6 | 由EOSIO社区多个资深成员成立，每个成员都是区块链行业的早期创业者，涉及了钱包、矿池、交易所等诸多业态。基金成员经历过从价值承载的比特币，运行智能合约的以太坊，再到企业级应用的EOS，每个成员都致力于区块链技术落地，提高人类生产力以及自由的事业。
7 | ## 3. 方案目标
8 | * 吸引有优秀开发者或者团队
9 | * 让更多的社区力量参与进来
10 | * 加速EOSIO技术的不断进化
11 | * 繁荣EOSIO生态
12 | ## 4. 主要任务
13 | 生态基金主要在为以下工作提供资源：
14 | * 核心代码的研发工作
15 | * EOSIO生态类应用工具
16 | * EOSIO的社区发展与激励
17 |
18 | 本方案用于建立BOS下一步的社区化合作的形式。这些资金会用于推进BOS以及其他EOSIO基础项目发展所需要的支持和激励方面。
19 | ## 5、提案与公审要点
20 | BOS社区参与者均可以提出议案，参与者需要抵押100 BOS向公投合约提出提案。
21 | 提案需要包括：
22 | * 任务的名称
23 | * 任务的功能点
24 | * 任务的最晚完成提交时间，公投通过以后起算
25 | * 提案所需金额及收款账户，收款账户后续可改
26 |
27 | 提案通过的条件：
28 | 1. 参与投票数量不少于提案发起时参与BP投票数量的 40%
29 | 2. 支持票/反对票的比率大于 1.5
30 | 3. 以上条件持续 20 天成立
31 |
32 | BOS评审员
33 | * 抵押10万BOS
34 | * 对各大公链共识机制有了解
35 | * 公开自己的BOS账户，以及其他有效联系方式，建立自己的主页或社交账户地址(不用透露个人敏感信息)
36 | * 如有作弊发生，资格立即被BP多签取消，并将抵押转入到基金账户，锁仓一年后归还
37 | * 每季度末统计一次投票，前5名当选，最多20名评审员
38 | * 评审员任期一年，期满需再次发起投票
39 |
40 | 成为评审员的条件：
41 | 1. 参与投票数量不少于提案发起时参与BP投票数量的 3%
42 | 2. 支持票/反对票的比率大于 1.5
43 | 3. 以上条件持续 20 天成立
44 | ## 6、方案流程要点：
45 | 1. 社区以公投方式选出合适的提案来进行基金支持
46 | 2. 单笔提案激励额度不得大于100万BOS；正常情况下截止时间到期后，提案奖金自动支付
47 | 3. 最晚交付日前10天，若 BET 认为该任务未被有效执行，则有权暂时冻结资金支付，并将该支付的议案提交至节点表决。BET 检查点：
48 | * Testcase覆盖程度，测试是否通过
49 | * 编码质量是否达标
50 | * 提案规定的功能是否实现
51 | * 是否存在安全漏洞
52 | 4. 若资金支付被冻结，BOS独立评审员需要在7天内发表审查意见，并在合约中做出独立判断，并发布判断的相关调查报告的链接。
53 | 5. 评审员发布意见以后2周内，BP可以参考评审员的决定，若超过2/3加1的出块节点同意继续支付提案激励，则继续支付90%的提案激励，反之则否决支付。
54 | 6. 提案激励的10% 平分给和多数节点做出一致结论的评审员 和 参与表决的BP。
55 |
56 | 
57 |
--------------------------------------------------------------------------------
/imgs/BOS_Referendum.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/BOS_Referendum.png
--------------------------------------------------------------------------------
/imgs/BOS_Referendum_CN.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/BOS_Referendum_CN.png
--------------------------------------------------------------------------------
/imgs/bospbft.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/bospbft.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math01.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math01.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math02.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math02.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math03.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math03.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math04.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math04.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math05.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math05.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math06.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math06.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math07.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math07.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math08.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math08.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math09.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math09.png
--------------------------------------------------------------------------------
/imgs/dops_borad_count_math10.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/dops_borad_count_math10.png
--------------------------------------------------------------------------------
/imgs/flow_cn.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/flow_cn.png
--------------------------------------------------------------------------------
/imgs/flow_en.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/flow_en.png
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_df_listen_offchain.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_df_listen_offchain.png
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_df_listen_table.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_df_listen_table.jpg
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_df_offchain1.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_df_offchain1.jpg
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_df_offchain2.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_df_offchain2.jpg
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_df_offchain_detail.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_df_offchain_detail.png
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_df_table.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_df_table.jpg
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_game_model.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_game_model.png
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_risk_control.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_risk_control.png
--------------------------------------------------------------------------------
/imgs/oralce/bosoracle_structure.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/oralce/bosoracle_structure.png
--------------------------------------------------------------------------------
/imgs/scale/blockstructure.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/scale/blockstructure.png
--------------------------------------------------------------------------------
/imgs/scale/networktopology.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/scale/networktopology.png
--------------------------------------------------------------------------------
/imgs/scale/productverify.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/boscore/Documentation/dec7f76a8b31efee141037c98beeee2ee16d9a36/imgs/scale/productverify.png
--------------------------------------------------------------------------------