forked from hashgraph/hedera-improvement-proposal
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Move Smart contracts to Besu Library (hashgraph#138)
* Move Smart contracts to Besu Library HIP describing moving the Smart Contract library to Besu and the secondary implications such as London hard fork support. Signed-off-by: Danno Ferrin <[email protected]> * update admin headers Signed-off-by: Danno Ferrin <[email protected]> * file name Signed-off-by: Danno Ferrin <[email protected]>
- Loading branch information
Showing
1 changed file
with
244 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,244 @@ | ||
| - hip: 26 | ||
| - title: Migrate Smart Contract Service EVM to Hyperledger Besu EVM | ||
| - author: Daniel Ivanov ([email protected]), Danno Ferrin ( | ||
| [email protected]) | ||
| - type: Standards | ||
| - category: Services | ||
| - status: Draft | ||
| - created: 16 September 2021 | ||
| - discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/140 | ||
| - updated: 17 September 2021 | ||
| - requires: | ||
| - replaces: | ||
| - superseded-by: | ||
|
|
||
| ## Abstract | ||
|
|
||
| Replace the Ethereum Virtual Machine (EVM) engine in Hedera Services, moving | ||
| from an EthereumJ based engine to a Hyperledger Besu based engine | ||
|
|
||
| ## Motivation | ||
|
|
||
| The current codebase that implements EVM Smart Contract transactions is out of | ||
| date. It is based on EthereumJ and the upstream project has not implemented any | ||
| hard forks since the St. Petersburg hard fork in early 2019. Some changes to | ||
| opcodes and precompiled contracts make support of newer Solidity versions | ||
| difficult. The integration also required inclusion of the entire EthereumJ | ||
| codebase, as the EVM was not fully segregated from the client code. | ||
|
|
||
| ## Rationale | ||
|
|
||
| Hyperledger Besu is an Ethereum Mainnet compatible EVM client with an EVM that | ||
| is severable from the codebase. It is also supported by an active maintainer | ||
| community and is a "Graduated Project" from the Hyperledger Project. The | ||
| codebase is also up-to-date with current Ethereum Mainnet hard forks (London as | ||
| of the writing of this HIP) and has a roadmap aiming to support future Ethereum | ||
| features such as Proof of Stake migration and MEV integration. | ||
|
|
||
| With Besu's current maintainers it will be possible to extract the EVM code | ||
| needed to form a reusable library and not include any unneeded support code such | ||
| as Ethereum networking and merkle tree support. Going forward it will be easier | ||
| to maintain parity with Ethereum Mainnet evolutions such as the EVM container | ||
| formats and new opcodes/precompiled contracts. | ||
|
|
||
| ## User stories | ||
|
|
||
| As a developer I want to execute EVM contracts with current versions of Solidity | ||
| and with an EVM that is more compatible with Ethereum Mainnet than our current | ||
| EVM. | ||
|
|
||
| ## Specification | ||
|
|
||
| This release targets a swap between EthereumJ and Besu with a minimum of | ||
| compatibility changes. | ||
|
|
||
| ### Hedera | ||
|
|
||
| The current `EthereumJ` dependency is to be removed from the codebase and Hedera | ||
| optimised fork of `Besu` based on the upcoming 21.10.0 release is to be | ||
| introduced as a dependency. The `Besu` integrations will be configured to use | ||
| the "London" hard fork of Ethereum Mainnet with some necessary changes outlined | ||
| in [Backwards Compatibility]. | ||
|
|
||
| All operations (transition logics) in the Smart Contract Service will be | ||
| refactored to a new model-based design. | ||
|
|
||
| The current `SmartContractRequestHandler` is to be removed along with the | ||
| related EthereumJ execution logic. Instead, two new components will be | ||
| introduced - `EvmExecutor` and `HederaWorldUpdater`. The executor will be | ||
| preparing and running the `MessageFrames` of the EVM until halt. | ||
|
|
||
| Account and State access (read/write) will be provided to Besu through | ||
| implementation of a `WorldUpdater`. The updater will expose an API to Besu. The | ||
| component will utilise Postgres for bytecode and storage persistence (same as | ||
| the current EthereumJ integration). | ||
|
|
||
| #### Account Abstraction | ||
|
|
||
| The Smart Contract internal logic will be updated to more fully conform to | ||
| Hedera's account abstractions. | ||
|
|
||
| 1) Addresses in Hedera are utilising sequence number design compared to the hash | ||
| based design in the default EVM implementation. | ||
| 2) Hedera's account abstraction requires a `sponsor` and `expiry` for every | ||
| contract/account created. | ||
|
|
||
| The following changes will be made to Besu in order to mitigate the fundamental | ||
| changes described above: | ||
|
|
||
| - New `HederaCreate` operation in Besu will be introduced to support | ||
| the `CREATE` opcode. The operation will compute new contract addresses based | ||
| on `sequence numbers`, and matches existing behavior with EthereumJ. | ||
| - `AbstractWorldUpdater` will be extended to handle `MessageFrame` reverts to | ||
| reclaim the allocated `sequence numbers` | ||
| during `MessageFrame` execution. | ||
| - `MutableAccount` will be extended to support `sponsor` and `expiry` | ||
| properties. | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| ### Changes unrelated to "London" hard fork | ||
|
|
||
| The following changes will be made to the Opcodes, outside of London hard fork | ||
| support. These are done to better reflect the nature of the Hedera platform. | ||
|
|
||
| #### `CREATE2` | ||
|
|
||
| The `CREATE2` operation will not be supported and return an illegal opcode | ||
| failure. The implementation in hedera of `CREATE` and `CREATE2` are identical, | ||
| and this creates a usability problem with contracts that expect `CREATE2` to | ||
| operate in the specified manner. This stems from the differences in Hedera's and | ||
| Ethereum's account mapping. | ||
|
|
||
| #### `COINBASE` | ||
|
|
||
| The `COINBASE` operation will return the funding account (Hedera Fee collecting | ||
| account which on mainnet is `0.0.98`). The implementation at the moment returns | ||
| the `0.0.0` account and `0x0` EVM address. | ||
|
|
||
| #### `GASLIMIT` | ||
|
|
||
| The `GASLIMIT` operation will return the `gasLimit` of the transaction. The | ||
| transaction `gasLimit` will be the lowest of the gas limit requested in the | ||
| transaction or a global upper gas limit configured for all smart contracts. The | ||
| current maximum configured gas limit per transaction is 300,000 gas. | ||
|
|
||
| ### Upgrade to "London" Hard Fork | ||
|
|
||
| The smart contract platform will be upgraded to support the EVM visible changes | ||
| for the "London" hard fork. This includes changes introduced in the "Istanbul" | ||
| and "Berlin" hard forks. Changes relating to block production and data | ||
| serialization (such as the fee market, intrinsic gas costs, and transaction | ||
| formats) will not be implemented because they are not relevant to Hedera's | ||
| architecture. | ||
|
|
||
| #### `BASEFEE` | ||
|
|
||
| The `BASEFEE` opcode will return zero. Hedera does not use the Fee Market | ||
| mechanism this is designed to support. | ||
|
|
||
| #### Reject Contracts starting with `0xFE` | ||
|
|
||
| Hedera `ContractCreate` transactions and `CREATE` opcode calls will fail if the | ||
| first bytes of the smart contract is `0xFE`. Extending this to | ||
| the `ContractCreate` transaction mirrors how Ethereum contract deployments | ||
| typically operate. | ||
|
|
||
| #### `SELFBALANCE` | ||
|
|
||
| This opcode will operate as expected with no change from Ethereum Mainnet. | ||
|
|
||
| #### `CHAINID` | ||
|
|
||
| The `CHAINID` opcode will return `290` (hex `0x0127`) for mainnet, `291` ( | ||
| hex `0x0128`) for testnet, and `292` ( | ||
| hex `0x0129`) for previewnet. | ||
|
|
||
| #### Blake2 compression function F precompile | ||
|
|
||
| The precompiled contract operates the same as on Ethereum Mainnet. | ||
|
|
||
| ### Gas Schedule Changes | ||
|
|
||
| The Smart Contract Service will use the Gas Schedule from the "London" hard | ||
| fork. Notable changes include warm/cold account access and refund reductions. | ||
|
|
||
| #### Warm and Cold Account and Slot Access | ||
|
|
||
| Berlin introduced the notion of warm and cold accounts and storage slots. The | ||
| first access to an account or storage slot in a transaction will need to pay | ||
| the "cold" costs and all subsequent calls will pay the lower "warm" access | ||
| costs. [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) contains the full | ||
| details of the new cost scheduling. | ||
|
|
||
| Hedera does not at this time allow for "pre-warming" addresses and storage slots | ||
| as part of the transaction as seen | ||
| in [EIP-2930](https://eips.ethereum.org/EIPS/eip-2929). Future HIPs may support | ||
| this scheme. | ||
|
|
||
| #### Gas Refund Reductions and Eliminations | ||
|
|
||
| In the London gas schedule the amount of gas that can be returned from storage | ||
| access usage patterns has been significantly reduced. Account refunds | ||
| from `SELFDESTRUCT` have been completely removed. | ||
|
|
||
| ## Security Implications | ||
|
|
||
| Between Besu and EthereumJ there is no material difference in the security | ||
| attack surfaces. The same specifications and Hedera integrations will exist. | ||
|
|
||
| <!-- | ||
| ## How to Teach This | ||
| > For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. | ||
| --> | ||
|
|
||
| ## Reference Implementation | ||
|
|
||
| To be done | ||
|
|
||
| ## Rejected Ideas | ||
|
|
||
| ### Migration to another Smart Contract VM | ||
|
|
||
| The EVM is not the only smart contract platform, however it is the platform that | ||
| has the most widespread use in terms of total users and total numbers of DLTs | ||
| supporting the EVM. One alternative of note is WASM and eWASM. The Ethereum | ||
| Foundation's eWASM project has stagnated over the last two years and is not | ||
| under active development. It also did not achieve the performance goals it had | ||
| set, often running slower than optimized EVM implementations. WASM as a | ||
| standalone technology lacks determinism in some instructions it supports (mostly | ||
| floating point operations) as well as lacking resource metering and limitations. | ||
|
|
||
| Other leading smart contract platforms (TEAL, Michelson, MoveVM, etc.) are | ||
| strongly tied to their host chain and are not used with other chains and have | ||
| not gained cross-DLT support. A few chains that have custom smart contract | ||
| platforms have added EVM compatability layers or libraries for their systems | ||
| too (Aurora/NEAR and Arbitrum most notably). | ||
|
|
||
| Apart from EVM being one of the best choices there are also issues relating to | ||
| migrating to other smart contract systems that staying with EVM avoids. While | ||
| there may be future changes in supported services keeping the Smart Contract | ||
| Service on the EVM provides the least amount of backwards compatibility issues. | ||
|
|
||
| ### Eliminating Smart Contract Service Support | ||
|
|
||
| Eliminating the EVM as a whole would foreclose future growth of the Hedera | ||
| Platform in the "on-chain" smart contracts arena. | ||
|
|
||
| ## Open Issues | ||
|
|
||
| Currently, no open issues. | ||
|
|
||
| ## References | ||
|
|
||
| * [Hyperledger Besu](http://github.com/hyperledger/besu) | ||
| * [Ethereum London Hard Fork](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/london.md) | ||
| * [Ethereum Berlin Hard Fork](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md) | ||
| * [Ethereum Istanbul Hard Fork](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/istanbul.md) | ||
|
|
||
| ## Copyright/license | ||
|
|
||
| This document is licensed under the Apache License, Version 2.0 -- | ||
| see [LICENSE](../LICENSE) | ||
| or (https://www.apache.org/licenses/LICENSE-2.0) |