How To Signal EIP-712 Structured Knowledge With MetaMask | by Laszlo Fazekas | Oct, 2023

MetaMask is among the most used crypto wallets, however it presents far more than that. With its assist, we have now the chance to digitally signal information constructions, which might be utilized in many various methods. One choice is to make use of MetaMask for authenticating our customers. On this case, we determine our customers with an Ethereum tackle as an alternative of a password. The consumer proves possession of the Ethereum tackle by digitally signing an information construction, and the signature is then validated on the server aspect. As MetaMask securely shops our personal key and even presents the choice to make use of {hardware} wallets, one of these authentication is far more safe than conventional password-based options.

There may be additionally the choice to signal sure API calls with MetaMask. For instance, within the case of a monetary service, along with MetaMask authentication, we are able to signal particular person monetary transactions individually, making them far more safe.

MetaMask signatures might be validated on the blockchain with the assistance of a wise contract. One space of use for that is metatransactions. With metatransactions, we are able to simplify using blockchain functions for customers. Within the case of metatransactions, the transaction charges are paid by a relay server as an alternative of the consumer, so the consumer doesn’t must have cryptocurrency. The consumer merely places collectively the transaction, indicators it utilizing MetaMask, and sends it to the relay server, which then forwards it to a wise contract. The good contract validates the digital signature and executes the transaction.

After concept, let’s check out the apply.

The EIP-712 customary defines the way to signal structured information packages in a standardized method. MetaMask shows these structured information in a readable format for the consumer. An EIP-712 compliant construction, as proven on MetaMask (might be examined on this URL) seems like this:

The above transaction was generated utilizing the next easy code:

    async operate primary() {
if (!window.ethereum || !window.ethereum.isMetaMask) {
console.log("Please set up MetaMask")
return
}
const accounts = await window.ethereum.request({ methodology: 'eth_requestAccounts' });
const chainId = await window.ethereum.request({ methodology: 'eth_chainId' });
const eip712domain_type_definition = {
"EIP712Domain": [
{
"name": "name",
"type": "string"
},
{
"name": "version",
"type": "string"
},
{
"name": "chainId",
"type": "uint256"
},
{
"name": "verifyingContract",
"type": "address"
}
]
}
const karma_request_domain = {
"identify": "Karma Request",
"model": "1",
"chainId": chainId,
"verifyingContract": "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC"
}
doc.getElementById('transfer_request')?.addEventListener("click on", async operate () {
const transfer_request = {
"varieties": {
...eip712domain_type_definition,
"TransferRequest": [
{
"name": "to",
"type": "address"
},
{
"name": "amount",
"type": "uint256"
}
]
},
"primaryType": "TransferRequest",
"area": karma_request_domain,
"message": {
"to": "0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC",
"quantity": 1234
}
}
let signature = await window.ethereum.request({
"methodology": "eth_signTypedData_v4",
"params": [
accounts[0],
transfer_request
]
})
alert("Signature: " + signature)
})
}
primary()

The eip712domain_type_definition is an outline of a common construction, which comprises the metadata. The identify subject is the identify of the construction, the model subject is the definition model of the construction, and the chainId and verifyingContract fields decide which contract the message is meant for. The executing contract verifies this metadata as a way to be sure that the signed transaction is simply executed on the goal contract.

The karma_request_domain comprises the precise worth of the metadata outlined by the EIP712Domain construction.

The precise construction that we ship to MetaMask for signature is contained within the transfer_request variable. The kinds block comprises the sort definitions. Right here, the primary ingredient is the obligatory EIP712Domain definition, which describes the metadata. That is adopted by the precise construction definition, which on this case is the TransferRequest. That is the construction that can seem in MetaMask for the consumer. The area block comprises the precise worth of the metadata, whereas the message comprises the precise construction that we need to signal with the consumer.

The signature might be simply validated on the server aspect by utilizing the eth-sig-util:

import { recoverTypedSignature } from '@metamask/eth-sig-util'
const tackle = recoverTypedSignature({
information: typedData,
signature: signature,
model: SignTypedDataVersion.V4
}))

