Beyond Traditional Governance: Embracing On-Chain with OKP4 (2/3)
1. Governance and Facts
In any system of governance, having access to accurate and reliable information is crucial for making informed decisions. The understanding of the world and the interpretation of facts form the base upon which governance relies. In this context, several key elements contribute to establishing a reliable source of truth and enabling effective governance.
Let’s see the main data sources on which the OKP4 protocol is based.
1.1 The State
With its decentralized and immutable nature, blockchain technology provides a foundation for establishing a trustworthy and transparent source of truth. Governance systems rely on these data, considering them an indisputable truth at a specific time (i.e., at a particular block height in blockchain terminology).
These crucial data enable the expression of enlightened governance, informed by information at the heart of the blockchain, such as the history of transactions, the status of account balances, positions in staking, and the outcomes of voting processes, to name just a few.
1.2 The Knowledge
Knowledge refers to the global understanding of the world, i.e. what we know about the Dataverse.
Knowledge is also part of the state of the blockchain, but in a very specific form: the fundamental unit of this knowledge is the semantic triple (https://en.wikipedia.org/wiki/Semantic_triple): Subject, Predicate, and Object. These triples are recorded in the OKP4 blockchain, rendering them indisputable truths.
Governance extracts its source of truth from this knowledge, formulating targeted and adaptive regulations.
1.3 The Verifiable Credentials
The Verifiable credentials (https://en.wikipedia.org/wiki/Verifiable_credentials) refers to what we know about a (decentralized) identity. It plays a crucial role in establishing trust and authenticity in governance systems. These credentials enable active entities to prove specific attributes or qualifications about themselves while preserving privacy. Hence, governance, utilizing the knowledge derived from verifiable credentials, can evaluate the fulfilment of particular rules that necessitate these properties, for instance: identity (age, nationality), ownership (digital assets, NFTs), and qualification (certification), to name just a few.
1.4 The IBC
In the Cosmos ecosystem, Inter-Blockchain Communication (IBC — https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html) protocol serves as a reliable source of truth by facilitating secure and efficient communication between different blockchain systems. It allows transferring information, assets, and data across disparate blockchains, expanding the scope of accessible and verifiable information.
Through the Inter-Blockchain Communication (IBC) protocol, governance can tap into a wealth of accurate, cross-chain verified data, broadening its knowledge base with insights from other blockchains.
1.5 The Oracles
Oracles represent the window into the Wild World beyond the dataverse and the blockchain. As a bridge between the physical or external world and the blockchain-based systems, oracles channel external data and real-world events into the OKP4 blockchain.
Through Oracles, Governance can access up-to-date, accurate and trusted information, enabling evaluation of the rules based on real-world facts, such as financial data, event outcomes, IoT sensor data, and real-world identities, to name just a few.
2. Governance on-chain
Considering governance as an integral part of the blockchain presents numerous challenges, but it is a critical undertaking, especially given the high sensitivity and criticality of governance’s scope and stakes. This is particularly true in the context of the OKP4 protocol.
Let’s see some significant benefits:
· Transparency and Trust: On-chain governance ensures that all decisions and rules are recorded on the blockchain, providing a transparent and immutable record.
· Decentralization: Traditional governance models often rely on a central authority. In contrast, on-chain governance is inherently decentralized, which can lead to more equitable outcomes and greater participation from the community.
· Security: Blockchain’s cryptographic security measures protect the integrity of the governance process. This helps prevent fraud and other forms of manipulation, ensuring that the governance process is fair and secure.
3. Governance as Code
“Governance as Code” is a captivating narrative. It’s a four-act play that spotlights a dialogue between a fictional blockchain developer and myself. The underlying theme of this story revolves around implementing governance rules within the OKP4 blockchain.
3.1 Act 1: The Code, Nothing But the Code
Developer: I think we should implement governance using smart contracts. They offer great flexibility and security.
Me: But wouldn’t this quickly get complicated? If every governance requires its own smart contract, we would end up with hundreds, if not thousands, of contracts to manage.
Developer: Yeah, it’s true, but the flexibility and transparency of smart contracts are major advantages.
Me: Sure. But what about security? How to guarantee the security of hundreds of smart contracts, all different, how to ensure that the governance encoded in the code of smart contracts is compliant?
Developer: You’re right. Perhaps we should consider parameterizing smart contracts to improve their manageability.
Me: Explain yourself!
3.2 Act 2: a few steps towards Abstraction
Developer: Let’s parameterize smart contracts. This would allow us to handle variations between governances without having to develop a new contract for each new governance.
Me: That’s absolutely true, but there’s still the question of how you can design it, and how much flexibility you want to provide to smart contracts. You will quickly run into limitations, and we will go back to the previous situation, several hundred smart contracts, which will be even more complicated to audit, because of the abstraction.
Developer: Hmm… I understand. So, the sticking point seems to be the expressiveness of the parameters. If the parameters could finely detail the governance rules, that should theoretically solve the problem, right?
Me: Exactly. So, what’s the next step?
Developer: It brings to mind DSLs — Domain-Specific Languages (https://en.wikipedia.org/wiki/Domain-specific_language).
Me: Explain yourself!
3.3 Act 3: The power of DSLs
Developer: Here’s the idea: A DSL could indeed facilitate the expression of governances. This would allow us to create more tailored and readable smart contracts, and possible, implement only one, only one to rule them all!
Me: But is that really possible? The DSL would need to be both flexible enough to cover all possible governances and precise enough to leave no room for misinterpretations.
Developer: This is a complicated question. DSLs are often used in specific contexts, and creating a DSL to express all possible forms of governance could be very complex. However, it is not impossible.
Me: Creating a DSL is challenging: you have to handle lexemes, tokens, unambiguous grammar, and semantics (see formal language theory). Developing an interpreter for a DSL can also be tough, even more for a smart contract executed in the blockchain. While there is an extensive range of tools already available, the semantics (the actions) need to be implemented. This implementation process is incredibly complex, and ensuring that it functions as intended is even more difficult.
Developer: I agree. This approach is too ambitious, out of reach, and ultimately untenable. Well, I’ve lost all hope.
Me: You shouldn’t. One observation: in nature there are specific languages already existing, with their interpreters already coded (and functionnal). why not using an existing Logic Language?
Developer: Explain yourself!
3.4 Act 4: Prolog, a new hope
Me: Let me suggest a proposal: Prolog (https://en.wikipedia.org/wiki/Prolog) as a DSL. Originating in the 1970s, Prolog is the most widely adopted language inspired by logic programming research. It’s fundamentally a PROgramming LOGic language.
Developer: This is above understanding!
Me: No this is mind blowing!
Developer: …
Me: Prolog could facilitate the precise and flexible expression of governance rules required for the OKP4 protocol.
Developer: Hold on, I’ve tinkered with Prolog before: Unification, First Order Logic, Horn clauses, Backtracking, Recursion, Cut…
Me: It’s not as complex as it may seem. Given its goal-oriented nature, Prolog is quite intuitive and ideally suited for rule expression.
Developer: …
Me: Alright, let’s illustrate this with an example. Imagine a Zone that only acknowledges datasets under an Open Data license related to agriculture or food. We can effortlessly express a Rule that outlines the criteria for “declaring” the dataset as follows:
canRegister(_, Dataset) :-
license(Dataset, License), openLicense(License),
(field(Dataset, "agriculture") ; field(Dataset, "food")).Developer: Ah, that seems remarkably straightforward to comprehend.
Me: Indeed, it is. Also, do take note of the expressiveness, scalability, and maintainability it offers. This makes it a highly viable option for building robust and flexible governance systems.
Developer: Ok. Hm, but Prolog rules are executed by an interpreter, essentially an execution container with limited interaction capabilities with the outside world — in this case, the blockchain. How would we access and express the sources of truth in Prolog?
Me: It’s straightforward. We boost Prolog with chain-specific predicates that enable access to these sources of truth, like the blockchain State or Knowledge. Let me show you: bankBalances/2 is a chain-specific predicate which unifies an account with the list of balances (coins). Hence:
bank_balances('okp41ffd5wx65l407yvm478cxzlgygw07h79sq0m3fm', X).results in X = [uknow-23495024449245]. Looks like I’m quite wealthy.
Developer: That sounds promising. But security seems like a potential concern. Allowing Prolog programs to run on the blockchain could pose a risk.
Me: Absolutely, security is paramount. Initially, we aim to support only a subset of the ISO standard of Prolog. Additionally, as a blockchain developer, you’re aware that determinism is crucial. Yet, certain Prolog predicates, like get_time/1 — which returns the current date, are non-deterministic. To tackle this, we restrict the availability of predicates by specifying a list of allowed or forbidden predicates.
Developer: I see, and I suppose these restrictions are set by the Governance Protocol.
Me: Absolutely. Additionally, since the Prolog programs run inside a controlled container, with strict management of the predicates executed and limited interaction with the outside world, the security is significantly enhanced. This level of control over what gets executed and how it interacts with external systems provides a robust defense against security threats.
Developer: What about the cost of execution? How do we prevent a Prolog program from running too long?
Me: Both of these concerns can be addressed with the concept of Gas, already existing in Cosmos blockchains. Each predicate defines the amount of gas its execution requires, and the execution of a Prolog program is constrained by the maximum amount of gas that can be consumed.
Developer: Fascinating. But hold on… is it feasible to implement a Prolog interpreter within the blockchain?
Me: Indeed, it’s entirely possible. In fact, we at OKP4, have already done it (https://github.com/okp4/okp4d)!
Developer: Awesome!
Me: And the current integration takes the form of a Cosmos module based on an open-source (https://github.com/ichiban/prolog) implementation of Prolog.
Developer: A module? So, it’s not a Smart Contract?
Me: Not yet. But soon. Ready to take the plunge? As it currently stands, the OKP4 protocol deploys a logic interpretation engine via a Smart Contract known as Law Stone, which operates on the logic module. Want to know more?
Developer: Sure.
Thank you for reading this article! I hope you found it useful. See you soon for our 3rd and final article on Governance!
In this next article, I will delve more concretely into the different building blocks that shape the on-chain governance implementation, unveiling the architectural and technical specifics of the OKP4 protocol.
