How to implement a Blockchain from scratch - adding system transactions

Adding a system transaction to a blockchain system is actually quite easy. Let we imagine the situation that we have something as a number of privileged accounts - they might be related to nodes as well and we want to initiate a transaction to adding a new one to these privileged accounts: 

- There must be a transaction that contain as an address one of the address of the privileged accounts. 

- There must be a state information in the blockchain containing the available set of system accounts 

- There must be a validation rule that not only validate the signature but checks as well if the related account is in the system state among the possible addresses. 

- There must be a state transforming rule, which in case the transaction is valid adds the new account to the state. 

The system can be started by adding to the first node a system right and then the first node can attach further nodes to the system account state. 

Optionally, there can be other special accounts or activities in the state that can be carried out only by system transactions. 

Certainly it is an open question if such a system is more vulnerable against forking attacks.

Such a system could provide the basis for realizing on-chain governance. Let we imagine the situation that difficult is a variable in the system state that can be modified only by system transactions. There might be one model that every authorized account can modify the variable, however we imagine that each transaction makes just a kind of a vote for the new value. If the number of positive votes reach a certain value, the new difficult will be considered in the future.  

Types of blockchain governance

One of the critical part of every blockchain solution is governance. It is especially valid for blockchain platforms, like Bitcoin or Ethereum, but it is actually the same for blockchain applications that are realized on the top of a platform. Governance means carrying out changes or further development of the application. There are several models that has different advantages and disadvantages in the practice:

- Off-chain governance means that the governance model is totally independent from the blockchain itself. Changes of the platform is proposed by a community or trusted people and both the implementation and the implementation is carried out by these people as well. Such a model has the advantage that it is technologically less challenging, however it might cause a split in the community resulting a split or hard-fork in the platform itself as well. Such models are realized by Bitcoin and Ethereum where improvements are presented by improvement proposals, like Bitcoin Improvement Proposal (BIP), or Ethereum Improvement Proposal (EIP). The model caused several hard-forks in the above mentioned platforms, resulting for example Bitcoin Cash, or Ethereum Classic. 

- On-chain governance means that several elements of the platform is able to change by a community decision, and both the decision mechanism and the change implementation is supported by the platform itself. Such an example is the difficulty increase or decrease mechanism of the Bitcoin network which is hard-coded in the consensus mechanism and is practically relized by the voting of the miners or the voting of the stakeholders. Other platforms like Monero have much further developed on-chain consensus mechanism, as an example part of the transaction fee is collected into an online wallet as an improvement budget, which can be used for further development or even marketing projects based on the voting of the community. 

From another perspective blockchain governance can be categorized on the fact, who makes the decision. From this point of view there might be the following models: 

- Centralized governance: systems like Ethereum has a pretty centralized governance. From a practical point of view almost all of the changes are governed eventually by Buterin. It has certainly, the advantage of being able to adapt fast, however not necessarily truly open as participation. 

- Open governance: Systems like Bitcoin has a real open governance model. Practically everybody can initiate new changes in the system and the implementation of these changes require a pretty open consensus as well. Practically the core developers, the miners, the exchanges and the shops should all agree in order that a change is implemented successfully. As it is almost a pretty open democratic process, certainly it can be very slow and inefficient in the implementation phase.

- Governance by trusted actors: There can be model between the two previously mentioned examples as well, where several trusted (and sometimes well known) actors can initiate and implement changes in the platform. Such governance model will be implemented directly by Hedera Hashgraph. Similar initiative can be found like in Dash or Monero, where indirectly the stakeholders or the master node responsibles can be regarded as trusted actors.    

Tools for decentralized requirement engineering

Requirement engineering in an enterprise context can be a pretty tough problem, especially at discussing with ever participants and stake and stockholder of the project and achieving a common decision. It will be even more difficult in the context of a consortium blockchain solution as not only a participants of one but several companies should be taken into account. Achieving a common decision in such a situation might be a nightmare. What we would need are tools for the decentralized requirement and process engineering. Like a common dashboard on the process or requirements must be presented with several possible governance algorithms where the participants can vote or modify the process or the requirements based on different interest. Based on the outcome of the decentralized process engineering, the final blockchain system can be designed. The requirement or process engineering can be itself supported by blockhain and of course everything that has anythin to do with on-chain governance will help a lot. 

Bitcoin difficulty and on-chain governance

