[Shipped] Building out Incognito’s trustless bridge to Bitcoin and all other blockchains

[duc]

What privacy problem are you solving?

Today, anyone can send BTC, ETH, and thousands of other cryptocurrencies to another party without going through a financial institution. For those who value privacy, these cryptocurrencies come with a big tradeoff. Transactions are recorded on public ledgers, displaying amounts involved, inscribing virtual identities of their senders and receivers. Given the choice, we strongly believe that very few people will willingly disclose their crypto financials to the entire world.

The inherent lack of privacy to cryptonetworks today is a real and present threat to the entire crypto space.

What is the solution?

We’re proposing a solution to shield any cryptocurrency – BTC, ETH, USDT, etc. In effect, any cryptocurrency can now be a privacy coin. Both shielding and unshielding processes are carried out via a decentralized group of trustless custodians. Once shielded, transactions are confidential and untraceable.

Shielding is the process of turning cryptocurrencies on other cryptonetworks (or “public coins”) into privacy coins on Incognito. Through Portal, a public coin can be shielded to obtain its privacy coin counterpart of the same value. For example, BTC can be shielded to obtain the privacy coin pBTC. pBTC has the same value as BTC, so 1 pBTC can always be redeemed for 1 BTC and vice versa.

Once shielded, privacy coin transactions are confidential and untraceable. A privacy coin enjoys the best of both worlds. It retains the value of its original counterpart and can be transacted confidentially on the Incognito network

Figure 1. Shielding BTC and minting pBTC. Other public coins follow the same shielding process. Note that we simplify step 5 to make it simple for readers to follow the main logic: the proof of deposit is not generated by the custodian, but by the miners of underlying cryptonetwork.

Unshielding is the reverse process of shielding: turning privacy coins back into public coins

Figure 2. Unshielding pBTC and releasing BTC. Other public coins follow the same unshielding process

What substitutes do people resort to because this doesn’t exist yet?

Current blockchain interoperability solutions mostly involve building ad-hoc bridges. BTC Relay, WBTC, and TBTC build ad hoc bridges between Bitcoin and Ethereum, while Kyber Network builds Waterloo, an ad hoc bridge between Ethereum and EOS. For Portal, doing it ad hoc – one bridge for every cryptonetwork – is not a scalable option.

Portal takes a different approach: build once, work with any cryptonetwork. The shielding mechanism operates via a general bridge design that connects Incognito to any number of cryptonetworks, allowing for secure bi-directional transfers of cryptocurrencies whenever privacy is needed. This means any coin can now be a privacy coin. This approach is especially helpful for creating interoperability with cryptonetworks that do not support smart contracts, like Bitcoin and Binance Chain.

Who are you?

The project will be implemented by @duc, @hiennguyen, and @harry on the core team.

