certusone
/
dc4bc
mirror of https://github.com/certusone/dc4bc.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Updated readme

This commit is contained in:
Andrej Zavgorodnij 2020-10-15 18:12:54 +03:00
parent 1935cb0ffd
commit 1963f92a89
2 changed files with 23 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
README.md
View File

@ -106,3 +106,26 @@ If at any point something goes wrong (timeout reached, the deal is invalid, publ
If not enough participants signal their willingness to sign within a timeout or signal their rejection to sign, signature process is aborted.
We organize logic in the hot node as a set of simple state machines that change state only by external trigger, such as CLI command, message from cold node, or a new message on Bulletin Board. That way it can be easily tested and audited.
# Finite-state machines description
We moved away from the idea of one large state machine that would perform all tasks, so we divided the functionality into three separate state machines:
* SignatureProposalFSM - responsible for collecting agreements to participate in a specific DKG round
* DKGProposalFSM - responsible for collecting a neccessary data (pubkeys, commits, deals, responses and reconstructed pubkeys) for a DKG process
* SigningProposalFSM - responsible for signature process (collecting agreements to sign a message, collecting partial signs and reconstructed full signature)
We implemented a FSMPoolProvider containing all three state machines that we can switch between each other by hand calling necessary events.
For example, when SignatureProposalFSM collected all agreements from every participant it's state becomes *state_sig_proposal_collected*.
That means it's time to start a new DKG round to create shared public key. We can do it by sending *event_dkg_init_process* event to the FSM.
# Visual representation of FSMs
### SignatureProposalFSM
![SignatureProposalFSM](images/sigFSM.png)
### DKGProposalFSM
![DKGProposalFSM](images/dkgFSM.png)
### SigningProposalFSM
![SigningProposalFSM](images/signingFSM.png)

21
fsm-states.md
View File

@ -1,21 +0,0 @@
# Finite-state machines description
We moved away from the idea of one large state machine that would perform all tasks, so we divided the functionality into three separate state machines:
* SignatureProposalFSM - responsible for collecting agreements to participate in a specific DKG round
* DKGProposalFSM - responsible for collecting a neccessary data (pubkeys, commits, deals, responses and reconstructed pubkeys) for a DKG process
* SigningProposalFSM - responsible for signature process (collecting agreements to sign a message, collecting partial signs and reconstructed full signature)
We implemented a FSMPoolProvider containing all three state machines that we can switch between each other by hand calling necessary events.
For example, when SignatureProposalFSM collected all agreements from every participant it's state becomes *state_sig_proposal_collected*.
That means it's time to start a new DKG round to create shared public key. We can do it by sending *event_dkg_init_process* event to the FSM.
## Visual representation of FSMs
### SignatureProposalFSM
![SignatureProposalFSM](images/sigFSM.png)
### DKGProposalFSM
![DKGProposalFSM](images/dkgFSM.png)
### SigningProposalFSM
![SigningProposalFSM](images/signingFSM.png)