The state of decentralization

When you hear about Incognito, you probably hear that it’s a DEX, a privacy wallet, a kind of node, or a blockchain network. And yet, Incognito is none of that and all of that at the same time.

When I think of Incognito, I see an unstoppable, decentralized, privacy-preserving infrastructure that is the foundation for all future online payment. Fortunately or unfortunately, we are not there yet, and there’s still a lot of work to be done to bring Incognito to that point. In this article, I’ll attempt to bring clarity to the current state of every part of the Incognito project infrastructure.

Incognito Network

The Incognito Network is a sharded PoS network that consists of two types of blockchains - the shards and the beacon chain. Every shard acts as an independent blockchain and the beacon synchronizes data between shard chains.

Current state of the network:

We released 1/3 of the validator slots to the community in Oct 2019. The remaining 2/3 of the slots are currently fixed (operated by the core team) to keep the network stable while development continues. Below, you can see the conditions that are required to release each aspect of the network.

Releasing fixed slots in the shards:

The fixed shard nodes will be released gradually to maintain the stability of the network, as this ensures it will only utilize “healthy” validators. There are 3 things that the team is working on to be able to achieve this goal:

  1. Node monitor (Building) - Improving node statuses with more comprehensive info so that node owners can understand whether their nodes are operating as expected or not.

  2. Slashing (Building) - Enabling the network to detect inoperative or misbehaving validators and replace them with “healthy” validators. After slashing has been active for some time, this will increase the stability of the network by employing only “healthy” validators.

  3. Dynamic committee size (Building) - Securing the network against a worst-case scenario in which the network has many inoperative validators and does not have sufficient votes to create a new block. In this scenario, the network will be able to adjust its committee size so the minimum required votes for creating a new block are lessened, in order to get the network up and running as quickly as possible.

Releasing the beacon chain:

The beacon slots can only be released when we create a protocol that de-motivates beacon validators from collusion to create malicious blocks. This is because the beacon chain is an extremely important layer responsible for the processing and verification of blocks, and the synchronization of shards.

At the moment, we are in the early stages of protocol design. One hypothesis we are exploring is using a Proof-of-Work or Proof-of-Authority protocol, since Proof-of-Stake is unlikely to be a good solution for a network holding a large amount of assets, like the public coins that are sent into the Incognito network via bridges.

Finally, prior to releasing the fixed slots, we also need to create a convenient method for validators to get updates for patches, new features, bug fixes, etc. This method will give validators the freedom to choose whether or not to accept an update, and the community will decide which update will be adopted.

Note: While not yet completely decentralized, all aspects of the Incognito blockchain are open source.

Find the network code here.

Cross-blockchain communication

To make privacy the universal default state for Bitcoin, Ethereum, and other crypto, we have to maintain bridges to every blockchain network. Below is the current status of all active bridge developments:

Bridge to Ethereum et al

This is a bridge to Ethereum and other smart-contract-based networks like BSC. Currently, there are two iterations:

ETH bridge v.1

  1. Trustless, non-custodial bridge. Funds are locked in Ethereum smart contracts. Releasing funds requires signatures from the beacon committee.

  2. The bridge has been audited by Coinspect.

  3. Shielding via mobile was implemented with a solution that requires a temporary ethereum address, which introduces a level of centralization. It’s a trade-off between decentralization and the user experience, in which a user only needs to send funds (Ether/ERC20) to a temporary address generated by Incognito’s backend service and the rest is handled by Incognito relayers. In other words, the user doesn’t need to maintain assets in the Incognito wallet or bother interacting with the Incognito vault smart contract. This solution is not ideal, and in some cases, transactions can get stuck and require core dev team intervention. As a short term solution, we’re working to make the intervention as automatic as possible, to shorten the time a user has to wait for support.

ETH bridge v.2

As a medium-term solution for the problem above, we’re also working on an iteration that will allow users to interact directly with Incognito vault smart contract for shielding. This means a user can sign a transaction to send funds to Incognito contract directly from his/her Ethereum wallet. If the transaction gets stuck for any reason (i.e., Ethereum network congestion), the funds will still be in his/her wallet, instead the Incognito team’s wallet as it was in the previous iteration. This will offer a decentralized experience to users while preserving the underlying protocol.

View the Etherum bridge code here.

Portal

This is a blockchain-agnostic bridge to Bitcoin, Monero and other chains that don’t support smart-contracts. It has multiple iterations:

Portal v.1
A custodial bridge in which the Incognito core team serves as a custodian for funds (currently live). BTC <> pBTC are backed 1:1.

Portal v.2 (Shipped)
Trustless custodianship with Incognito bond contracts (hard-coded logic right on the Incognito protocol), where anyone can become a custodian. Requires 200% collateralization in PRV to cover the value of the coins held (currently deployed in mainnet).

Portal v.3 (Shipped)
Trustless custodianship with Ethereum bond contracts. Similar functionality to Portal v.2, with the ability to use Ethereum-based assets as collateral (deployed in mainnet).

