Skip to content

v0.22.2

Choose a tag to compare

View all tags
@BRBussy BRBussy released this 19 Sep 16:39
· 48 commits to main since this release
v0.22.2
64328e2
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Highlights

  • The request signing key is derivable as a key, not only as its EVM address: deriveMidnightRequestSigningKey returns the public key the MPC signs a contract's requests with (#119).
  • Request records derive their own signer: two functions take an on-ledger request record and own the MPC's rendering of its sender and path into the derivation string, which every consumer did by hand until now (#119).

New features

  • deriveMidnightRequestSigningKey(mpcSecp256k1PublicKey, contractAddress, path): the request signing public key as a Secp256k1Point, the request-side twin of deriveMidnightResponseKey. Format it with formatSecp256k1PublicKey (#119).
  • deriveSignBidirectionalEventSigningKey(mpcSecp256k1PublicKey, request) and deriveSignBidirectionalEventSignerEvmAddress(mpcSecp256k1PublicKey, request): the same key, and its EVM address, from a request record. The requester is the record's sender, and the path is the lowercase hex of its full 32 path bytes, exactly as the MPC renders it. The address is the expectedSigner that verifySignatureRespondedEvent takes (#119).
  • SignBidirectionalEventKeySelector: the two record fields (sender, path) that select a request signing key, so a caller can pass a whole record or just those two (#119).
  • asciiUnpadded(bytes): the inverse of asciiPadded, for the zero-padded text fields of a request record (caip2Id, the two schemas). Only trailing zero bytes are padding: a zero byte inside the text is kept (#119).

Refactoring

  • deriveEvmAddress is defined as the address of deriveMidnightRequestSigningKey, so the key and its address cannot drift apart. Its golden vectors pass unchanged (#119).
  • decodeSignetEventName goes through asciiUnpadded, leaving the package one implementation of the unpadding (#119).
  • The new key functions are pinned to the existing independent golden addresses: a key whose EVM address matches a golden vector is the key that vector was constructed from, so no vector was generated from the code under test (#119).

Breaking changes

  • None. The release is additive: no existing export changes its signature or its output.

Full Changelog: v0.22.1...v0.22.2

Assets 2
Loading