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.
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.
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
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.
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
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.
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.
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.
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
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
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
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.
@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?
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)
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.
@Rocky(thach) will join us to take care of portal v2 BNB
About fullnode for Binance relaying, we can setup a strong fullnode. But tx fee is a new issue for this relaying, when we is high, relaying need to pay a high fee for relaying tx, an economic issue.
And your team also tell me about big size of Binance, it will hurt incognito db size
I’m runing a node to sync data from testnet and get error nil pointer
I suggest we will review why we can not get Custodian pool state by key and change some code to make sure this is not error with nil pointer
Updates for the week of May 4 - May 8, 2020:
Regarding Binance chain’s headers relaying, we decided to point to a fullnode maintained by Binance team as a solution for the issue we faced/mentioned last week. At the moment we think this is a practical and acceptable solution when Binance chain is pretty centralized and is being controlled 100% by Binance team (100% validators in Binance’s committee are being run by the team and never swap)
The QA team still works on trustless bridge v2 testing this week. The testing report details can be found here Quality control strategy to minimize oversight for Q2 2020. There were a few bugs that mostly related to liquidation process. We’ve fixed and the fix will be deployed to testnet early next week.
We’ve also re-designed the way to choose custodians for redeem flow that allows custodians to volunteer to return public coins (btc, bnb) to redeemers first and the system will choose more custodians if needed afterward. This will be implemented next week too.
Hi @hiennguyen @hardy
Because consensus-v2 with multiview(fix block proposor) still waiting these bug to continuously deploy on testnet. Please commit that you can check these issue before 13 May so that I can deploy it. Because when deploy consensus-v2 earlier, we can make decision ealier for deploying for mainnet
cc @0xkumi and team consensus
So did the trustless bridge ever become deployed? If so which coins currently use this?
Hi @Fatfaa, thanks for your question.
We have deployed Incognito’s trustless bridge to Bitcoin and Binance chain with Incognito bond contract. For your information, we have been developing the trustless bridge v3 with Ethereum bond contract. Please see here for more details: Incognito's trustless bridge V3 with Ethereum bond contract
Thanks for clarifying! We need a chart that shows what is what currently, dev team is so fast!