8000 193 burn fee collected in prepayment by KelvinThai · Pull Request #199 · Bisonai/orakl · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

Merged
merged 13 commits into from
Feb 3, 2023

Conversation

KelvinThai
Copy link
Contributor
@KelvinThai KelvinThai commented Jan 30, 2023

In this PR:

  • Burn fee in Prepayment
  • Remove RequestConfirmation in on-chain oracles
  • refactor offchain oracles, remove RequestConfirmation parameter

@KelvinThai KelvinThai linked an issue Jan 30, 2023 that may be closed by this pull request
Copy link
Member
@martinkersner martinkersner left a 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.

@@ -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;
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good!

Copy link
Member

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?

KelvinThai and others added 2 commits January 31, 2023 10:03
Co-authored-by: Martin Kersner <martin@bisonai.com>
Co-authored-by: Martin Kersner <martin@bisonai.com>
@KelvinThai KelvinThai self-assigned this Jan 31, 2023
@martinkersner martinkersner linked an issue Feb 1, 2023 that may be closed by this pull request
Copy link
Member
@martinkersner martinkersner left a 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) {
Copy link
Member

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) {
Copy link
Member

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.

Copy link
Member
@martinkersner martinkersner left a 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
Copy link
Member

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())
Copy link
Member

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()
Copy link
Member

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

@KelvinThai
Copy link
Contributor Author

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}
Copy link
Member

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.

Copy link
Member
@martinkersner martinkersner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martinkersner martinkersner merged commit e548204 into master Feb 3, 2023
@martinkersner martinkersner deleted the 193-burn-fee-collected-in-prepayment branch February 3, 2023 06:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Burn fee collected in Prepayment Decide how to deal with minimumRequestConfirmations in VRF
2 participants
0