EVM (Ethereum) Vault Design
Ethereum was the first blockchain to succesfully introduce smart contracts and is the leading smart contract blockchain using the EVM (Ethereum Virtual Machine). The Chainflip Vault secures the native asset as well as the supported ERC20 tokens in each EVM chain. It is uniquely designed in a way that the Chainflip Validator Network always keeps control over the funds secured in the Vault.
Features of the EVM (Ethereum) Vault Design
- Access funds using Schnorr Signatures as generated by our FROST protocol as part of the transaction payload.
- Deterministically generate and manage an arbitrary number of Deposit Channel Addresses (Ingress Addresses) that hold funds that only the Vault can access.
- Reusal of deposit channels to reduce gas costs.
- Batching capabilities to drastically reduce gas costs.
- Ability to perform a “key rotation” from one Authority Set to the next, whilst maintaining access to older deposit channels.
- Entry point for initiating swaps via a smart contract call.
- Cross-Chain Messaging (CCM) capabilities
Accessing Vault funds using FROST Protocol Schnorr Signatures
Ethereum doesn't natively support FROST Protocol Schnorr Signatures as part of the EVM signature verification specifications. To overcome this, we have implemented a KeyManager smart contract that can verify FROST Protocol Schnorr Signatures using the aggregate key stored in the contract. This smart contract is deployed on each EVM chain and is used to verify the signatures included in the transactions' payload. Every transaction that accesses funds in the Vault requires a payload with a signature that is verified. Without a valid signature no funds can be accessed.
Generation and management of Deposit Channel Addresses
The Chainflip protocol opens deposit channel addresses for every swap. To do that, it precomutes the address where a Deposit smart contract will be deployed using the create2 opcode with a predetermined salt for each swap. When the user makes a deposit to that address, the deposit is witnessed and a Deposit contract is deployed in that address to fetch the assets.
Deploying a smart contract is an expensive operation that requires a lot of gas. In order to reduce the gas costs, and therefore the fees for the users, already deployed Deposit Channels are reused for successive swaps. When a channel opened for one user expires, it becomes available for a future user. Then, the Vault only needs to fetch from the Deposit Channel to sweep the assets from the Deposit Channel to the Vault and doesn't require a new deployment.
This optimization not only reduces the cost of fetching the assets but it also allows for deposits of native assets to be directly funneled atomically from an already deployed Deposit smart contract channel into the Vault upon deposit, without the need of performing an additional fetch from the Vault.
Batching capabilities to drastically reduce gas costs
The Vault smart contract allows for batching multiple actions into a single transaction. A single signature verification can be used for multiple transfers and fetch actions. Given that the signature verification is significantly more expensive than the actual transfer or fetch actions, this drastically reduces the gas costs (and therefore fees) per swap.
To illustrate the point, let's use some approximate numbers - a signature verification is ~80k gas and an asset transfer is ~10k within the Vault logic.
- 1 transfer = 80k + 10k = 90k gas === 90k gas per transfer
- 2 transfers = 80k + 2 * 10k = 100k gas === 50k gas per transfer
- 5 transfers = 80k + 5 * 10k = 130k gas === 26k gas per transfer
It's clear that the gas costs per swap decreases significantly as the number of batched actions increase. The more swaps processed by Chainflip's Vault the cheaper it becomes for users. This enhances Chainflip's scalability.
EVM (Ethereum) Vault Rotations
Differently from other Vault designs, the EVM Vault doesn't require moving the funds upon a key rotation. The current aggregate key is stored in the KeyManager contract, which verifies all the calls made to the Vault. When a key rotation occurs, the KeyManager contract is updated with the new aggregate key. After that, payloads signed with the previous aggregate key will no longer be valid. Also, given that the Vault has not changed in any way, it still has access to the already opened Deposit channels and doesn't require any extra actions.
Entry point for initiating swaps via a smart contract call
While using Deposit Channels is a very simple way to initiate a swap, the Vault smart contract allows for the initiation of swaps via a smart contract call. In that case, all the swap parameters need to be passed as part of the smart contract call as explained in Vault Swaps.
This feature allows for easier integration with other on-chain protocols. However, it's worth evaluating the tradeoffs of using this method instead of using Deposit Channels, as generally deposit channels will require less gas.
Cross-Chain Messaging (CCM) capabilities
Besides regular swaps, Chainflip supports Cross-Chain Messaging Swaps for EVM chains. The Vault smart contract executes these swaps by atomically transferring the assets and calling the user's contract logic on the destination chain along with the user's specified message. These swaps are not batched with any other actions.