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 comparison
| 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., SPENDER_DOES_NOT_HAVE_ALLOWANCE.
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.
In the regular call case, the call to contract B sees B’s code executed in the context of its own state, therefore allowing B to only modify B’s own state. The sender value also appropriately differs between the calls to highlight that the EOA made the 1st call and contract A made the 2nd.
In a delegate call case, the call to contract B sees B’s code executed in the context of A’s state, therefore allowing B to modify A’s state. The sender and recipient values are preserved from the 1st call as if the EOA initiated the call.
In summary, a delegate call executes the called contract’s code in the context of the previous calling 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 contract 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 contract 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.
Existing HTS System Contract Impacts
| IHederaTokenService System Smart Contract Function | v1 Model Authorization Requirement | v2 Model Authorization Requirement | Solution by Developers | Additional Secure Pathways |
| approve, approveNFT | Signature map contains account admin key signature | msg.sender must be entity to be modified | Upgrade contracts to allow owner contract to explicitly set an allowance approval. or Upgrade DApps to support explicit account allowance approval transaction. | HIP 376 IERC.approve() |
| associateToken | Signature map contains account admin key signature | msg.sender must be entity to be modified | Upgrade contracts to allow contract to explicitly associate with a token. or Upgrade DApps to support explicit user associate transaction. | 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 | 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 | msg.sender must be entity to be modified in treasury or autoRenew assignment case | | |
| cryptoTransfer | Signature map contains sender admin key signature or Contract Id satisfies Entity.key requirements | msg.sender must be balance owner | Upgrade DApps to support explicit account allowance approval transaction. | |
| deleteToken | Signature map contains token admin key signature or Contract Id satisfies Token.adminKey requirements | Contract Id satisfies Token.adminKey requirements | 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 | Upgrade contracts. or Upgrade DApps to provide explicit user dissociate | HIP 719 IHRC.dissociate() |
| freezeToken | Signature map contains freeze key signature or Contract Id satisfies Token.freezeKey requirements | Contract Id satisfies Token.freezeKey requirements | 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 | 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 | 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 | 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 | Token admin must set desired contract in kyc key | |
| setApprovalForAll | Signature map contains admin key signature | msg.sender must be entity to be modified | Upgrade contracts to allow owner contract to explicitly set an allowance approval. or Upgrade DApps to support explicit account allowance approval transaction. | HIP 376 IERC.setApprovalForAll() |
| transferFrom, transferFromNFT | Signature map contains admin key signature or Spender must have been pre-approved an allowance | msg.sender must be balance owner. | Upgrade DApps to support explicit account allowance approval transaction. | |
| 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 | msg.sender must be balance owner. or Contract Id satisfies Entity.key requirements Contract has been approved an allowance to spend by owner | Upgrade DApps to support explicit account allowance approval transaction. | |
| updateTokenInfo, updateTokenExpiryInfo, updateTokenKeys | Signature map contains token admin key signature or Contract Id satisfies Token.adminKey requirements | Contract Id satisfies Token.adminKey requirements | 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 | 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 | 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 | Token admin must set desired contract in pause key | |
While the changes impacts user experience requiring more explicit steps, it more than proportionately increases 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.
