Switch apache milagro with herumi/bls-wasm - #570
Conversation
# Conflicts: # packages/lodestar/src/eth1/wallet.ts # packages/lodestar/src/util/bytes.ts # packages/lodestar/src/util/keystore.ts
Codecov Report
@@ Coverage Diff @@
## master #570 +/- ##
==========================================
- Coverage 64.83% 63.54% -1.29%
==========================================
Files 199 196 -3
Lines 3609 3454 -155
Branches 329 318 -11
==========================================
- Hits 2340 2195 -145
+ Misses 1172 1165 -7
+ Partials 97 94 -3 |
|
Other than the thing about versioning, lgtm |
wemeetagain
left a comment
There was a problem hiding this comment.
Looks great! Much simpler.
Separate thought, if we simplify our code (eg: validator and keystore code), we probably won't even need to use the OO interface to bls, maybe just use a simple IKeypair interface :)
interface IKeypair {
private: Buffer;
public: Buffer;
}and the functional interface exported here in this file
function getPublicKey(priv: Buffer): Buffer;
function sign(priv: Buffer, msg: Buffer, domain: Buffer): Buffer;
function aggregateSignatures(sigs: Buffer[]): Buffer;
function aggregatePublicKeys(pubs: Buffer[]): Buffer;
function verify(pub: Buffer, msg: Buffer, sig: Buffer, domain: Buffer): boolean;
function verifyMultiple(pubs: Buffer[], msgs: Buffer[], sig: Buffer, domain: Buffer): boolean;
Actually, I was thinking of removing those functional interfaces as they are somewhat slower and much less optimized (you have to deserialize buffer and allocate new array to create internal wasm implementation format). Example, keeping PrivateKey instance and using We could see potential speed up if we convert, our validator registry public keys into PublicKey instances once and just use instances. It would shave ~20-30% time on every aggregation and verification |
|
I see, good point. Public keys would be a good thing to store with an "optimized beacon state", along with the committees and other things. |
End-to-end proposer preferences implementation: **Beacon Node:** - New gossip topic `proposer_preferences` with validation, scoring, queue config - ProposerPreferencesPool + SeenProposerPreferences (with pruning) - Validation: epoch+1 check, proposer lookahead match, dedup, BLS signature - Bid validation: require matching preferences (fee_recipient + gas_limit) - API: POST /eth/v1/validator/proposer_preferences (submit) - API: GET /eth/v1/beacon/pool/proposer_preferences (query) - SSE event: proposer_preferences - Metrics: pool size, gossip/api insert outcomes **Validator Client:** - pollProposerPreferences: epoch-boundary polling, queries next-epoch proposer duties, signs preferences with fee_recipient/gas_limit, submits to BN - ValidatorStore.signProposerPreferences with DOMAIN_PROPOSER_PREFERENCES - External signer support (PROPOSER_PREFERENCES message type) **State Transition:** - getProposerPreferencesSigningRoot helper Addresses beacon-APIs ChainSafe#570 and ChainSafe#435. Resolves TODO GLOAS comments in bid validation. Generated with assistance from AI (Codex CLI + Claude).
resolves #566