Closed patitonar closed 5 years ago
netlify[bot]
commented
5 years ago Deploy preview for kind-kilby-95344f processing.
Building with commit 271d13f341ce3b2afa0d0d1c735c90666b07e98d
https://app.netlify.com/sites/kind-kilby-95344f/deploys/5cc1c38de879f300087c8fe1
coveralls
commented
5 years ago | Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
|---|---|---|---|---|---|
| src/components/Bridge.js | 0 | 1 | 0.0% | ||
| src/components/StatisticsPage.js | 0 | 1 | 0.0% | ||
| src/stores/utils/contract.js | 0 | 5 | 0.0% | ||
| src/stores/utils/array.js | 0 | 13 | 0.0% | ||
| src/stores/ForeignStore.js | 0 | 14 | 0.0% | ||
| src/stores/HomeStore.js | 0 | 25 | 0.0% | ||
| <!-- | Total: | 20 | 79 | 25.32% | --> |
| Files with Coverage Reduction | New Missed Lines | % | ||
|---|---|---|---|---|
| src/stores/utils/decimals.js | 6 | 0.0% | ||
| src/stores/utils/contract.js | 23 | 0.0% | ||
| <!-- | Total: | 29 | --> |
| Totals | |
|---|---|
| Change from base Build 446: | -0.4% |
| Covered Lines: | 58 |
| Relevant Lines: | 1415 |
patitonar
commented
5 years ago To calculate fee amount taken by validators we get each specific transfers event and apply the fee value that was set at that moment of the transaction.
The most complicated part is to know which fee value we should use for that event, this will be determined by the modes of the fee manager (ONE_DIRECTION, BOTH_DIRECTIONS) and if it set on home or foreign network. Also fee value could be changed during time.
The method getRewardableData provides us all of the information, if column should be displayed on statistic tab, which historic fee values use for the events and the current fee to apply for new transfers. All of this based on fee manager possible configurations.
If we introduce new events lets say:
FeeDistributedFromSignatures(uint256 feeAmount, ...) every time distributeFeeFromSignatures is called (on home or foreign)FeeDistributedFromAffirmation(uint256 feeAmount, ...) every time distributeFeeFromAffirmation is called (on home)We could replace logic of applying the fee value to the amounts on the transfers events to just accumulate the values from these two new events. This will make the logic a little simpler.
Numbers of requests will be the same, so there will be no performance improvements from that side. And we will still need getRewardableData method to provide some information for the different scenarios.
The problem is that we need to support displaying fee information for already deployed ETC-WETC bridge, and having both approaches will increase the complexity of the logic.
So I think that given we have an already working bridge we should use this implemented approach (or any other we can think of) with the existing events.
Does this makes sense to you?
akolotov
commented
5 years ago Ok. Let's keep it as you are suggesting. Regarding:
The problem is that we need to support displaying fee information for already deployed ETC-WETC bridge, and having both approaches will increase the complexity of the logic.
The code of the token bridge contracts is going to be on the audit soon. So, I expect some comments from auditors that will require upgrade of the deployed implementation. That's why I think we will have the opportunity to change the behavior of contracts and it is good to use this opportunity to simplify the logic of the dependent products. Let's keep it in mind.
Closes #210
To calculate the collected fees the following events are used:
UserRequestForSignatureandAffirmationCompletedevents to get the transfersHomeFeeUpdatedandForeignFeeUpdatedevents to get all fee values along the blocksTo get the collected deposits fee, for every
UserRequestForSignaturewe calculate the fee based on fee manager mode and the fee value on that block. The same logic applies for collected withdrawal fees, but instead we useAffirmationCompletedeventsThis is how information is displayed for ETC/WETC bridge: