BOS Platform Development updates

Consensus and Trust Contracts Specifications

A lot of work was put into the creation of the specification of the Consensus Algorithm and Trust Contracts, although this may sound trivial, we’d like to stress that we are not just a project that will copy blockchain code, refine it and release it — we are building a completely new blockchain platform from the ground up. Understanding that there would be some that would think “You’re really just tweaking Stellar” — we’d like to advise that we are using Stellar’s consensus algorithm as a basis for our mFBA. This means revisiting the concept behind it, optimizing it based on theoretical research, process and operational analysis, tests, and fit to our environment — and this is only the consensus component — we will need to integrate this into the wider BOS Platform!

As mentioned last week, we have broken up the development of the Platform into Iterations, these Iterations will specifically focus on the Consensus and Trust Contract components.

Last Friday marked the last day of Iteration 4, and below is a summary of the outcomes:

Consensus

The objective of the consensus component is to determine the ultimate quorum configuration for our Platform.

The development team created a model able to determine whether the quorum configuration of our network is healthy or not in relation to consensus verification. This required interrogation into the fundamentals of Federated Byzantine Algorithm in relation to safety, liveliness and fault tolerance, then translating that into the model.

We are happy with how the model satisfies safety and liveliness, but we wish to further explore fault tolerance of nodes and the network — this will be one of our focuses for the next iteration. In addition for the next Iteration, we will:

Further our model with fault tolerance and safety verification (what is the difference between Safety and safety verification?)

Explore other consensus algorithms in the view of optimizing our BOS Platform (ongoing)

Investigate consensus with:

Multiple ballots

Single client — messages to one node

Multiple clients — messages to multiple nodes

Message scheduling

Trust Contract

This iteration of the Trust Contract stream of work focused on the architecture design and integration components into the blockchain such as the Message, Account, Consensus and Storage objects.

Next iteration will focus on setting up the environment for the team to further work to write the Contracts — and in the future we will incorporate OWL and TAL aspects to develop the Trust Contract.

To read more about our Trust Contracts, please visit our Medium articles: Trust Contract Part 1, Part 2, Part 3

(HYPERLINK TO: https://medium.com/@boscoin/smart-contracts-trust-contracts-part-1-83f12dec7641 https://medium.com/@boscoin/smart-contracts-trust-contracts-part-2-6b9dbadfdf98 https://medium.com/@boscoin/smart-contracts-trust-contracts-part-3-6cf76bf5882e)

Platform Specifications

The specifications work the team are working on breaks down the Consensus and Trust Contracts into specific elements. The level that it dives into will essentially map out all the coding required for those aspects.

As mentioned before, we are keeping development behind closed doors, but we will give you a sneak peek into the work:

This is just a excerpt of the the specification work which includes elements such as:

Hash Key & Signature; Multi-sig; Inflation; Node State; Confirmations; Acceptance; Quorum Banning; Validation; Public Membership.