2.2.9 Cycle 9 - Protocol Updates

Design

A lot of the work so far has been based around the software, in the form of the node program and the webportal, however there is a third portion of this project which is equally valuable to its creation, the monochain protocol itself.

Hence in this cycle I will be expanding some of the concepts initialised in the analysis of this project and therefore this cycle will take a very different form to the other cycles in the project.

Now the reason I'm only just talking about the protocol this late into the project is because a lot of the initial sections were theorised and planned in the analysis part of this project. However due to the complexity of a blockchain protocol, and hence the monochain protocol, this was only the major framework of the protocol and the details need to be ironed out as the project proceeds.

In this cycle the two sections of the protocol to be looked more into are:

• The regulation of the speed at which blocks are created

• The initial theorisation of voting on blockchain parameters.

Objectives

As specified in the above there will be two main areas of the protocol to be examined and improved. Those areas being:

• Regulating block production speed

• Voting on blockchain parameters

Let's start with the regulation of the speed at which blocks are produced

In order for the blocks to be properly propagated amongst all the nodes in the network, blocks cannot just be created thousands of times per second and have it hoped that all the nodes receive them, hence some kind of regulation method needs to be created to limit the amount of blocks created per time period. Initially this will be purely a conceptual, protocol change, but time permitted should be implemented into the node software in a future cycle.

• Conceptualise how blocks are going to be regulated

• Don't use a constant timing based method (e.g. only allowing a new block every 10s) as this could lead to multiple nodes publishing new blocks as soon as that time period completes, causing forks.

Leading on from here is the voting concept

Voting is essential to any decentralised power structure and since this blockchain will be a decentralised structure that will most likely require updates and adjustments into the future, it makes sense for the monochain to allow voting to change the specifics of the fundamentals of which it is based upon. The requirements for this are that the specific parameters that control the functunality and specifics of the blockchain should be able to be changed and tweaked through voting by users of the system.

• Votes should have the power to change parameters of the blockchain, e.g. transactional speed.

• Votes should allow anyone with a wallet to vote.

Development

Transaction Speed

In order to ensure blocks can be created whilst there are low transaction rates yet restricting blocks from being created too quickly, each block may not be created more than once per 10 seconds, with each block having a maximum of 5000 transactions, setting the maximum transactions per second to 500, far more than Ethereum 1.0's 30 per second although much lower than Visa's average of 1700 per second and Ethereum 2.0's theoretical 100,000 per second.

This will be achieved by setting the number of seconds after the last block creation at which a block can be registered to be:

time = 5 + 30000(transactions + 50)^-1

Where the transactions variable is the number of transactions in this new block, promoting miners to add as many transactions into a block as possible, such to reach this time constraint quicker by lowering it.

An upgrade to increase this could be introduced in the future through the use of the system's wallet, as this rule will be included into the blockchain as a smart contract owned by the system's wallet. However, this will need to be done through voting.

Voting

Voting is essential to the way the Monochain works, as it creates a truly decentralised system of which no individual party has control of whilst ensuring the system can adapt and change into the future.

The way in which this will work is the following:

1. A mining Node will register a vote by creating two new voting "wallets", where the public key for the wallets will be in the format "vote:[uid]:true" and "vote:[uid]:false" and there is no private key.

2. Users will then vote by sending a "vote token" to one of the two wallets in the pair, where they do not need any vote tokens to send a vote token, they just cannot send a token to the same vote more than once and cannot send a vote token to both "wallets".

3. If a vote receives less than 100 votes or 75% of the quantity of votes from the previous vote then it is immediately cancelled as invalid (although as this is a system rule it can be changed through voting).

4. If a vote receives a majority of no votes then the vote is cancelled and nothing happens, if the vote receives a majority yes vote then the change it wishes to put into place is granted and that change is made to the system wallet.

5. Initially votes cannot exceed more than once per 1209600 seconds (two weeks), but this can be set to be controlled by some algorithm once the methodology is proved to work