The main issue of Portal versions 2 and 3 is liquidations. If the price of collateral drops dramatically, it has to be liquidated and the user that shielded, for example, BTC, must receive back 120% of the value of their BTC in collateral tokens instead of the original BTC. Because of this, we haven’t switched the bridge from Portal v.1 to Portal versions 2 or 3, and have instead proceeded to develop Portal v.4, which solves this problem.

Portal v.4 (Building)
Trustless custodianship and more. Version 4 is a mix of Portal v.1 and the Ethereum bridge. It requires signing (multisig) by the beacon chain committee. This removes the need for collateral and eliminates the risk of liquidation for end users. A similar implementation can be found in the Ren protocol.

The code for Portal v1 is closed sourced to ensure security.
The code for Portals v2, v3 and v4 is merged here.

Which bridge am I using if I shield/unshield now?

Spring 2021

  1. If you shield/unshield ETH or ERC20, you’re using ETH bridge v.1.
  2. If you shield/unshield BTC, XMR, or other coins, you’re using Portal v.1.

May - June 2021

  1. When Privacy v.2 is released, we will switch from ETH bridge v.1 to ETH bridge v.2, which removes temporary Ethereum addresses and allows you to shield/unshield directly from your Ethereum wallet.
  2. When Portal v.4 is released, we will switch BTC, XMR, and other bridges from Portal v.1 to Portal v.4.

Summer 2021

  1. We’ll focus on a bridge to BSC in the manner of ETH bridge v.2.
  2. We’ll focus on adding more networks to Portal v.4, such as Zcash, Polkadot, and Cardano.

Applications

Applications are the third part of the privacy infrastructure. Unlike on the Ethereum network, the Incognito blockchain doesn’t have a VM to support smart-contracts, but it allows us to hardcode applications on the protocol level, which can then be executed by all validators in the network. Applications built this way are as decentralized as the Incognito protocol itself.

There are currently several privacy dApps built on Incognito: the Incognito pDEX, pUniswap, pKyber, and pCompound, among others still in development. Some of them, like pUniswap, you may have already used. Others, like pCompound, have yet to be released.

Incognito wallet

The Incognito wallet is a self-custodial wallet for the Incognito blockchain. It’s decentralized in the same way your self-custodial BTC, ETH, or XMR wallets are when supported on the appropriate networks. The Incognito wallet does not refer to the Incognito app, which contains more than the wallet. It refers to the store, send, and receive functions of the blockchain, and can be performed without the app.

See the wallet source code here.

Incognito pDEX

The pDEX is an AMM-based decentralized exchange, just like the most famous implementation of such tech - Uniswap protocol.

Every AMM DEX contains two functions: providing liquidity and executing swaps (trades).

On the Incognito blockchain, currently only transfer transaction types are private and all other transaction types, such as trade or add liquidity, are not. So, in order to guarantee privacy for pDEX trades and other transactions, temporary addresses are used to hide the identity of senders/traders. This solution suffers two issues:

  1. We must use centralized accounts managed by Incognito as temporary addresses.

  2. There are multiple transactions grouped into one function, which takes longer to complete.

Apart from the two issues mentioned above, the process also can get stuck in the middle (the more transactions involved in the process, the more potential points of failure result).

The short-term solution for failed transactions is to monitor and retry quickly as possible, by using automated processes.

For a medium-term solution, one-time address (which will be release in Privacy v.2) allows us to remove temporary addresses and results in a more decentralized process:

Currently, providing liquidity suffers the same problems, and benefits from the same solutions.

For more details about how Privacy v.2 and one-time addresses can help solve centralization, slow transaction times, and transaction failure, read here.

Explore the pDEX source code here & here.

Provide

Provide is a centralized tool that was built on top of the ADD function. It’s a pool that collects pCoins, matches their value with PRV, and moves them to liquidity pools in ADD.

Provide is a trusted tool that the core team manages, and was created as a temporary solution to incentivize enough liquidity to enable anonymous trades. We built it in the early days of Incognito when PRV supply was limited and we needed to find a way to maintain liquidity without requiring you to purchase and provide PRV. Due to its popularity, we kept it around.

After releasing Privacy v.2 and coming pDEX improvements, we will create a decentralized liquidity incentive structure and migrate liquidity from Provide to ADD in an organic way.

Once that transition is complete, Provide and the centralization of liquidity will disappear.

Incognito Nodes

vNodes - Decentralized. This works the same way as ETH 2.0 vNodes.

pNodes (self-stake) - Decentralized. This is the same as running a virtual node on your home computer, except the software execution is automatic and pre-installed.

pNodeS (funded stake) - Centralized. This works like “cloud mining”, when you purchase part of the hash rate and earn from it.

Comment your thoughts

You can help improve this article by letting me know what you think. Do you have any questions that remain unanswered? Reply below!

22 Likes

Thank you @duc for the posting and I look forward to the further developments and growth of Incognito… :sunglasses:

3 Likes

Thank you for your work @duc & team. You all are brilliant.

2 Likes