Hedera
Hedera: HCS ordering versus smart contract logic
Hedera is a public distributed ledger where Hedera Consensus Service (HCS) orders and timestamps messages, while Smart Contract Service executes custom logic in an Ethereum Virtual Machine (EVM)-compatible environment. HCS gives application software an agreed message history to interpret. Smart contracts put custom rules into code that runs on the network. Transactions must satisfy their applicable signature requirements and pay fees in HBAR.
HCS and Smart Contract Service compared
| Dimension | Hedera Consensus Service | Smart Contract Service |
|---|---|---|
| Primary function | Order and timestamp messages published to consensus topics. | Execute EVM-compatible smart contract logic. |
| Application rules | Application software interprets the ordered message history. | Deployed contract code evaluates custom rules on the network. |
| Submitted work | Messages associated with a consensus topic. | Contract deployment and interactions with deployed contracts. |
| Client-set budget | The client can set a maximum transaction fee. | The client can set a maximum transaction fee and a maximum gas limit. |
| Network fee payment | HBAR, with service fees expressed in US dollars and converted at transaction time. | HBAR, with gas relevant to contract execution. |
What does an HCS record establish?
A consensus topic gives applications a message history with an agreed order and consensus timestamps. This supports auditable logs and coordination between systems that need a common record. The application determines how each message affects its own business records.
The consensus timestamp belongs to the submitted message. It does not establish when an external event actually happened or whether the event description is accurate. Those questions depend on the information supplied to the application and the checks that the application performs.
HCS messages can be public or encrypted. Payload confidentiality therefore depends on how the application encrypts its content and manages access to the decryption keys. Ordering and timestamping remain the service’s role in either case.
Where does contract execution add value?
Smart Contract Service runs deployed application logic in an EVM-compatible environment. A contract’s code determines how it handles permitted inputs and applies its programmed conditions.
An application can use HCS for an ordered record alongside contracts for custom logic. The two results have different meanings: a message’s consensus timestamp establishes its place in the log, while a contract execution result establishes what happened during that execution. A related message alone does not establish that a separate contract action completed.
Native token creation and management can also use Hedera Token Service APIs without deploying a smart contract. Contracts are available when the application needs custom logic.
Signatures, fees and gas
At a minimum, the account paying for a client-created transaction must sign it. Additional signatures may be required by the relevant account, topic or token settings. For HCS submissions, the topic’s configuration can therefore change which signatures are necessary.
The maximum transaction fee expresses what the payer is willing to pay. Smart contract transactions also let the client specify a maximum gas limit for execution. These are separate controls: one concerns the transaction fee budget and the other concerns the permitted computational work.
HCS fees are denominated in US dollars and converted to HBAR at transaction time. A fee for an HCS operation does not describe the cost of a smart contract call. The service and operation being performed remain material to the cost.
Shared consensus and application correctness
Both services use the Hedera network’s hashgraph consensus. Its asynchronous Byzantine fault tolerance assumes that attackers control less than one-third of consensus voting weight and that messages between honest nodes eventually arrive. The eventual-delivery condition does not impose a fixed completion deadline.
Agreement on transaction order does not establish that application inputs are accurate or that contract code implements the intended rules. EVM compatibility also does not establish audit status. Hedera’s reference Solidity contracts are examples that are not audited; audits of the network’s consensus or services code do not extend automatically to an application’s contracts.
