Delegation design Update #279
Conversation
| Operational keys will use key evolving signatures (KES). To be precise, we will | ||
| use keys according to the MMM scheme \citep{cryptoeprint:2001:034}, with 1-day | ||
| regular updates and a key lifetime of \(2^7 = 128\) days, a little over three | ||
| months. |
There was a problem hiding this comment.
We should perhaps clarify that this is the number of slots equivalent to one day. And I think the terminology is key "evloution" rather than "update".
| \subsection{Stakepool Metadata} | ||
| \label{stakepool-metadata} | ||
|
|
||
| The stake pool registration certificate can contain a URL (up to 32 bytes), |
There was a problem hiding this comment.
Didn't we say 64bytes above?
| Those servers are simple, and in particular, they require relatively little | ||
| trust: because of the content hash, someone running a proxy server can not | ||
| display forged metadata.\todo{Is this actually sufficient, or should | ||
| we require the metadata to be signed by the pool's key?} The worst thing they |
There was a problem hiding this comment.
The hash of the metadata is witnessed by the pool's operator key. I'm pretty sure that's sufficient.
There was a problem hiding this comment.
Ok, I'll remove the TODO. Thanks!
| In order for stakeholders to be able to delegate their stake to a pool, the | ||
| wallet will provide a listing of stake pools, in a section of the UI called the | ||
| \emph{delegation centre}. In order to make it easy for users to do a rational | ||
| choice when delegfating, this listing will be ordered by the rewards that the |
| @@ -2283,7 +2332,8 @@ \subsection{Display of Stake Pools in the Wallet} | |||
| wallet should monitor the non-myopic rewards regularly. Should the stake pool | |||
| become less favourable (by missing blocks, or even becoming inactive, or by | |||
| changing its cost/margin), the wallet should notify the user, and ask them to | |||
| consider changing their delegation. | |||
| consider changing their delegation.\todo{Specify how many places the pool has to | |||
| drop in order to trigger this notification} | |||
There was a problem hiding this comment.
Yeah, if it's about order, or absolute or relative change in the quality metric. Needs input from the researchers.
| Also, we require that within any given chain, if there are two blocks A and B | ||
| signed using operational key certificates issued by the same cold key, if A is | ||
| an older block than B, the counter in the operational certificate in the | ||
| witness of B must be at least as large as the one in the counter in the |
There was a problem hiding this comment.
I think "in the witness of" B isn't right, it's just in the cert itself. The cert is in the header, and then the header is signed. I think it's enough to say in the cert, or in the cert in the header of B.
There was a problem hiding this comment.
Right. I'll also change it to "certificate in the header of A" in the next line.
| the obligation of the stake pool operator that this URL points to a JSON | ||
| object containing the metadata of the pool, as described in | ||
| \cref{stakepool-metadata}. The content hash of that JSON object should match | ||
| the content hash in the registration certificate. |
There was a problem hiding this comment.
what should happen if they don't match? Would the wallet simply highlight this in its listing?
There was a problem hiding this comment.
No, we'll not display such a stake pool. The content hash is used to verify that the metadata is correct.
There was a problem hiding this comment.
Good catch, I'll add a line.
| \item[A list of IP addresses and/or Domain Names] | ||
| of public relay nodes that the stake pool operator provides to contribute to | ||
| the Cardano network. | ||
| \item[A set of tags] |
There was a problem hiding this comment.
Right, this requires some explanation.
kantp
force-pushed
the
delegation-design-1.3
branch
from
0ac4ebe
to
7286d84
Compare
kantp
force-pushed
the
delegation-design-1.3
branch
from
7286d84
to
34beb4b
Compare
We can not move them to the rewards pool -- if we did, it would create an incentive for all other leaders to censor a certificate that caused the pool to use a valid certificate.
The paragraph was not entirely true, it said there was only one possible source of funds in addition to UTxO entries, but with rewards accounts, there is another one.
I had written that a "witness must be signed by key x", when I meant to say that the witness should contain a signature of that key.
Replacing an explanation of the concept with a link to the section where it's already explained. Fixed a reference.
Specify the format for the metadata, and how it is provided. Streamline the different sections that touch stake pool metadata.
The subsection was named "Theoretical Proposal", but since we have since discussed it at length and will go for this proposal, "Mechanism" is a more fitting heading.
Update docs/delegation_design_spec/delegation_design_spec.tex Co-Authored-By: kantp <philipp.kant7@gmail.com>
kantp
force-pushed
the
delegation-design-1.3
branch
from
34beb4b
to
409e46a
Compare
|
Rebased on current master and force-pushed, to fix the builds. |
Further updates to the design document, following Berlin and more recent discussions.