-
Notifications
You must be signed in to change notification settings - Fork 19
210 test if account has enough balance to request service #228
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
210 test if account has enough balance to request service #228
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.
I think we have to check the required balance in a different way. You can see more details in comments.
|
||
uint256 payment; | ||
|
||
payment = calculatePaymentAmount( |
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.
In my opinion the payment
value which you compute is something completely different than we are interested in. Similar computation is done inside of fulfill*
functions but the purpose and final value will be very different.
What I was thinking to do it is to set some predefined required balance that has to be in account, otherwise the request will be rejected.
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.
oh, then that makes the problem much simpler. the way I'm doing is to utilize the payment calculation in the fullfillment, the only difference is the gas at the time of fullfill and the time at request, but that is a very small number.
In your case, we can just simply implement a global MinBalance viriable and check that in every request, am I getting it right?
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 gas difference will be quite significant, but even if it is small difference it does not compute the correct value, therefore we should not use it. It could lead to failed fulfillments.
We can define minBalance
which would be part of Prepayment
configuration. It will be simpler solution and everybody will understand that it is predefined. The value has to be selected with care because it can have similar problems like the current solution.
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. In case we implement the minBalance
, it should be implemented in the Coordinators, not Prepayment
because the price is different for every service.
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.
Yes, you are right!
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.
How about I refactor this with minBalance
and setter function for this? It would raise centralize issues, but do you think it's good enough for now?
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 it is good for now. We can solve similar centralization problems later on. For now, the goal is to make sure that people with balance lower than minBalance
cannot request anything. However, we must keep in mind that at first nobody will pay for the service, so the value would be 0.
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.
Perfect! let's go for it
|
||
uint256 payment; | ||
|
||
payment = calculatePaymentAmount( |
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.
The same problem as described above.
@@ -161,6 +161,8 @@ describe('Prepayment contract', function () { | |||
|
|||
await prepaymentContractConsumerSigner.addConsumer(accId, consumerContract.address) | |||
await prepaymentContract.addCoordinator(coordinatorContract.address) | |||
const value = 1_000_000_000_000_000 |
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 prefer to use ethers.utils.parseUnits
instead of raw wei values. It will be easier to read.
https://docs.ethers.org/v5/api/utils/display-logic/#utils-parseUnits
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 is also already function called parseKlay
.
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 Can you please update this value?
|
||
await expect( | ||
consumerContract.requestData(accId, maxGasLimit, { | ||
gasLimit: 500_000 |
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.
Do we have to specify the gasLimit
?
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.
We dont have to, it runs either way, it just my habit to include a high gas limit in test, I some case it doesn't work on local with low gas limit
contracts/test/v0.1/VRF.test.ts
Outdated
|
||
await prepaymentContractConsumerSigner.addConsumer(accId, consumerContract.address) | ||
await prepaymentContract.addCoordinator(coordinatorContract.address) | ||
const value = 1_000_000_000_000 |
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.
The deposit is not high enough, that's why it should fail?
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.
yes, tha's the purpose of the test
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 it is not exactly obvious from this test that such number is too small. After the implementation is changed to minBalance
. I think it will make more sense but the deposited value still should be defined based on minBalance
and testing the it is smaller than minBalance
.
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 few cosmetic changes mostly related to
- where we call
setMinBalance
- how do we convert klay to peb (let's do to same everywhere please)
- suggesting to remove an extra unused variables
function requestData( | ||
Orakl.Request memory req, | ||
uint32 callbackGasLimit, | ||
uint64 accId | ||
) external nonReentrant returns (uint256 requestId) { | ||
uint256 startGas = gasleft(); |
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 don't think startGas
is used anywhere in this function.
@@ -450,7 +458,14 @@ contract VRFCoordinator is | |||
uint32 callbackGasLimit, | |||
uint32 numWords | |||
) external nonReentrant onlyValidKeyHash(keyHash) returns (uint256 requestId) { | |||
uint256 startGas = gasleft(); |
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 don't think startGas
is used anywhere in this function.
@@ -450,7 +458,14 @@ contract VRFCoordinator is | |||
uint32 callbackGasLimit, | |||
uint32 numWords | |||
) external nonReentrant onlyValidKeyHash(keyHash) returns (uint256 requestId) { | |||
uint256 startGas = gasleft(); | |||
bool isDirectPayment = false; |
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 move this closer to the call of requestRandomWordsInternal
. You have included the check in between one logical piece of code.
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.
Sorry, I dont understand this Comment, we remove this unused variable?
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.
Github does not show it nicely. The comment is for line 462, but it looks like I am commenting about 461. Let me try to explain it with example.
Before adding the balance check, the code looked like this
bool isDirectPayment = false;
requestId = requestRandomWordsInternal(
keyHash,
accId,
callbackGasLimit,
numWords,
isDirectPayment
);
isDirectPayment
variable was defined close requestRandomWordsInternal
so the meaning of false
value is apparent. However, after adding the check for minBalance
, it looks as follows
bool isDirectPayment = false;
(uint256 balance, , , ) = s_prepayment.getAccount(accId);
if (balance < s_minBalance) {
revert InsufficientPayment(balance, s_minBalance);
}
requestId = requestRandomWordsInternal(
keyHash,
accId,
callbackGasLimit,
numWords,
isDirectPayment
);
Definition of isDirectPayment
is separated from requestRandomWordsInternal
call by check for minBalance
.
It might be better to check the comments from files section where it is easier to understand what is being commented on.
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.
gotcha!
@@ -161,6 +161,8 @@ describe('Prepayment contract', function () { | |||
|
|||
await prepaymentContractConsumerSigner.addConsumer(accId, consumerContract.address) | |||
await prepaymentContract.addCoordinator(coordinatorContract.address) | |||
const value = 1_000_000_000_000_000 |
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 Can you please update this value?
@@ -31,6 +32,9 @@ describe('Request-Response user contract', function () { | |||
|
|||
await (await coordinatorContract.registerOracle(rrOracle0)).wait() | |||
|
|||
const minBalance = ethers.utils.parseUnits('1', 15) |
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 this is quite hard to read and understand the meaning of this value. How about doing this instead which should produce the same value.
const minBalance = ethers.utils.parseUnits('1', 15) | |
const minBalance = ethers.utils.parseUnits('0.001') |
contracts/test/v0.1/VRF.test.ts
Outdated
gasAfterPaymentCalculation, | ||
Object.values(feeConfig) | ||
) | ||
const minBalance = ethers.utils.parseUnits('1', 15) |
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.
Same as described above, it is hard to read and consequently understand the desired value.
@@ -31,6 +32,9 @@ describe('Request-Response user contract', function () { | |||
|
|||
await (await coordinatorContract.registerOracle(rrOracle0)).wait() | |||
|
|||
const minBalance = ethers.utils.parseUnits('1', 15) | |||
await coordinatorContract.setMinBalance(minBalance) |
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 this should be part of fixture where we define all important settings related to deployment.
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.
yes, let's move it to fixture.
contracts/test/v0.1/VRF.test.ts
Outdated
Object.values(feeConfig) | ||
) | ||
const minBalance = ethers.utils.parseUnits('1', 15) | ||
await coordinatorContract.setMinBalance(minBalance) |
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.
Same as above. I think this should be part of fixture where we define all important settings related to deployment.
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 have tested running tests locally, all of them as working fine.
LGTM!
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!
No description provided.