独家优惠奖金 100% 高达 1 BTC + 180 免费旋转

How to organize a neutral Blockchain governance?

To tackle this challenge, we stepped back from actually applying blockchain technology and asked rather what is necessary to have a functioning blockchain that can be applied. Of course, this raised at first the question: What shall it be applied for?

To be able to answer this question without elaborating for hours and hours, we simply defined the scope to be that of enterprise applications — this was also due to b2b-focus of the evan.network — we took here advantage of the experiences we already made on this field.

So, the first central question for us to be answered was:

What is necessary to have a functioning blockchain that can be used for enterprise applications?

The first criterium coming to mind was stable costs. In businesses, the question of costs in relation to revenues is crucial. Both are subject to planning, and for successful plans, stability and thereby predictability of its columns is necessary.

The second criterium coming to mind was fast transactions. In today’s economy, exchanges and transactions happen with a high frequency — recording them must happen with the same frequency. And the frequency is likely to increase in future.

The third criterium popping up in our heads was data protection compliance. It is especially important since on May 25th of this year, the GDPR became effective for all companies operating in the European Union or interacting with people living in the European Union.

So, with these criteria in mind, we took a look at the different forms of blockchain, which are in existence.

The most popular one — popular in terms of “who knows it” — is for sure the public chain. We proceeded to check it against our three categories.

Stable costs. This was our first bullet point. And had to be rejected for public chains — simply because their coins are not stable. In fact, they are subject to large fluctuations.

It becomes quite clear on this chart. It shows the price of Bitcoin in green. The study, which it was taken from, was published on Pulsar and shows a strong positive correlation between conversation volumes in social media, search volumes and the coin price. So, when people talk about a coin, even more people get interested, search for it, buy it and increase thereby the price — so the large fluctuations seem to be a pure result of supply and demand.

The next criterium we found earlier was fast transactions, or small block times, respectively. This also had to be rejected for public chains.

On average, transaction times for the Ethereum chain, one of the most popular public chains, are at around 15 seconds — which can be seen on the above chart. This is way too long for enterprise uses.

And also the third aspect — the compliance with data protection regulations — could not be answered positively for public chains. In those, usually Proof-of-Work mechanisms are applied. The big problem here is: the unknown members of it. Everyone can participate and try to mine new blocks. But GDPR requires to know the identity of data processors.

Summing up, we had to conclude that public chains are not suitable for enterprise applications.

Going on, we shifted our focus to private chains and checked them in the same manner as we did for public chains.

The first criterium to check was again stable costs. It could be answered positively, because for a closed ecosystem with restricted access and no publicly traded tokens or coins, there will be no comparable influences of demand and supply as we observed for public chains.

The second criterium was fast transactions. It is also given in private chains. With a closed ecosystem, one will observe less traffic than with an open one — hence fewer transactions, and accordingly shorter waiting times.

The third criterium was data protection compliance. In private chains, the operator processing the data is known — so the criterium can be fulfilled.

So what had we to conclude? Clearly, private chains meet all the requirements we defined, which are required by a blockchain to enable enterprise applications. However, there is one obstacle regarding private chains:

Why should one use them?

What is the advantage of a privately operated blockchain in comparison to platforms and databases we all know?

A central concept of blockchain is the possibility to build neutral networks — in which no one has full power and data sovereignty. In contrast, in private chains, the operator is in exactly that dominant position — so, to use a common picture, one could describe private chains in comparison to known platforms like an old car with new paint — looks differently but is actually the same.

So, we had to face the big question of where to go next to find what is necessary for an enterprise blockchain?

As you know the evan.network from earlier blog articles we published, our solution was the following: We tried to set-up a blockchain-solution for enterprises that is somehow public and somehow private, both at the same time.

For the category of cost, it was obvious from our earlier dive into public chains that the specific blockchain’s token must not be traded freely.

For the fast transaction times, first of all, no Proof-of-Work as consensus mechanism had to be used. Next to that, we thought it useful to increase block sizes — the bigger a block is, the less often a new block must be confirmed. Additionally, decreasing the amount of data that are put into the blocks could be helpful — on this way the frequency of required new blocks sinks as well.

Last, but not least: data protection — data processors must be known. Period.

We know that this all sounds again like private chains. To account for the concept of decentralization coming along with blockchain technology, it is of central importance to take measures to not fall into the same dominance-centralization-trap that private chains are already in. Otherwise, one will be faced again with the question of why to use blockchain?

The possible solution accounting for all the needs of enterprise-ready blockchains is a consortium chain with known members who operate the chain. Such a consortium chain is completely free to use by anybody, can be confirmed and validated by anybody and is open to welcome and integrate new members and has optimally no central authority.

Now, since we answered the first central question — What is necessary to have a functioning blockchain that can be used for enterprise applications? — we were confronted with the next big question:

How to run a syndicated blockchain network for enterprises with known members, but without central authority?

This is the central question of governance. In the following, we would like to present our approach to finding the answer that appears most suitable to us.

At first, we decided to clarify who are the stakeholders in the blockchain enterprise network.

The first and most important role to think of is that of a node operator. Nodes are the central columns of blockchain — they store the blockchain copies and if needed additional data, and they provide consensus for the network.

The next role to think of for a blockchain enterprise network could be called users. These are individual business units, which use the provided network infrastructure and build and implement their own business models within the network. One could see them in analogy to shops in a mall — where the building of the mall is the blockchain network itself erected by the nodes.

The third group of stakeholders in the blockchain enterprise network could be that of developers. These are independent coders or even software firms, which offer services to members of the network.

The last stakeholder group to think of is that of so-called customers. They simply use the network and the offered business models in it.

