What is OKC?
An in-depth look at the decentralized blockchain protocol created by OKX
Table of Contents
- OKC’s operation process and its role in the ecosystem
- OKC disclaimer
- Conclusion — OKC summary
OKC, previously known as OKExChain, is open-source, public blockchain technology developed by OKX for building blockchain-based trading applications. It is designed to establish a safe and efficient decentralized-finance architecture that can be used to create a decentralized exchange, or DEX, that features community-based operations, transparent trading rules and allows the users to control their own assets.
We know that, in the blockchain world, cross-chain technology is a key link in realizing interaction between assets and data, and is the technological base for DeFi. As the name implies, cross-chain means the realization of asset transfer, information exchange and application collaboration between different blockchain platforms. Acting much like a bridge that connects different public chains, cross-chain technology helps realize data transmission between different blockchain networks while, at the same time, greatly reducing the transmission costs. It is simple and effective to use the cross-chain module to achieve value, user and scenario application-based interconnection among blockchains — which lays the foundation for jointly building a shared ecosystem and value-added system.
Considering the above, the team used Cosmos SDK and Tendermint to construct OKC. Cosmos introduces an Inter-Blockchain Communication, or IBC, protocol that — together with the Tendermint consensus algorithm, featuring instant finality — can be used to realize value transmission between blockchains. In the future, we will be able to use Cosmos to solve issues regarding the multi-directional circulation of value by adding support for heterogeneous cross-chaining.
Cosmos is a network composed of many independent and parallel blockchains that are inter-connected by nodes.
Within Cosmos, all consensus layers adopt Tendermint, a consensus engine that supports Byzantine-fault tolerance and boasts high efficiency, high performance, consistency and other characteristics.
Cosmos network is mainly composed of two parts:
Each Zone and Hub is an independent blockchain with independent state consensus. Zones are used to solve specific application needs, and Hubs are designed specifically to handle cross-chain transactions between Zones — much like a central bank handling the settlement between banks. Cross-chain value transfer is achieved by realizing intercommunication and interoperation between different Zones and their shared Hub, which are based on the IBC protocol for cross-chain communication.
It’s the aim of Cosmos to realize simplified blockchain development and achieve interconnection between blockchains. The key to the former lies in the Tendermint consensus algorithm, while that to the latter lies in its cross-chain mechanism.
Tendermint contains two main technical components:
- Tendermint Core, which is the blockchain consensus engine.
- ABCI, which is the general API.
Tendermint Core is used to realize Byzantine consensus and the data transmission between nodes. By using the consensus algorithm combining Byzantine-fault tolerance and delegated proof of stake, it can achieve ultimate finality in block generation — which means that the transaction has been written into the block, added to the blockchain and cannot be reversed or tampered with thereafter — ensure that each node records the same transaction in the same order and pave the way for extremely fast transaction confirmations and high throughput. In general, Tendermint Core is mainly used to construct the network layer and consensus layer of the blockchain in a way that allows the developer to personalize the blockchain without worrying about the realization of consensus and network transmission.
ABCI is a blockchain API and a protocol that supports the implementation of transaction processing in any programming language. For developers, the only thing they need to do when conducting blockchain development based on the Cosmos framework is to write applications that are compatible with the ABCI interface.
In order to further reduce the complexity of blockchain development on top of Tendermint Core and ABCI, Cosmos has introduced the Cosmos SDK, a tool that is based on the standardization of some common blockchain modules. Cosmos SDK can be deemed a “chain-making tool” of Cosmos, as it makes blockchain design within the network as simple as adding modules — such as governance, staking and pledge — which, coupled with the innate interoperability between blockchains created with it, serves to greatly reduce the complexity of blockchain project development.
Depending on whether the related blockchains are based on different technology platforms, the cross-chain mechanism can be either homogeneous cross-chain or heterogeneous cross-chain. The former refers to the interaction between blockchains with the same underlying structure in terms of the encryption algorithm, address, account algorithm rules, etc. One example is trading Ethereum-based tokens. Although we have seen relatively mature applications of a homogeneous cross-chain in many projects, it remains powerless in solving issues preventing the interaction between mainstream assets — such as Bitcoin (BTC), Ether (ETH) and Tether (USDT) — with the greatest consensus.
Homogeneous cross-chain, which realizes value locking and value exchange between blockchains with different chain structures, provides the answer to the problem of multi-directional circulation of value. Cosmos, which adopts a relay-based multi-chain and multi-layer architecture, will support cross-chain asset interaction.
In order to support cross-chain interoperation between parallel chains, Cosmos introduces the Inter-Blockchain Communication protocol and the Tendermint consensus algorithm — featuring instant ultimate finality — to realize value and data transmission between multiple heterogeneous chains. All parallel chains are connected to the Hub through IBC, and the Hub acts as the relay chain to assist the verification and transfer of cross-chain transactions.
Specifically, the Hub helps each Zone synchronously record the status of each other Zone — and the object of this function is the block headers of other Zones. When Zone 1 sends a cross-chain message to Zone 2, all of its information is packed into a data packet that is stored in its block header. The Hub waits for Zone 1 to reach a consensus regarding the block containing the information and then transfers the information stored in the block header of Zone 1 to a new block. After the Hub completes the block consensus, Zone 2 will receive the verification message broadcasted by the Hub, which involves the block header of Zone 1. After that, Zone 2 must verify whether the proof regarding Zone 1 is true. If it is true, Zone 2 will start to perform related operations and send feedback to the Hub about the related block.
Let’s use the transfer of 10 OKTs from OKC to Cosmos as an example to illustrate cross-chain interaction based on IBC:
- 1. To perform cross-chain transactions between OKC and Cosmos, chains at both ends need to run each other’s light blockchain node services.
- a. In this way, the block header information of the other party can be received in real time, which is convenient for subsequent execution of Simple Payment Verification-like confirmation, in which SPV nodes verify the existence of the transaction by requesting proof of the Merkle path and verifying the proof of work in the blockchain.
- 2. The OKC chain initializes the IBC protocol and freezes the related assets — 10 OKTs, in this example — after which it generates the corresponding proof and sends it to the Cosmos Hub blockchain.
- 3. After receiving the corresponding message, the Cosmos Hub chain confirms that OKC has indeed frozen the corresponding assets by checking the block header information of the OKC chain before generating an asset of equivalent value — again, 10 OKTs, in our example.
- 4. The 10 OKTs are transferred from OKC to Cosmos.
Ethereum Virtual Machine compatibility
Ethereum Virtual Machine support provides an environment for smart contracts to run and interact with other contracts. Smart contracts on Ethereum are coded in the programming language Solidity and then converted into EVM bytecode, a computer-readable code for Ethereum Virtual Machine. Since the EVM isolates code input and execution functions from the Ethereum blockchain, other blockchains can also run Ethereum DApps — as long as they have EVM compatibility.
OKC is the first Cosmos-based architecture to adopt EVM compatibility. This means that developers can now migrate their Ethereum DApps to OKC without having to write entirely new code — which ultimately facilitates a cross-chain-friendly ecosystem.
The migration of Ethereum DApps to OKC is beneficial to both developers and end-users. Let’s imagine, for instance, that a lending protocol is migrated to OKC through the use of the Ethereum Virtual Machine. To offer a smooth migration experience, the OKC team offers technical guidance to developers on how to migrate their existing codebase, so they can bootstrap their operations on OKC more efficiently. Developers can refer to the OKC technical document to learn about the configuration of EVM compatibility on OKC.
The OKC team has also introduced EVM-compatible wallet addresses to its users. Now, each OKC user will have two wallet addresses: a native OKC wallet address and an EVM-compatible wallet address. EVM addresses start with “0x” and OKC’s native wallet addresses start with “ex.”
The introduction of EVM-compatible wallet addresses allows users to track their OKC assets more easily. In the example of a lending protocol, the wallet providers on OKC enable users to track their lending balances in their “0x” addresses. Additionally, users can use the OKLink blockchain explorer to track their OKC transaction activity.
OKT is the native token issued on the main network of OKC. All tokens contained in the OKC genesis block are allocated to OKB holders in proportion to their OKB holdings. OKT is the carrier of value for the OKC ecosystem, and its value determines the development prospects of DEX, DeFi and other applications on OKC.
OKT adopted an initial minting of 10 million in its genesis block. The initial OKT supply was distributed to OKB holders who staked their OKB in OKX Jumpstart. OKT also applies a reward-halving model — the block reward is halved roughly every three years. The current block reward is 0.5 OKT, and the theoretical maximum supply of OKT is about 41.69 million.
Use of system resources
A program running on the OKC network requires OKC to allocate certain network resources — such as computation, storage, bandwidth, etc. — according to its operational needs. OKC charges transaction fees for any resource usage.
In order to avoid malicious behaviors, it’s required to pledge a certain amount of OKT before applying for a node to become a validator/proxy node, submitting a chain governance proposal or executing an order pending operation.
Users who hold a certain amount of OKT can issue new tokens on the OKC network, which can be freely traded on OpenDEX once the relevant proposal application and activation are completed through digital asset trading pairs. Each of the relevant operations — token issuance and activation, additional issuance and destruction of digital asset trading pairs — would incur a corresponding handling fee that needs to be paid.
Each block only has a limited capacity and, as the volume of pending orders on OpenDEX continues to rise, the number of transactions that need to be processed by the block in a single cycle may exceed the carrying capacity of the block, resulting in the system being unable to distinguish junk token pairs from those with values. In this case, how does OpenDEX select the transactions to be processed by the block?
Match-making security is introduced to solve this problem, which means that an operator can deposit any amount of, or 0, OKT as a security for each trading pair it operates. The match-making system will give priority to trading pairs with higher securities or, if the securities are the same, select transactions according to the chronological order of submission.
The above-mentioned solution, which is based on dynamic bidding auctions, may expand OKT’s usage scenarios while also quantifying the strength of DEX operators. Suppose that the match-making capacity of each block is limited to 100 transactions, but 200 transactions are generated in a certain block generation cycle — 100 of which belong to transaction pair A and the other 100 to transaction pair B — 100 of those transactions cannot be placed in this block for processing for the duration of this cycle. In such a case, if the security provided for A is greater than that for B, the match-making system will give priority to the 100 transactions in trading pair A and, if the securities provided for both trading pairs are of the same amount, the match-making system will give priority to the first 100 transactions ranked by the chronological order of their submission.
For token holders, voting is the most important way of participating in validator elections and on-chain governance. Holders obtain voting rights by pledging their tokens, with 1 OKT corresponding to one vote that may be used in an election with up to 30 nodes.
During the block-production process, the validators are elected by calculating their voting weights — which are determined by the vote of holders or their proxies.
In on-chain governance, decisions on proposals are also made by validators through voting.
OKC adopts the consensus algorithm of Tendermint (BFT-DPOS), and there are six basic steps to create a block:
- Become a full node.
- Register as a candidate node.
- Vote to elect a validator.
- Select a block generation node.
- Make a proposal.
- Generate a new block after reaching Tendermint consensus.
Before becoming a block producer, a token holder needs to first become a full node in the distributed blockchain network by running a node client. To participate in the validator election, a full node needs to register as a candidate after pledging a certain number of tokens for the purpose. The nodes ranked in the top 21 in the election become the validators in the next cycle. After the election, the system will calculate the corresponding voting weights based on the votes obtained by the 21 nodes and select the block generation nodes from them by running a random algorithm with such weights. These selected nodes will then produce blocks according to the Tendermint consensus protocol.
Block generation based on the Tendermint consensus mechanism requires two stages of voting:
A selected block producer will monitor and collect all transactions in the entire network, then assemble a new block (i.e., the proposal block) within a certain period of time and broadcast it to the entire network.
After receiving the broadcast about the proposal block, all validators will read all transactions in the block and verify them. If there is no problem, a pre-vote message will be broadcast to all validators. The second stage (pre-commit) will commence if votes approving the proposal block account for more than two-thirds of all votes received. If pre-commit votes approving the proposal block account for more than two-thirds of all votes received, the proposal block will be written to the local blockchain and the new block is created with ultimate finality.
After a new block is generated, the system will enter the next round of block generation.
If a current proposal block goes offline, due to poor connection and other reasons, the block producer may fail to submit a block — in which case, the protocol will choose the next validator to become the block producer and propose a new block at the same height and restart the voting process.
Additionally, Tendermint introduces a locking mechanism — which means that, once a validator pre-commits a block, it is “locked” to that block and it must also pre-vote for that block. Only if a block is not successfully submitted in the previous round of pre-proposal and pre-vote can the corresponding validator be unlocked from it and participate in the next round of pre-commit for a new block. Assuming that less than one-third of validators are Byzantine nodes, Tendermint guarantees that validators will never repeatedly submit blocks at the same height, which may lead to conflicts.
For token holders, voting is the most important way of participating in validator elections and on-chain governance.
A validator election is determined by votes from token holders or proxy nodes, and each voter can vote for up to 30 nodes. All nodes that receive a vote are sorted by voting weight from highest to lowest, and the top 21 nodes will be selected by the system to become validators. The remaining nodes will become standby (candidate) nodes. The validator election is a periodic event, meaning a new election will take place at the beginning of a new cycle.
If token holders or proxy nodes didn’t participate in the voting for on-chain governance, validators they’ve chosen can directly inherit their voting rights and vote on relevant proposals — but the token holders or proxy nodes still have the right to change the votes afterward.
The voting weight coefficient is calculated by dividing the difference from the starting time to voting time by the total number of seconds in 364 days, which will increase with the increase in said difference.
The voting weight is the pledge amount multiplied by the Xth power of 2 and the “X” equals the weight coefficient.
We can see that the voting weight coefficient increases when the deposit security increases as well as when the difference from starting time to voting time decreases. To a certain extent, users are encouraged by said calculation method to provide larger deposits and continue to participate in voting.
- In the formula, “Weight” is the voting weight coefficient, which changes with time (i.e., the greater the difference from starting time to voting time, the greater the weight coefficient).
- now_timestamp is the timestamp for the current vote.
- start_timestamp is the starting timestamp, which is 946684800 (00:00:00 UTC on Jan. 1, 2000).
- seconds_per_day is the number of seconds per day — i.e., 60*60*24.
- weeks_per_year is the number of weeks per year — i.e., 52.
- “Shares” is the calculated voting weight.
- delegated_Tokens is the amount of pledged OKT.
The validator election is decided by the voting of OKT holders, who can either vote directly or by proxy. To register as a voting proxy, users need to deposit a certain number of OKTs in their pledge account. If a proxy chooses to withdraw from the locked voting, it can’t withdraw the pledged token until the 14-day lock-up period expires.
In terms of fund security, because the user does not need to hand over any key and the proxy account only obtains the voting rights with respect to the token, the whole delegation is an on-chain process that has no effect on the actual ownership of the token — which still remains in the user’s personal address. However, when users change the number of tokens pledged for the proxy, all their voting weights will also be updated accordingly.
In view of the fact that rewards and punishments of a validator will also affect any proxy who voted for it, proxies should use browsers on OKLink or other OKC blocks to learn about validators and conduct detailed investigations and screenings before voting. After voting, the proxy also needs to continuously observe the operation of the validator to ensure that it acts correctly — such as ensuring uptime, not double signing or becoming compromised, and participating in governance. If there is any warning sign, the proxy can quickly unbind the vote or switch the vote to another validator with immediate effect.
OKC relies on a set of validators to maintain network security, each of which is a full node that participates in the consensus through voting by broadcast. To become a validator, the node must meet certain requirements proposed by the system, including a security deposit in tokens, as well as meet the requirements for hardware and software configurations.
The following is a list of the validators’ responsibilities:
- Validators must avoid double signatures. Once a double signature is found in the test network, an automatic penalty will be executed immediately.
- Validators must be able to continuously run the correct version of the software. Proposers need to ensure that their servers are always online and their private keys are not compromised.
- Validators must keep their node versions actively updated to increase security.
- Validators must keep an eye on hardware requirements when the system is updated and keep hardware updated to meet the requirements.
- Validators must protect against DDoS attacks when they occur.
- Validators must actively participate in governance. Proposers are required to vote on each proposal.
To become a validator, the node must be connected to the OKC network and have a security deposit of 10,000 OKTs.
OKC’s minimum system requirements are:
- Desktop or laptop hardware running recent versions of MacOS, Windows or Linux.
- 500 GB of free disk space, accessible at a minimum read/write speed of 100 MB/s.
- Four cores of CPU and 8 gigabytes of memory (RAM).
- A broadband internet connection with upload/download speeds of at least 1 megabyte per second.
As you can see, at the beginning of the project, the node configuration requirements seem average at best — but, over time, the hardware requirements will be elevated with the increase in network usage. Compared with other blockchains, such as Ethereum or Bitcoin, the OKC network has much higher throughput and, thus, requires higher bandwidth to maintain smooth communication between various nodes. Additionally, as the size of the block data will increase and the block-generation node needs to have enough hard-disk capacity to store complete block data, there is also the need to expand the hard-disk capacity of a node whenever necessary.
The currently available servers are mainly divided into two types:
- Self-built server: A server that is purchased, assembled and connected to a relevant network by oneself. This type of server entails relatively high upfront costs, including hardware costs, site costs and operating costs, and also high-impact requirements (around-the-clock power supply and network connection). The advantage of a self-built server is that it allows direct adjustments to certain service supports.
- Cloud server: A ready-made cloud server that runs related services through it after completing corresponding dynamic parameter configuration. The advantages of cloud servers include flexibility and low cost. At present, most of the existing nodes use cloud servers — such as Amazon’s AWS, Google’s cloud services, Alibaba Cloud, etc. — due to the aforesaid advantages. All you need to do after purchasing a cloud service is to configure it in accordance with the official tutorial. Of course, this node configuration method has long been criticized in the decentralization community because it means handing over control of the node services of the decentralized networks to the centralized IT giants providing said services.
The validator server’s data center should be equipped with redundant power supplies, connectivity and storage backup facilities. Other than several redundant network boxes for fiber optic connection, firewall operations and switching, validators are also expected to have small servers with redundant hard drives and failover functions. The relevant hardware can be placed at the bottom of the data center.
It is best for OKC nodes to have complete monitoring, warning and management solutions against attacks and interruptions so that they can maintain the security and isolation of their data centers and thereby avoid accidental unbinding or events that trigger system punishments.
The economic-incentive mechanism designed for bookkeeping nodes is an indispensable and important part of any blockchain project. The rewards for BTC accounting nodes (miners) include block-generation rewards and transaction fees. Since OKTs generated by the OKC genesis block are distributed to OKB investors in a 1:1 ratio, where do the rewards for miners come from?
Such rewards mainly come from two sources:
- The first source is the 1% annual additional issuance by the system (which will be proportionally distributed to each block), 25% of which will be deemed as generation rewards and distributed among 21 validators according to their voting weights.
- The remaining 75% will be distributed to all candidate nodes according to the voting ratio. This method helps to avoid inaction of generation nodes, because they can still get voting rewards by acting as the candidate nodes after failing to obtain block generation rewards.
Another source is the handling fee, which is allocated only to 21 validators, according to their voting weights. There are two types of handling fees — namely, the system handling fee and business handling fee. The former is the gas fee and the latter includes handling fees incurred from the issuing of token–currency pairs by operators, activation of digital asset transaction pairs and additional issuances, among other things.
The token security provided by the node can also be regarded as a security deposit for verification activities. A node may lose the qualification to produce blocks if it is inactive or has any improper or malicious action during block production, whether advertently or inadvertently, due to attacks.
The specific penalty rules are as follows:
- Not participating in the block’s verification signature will result in a ban for 10 minutes — that is, the node cannot participate in block generation in the next 10 minutes.
- Double signing — that is, signing two blocks of different chains at the same height — will result in the node being permanently disqualified for block production.
In addition to creating new blocks, validators must also participate in on-chain governance.
If the creation of new blocks is to ensure the continuity of the blockchain, on-chain governance determines the parameter settings of the entire system — which, in turn, determines the developmental direction of the entire network.
OKC’s on-chain governance mainly involves four aspects:
- Brainstorming on a given topic.
- Changing system parameters.
- Deleting trading pairs in DEX.
- Supporting network upgrades.
To prevent meaningless and malicious proposals, each governance proposal must be accompanied by a security deposit of at least 100 OKTs, and the amount of the deposit determines the weight of the proposal. Each proposal meeting the aforementioned requirements will enter a two-week voting period. At the end of the voting period, the proposal is passed if affirmative votes, excluding abstentions, account for 50% of total votes and negative votes, excluding abstentions, account for less than 33.33% of total votes.
Although OKX engineers were major contributors to OKC’s design, the protocol is both decentralized and permissionless. As such, no single network participant — OKX included — can prevent any other user from interacting with or deploying smart contracts to OKC. The existence of any decentralized application on OKC does not constitute an OKX endorsement of said DApp’s reliability or security.
Most DApps are deployed with good intentions. However, in a highly experimented sector, even well-meaning developers make mistakes or may not account for every eventuality. Meanwhile, some DApps may contain malicious code intended to defraud their users. In either case, loss of funds resulting from the use of DApps is irreversible. Like other blockchain ecosystems, it is crucial that all OKC users do thorough research into a DApp before committing funds or granting any permissions to it.
Similarly, OKX is powerless to assist in the recovery of any missing funds resulting from the loss or compromise of your wallet’s private key. As is the case with all decentralized, permissionless blockchain networks, you must take full responsibility for your own private key. OKX will never request your private key, and you should never share it with anyone — including DApp team members.
If you receive a request for your private key via email, direct message, pop-up or similar, you should ignore it regardless of any technical issues you may be currently experiencing or how compelling any benefits mentioned may seem. You can also report efforts to impersonate entities like OKX or DApp teams via their official channels so that they may alert other users to threats.
OKC is a set of open-source public chains developed by OKX for blockchain applications. It is designed to establish a safe and efficient DeFi architecture that can be used to create a decentralized exchange that features community-based operations and transparent trading rules, and allows the users to control their own assets.
The team used Cosmos SDK and Tendermint to construct OKC. The Inter-Blockchain Communication protocol, together with Tendermint consensus algorithm featuring instant finality, can be used to realize value transmission between blockchains. In the future, we will be able to use Cosmos to solve issues regarding the multidirectional circulation of value by adding support for heterogeneous cross-chaining.
As an open decentralized exchange based on the OKC ecosystem, OpenDEX overcomes not only several major pain points faced by centralized transactions — such as the risks of information leakage, fund embezzlement, theft and network crash, and the limited number of trading pairs — but also the problem of insufficient liquidity faced by other existing DEXs through the introduction of DEX operators.
Author: Zhang Xiuxiu
Instructors: Fan Haiyang, Xu Qian, Meng Xiangjian
- OKC GitHub
- Introduction and Practical Analysis of Tendermint
- OKX Research Report: Staking Economy, a New Mining Ecosystem Based on PoS Consensus (Chinese language)
- Analysis and Ideas of Cross-Chain Technology (Chinese language)
- In-depth Analysis of Tendermint and How It Will Quickly Integrate Into the Cosmos Ecosystem (Chinese language)