doc: Spec of commit public randomness #117
Conversation
gitferry
requested review from
SebastianElvis,
vitsalis,
KonradStaniec,
Lazar955,
RafilxTenfen,
samricotta and
bap2pecs
|
|
||
| ## Commit Process | ||
|
|
||
| ### Generating a Commit |
There was a problem hiding this comment.
I think I would describe here also:
- full commit message used in Babylon (can be link to Babylon proto file)
- the format of randomness i.e 32byte public point
- the merkle tree library used and format of the proof
In general, this spec should have enough details that any body can implement his own randomness committing process.
There was a problem hiding this comment.
Good point! Added useful links in a73f745
docs/commit-pub-rand.md
Outdated
| - Construct the merkle tree based on the list of randomness and save the merkle | ||
| proof of each randomness to the database indexed by height. | ||
| - Construct the commit message based on the root of the merkle tree. | ||
| - Sign the commit message and sent a transaction to Babylon. |
There was a problem hiding this comment.
I would describe here what data is signed and using which signature algo
gitferry
force-pushed
the
gai/docs-commit-pub-rand
branch
from
66cd184 to
a73f745
Compare
docs/commit-pub-rand.md
Outdated
| the request. The details of the generator can be found in [eotsmanager/randgenerator](../eotsmanager/randgenerator/randgenerator.go). | ||
| - Construct the merkle tree based on the list of randomness using the CometBFT's [merkle](https://github.com/cometbft/cometbft/tree/main/crypto/merkle) | ||
| library. | ||
| - Save each randomness along with the merkle |
There was a problem hiding this comment.
hmm I think this is to specific to implementation i.e the fact that we store randomnes and merkle proofs in database is how we decided to do things, and not necessary the only way.
Alternative would be to always regenerate randomnes deterministically from the seed at start from the requested height, and keep active merkle tree in the memory.
Given that db is implementation specific, maybe we can commit it from this list ?
In general, given that this is a spec maybe we should generalize this list i.e avoid as many implementation details as possible. Even the fact that we generate randomness using eotsmanager/randgenerator is a bit implementation specific.
Maybe one thing to mention here, is that it is important that one the commitment happens, the committer must be able to always re-create the committed public randomness somehow (and corresponiding private randomness ) as this is later used in EOTS signature and cannot be changed.
There was a problem hiding this comment.
Makes sense. Improved at ac29934
No description provided.