OKP4 Blockchain

OKP4 blockchain enables a new generation of hybrid on & off-chain applications. It is a sector-specific blockchain designed for digital assets sharing & coordination (datasets, algorithms, storage, computation...).

OKP4:

• Is a Proof of Stake chain based on the cosmos SDK, using the battle-tested Tendermint algorithm
• Is operated by a network of independant validators and the KNOW token
• Is designed at its core (blockchain modules) to be optimized for digital assets sharing & coordination
• Is designed for interchain applications leveraging on-chain resources from other ecosystems
• Enables CosmWasm smart contracts to define Data Space governance rules and optimal interest aligment between participants
• Is governed by its community of token holders
• Provides permissionless freedom and opportunites for builders to build, providers to share, users to benefit and communities to coordinate themselves for knowledge creation

Consensus: Tendermint

In this section we briefly describe the Tendermint consensus protocol.

Validators

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.

Consensus

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.

Light Clients

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).

Preventing Attacks

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

Canonical Services

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

The 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

The 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

The 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.

CosmWasm smart contracts

wasm is a module provided by the CosmWasm project, which enables the OKP4 Blockchain to become of vibrant smart contract hub and provide many opportunities for governance innovation.

CosmWasm is the best solution to build interchain protocols - it is the future of smart contracts. Using existing languages like Rust and Go, it is easy for developers to build highly secure and extensible contracts and use many existing libraries known by most builders across the world.

Moreover, it is IBC-ready, designed to benefit from the interchain world and the many opportunites provided by other blockchains.

It also enables builders to design and mint custom tokens, used for Data Space governance for instance, thanks to CosmWasm Tokens and CosmWasm Plus repositories, which are collections of contracts within CosmWasm virtual machine.

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 tokens.

• cw20-staking: A smart contract (compliant with cw20 specification) that provides staking derivatives.

• cw20-streams: A smart contract (compliant with cw20 specification) allowing a cw20 payment to be vested continuously over time.

• cw20-bonding: A smart contract (compliant with cw20 specification) that demonstrate extensibility of cw20-base contract by adding bonding curves functions.

• 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 cw3 multisigs.

• cw721-base: A smart contract (compliant with cw721 specification) for managing Non-fungible tokens (NFT).

Oracles

Similar to the Terra blockchain and its Oracle module, the Oracle module provides the OKP4 Blockchain with an up-to-date and accurate price feed of exchange rates of $KNOW against other currencies.

Some other Oracles networks may be used in the future for enhanced functionalities (e.g. Chainlink, Band...).

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.

OKP4 Services

Overview

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:

	Cosmos SDK	CosmWasm
Speed of Development	+	- (Rust)
Customization	+	-
Performance	+	~
Strict Resource Control	-	+
Ease of maintenance	-	+
Modularity	-	+

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.

Data Space

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.

Rule

The smart contract rule ensures strict compliance with the governance rules established for each Data Space and extensively for the entire Dataverse.

Exec

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.

Pay

The smart contract pay is responsible for maintaining a policy of paying for data and services defined by the governance rules.

Logic

The module logic introduces into the blockchain an "engine" that is powerful enough to interpret and guarantee the correct execution of the Data Spaces' governance rules.

Governance

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.

Proposal Pool

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.

Voting Parameters

• 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

Initial Parameters

Bloc time: 6.5s

Block reward: For more details click here

Token release: daily

Slashing:

• 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

OKP4 Ontology

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.

tip

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 knowledge representation language chosen for the OKP4 is RDF Schema and Web Ontology Language on top of the framework Resource Description Framework.

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:

data-metadata.ttl

@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#> .

<https://ontology.okp4.com/world/0cc88f43-849a-41ce-bdee-0ba45907f456>
  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> .

Concerns

Work in progress