BLS Signatures

[frrist]

Why is BLS important?

Functionally, BLS signature aggregation enables the Filecoin network to store more client data by reducing the on-chain storage requirement of each signed message.
Because this represents a protocol change that affects wallets, exchanges, and signature specs, this effort will need to be completed before launch. This effort will be a block to launch. Note that BLS signature aggregation is less of a feature and more of a core protocol component.

BLS allows signatures for message signatures to be aggregated into a single signature and placed on a block. This means we only need to store one signature per block instead of N signature, where N is the number of messages in the block. This allows us to reduce the size of our chain.

Birds-Eye View of Changes

• go-filecoin will use bls-signatures to sign, verify, and aggregate signatures in addition to generating the public/private keys used to produce the signatures. bls-signatures is written in rust and will require a cgo wrapper.
• Signatures in messages shouldn't be included on chain (this is how we save space). Signatures should be attached to messages when propagating them out, but the messages in blocks will be different than the messages broadcasted to peers.
• Miners need to aggregate signatures when mining a block. This implies a new field will need to be added to blocks, said field should contain the signature representing the aggregate signature of all messages contained by the block.
• Actors will need to store their public keys
  • Quick and dirty solution: Message.To contains the entire public key when creating an actor.
  • Long term thought: Add a field to the account actor to store the public key.
    • This implies a new method/actor being needed for actor creation. One idea is to add an AccountManager Actor that accepts CreateAccountActor messages and manages the actor creation process.
• Actors will need an ID, said ID is a monotonically increasing value that is generated when an actor is created. An Actor may be referenced by its ID, its Address or its Public Key. A map of ID -> Actor and a map of PublicKey -> ID will need to be maintained.
  • Said maps will allow for:
    • Key cycling, it is common practice to cycle out keys every so often for security reasons.
    • ID reuse, saves space
  • Said maps should not be kept on chain, they should instead be built by a filecoin node during its sync process.
• Verifying a block must now verify the blocks signature
  • Requires getting the public keys for each message in the block (see above points for details on getting public keys)
• Verifying Block Mining Ticket signatures will need additional consideration.
  • TODO

Acceptance Criteria (List is WIP)

• Must close out Signature code and tests should be in one, reasonable place. #1326
• All new Code has Unit Tests
  • No shortcuts are taken in the tests! -- test work at least as "real" as they do today unless we agree otherwise
• Timebox @frrist to <= %20
• this work is done (COMPLETELY!) when this epit is closed out, meaning zero technical debt deferred, follow-up issues, TODO's for missing features that could be implemented today, tests, places in the code where we should be using it but aren't, etc. ; see "do not create technical debt" section of https://github.com/filecoin-project/go-filecoin/blob/master/CONTRIBUTING.md#developer-dos-and-donts

Design Doc

https://docs.google.com/document/d/1W6eKt5kuLF9zZmwIdiQl2-UAs2VJg-KqO3ti2fYVN_M/edit

[phritz]

Actors will need to store their public keys
Quick and dirty solution: Message.To contains the entire public key when creating an actor.
Long term thought: Add a field to the account actor to store the public key.
This implies a new method/actor being needed for actor creation. One idea is to add an AccountManager Actor that accepts CreateAccountActor messages and manages the actor creation process.

The fact that we want to assign monotonically increasing ids argues for an account manager actor that can store the next available id. An actor's id and public key can be stored in the actor. I think you should probably go this route.

Note that miner creation should probably move to the account manager and we should take the functionality off the vmcontext (bc it lives on the account manager): https://github.com/filecoin-project/go-filecoin/blob/29325c33caaa484ebe395fc5d26fd876cbdb86c3/actor/builtin/storagemarket/storagemarket.go#L109

How does upgrading work in this new world?

Timebox @frrist to <= %20

The original arrangement was for frrist to spend time helping @bvohaska come up to speed to do this work, which is why we timeboxed frrist's involvement to 20%. Something seems to have changed, now frrist is on the hook for all the work? If so then we need to shuttle this item through our normal dev process. The only reason it didn't go through the process in the first place is because it was characterized as consultation / helping someone come up to speed. (We also need to answer the question of why frrist is the right person to do this. Not saying he isn't, just saying that he represents 50% of our dev infra firepower.)

WRT priority my understanding is that one of the reasons to do this now is because exchanges will need time to implement. I'm not sure how compelling I find this given that launch isn't exactly imminent.

[phritz]

• how does this affect message wait and things that use message cids? the cid of the signed message will be different from the cid of the unsigned message. the cid in the message pool of a signed message might be different than the on chain cid in the block. what about cids returned by commands? this seems like something we need to answer up front.
• unclear to me whether use a signature for the ticket #1054 should proceed ahead of this work. i think yes and you convert it?
• see also many comments in the issues, i think we need to make this epic a little more concrete, which i realize may be hard for you given that it requires a lot of go-filecoin internal context. please rely on me and @acruikshank to help when you need us.

[phritz]

• use message cid everywhere, not signedmessage cid

[whyrusleeping]

Actors will need to store their public keys

What we talked about here was that when sending funds to a non-existent actor, you set the to field of the message to the public key. Then, during message processing, a new account actor is created, and it gets that public key set into its internal state. Note: This also removes the ambiguity around new actor creation (we don't have to do the weird 'upgrade' thing, as actors will have unambiguous addresses)

I would say to keep new actor creation the same as it is, for now. Adding in the 'Init Actor' (what we previously talked about calling the actor responsible for creating new actors) will require a bit of extra consideration (what happens if users can create their own copy of the storage market actor? Or miner actors?)

@phritz

The original arrangement was for frrist to spend time helping @bvohaska come up to speed to do this work

@frrist did the initial signatures work, and this work will likely be much easier for him to do than anyone else (especially compared to brian, who is not ramped up on the codebase).

[frrist]

What we talked about here was that when sending funds to a non-existent actor, you set the to field of the message to the public key

@phritz from our discussion in storytime yesterday; this is the reason for being able to use a public key as an address -- we create an actor by sending some filecoin to a public key -- will update #1607