The Hedera Smart Contract Service (HSCS) combines the third-generation Hedera native entity functionality - high throughput with fast finality, affordable and predictable fees, and fair transaction ordering - with an optimized and highly performant second-generation Ethereum Virtual Machine (EVM). Our goal is to provide full support for smart contracts written on other EVM-compatible chains and to facilitate their smooth deployment on Hedera — as simple as copy/paste. Developers should be able to simply point to a Hedera-supported RPC endpoint and carry out their smart contract executions and queries with the same code and similar tools - this is our goal for EVM equivalence
To achieve this, the ledger executes all smart contract transactions using the Besu EVM and persists the changes in the Hedera-optimized Virtual Merkle Tree state. Users are able to observe certain finality (not probabilistic finality) of smart contract executions in 2-3 seconds whiles ensuring state changes can be fully encapsulated in smart contract functionality.
Hedera Consensus Nodes must strike a delicate balance between Hedera security and EVM security models. With HSCS Security Model v1, the complexity of this challenge left gaps for which bad actors could operate. With the HCSC Security Model v2, greater clarity and additional protections have been brought to the network.
v1 Security Model Boundaries
The old security model (pre 0.35.2) supported account key signatures provided at transaction time for authorization. The boundary rules could be summarized as follows
- Smart contracts could only change their own storage or the storage they were delegate called with.
- System smart contracts could be delegate called, in order to carry out Hedera Token Service (HTS) operations on behalf of another account - Externally Owned Account (EOA) or contract account.
- Smart Contracts could change an EOA’s storage with the appropriate signature in the transaction.
- Smart Contracts could change an EOA’s balance with the appropriate signature in the transaction or with prior addition to an allowance approval list.
This provided a huge improvement to user experience as contracts could combine transactions in an attempt at atomicity. For instance, a contract could associate, transfer and approve transactions on a user's behalf with one signature. While focusing on usability, this approach did not address cases in which bad actors could carry out an unsanctioned transaction on behalf of a user, e.g., https://hedera.com/blog/analysis-remediation-of-the-precompile-attack-on-the-hedera-network
To address this, the core Hedera engineers thoroughly analyzed the Smart Contract Service and the HTS system contracts, aiming to secure the state and token assets of users and the network during Smart Contract executions. The results of this effort are the guidelines in Hedera Services release v0.35.2.
v2 Security Model Boundaries
In the new model, account key signatures may not provide authorization for contract actions. The boundary rules can be summarized as follows
- Smart contracts can only change their own storage or the storage they were delegate called with.
- System smart contracts may not be delegate called, except from the Token proxy/facade flow e.g. HIP 719. In such cases HTS tokens are represented as smart contracts (see HIP 218) for common ERC methods.
- Smart contracts can change an EOAs storage only if the contract ID is contained in the EOAs key.
- Smart contracts can change an EOAs balance if they have been approved a token allowance for a specific token held by the EOA.
|Boundary Spec||v1 Model||v2 Model||Change|
|Storage Changes||Smart Contracts could only change their own storage or the storage they were delegate called with.||Smart contracts can only change their own storage or the storage they were delegate called with.||N|
|System Contract Call Types||System smart contracts could be delegate called in order to carry out Hedera Token Service operations on behalf of another account (EOA) or contract.||System smart contracts can not be delegate called, except from the Token facade flow, which presents HTS tokens as smart contracts for common ERC methods.||Y|
|Permissioned Account Storage Changes||Smart Contracts could change an EOA’s storage with the appropriate signature in the transaction.||Smart contracts can change an EOAs storage only if the contract ID is contained in the EOAs key.||Y|
|Permissioned Account Balance Changes||Smart Contracts could change an accounts (EOA or contract) balance with the appropriate signature in the transaction or with prior addition to an allowance approval list||Smart contracts can change an EOAs balance if they have been approved an allowance for a specific token held by the EOA.||Y|
In summary, the HSCS utilizes a three-level approach:
- Level 0 - EVM security model - entities may only modify their own state and balance.
- Level 1 - EVM balance allowance interactions - transfer and access to account balance will follow tested web3 interface standards, e.g., ERC 20 & ERC 721 approvals.
- Level 2 - Hedera advanced security features - unique Hedera features may utilize contract-compatible authorization features e.g., ContractID keys.
To achieve state change or value transfer, executions must not break any of the rules of each level. Transactions that don’t satisfy the appropriate authorization will fail with response codes such as
INVALID_FULL_PREFIX_SIGNATURE_FOR_PRECOMPILE when a sender is not authorized to carry out an operation. More operational-specific response codes will be returned where applicable, e.g.,
EOA <> Contract Interactions
To add greater clarity to the security model, it’s valuable to explore the rules of account (EOA & contract) interaction in smart contract execution.
The two illustrations below describe the context for contract executions for EOAs and contracts during regular and delegate calls. We follow how the accounts, state (storage and value balance), and code may change as you progress through the chain of calls.