The recoverTypedSignature operate has three parameters. The primary parameter is the structured information, the second is the signature, and the final is the signature model. The return worth of the operate is the recovered Ethereum tackle.

Now, let’s see how the signature might be validated on-chain by a wise contract. The code is from my karma cash repo (you may learn extra about karma cash right here). The next TypeScript code sends a meta transaction to the karma cash good contract:

const varieties = {
"TransferRequest": [
{
"name": "from",
"type": "address"
},
{
"name": "to",
"type": "address"
},
{
"name": "amount",
"type": "uint256"
},
{
"name": "fee",
"type": "uint256"
},
{
"name": "nonce",
"type": "uint256"
}
]
}
let nonce = await contract.join(MINER).getNonce(ALICE.tackle)
const message = {
"from": ALICE.tackle,
"to": JOHN.tackle,
"quantity": 10,
"charge": 1,
"nonce": nonce
}
const signature = await ALICE.signTypedData(karma_request_domain, 
varieties, message)
await contract.join(MINER).metaTransfer(ALICE.tackle, JOHN.tackle, 
10, 1, nonce, signature)
assert.equal(await contract.balanceOf(ALICE.tackle), ethers.toBigInt(11))

The varieties variable defines the construction of the transaction. The “from” is the tackle of the sender, whereas the “to” is the tackle of the recipient. The quantity represents the amount of tokens to be transferred. The charge is the “quantity” of tokens that we provide to the relay node in change for executing our transaction and protecting the fee within the native forex of the chain. The “nonce” serves as a counter to make sure the individuality of the transaction. With out this subject, a transaction could possibly be executed a number of instances. Nevertheless, due to the nonce, a signed transaction can solely be executed as soon as.

The signTypedData operate offered by ethers.js makes it simple to signal EIP-712 constructions. It does the identical factor because the code offered earlier however with a less complicated utilization.

The metaTransfer is the strategy of the karma contract for executing meta-transaction.

Let’s see the way it works:

    operate metaTransfer(
tackle from,
tackle to,
uint256 quantity,
uint256 charge,
uint256 nonce,
bytes calldata signature
) public digital returns (bool) {
uint256 currentNonce = _useNonce(from, nonce);
(tackle recoveredAddress, ECDSA.RecoverError err) = ECDSA.tryRecover(
_hashTypedDataV4(
keccak256(
abi.encode(
TRANSFER_REQUEST_TYPEHASH,
from,
to,
quantity,
charge,
currentNonce
)
)
),
signature
);
require(
err == ECDSA.RecoverError.NoError && recoveredAddress == from,
"Signature error"
);
_transfer(recoveredAddress, to, quantity);
_transfer(recoveredAddress, msg.sender, charge);
return true;
}

So as to validate the signature, we should first generate the hash of the construction. The precise steps for doing this are described intimately within the EIP-712 customary, which features a pattern good contract and a pattern javascript code.

In abstract, the essence is that we mix the TYPEHASH (which is the hash of the construction description) with the fields of the construction utilizing abi.encode. Then produces a keccak256 hash. The hash is handed to the _hashTypedDataV4 methodology, inherited from the EIP712 OpenZeppelin contract within the Karma contract. This operate provides metadata to our construction and generates the ultimate hash, making construction validation quite simple and clear. The outermost operate is ECDSA.tryRecover, which makes an attempt to recuperate the signer’s tackle from the hash and signature. If it matches the tackle of the “from“ parameter, the signature is legitimate. On the finish of the code, the precise transaction is executed, and the relay node performing the transaction receives the charge.

EIP-712 is a common customary for signing constructions, making it simply one in all many makes use of for implementing meta-transactions. Because the signature might be validated not solely with good contracts, it will also be very helpful in non-blockchain functions. For instance, it may be used for server-side authentication, the place the consumer identifies themselves with their personal key. Such a system can present a excessive stage of safety sometimes related to cryptocurrencies, permitting for the opportunity of utilizing an internet utility solely with a {hardware} key. As well as, particular person API calls will also be signed with the assistance of MetaMask.

I hope that this transient overview of the EIP-712 customary has been inspiring for a lot of and that it is possible for you to to put it to use in each blockchain-based and non-blockchain initiatives.