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

duc · 29 February 2020 01:53

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 · 29 February 2020 01:59

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 · 4 March 2020 10:56

@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 · 7 March 2020 01:28

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 · 15 March 2020 14:11

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 · 23 March 2020 01:31

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 · 23 March 2020 01:01

@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 · 23 March 2020 05:03

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 · 29 March 2020 18:56

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 · 30 March 2020 07:59

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 · 5 April 2020 17:00

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 · 9 April 2020 02:29

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 · 12 April 2020 01:22

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 · 16 June 2020 07:26

Hi @duc @0xkraken
It sounds good that you have some updating for this. But as I talked to @0xkraken, 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 @0xkraken 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 · 17 April 2020 08:15

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 · 18 April 2020 15:27

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

duc · 24 April 2020 08:28

Updates for the week of April 20-24, 2020:

As we’ve updated previously, the trustless bridge v2 was deployed on testnet last week and has been testing aggressively this week by QA team, thanks @hardy for your testing effort on this.
Along the way, a few bugs have been spotted and two typical ones were related to block header relaying processes for both Bitcoin and Binance chain. Fortunately, these two have been fixed, you can find the PRs for them at: https://github.com/incognitochain/incognito-chain/pull/872 https://github.com/incognitochain/incognito-chain/pull/875
Next week, apart from testing and bug fixing, we’ll be working on an implementation for trustless bridge v3 (Ethereum bond contract) that’s been late for 1 week or so against what we planned.

duy · 25 April 2020 20:03

@duc thanks for the update.

can you elaborate more on protecting privacy for custodians? how will the custodians deposit into the ethereum smart contract? will that be a direct call from the custodian eth address or will be through pEthereum? personally, i would call it through pEthereum so that i can keep my privacy without disclosing i’m a custodian.

similar concerns on privacy for custodians. how is the deposit address (btc custodial address generated? is it linked to the custodian’s identity? if so, how can we avoid that?

duc · 1 May 2020 14:56

hey @duy thanks for your great questions. To be honest, when we designed originally the trustless bridge, pEthereum has not existed yet. Yeah, you’re right, we can leverage the work of pEthereum to be able to preserve privacy for custodians once they deposit into Ethereum bond contract (if they want, otherwise they can always make a direct call to contract for sure)
And in order to avoid the “link” between custodian’s identity and his deposit address (say bitcoin address), the address would be generated from custodian’s Incognito private key. You can think the key as a seed for the bitcoin key-pair generation function. The custodian has then fully control on the newly created bitcoin address such as signing on a bitcoin transaction by using his own incognito private key, … Moreover, the generation is one way and irreversible so no one can link those two addresses together (custodian’s incognito and bitcoin addresses)

duc · 1 May 2020 17:08

Updates for the week of April 27 - May 1, 2020:

This week we’ve been working closely with QA team to help them with their testing scenarios for the trustless bridge. Due to the processes’ complexity, the testing seemed to take much more time than expected so @thach was joining us to help speed it up (besides @hardy)
Good news is the bridge between Incognito and Bitcoin is working well on testnet now. QA team will be proceeding to test with Binance chain next week.
We’re also facing some issues that will need to be resolved next week too:

Simple payment verification (SPV) for transactions from Binance chain is mostly relying on block headers that would be relayed into Incognito chain by a relayer worker. Unfortunately, Binance chain is producing blocks too fast (~ 3 block/s) that both the relayer and Incognito chain could not manage to achieve that fast yet. Pointing to public full-nodes provided and maintained by Binance team will probably be a backup solution for the problem.
Re-design the way to choose custodians for redeem flow a bit in order to make it more flexible and convenient for custodians and even redeemers by increasing the opportunity for redeemers to get their public coins (btc, bnb, …) back from custodians who more likely willing to do it.