Hedera Smart Contract Service Security Model Update

Jun 08, 2023

by Nana Essilfie-Conduah

Smart Contracts Engineering & Experience

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

Name: Hedera
Price range: $

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.

Continue Learning

View All Posts