This blog post is part of a series called Governance of Consortium Blockchains. The series will explore the policies that should be created once a governance body takes form. Read below for the fourth of this five-part series.
Technical policies are a touchy subject for any type of organization. If they are too tight, then innovation is stifled. If they are too loose, then the organization’s efficiency suffers. When creating governance policies for consortiums, the focus should be on enhancing trust between members and keeping the infrastructure stable. The policies should promote best practices, but not dictate methodologies. Chaincode, or smart contracts, and the underlying infrastructure are covered.
There are three areas to focus on: change management, verification, and security.
Change management is primarily a communications policy. It covers both emergency releases, such as security fixes, and regular planned releases to the chaincode and infrastructure. It may include references to specific technologies and versions.
Regular planned releases can be on a continual schedule, such as every quarter, or as part of a specific project plan. The policy will set the expectations for notification, downtime, rollbacks, and other release-related tasks. The actual release methodology should be agreed upon by the members in the consortium.
Emergency releases will have a shortened timeline, due their very nature. The policy should include the same expectations as a planned release:
- Releases are planned quarterly and should be executed during off hours.
- Releases should happen in the third week of the third month of a quarter.
- If downtime is expected to be greater than two hours, a downtime notification needs to be sent no later than one month in advance.
- Notifications are sent to a contact list provided by consortium members.
- Notifications needed during a release consist of a start notification, status notifications hourly, and either a completion notification or a rollback notification.
- Emergency release notifications should be sent no later than one hour before the start of the release. Although more lead time is preferred.
Verification refers to auditing code changes before they are released, pre-release acceptance, and post-release acceptance. Code audits should be conducted by a group approved by the consortium. Pre-release acceptance is a formal approval process done by members of the consortium. The policy will outline which members need to approve and how the results are tabulated. Post-release acceptance is a less formal process that is used to make sure the release is working as expected for each member:
- Pre-release acceptance requires a super majority of members voting to approve the release.
- Code changes are audited one month before pre-release acceptance.
- Code auditors are selected from each member group annually.
- Post-release acceptance requires all members to verify that the system is working.
Security policies fall into three categories: identity management, infrastructure security, and code security.
Identity management deals with the mechanisms and procedures need to prove the identity of a participant. Mechanisms such as private keys, multi-factor authentication, and password strength are outlined and defined. Procedures are generally best practices used in the industry.
Infrastructure security focuses on the technical aspect of the network, such as certificate authorities and certificate types (e.g. x509). The policies set the common practices across the consortium, so the network can work together:
- TLS v2.x security must be used for all communications over the public internet.
- The consortium uses a private Certificate Authority.
- The Certificate Authority provides X.509v3 certificates with SHA256.
- The Certificate Authority will publish Certificate Revocation Lists (CRL) within one hour of a revocation.
The last piece in this series will be about arbitration, adjudication and other legal matters.
Check out the rest of this series:
Governance of Consortium Blockchain Series Part One