This document provides information to developers who wish to work with StarkNet's node RPC API and are familiar with Ethereum's RPC API. The document focuses on existing APIs, specifically targeting distributed application developers.
As a general rule, the APIs are similar in naming, semantics and conventions. We generally follow the same methods used in Ethereum's node API and make changes where the technology requires it to maintain consistency.
Below you can find a summary of the changes, whether cross-cutting or method-specific. We also provide a mapping of methods.
We currently compare Ethereum 1.0 API, as defined here, and StarkNet's API.
Familiarity with Ethereum and StarkNet is assumed herein.
Some differences are more fundamental and manifest in different API methods.
Block and Transaction objects: Block and transaction objects have a somewhat different structure compared to Ethereum. These changes are mainly due to different network mechanics, e.g., no proof of work in StarkNet.
Block Tags: In some cases, the API refers to a block using relative tags that point to a block
in a specific position in the chain or state (latest, earliest, pending). Where applicable,
StarkNet allows referring only to the latest block, using the latest
tag.
Unless otherwise noted, the method names used are the same method names with a different prefix.
The eth
prefix is replaced with starknet
.
The fundamental data type in StarkNet is a field element. As a corollary, all resulting blocks and transactions' hashes are also field elements. When referring to a block/transaction type or an address, StarkNet uses a field element, not a 256-bit number.
The field element type in StarkNet is based on the field in the underlying Cairo VM.
In other words, a value x of a field element type is an integer in the range of 0≤x<P
. P
is currently defined as 2^251+17*2^192+1
We list below the methods in Ethereum's API and their corresponding StarkNet methods.
| Ethereum Method | StarkNet Method | Differences From Ethereum | | --------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- | --------- | --------------------------- | | eth_blockNumber | starknet_blockNumber | Will return only the block number | | eth_chainId | starknet_chainId | | | eth_getBlockByNumber | starknet_getBlockByNumber |
- Doesn’t have the include transactions input.
- The result key is “result”.
- Supports also “latest” block tag as input
- The result is always an integer
- The response key is “result”.
- May return an error for invalid block hash.
- Block number input is given as a decimal integer.
- The result key is “result”.
- May return an error for invalid block number.
- The result key is “result”.
- Will not return market fee parameters.
- Doesn’t have the include transactions input.
- The result key is “result”.
- Accepts a block hash instead of a block number
- The result key is “result”.
- The result type is a field element.
- Will return errors for invalid contract or storage keys.
- Input key is “transaction_hash”.
- The result key is “result”.
- Will not return null.
- Will return an error for an invalid transaction hash.
- Input key is “transaction_hash”.
- The result key is “result”.
- Will not return null.
- Will return an error for an invalid transaction hash.
- The input key is “contract_address”.
- Does not accept a block number.
- Will return byte code (field elements) and ABI.
- Will return an error for an invalid contract address.
- Input transaction is different.
- Input block designated by hash.
- Will return errors for invalid contract address | message selector | call data | or general error.