The Factom Protocol is demonstrating pretty solid stability. At the same time, we are really hurting for resources, and we are competing with protocols that have done some pretty good marketing.
This is the time to do a clean rebuild of the Factom Protocol. We have the opportunity to build on work done by TFA and Factom Inc. for the DOE, on the work done in the WAX build, and on the experience of other successful projects. We can do so without losing touch with the basic design principles in Factom that have proven successful.
Work is still needed to flush out the details. It is at a point where everyone can review the work so far.
Presentation to give the highlights of Factom 2.0
White paper for Factom 2.0
Prototype code for the Validator / Accumulator architecture
The Presentation is pretty approachable, while the white paper has sections that are deeply technical. The ValAcc prototype application can be built and evaluated by developers, and also implements the algorithms described in the white paper around Stateful Merkle Trees.
And not to bury the lead, the proposal suggests we can deploy Factom 2.0 in three phases, where the last two phases are transparent to users:
Phase I
Leaders would be refactored into the validator / accumulator architecture with go channels used to implement the communications between various components. Factomd would be a single server deployment of authority nodes and followers.
Estimated Performance: 1000 - 5000 tps
Phase II
Change Authority Node deployment to require a server per VM. Each VM amounts to a shard of the network with only its own concerns limiting its performance.
Estimated Performance: 28,000 - 144,000 tps
Phase III
Authority Set deployment would add an additional sharding layer within each VM to allow each VM to leverage multiple servers.
Estimated Performance: 25,000,000 - 130,000,000 tps
@Core Committee @Exchange Working Group
Would notify the Governance Working Group, but the @Governance Working Group doesn't actually do the lookup properly... @WB
ADDED: Factom 2.0 Design
This is the time to do a clean rebuild of the Factom Protocol. We have the opportunity to build on work done by TFA and Factom Inc. for the DOE, on the work done in the WAX build, and on the experience of other successful projects. We can do so without losing touch with the basic design principles in Factom that have proven successful.
Work is still needed to flush out the details. It is at a point where everyone can review the work so far.
Presentation to give the highlights of Factom 2.0
White paper for Factom 2.0
Prototype code for the Validator / Accumulator architecture
The Presentation is pretty approachable, while the white paper has sections that are deeply technical. The ValAcc prototype application can be built and evaluated by developers, and also implements the algorithms described in the white paper around Stateful Merkle Trees.
And not to bury the lead, the proposal suggests we can deploy Factom 2.0 in three phases, where the last two phases are transparent to users:
Phase I
Leaders would be refactored into the validator / accumulator architecture with go channels used to implement the communications between various components. Factomd would be a single server deployment of authority nodes and followers.
Estimated Performance: 1000 - 5000 tps
Phase II
Change Authority Node deployment to require a server per VM. Each VM amounts to a shard of the network with only its own concerns limiting its performance.
Estimated Performance: 28,000 - 144,000 tps
Phase III
Authority Set deployment would add an additional sharding layer within each VM to allow each VM to leverage multiple servers.
Estimated Performance: 25,000,000 - 130,000,000 tps
@Core Committee @Exchange Working Group
Would notify the Governance Working Group, but the @Governance Working Group doesn't actually do the lookup properly... @WB
ADDED: Factom 2.0 Design
Last edited: