In this section we briefly describe the Tendermint consensus protocol.
In classical Byzantine Fault-Tolerant (BFT) algorithms, each node has the same weight. In Tendermint, nodes have an amount of voting power, and are called Validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block. According to our model, the voting power of each validator is determined by the amount of staking tokens bonded as collateral.
Tendermint is notable for its simplicity, performance, and fork-accountability (the processes that caused the consensus to fail can be identified and punished according to the rules). The Protocol requires a fixed known set of Validators, where each Validator is identified by their public key. Validators attempt to come to consensus on one block at a time, where a block is a list of transactions. Voting for consensus on a block proceeds in rounds. Each round has a round-leader, or proposer, who proposes a block. The Validators then vote, in stages, on whether to accept the proposed block or move on to the next round. The proposer for a round is chosen deterministically from the ordered list of Validators, in proportion to their voting power. Tendermint's security derives from its use of optimal Byzantine fault-tolerance via super-majority (>2/3) voting power and a locking mechanism. Together, they ensure that:
- ≥1/3 voting power must be Byzantine to cause a violation of safety, where more than two values are committed
- If any set of validators ever succeeds in violating safety, or even attempts to do so, they can be identified by the protocol. This includes both voting for conflicting blocks and broadcasting unjustified votes
Despite its strong guarantees, Tendermint provides exceptional performance by providing thousands transactions per second, with commit latencies on the order of 1 to 2 seconds. Notably, performance of well over a thousand transactions per second is maintained even in harsh adversarial conditions, with Validators crashing or broadcasting maliciously crafted votes.
The need to sync all block headers is eliminated in Tendermint PoS as the existence of an alternative chain (a fork) means ≥1/3 of bonded stake can be slashed. Of course, since slashing requires that someone share evidence of a fork, light clients should store any block-hash commits that it sees. Tendermint light clients need only to keep up with changes to the validator set, and then verify the >2/3 PreCommits in the latest block to determine the latest state and avoid long range attacks. Succinct light client proofs also enable IBC (Inter-Blockchain Communication).
Tendermint has protective measures for preventing certain notable attacks, like long-range-nothing-at-stake double spends and censorship.
ABCI (Application BlockChain Interface)
Tendermint consensus algorithm is implemented in a program called Tendermint Core. Tendermint BFT connects to blockchain applications via the ABCI. ABCI in an interface that defines the boundary between the replication engine (the blockchain), and the state machine (the application). By using a socket protocol, we enable a consensus engine running in one process to manage an application state running in another.
For more informations: https://docs.tendermint.com/master/introduction/what-is-tendermint.html
A large number of blockchains in the Cosmos Ecosystem share a common set of services, either because they are provided by layer 0 of the Cosmos SDK or because they are standard in the Ecosystem.
This section lists the main services that are available in the OKP4 Blockchain.
From the Cosmos SDK
The OKP4 Blockchain is based on the Cosmos SDK layer 0 and, as such, comes with a set of functionalities any blockchain application needs. These functionalities are grouped into modules, each module being responsible for a well-defined functional scope.
The list of integrated modules available in the OKP4 blockchain can be found in the Cosmos SDK documentation. The main ones are briefly described hereafter.
bank module is responsible for handling multi-asset coin transfers between accounts and tracking special-case pseudo-transfers which must work differently with particular kinds of accounts.
staking module enables the OKP4 Blockchain to support an advanced Proof-of-Stake (PoS) system where holders of $KNOWs can become Validators or delegate tokens to Validators.
governance module enables the OKP4 Blockchain to establish a governance on-chain. In this system, holders of $KNOWs can vote on proposals on a 1 token 1 vote basis.
From the Cosmos Ecosystem
wasm is a module plugable into the Cosmos SDK, provided by the CosmWasm project, that enables the OKP4 Blockchain to provide a smart contracting platform through which the functionalities of the OKP4 Blockchain is implemented, operated.
In the context of the OKP4 Blockchain, the following smart contracts (and/or specifications) are considered (non-exhaustive and subject to evolve):
cw20-base: A smart contract (compliant with cw20 specification) implementing a standard API for tokens, with the following functionalities: transfer tokens from one account to another, get the current token balance of an account, get the total supply of the token available on the network...
cw20-atomic-swap: A smart contract (compliant with cw20 specification) implementing atomic swaps for both native and
cw20-staking: A smart contract (compliant with cw20 specification) that provides staking derivatives.
cw20-streams: A smart contract (compliant with cw20 specification) allowing a
cw20payment to be vested continuously over time.
cw3-multisig: A smart contract (compliant with cw3 specification) for multisig/voting.
cw4-group: A smart contract (compliant with cw4 specification) for storing group membership, which can be combined with
cw721-base: A smart contract (compliant with cw721 specification) for managing Non-fungible tokens (NFT).
Inter-blockchain communication (IBC)
The Inter-Blockchain Communication protocol (IBC) is an end-to-end, connection-oriented, stateful protocol for reliable, ordered, and authenticated communication between heterogeneous blockchains arranged in an unknown and dynamic topology.
OKP4 aims to be one of the first to leverage IBC to enable interchain applications. Imagine a Stargaze community using their NFT as a governance token for a Community-powered Data Space leveraging resources provided by Akash and verifiable identity credentials through Cheqd...
OKP4 will also integrate the coming upgrades such as Interchain Accounts (ICA). ICA allows one blockchain to securely control an account on another blockchain, using IBC. Thanks to such revolutionary upgrades, OKP4 aims to be the chain enabling powerful synergies in the Cosmos Ecosystem, leveraging resources provided by all the ever-expanding IBC-compatible chains.
The functionalities of the OKP4 Blockchain are divided by nature according to their responsibility and functional scope.
The following diagram shows the different specific parts of the OKP4 Blockchain, which are detailed in the following sections.loading...
The question of implementation
A choice arises as to how services are implemented in the OKP4 Blockchain. There are two choices:
- Use a module, a powerful extension mechanism provided by the Cosmos SDK that allows to implement features natively in the blockchain.
- Use a (stateful) Smart Contract, an extension mechanism offered by a Virtual Machine capable of interpreting an assembly-like language in the blockchain. For this, CosmWasm is the option.
The following table compares the two approaches according to different criteria:
|Speed of Development||+||- (Rust)|
|Strict Resource Control||-||+|
|Ease of maintenance||-||+|
For the OKP4 Blockchain, we consider a Smart Contract (CosmWasm) implementation strategy by default, and for specific cases, a native implementation per module in the blockchain.
The smart contract
Data Space is in charge of managing the Data Spaces. The smart contract manages the entire life cycle of a Data Space, from its creation to its destruction.
The smart contract is a factory in such a way that at each new instance, a new Data Space is created in the blockchain.
The smart contract
rule ensures strict compliance with the governance rules established for each Data Space and extensively for the entire Dataverse.
The smart contract
exec is in charge of "orchestrating" the execution of the different services.
The smart contract does not interact directly with the services, but maintains in the blockchain an order book of the different executions to be carried out, as well as the history of all the executions to form a knowledge graph of all processes.
The smart contract
pay is responsible for maintaining a policy of paying for data and services defined by the governance rules.
logic introduces into the blockchain an "engine" that is powerful enough to interpret and guarantee the correct execution of the Data Spaces' governance rules.
OKP4 blockchain governance needs to be operated by the community in a decentralized way. The governance space has seen rapid and drastic changes in recent years with the emergence of DAOs (Decentralized Autonomous Organizations). OKP4 DAO mission is to coordinate various changes to the blockchain such as software upgrades, treasury management and constitutional amendments. The Protocol's operating rules allow for cohesion between stakeholders on all types of issues such as theft, bugs, management, etc., allowing for faster and cleaner resolution or management.
Validators and any staked $KNOW holders are eligible to vote on all governance proposals that may change predefined system parameters, vote on changes to the rules that govern DAO policies, coordinate upgrades, propose improvements, extensions or changes for the Protocol. In addition, all validators are encouraged for voting on all proposals.
If the validator does not vote on a proposal within the time limit, he/she will be automatically disabled for a period of time (1 week by default). Delegators automatically inherit the vote of the delegated Validator. This vote can be changed manually.
Each Data Space can also have its own rules (Rulebook) and its own governance mechanism that allows users to have freedom and potential to experiment without permissions. For more information please click here.
The DAO will have its own treasury in order to encourage development and improvements of the Protocol (grants), fund initiatives, encourage liquidity providing, provide insurance to users...
In order to discuss and work on the proposals, a forum & communication channels will be made available. Once propositions are sufficiently constructed and the required $KNOW amount has been deposited, they will be submitted to a vote.
The rules are written in the Governance section of the Token model, click here.
In order to offer the possibility to anyone to make a voting proposal, we introduce the concept of proposal pool. If someone has a proposal to make but does not have enough tokens to launch the proposal alone, it is possible to launch a proposal pool. Over a given period of time (before the voting period), anyone who thinks the proposal is a good idea and deserves to be voted on can come and deposit $KNOW in this pool. If the amount of $KNOW tokens is reached before the end of the period, the proposal passes as a classic proposal and is governed by classic rules; if the period is exceeded and the total amount is not met, the contributors are refunded.
- Minimum deposit: 600 $KNOW. Subject to change depending on the price of the token and the choices of the DAO
- Maximum deposit period: 14 days. After this period, if the minimum deposit is not reached, the proposal is rejected
- Voting period: 5 days
- Quorum: 30%. Minimum participation depending on the number of tokens staked by Validators
- Threshold: 50%. Validating majority
- Veto threshold: 33%. Option in the vote to reduce the threshold
Bloc time: 6.5s
Block reward: For more details click here
Token release: daily
- Signed block window: 20,000
- Minimum signed per window: 5%
- Downtime jail duration: 600s
- Slash fraction doublesign: 5%
- Slash fraction downtime: 0.01%
Unbounding time: 14 days
A formal model of the information
Ontology is the most general and fundamental concept of the Semantic Web. Ontologies are linked to various data elements representing conceptualized information about these data items. This allows for unambiguous identification, understanding, navigation and usage of this information.
The fundamental objective of an ontology is to specify and share meaning, while the fundamental objective of a schema is to describe data.
Ontologies can be used for a wider range of purpose, such interoperability, knowledge modeling.
OKP4 uses an ontology to describe and define the different forms of vocabularies used in the Protocol in a standard format. The aim is to model a semantic network of all the entities (Data Spaces, data, services, processing workflows) by semantically characterizing what they are and the relationships they maintain between them.
The following diagram gives a graphical overview of the ontology currently designed.
The ontology also provides a complete living understanding and knowledge of the datasets within a Data Space, their transformation (by the services), as well as the governance rules that apply (data sharing, consents, policy rules). From that perspective, it provides the Data Lineage (allowing the traceability) of each piece of data in the Data Spaces during different processings, resulting in a Knowledge Graph of any data in the Dataverse.
Ontology is at the heart of the blockchain
Ontology has a special place in the OKP4 Protocol as much of the information is encoded and stored as an ontology on-chain in the blockchain transactions. Therefore, the blockchain is the only source of truth and any dApp can consult the semantic information that has been added, modified or deleted in the system.
For example, the creation of a new Data Space requires a metadata profile that describes and characterizes the Data Space created. This creation is performed by a blockchain transaction containing the encoded RDF description conforming to the formal model:
@prefix : <https://ontology.okp4.space/core/> .
@prefix exif-system: <http://ns.exiftool.org/File/System/1.0/> .
@prefix exif-file: <http://ns.exiftool.org/File/1.0/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
rdf:type owl:NamedIndividual, :Metadata ;
exif-system:FileName "hw_25000.csv" ;
exif-system:FileSize "619 KiB" ;
exif-system:FileModifyDate "2021:09:24 20:29:15+02:00" ;
exif-file:FileType "CSV" ;
exif-file:FileTypeExtension "csv" ;
exif-file:MIMEType "text/csv" ;
exif-file:MIMEEncoding "us-ascii" ;
:describes <https://ontology.okp4.com/world/5d792b01-6e7a-4837-80ad-a8516c184bae> .
Work in progress