Governance
Even though blockchain technology is immutable by nature, Openfabric has to be able to address any market challenges and continuously adapt. The ecosystem must include mechanisms that can apply adjustments to its components, when needed. Conceptually, there are two categories of changes that can be applied: changes in system parameters, and changes at the protocol level. The system parameters guide the proper functioning of the platform. The actual values for these parameters should be the subject of system-wide voting sessions. Some examples of parameters that can change over time are the execution fees and the minimum number of peers required for a specific task. The protocols themselves need to be adjustable and - with sufficient agreement - it should be possible to introduce new rules and constraints. Amendment of the existing rules will be necessary for the future. As the Openfabric ecosystem is decentralized, there cannot be a single organization or person performing these changes, so the network has a governance system that allows prominent actors in the community to propose and vote for improvements.
A. Improvement Proposals
Protocol level and system parameter adjustments should be submitted to an enhancement proposal system. Each proposal contains logic for adjusting parts of the ecosystem. A proposal is only executed if a majority of the council members have voted in favor of it within a time limit.
B. Governance Model
The governance is ensured by a council formed by a group of individuals and organizations that are allowed to cast a vote on improvement proposals. This council is dynamic in size; one can leave the group at any time, and new members can join if the majority approves them. The council members are responsible for continuously applying changes to the network, so that it can adapt to the frequent changes in the market.
C. Consensus
From a scientific perspective, a decentralized system represents a replicated state machine [78], [79]. The replication ensures the system’s consistency, liveliness, and fault tolerance. Traditionally, the transitions in system state are endorsed by a unique consensus mechanism that is operated by the entire network. This approach has proven to be slow [80] and inefficient, in terms of energy consumption [81], since every decision requires the involvement of the entire network. In order to ensure a fast, scalable and responsive system, Openfabric is utilizing the dynamic consensus [46], a superset of the traditional consensus architecture. As depicted in Fig. 10, the physical network is virtualized; a node represents a computing element engaging into multiple consensuses in parallel. The Dynamic Consensus represents a new architecture extension which allows multiple, complementary, consensus algorithms to run on the same platform. This approach ensures that several decisions covering different topics can be reached in parallel.
Fig.10: Dynamic consensus model
In a distributed system, any component of the network may be faulty at any moment, so the system design should incorporate mechanisms to protect against these faulty nodes [82]. In order for the system to be fault-tolerant, it must introduce redundancy and replication of the information, as well as the capacity to isolate the faulty nodes [79]. From an infrastructure perspective, the Openfabric DOS runs the dynamic consensus model on top of a federated network. The DOS represents the backbone of the ecosystem, and is responsible for all governing aspects.The dynamic consensus guarantees byzantine fault resilience by adding the replicas in the communication protocol; it will provide a minimal number of nodes on any level of the consensus.
D. Regulation Compliance
The GDPR (General Data Protection Regulation) [83] is an EU regulation for protecting an individual’s fundamental right to privacy; it broadly defines personal data as ”any information” that relates to an identified or identifiable living person Art. 4(1). The GDPR’s core principles are lawfulness, fairness and transparency, data minimisation, data storage and purpose limitation, accuracy, accountability, integrity, and confidentiality. Enforcing GDPR in a decentralized system is a controversial and challenging task; it creates a tension between protection of the fundamental rights and technology innovation [84]. Principal difficulties that should be resolved are blockchain data removal (blockchains are immutable), automated decision-making in a smart contract that can be contested, and deciding on who the data controller is. Various studies [85] [86] [84] tried to show recommendations on how DLTs can be GDPR compliant, but there is no standardization on this subject. In Openfabric, the user is the owner and controller of their sensitive information. For publicly-disclosed user attributes, the GDPR rules are still applicable, and the user should grant consent for allowing to have that data revealed on the platform. The user can revoke access to their data. To ensure privacy and security, users encrypt data before sending it to the platform, and in addition, the off-chain storage pointer (address) is encrypted. When the user requests data removal, the platform will destroy the encryption keys. Even if data continues to exist on the off-chain storage (when the deletion is impossible, e.g. IPFS), the content cannot be accessed without decryption keys. Openfabric implements a logging mechanism wherein activities that include personal data are recorded.
