Use the BDT protocol to ensure the interconnection between CYFS users, even users under NAT, and protect privacy through protocol encryption.
Provide a basic consensus framework to ensure that all proposals are received, executed and verified in a unified order.The DECApp developers only need to define the implementation and verification methods of proposals according to their needs,it's a Smart Contract.
For the ending user,They only need to complete the operation following the guidance of DECApp:
Initialize the Group.
Create the proposal.
Submit the proposal.
Check and sign the proposal as a vote.
The decide will be formed automatically by DECApp.
The follow sequence diagram will show a common flow for a proposal.
%% 时序图例子,-> 直线，-->虚线，->>实线箭头
sequenceDiagram
participant User
participant CYFS
participant DECApp
User->>CYFS: post(proposal)
CYFS->>DECApp: on_execute(proposal,last_result)
DECApp->>DECApp: result=execute(proposal,last_result)
DECApp-->>CYFS: result
CYFS->>CYFS: broadcast(proposal,result) to other members
CYFS->>DECApp: on_verify(proposal,last_result)
DECApp->>DECApp: is_ok=verify(proposal,last_result)
DECApp-->>CYFS: is_ok
CYFS-->>User: finish(result,is_ok)
A vote on a proposal is a proposal that depends on the original proposal,and its execution process is exactly the same as the general proposal.
A proposal that requires voting, from the original proposal to the formation of the final resolution, the implementation process is as follows.
%% 时序图例子,-> 直线，-->虚线，->>实线箭头
sequenceDiagram
participant User
participant CYFS
participant DECApp
User-->>DECApp: post(proposal)
DECApp->>DECApp: result_proposal_list=add(proposal,last_proposal_list)
DECApp-->>CYFS: result_proposal_list
User->>CYFS: proposal_list = get_voting_proposals()
CYFS-->>User: proposal_list
User->>User: vote=make_vote(proposal_list.select(),voter=self)
User-->>DECApp: post(vote)
DECApp->>DECApp: all_votes=collect_votes(vote)
DECApp->>DECApp: is_enough=check(all_votes)
DECApp->>DECApp: if is_enough {result=decide()}
DECApp->>DECApp: if !is_enough {result=add(vote,last_vote_list)}
DECApp-->>CYFS: result
We can find that the working mode for users and developers hasn't changed substantially against Web2, there are only some differences in form:
In the Web2 era, the database is directly updated when the proposal is executed after the user has been authenticated.
In CYFS, there is an additional verification stage before the proposal execution results take effect. Usually, each node executes it once to compare whether the respective calculation results are the same.
And, all cyfs:// protocols will support the Group as a Zone,the same interface will be provided as People,so,it will work in the same way for People zone.
Cheaply
The entire process is almost completed locally by the Group members, and no additional on-chain fees are required.
Hotstuff
I will introduce Hotstuff briefly. Please refer to the professional literature if you want to learn more about it.
Fault tolerance
Hotstuff is a type of BFT consensus algorithm:
Assume that the number of malicious nodes is f;
The total number of all nodes is N.
To reach a correct consensus:
The total number of votes is v;
The number of votes for normal nodes is n, in the worst case, all malicious nodes also participated in the vote, n > f;
The number of unvoted nodes is N - v, n > N - v;
$$
\begin{cases}
\ v >= n + f; => min(v) = n + f => min(v) = min(n) + f \
\ n > f; => min(n) = f + 1 \
\ n > N - v; => max(N) = n + v - 1 \
\end{cases}
=>
\begin{cases}
\ min(v) >= 2f + 1; \
\ n + v > N; => min(n) + min(v) > N \
\end{cases}
=> N < f + 1 + 2f + 1 = 3f + 2; \
=> N <= 3f + 1
$$
From the above calculations, we can prevent malicious nodes accounting for up to 1/3(excluding) of the total when we collect signatures from more than 2/3(excluding) nodes.
Consensus process
PBFT
PBFT is the first available BFT algorithm, and its basic process is:
Sort all nodes in a certain order;
Select one node in order as the master node, responsible for sorting, executing, packaging, blocking for all proposals;
The master node broadcasts the packaged block to other nodes;
All nodes verify the information described in the block they received, sign the vote, and broadcast the vote to all other nodes again;
Each node conducts 2nd signature votes when 2f+1 signatures are collected, and broadcasts the vote to all other nodes again;
Each node update the local result and return it to the client when 2f+1 2nd signatures are collected;
The client confirms that the request is processed correctly after 2f+1 2nd signatures are collected.
Here, it is required to collect 2f+1 signatures twice, because each node must ensure that 2f+1 nodes have received votes, so that they can recover in the event of a failure.
View change:
There should be a mechanism to change the master when the master node does evil or fails, otherwise the activity of the system cannot be guaranteed.
The current running state of all nodes is a view, and the process of changing the master node is view change:
A node finds that the master node is faulty, selects the next node as the new master node, and initiates a view change request;
Other nodes sign the vote if they also agree to view change, and attach the block vote with the highest signature height of 2f+1; then broadcast to other nodes;
Same as the previous consensus process, all nodes arrive a same state on view change again;
Each node synchronizes the local chain to the highest level according to the voting information attached to the voting during the consensus process.
Hotstuff
Hotstuff optimizes PBFT in several pionts:
Pipelining: the vote for each block is also the confirmation of the next state of the previous block, and the whole process only has two broadcasts per block on average (2*n, block broadcast and voting);
Simplify the state machine: the view change process is subtly integrated into the block consensus process, and the view change process only changes the node responsible for collecting votes for the next block;
Proposal and consensus achievement process
From the previous introduction to the scenario of
Shared Property Rights, it is not difficult to see that the key issues is:Consortium Blockchainsimply and cheaply?Define standard
Objects forCYFSusers to ensure they representing in the same way.GroupGroupProposalGroupConsensusBlockUse the
BDTprotocol to ensure the interconnection betweenCYFSusers, even users under NAT, and protect privacy through protocol encryption.Provide a basic consensus framework to ensure that all proposals are received, executed and verified in a unified order.The
DECAppdevelopers only need to define the implementation and verification methods of proposals according to their needs,it's aSmart Contract.For the ending user,They only need to complete the operation following the guidance of
DECApp:Group.proposal.proposal.proposalas a vote.DECApp.The follow sequence diagram will show a common flow for a proposal.
A vote on a proposal is a proposal that depends on the original proposal,and its execution process is exactly the same as the general proposal.
A proposal that requires voting, from the original proposal to the formation of the final resolution, the implementation process is as follows.
We can find that the working mode for users and developers hasn't changed substantially against
Web2, there are only some differences in form:Web2era, the database is directly updated when the proposal is executed after the user has been authenticated.CYFS, there is an additional verification stage before the proposal execution results take effect. Usually, each node executes it once to compare whether the respective calculation results are the same.And, all
cyfs://protocols will support theGroupas aZone,the same interface will be provided asPeople,so,it will work in the same way forPeoplezone.HotstuffI will introduce
Hotstuffbriefly. Please refer to the professional literature if you want to learn more about it.Fault tolerance
Hotstuffis a type ofBFTconsensus algorithm:f;N.v;n, in the worst case, all malicious nodes also participated in the vote,n > f;N - v,n > N - v;$$ \begin{cases} \ v >= n + f; => min(v) = n + f => min(v) = min(n) + f \ \ n > f; => min(n) = f + 1 \ \ n > N - v; => max(N) = n + v - 1 \ \end{cases}
=>
\begin{cases} \ min(v) >= 2f + 1; \ \ n + v > N; => min(n) + min(v) > N \ \end{cases}
=> N < f + 1 + 2f + 1 = 3f + 2; \ => N <= 3f + 1
$$
From the above calculations, we can prevent malicious nodes accounting for up to 1/3(excluding) of the total when we collect signatures from more than 2/3(excluding) nodes.
Consensus process
PBFTPBFTis the first availableBFTalgorithm, and its basic process is:sorting,executing,packaging,blockingfor all proposals;2f+1signatures are collected, and broadcasts the vote to all other nodes again;2f+12nd signatures are collected;2f+12nd signatures are collected.Here, it is required to collect
2f+1signatures twice, because each node must ensure that2f+1nodes have received votes, so that they can recover in the event of a failure.View change:
There should be a mechanism to change the master when the master node does evil or fails, otherwise the activity of the system cannot be guaranteed.
The current running state of all nodes is a
view, and the process of changing the master node isview change:view changerequest;view change, and attach the block vote with the highest signature height of2f+1; then broadcast to other nodes;view changeagain;HotstuffHotstuffoptimizesPBFTin several pionts:Pipelining: the vote for each block is also the confirmation of the next state of the previous block, and the whole process only has two broadcasts per block on average (2*n, block broadcast and voting);
Simplify the state machine: the view change process is subtly integrated into the block consensus process, and the view change process only changes the node responsible for collecting votes for the next block;