I hope you remember I asked you to take me as one of the first lucky ones custodians?
“end of Feb 2020” = tomorrow
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.
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.
@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.
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)
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.
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.
@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!
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 @TuanN 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?