Voting requires bandwidth, and so we would like to reduce the amount of voting. To do this, want nodes to vote only on transactions satisfying certain criterion. However, if the criterion is subjective (e.g. time based), not all nodes will agree about which transactions need voting on. See here and here. If only a subset of nodes vote on a transaction, we have a problem, because they are more vulnerable to attack. We show how we can solve this problem.
An opinion is a pair (b,\ell) where b\in\{0,1\} is a Boolean value and \ell\in\{1,2,3\} is the level of knowledge:
- \ell=1 means you believe b,
- \ell=2 means you know everyone also believes b,
- \ell=3 means you know that everyone knows that every believes b.
FPC contains a passive voting option, which allows nodes to choose their level of participation :
- \ell=1 means full (or normal) participation: makes and responds to querries
- \ell=2 means that the node only responds to querries about the transaction, but does not querry nor change its opinion,
- \ell=3 no participation: FPC will not affect the opinion of this transaction.
How does this help us? This allows us to not vote on transactions which are obviously bad.
- Here is an example. Consider the FCoB rule, where we like a transaction if we have not detected a conflict with c time after the arrival. Letting t_a be the arrival time of the transaction in question, and D an upper bound on the network delay, we set:
- Dislike a transaction with level 3 if you detect a conflict in the interval (-\infty ,t_a+c-2D]
- Dislike a transaction with level 2 if you detect a conflict in the interval (t_a+c-2D,t_a+c-D]
- Dislike a transaction with level 1 if you detect a conflict in the interval (t_a+c-D,t_a+c]
- Like a transaction with level 1 if you do not detect a conflict in the interval (t_a+c,t_a+c+D]
- Like a transaction with level 2 if you do not detect a conflict in the interval (t_a+c+D,t_a+c+2D]
- Like a transaction with level 3 if you do not detect a conflict in the interval (t_a+c+2D,\infty)
We make one more remark. Opinions are totally ordered in the following manner
(0,3)<(0,2)<(0,1)<(1,1)<(1,2)<(1,3)
and thus opinion has a join (aka an ``and’’) operation which take the minimum of two elements. This join operation allows us to vote on multiple transactions at once. Indeed, we can have several different questions, and store the opinion of a transaction. Then we can take the total opinion, as the join, or minimum of all the opinions on the various questions.
Similarly, when we vote on a transaction, we can vote on its entire history by considering the least of the total opinion on every transaction in its history.