Conversation
`bundle_solution` and `signature` have been added into `BundleHeader` since this commit, which means the proof of election can be verified using only the header now, rendering the `SignedBundle` useless.
Since `BundleHeader` encompasses the bundle solution and signature now, we can update the interface between the domain and consensus chain, eliminating the usages of `SignedOpaqueBundle`.
They're useless and all the usages have been removed.
The sole difference between `PreliminaryBundleHeader` and `BundleHeader` is the signature, similar to the typical post digests in Substrate block header.
| pub bundle_solution: BundleSolution<DomainHash>, | ||
| /// Signature of the bundle. | ||
| pub signature: ExecutorSignature, | ||
| } |
There was a problem hiding this comment.
Why not nesting BundleHeader in SignedBundleHeader or SealedBundleHeader? This is a strange approach and the only reason for it I can come up with is such that some of existing code doesn't need to change.
There was a problem hiding this comment.
I hesitated to nest the BundleHeader because, in most cases, we primarily work with the SealBundleHeader instead of the BundleHeader. To facilitate working with the SealBundleHeader more conveniently, I opted to make the default assumption and enable direct usage of header.foo instead of sealed_header.header.foo.
The naming you suggested looks good to me though, I can rename them to BundleHeader and SealedBundleHeader.
There was a problem hiding this comment.
You can always do let header = sealed_header.header; and the rest of the code will be just like it was before. It is less pretty in my opinion that you need to construct a separate data structure to sign it, also during refactoring when new field is added you need to not forget to add it to the data structure that you sign. Just feels unnecessarily tricky.
There was a problem hiding this comment.
The concern of missing a field during the refactoring makes sense, I'm not super satisfied with let header = sealed_header.header;, but happy to take this suggestion.
4 participants
The main point in this PR is to move
bundle_solutionandsignaturein the previousSignedBundleintoBundleHeader, no logical processing changes. Now we havePreliminaryBundleHeadercontaining everything in the correspondingBundleHeaderbut the signature, domain operator signs the hash ofPreliminaryBundleHeaderand then use the signature to create the finalBundleHeaderwhen producing a bundle.Close #1485
Code contributor checklist: