While A Constitution For A Blockchain May Seem Unusual, It Will Make Early Project Development Much Easier And Result In A More Responsive Platform.

While a blockchain constitution can be compared to the terms of service that many websites use, the main advantage of utilizing a constitution is the ability to make necessary changes efficiently.

While making modifications to the underlying code of a project may seem very dangerous, during the early stages of a project some changes should be expected. Instead of taking the opinion that the network is bullet-proof as is and making any modifications extremely difficult, a constitution would allow all users to agree to terms that are established surrounding modifications to the software. This is not to say that any specific entity can change the underlying code independently, because any modifications would still require an overwhelming majority of block producers to reach agreement on the proposed changes. Outlining the rules and manner in which changes can be implemented up front will allow the platform to be receptive and adaptive to potential problems that the network is faced with, without the users feeling as though any single actor or group has too much control or influence. 

The block producers are elected by users in proportion to their total stake, which will mean that any large stakeholders will always be very up to date on block producers activity. While a constitution may seem like it is a dangerous binding contract, the goal of the constitution is to ensure that all users are well aware of how the platform actually works. The ability to change underlying code will likely make many individuals very weary, but none of the block producers or developers have any incentive to make any modifications that have a negative impact on any part of the network. In theory block producers could collude and attempt to make modifications to contracts in a malicious way to give themselves an advantage, the probability of this happening is extremely unlikely. 

The Constitution are just a general set of guidelines, and individuals can create more specific guidelines specific to their contracts. 

Developers and parties engaged in smart contracts on the EOS platform will have the ability to establish their own rules outlining the specific contract, and agree to different rules than other contracts. If two individuals were going to enter into a hedging con tract with each other, they could specify that no modifications to the contract code could be implemented from either party, or any block producer. If a business was attempting to establish their business logic on the platform, they would likely specify that the individuals controlling the account, as well as the block producers could modify the underlying code. This gives the business the ability to make changes in the early phases of its development, because assuming that initial code is perfect for real world deployment is impractical. While the code may be strong and may very well turn out to run on the platform perfectly, the ability to make the necessary adjustments if the application isn't performing optimally is very important for the rate at which a project can actually come to life.

If an application was to gain mainstream success, it would have likely already been tested extensively for some time before the adoption took place. Adoption will not happen overnight, and the ability to make the necessary modifications to the code or application is vital for being able to achieve and support mass adoption. There are very few applications or projects that were never modified from the time they were first released to the point at which they were adopted. The developers of the application still wouldn't have absolute power over making modifications to their code, because in most cases a certain percentage of block producer must agree on these modifications as well. If an application developer attempted to update their code with something against the terms of the constitution in any way, the changes would likely not be implemented by the block producers. 

Code cannot ever be ensured to be perfect, so why establish a platform's ability to change under the assumption that the original code is perfect.

While individuals may be confident that the code will always perform as instructed, in the field other factors can often come into play and cause problems that the developers did not realize. While the original code may be perfect, if the guidelines around making changes and modifications to the code assume the code is perfect then changes will be much harder to implement. Having the firm belief that the original code is ideal and should not be manipulated has caused significant issues for various projects in the past, such as Ethereum and Ethereum Classic. While having the ability to make modifications to the code may seem like there is greater risk, I actually think that this will enable to platform to respond to potential threats and issues much faster. 

If we assume that witnesses on the EOS platform will act honorably and in the best interests of the platform, then the danger from the ability to modify the code assuming consensus is not nearly as scary. Any changes that are not deemed Emergency changes will be delayed 30 days after reaching the required consensus before they are actually implemented. This means that if users and the community deem that the proposed changes will hard them or the network in some way, they have the ability to pull their support from the witnesses who support the changes, and replace them with witnesses who disagree with the changes. 

While Emergency changes much reach the same consensus as any other change, the change is able to implemented immediately. This will not mean that the block producers have the ability to abuse this power, because if the community deems that these changes were dangerous or disagreed with them, then they could give their support to witnesses who will work to reset the modification. A witness must firmly and confidently believe in any purposed change that they support, because ultimately they are putting their credibility and their 'job' on the line. If witnesses began to abuse any of their power to modify or change the software, they would be noticed and immediately booted from their position by the community. Due to the fact that all stakeholder's have a direct interest in the future success of the platform, the community will likely be very observant of all witness behavior. Due to the fact that witnesses are so replaceable, they have ample incentive to act in the best interests of the community and platform. 

I really hope that you enjoyed this post, and I urge any comments, input, questions, ect. to be left below. Thanks for reading!

For more/upcoming information on EOS, I recommend you subscribe to the mailing list here, and check out the GitHub here. Dan recently did a coin interview where he offered many great explanations and information which can be found here.

image sources:1-2-3