|
| 1 | +--- |
| 2 | +title: Direct Calls from Cadence to Flow EVM |
| 3 | +sidebar_label: Direct Calls to Flow EVM |
| 4 | +sidebar_position: 5 |
| 5 | +--- |
| 6 | + |
| 7 | +Direct calls from Cadence to Flow EVM are essential for enabling Cadence smart contracts to interact seamlessly with the EVM environment hosted on the Flow blockchain. These calls facilitate a range of functionalities including state queries and transaction initiations, allowing Cadence contracts to leverage EVM-based tools and assets. |
| 8 | + |
| 9 | +## Making Direct Calls |
| 10 | + |
| 11 | +### Accessing Flow EVM |
| 12 | + |
| 13 | +To interact with Flow EVM, Cadence contracts must first import `EVM` from its service address: |
| 14 | + |
| 15 | +```js |
| 16 | +import EVM from <ServiceAddress> |
| 17 | +``` |
| 18 | + |
| 19 | +Next, create an `EVMAddress` with a sequence of 20 bytes representing the EVM address: |
| 20 | + |
| 21 | +```js |
| 22 | +let addr = EVM.EVMAddress(bytes: bytes) |
| 23 | +``` |
| 24 | + |
| 25 | +Once you have access to an `EVMAddress`, you can query various pieces of state information such as: |
| 26 | + |
| 27 | +- `balance() EVM.Balance` provides the balance of the address. It returns a balance object rather than a basic type to avoid errors when converting from flow to atto-flow. |
| 28 | +- `nonce() UInt64` retrieves the nonce associated with the address. |
| 29 | +- `code(): [UInt8]` fetches the code at the address; it returns the smart contract code if applicable, and is empty otherwise. |
| 30 | + |
| 31 | +``` |
| 32 | +import EVM from <ServiceAddress> |
| 33 | +
|
| 34 | +access(all) |
| 35 | +fun main(bytes: [UInt8; 20]) { |
| 36 | + let addr = EVM.EVMAddress(bytes: bytes) |
| 37 | + let bal = addr.balance() |
| 38 | +} |
| 39 | +``` |
| 40 | + |
| 41 | +### Sending Transactions to Flow EVM |
| 42 | + |
| 43 | +To send transactions to Flow EVM, use the `run` function which executes RLP-encoded transactions. RLP (Recursive Length Prefix) encoding is used to efficiently encode data into a byte-array format, suitable for Ethereum-based environments. Here's an example of wrapping and sending a transaction: |
| 44 | + |
| 45 | +``` |
| 46 | +import EVM from <ServiceAddress> |
| 47 | +
|
| 48 | +transaction(rlpEncodedTransaction: [UInt8], coinbaseBytes: [UInt8; 20]) { |
| 49 | +
|
| 50 | + prepare(signer: AuthAccount) { |
| 51 | + let coinbase = EVM.EVMAddress(bytes: coinbaseBytes) |
| 52 | + let result = EVM.run(tx: rlpEncodedTransaction, coinbase: coinbase) |
| 53 | + assert( |
| 54 | + runResult.status == Status.successful, |
| 55 | + message: "tx was not executed successfully." |
| 56 | + ) |
| 57 | + } |
| 58 | +} |
| 59 | +``` |
| 60 | + |
| 61 | +Using `run` restricts an EVM block to a single EVM transaction, while a future `batchRun` will offer the capability to execute multiple EVM transactions in a batch. |
| 62 | + |
| 63 | +### Handling Transaction Responses |
| 64 | + |
| 65 | +Handling responses correctly is crucial to manage the state changes or errors that occur during `EVM` transactions: |
| 66 | + |
| 67 | +When calling `EVM.run`, it's important to understand that this method does not revert the outer Flow transaction. Developers must therefore carefully handle the response based on the `result.Status` of the EVM transaction execution. There are three main outcomes to consider: |
| 68 | + |
| 69 | +- `Status.invalid`: This status indicates that the transaction or call failed at the validation step, such as due to a nonce mismatch. Transactions with this status are not executed or included in a block, meaning no state change occurs. |
| 70 | +- `Status.failed`: This status is assigned when the transaction has technically succeeded in terms of being processable, but the EVM reports an error as the outcome, such as running out of gas. Importantly, a failed transaction or call is still included in a block. Attempting to resubmit a failed transaction will result in an `invalid` status on the second try due to a now incorrect nonce. |
| 71 | +- `Status.successful`: This status is given when the transaction or call is successfully executed and no errors are reported by the EVM. |
| 72 | + |
| 73 | +For scenarios where transaction validity is critical, developers may choose to use the `mustRun` variation, which reverts the transaction in the case of a validation failure, providing an added layer of error handling. |
| 74 | + |
| 75 | +### Understanding Gas Usage in EVM Transactions |
| 76 | + |
| 77 | +Direct calls to Flow EVM require gas, it's important to understand how gas usage is calculated and billed. During the execution of methods that interact with the EVM: |
| 78 | + |
| 79 | +- **Gas Aggregation**: The gas used by each call is aggregated throughout the transaction. |
| 80 | +- **Gas Adjustment**: The total gas used is then adjusted based on a multiplier. This multiplier is determined by the network and can be adjusted by the service account to reflect operational costs and network conditions. |
| 81 | +- **Payment of Gas Fees**: The adjusted total gas amount is added to the overall computation fees of the Flow transaction. These fees are paid by the transaction initiator, commonly referred to as the payer. |
| 82 | + |
| 83 | +## Keep Learning |
| 84 | + |
| 85 | +For more information and a deeper dive into the `EVMAddress`, `Result`, and `Status` objects, see [the contract here](https://github.com/onflow/flow-go/blob/feature/stable-cadence/fvm/evm/stdlib/contract.cdc). |
0 commit comments