The Hedera Smart Contract Service (HSCS) integrates the features of Hedera's third-generation native entity functionality—high throughput, fast finality, predictable and affordable fees, and fair transaction ordering—with a highly optimized and performant second-generation Ethereum Virtual Machine (EVM). We aim to offer comprehensive support for smart contracts originally written for other EVM-compatible chains and to enable their seamless deployment on Hedera.
We strive to ensure that developers can conveniently point to a Hedera-supported RPC endpoint and perform smart contract executions and queries using the same code and similar tools to achieve EVM equivalence. All smart contract transactions are executed using the Besu EVM to realize this objective, and the resulting changes are stored in the Hedera-optimized Virtual Merkle Tree state. Users are thus guaranteed deterministic finality (as opposed to probabilistic finality) of smart contract executions within 2-3 seconds while ensuring that state changes are entirely encompassed within smart contract functionality.
{% hint style="info" %} 🔔 A Comprehensive breakdown of Hedera's EVM equivalence goals and exceptions can be found here. {% endhint %}
The old security model (pre 0.35.2) supported account key signatures provided at transaction time for authorization. Some of the key characteristics of this model included:
- Smart contracts could only change their own storage or the storage they were delegate called with.
- System smart contracts could be delegate called 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 greatly improved 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.
In the new security model, account key signatures cannot provide authorization for contract actions. Its key characteristics include:
- 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 approved for 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 may 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 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 a token allowance. | Y |
In summary, HSCS utilizes a three-level security approach:
- Level 0 - EVM Security Model: Entities may only modify their own state and balance.
- Level 1 - ERC Account Value Security Models: Transfer and access to account value will follow tested web3 interface standards, e.g., ERC20, ERC721.
- Level 2 - Hedera Advanced Security Features: Unique Hedera features may utilize contract-compatible permissions, e.g., ContractID keys.
Hedera's three-level smart contract security model
To achieve state change or value transfer, executions must adhere to 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. SPENDER_DOES_NOT_HAVE_ALLOWANCE.
Developers are strongly encouraged to test their applications with new contracts and UX using the new security model to avoid unintended consequences.
- The new security model has been applied to contracts created from the mainnet 0.35.2 release and onwards.
- Existing contracts deployed before this upgrade will continue to use the previous security model for a limited time to allow for application/UX modifications.
- The previous security model will only be maintained for approximately three months. The current target is for the network to remove the previous security model and for all contracts to follow the new model by the mainnet release of July 2023.
- See a comprehensive list of the security updates made here.
The security update involves changes to entity permissions during contract executions when modifying the state. In short, system contract calls (smart contract calls to the Hedera Token Service) are no longer executed with all upper caller privileges, even if the authorized user provides a signature.
Understanding the process of contract executions for both externally owned accounts (EOAs) and contracts during regular and delegate calls is crucial. This process involves tracking how accounts, state (storage and value balance), and code may change as you progress through the chain of calls.
In a regular call scenario, when a call is made to contract B, B’s code is executed in the context of its own state. This allows B to modify only its own state. The sender value also differs between the calls to highlight that the EOA made the first call and contract A made the second.
On the other hand, in a delegate call scenario, the call to contract B sees B’s code executed in the context of A’s state. This allows B to modify A’s state. The sender and recipient values are preserved from the first call as if the EOA initiated the call.
In summary, a delegate call executes the calling contract's code in the context of the previous account, giving the code access to the previous account's state and blurring the lines of authorized state management.
Applying this to the security model changes, the following table summarizes the authorization check changes.
| Scenario | Authorization check | Old Model | New Model |
|---|---|---|---|
| Smart contract A can change its own state using a call | sender = Contract A | Y | Y |
| Smart contract A can change EOA’s state via call | sender = EOA | N | N |
| Smart contract B can change contract A’s state via call | sender = A | N | N |
| Smart contract A can change EOA’s state via delegate call | sender = EOA | Y | Y |
| Smart contract B can change contract A’s state via delegate call | sender = Contract A | Y | Y |
| System smart contracts can change another accounts (EOA or contract A or contract B) state via call | sender = account | N | N |
| System smart contract can change another accounts EOA or contract A or contract B) state via delegate call | sender = account | N | N |
| System contracts can change an accounts (EOA or contact A or contract B) state via call with the appropriate signature | signature map contains signature of accounts (EOA or contact A or contract B respectively) | Y | N |
| System smart contract can change another accounts (EOA or contact A or contract B) state via delegate call with the appropriate signature | signature map contains signature of accounts (EOA or contact A or contract B) | Y | N |
| Contract A or B can call a system contract via a call | - | Y | Y |
| Contract A or B can call a system contract via a delegate call | - | Y | N |
At the time of the change, the HTS system contract was the only pathway to expose Hedera API functionality through Smart Contracts. As such, it’s fair to consider the differences between pre and post-security model updates when observing HTS system contract state-changing functions.
| IHederaTokenService System Smart Contract Function | v1 Model Authorization Requirements | v2 Model Authorization Requirements | Impacts Code | Solution by Developers |
|---|---|---|---|---|
| approve, approveNFT | signature map contains accounts admin key signature | msg.sender must be entity to be modified | Y | Upgrade contracts or Upgrade DApps to provide explicit user approval *Additional secure pathways: HIP 376 IERC.approve() |
| associateToken | signature map contains account admin key signature | msg.sender must be entity to be modified | Y | Upgrade contracts or Upgrade DApps to provide explicit user associate *Additional secure pathways: HIP 719 IHRC.associate() |
| burnToken | signature map contains token burn key signature or Contract Id satisfies Token.supplyKey requirements | Contract Id satisfies Token.supplyKey requirements | Y | Token admin must set desired contract in Supply key |
| createFungibleToken, createFungibleTokenWithCustomFees, createNonFungibleToken, createNonFungibleTokenWithCustomFees | signature map contains affected account admin key signature(s) in treasury or autoRenew assignment case |
or autoRenew assignment case | Y | - |
| cryptoTransfer | signature map contains sender admin key signature or Contract Id satisfies Entity.key requirements |
or autoRenew assignment case | Y | Upgrade DApps to provide explicit user approval. |
| deleteToken | signature map contains token admin key signature or Contract Id satisfies Token.adminKey requirements | Contract Id satisfies Token.adminKey requirements | Y | Token admin must set desired contract in admin key |
| dissociateToken, dissociateTokens | signature map contains admin key signature | msg.sender must be entity to be modified | Y | Upgrade contracts or Upgrade DApps to provide explicit user dissociate *Additional secure pathways: HIP 719 IHRC.associate() |
| freezeToken | signature map contains freeze key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.freezeKey requirements | Y | Token admin must set desired contract in freeze key |
| grantTokenKyc | signature map contains kyc key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.kycKey requirements | Y | Token admin must set desired contract in kyc key |
| mintToken | signature map contains appropriate signature or Contract Id satisfies Token.supplyKey requirements | Contract Id satisfies Token.supplyKey requirements | Y | Token admin must set desired contract in Supply key |
| pauseToken | signature map contains pause key signature or Contract Id satisfies Token.pauseKey requirements | Contract Id satisfies Token.pauseKey requirements | Y | Token admin must set desired contract in pause key |
| revokeTokenKyc | signature map contains kyc key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.kycKey requirements | Y | Token admin must set desired contract in kyc key |
| setApprovalForAll | signature map contains admin key signature | msg.sender must be entity to be modified | Y | Upgrade contracts or Upgrade DApps to provide explicit user associate *Additional secure pathways: HIP 376 IERC.setApprovalForAll() |
| transferFrom, transferFromNFT | signature map contains admin key signature or Spender must have been pre-approved an allowance |
or autoRenew assignment case | Y | Upgrade DApps to provide explicit user approval. |
| transferToken, transferTokens, transferNFT, transferNFTs | signature map contains admin key signature or Contract Id satisfies Entity.key requirements or Contract has been approved an allowance to spend by owner |
If not 1. Contract Id satisfies Entity.key requirements or 2. Contract has been approved an allowance to spend by owner | Y | Upgrade DApps to provide explicit user approval. |
| updateTokenInfo, updateTokenExpiryInfo, updateTokenKeys | signature map contains token admin key signature or Contract Id satisfies Token.adminKey requirements | Contract Id satisfies Token.adminKey requirements | Y | Token admin must set desired contract in admin key |
| wipeTokenAccount, wipeTokenAccountNFT | signature map contains token wipe key signature or Contract Id satisfies Token.wipeKey requirements | Contract Id satisfies Token.wipeKey requirements | Y | Token admin must set desired contract in Wipe key |
| unfreezeToken | signature map contains token freeze key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.freezeKey requirements | Y | Token admin must set desired contract in freeze key |
| unpauseToken | signature map contains token pause key signature or Contract Id satisfies Token.pauseKey requirements | Contract Id satisfies Token.pauseKey requirements | Y | Token admin must set desired contract in pause key |
{% hint style="info" %} Note: While the changes impact user experience, requiring more explicit steps, they more than proportionately increase user and network security across the board. The team continues to push diligently to provide the community with secure and scalable API solutions to enable them to build creative dApps and carve out their own shared world on the ledger. {% endhint %}
0.35.2
- After the security incident on March 9th, the engineers conducted a thorough analysis of the Smart Contract Service and the Hedera Token Service system contracts.
- As part of this exercise, we did not find any additional vulnerabilities that could result in an attack that that which we witnessed on March 9th.
- The team also looked for any disparities between the expectations of a typical smart contract developer who is used to working with the Ethereum Virtual Machine (EVM) or ERC token APIs and the behaviors of the Hedera Token Service system contract APIs. Such differences in behavior could be used by a malicious smart contract developer in unexpected ways.
- In order to eliminate the possibility of these behavioral differences being utilized as attack vectors in the future, the consensus node software will align the behaviors of the Hedera Smart Contract Service token system contracts with those of EVM and typical token APIs such as ERC 20 and ERC 721.
- As a result, the following changes are made as of the mainnet 0.35.2 release on March 31st:
- An EOA (externally owned account) will have to provide explicit approval/allowance to a contract if they want the contract to transfer value from their account balance.
- The behavior of
transferFromsystem contract will be exactly the same as that of the ERC 20 and ERC 721 spectransferFromfunction. - For HTS specific token functionality (e.g. Pause, Freeze, or Grant KYC), a contract will be authorized to perform the associated token management function only if the ContractId is listed as a key on the token (i.e. Pause Key, Freeze Key, KYC Key respectively).
- The
transferTokenandtransferNFTAPIs will behave astransferin ERC20/721 if the caller owns the value being transferred, otherwise it will rely on approve spender allowances from the token owner. - The above model will dictate entity (EOA and contracts) permissions during contract executions when modifying state. Contracts will no longer rely on Hedera transaction signature presence, but will instead be in accordance with EVM, ERC and ContractId key models noted.
- As part of this release, the network will include logic to grandfather in previous contracts.
- Any contracts created from this release onwards will utilize the stricter security model and as such will not have considerations for top-level signatures on transactions to provide permissions.
- Existing contracts deployed prior to this upgrade will be automatically grandfathered in and continue to use the old model that was in place prior to this release for a limited time to allow for DApp/UX modification to work with the new security model.
- The grandfather logic will be maintained for an approximate period of 3 months from this release. In a future release in July 2023, the network will remove the grandfather logic, and all contracts will follow the new security model.
- Developers are encouraged to test their DApps with new contracts and UX using the new security model to avoid unintended consequences. If any DApp developers fail to modify their applications or upgrade their contracts (as applicable) to adhere to the new security model, they may experience issues in their applications.