These genius are doing great works on libraries for ensuring more proofs for dBFT, @igormcoelho and @vang1ong7ang, respectivelly: https://github.com/NeoResearch/libbft & https://github.com/NeoResearch/libsm
In addition, during these last days good designs were done together and a beautiful state machine graph is emerging!
Stay tuned. aheuahuea

graphviz-dbft-v3-cancel-phase.pdf
Currently, the discussion surrounding the version number emerged, if it should be a major version or a minor version.
Perhaps, it is a Major Version because of the following features (under update):
SystemFee;CN as an Active one.@vncoelho I'm very interested in your dBFT 3.0 design. Do you have any doc about the specific descrption of dbft 3.0, it is difficult for me to understand just by looking at this UML diagram, haha.
Hi @eryeer,
In fact, that is true, the UML is not easy to understand. We talked about this during @vang1ong7ang journey here in Brazil.
Furthermore, he was the one that was engaged in designing this UML. In this sense, perhaps you can also talk directly to him.
For now, we are still working on the mathematical proofs of dBFT 2.0 and libraries for testing the design of dBFT 3.0.
We prefer to keep description simple for now for avoiding confusion.
Let's stay tuned, we believe that this month of January will be good for working on that.
@eryeer @erikzhang @shargon @wanglongfei88 please find attached pre-release report on dBFT 3.0 studies. We tried to keep it short, but it already takes some pages... so feel free to start from last page (Highlights), which is just a single page, and then get complete report. It's not completed yet, but it already aggregates several interesting community discussions from past few months/years.
Report on dBFT 3.0 - Pre-Release 2019-01-19
Report on dBFT 3.0 - Pre-Release 2019-01-20 [UPDATE]
[Report on dBFT 3.0 - Pre-Release 2019-01-22](https://github.com/NeoResearch/dbft3-spork-detect/blob/v0.5/docs/dBFT3_0-Report-NeoResearch-prerelease-19-01-22.pdf) [UPDATE]
In short: we believe that multiple proposals are feasible on practice, reducing the burden of a single Primary, by allowing precise T=15secs timing every block, and participation of other "guest" nodes (possibly community nodes with high stakes locked on NEO) to earn fees. This also helps voting procedures, to already know the MainNet performance of a "hot" node (not yet voted).
We start modeling a double primary mechanism, which is not yet proposed in academic literature, to the best of our knowledge. We have many citations not yet included on text (but present on our minds), so it's likely we forgot to mention many things, sorry for that. But it's a solid start. Enjoy ;)
@vang1ong7ang @Tommo-L @eryeer @shargon @erikzhang @wanglongfei88
We were today able to find strong mathematical evidences that double proposals will not produce sporks:
Here is the current mathematical model: https://github.com/NeoResearch/milp_bft_failures_attacks/blob/master/dbft3.0/MILP_BFTConsensus_dBFT3.0_2P.mod
We considered the model with 2 Primaries, which we believe will benefit the ecosystem in different aspects.
In the next steps, during these coming weeks, we are going to try to modify the model for minimizing the number of blocks instead of maximizing. In this sense, we plan to find and improve the model in order ensure liveness in most extreme situations.
Most helpful comment
@eryeer @erikzhang @shargon @wanglongfei88 please find attached pre-release report on dBFT 3.0 studies. We tried to keep it short, but it already takes some pages... so feel free to start from last page (Highlights), which is just a single page, and then get complete report. It's not completed yet, but it already aggregates several interesting community discussions from past few months/years.
Report on dBFT 3.0 - Pre-Release 2019-01-19
Report on dBFT 3.0 - Pre-Release 2019-01-20 [UPDATE]
[Report on dBFT 3.0 - Pre-Release 2019-01-22](https://github.com/NeoResearch/dbft3-spork-detect/blob/v0.5/docs/dBFT3_0-Report-NeoResearch-prerelease-19-01-22.pdf) [UPDATE]
In short: we believe that multiple proposals are feasible on practice, reducing the burden of a single Primary, by allowing precise T=15secs timing every block, and participation of other "guest" nodes (possibly community nodes with high stakes locked on NEO) to earn fees. This also helps voting procedures, to already know the MainNet performance of a "hot" node (not yet voted).
We start modeling a double primary mechanism, which is not yet proposed in academic literature, to the best of our knowledge. We have many citations not yet included on text (but present on our minds), so it's likely we forgot to mention many things, sorry for that. But it's a solid start. Enjoy ;)