In the bitcoin protocol there is a part which automatically adjust difficulty in a way that the block time is always fine-tuned to 10 minutes blocktime. If the current rate of blocks is faster than 10 minutes, than the difficulty is increased, if it is slower, the difficulty is decreased. Similar ideas can be found in other blockhain solutions as well, like Ethereum or Monero. This mechanism can be thought as a kind of a on-chain governance method where practically the miners with computation as a scarce resource vote for the change to take place or not. 

Realizing on-chain blockchain governance

To realize an on-chain governance on the blockchain, you have to have two elements:

1. system variables or system contracts: these are special variables that are stored in the blockchain itself and the consensus algorithm of the nodes are dependent on these variables. As an example, difficulty of the standard bitcoin blockhain can be regarded as such a variable. Optimally even the exact consensus mechanism can be stored in such a variable and the nodes might pick an exact algorithm based the variable on the fly. Examples might be changing from proof of work to proof of stake or byzantine fault tolerance. 

2. A changing mechanism of the variable. There might be different mechanisms for the change, like: 

 - totally centralized: there is an authorized actor with a special secret key who can change the value.

 - community voting: several actors, like prominent community members vote for the change and if the majority or super majority voted for the same value, the value will change. 

 - voting by mining: indirectly miners can initiate changes in the protocol itself as well, this is kind of a voting by work (at proof of work), or voting with stake (at proof of stake). Similar mechanism is implemented at some cryptocurrencies where the blocksize can be configured by the miners.

Certainly, extreme attention has to be payed at realizing such a systems, as at the changing the consensus mechanism there might be a totally new form of attack, which is attacking the on-chain governance change itself, like with forking attacks. For this reason, it is always proposed to implement such a governance rules taking effect longer runs as the standard transaction validation. Similarly, as in Bitcoin, the coinbase transaction taking effect only after 100 blocks.   

Another option might be to realize something as "soft governance" in some cases. As an example, we can say that the block size limit is a governance variable that can be increased if a certain agreement was made among participants. However we can do something as a "soft governance", like the block size limit can be increased by every miner, only it is disincentived. 

On chain governance in multi-hash Blockchain

In case of a multi-hash blockchain system, where a pair of a hash-pointer can have different reset time, there might be the possibility to control this reset time based on a common consensus on chain consensus. At a given consensus system, the hash pointers might be stored as: 

<p1, reset_time_1, remaining_reset_time_1>

<p2, reset_time_2, remaining_reset_time_2>

The reset algorithm can work as:

if (remaining_reset_time_i <= 0) {

  do hash reset;

  remaining_reset_time_i = reset_time_i;

}

The reset time is however stored on the blockchain, so there might be a decentralized voting mechanism, controlled either by the miners or by the community that can change the reset time to a new value. This is however not so simple. The problem is that the reset period of p1 hash pointer has to be in the middle of the hash period of the p2, otherwise the system security can be more easily compromised. One algorithm can be the following:

Supposing we have accepted a new future_reset_time, we can do the following modification at the following reset like in this example for 1, supposing that the resets have 50% time delay to each other:

if (remaining_reset_time_1 <= 0) {
  do hash reset;
  remaining_reset_time_1 = future_reset_time;
  remaining_reset_time_2 = future_reset_time / 2;  
  reset_time_1 = future_reset_time
  reset_time_2 = future_reset_time
}

Certainly, it is an open question how agreement on the new retention time can work in the most efficient way. One idea can be to introduce some special variables in the blockchain that store such a system information and a voting mechanism, like special voting transactions by end-users, or voting by mining power that can make a proposed variable final.  

blockchain governance and the two levels of smart contract

Blockchain governance is a complicated topic, especially if we consider not only the consortium but the public solutions as well. Mismanaged governance can cause forking and other undesired effects. It would be a great idea if governance activities of a blockchain could be actually supported by smart contracts, implying two categories of smart contracts in the system: 

1. system smart contracts, realizing basic functionalities and services related either to maintain the consensus and the system or providing general services to other smart contracts. 

2. user based or custom smart contracts, providing general user defined functionalities using both the consensus algorithms of the blockchain and the functionalities of the system smart contracts. 

The key concept of such a system smart contract layer is to provide a further integration link between the infrastructure nodes, the services of such a nodes and the system smart contracts, or putting elements of the genesis file into the smart contract.