Document Acceptance Criteria for Random Beacon v2 #2665
Conversation
The document stores User Acceptance Criteria for Random Beacon v2 feature. It will be used to gain common understanding of how Random Beacon v2 should act and will be utilised during the acceptance testing of the feature.
michalinacienciala
force-pushed
the
random-beacon-uacs
branch
from
e8203ba to
b72d78e
Compare
michalinacienciala
changed the title
| higher, the transaction should be reverted) + | ||
| - is there at least one active signing group? | ||
|
|
||
| | Relay request |
There was a problem hiding this comment.
What about the case when relay entry is being requested during group creation?
There was a problem hiding this comment.
It is possible but there is a corner case we should consider. Once group creation starts, the sortition pool is locked and remains in that state until the challenge period passes. A relay request can happen and it can be fulfilled in that time. However, if some members miss their turn during entry submission, we need to remove them from the sortition pool. Removal is not possible when the pool is locked so there is a problem here. We are trying to develop a solution here. @pdyraga and @eth-r can shed more light here.
There was a problem hiding this comment.
I updated the UACs based on what was agreed upon: e9cdc51.
There was a problem hiding this comment.
The latest version is that we are not going to remove anyone from sortition pool in case of misbehavior/inactivity but we will exclude them from future rewards for some governable period of time.
Some new UACs has been added to the list. Bunch of UACs has been updated to better reflect the expected behaviour.
michalinacienciala
force-pushed
the
random-beacon-uacs
branch
from
ba60529 to
416ac5d
Compare
| | If the DKG timeout notification was deemed justified, then: + | ||
| - the pool should be unlocked + | ||
| - the fixed amount reward (in T) should be sent from the maintenance pool to | ||
| the notifier. |
There was a problem hiding this comment.
Should the members of the candidate group be punished for not producing the DKG result with 2 weeks removal from the sortition pool?
There was a problem hiding this comment.
In relay entry, we punish using slashing if the timeout has been violated. However, IIRC it's not the case here. We probably won't punish for DKG timeouts (RFC doesn't mention about that as well) as they are less harmful than relay entry timeouts. @pdyraga is that correct?
There was a problem hiding this comment.
Yes, let's not punish them for now. It could happen that some operators dropped from the pool and honest ones could not produce DKG result. Being in the group and not answering calls is a serious crime. Dropping and not cooperating in DKG is less harmful to the network.
There was a problem hiding this comment.
Ok, thanks for clarification, I don't change anything here then.
michalinacienciala
requested review from
pdyraga,
nkuba,
lukasz-zimnoch,
tomaszslabon and
dimpar
It was agreed that: "In case of a challenge we will get number of blocks that was mined until the challange happened and use it as an offset to: 1. determine new starting block for submissions, so members start submitting from the first member 2. calculate new DKG timeout to give all members a chance to submit a result"
| higher, the transaction should be reverted) + | ||
| - is there at least one active signing group? | ||
|
|
||
| | Relay request |
There was a problem hiding this comment.
It is possible but there is a corner case we should consider. Once group creation starts, the sortition pool is locked and remains in that state until the challenge period passes. A relay request can happen and it can be fulfilled in that time. However, if some members miss their turn during entry submission, we need to remove them from the sortition pool. Removal is not possible when the pool is locked so there is a problem here. We are trying to develop a solution here. @pdyraga and @eth-r can shed more light here.
| | If the DKG timeout notification was deemed justified, then: + | ||
| - the pool should be unlocked + | ||
| - the fixed amount reward (in T) should be sent from the maintenance pool to | ||
| the notifier. |
There was a problem hiding this comment.
In relay entry, we punish using slashing if the timeout has been violated. However, IIRC it's not the case here. We probably won't punish for DKG timeouts (RFC doesn't mention about that as well) as they are less harmful than relay entry timeouts. @pdyraga is that correct?
Each group created in the system remains active for a certain period of time. A group that expired is no longer selected for any new work. Group expiration is performed in the relay request transaction.
| | Governable parameters | ||
| | The slashing amount for submitting malicious DKG result | ||
| (`maliciousDkgResultSlashingAmount`) should be a governable parameter. |
There was a problem hiding this comment.
Not sure if the slashing is for submitting the result or supporting. Asked in https://github.com/keep-network/keep-core/pull/2751/files#r761879103.
| aspects should be taken into account: + | ||
| - does it reference the existing DKG request? (if not, then notification | ||
| invalid) + | ||
| - has the DKG timeout passed? (if not, then notification invalid) + |
There was a problem hiding this comment.
Not sure if that condition need to be always passing.
From the Random beacon README:
DKG timeout includes the situation when no new relay entry was produced and sortition could not be performed.
That means this situation:
Somebody requested a new entry, frequency of group creation was hit, and due to that the sortition pool got locked. Then nobody published the new relay entry and we now want to unlock the pool and will do that in the DGK timeout notification.
From RFC-1 we know that:
The [DKG timeout] timer starts at the moment when the first member becomes eligible [to submit DKG result]
My understanding is that in the case I described we never start the DKG, so we can't say whether the DKG timeout has passed or not...
|
UACs list updated after recent changes to the Random Bacon v2. Ready for another round of reviews. |
Now that we have a set of proposed values for governable parameters in the RandomBeacon contract, we can update the UACs.
|
@tomaszslabon, I applied your propositions, also updated a couple more of parameters. |
The document stores User Acceptance Criteria for Random Beacon v2
feature. It will be used to gain common understanding of how Random
Beacon v2 should act and will be utilised during the acceptance testing
of the feature.