Post certifier service #144
Conversation
poszu
force-pushed
the
post-certifier-service
branch
from
dc9932b to
e883bf0
Compare
Codecov Report
@@ Coverage Diff @@
## main #144 +/- ##
==========================================
- Coverage 94.25% 93.84% -0.42%
==========================================
Files 22 24 +2
Lines 2978 3004 +26
==========================================
+ Hits 2807 2819 +12
- Misses 171 185 +14
|
poszu
force-pushed
the
post-certifier-service
branch
from
9f9a32e to
58d4d17
Compare
| init_cfg: | ||
| min_num_units: 4 | ||
| max_num_units: 99999 | ||
| labels_per_unit: 4294967296 | ||
| scrypt: | ||
| n: 8192 | ||
| r: 1 | ||
| p: 1 | ||
|
|
||
| metrics: "127.0.0.1:9090" |
There was a problem hiding this comment.
Can this somehow be gamed by only init the minimum amount generating a proof of that to get a certificate and then keep initializing, i.e. the effort to get a certificate isn't dependent on the post size?
Would this lead to reasonable smeshers to always init the minimum for the certificate (unless they already have a proof for a bigger size)?
There was a problem hiding this comment.
It probably is OK though since the PoW is also the same difficulty independent of PoST size.
There was a problem hiding this comment.
Yes, one could initialize 4 units, create a POST proof, certify with it, and then keep initializing. It doesn't matter because we only want to confirm that a smesher spent significant resources and has a valid POST (at some point in time).
| pub challenge: [u8; 32], | ||
| pub num_units: u32, | ||
| pub labels_per_unit: u64, |
There was a problem hiding this comment.
Will this cause the value to also be dropped from the json file? We should check if that breaks the node internal initializer in the "supervised" setup.
There was a problem hiding this comment.
It won't break because I removed labels_per_unit from the proof metadata structure. The initializer uses a different structure for the post metadata.
Closes #146
A certifier service that creates certificates for a node confirming it holds a valid POST proof.
The client (presumably the spacemesh node) submits a POST proof with its metadata to the certifier on
/certifyHTTP endpoint. The certifier validates the proof and, if valid - signs the nodeID and returns the signature. If the proof is invalid it returns a 403 status code.The client can later use this certificate to register in a poet. The poet is supposed to know the certifier's public key and verify the signature over a node ID.