Divergence from Ethereum

Overview

Radius diverges from standard Ethereum behavior in several key ways. This section outlines the most significant differences.

Blocks

Radius does not inherently rely on blocks, in that it does not require batches of transactions to be grouped together and agreed on accordingly. Instead, the atomic unit of execution is a single transaction. So long as the transaction is valid at the time of execution, it is executed.

However, given that Radius is EVM-compatible, and it is designed to support the Ethereum JSON-RPC API, block-oriented RPC methods, and block-related opcodes are still supported, just with some differences worth noting.

A primary difference is that blocks are not stored as part of the Radius state during execution. Instead, a block is generated on-the-fly as needed, when responding to a block-related RPC request. See Block Hashes for more details on how this block differs from a standard Ethereum block.

Block Numbers

Block numbers in Radius correspond to timetstamps in milliseconds. Therefore, the block number of a transaction is the time at which it occurred, and a "block" contains all of the transactions that occurred within that millisecond. When requested, this block is reconstructed by the execution layer, but it is otherwise not stored in block form as part of the Radius state. This is in part due to optimizing for speed, and also because there is no consensus step for a "block" that would allow for a real-time consistent view of what a "block" is. Moreover, blocks after a certain point will not be re-constructed with particularly old transactions. The length of time is dependent on the volume of transactions processed by the system.

Block numbers retrieved by eth_blockNumber return the current timestamp in milliseconds, as this is the current block number.

Block Hashes

The block hash is the same as the block number for a given block. This, again, is due to the fact that there is no real time consistent view of what transactions are in a block. Additionally, given that blocks are not an official part of the Radius state, we do not generate a hash for each block after the fact, as at least in Ethereum is based on the previous block hash, so there is a dependency chain that is not maintained.

BLOCKHASH (0x40)

The BLOCKHASH opcode is supported, but given that the hash is a timestamp, it may not be suitable for use in contracts leveraging it for pseudorandomness ¹.

Additionally, if there is sufficient demand, Radius could support precompiles to provide pseudorandomness.

Beneficiaries and COINBASE (0x41)

Gas fees in Radius are paid to a specific set of beneficiary addresses, and the number of beneficiary addresses available is known at any given time. However, reads of the balance or state of any of the beneficiary addresses are not guaranteed to be fresh. The rationale for this is at high volumes, the beneficiary addresses are updated frequently, and requiring every transaction to lock the beneficiary address would be too expensive computationally. So, as a concession, reads of the beneficiary address within contract execution return an empty account.

Calls to eth_getBalance return a view of the beneficiary address balance, though it is read ephemerally and may be stale.

The COINBASE opcode faithfully returns the beneficiary address corresponding to the execution environment of the current transaction. However, if the account state is read as a part of the same transaction, it returns an empty account. This is also true for any reads of other beneficiary addresses.

Reading the coinbase account state within the transaction does not appear to be a common pattern, but it is worth being well aware of as a developer.

Stored transaction data

Receipts in Radius are largely the same as in Ethereum, however the transactionIndex field is not necessarily accurate. If multiple transactions occur within the same millisecond timestamp, the resultant constructed pseudo-block will contain multiple transactions, but the receipt for each will have the same transactionIndex (0). Since we do not sequence transactions into a block, we cannot faithfully denote the transaction index in the receipt in all cases. So, this field while present, can be disregarded and should not be relied on.