Buy crypto anonymously on the Incognito pDEX   

[Ongoing] Incognito’s trustless non-custodians bridge V4

#1

Problem:

As you know, we finished the design and implementation of Incognito’s trustless bridge for public tokens (BTC and BNB) that allow users to shield public tokens decentralized, aka Portal v2 (with Incognito vault) and Portal v3 (with Ethereum smart contract vault). See detail: Incognito's trustless bridge V3 with Ethereum bond contract

However, there are some problems with our current design.

  • First, the logic of the shielding and unshielding processes is quite complicated. So, it’s too difficult to operate the protocol practically.
  • Second, portal supports shield BTC and BNB while the collaterals are maybe other tokens (such as PRV, ETH, USDT, etc). So it needs the exchange rates between those tokens for calculations. But unfortunately, the rates usually fluctuate significantly lead to liquidations occur frequently that we don’t want to happen.
  • Third, the pool vault’s size is a bit small since the incentives for custodians to deposit tokens into the pool are not attractive enough.

Solution:

We simplified the protocol with a new approach: No Custodians - No liquidations.

The main change in the new design is who holds public tokens when users shield their public tokens into pToken. Instead of custodians, the multisig wallet generated by the keys of beacon validators in Incognito chain will receive public tokens from users. When unshielding, the beacon validators will create a raw transaction over the external chain (e.g., Bitcoin Chain) with at least ⅔ signatures of total validators to send back public tokens to users.

With the new design, we don’t need over-collateralization and also don’t have to worry about liquidation. It significantly reduces risks for both users and custodians. Users can shield and unshield with the trustless non-custodians bridge simply and more securely.

Objective:

Deploy Incognito’s trustless non-custodians bridge (Portal v4) on the mainnet environment.

Length: 2.5 months

  • 20/1 - 23/2: finalize the protocol design and finish the implementation of Bridge v4.
  • 24/2 - 2/3: complete shielding flow (unit tests + local tests + implementation docs), feature flag for Bridge v4.
  • 3/3 - 9/3: complete unshielding flow (unit tests + local tests + implementation docs).
  • 10/3 - 16/3: complete replacement fee + submitting the external txs confirmed (unit tests + local tests + implementation docs).
  • 17/3 - 23/3: complete workers for bridge v4.
  • 24/3 - 31/3: complete local testing by QC team.
  • 1/4 - 9/4: complete testing on testnet environment. Prepare some necessary things for migration to the trusted bridge and ensure the security of beacon keys.

Key results:

Have a workable version of the trustless non-custodians on the mainnet environment for Bitcoin by April 9. We will deploy bridge v4 on the code base of privacy v1 in this release. Then, we will merge privacy v2’s code after privacy v2 gets the stable release.

Note:

15 Likes
We have keys, but do we really have THE keys to our crypto in Incognito?
Incognito 2021 (Q3 & 4) timeline
Incognito February 2021 Targets
What stops me from shielding too much?
Helium hotspot tokens
Critical analysis of Incognito
Weekly Privacy Newsletter - 2.2.21
Incognito's 2021 privacy roadmap for the world
[Shipped] Incognito's trustless bridge V3 with Ethereum bond contract
[BUG] Amount of pToken in network is not fully pegged 1:1 to vault balance
Join us for the February 2021 PRV Holders Call
Letter to PRV Holders (January 2021)
#2

Thanks for the information. I’ll be studying the Github intently.

4 Likes
#3

Interesting. I need to read this again a few more times.

3 Likes
#4

As new validators come one, don’t you have to change the multiSigniture to account for that? Also this might potentially slow down withdraws.
But it definitely is a step in the right direction, we desperately need decentralization asap.

3 Likes
#5

Awesome!! This is exactly how I believe incognito should be functioning but never mentioned it because I thought you were working on something else.

How many members of the multisig will there be? Who can be able to be a member?

I’m curious the process if someone wants to get their collateral back and stop being a member of the multisig. Obviously you can’t “unlearn” a private key. Also, if the multisig members are not putting up collateral to overcollateralize the position, what keeps them incentivized to doing their part in continuing to sign transactions as needed? If too many of the multisig members leave, there will not be enough left to unshield a coin.

Also, the opposite problem: How do you propose to limit the number of participants without putting up collateral? There are large players even with validator nodes and if collectively they gain access to 2/3 signatures, they can steal the coins. Without collateral there is no penalty.

