frrist
commented
5 years ago Things that ought to happen before work is continued on BLS:
-
Init Actor Spec and Implementation
- Related:
- PR of initial Init Actor sketch: https://github.com/filecoin-project/specs/pull/169
- Reason: A requirement of using BLS signatures in go-filecoin is storing BLS public keys of actors on chain. Public keys are needed to perform block validation. The required modifications have been made to the address code to support storing public keys, but the be details of the actor creation process still need to be worked out. Currently an actor is only created when funds are sent to its account -- this will not work moving forward.
-
Actors can be referenced by ID's
- Related:
- Issues related to discussion: https://github.com/filecoin-project/specs/issues/170
- Reason: The main benefit of BLS is the signature aggregation, it allows us to verify multiple messages with a single signature. However, as was stated above, actors using BLS will need to store their public keys on chain. Referencing actotrs by their BLS public keys is costly due to their size. We cannot hash the keys like we do for secp256k1, since BLS keys lack a recovery property. In order to reap the benefit of BLS we will need a more compact way of referencing actors, assigning actors an ID at creation is the current proposed solution.
-
Multikey Spec and Implementation:
- Related:
- No relevant info.
- Reason: Since go-filecoin will allow for actors to use SECP256K1 keys in addition to BLS keys we will more than likely need a way to determine the difference between the keys when they are serialized to bytes.
-
Multisig (currently called Multi-John-Hancock due to name collisions) Spec and Implementation:
- Related:
- No relevant info.
- Impact: For the same reason we need Multikey, we will also need "MultiJH". When marshaling and unmarshaling signatures generated by different keys (BLS, and Secp256k1) we will need a means of identifying which key they came from.
anorth
@frrist has work in progress on BLS signature integration, the scope of which quickly expanded and we decided to postpone it in favour of a focus on other deliverables for now.
@frrist please dump your mental state of the work so that we (possibly someone else) can pick it up cleanly in the future. In this issue is probably a good enough place.