After coming up with stakeholders, we proceeded to think about the objectives and intentions of the main roles. Specifically, we looked at the question, if a group should have votes in the network.

The node operator takes over responsibility and provides resources to the network — so one might assume that he wants to receive a compensation for these services. This compensation might be on the one hand fulfilled through giving him a voice. He could be allowed to participate in decisions that are crucial for the network. However, it might be possible that this is not enough for him. Burden him with costs and giving in turn votes might please a very altruistic individual — but we cannot and should not assume such an attribute in the enterprise world. Hence, we also need to ensure that he is somehow financially compensated.

The user implements a business model. He wants to make revenues, otherwise he wouldn’t be there. His own business should please him sufficiently from a financial perspective. Still, we need to answer the question, if the user also would ask for some form of participation rights?

In favor for this would be the argument, that only with his offered business models, the network itself starts to make sense. A mall without shops is not very attractive, isn’t it?

On the other hand, one could argue that the user does not contribute to the network structure itself, he simply takes advantage of it — so why should he be allowed to participate in decisions on it?

We came up with the idea to include users in network structure decision making processes, who reach a certain level of influence — for example because their business models represent a non-neglectable share of all traffic and transactions in the network.

The developer might also have financial interests. He can meet them by charging users for his services. In addition, we assumed for now that he only provides coding input to the offered business model solutions, not to the network infrastructure itself. So, it seemed fair that he does not need to participate in network decisions.

The consumer is the last stakeholder group to consider. Of course, he has no financial demands to be fulfilled due to his role in the network — he simply utilizes a given structure. Why paying him for that?

After laying out, who of our stakeholder groups should somehow participate in network decisions, we also defined the decisions, which need to be made.

Therefore, with the objective to not overload this article and confuse every reader, we concentrated on two main subjects: technical and financial questions.

Technical questions would be for example on whether to execute a hard fork, to alter the networks core code, or to switch to another consensus mechanism. It should go without larger discussions that node operators must participate in those kinds of decisions. Regarding the users, or at least the large users we proposed to include in decisions, we argued not to include them, because these technical decisions concern the fundament the network is built on, and they do not interact with this fundament.

Financial questions entail, among others, the gas prices or prices for potential storage services. Since both node operators as receiver and users as a provider of those payments are impacted, both must have a vote on the issue.

We concluded that the node operators are in favor of high prices. In contrast, users would prefer low prices — because they will be interested in more traffic on their business models, which will be the case for cheaper prices. So, the topic of financial questions was identified as one of the diametral interests.

At this point, we have defined who should participate in which decisions. Still, we needed to clarify how the decisions take place. Shall it happen off-chain or on-chain?

Off-chain means that identities of the blockchain enterprise network come together and vote — per e-mail, or via some online voting tools, or even in person on a monthly meeting. Their decisions are then implemented on the blockchain.

On-chain means that voting happens directly with chain-identities in the blockchain, and then the decisions get implemented directly and automatically.

We came to the position that for the current state of the blockchain world, and especially for an enterprise network in its early stages, off-chain voting is favorable. On this way, potential mistakes in codes can be circumnavigated.

Later, on-chain voting might become an option.

With multiple identities included in a decision, a vote happens. For it, interests need to be aligned and no role should become too influential. Since we are in a blockchain world, we want decentralized power — so checks and balances are required. Sounds all familiar, right?

The same issues are faced in every country — and tackled with constitutions. So we could say, that for the sake to organize and govern a blockchain network, we require a constitution.

In this figure, you can see an approach to mimic the US constitution with the Bitcoin blockchain. The different groups in the Bitcoin ecosystem get assigned to the constitutional branches. We consider this to be a promising approach to finding a suitable governance structure for a blockchain network.

Constitutions with a system of checks and balances worked for hundreds of years — why shouldn’t they do so in blockchain networks as well.

Accounting for different groups and including them and their interests and needs in decisions creates effectively a blockchain democracy.

However, we are aware that there are also critical voices, who argue that blockchains should not be democracies.

They present as an argument, that one real-world individual could have multiple blockchain identities. Thus, one man one vote wouldn’t work properly. Switching to one coin one vote, in a staking set-up, wouldn’t solve the problem either, because then the network would end up as a plutocracy — the rich ones make the decisions.

The issue of multiple identities per individual could be tackled in syndicated enterprise chains by requiring upon registration a KYC process — then it would be noticed if an individual registers multiple times.

Finally, we focused on the legal body for a blockchain enterprise network. Apart from the typical blockchain decentralization ethos, it should be clear to everyone that there is always a legal body needed. Our opinion is to be careful upon creating such a body. In many jurisdictions, it can be very hard to change statutes of such a body. Hence, we would advise on starting with a loose consortium structure between the players, based on contracts. On this way, the network can be developed and mistakes in its inner set-up can be cleared easily. Once everything is defined and working, the final legal body can be formed.

We hope we were able to provide you with some insights upon central questions of governance in syndicated blockchain networks for enterprises.

Follow us on Twitter to get all information around the evan.network!

Add a comment

What is your view?

Send

Related posts:

Transforming weekends

A heart that aches with the pain of the others. What paths led them to this place? I stand amazed at the courage the others display in facing their pain, in revisiting pasts. What grace, undeserved…

What is a Certified Translation?

This is a common question for almost everyone needing a “certified translation” for study, immigration, tourist or medical purposes. All professional translators should be educated to degree level…

A Self is Always Becoming

I remember hearing about how people don’t have a self to find anywhere deep inside. We’re an amalgamation of so many different things and still constantly changing every day. I think trusting other…