-
Notifications
You must be signed in to change notification settings - Fork 22
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
Implement checkpoint call for staking #135
Conversation
d6949bf
to
908bc84
Compare
@@ -88,9 +95,12 @@ | |||
FailedTransactionSubmissionRound: HandleFailedTxRound, | |||
FinishedDecisionRequestTxRound: DecisionReceiveRound, | |||
FinishedBetPlacementTxRound: RedeemRound, | |||
FinishedRedeemingTxRound: ResetAndPauseRound, | |||
FinishedRedeemingTxRound: CallCheckpointRound, |
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 means all services, even non-staking ones need to transition here...
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.
Correct. Conceptually, it would not make much sense to add a check to any of the existing rounds on whether we should transition here or not. Therefore, CallCheckpointRound
is always entered and immediately exits if the service is not staked.
) | ||
self._safe_tx_hash = safe_hash[2:] | ||
|
||
def wait_for_condition_with_sleep( |
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.
Why do we need this?
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 order to perform the contract calls in a serialized manner, and only continue to the next step if the current call succeeded. Otherwise, the behaviour sleeps and retries the same call.
def async_act(self) -> Generator: | ||
"""Do the action.""" | ||
with self.context.benchmark_tool.measure(self.behaviour_id).local(): | ||
yield from self.wait_for_condition_with_sleep(self._check_service_staked) |
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 doesn't make sense for non-staking services.
I would have preferred non-staking services never reach this FSM. But given this design, you need at least some sort of boolean to track if this service even needs to do anything here.
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 mean now that it is implemented this way, it will work..
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 does have a boolean in the synced data and checks on-chain only during the first period:
trader/packages/valory/skills/staking_abci/behaviours.py
Lines 230 to 232 in 908bc84
if self.synchronized_data.period_count != 0: | |
self.is_service_staked = self.synchronized_data.is_service_staked | |
return True |
If not staked, it does nothing:
trader/packages/valory/skills/staking_abci/behaviours.py
Lines 298 to 310 in 908bc84
checkpoint_tx_hex = None | |
if self.is_service_staked: | |
yield from self.wait_for_condition_with_sleep(self._get_next_checkpoint) | |
if self.is_checkpoint_reached: | |
checkpoint_tx_hex = yield from self._prepare_safe_tx() | |
tx_submitter = self.matching_round.auto_round_id() | |
payload = CallCheckpointPayload( | |
self.context.agent_address, | |
tx_submitter, | |
checkpoint_tx_hex, | |
self.is_service_staked, | |
) |
As mentioned above, it would not make much sense conceptually to check whether the service is staked in any of the other abcis.
Moreover, this implementation makes this component as much independent as possible, so that future services can easily make use of it.
Also check if the maximum bet amount is available before sending a request, in case that the service is not using the kelly criterion. If the sum of the maximum bet amount and the mech price cannot be covered, then wait until the safe is refilled.
Check max bet amount
No description provided.