Others can chime in here—I am not the most technical person. I’ve just watched other projects that use this sort of mechanism. It’s brilliant but also not without problems.

3 Likes
#6

Has this concept ever been used? Does this concept favor nodes that are selected every epoch (team controlled) to be the gatekeepers of funds? Just trying to figure out if this is actually decentralized or just a form of a better trustless setup

#7

Hi @marko, @Revolve,
Thank you so much because of your interest in Portal v4.
Members of the multisig wallet of Portal v4 include seven fixed beacon validators in Incognito chain. Currently, we don’t swap beacon validators and make sure there are always at least 5 validators (> ⅔) are available so it doesn’t make slow down the unshielding process.

3 Likes
#8

Hi @hiennguyen
Thanks so much for your reply. That seems like a good plan for V4.

Who are the seven fixed beacon validators that control the multisig? Are these all different members of the team?

2 Likes
#9

I just got a chance to read the entire string and indeed marko and revovle raise valid issues but overall this upgrade will be incredibly amazing and I along with the community at large look forward to its implementation…great job @hiennguyen… :sunglasses:

1 Like
#10

The new status of Bridge v4 (20/01 - 23/02/2021):

What result?

  • We finalized the design protocol with the trustless non-custodians approach by using the multisig wallet which is public tokens custody.
  • We completed implementing almost features on Bridge v4 (including both shielding and unshielding flow).

What next?

  • We do local tests on our flows and write unit tests for them.

Thanks all.

5 Likes
#11

Hi @hiennguyen,
I am very interested in the way you guys make the network more and more trustless. Still, does what you say,

imply that these seven fixed beacon validators will never be swapped, never be replaced? In that case, I think the beacon chain will be a single point-of-failure and thus, the network will be more vulnerable.

#12

Compare to the current centralized approach, this is still much better.

#13

Hi @AloneWalker, thanks for your question.
First, we don’t release beacon validators to make sure the stability of the network currently. But it’s only temporary. We are trying to release beacon nodes soon.

Second, although the private keys of the multi-sig wallet are generated by beacon validators, we will make sure attackers can’t re-generate or get the private keys even they find a way to access the servers of beacon nodes.

2 Likes
Incognito 2021 - Transparency, decentralization, and infrastructure
The state of decentralization
#14

The replacing of fixed beacon validators will make it very hard to the recovery of the multisig private key.

Perhaps could you explain more about this technique? Or could you give me any keyword?

#15

Hi everyone,

We want to give you some updates about the process of the proposal.
We will speed up the process of implementing trustless bridge v4 in order to improve the current trusted bridge for Bitcoin sooner. Here are the new timelines of the proposal:

  • 20/1 - 23/2: finalize the protocol design and finish the implementation of Bridge v4.
  • 24/2 - 2/3: complete shielding flow (unit tests + local tests + implementation docs), feature flag for Bridge v4.
  • 3/3 - 9/3: complete unshielding flow (unit tests + local tests + implementation docs).
  • 10/3 - 16/3: complete replacement fee + submitting the external txs confirmed (unit tests + local tests + implementation docs).
  • 17/3 - 23/3: complete workers for bridge v4.
  • 24/3 - 31/3: complete local testing by QC team.
  • 1/4 - 9/4: complete testing on testnet environment. Prepare some necessary things for migration to the trusted bridge and ensure the security of beacon keys.

Note: We will deploy bridge v4 on the code base of privacy v1 in this release. Then, we will merge privacy v2’s code after privacy v2 gets the stable release.

7 Likes
Weekly Privacy Newsletter - 3.2.21
Incognito March 2021 Targets
Letter to PRV Holders (February 2021)
#16

Thank you for the updated news @hiennguyen… :sunglasses:

#17

The replacing of fixed beacon validators will make it very hard to the recovery of the multisig private key.

Your concern is totally reasonable. Maybe we only run bridge v4 while beacon validators are fixed. Since we release beacon validators, maybe we will switch to Bridge v3 - the completely trustless decentralized bridge.

Perhaps could you explain more about this technique? Or could you give me any keyword?

In order to ensure the security of multisig private keys, we will use cryptography to encrypt the seeds (which are used to generate the private keys of multisig wallet) on beacon servers. Therefore, if any attackers access beacon servers, but they can’t collect the seeds and generate the private keys.

7 Likes
#18

Is bridge v3 the over collateralized approached method ? If so why go back to that?