• @duc is the engineer of Incognito’s interoperability team. He’s been with the project since the beginning, leading the design and implementation of the Ethereum bridge (see https://incognito.org/t/incognito-mode-for-ethereum/53). Previously, @duc worked on data engineering, AI, and scalable systems. His first crypto project was on decentralizing data sets for machine learning.

• @hiennguyen is an engineer in Incognito’s interoperability team. She joined Incognito at the very beginning. Previously, @hiennguyen worked on cryptography and has now implemented the privacy protocol for Incognito. She is looking forward to increasing her knowledge and experience by moving on and helping to build out the Portal project.

Why do you care?

Monero, Zcash, and Grin introduced their own version of cryptocurrencies that focus on privacy. Portal takes a different approach, based on the premise that people don’t want a new cryptocurrency with privacy. What they really want is privacy for their existing cryptocurrencies: incognito mode for any cryptocurrency.

Portal is designed so users don’t have to choose between their favorite cryptocurrencies and privacy coins. They can have both. They can hold any cryptocurrency and still be able to use it confidentially whenever they want. Privacy needs to be ubiquitous, inclusive, and accessible.

For these reasons, Portal is a really challenging project that is and worth solving, and we’re excited to make it happen.

What’s your plan? What’s your schedule?

The project duration will be 2 months from Feb 1, 2020 to May 31, 2020.

Ship Date	Deliverable
March 31, 2020	Ship trustless bridge with Bitcoin, Binance Chain (Incognito bond contract) for Protocol side
April 30, 2020	Ship trustless bridge with Bitcoin, Binance Chain (Incognito bond contract) for App side
May 31, 2020	Ship trustless bridge with Bitcoin (Ethereum bond contract) for both Protocol and App

What are the key results?

Goals for May, 2020

Trustless bridge V2
Get the protocol deployed on Mainnet after passing all test-cases from QA team.

Trustless bridge V3
Implement SPV function to verify Bitcoin transaction on Ethereum bond contract along with its unit-tests.

What’s your budget?

The project will be undertaken by 2 engineers for 4 months:

Resource	Quantity	Monthly Cost
Incognito protocol engineer	2	3,000 PRV
TOTAL (x 4 months)		12,000 PRV

Is there an existing conversation around this idea?

A few months ago, we received a grant from Binance that took the development of Portal to this point, and will help offset additional development costs going forward. See https://incognito.org/t/binance-funds-development-of-the-incognito-portal/77 for more details.

Is there anything else you would like the community to know?

We are always happy to hear feedback from the community so feel free to leave comments if any. Thanks.

[duc]

Quick update for Feb 2020:

• Finished up the development for shielding process
• We’re now writing unit-tests for cases of the process. It’ll be done by the end of Feb 2020.
• Next week, we’ll be starting working on unshielding process.

[zes333]

@duc HI👋
I hope you remember I asked you to take me as one of the first lucky ones custodians?

[abduraman]

“end of Feb 2020” = tomorrow

[duc]

sure @zes333, you’re one of the most active members on the forum. we’re actually appreciated… as the plan, we’ll be delivering the first version of the bridge at the end of March (Incognito bond contract) so can’t wait to see you there.

[duc]

yep @abduraman, we’re working hard to get the shielding process done internally on our local environment. Really excited to be able to ship the first version of the bridge by the end of March.

[annie]

@duc the update looks good. Funds for Feb has been disbursed, please kindly check.
We will continue disburse every subsequent week dependent on progress, so keep us updated.

Thanks!

[duc]

Update: week of March 2 - 6, 2020:

• We’ve been working on the redeem flow of Portal (a.k.a, pTokens -> public coins). It’s almost done, we’re still on testing for the flow.
• The thing left of development is the auto-liquidate process (before going to the testing stage)

[duc]

Updates for the week of March 9 - 15, 2020:
We’ve been working on 3 things:

• Incentives for custodians - custodians will receive shield mining rewards in addition to shielding fees (100%)
• Auto-liquidation - that happens when custodian doesn’t return public coins (eg, bnb, btc) to user or value of bonded collaterals drops significantly (95%, a few issues just came up and we’re fixing them)
• Bitcoin SPV processes - Apart from Binance chain (that has been implemented already), we’re also getting Bitcoin supported in Portal. For more details, we’ve been working on header relaying as well as transaction verification with Merkle tree processes for a week now (~60%). These are expected to be done next week.

[duc]

Updates for the week of March 16 - 22, 2020:

• We’ve almost done the implementation of this proposal. However, from the core team, there are some other proposals that are being worked in parallel. One of them is Reduce Blockchain size by 50%. The work of this proposal is really cool when it’s introducing a new way to store chain’s data much more efficiently. Unfortunately, the data of trustless bridge (aka Portal) is storing & manipulating in the old way which is not 100% compatible with the new way so we need to merge code and rework on that a bit next week.
• For that reason, we’re proposing an extension of the protocol ship date for the first version until April 10 (instead of March 31 as planned). Really apologized about this.

[duy]

@duc i personally think delaying it just 10 days but being able to ship both trustless bridge to bitcoin and blockchain size reduction to 50% is totally awesome!

[thaibao]

I think this is make sense for our system. Last week, I reviewed pull request code from Db version 2, and we have a lot of thing which be changed. This is newest code branch for dev, in here. Maybe your team need to have 2-3 days to merge back your branch, and retest again from this.

[duc]

Updates for the week of March 23 - 29, 2020:

• We’ve finished merging code and upgrading Portal persistence to one that’s completely compatible with Database V2 (see it here: Reduce Blockchain size by 50%)
• So the implementation of Portal for both Bitcoin and Binance chain has been done and we’ll be focusing on testing (eg., writing unit tests or even automation tests) next week.

[thaibao]

Early, @duc, to make this feature can come to user,
I think we need to make it with another proposal for UI/UX on app

[duc]

Updates for the week of March 30 - April 5, 2020:

• We’ve worked on 3 backend workers that are getting external information (eg., block headers from Bitcoin, Binance chain and coin prices from Coinmarketcap) and feeding into Incognito chain for further processes. The code of these workers could be found here (https://github.com/incognitochain/incognito-portal-feeders)
• We’ve also been working on testing for a while and will be continuing to focus on it next week. If everything’s going to be okay, we’ll deploy the protocol to mainnet by the end of next week.

[thaibao]

Hi team

I spent 1-2 days reviewing your team pull request and saw that we have some issues in the reward of the custodian. I consider that we need to make some review for this, it should be come from DAO. Because we have a total supply of PRV incognito, and DAO account gets a little from this so that somehow we need to get the reward from DAO account to fund for custodian reward

Thanks

[duc]

Updates for the week of April 6 - 12, 2020

• After got code reviews, we’ve fixed logic related to custodial reward so you can look into the updated PR here (https://github.com/incognitochain/incognito-chain/pull/832), @thaibao.
• Once the PR is reviewed and merged into codebase, we will proceed to deploy the trustless bridge protocol on testnet. It’s should take a few days for QA on that environment before moving to mainnet.
• In the meantime, we’re also preparing resources and knowledge for the next version of the trustless bridge with Ethereum bond contract.

[thaibao]

Hi @duc @hiennguyen
It sounds good that you have some updating for this. But as I talked to @hiennguyen, when we have some variable on beacon(total reward for all custodian), this will increase communication between beacon and shard, we will have risk here. My suggestion to @hiennguyen is that we will process custodian reward in function buildRewardInstructionByEpoch of salary.go.

In this way, we will process more on the reward of DAO account and the same flow with instruction of DAO, by getting x% from the reward of DAO account and fund for custodian reward. And we only build more instruction for custodian reward besides DAO reward. No need to create a new variable on the beacon and wait for shard sync it.

You guys can review my suggestion soon to have a good solution to this issue.

Thanks

[duc]

Updates for the week of April 13 - 17, 2020:

• We’ve managed to merge trustless bridge’s code into incognito chain main branch and deployed it on Testnet environment as well.

• The QA team has also been working on testing (understand the bridge’s flow and define test-cases) for the trusted bridge for a while. Please see more details at Quality control strategy to minimize oversight

• In the meantime, we’ve also started working on the trustless bridge V3 that will be using Ethereum contract as a vault apart from Incognito chain vault. In the next week, we’ll be continuing to working on it.

[thaibao]

Hi team,

It sounds happy that we have just merged code into ready branch for deploying. And tester team can start test around great features that we have just built

I have just spent more time to review about feeder tool for our team. This may not important more than the code of portal v2 in node app, but you guys can support me with some of my suggestion.

1/ We can consider change this import to the same format with other repo

that mean “github.com/incognitochain/incognito-portal-feeders/…”. I think this is the same way we often use

2/ We reuse a lot utils.NewHttpClient(…) in main.go for

we can consider change a little bit here: os.Getenv(“INCOGNITO_PROTOCOL”), os.Getenv(“INCOGNITO_HOST”), os.Getenv(“INCOGNITO_PORT”); not repeat again on every agents

3/ I think here

we try to distinguish mainnet and testnet, so can we apply something like this. In this way, we can extend more param when needing to use testnet / mainnet. I mean Network, maybe it is an object with 1st property is string Name(mainnet/testnet), and 2nd … something else

4/ I think some string or number that we can move into same file constants.go. In this way, we can find it fastly when we want to update

5/ If having more time, can we get log utils
and reuse instead of using fmt for the same format

6/ Maybe I not understand about logic of code here

but can we merge for at line 127 with line 143, line 157(1 loop ‘for’ for 3 logic )?

7/ Why did we use int64 here?

can we use uint64? Cause this is height of block. like this

8/ We consider that can we use maps into here? Because it is actually easy to use if we have demand to built API to get info from this tool

I suggest
const name_coin = ‘name_coin’
map[name_coin] = ‘token ID’

Maybe some of my suggestions are not clear, you can ask me if you not understand. The fact that it is only suggestions so that you can review and make decisions on it