Ethereum provides robust capabilities for typed message signing, particularly through EIP-191 and EIP-712. These Ethereum Improvement Proposals enhance the security and usability of signing data on the Ethereum blockchain.Documentation Index
Fetch the complete documentation index at: https://fireblocks-43c4b3ee-chore-add-cli.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
EIP-191: Versioned Signatures
EIP-191 specifies a standard for signing messages that includes a versioning scheme. The version byte in the signature tells how the message should be structured, enabling multiple types of signatures under a single framework.How EIP-191 Works
- Prefix Addition: A standard prefix
\x19Ethereum Signed Message:\nis added to the message. This prefix includes a declaration of the length of the message that follows, which helps ensure that the message is exactly as intended when signed and verified. - Message Concatenation: The length of the message and the message itself are then concatenated following the prefix.
- Hashing: The entire string (prefix + length + message) is typically hashed using a cryptographic hash function like
keccak-256. - Signing: The resulting hash is then signed using the private key associated with the Ethereum address of the signer.
EIP-712: Signing Structured Data
EIP-712 takes typed message signing further by introducing a standard for signing structured data that humans and machines can read. This EIP aims to make blockchain interactions as understandable as possible, providing users with a clear understanding of what they are signing, thereby reducing the risk of malicious activities.How EIP-712 Works
- Data Typing and Structuring: Data is structured into types, each defined with a name and a series of fields. EIP-712 allows you to define custom types in addition to predefined types.
- Domain Separation: EIP-712 introduces the concept of domain separation, which allows different applications to define their own unique “domains” to prevent signature collisions. A domain includes defining the contract’s name, version, and the chain it’s deployed on.
- Message Creation: The message to be signed is composed of typed data according to the specified schema. This can include multiple fields and data types.
- Signing the Data: Users sign the structured data using their private keys. This signature can be verified against the signer’s public key.
- Verification: The smart contract can then verify the signature directly by reconstructing the typed data and using the signer’s public address.
Ethereum Typed Message Signing in Fireblocks:
Fireblocks supports both EIP-191 and EIP-712 Typed Message Signing. Additionally, Fireblocks users can sign Typed Messages for any EVM-compatible blockchain supported by Fireblocks. This capability is facilitated by all EVM networks using the same address derivation, resulting in the same address within the same vault account.For any EVM compatible network other than Ethereum, users must still specify ETH as the assetId when calling the API.Below you can find TypeScript SDK examples on how to use Fireblocks for EIP712 and EIP191 Typed Message Signing:
Structuring the Signature
Once the Typed Message Signing request is successfully signed, you can retrieve the transaction using the Get Transaction By TxId Endpoint. The signed transaction will appear in the following format:signedMessages array. Within this object, the signature object contains three components: r, s, and v:
r: This is the first 32 bytes of the signature, representing the X coordinate of the point on the elliptic curves: This is the second 32 bytes of the signature, representing the scalar component of the elliptic curve pointv: This parameter is crucial for correctly reconstructing the public key used in signing. It helps distinguish between the possible public keys that could correspond to the signature
v value is calculated, a modification introduced by EIP-155.
EIP-155 prevents certain types of replay attacks by incorporating the chainId into the v value:
chainId value when working with any EVM-based blockchain as it directly affects the calculation of the v parameter.
Properly calculating v ensures that the signature correctly corresponds to the network on which the transaction is intended, thus preventing cross-chain replay attacks.
A full list of EVM Networks chainId values can be found here.