-
Notifications
You must be signed in to change notification settings - Fork 19
193 burn fee collected in prepayment #199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many small and one big issue. Please be more careful and try to avoid obvious problems.
contracts/src/v0.1/Prepayment.sol
Outdated
@@ -18,10 +18,13 @@ contract Prepayment is | |||
uint16 public constant MAX_CONSUMERS = 100; | |||
bytes32 public constant WITHDRAWER_ROLE = keccak256("WITHDRAWER_ROLE"); | |||
bytes32 public constant COORDINATOR_ROLE = keccak256("COORDINATOR_ROLE"); | |||
uint16 public constant MIN_BURN_RATIO = 20; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the range should be between 0 and 100, and because such range is quite obvious, we do not need to define global variables for that. If you agree, please remove both MIN_BURN_RATIO
and MAX_BURN_RATIO
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was my first thought, theoretically, we could set it to 100% and burn all the fee. that would 8000 not ideal for our future operator, also the auditor would mark that as a "centralized issue". So I thought It would be better to make the decision at the beginning and make it constant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have to be flexible. We should not set some rules before getting approval from KF side. Keeping it in between 0 and 100 is the best we can do in my opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. flexibility and decentralization are always 2 opposite metrics of blockchain, sometimes we sacrifice one for the other.
How about we keep the const but set that to 0 --> 100 for now? Then we inform KF that all the centralized issues may arise if we go that path, then we can decide on a suitable boundary for burning rates.
The reason I want to keep those constant is to be totally transparent for our 3rd party node operators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please update the code according to your suggestion?
Co-authored-by: Martin Kersner <martin@bisonai.com>
Co-authored-by: Martin Kersner <martin@bisonai.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You did not finish removing requestConfirmations
. Some of them are not removed at all, some of them are half done. Please look at it again.
MAX_REQUEST_CONFIRMATIONS | ||
); | ||
} | ||
// if (minimumRequestConfirmations > MAX_REQUEST_CONFIRMATIONS) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't keep commented code. We don't plan to use it, so it is better to remove it.
s_config.minimumRequestConfirmations, | ||
MAX_REQUEST_CONFIRMATIONS | ||
); | ||
if (requestConfirmations > MAX_REQUEST_CONFIRMATIONS) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has to be removed as well. We are removing requestConfirmations
from everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks better! But we are not still there. Because we removed requestConfirmations
off-chain part has to be changes as well. Please think about global consequences when something is changed.
await prepaymentContract.connect(node).chargeFee(accId, feeAmount, node.address) | ||
).wait() | ||
const txEvent = prepaymentContract.interface.parseLog(txReceipt.events[0]) | ||
const { acc, oldBalance, newBalance, burnAmount } = txEvent.args |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
acc
, oldBalance
and newBalance
are not used, we do not have to extract them from event.
const amount = burnAmount.toNumber() + balanceNode.toNumber() | ||
|
||
expect(feeAmount).to.be.equal(amount) | ||
console.log('burn amount', burnAmount.toString(), '- node balance', balanceNode.toString()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not include logs to tests. We can use them for debugging, but otherwise we are just interested if tests passes or fail.
|
||
it('Should chargeFee with burn token', async function () { | ||
const { prepaymentContract, deployer, accId } = await loadFixture(deployFixture) | ||
const accounts = await ethers.getSigners() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better to use named accounts rather than using getSigners
directly. We have already defined quite many of them at https://github.com/Bisonai-CIC/orakl/blob/2cd73a4a7243188a21bd279048ecf0eb79e7eba8/contracts/hardhat.config.ts#L48-L74
Yes, I noticed the offchain part as well, we will working on it in this branch |
@@ -1,3 +1,2 @@ | |||
registry=https://registry.yarnpkg.com/ | |||
@bisonai-cic:registry=https://npm.pkg.github.com | |||
//npm.pkg.github.com/:_authToken=${NPM_TOKEN} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KelvinThai The problem is here, that's why the test breaks. Please put it back. We need it there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! But please remove the minimumRequestConfirmations
also from following files:
- https://github.com/Bisonai-CIC/orakl/blob/193-burn-fee-collected-in-prepayment/contracts/test/v0.1/VRF.config.ts
- https://github.com/Bisonai-CIC/orakl/blob/193-burn-fee-collected-in-prepayment/contracts/config/localhost/vrf.json
- https://github.com/Bisonai-CIC/orakl/blob/193-burn-fee-collected-in-prepayment/contracts/config/baobab/vrf.json
In this PR: