Skip to content

api::AggregatedTranscript serialization issue in nucypher/nucypher #209

@cygnusv

Description

@cygnusv

A tiny side-effect of the huge Recovery & Refresh refactor (#188), back from March 2024, included a subtle change in api::AggregatedTranscript, which is the exposed view of aggregate transcripts which we have from nucypher/nucypher. This change (see 315d2b4#diff-851e635fce0c36223c8a78c17a4b97f59ab5810b784bc4e44939ec09c1331a8fR263) implied that the aggregate transcript struct now includes the DKG public key explicitly. This interface is adequate for abstraction reasons since higher layers will often ask for the the public key associated to an aggregate, but introduces redundancy when serializing, since the public key can be extracted from the aggregate transcript.

This was only caught when working on a preliminary integration of this epic in nucypher/nucypher, since the Coordinator contract checks aggregate transcript sizes, which are now unnecessarily bigger due to the extra public key. A simple workaround at the nucypher/nucypher level is to send only the transcript part to the contract, and conversely, appending the public key when deserializing from it. As a permanent fix, there's two options:

  • Make api::AggregatedTranscript a mere wrapper around pvss:PubliclyVerifiableSS, and derive the DKG public key from the PubliclyVerifiableSS on the fly (this is merely returning PubliclyVerifiableSS.coeffs[0]). This implies that serialized api::AggregatedTranscript would only include serialized pvss:PubliclyVerifiableSS.
  • Leave api::AggregatedTranscript struct as is but tweak its serialization so that public keys are not included, and are extracted at deserialization time from the transcript data (similarly as the option above).

Note that a similar issue, this time only as an optimization, also happens in the Coordinator contract at aggregation posting time (see nucypher/nucypher-contracts#108); i.e., no need to pass the public key explicitly since the aggregate transcript is also sent as part of the transaction.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions