feat(dan_layer)!: generate and add checkpoint signatures #4261
Conversation
…tures This is because the protocol requires that we know which if the validators signed each checkpoint
sdbondi
force-pushed
the
dan-layer-committee-checkpoint-signatures
branch
from
30feb7d to
1e28548
Compare
| } | ||
|
|
||
| message SignerSignature { | ||
| bytes signer = 1; |
There was a problem hiding this comment.
nit:
| bytes signer = 1; | |
| bytes signer_pubkey = 1; |
| let request = grpc::CreateInitialAssetCheckpointRequest { | ||
| // TODO: contract id | ||
| contract_id: Vec::from_hex(asset_public_key)?, | ||
| merkle_root, | ||
| committee, | ||
| committee_signatures: None, |
There was a problem hiding this comment.
I take it this is still test/initial code?
Surely the initial checkpoint needs to be signed by the committee?
There was a problem hiding this comment.
yeah this is in the collectibles app, which is a little in limbo at the moment
|
@SWvheerden I don't see a problem with the double hash. The "true" challenge is hashed separately and then the Nonce and Pub Keys are committed to in the signature to prevent reuse. |
Dont get me wrong, I think it's perfectly fine as is, was wondering why double hash it, a single hash is supposed to be perfectly random. |
|
@SWvheerden basically it encapsulates that a SignerSignature must always commit to the public key and nonce, saves the caller from generating a nonce and potentially forgetting to include it in the challenge. The inner challenge will be domain separated. |
Yeah signatures always need to commit to the pubkey and nonce, multisigs need to commit to the hash of the nonce, but that's not required here as its a single signer. |
Yeah more or less. |
Description --- * feat(base_layer): added contract acceptance signature validation * feat(dan_layer): created a new `AcceptanceManager` to centralize the creation, signing and submission of contract acceptances. It's used now both for manual and auto acceptances in the validator node. * refactor(dan_layer): the method `get_current_contract_outputs` in `BaseNodeClient` now return `UtxoMinedInfo` objects. Needed for retrieving the `commitment` of the contract constitution, used in the acceptance signature * refactor(integration_test): unifying of duplicated acceptance steps * fix(integration_test): some fixtures files and steps are outdated Motivation and Context --- Contract acceptances need to be signed by the validator node submitting them. Also, the base layer should validate that the signature is valid. Similar to [recent PRs](#4261), the acceptance signatures follow: `e = H_1(signer_public_key || public_nonce || H_2(contract_id||constitution_commitment))` How Has This Been Tested? --- * New unit test to check the base layer validation of acceptance signatures * For the validation node part, the existing integration test do not raise the signature error
Description --- * New base layer validation of checkpoint signatures: verifies that ALL the signatures present in the checkpoint are valid * Unified the error type for invalid signatures across all contract output types Motivation and Context --- The base layer needs to check if all the signatures in a checkpoint are valid. This PR is based on previous work on checkpoints (see #4261 and #4285). The checkpoint signature is calculated as: `e = H_1(signer_public_key || public_nonce || H_2(contract_id||commitment||merkle_root||checkpoint_number))` But take into account that the `commitment` is still a mock value as of now we still don't have a method for creating a shared value. How Has This Been Tested? --- New unit test checks that invalid signatures are detected
Description
Motivation and Context
DAN committees need to collect signatures to include in checkpoints. This PR adds the initial implementation of that.
The signature challenge is:
e = H_1(signer_public_key || public_nonce || H_2(contract_id||commitment||merkle_root||checkpoint_number))Although constructing a challenge with actual data is a TODO as that involves a bit of a refactor.
This PR also adds the
SignerSignaturestruct that includes the signing public key along with the Schnorr signature tuple<R, s>. This is so that we know which if the validators signed. There may be an aggregate signature scheme that allows this.How Has This Been Tested?
Manually, initial checkpoint contains signature.