search

filecoin-project / venus

Filecoin Full Node Implementation in Go
https://venus.filecoin.io
Other
2.06k stars 462 forks source link

Produce sensible key (proverId) from miner address during sealing #493

Closed laser closed 6 years ago

laser commented 6 years ago

Description

See: https://github.com/filecoin-project/go-filecoin/issues/474

Quoting my last comment on the issue:

Without going into gratuitous detail here, the safe way to handle this is for the Filecoin Node to pass a maximum of 254 significant bits to FPS (Filecoin Proving Subsystem). This underlying fact allows for a variety of possible answers to the question at hand. Whichever one we select will need to be specified carefully, since there ways to get it wrong. I don't want this comment to be the canonical specification, though – so I will break further discussion out in #493.

Based on the above, the simplest thing might be to hash to 31 bytes and pad with a terminal zero byte in all cases. This would satisfy the requirements without getting too complicated.

Alternately, for the sake of simplicity, we could define the input to just be 31 bytes.

The latter solution would prevent Filecoin from using all available bits, but is that actually important?

Acceptance Criteria

Along with implementation, whatever decision gets made needs to be communicated to the FPS team so it can be reflected in the API.

laser commented 6 years ago

I talked to @dignifiedquire about this today.

My plan is to zero-pad the address public key-hash (already a 20-byte BLAKE2b digest) to 31 bytes and send that hash to the FPS as "prover id".

If I use the output of the Address#Hash method, I ensure forward compatibility with any address format-changes.