Overview

Pantheon Overview

Contents

• What is Pantheon?
• What can you do with Pantheon?
• What doesn't Pantheon support?

What is Pantheon?

Pantheon is an open-source Ethereum client developed under the Apache 2.0 license and written in Java. It runs on the Ethereum public network, private networks, and test networks such as Rinkeby and Ropsten. Pantheon implements Proof of Work (Ethash) and Proof of Authority (Clique) consensus mechanisms.

You can use Pantheon to develop enterprise applications requiring secure, high-performance transaction processing in a private network.

Our roadmap includes Pantheon with privacy features, alternative consensus mechanisms, and other enterprise features.

What can you do with Pantheon?

Pantheon includes a command line interface and JSON-RPC API for running, maintaining, debugging, and monitoring node operations in an Ethereum network. You can use the API via RPC over HTTP or via WebSockets transport, and Pub/Sub is supported. The API supports typical Ethereum functionalities such as:

• Ether token mining
• Smart contract development
• Decentralized application (Dapp) development

The Pantheon client supports common smart contract and Dapp development, deployment, and operational use cases, using tools such as Truffle, Remix, and web3j. The client supports common JSON-RPC API methods such as eth, net, web3, debug, and miner.

Pantheon doesn't support Account management.

Installation

Pantheon Installation

You can install Pantheon by:

• Installing the binary distribution
• Building from source

Note To run a single node to connect the Ethereum mainnet or a public testnet, running from the Pantheon docker image is the fastest way to get started.

Disk Space and RAM Requirements

Your computer should have at least 4 GB RAM.

Disk space needed varies depending on the network on which you run nodes. A small test network might require 200 MB while a mainnet node might require 1.5TB. If syncing a node on mainnet, allow 1.5 TB to 2 TB for the full blockchain archive.

Install Binary Distribution

Installation from Binary Distribution

Contents

• Mac OS
• Windows
• Linux / Unix

Mac OS

Prerequisites

• Homebrew

Install Using Homebrew

brew tap pegasyseng/pantheon
brew install pantheon

Display Pantheon command line help to confirm installation:

pantheon --help

Windows with Chocolatey

Prerequisites

• Chocolatey

Install Using Chocolatey

To install from Chocolatey package:

choco install pantheon

Display Pantheon command line help to confirm installation:

pantheon --help

Linux / Unix / Windows without Chocolatey

Prerequisites

• Java JDK

  Note Pantheon requires Java 8+ to compile; earlier versions are not supported.

  Note Pantheon is currently supported only on 64-bit versions of Windows, and requires a 64-bit version of JDK/JRE. We recommend that you also remove any 32-bit JDK/JRE installations.

Install from Packaged Binaries

Download the Pantheon packaged binaries.

Unpackage the downloaded files and change into the pantheon-<release> directory.

Display Pantheon command line help to confirm installation:

bin/pantheon --help

Build from Source

Building Pantheon from Source

Prerequisites

• Java JDK

  IMPORTANT: Pantheon requires Java 8+ to compile; earlier versions are not supported.

• Git or GitHub Desktop

Running Locally

• Installation on Linux / Unix / Mac OS X
• Installation on Windows

Running Virtually

• Installation on VM

Installation on Linux / Unix / Mac OS X

Clone the Pantheon Repository

Clone the PegaSysEng/pantheon repo to your home directory (/home/<user>):

git clone --recursive https://github.com/PegaSysEng/pantheon.git

Build Pantheon

After cloning, go to the pantheon directory.

Build Pantheon with the Gradle wrapper gradlew, omitting tests as follows:

./gradlew build -x test

Go to the distribution directory:

cd build/distributions/

Expand the distribution archive:

tar -xzf pantheon-<version>.tar.gz

Move to the expanded folder and display the Pantheon help to confirm installation.

cd pantheon-<version>/
bin/pantheon --help

Continue with the Private Network Quickstart or Starting Pantheon.

Installation on Windows

Note Pantheon is currently supported only on 64-bit versions of Windows, and requires a 64-bit version of JDK/JRE. We recommend that you also remove any 32-bit JDK/JRE installations.

Install Pantheon

In Git bash, go to your working directory for repositories. Clone the PegaSysEng/pantheon repo into this directory:

git clone --recursive https://github.com/PegaSysEng/pantheon

Build Pantheon

Go to the pantheon directory:

cd pantheon

Open a Windows command prompt. Build Pantheon with the Gradle wrapper gradlew, omitting tests as follows:

gradlew build -x test

Note To run gradlew, you must have the JAVA_HOME system variable set to the Java installation directory. For example: JAVA_HOME = C:\Program Files\Java\jdk1.8.0_181.

Go to the distribution directory:

cd build\distributions

Expand the distribution archive:

tar -xzf pantheon-<version>.tar.gz

Move to the expanded folder and display the Pantheon help to confirm installation.

cd pantheon-<version>
bin\pantheon --help

Continue with the Private Network Quickstart or Starting Pantheon.

Installation on VM

You can run Pantheon on a virtual machine (VM) on a cloud service such as AWS or Azure, or locally using a VM manager such as VirtualBox.

If you set up your own VM locally using a VM manager such as VirtualBox, there are a few considerations:

• Make sure that Intel Virtualization Technology (VTx) and Virtualization Technology for Directed I/O (VT-d) are enabled in BIOS settings.

• On Windows, you might need to disable Hyper-V in the Windows Feature list.

It is recommended that you create a VM with the following attributes:

• Memory Size: Set to 4096 (recommended)

• Create a virtual hard disk with at least 10 GB; 20 GB is recommended

• Virtual hard disk file type: VDI (if you need to share it with other apps, use VHD)

• (Optional) You can create a shared directory in order to copy block files or genesis files from the host computer to the VM. For details on how to create a shared directory, see "Share Folders" in Install Ubuntu on Oracle VirtualBox.

Getting Started

Getting Started

You can get started with Pantheon by:

• Starting a node as described in Starting Pantheon
• Running from the Pantheon docker image
• Using the Private Network Quickstart

To run a single node to connect the Ethereum mainnet or a public testnet, running from the Pantheon docker image or installing the packaged binaries is the fastest way to get started.

To run a private network on which you can make JSON-RPC requests and send transactions, or explore Pantheon and Ethereum networks, the Private Network Quickstart runs a private network of Pantheon nodes in a Docker container.

Starting Pantheon

Starting Pantheon

Pantheon nodes can be used for varying purposes as described in the Overview. Nodes can connect to the Ethereum mainnet, public testnets such as Ropsten, or private networks.

Prerequisites

Pantheon Installed

Local Block Data

When connecting to a network other than the network previously connected to, you must either delete the local block data or use the --datadir option to specify a different data directory.

To delete the local block data, delete the database directory in the pantheon/build/distribution/pantheon-<version> directory.

Genesis Configuration

Pantheon specifies the genesis configuration, and sets the network ID and bootnodes when connecting to mainnet, Rinkeby, and Ropsten.

When --dev-mode is specified, Pantheon uses the development mode genesis configuration.

The genesis files defining the genesis configurations are in the Pantheon source files.

To define a genesis configuration, create a genesis file (for example, genesis.json) and specify the file using the --genesis option.

Confirm Node is Running

If you have started Pantheon with the --rpc-enabled option, use cURL to call JSON-RPC API methods to confirm the node is running. For example:

• eth_chainId returns the chain ID of the network.

    curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' 127.0.0.1:8545

• eth_syncing returns the starting, current, and highest block.

   curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' 127.0.0.1:8545

  For example, after connecting to mainnet eth_syncing will return something similar to:

    {
      "jsonrpc" : "2.0",
      "id" : 1,
      "result" : {
        "startingBlock" : "0x0",
        "currentBlock" : "0x2d0",
        "highestBlock" : "0x66c0"
      }

Run a Node on Ethereum Mainnet

To run a node on the Ethereum mainnet:

$ bin/pantheon

To run a node on mainnet with the HTTP JSON-RPC service enabled:

$ bin/pantheon --rpc-enabled

Run a Node on Ropsten Testnet

Note From v0.8.2, use the --ropsten option instead of the following options. For v0.8.1, use the following options.

To run a node on Ropsten:

$ bin/pantheon --network-id=3 --genesis=<path>/pantheon/ethereum/core/src/main/resources/ropsten.json --bootnodes=enode://6332792c4a00e3e4ee0926ed89e0d27ef985424d97b6a45bf0f23e51f0dcb5e66b875777506458aea7af6f9e4ffb69f43f3778ee73c81ed9d34c51c4b16b0b0f@52.232.243.152:30303,enode://94c15d1b9e2fe7ce56e458b9a3b672ef11894ddedd0c6f247e0f1d3487f52b66208fb4aeb8179fce6e3a749ea93ed147c37976d67af557508d199d9594c35f09@192.81.208.223:30303

To run a node on Ropsten with the HTTP JSON-RPC service enabled and allow Remix to access the node:

$ bin/pantheon --rpc-enabled --rpc-cors-origins "http://remix.ethereum.org" --network-id=3 --genesis=<path>/pantheon/ethereum/core/src/main/resources/ropsten.json --bootnodes=enode://6332792c4a00e3e4ee0926ed89e0d27ef985424d97b6a45bf0f23e51f0dcb5e66b875777506458aea7af6f9e4ffb69f43f3778ee73c81ed9d34c51c4b16b0b0f@52.232.243.152:30303,enode://94c15d1b9e2fe7ce56e458b9a3b672ef11894ddedd0c6f247e0f1d3487f52b66208fb4aeb8179fce6e3a749ea93ed147c37976d67af557508d199d9594c35f09@192.81.208.223:30303

Where <path> is the path to the /pantheon directory.

Run a Node on Rinkeby Testnet

To run a node on Rinkeby specifying a data directory:

$ bin/pantheon --rinkeby --datadir=<path>/<rinkebyDataDir>

Where <path> and <rinkebyDataDir> are the path and file where the Rinkeby chain data is to be saved.

Run a Node on Goerli Testnet

To run a node on Goerli specifying a data directory:

$ bin/pantheon --goerli --datadir=<path>/<goerliDataDir>

Where <path> and <goerliDataDir> are the path and file where the Goerli chain data is to be saved.

Note: This option is only available from v0.8.3.

Run a Node for Testing

To run a node that mines blocks at a rate suitable for testing purposes:

$ bin/pantheon --dev-mode --network-id="2018" --bootnodes= --miner-enabled --miner-coinbase fe3b557e8fb62b89f4916b721be55ceb828dbd73 --rpc-cors-origins "all" --ws-enabled --rpc-enabled

Running Pantheon from Docker Image

Run Pantheon from Docker Image

A Docker image is provided to run a Pantheon node in a Docker container.

Use this Docker image to run a single Pantheon node without installing Pantheon.

Prerequisites

To run Pantheon from the Docker image, you must have Docker installed.

Quickstart

To run a Pantheon node in a container connected to the Ethereum mainnet:

docker run pegasyseng/pantheon:latest

Command Line Options

You cannot use the following Pantheon command line options when running Pantheon from the Docker image:

• --datadir, see Persisting Data
• --config, see Custom Configuration File
• --genesis, see Custom Genesis File.
• --rpc-listen, --p2plisten, --ws-listen, see Exposing Ports

All other Pantheon command line options work in the same way as when Pantheon is installed locally.

Persisting Data

Specify a Docker volume to persist data between stopping and restarting the container. This is the equivalent of specifying the -datadir option.

If a Docker volume is not specified, all data saved to the data directory is removed each time the container is stopped.

To run Pantheon specifying a volume for the data directory:

docker run --mount type=bind,source=/<pantheonDataDir>,target=/var/lib/pantheon pegasyseng/pantheon:latest

Where <pantheonDataDir> is the volume to which the data is saved.

Custom Configuration File

Specify a custom configuration file to provide a file containing key/value pairs for command line options. This is the equivalent of specifying the --config option.

To run Pantheon specifying a custom configuration file:

docker run --mount type=bind,source=/<path/myconf.toml>,target=/etc/pantheon/pantheon.conf pegasyseng/pantheon:latest

Where myconf.toml is your custom configuration file and path is the absolute path to the file. For example:

docker run --mount type=bind,source=/Users/username/pantheon/myconf.toml,target=/etc/pantheon/pantheon.conf pegasyseng/pantheon:latest

Custom Genesis File

Specify a custom genesis file to configure the blockchain. This is equivalent to specifying the --genesis option.

To run Pantheon specifying a custom genesis file:

docker run --mount type=bind,source=</path/mygenesis.json>,target=/etc/pantheon/genesis.json pegasyseng/pantheon:latest

Where mygenesis.json is your custom configuration file and path is the absolute path to the file. For example:

docker run --mount type=bind,source=/Users/username/pantheon/mygenesis.json,target=/etc/pantheon/genesis.json pegasyseng/pantheon:latest

Exposing Ports

Expose ports for P2P peer discovery, JSON-RPC service, and WebSockets. This is required to use the defaults ports or specify different ports (the equivalent of specifying the --rpc-listen, --p2p-listen, --ws-listen options).

To run Pantheon exposing local ports for access:

docker run -p <localportJSON-RPC>:8545 -p <localportWS>:8546 -p <localportP2P>:30303 pegasyseng/pantheon:latest --rpc-enabled --ws-enabled

For example, to enable RPC calls to http://127.0.0.1:8545 and P2P discovery on http://127.0.0.1:13001:

docker run -p 8545:8545 -p 13001:30303 pegasyseng/pantheon:latest --rpc-enabled

Starting Pantheon

Run a Node on Ethereum Mainnet

To run a node on the Ethereum mainnet:

docker run -p 30303:30303 --mount type=bind,source=/<myvolume/pantheon>,target=/var/lib/pantheon pegasyseng/pantheon:latest

To run a node on mainnet with the HTTP JSON-RPC service enabled:

docker run -p 8545:8545 -p 30303:30303 --mount type=bind,source=/<myvolume/pantheon>,target=/var/lib/pantheon pegasyseng/pantheon:latest --rpc-enabled

Run a Node on Ropsten Testnet

Save a local copy of the Ropsten genesis file.

To run a node on Ropsten:

docker run -p 30303:30303 --mount type=bind,source=/<myvolume/pantheon/ropsten>,target=/var/lib/pantheon --mount type=bind,source=/<path>/ropsten.json,target=/etc/pantheon/genesis.json pegasyseng/pantheon:latest --network-id=3 --bootnodes=enode://6332792c4a00e3e4ee0926ed89e0d27ef985424d97b6a45bf0f23e51f0dcb5e66b875777506458aea7af6f9e4ffb69f43f3778ee73c81ed9d34c51c4b16b0b0f@52.232.243.152:30303,enode://94c15d1b9e2fe7ce56e458b9a3b672ef11894ddedd0c6f247e0f1d3487f52b66208fb4aeb8179fce6e3a749ea93ed147c37976d67af557508d199d9594c35f09@192.81.208.223:30303

Run a Node on Rinkeby Testnet

To run a node on Rinkeby:

docker run -p 30303:30303 --mount type=bind,source=/<myvolume/pantheon/rinkeby>,target=/var/lib/pantheon pegasyseng/pantheon:latest --rinkeby

Run a Node for Testing

To run a node that mines blocks at a rate suitable for testing purposes with WebSockets enabled:

docker run -p 8546:8546 --mount type=bind,source=/<myvolume/pantheon/testnode>,target=/var/lib/pantheon pegasyseng/pantheon:latest --dev-mode --bootnodes= --miner-enabled --miner-coinbase fe3b557e8fb62b89f4916b721be55ceb828dbd73 --rpc-cors-origins "all" --ws-enabled

Stopping Pantheon and Cleaning up Resources

When you're done running nodes, you can shut down the node container without deleting resources. Alternatively, you can delete the container (after stopping it) and its associated volume. Run docker container ls and docker volume ls to obtain the container and volume names. Then run the following commands:

To stop a container:

docker stop <container-name>

To delete a container:

docker rm <container-name>

To delete a container volume (optional):

docker volume rm <volume-name>

Private Network Quickstart

Private Network Quickstart Tutorial

This tutorial describes how to use Pantheon to run a private network of Pantheon nodes in a Docker container.

Note To run the Private Network Quickstart, you must install Pantheon by cloning and building.

If you have installed Pantheon from the packaged binaries or are running the Docker image, you can proceed with Starting Pantheon.

Prerequisites

To run this tutorial, you must have the following installed:

• Docker and Docker-compose

• Git command line

• Curl command line

• A web browser that supports Metamask (currently Chrome, Firefox, Opera, and Brave), and has the MetaMask plug-in installed. This tutorial uses screenshots from Brave.

Clone Pantheon Source Code

As indicated in the installation section, clone the repository.

Build Docker Images and Start Services and Network

This tutorial uses Docker Compose to simplify assembling images and running in a private network. To run the containers, go to the pantheon directory and run the following commands:

On Linux/Mac, run the following shell command provided with the code:

quickstart/runPantheonPrivateNetwork.sh

On Windows, run the following docker-compose commands:

// Run the Docker containers
quickstart\docker-compose up -d --scale node=4

// List the endpoints
quickstart\docker-compose port explorer 80

This script builds Pantheon, builds the images and runs the containers. It will also scale the regular node container to four containers to simulate a network with enough peers to synchronize.

When the process ends, it lists the running services:

        Name                       Command               State                              Ports                           
-----------------------------------------------------------------------------------------------------------------------------
quickstart_bootnode_1    /opt/pantheon/bootnode_sta ...   Up      30303/tcp, 8545/tcp, 8546/tcp                              
quickstart_explorer_1    nginx -g daemon off;             Up      0.0.0.0:32770->80/tcp                                      
quickstart_minernode_1   /opt/pantheon/node_start.s ...   Up      30303/tcp, 8545/tcp, 8546/tcp                              
quickstart_node_1        /opt/pantheon/node_start.s ...   Up      30303/tcp, 8545/tcp, 8546/tcp                              
quickstart_node_2        /opt/pantheon/node_start.s ...   Up      30303/tcp, 8545/tcp, 8546/tcp                              
quickstart_node_3        /opt/pantheon/node_start.s ...   Up      30303/tcp, 8545/tcp, 8546/tcp                              
quickstart_node_4        /opt/pantheon/node_start.s ...   Up      30303/tcp, 8545/tcp, 8546/tcp                              
quickstart_rpcnode_1     /opt/pantheon/node_start.s ...   Up      30303/tcp, 0.0.0.0:32769->8545/tcp, 0.0.0.0:32768->8546/tcp

This is followed by a list of the endpoints:

****************************************************************
JSON-RPC HTTP service endpoint      : http://localhost:32770/jsonrpc   *
JSON-RPC WebSocket service endpoint : ws://localhost:32770/jsonws   *
Web block explorer address          : http://localhost:32770   *                                                                             
****************************************************************

• Use the JSON-RPC HTTP service endpoint to access the RPC node service from your Dapp or from cryptocurrency wallets such as Metamask.
• Use the JSON-RPC WebSocket service endpoint to access the web socket node service from your Dapp. Use the form ws://localhost:32770/jsonws.
• Use the Web block explorer address to display the block explorer web application. View the block explorer by entering the URL in your web browser.

On Linux/Mac, to display the list of endpoints again, run the following shell command:

quickstart/listQuickstartServices.sh

On Windows, to display the list of endpoints again, run the following docker-compose command:

quickstart\docker-compose port explorer 80

Block Explorer

This tutorial uses the Alethio light block explorer.

Run the Block Explorer

Access the explorer by copying and pasting the Web block explorer address displayed when starting the private network to your browser.

The block explorer displays a summary of the private network:

Notice the explorer indicates 6 peers: the 4 regular nodes, the mining node and the bootnode.

Click on the block number to the right of Best Block to display the block details.

You can explore blocks by clicking on the blocks under Bk down the left-hand side.

You can search for a specific block, transaction hash, or address by clicking the magnifying glass in the top left-hand corner.

Run JSON-RPC Requests

Now we're ready to run requests.

You can run RPC requests on rpcnode, the node that is exposed to the host in order to listen for requests. This tutorial uses cURL to make JSON-RPC requests.

On Windows: We suggest using Postman or a similar client to make RPC requests from Windows. Using curl via Command Prompt or Windows PowerShell might not work.

This tutorial uses the placeholder http://localhost:http-rpc-port. When you run this tutorial, replace http-rpc-port with the JSON-RPC HTTP service endpoint provided when you list the endpoints. (For example, http://localhost:32770/jsonrpc.) The dynamic docker port mapping changes each time you run the network.

Requesting the Node Version

Run the following command from the host shell :

curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}' http://localhost:http-rpc-port

The result should be as follows:

{
   "jsonrpc" : "2.0",
   "id" : 1,
   "result" : "pantheon/1.0.0"
}

Here we simply query the version of the Pantheon node, which confirms the node is running.

Now if this works, let's see some more interesting requests.

Counting Peers

Peers are the number of other nodes connected to the RPC node.

Poll the peer count using net_peerCount:

curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' http://localhost:http-rpc-port

The result should be the following response, indicating that there are 6 peers:

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : "0x6"
}

Requesting the Most Recent Mined Block Number

This provides the count of blocks already mined.

To do so, call eth_blockNumber to retrieve the number of the most recent block:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://localhost:http-rpc-port

The result of this call should be:

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : "0x8b8"
}

Here the hexadecimal value 0x8b8 translates to 2232 in decimal; that many blocks have already been mined.

Checking the Miner Account Balance (Coinbase)

Then call eth_getBalance to retrieve the balance of the mining address defined in the miner node:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xfe3b557e8fb62b89f4916b721be55ceb828dbd73","latest"],"id":1}' http://localhost:http-rpc-port

The result of this call should be something like :

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : "0x79f905c6fd34e80000"
}

0x79f905c6fd34e80000 = 2250000000000000000000 Wei (2250 Ether) (you can use a unit converter )

Wait a few seconds until new blocks are mined and make this call again. The balance should increase, meaning that the miner address successfully received the mining reward.

Also you can see this information in the block explorer. It does exactly the same thing as we did manually, connecting to the rpc node using http JSON-RPC, but displays information on a web page.

Additional Requests

Now that you are familiar with basic RPC requests you can run JSON-RPC commands to send transactions. In order to send transactions, you will first need to create an account or use one of the 3 accounts created during the genesis of this test network.

Account 1

This is the mining node coinbase account:

• Address: 0xfe3b557e8fb62b89f4916b721be55ceb828dbd73
• Private key : 0x8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63

• Initial balance : 0xad78ebc5ac6200000 (200000000000000000000 in decimal)

  Account 2

• Address: 0x627306090abaB3A6e1400e9345bC60c78a8BEf57

• Private key : 0xc87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3

• Initial balance : 0x90000000000000000000000 (2785365088392105618523029504 in decimal)

  Account 3

• Address: 0xf17f52151EbEF6C7334FAD080c5704D77216b732

• Private key : 0xae6ae8e5ccbfb04590405997ee2d52d2b330726137b875053c36d94e974d162f
• Initial balance : 0x90000000000000000000000 (2785365088392105618523029504 in decimal)

Note Pantheon does not provide an accounts management system, so if you want to create your own account, you will have to use a third party tool like Metamask.

Creating a Transaction Using MetaMask

After you sign in to MetaMask, connect to the private network RPC endpoint by:

1. In the MetaMask network list, select Custom RPC.
2. In the New RPC URL field, enter the JSON-RPC HTTP service endpoint displayed when you started the private network.

Save the configuration and return to the MetaMask main screen. Your current network is now set to the private network RPC node.

Import one of the existing accounts above into metamask using the corresponding private key.

NOTE that here we don't really care about securing the keys as it's just a tutorial, but be sure to secure your accounts when you run into a real usecase. This will be discussed in a more advanced chapter.

Once this is done, try to create another account from scratch to send some ether to.

Of course remember that here we are dealing with valueless ether as we are not on the main network but on a local private network.

In MetaMask, select the new account and copy the account address by clicking the ... button and selecting Copy Address to clipboard.

In the block explorer, search for the new account by clicking on the magnifying glass and pasting the account address into the search box. The account is displayed with a zero balance.

Send some ether from the first account (containing some ether) to the new one (that have a zero balance).

Click refresh on the browser page displaying the new account. The updated balance is displayed and reflects the transaction completed using MetaMask.

Truffle Pet Shop Tutorial

With a couple of modifications, we can use the private network in this tutorial as the blockchain for the PetShop tutorial on Truffle website.

Prerequisites

• Node.js v6+ LTS and npm (comes with Node)

Install Truffle and Unpack Truffle Box

Install Truffle :

npm install -g truffle

Note npm requires sudo on Linux.

Create a pet-shop-tutorial directory and move into it:

mkdir pet-shop-tutorial
cd pet-shop-tutorial

Unpack Pet Shop truffle box:

truffle unbox pet-shop

Install the wallet:

npm install truffle-privatekey-provider

Note npm requires sudo on Linux.

Modify the Pet Shop Example

Modify the truffle.js file in the pet-shop-tutorial directory to add our wallet provider:

const PrivateKeyProvider = require("truffle-privatekey-provider");
const privateKey = "8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63";
const privateKeyProvider = new PrivateKeyProvider(privateKey, "<YOUR HTTP RPC NODE ENDPOINT>");

module.exports = {
  // See <http://truffleframework.com/docs/advanced/configuration>
  // for more about customizing your Truffle configuration!
  networks: {
    development: {
      host: "127.0.0.1",
      port: 7545,
      network_id: "*" // Match any network id
    },
    quickstartWallet: {
      provider: privateKeyProvider,
      network_id: "*"
    },
  }
};

Replace <YOUR HTTP RPC NODE ENDPOINT> with your HTTP RPC node endpoint (for example, http://localhost:32770/jsonrpc).

The private key is the miner address which means it will have funds.

Once this is done, you can continue with the regular tutorial steps on the Truffle website until Step 3 in the Migration section.

Use Pantheon Private Network Instead of Genache

We are going to use our private network instead of Genache, so skip steps 3, 4, and 5 in the Migration section.

In step 4, specify our private network:

truffle migrate --network quickstartWallet

Output similar to the following is displayed (your addresses will differ):

Using network 'quickstartWallet'.

Running migration: 1_initial_migration.js
  Deploying Migrations...
  ... 0xfc1dbc1eaa14fa283c2c4415364579da0d195b3f2f2fefd7e0edb600a6235bdb
  Migrations: 0x9a3dbca554e9f6b9257aaa24010da8377c57c17e
Saving successful migration to network...
  ... 0x77cc6e9966b886fb74268f118b3ff44cf973d32b616ed4f050b3eabf0a31a30e
Saving artifacts...
Running migration: 2_deploy_contracts.js
  Deploying Adoption...
  ... 0x5035fe3ea7dab1d81482acc1259450b8bf8fefecfbe1749212aca86dc765660a
  Adoption: 0x2e1f232a9439c3d459fceca0beef13acc8259dd8
Saving successful migration to network...
  ... 0xa7b5a36e0ebc9c25445ce29ff1339a19082d0dda516e5b72c06ee6b99a901ec0
Saving artifacts...

Search for the deployed contracts and transactions in the block explorer using the addresses displayed in your output.

Continue with the regular tutorial steps in the Testing the smart contract section.

To run the tests in the Running the tests section, specify our private network:

truffle test --network quickstartWallet

Output similar to the following is displayed:

Using network 'quickstartWallet'.

Compiling ./contracts/Adoption.sol...
Compiling ./test/TestAdoption.sol...
Compiling truffle/Assert.sol...
Compiling truffle/DeployedAddresses.sol...


  TestAdoption
    ✓ testUserCanAdoptPet (2071ms)
    ✓ testGetAdopterAddressByPetId (6070ms)
    ✓ testGetAdopterAddressByPetIdInArray (6077ms)


  3 passing (37s)

Continue with the regular tutorial steps in the Creating a user interface to interact with the smart contract section.

We have already connected our private network to MetaMask so you can skip the Installing and configuring MetaMask section.

Continue with the regular tutorial steps from the Installing and configuring lite-server section to the end of the tutorial.

When you adopt pets in the browser and approve the transaction in MetaMask, you will be able to see the transactions in the block explorer.

Shut Down the Network and Remove the Containers

To shut down the network and delete all containers:

On Linux/Mac, run the following shell command:

quickstart/removePantheonPrivateNetwork.sh

On Windows, run the following docker-compose command:

quickstart\docker-compose down

Note On Windows, the quickstart creates a volume called quickstart_public-keys. Remove this volume using docker volume rm quickstart_public-keys.

Stop and restart the Private Network without Removing the Containers

To shut down the network without deleting the containers:

On Linux/Mac, run the following shell command:

quickstart/stopPantheonPrivateNetwork.sh

On Windows, run the following docker command:

docker-compose stop

(This command will also stop other running containers unrelated to quickstart.)

To restart the private network:

On Linux/Mac, run the following shell command:

quickstart/resumePantheonPrivateNetwork.sh

On Windows, run the following docker command:

docker-compose start

Network ID and Chain ID

Network ID and Chain ID

Ethereum networks have a network ID and a chain ID. The network ID is specified using the --network-id option and the chain ID is specified in the genesis file.

For most networks including mainnet and the public testnets, the network ID and the chain ID are the same.

The network ID is automatically set by Pantheon when connecting to the Ethereum mainnet (1), Rinkeby (4), and Ropsten(3).

When using the --dev-mode or --genesis options, specify the network ID using the --network-id option.

Node Keys

Node Keys

Each node has a node key pair consisting of a node private key and node public key.

Node Private Key

If a key file does not exist in the data directory and the --node-private-key option is not specified when Pantheon is started, a node private key is generated and written to the key file. If Pantheon is stopped and restarted without deleting the key file, the same private key is used when Pantheon is restarted.

If a key file exists in the data directory when Pantheon is started, the node is started with the private key in the key file.

Note The private key is not encrypted.

Node Public Key

The node public key is displayed in the log after starting Pantheon. Use the export-pub-key subcommand to export the public key to a file.

The node public key is also referred to as the node ID. The node ID forms part of the enode URL for a node.

Specifying a Custom Node Private Key File

Use the --node-private-key option to specify a custom key file in any location.

If the key file exists, the node is started with the private key in the custom key file. If the custom key file does not exist, a node private key is generated and written to the custom key file.

For example, the following command either reads the node private key from the privatekeyfile or writes the generated private key to the privatekeyfile:

bin/pantheon --node-private-key "/Users/username/privatekeyfile"

Networking

Networking

Pantheon uses the network to find and connect to peers.

Firewalls and Incoming Connections

The default logging configuration does not list node connection and disconnection messages.

To enable listing of node connection and disconnection messages, specify the command line option --logging=DEBUG. For more verbosity, specify --logging=TRACE.

The console logs connection and disconnection events when the log level is DEBUG or higher. If Successfully accepted connection from ... is displayed, connections are getting through the firewalls. For example:

2018-10-16 12:37:35.479-04:00 | nioEventLoopGroup-3-1 | INFO  | NettyP2PNetwork | Successfully accepted connection from 0xa979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c

If connections are not getting through the firewalls, ensure the peer discovery port is open on your firewall.

Peer Discovery Port

The --p2p-listen option specifies the host and port on which P2P peer discovery listens. The default is 127.0.0.1:30303.

Limiting Peers

Limiting peers reduces the bandwidth used by Pantheon. It also reduces the CPU time and disk access used to manage and respond to peers.

Use the --max-peers command line option to reduce the maximum number of peers. The default is 25.

Use the --max-trailing-peers option to reduce the maximum P2P peer connections for peers that are trailing behind the local chain head. The default is unlimited but the number of trailing peers cannot exceed the value specified by --max-peers.

Trailing peers cannot be used to get new blocks and are more likely to be requesting blocks from you. Limiting trailing peers may reduce the time taken to catch up to the chain head when synchronizing.

No Discovery

The --no-discovery command line option disables P2P peer discovery. Only use this option if you are running a test node or a test network with fixed nodes.

Monitoring Peer Connections

Use the debug_metrics JSON-RPC API method to obtain information about peer connections.

Accounts for Testing

Accounts for Testing

You can use existing accounts for testing by including them in the genesis file for a private network. Alternatively, Pantheon provides predefined accounts in development mode.

Development Mode

When you start Pantheon with the --dev-mode command line option, the dev.json genesis file is used by default.

The dev.json genesis file defines the accounts below that can be used for testing.

Warning Do not use the following accounts on mainnet or any public network except for testing. The private keys are displayed here so the accounts are not secure.

Account 1 (Miner Coinbase Account)

• Address: 0xfe3b557e8fb62b89f4916b721be55ceb828dbd73
• Private key : 0x8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63

• Initial balance : 0xad78ebc5ac6200000 (200000000000000000000 in decimal)

  Account 2

• Address: 0x627306090abaB3A6e1400e9345bC60c78a8BEf57

• Private key : 0xc87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3

• Initial balance : 0x90000000000000000000000 (2785365088392105618523029504 in decimal)

  Account 3

• Address: 0xf17f52151EbEF6C7334FAD080c5704D77216b732

• Private key : 0xae6ae8e5ccbfb04590405997ee2d52d2b330726137b875053c36d94e974d162f

• Initial balance : 0x90000000000000000000000 (2785365088392105618523029504 in decimal)

  Genesis File

To use existing test accounts, specify the accounts and balances in a genesis file for your test network. For an example of defining accounts in the genesis file, refer to dev.json.

Use the --genesis command line option to start Pantheon with the genesis file defining the existing accounts.

Logging

Logging

Pantheon uses Log4J2 for logging. There are two methods to configure logging behavior:

• Basic - changes the log level.
• Advanced - configures the output and format of the logs.

Note For most use-cases, the basic method provides sufficient configurability.

Basic Log Level Setting

Use the --logging command line option to specify the logging verbosity. The --logging option changes the volume of events displayed in the log.

Advanced Custom Logging

You can provide your own logging configuration using the standard Log4J2 configuration mechanisms. For example, the following Log4J2 configuration is the same as the default configuration except logging of stack traces for exceptions is excluded.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
  <Properties>
    <Property name="root.log.level">INFO</Property>
  </Properties>

  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSSZZZ} | %t | %-5level | %c{1} | %msg %throwable{short.message}%n" />    </Console>
  </Appenders>
  <Loggers>
    <Root level="${sys:root.log.level}">
      <AppenderRef ref="Console" />
    </Root>
  </Loggers>
</Configuration>

To use your custom configuration, set the environment variable LOG4J_CONFIGURATION_FILE to the location of your configuration file.

If you have more specific requirements, you can create your own log4j2 configuration.

For Bash-based executions, you can set the variable for only the scope of the program execution by setting it before starting Pantheon. For example, to set the debug logging and start Pantheon connected to the Rinkeby testnet:

LOG4J_CONFIGURATION_FILE=./debug.xml bin/pantheon --rinkeby

Testing and Developing Nodes

Testing and Developing Nodes

Bootnodes

Bootnodes are used to initially discover peers.

Mainnet and Public Testnets

For mainnet and Rinkeby, Pantheon predefines a list of enonde URLs. For Ropsten, bootnodes are specified using the --bootnodes option.

Private Networks

To start a bootnode for a private network:

1. Export the public key to a file:

   pantheon export-pub-key bootnode

   The node public key is exported to the bootnode file.

2. Start the bootnode, specifying:

   • An empty string for the --bootnodes option because this is the bootnode.

   • The network ID for your private network.

     pantheon --bootnodes="" --network-id 123 

To specify this bootnode for another node, the enode URL for the --bootnodes option is enode://<id>@<host:port> where:

• <id> is the node public key written to the specified file (bootnode in the above example) excluding the initial 0x.
• <host:port> is the host and port the bootnode is listening on for P2P peer discovery. Specified by the --p2p-listen option for the bootnode (default is 127.0.0.1:30303).

For example, if the --p2p-listen option is not specified and the node public key exported is 0xc35c3ec90a8a51fd5703594c6303382f3ae6b2ecb9589bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f

Then the enode URL is: enode://c35c3ec90a8a51fd5703594c6303382f3ae6b2ecb9589bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f@127.0.0.1:30303

Note The default host and port for P2P peer discovery is 127.0.0.1:30303. The --p2p-listen option can be used to specify a host and port.

To start a node specifying the bootnode for P2P discovery:

pantheon --datadir=/tmp/pantheon/30301 --p2p-listen=127.0.0.1:30301 --network-id=123 --bootnodes=enode://c35c3ec90a8a51fd5703594c6303382f3ae6b2ecb99bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f@127.0.0.1:30303

Proof of Authority

Proof of Authority

Pantheon implements the Clique Proof-of-Authority (PoA) consensus protocol. Clique is used by the Rinkeby testnet and can be used for private networks.

In PoA networks, transactions and blocks are validated by approved accounts, known as signers. Signers take turns to create the next block. Existing signers propose and vote to add or remove signers.

Genesis File

To use Clique in a private network, Pantheon requires a PoA genesis file. When connecting to Rinkeby, Pantheon uses the rinkeby.json genesis file in the /pantheon/ethereum/core/src/main/resources directory.

A PoA genesis file defines properties specific to Clique:

{
  "config": {
    ....
    "clique": {
      "period": 15,
      "epoch": 30000
    }
  },
  ...
  "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000dd37f65db31c107f773e82a4f85c693058fef7a90000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  ...
}

The properties specific to Clique are:

• period - Block time in seconds.
• epoch - Number of blocks after which to reset all votes.
• extraData - Initial signers are specified after the 32 bytes reserved for vanity data.

To connect to the Rinkeby testnet, start Pantheon with the --rinkeby option. To start a node on a PoA private network, use the --network-id and --genesis options.

Adding and Removing Signers

To propose adding or removing signers using the JSON-RPC methods, you must enable the RPC interface using the --rpc-enabled option. If also using the --rpc-api option, include CLIQUE.

The JSON-RPC methods to add or remove signers are:

• clique_propose
• clique_getSigners
• clique_discard

To propose adding a signer, call clique_propose specifying the address of the proposed signer and true. For example,

curl -X POST --data '{"jsonrpc":"2.0","method":"clique_propose","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73", true], "id":1}' <JSON-RPC-endpoint:port>

When the next block is created by the signer, a vote is added to the block for the proposed signer.

When more than half of the existing signers propose adding the signer and their votes have been distributed in blocks, the signer is added and can begin signing blocks.

Use clique_getSigners to return a list of the signers and to confirm that your proposed signer has been added.

curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSigners","params":["latest"], "id":1}' <JSON-RPC-endpoint:port>

To discard your proposal after confirming the signer was added, call clique_discard specifying the address of the proposed signer. For example:

 curl -X POST --data '{"jsonrpc":"2.0","method":"clique_discard","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"], "id":1}' <JSON-RPC-endpoint:port>

The process for removing a signer is the same as adding a signer except you specify false as the second parameter of clique_propose.

Epoch Transition

At each epoch transition, all pending votes collected from received blocks are discarded. Existing proposals remain in effect and signers re-add their vote the next time they create a block.

Define the number of blocks between epoch transitions in the genesis file.

Passing JVM Options

Passing JVM Options to Pantheon

To perform tasks such as attaching a debugger or configuring the garbage collector, pass JVM options to Pantheon.

Pantheon passes the contents of the PANTHEON_OPTS environmental variable to the JVM. Set standard JVM options in the PANTHEON_OPTS variable.

For Bash-based executions, you can set the variable for only the scope of the program execution by setting it before starting Pantheon. For example:

PANTHEON_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 bin/pantheon --rinkeby

Creating and Sending Transactions

Transactions

You can send signed transactions using the eth_sendRawTransaction JSON-RPC API method.

These examples describe how to create a signed raw transaction that can be passed to eth_sendRawTransaction.

To avoid exposing your private keys, create signed transactions offline.

The examples use the following libraries to create signed transactions:

• https://github.com/ethereum/web3.js/
• https://github.com/ethereumjs/ethereumjs-tx

Note: Other libraries (such as webj3 or ethereumj) and tools (such as MyEtherWallet or MyCrypto) can also be used to create signed transactions.

Example JS scripts are provided to create signed raw transaction strings to:

• Send ether
• Deploy a contract

Note: Node.js must be installed to run JS scripts.

The example JS scripts can be used to create raw transactions to send in the private network created by the Private Network Quickstart. The JSON-RPC endpoint in the examples must be updated to the endpoint for the private network displayed after running the quickstart/runPantheonPrivateNetwork.sh script.

To create and display the transaction string, run the JS script. For example:

node create_signed_raw_transaction.js

To send a signed transaction, run:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["raw_transaction_string"],"id":1}' <JSON-RPC-endpoint:port>

Where:

• raw_transaction_string is the signed raw transaction string displayed by the JS script.
• <JSON-RPC-endpoint:port> is the JSON-RPC endpoint.

For example:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xf86a808203e882520894f17f52151ebef6c7334fad080c5704d77216b732896c6b935b8bbd400000801ca08ce4a6c12f7f273321c5dc03910744f8fb11573fcce8140aa44486d385d22fb3a051f6bcc918bf3f12e06bfccfd1451bea5c517dffee0777ebd50caf177b17f383"],"id":1}' http://localhost:8545

All accounts and private keys in the examples are from the dev.json genesis file in the /pantheon/ethereum/core/src/main/resources directory.

Sending Ether

The following is an example of JavaScript that displays a signed transaction string to send ether.

const web3 = require('web3')
const ethTx = require('ethereumjs-tx')

// web3 initialization - must point to the HTTP JSON-RPC endpoint
const web3 = new Web3(new Web3.providers.HttpProvider('http://127.0.0.1:8545'))

// Sender address and private key
// Second acccount in dev.json genesis file
// Exclude 0x at the beginning of the private key
const addressFrom = '0x627306090abaB3A6e1400e9345bC60c78a8BEf57'
const privKey = Buffer.from('c87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3', 'hex')

// Receiver address and value to transfer
// Third account in dev.json genesis file
const addressTo = '0xf17f52151EbEF6C7334FAD080c5704D77216b732'
const valueInEther = 2000

// Get the address transaction count in order to specify the correct nonce
txnCount = web3.eth.getTransactionCount(addressFrom, "pending");

// Create the transaction object
var txObject = {
    nonce: web3.toHex(txnCount),
    gasPrice: web3.toHex(1000),
    gasLimit: web3.toHex(21000),
    to: addressTo,
    value: web3.toHex(web3.toWei(valueInEther, 'ether'))
};

// Sign the transaction with the private key
const tx = new ethTx(txObject);
tx.sign(privKey)

//Convert to raw transaction string
const serializedTx = tx.serialize();
const rawTxHex = '0x' + serializedTx.toString('hex');

console.log("Raw transaction string=" + rawTxHex)

Deploying a Contract

The following is an example of JavaScript that displays a signed raw transaction string to deploy a contract.

const web3 = require('web3')
const ethTx = require('ethereumjs-tx')

// web3 initialization - must point to the HTTP JSON-RPC endpoint
const web3 = new Web3(new Web3.providers.HttpProvider('http://127.0.0.1:8545'))

// Deployer address and private key
// First account in the dev.json genesis file
const addressFrom = '0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73'
const privKey = Buffer.from('8f2a55949038a9610f50fb23b5883af3b4ecb3c3bb792cbcefbd1542c692be63', 'hex')

// Compiled contract hash - can obtain from Remix by clicking the Details button in the Compile tab. 
// Compiled contract hash is value of data parameter in the WEB3DEPLOY section
const contractData = '0x608060405234801561001057600080fd5b5060dc8061001f6000396000f3006080604052600436106049576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680633fa4f24514604e57806355241077146076575b600080fd5b348015605957600080fd5b50606060a0565b6040518082815260200191505060405180910390f35b348015608157600080fd5b50609e6004803603810190808035906020019092919050505060a6565b005b60005481565b80600081905550505600a165627a7a723058202bdbba2e694dba8fff33d9d0976df580f57bff0a40e25a46c398f8063b4c00360029'

// Get the address transaction count in order to specify the correct nonce
txnCount = web3.eth.getTransactionCount(addressFrom, "pending");

var txObject = {
   nonce: web3.toHex(txnCount),
   gasPrice: web3.toHex(1000),
   gasLimit: web3.toHex(126165),
   data: contractData
};

const tx = new ethTx(txObject);
tx.sign(privKey)

const serializedTx = tx.serialize();
const rawTxHex = '0x' + serializedTx.toString('hex');

console.log("Raw transaction string=" + rawTxHex); 

eth_call or eth_sendRawTransaction

You can interact with contracts using eth_call or eth_sendRawTransaction.

eth_call	eth_sendRawTransaction
Read-only	Write
Invokes contract function locally	Broadcasts to network
Does not change state of blockchain	Updates blockchain (for example, transfers ether between accounts)
Does not consume gas	Requires gas
Synchronous	Asynchronous
Return value of contract function available immediately	Returns transaction hash only. Possible transaction may not be included in a block (for example, if the gas price is too low)

Using Wallets for Account Management

Using Wallets for Account Management

Pantheon does not implement private key management. Use third-party tools (for example, MetaMask and web3j) for creating accounts.

In Pantheon, you can use the JSON-RPC methods:

• eth_getBalance to obtain the account balance
• eth_sendRawTransaction to transfer ether or create and interact with contracts (for more information, refer to Transactions).

Mining

Mining

Start Pantheon with the following options to enable mining:

bin/pantheon --miner-enabled --miner-coinbase <account>

Where <account> is the account to which mining rewards are to be paid. For example, fe3b557e8fb62b89f4916b721be55ceb828dbd73.

JSON-RPC API methods for mining are:

• miner_start to start mining.
• miner_stop to stop mining.
• eth_mining to determine whether the client is actively mining new blocks.

RPC Pub/Sub

RPC Pub/Sub

Contents

• Introduction
• Subscribing
• Unsubscribing

Introduction

Use the RPC Pub/Sub API to wait for events instead of polling for them. For example, a Dapp can subscribe to logs to be notified when a specific event has occurred.

The RPC Pub/Sub methods are:

• eth_subscribe - create a subscription for specific events.
• eth_unsubscribe - cancel a subscription.

Note Unlike other JSON RPC-API methods, the RPC Pub/Sub methods cannot be called over HTTP.

Using RPC Pub/Sub

The RPC Pub/Sub API requires a persistent connection. Connect to the RPC Pub/Sub API using a tool such as WebSockets.

Use eth_subscribe to create subscriptions. Once subscribed, notifications are published by the API using eth_subscription.

Note Notifications are published by eth_subscription; you do not need to call eth_subscription.

Subscriptions are coupled to a connection. If the connection is closed, all subscriptions created over this connection are removed.

Subscription ID

eth_subscribe returns a subscription ID for each subscription created. Notifications include the subscription ID. For example, to create a synchronizing subscription:

{"id": 1, "method": "eth_subscribe", "params": ["syncing"]}

The result includes the subscription ID of "0x1":

{"jsonrpc":"2.0","id":1,"result":"0x1"}

The notifications also include the subscription ID of "0x1":

{"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0x1","result":{"startingBlock":"0x0","currentBlock":"0x50","highestBlock":"0x343c19"}}}

Notifications when Synchronizing

Subscribing to some events (for example, logs) can cause a flood of notifications while the node is synchronizing.

Subscribing

Use eth_subscribe to create subscriptions for the following event types:

• New headers
• Logs
• Pending transactions
• Synchronizing

New Headers

Use the newHeads parameter with eth_subscribe to be notified each time a block is added to the blockchain.

If a chain reorganization occurs, the subscription publishes notifications for blocks in the new chain. This means the subscription can publish notifications for multiple blocks at the same height on the blockchain.

The new headers subscription returns Block Objects.

To subscribe to new header notifications:

{"id": 1, "method": "eth_subscribe", "params": ["newHeads", {"includeTransactions": true}]}

The second parameter is optional. If specified, whole transaction objects are included in the notifications. Otherwise, the transaction hashes are included.

Example result:

{"jsonrpc":"2.0","id":2,"result":"0x1"}

Example notification without the {"includeTransactions": true} parameter included:

{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "params":{
    "subscription":"0x1",
    "result": {
      "number":"0x40c22",
      "hash":"0x16af2ee1672203c7ac13ff280822008be0f38e1e5bdc675760015ae3192c0e3a",
      "parentHash":"0x1fcf5dadfaf2ab4d985eb05d40eaa23605b0db25d736610c4b87173bfe438f91",
      "nonce":"0x0000000000000000",
      "sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
      "logsBloom":"0x00008000000000080000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000040000000000000000000000000000000000000000001000000000000000000000040000000000000000000000000000000000000400000000010000000000000000100000000000020000000000000000000000000000000000010000000000000000000000000000000000000000000",
      "transactionsRoot":"0x5b2e3c1a49352f1ca9fb5dfe74b7ffbbb6d70e23a12693444e26058d8a8e6296",
      "stateRoot":"0xbe8d3bc58bd982421a3ea8b66753404502df0f464ae78a17661d157c406dd38b",
      "receiptsRoot":"0x81b175ec1f4d44fbbd6ba08f1bd3950663b307b7cb35751c067b535cc0b58f12",
      "miner":"0x0000000000000000000000000000000000000000",
      "difficulty":"0x1",
      "totalDifficulty":"0x7c16e",
      "extraData":"0xd783010600846765746887676f312e372e33856c696e757800000000000000002160f780bb1f61eda045c67cdb1297ba37d8349df8035533cb0cf82a7e45f23f3d72bbec125a9f499b3eb110b7d1918d466cb2ede90b38296cfe2aaf452c513f00",
      "size":"0x3a1",
      "gasLimit":"0x47e7c4",
      "gasUsed":"0x11ac3a",
      "timestamp":"0x592afc24",
      "uncles":[],
      "transactions":["0x419c69d21b14e2e8f911def22bb6d0156c876c0e1c61067de836713043364d6c","0x70a5b2cb2cee6e0b199232a1757fc2a9d6053a4691a7afef8508fd88aeeec703","0x4b3035f1d32339fe1a4f88147dc197a0fe5bbd63d3b9dec2dad96a3b46e4fddd"],
      },
  }
}

Example notification with the {"includeTransactions": true} parameter included:

{
  "jsonrpc":"2.0",
  "method":"eth_subscription",
  "params":{
    "subscription":"0x1",
    "result": {
       ....
       "transactions":[
         {
           "blockHash":"0xa30ee4d7c271ae5150aec494131c5f1f34089c7aa8fb58bd8bb916a55275bb90",
           "blockNumber":"0x63",
           "from":"0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
           "gas":"0x5208",
           "gasPrice":"0x3b9aca00",
           "hash":"0x11f66c3e96a92e3c14c1c33ad77381221bf8b58a887b4fed6aee456fc6f39b24",
           "input":"0x",
           "nonce":"0x1",
           "to":"0x627306090abab3a6e1400e9345bc60c78a8bef57",
           "transactionIndex":"0x0",
           "value":"0x56bc75e2d63100000",
           "v":"0xfe8",
           "r":"0x4b57d179c74885ef5f9326fd000665ea7fae44095c1e2016a2817fc671beb8cc",
           "s":"0x7ec060b115746dda392777df07ae1feacc0b83b3646f0a3de9a5fc3615af9bb8",
          }
        ],
     },
   },
}

Logs

Use the logs parameter with eth_subscribe to be notified of logs included in new blocks. You can specify a filter object to receive notifications only for logs matching your filter.

Logs subscriptions have an filter object parameter with the following fields:

• address - (optional) Either an address or an array of addresses. Returns only logs created from these addresses.
• topics - (optional) Returns only logs that match the specified topics.

Note The fromBlock and toBlock attributes are not included in the filter object for the logs subscription because the subscription waits for logs rather than requesting them.

If a chain reorganization occurs, the subscription publishes notifications for logs from the old chain with the removed property in the log object set to true. This means the subscription can publish notifications for multiple logs for the same transaction.

The logs subscription returns Log objects.

To subscribe to all logs notifications:

 {"id": 1, "method": "eth_subscribe", "params": ["logs",{}]}

To subscribe to logs for a specific address and topic:

{"id": 1, "method": "eth_subscribe", "params": ["logs", {"address": "0x8320fe7702b96808f7bbc0d4a888ed1468216cfd", "topics": ["0xd78a0cb8bb633d06981248b816e7bd33c2a35a6089241d099fa519e361cab902"]}]}

Example result:

{"jsonrpc":"2.0","id":1,"result":"0x2"}

Example notification:

{
  "jsonrpc":"2.0",
  "method":"eth_subscription",
  "params":{
    "subscription":"0x2",
    "result":{
      "logIndex":"0x0",
      "removed":false,
      "blockNumber":"0x2174",
      "blockHash":"0x7bc83837534aa13df55ff7db77784b1d1ba666d4c4bdd223cae9fe09c7c37eba",
      "transactionHash":"0x942179373e413824c6bc7045e92295aff91b679215446549b4aeb084da46495b",
      "transactionIndex":"0x0",
      "address":"0x9b8397f1b0fecd3a1a40cdd5e8221fa461898517",
      "data":"0x",
      "topics":["0x199cd93e851e4c78c437891155e2112093f8f15394aa89dab09e38d6ca072787","0x0000000000000000000000000000000000000000000000000000000000000005"],
     },
   },
}

Pending Transactions

Use the newPendingTransactions parameter with eth_subscribe to be notified of pending transactions added to the transaction pool for the node.

The pending transactions subscription returns the transaction hashes of the pending transactions.

If a chain reorganization occurs, transactions are resubmitted to be included in the new canonical chain. This means the subscription can publish notifications for the same pending transaction more than once.

To subscribe to pending transaction notifications:

{"id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]}

Example result:

{"jsonrpc":"2.0","id":1,"result":"0x1"}

Example notification:

{
  "jsonrpc":"2.0",
  "method":"eth_subscription",
  "params":{
    "subscription":"0x1",
    "result":"0x5705bc8bf875ff03e98adb98489428835892dc6ba6a6b139fee1becbc26db0b8"
  }
}

Synchronizing

Use the syncing parameter with eth_subscribe to be notified about synchronization progress.

The sychronizing subscription returns an object indicating the synchronization progress.

To subscribe to synchronizing notifications:

{"id": 1, "method": "eth_subscribe", "params": ["syncing"]}

Example result:

{"jsonrpc":"2.0","id":1,"result":"0x4"}

Example notification:

{
  "jsonrpc":"2.0",
  "method":"eth_subscription",
  "params":{
    "subscription":"0x4",
    "result":{
      "startingBlock":"0x0",
      "currentBlock":"0x3e80",
      "highestBlock":"0x67b93c",
     }
  }
}

Unsubscribing

Use the subscription ID with eth_unsubscribe to cancel a subscription. Only the connection that created a subscription can unsubscribe from it.

To unsubscribe from a subsciption with subscription ID of 0x1:

{"id": 1, "method": "eth_unsubscribe", "params": ["0x1"]}

eth_unsubscribe returns true if subscription succuessfully unsubscribed; otherwise, an error is returned.

Example result:

{"jsonrpc":"2.0","id":1,"result":true}

Debugging Pantheon

FAQ

My command line options are not working as I expected?

Ensure quotes have not been automatically converted to smart quotes or hyphens combined if copying and pasting.

How can I monitor node performance and connectivity?

Using the debug_metrics JSON-RPC API method.

Pantheon CLI Reference

Pantheon Command Line Interface Reference

This reference describes the syntax of the Pantheon Command Line Interface (CLI) options and subcommands.

pantheon [OPTIONS] [COMMAND]

Runs the Pantheon Ethereum full node client.

Options

--banned-nodeids=<bannedNodeId&gt[,<bannedNodeId>...]...

List of node IDs with which this node will not peer. The node ID is the public key of the node. You can specify the banned node IDs with or without the 0x prefix.

>Note This option is only available from v0.8.2.

--bootnodes=<enode://id@host:port>[,<enode://id@host:port>...]...

List of comma-separated enode URLs for P2P discovery bootstrap.

When connecting to mainnet and Rinkeby, the default is a predefined list of enode URLs. Specify bootnodes when connecting to Ropsten or a private network.

--config=<PATH>

The path to the TOML configuration file. The default is none. The TOML file is composed of key/value pairs. Each key is the same as the corresponding CLI option name without the leading dashes (--). The config option is not used in the config file. Values must be treated according to TOML specifications for string, numbers, arrays and Booleans. Example: # Valid TOML config file datadir="~/pantheondata" # Path # Network bootnodes=["enode://001@123:4567", "enode://002@123:4567", "enode://003@123:4567"] p2p-listen="1.2.3.4:1234" # IP:port max-peers=42 rpc-listen="5.6.7.8:5678" # IP:port ws-listen="9.10.11.12:9101" # IP:port # Chain genesis="~/genesis.json" # Path to the custom genesis file # Mining miner-enabled=true miner-coinbase="0x0000000000000000000000000000000000000002"

> Note: This option is not used when running Pantheon from the Docker image.

--datadir=<PATH>

The path to the Pantheon data directory. The default location is the /build/distributions/pantheon- directory in the Pantheon installation directory.

> Note: This option is not used when running Pantheon from the Docker image.

--dev-mode

Set this option to true to run in development mode. For example, specify this option to perform CPU mining more easily in a private test network. In development mode, a custom genesis configuration specifies the chain ID. When using this option, also set the --network-id option to the network you use for development. Default is false.

> Note: The --dev-mode option overrides the --genesis option. If both are specified, the development mode configuration is used.

--genesis=<PATH>

The path to the genesis file. The default is the embedded genesis file for the Ethereum mainnet. When using this option, it is recommended to also set the --network-id option.

> Note: This option is not used when running Pantheon from the Docker image.
> Note: The --genesis option is overridden by the --dev-mode option. If both are specified, the specified genesis file is ignored and the development mode configuration used.

--goerli

Uses the Goerli test network. Default is false.

> Note: This option is only available from v0.8.3.

--host-whitelist=<hostname>

Comma-separated list of hostnames to allow access to the HTTP JSON-RPC API. Default is localhost.

To allow all hostnames, use * or all. We don't recommend this for production code. > Note: This option is only available from v0.8.3. Earlier versions allow access by all hostnames.

--max-peers=<INTEGER>

Specifies the maximum P2P peer connections that can be established. The default is 25.

--max-trailing-peers=<INTEGER>

Specifies the maximum P2P peer connections for peers that are trailing behind the local chain head. The default is unlimited but the number of trailing peers cannot exceed the value specified by --max-peers.

--miner-coinbase=<Ethereum account address>

Account to which mining rewards are paid. You must specify a valid coinbase when you enable mining using the --miner-enabled option or the miner_start JSON RPC-API method.

> Note: This option is ignored in networks using the Clique Proof-of-Authority (PoA) consensus protocol.

--miner-enabled

Enables mining when the node is starts. Default is false.

--miner-extraData=<Extra data>

A hex string representing the 32 bytes to be included in the extra data field of a mined block. The default is 0x.

--miner-minTransactionGasPriceWei=<minTransactionGasPrice>

The minimum price that a transaction offers for it to be included in a mined block The default is 1000.

--network-id=<INTEGER>

P2P network identifier. The default is set to mainnet with value 1.

--no-discovery

Disables P2P peer discovery. The default is false.

--node-private-key=<PATH>

<PATH> is the path of the private key file of the node. The default is the key file in the data directory. If no key file exists, a key file containing the generated private key is created; otherwise, the existing key file specifies the node private key.

> Note The private key is not encrypted. >Note This option is only available from v0.8.2.

--nodes-whitelist[=<enode://id@host:port>[,<enode://id@host:port>...]...]

Comma-separated enode URLs for permissioned networks. If you specify an empty list or --nodes-whitelist without a list, your node will not connect to any other nodes.

>Note This option is only available from v0.8.3. > Note: Permissioning is not currently supported. Support for permissioning is in active development.

--ottoman

Synchronize against the Ottoman test network. This is only useful if you are using an IBFT genesis file. The default is false.

> Note: IBFT is not currently supported. Support for IBFT is in active development.

--p2p-listen=<HOST:PORT>

Specifies the host and port on which P2P peer discovery listens. The default is 127.0.0.1:30303.

> Note This option is not used when running Pantheon from the Docker image.

--rinkeby

Uses the Rinkeby test network. Default is false.

--ropsten

Uses the Ropsten test network. Default is false.

> Note This option is only available only from v0.8.2. For v0.8.1, refer here.

--rpc-enabled

Set to true to enable the JSON-RPC service (RPC over HTTP). The default is false.

--rpc-listen=<HOST:PORT>

Specifies the host and port on which JSON-RPC listens. The default is 127.0.0.1:8545.

> Note: This option is not used when running Pantheon from the Docker image.

--rpc-api=<api name>[,...]...

Comma-separated APIs to enable on the JSON-RPC channel. When you use this option, the --rpc-enabled option must also be specified. The available API options are: ETH, NET, WEB3, CLIQUE, IBFT, DEBUG, and MINER. The default is: ETH, NET, WEB3, CLIQUE, IBFT.

> Note: IBFT is not currently supported. Support for IBFT is in active development.

--rpc-cors-origins=<rpcCorsAllowedOrigins>

Specifies domain URLs for CORS validation. Domain URLs must be enclosed in double quotes and comma-separated. Listed domains will be allowed access to node data (whitelisted). If your client interacts with Pantheon using a browser app (such as Remix using a direct connection or a block explorer), you must whitelist the client domains. For example, the following allows Remix to interact with your Pantheon node without using MetaMask: --rpc-cors-origins "http://remix.ethereum.org" Note: MetaMask runs as native code so does not require CORS validation. If Remix is connecting to the node through MetaMask, it also does not require CORS validation. The default value is "none". If you don't whitelist any domains, you won't be able to use webapps to interact with your Pantheon node. You can whitelist one or more domains with a comma-separated list. For example: --rpc-cors-origins "http://foo.com, https://bar.io" For development purposes, you can use "all" to accept requests from any domain, but we don't recommend this for production code.

--ws-enabled

Set to true to enable the WS-RPC (WebSockets) service. The default is false.

--ws-api=<api name>[,...]...

Comma-separated APIs to enable on Websockets channel. When you use this option, the --ws-enabled option must also be specified. The available API options are: ETH, NET, WEB3, CLIQUE, IBFT, DEBUG, and MINER. The default is: ETH, NET, WEB3, CLIQUE, IBFT.

> Note: IBFT is not currently supported. Support for IBFT is in active development.

--ws-listen=<HOST:PORT>

Host and port for WS-RPC (Websocket) to listen on. The default is 127.0.0.1:8546.

> Note: This option is not used when running Pantheon from the Docker image.

-h, --help

Show the help message and exit.

-l, --logging=<LEVEL>

Sets the logging verbosity. Log levels are OFF, FATAL, WARN, INFO, DEBUG, TRACE, ALL. Default is INFO.

-V, --version

Print version information and exit.

---

Commands

Pantheon subcommands are:

• import

  Imports blocks from the specified file into the blockchain database:

  pantheon import <block-file>

• export-pub-key

  Exports node public key to the specified file.

  pantheon export-pub-key <key-file>

###

---

Pantheon is licensed under Apache License 2.0.

Pantheon JSON-RPC API

Pantheon JSON-RPC API

The Pantheon JSON-RPC API uses the JSON (RFC 4627) data format, which can represent objects and data fields as collections of name/value pairs, in a relatively readable, hierarchical form. Values have specific data types such as QUANTITIES (decimal integers, hexadecimal numbers, strings) and UNFORMATTED DATA (byte arrays, account addresses, hashes, and bytecode arrays).

RPC is the remote procedure call protocol (RFC 1831), which is stateless and transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments.

• Using the Pantheon JSON-RPC API
• JSON-RPC API Methods
• JSON-RPC API Objects

Using the JSON-RPC API

Contents

• Postman
• Endpoint Address and Port
• HTTP and WebSocket Requests
• Block Parameter
• Not Supported by Pantheon

Breaking Change in v0.8.3

From v0.8.3, incoming HTTP requests are only accepted from hostnames specified using the --host-whitelist option. If not specified, the default value for --host-whitelist is localhost.

If using the URL http://127.0.0.1 to make JSON-RPC calls, use --host-whitelist to specify the hostname 127.0.0.1 or update the hostname to localhost.

If your application publishes RPC ports, specify the hostnames when starting Pantheon. For example:

pantheon --host-whitelist=foo.com

Specify * or all for --host-whitelist to effectively disable host protection and replicate pre-v0.8.3 behavior. This is not recommended for production code.

Using the Pantheon JSON-RPC API

Postman

Use the button to import our collection of examples to Postman.

Endpoint Address and Port

In this reference, the placeholder <JSON-RPC-http-endpoint:port> and <JSON-RPC-ws-endpoint:port> means an endpoint (IP address and port) of the JSON-RPC service of a Pantheon node respectively for http endpoint and for WebSocket endpoint. To activate JSON-RPC using http or WebSocket, see --rpc-listen and --ws-listen options in the CLI documentation.

The transport attributes are:

• HTTP: Listens by default on port 8545
• WebSockets: Listens by default on port 8546

HTTP and WebSocket Requests

HTTP

To make RPC over HTTP requests, you can use the curl tool, available in many systems using curl source code or pre-compiled packages.

curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":53}' <JSON-RPC-http-endpoint:port>

WebSockets

To make requests over WebSockets, this reference uses wscat, a Node.js based command-line tool.

First connect to the WebSockets server using wscat (you only need to connect once per session):

wscat -c ws://<JSON-RPC-ws-endpoint:port>

After the connection is established, the terminal will display a '>' prompt. Send individual requests as a JSON data package at each prompt:

{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":53}

The RPC Pub/Sub methods can also be used over WebSockets.

Block Parameter

When you make requests that might have different results depending on the block accessed, the block parameter specifies the block. Several methods, such as eth_getTransactionByBlockNumberAndIndex, have a block parameter.

The block parameter can have the following values:

• blockNumber : quantity - Block number. Can be specified in hexadecimal or decimal. 0 represents the genesis block.
• earliest : tag - Earliest (genesis) block.
• latest : tag - Last block mined.
• pending : tag - Last block mined plus pending transactions. Use only with eth_getTransactionCount.

Not Supported by Pantheon

Account Management

Account management relies on private key management in the client which is not implemented by Pantheon.

Use eth_sendRawTransaction to send signed transactions; eth_sendTransaction is not implemented.

Use third-party wallets for account management.

Protocols

Pantheon does not implement the Whisper and Swarm protocols.

JSON-RPC API Methods

Breaking Change in v0.8.3

From v0.8.3, incoming HTTP requests are only accepted from hostnames specified using the --host-whitelist option.

JSON-RPC Methods

The following lists the Pantheon JSON-RPC API commands:

admin Methods

• admin_peers

web3 Methods

• web3_clientVersion
• web3_sha3

net Methods

• net_version
• net_listening
• net_peerCount

eth Methods

• eth_syncing
• eth_chainId
• eth_coinbase
• eth_mining
• eth_gasPrice
• eth_accounts
• eth_blockNumber
• eth_getBalance
• eth_getStorageAt
• eth_getTransactionCount
• eth_getBlockTransactionCountByHash
• eth_getBlockTransactionCountByNumber
• eth_getUncleCountByBlockHash
• eth_getUncleCountByBlockNumber
• eth_getCode
• eth_sendRawTransaction
• eth_call
• eth_estimateGas
• eth_getBlockByHash
• eth_getBlockByNumber
• eth_getTransactionByHash
• eth_getTransactionByBlockHashAndIndex
• eth_getTransactionByBlockNumberAndIndex
• eth_getTransactionReceipt
• eth_newFilter
• eth_newBlockFilter
• eth_newPendingTransactionFilter
• eth_uninstallFilter
• eth_getFilterChanges
• eth_getFilterLogs
• eth_getLogs
• eth_getWork

debug Methods

• debug_metrics
• debug_traceTransaction

miner Methods

• miner_start
• miner_stop

clique Methods

• clique_discard
• clique_getSigners
• clique_getSignersAtHash
• clique_propose
• clique_proposals

ibft Methods

IBFT is not currently supported. Support for IBFT is in active development.

---

JSON-RPC API Reference

---

admin_peers

Returns networking information about connected nodes.

Parameters

None

Returns

result : array of objects - Object returned for each remote node.

Properties of the remote node object are:

• version - P2P protocol version
• name - Client name
• caps - P2P message capabilities
• network - Addresses of local node and remote node
• port - Port on remote node on which P2P peer discovery is listening
• id - Node public key. Excluding the 0x prefix, the node public key is the ID in the enode URL enode://<id ex 0x>@<host:port>.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"admin_peers","params":[],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : [ 
    {
      "version": "0x5",
      "name": "Parity-Ethereum/v2.3.0-nightly-1c2e121-20181116/x86_64-linux-gnu/rustc1.30.0",
      "caps": [
         "eth/62",
         "eth/63",
         "par/1",
         "par/2",
         "par/3",
         "pip/1"
      ],
      "network": {
         "localAddress": "192.168.1.229:50115",
         "remoteAddress": "168.61.153.255:40303"
      },
      "port": "0x9d6f",
      "id": "0xea26ccaf0867771ba1fec32b3589c0169910cb4917017dba940efbef1d2515ce864f93a9abc846696ebad40c81de7c74d7b2b46794a71de8f95a0d019f494ff3"
    } 
  ]
}

---

web3_clientVersion

Returns the current client version.

Parameters

None

Returns

result : string - Current client version.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "pantheon/1.0.0"
}

---

web3_sha3

Returns a SHA3 hash of the specified data. The result value is a Keccak-256 hash, not the standardized SHA3-256.

Parameters

DATA - Data to convert to a SHA3 hash.

Returns

result (DATA) - SHA3 result of the input data.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c00"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x5e39a0a66544c0668bde22d61c47a8710000ece931f13b84d3b2feb44ec96d3f"
}

---

net_version

Returns the current chain ID.

Parameters

None

Returns

result : string - Current chain ID.

• 1 - Ethereum Mainnet
• 2 - Morden Testnet (deprecated)
• 3 - Ropsten Testnet
• 4 - Rinkeby Testnet
• 42 - Kovan Testnet

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

Mainnet:

{
  "jsonrpc" : "2.0",
  "id" : 51,
  "result" : "1"
}

Ropsten:

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "3"
}

---

net_listening

Indicates whether the client is actively listening for network connections.

Parameters

None

Returns

result (BOOLEAN) - true if the client is actively listening for network connections; otherwise false.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : true
}

---

net_peerCount

Returns the number of peers currently connected to the client.

Parameters

None

Returns

result : integer - Number of connected peers in hexadecimal.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x5"
}

---

eth_syncing

Returns an object with data about the synchronization status, or false if not synchronizing.

Parameters

None

Returns

result : Object|Boolean - Object with synchronization status data or false, when not synchronizing:

• startingBlock : quantity - Index of the highest block on the blockchain when the network synchronization starts.

  If you start with an empty blockchain, the starting block is the beginning of the blockchain (startingBlock = 0).

  If you import a block file using pantheon import <block-file>, the synchronization starts at the head of the blockchain, and the starting block is the next block synchronized. For example, if you imported 1000 blocks, the import would include blocks 0 to 999, so in that case startingBlock = 1000.

• currentBlock : quantity - Index of the latest block (also known as the best block) for the current node. This is the same index that eth_blockNumber returns.

• highestBlock: quantity - Index of the highest known block in the peer network (that is, the highest block so far discovered among peer nodes). This is the same value as currentBlock if the current node has no peers.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":51}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 51,
  "result" : {
    "startingBlock" : "0x5a0",
    "currentBlock" : "0xad9",
    "highestBlock" : "0xad9"
  }

---

eth_chainId

Returns the chain ID.

Note This method is only available from v0.8.2.

Parameters

None

Returns

result : quantity - Chain ID in hexadecimal.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":51}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 51,
  "result" : "0x7e2"
}

---

eth_coinbase

Returns the client coinbase address. The coinbase address is the account to which mining rewards are paid.

To set a coinbase address, start Pantheon with the --miner-coinbase option set to a valid Ethereum account address. You can get the Ethereum account address from a client such as MetaMask or Etherscan. For example:

bin/pantheon --miner-coinbase="0xDD37f65dB31c107F773E82a4F85C693058fEf7a9" --rpc-enabled

Parameters

None

Returns

result : data - Coinbase address.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0xdd37f65db31c107f773e82a4f85c693058fef7a9"
}

---

eth_mining

Indicates whether the client is actively mining new blocks. Mining is paused while the client synchronizes with the network regardless of command settings or methods called.

Parameters

None

Returns

result (BOOLEAN) - true if the client is actively mining new blocks; otherwise false.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : true
}

---

eth_gasPrice

Returns the current gas unit price in wei.

Parameters

None

Returns

result : quantity - Current gas unit price in wei as a hexadecimal value.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x3e8"
}

---

eth_accounts

Returns a list of account addresses that the client owns.

NOTE: This method returns an empty object because Pantheon does not support account management.

Parameters

None

Returns

Array of data : List of 20-byte account addresses owned by the client.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":53}'  <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : [ ]
}

---

eth_blockNumber

Returns the index of the current block the client is processing.

Parameters

None

Returns

result : QUANTITY - Hexadecimal integer representing the 0-based index of the block that the client is currently processing.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":51}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 51,
  "result" : "0x2377"
}

---

eth_getBalance

Returns the account balance of the specified address.

Parameters

DATA - 20-byte account address from which to retrieve the balance.

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result : QUANTITY - Integer value of the current balance in wei.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xdd37f65db31c107f773e82a4f85c693058fef7a9", "latest"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x0"
}

---

eth_getStorageAt

Returns the value of a storage position at a specified address.

Parameters

DATA - A 20-byte storage address.

QUANTITY - Integer index of the storage position.

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result : DATA - The value at the specified storage position.

Request

Calculating the correct position depends on the storage you want to retrieve.

curl -X POST --data '{"jsonrpc":"2.0","method": "eth_getStorageAt","params": ["0x‭3B3F3E‬","0x0","latest"],"id": 53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x0000000000000000000000000000000000000000000000000000000000000000"
}

---

eth_getTransactionCount

Returns the number of transactions sent from a specified address.

Parameters

DATA - 20-byte account address.

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result : QUANTITY - Integer representing the number of transactions sent from the specified address.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0xc94770007dda54cF92009BFF0dE90c06F603a09f","latest"],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : "0x1"
}

---

eth_getBlockTransactionCountByHash

Returns the number of transactions in the block matching the given block hash.

Parameters

DATA - 32-byte block hash.

Returns

result : QUANTITY - Integer representing the number of transactions in the specified block.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : null
}

---

eth_getBlockTransactionCountByNumber

Returns the number of transactions in a block matching the specified block number.

Parameters

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result : QUANTITY - Integer representing the number of transactions in the specified block.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0xe8"],"id":51}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 51,
  "result" : "0x8"
}

---

eth_getUncleCountByBlockHash

Returns the number of uncles in a block from a block matching the given block hash.

Parameters

DATA - 32-byte block hash.

Returns

result : QUANTITY - Integer representing the number of uncles in the specified block.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0xb903239f8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238"],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : null
}

---

eth_getUncleCountByBlockNumber

Returns the number of uncles in a block matching the specified block number.

Parameters

QUANTITY|TAG - Integer representing either the 0-based index of the block within the blockchain, or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result : QUANTITY - Integer representing the number of uncles in the specified block.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : "0x1"
}

---

eth_getCode

Returns the code of the smart contract at the specified address. Compiled smart contract code is stored as a hexadecimal value.

Parameters

DATA - 20-byte contract address.

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result : DATA - Code stored at the specified address.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xa50a51c09a5c451c52bb714527e1974b686d8e77", "latest"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
    "jsonrpc": "2.0",
    "id": 53,
    "result": "0x60806040526004361060485763ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416633fa4f2458114604d57806355241077146071575b600080fd5b348015605857600080fd5b50605f6088565b60408051918252519081900360200190f35b348015607c57600080fd5b506086600435608e565b005b60005481565b60008190556040805182815290517f199cd93e851e4c78c437891155e2112093f8f15394aa89dab09e38d6ca0727879181900360200190a1505600a165627a7a723058209d8929142720a69bde2ab3bfa2da6217674b984899b62753979743c0470a2ea70029"
}

---

eth_sendRawTransaction

Sends a signed transaction. A transaction can send ether, deploy a contract, or interact with a contract.

You can interact with contracts using eth_sendRawTransaction or eth_call.

To avoid exposing your private key, create signed transactions offline and send the signed transaction data using this method. For information on creating signed transactions and using eth_sendRawTransaction, refer to Using Pantheon.

Note: Pantheon does not implement eth_sendTransaction.

Parameters

DATA - Hash of the signed raw transaction in hexadecimal format; for example:

params: ["0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"]

Returns

result : DATA - 32-byte transaction hash, or zero hash if the transaction is not yet available.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "id":1,
  "jsonrpc": "2.0",
  "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
}

---

eth_call

Invokes a contract function locally and does not change the state of the blockchain.

You can interact with contracts using eth_sendRawTransaction or eth_call.

Parameters

OBJECT - Transaction call object.

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result (DATA) - Return value of the executed contract.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x69498dd54bd25aa0c886cf1f8b8ae0856d55ff13","value":"0x1"}, "latest"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
    "jsonrpc": "2.0",
    "id": 53,
    "result": "0x"
}

---

eth_estimateGas

Generates and returns an estimate of how much gas is necessary to allow the transaction to complete. (Per Etherscan: gas price * gas used.) The transaction is added to the blockchain. The estimate may be significantly more than the amount of gas actually used by the transaction for reasons including EVM mechanics and node performance.

Parameters

NOTE: Parameters are the same as the eth_call parameters, except that all properties are optional. If you do not specify a gas limit, Pantheon uses the gas limit from the pending block as an upper bound. As a result, the returned estimate might not be enough to execute the call or transaction when the amount of gas is higher than the pending block's gas limit.

OBJECT - Transaction call object.

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result (QUANTITY) - Amount of gas used.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{"from":"0x687422eea2cb73b5d3e242ba5456b782919afc85","to":"0xdd37f65db31c107f773e82a4f85c693058fef7a9","value":"0x1"}],"id":53}' <JSON-RPC-endpoint:port>

Result

The following result yields a gas amount estimate of 21000 wei (0x5208) for the transaction.

{
  "jsonrpc" : "2.0",
  "id" : 54,
  "result" : "0x5208"
}

---

eth_getBlockByHash

Returns information about the block by hash.

Parameters

DATA - 32-byte hash of a block.

Boolean - If true, returns the full transaction objects; if false, returns the transaction hashes.

Returns

result : OBJECT - Block object , or null when no block is found.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0x16b69965a5949262642cfb5e86368ddbbe57ab9f17d999174a65fd0e66580d8f", false],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : {
    "number" : "0x7",
    "hash" : "0x16b69965a5949262642cfb5e86368ddbbe57ab9f17d999174a65fd0e66580d8f",
    "parentHash" : "0xe9bd4b277983580ef0eabad6011891f8b6aff9381a78bd1c4faca374a48b3e09",
    "nonce" : "0x46acb59e85b5bb6d",
    "sha3Uncles" : "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "logsBloom" : "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "transactionsRoot" : "0x7aa0913c235f272eb6ed6ab74ba5a057e0a62c1c1d1dbccfd971221e6b6e83a3",
    "stateRoot" : "0xfaf6520d6e3d24107a4309855593341ab87a1744dbb6eea4e709b92e9c9107ca",
    "receiptsRoot" : "0x056b23fbba480696b65fe5a59b8f2148a1299103c4f57df839233af2cf4ca2d2",
    "miner" : "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
    "difficulty" : "0x5",
    "totalDifficulty" : "0x10023",
    "extraData" : "0x",
    "size" : "0x270",
    "gasLimit" : "0x1000000",
    "gasUsed" : "0x5208",
    "timestamp" : "0x5bbbe99f",
    "uncles" : [ ],
    "transactions" : [ "0x2cc6c94c21685b7e0f8ddabf277a5ccf98db157c62619cde8baea696a74ed18e" ]
  }
}

---

eth_getBlockByNumber

Returns information about a block by block number.

Parameters

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Boolean - If true, returns the full transaction objects; if false, returns only the hashes of the transactions.

Returns

result : OBJECT - Block object , or null when no block is found.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x64", true],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : {
    "number" : "0x64",
    "hash" : "0xdfe2e70d6c116a541101cecbb256d7402d62125f6ddc9b607d49edc989825c64",
    "parentHash" : "0xdb10afd3efa45327eb284c83cc925bd9bd7966aea53067c1eebe0724d124ec1e",
    "nonce" : "0x37129c7f29a9364b",
    "sha3Uncles" : "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "logsBloom" : "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "transactionsRoot" : "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "stateRoot" : "0x90c25f6d7fddeb31a6cc5668a6bba77adbadec705eb7aa5a51265c2d1e3bb7ac",
    "receiptsRoot" : "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "miner" : "0xbb7b8287f3f0a933474a79eae42cbca977791171",
    "difficulty" : "0x42be722b6",
    "totalDifficulty" : "0x19b5afdc486",
    "extraData" : "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
    "size" : "0x21e",
    "gasLimit" : "0x1388",
    "gasUsed" : "0x0",
    "timestamp" : "0x55ba43eb",
    "uncles" : [ ],
    "transactions" : [ ]
  }
}

---

eth_getTransactionByHash

Returns transaction information for the specified transaction hash.

Parameters

DATA - 32-byte transaction hash.

Returns

Object - Transaction object, or null when no transaction is found.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0xa52be92809541220ee0aaaede6047d9a6c5d0cd96a517c854d944ee70a0ebb44"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : {
    "blockHash" : "0x510efccf44a192e6e34bcb439a1947e24b86244280762cbb006858c237093fda",
    "blockNumber" : "0x422",
    "from" : "0xfe3b557e8fb62b89f4916b721be55ceb828dbd73",
    "gas" : "0x5208",
    "gasPrice" : "0x3b9aca00",
    "hash" : "0xa52be92809541220ee0aaaede6047d9a6c5d0cd96a517c854d944ee70a0ebb44",
    "input" : "0x",
    "nonce" : "0x1",
    "to" : "0x627306090abab3a6e1400e9345bc60c78a8bef57",
    "transactionIndex" : "0x0",
    "value" : "0x4e1003b28d9280000",
    "v" : "0xfe7",
    "r" : "0x84caf09aefbd5e539295acc67217563438a4efb224879b6855f56857fa2037d3",
    "s" : "0x5e863be3829812c81439f0ae9d8ecb832b531d651fb234c848d1bf45e62be8b9"
  }
}

---

eth_getTransactionByBlockHashAndIndex

Returns transaction information for the specified block hash and transaction index position.

Parameters

DATA - 32-byte hash of a block.

QUANTITY - Integer representing the transaction index position.

Returns

Object - Transaction object, or null when no transaction is found.

Request

This request returns the third transaction in the 82990 block on the Ropsten testnet. You can also view this block and transaction on Etherscan.

Note: Your node must be synchronized to at least the block containing the transaction for the request to return it.

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0xbf137c3a7a1ebdfac21252765e5d7f40d115c2757e4a4abee929be88c624fdb7", "0x2"], "id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : {
    "blockHash" : "0xbf137c3a7a1ebdfac21252765e5d7f40d115c2757e4a4abee929be88c624fdb7",
    "blockNumber" : "0x1442e",
    "from" : "0x70c9217d814985faef62b124420f8dfbddd96433",
    "gas" : "0x3d090",
    "gasPrice" : "0x57148a6be",
    "hash" : "0xfc766a71c406950d4a4955a340a092626c35083c64c7be907060368a5e6811d6",
    "input" : "0x51a34eb8000000000000000000000000000000000000000000000029b9e659e41b780000",
    "nonce" : "0x2cb2",
    "to" : "0xcfdc98ec7f01dab1b67b36373524ce0208dc3953",
    "transactionIndex" : "0x2",
    "value" : "0x0",
    "v" : "0x2a",
    "r" : "0xa2d2b1021e1428740a7c67af3c05fe3160481889b25b921108ac0ac2c3d5d40a",
    "s" : "0x63186d2aaefe188748bfb4b46fb9493cbc2b53cf36169e8501a5bc0ed941b484"
  }
 }

---

eth_getTransactionByBlockNumberAndIndex

Returns transaction information for the specified block number and transaction index position.

Parameters

QUANTITY|TAG - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

QUANTITY - The transaction index position.

Returns

Object - Transaction object, or null when no transaction is found.

Request

This request returns the third transaction in the 82990 block on the Ropsten testnet. You can also view this block and transaction on Etherscan.

Note: Your node must be synchronized to at least the block containing the transaction for the request to return it.

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["82990", "0x2"], "id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : {
    "blockHash" : "0xbf137c3a7a1ebdfac21252765e5d7f40d115c2757e4a4abee929be88c624fdb7",
    "blockNumber" : "0x1442e",
    "from" : "0x70c9217d814985faef62b124420f8dfbddd96433",
    "gas" : "0x3d090",
    "gasPrice" : "0x57148a6be",
    "hash" : "0xfc766a71c406950d4a4955a340a092626c35083c64c7be907060368a5e6811d6",
    "input" : "0x51a34eb8000000000000000000000000000000000000000000000029b9e659e41b780000",
    "nonce" : "0x2cb2",
    "to" : "0xcfdc98ec7f01dab1b67b36373524ce0208dc3953",
    "transactionIndex" : "0x2",
    "value" : "0x0",
    "v" : "0x2a",
    "r" : "0xa2d2b1021e1428740a7c67af3c05fe3160481889b25b921108ac0ac2c3d5d40a",
    "s" : "0x63186d2aaefe188748bfb4b46fb9493cbc2b53cf36169e8501a5bc0ed941b484"
  }
}

---

eth_getTransactionReceipt

Returns the receipt of a transaction by transaction hash. Receipts for pending transactions are not available.

Parameters

DATA - 32-byte hash of a transaction.

Returns

Object - Transaction receipt object, or null when no receipt is found.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x504ce587a65bdbdb6414a0c6c16d86a04dd79bfcc4f2950eec9634b30ce5370f"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "blockHash": "0xe7212a92cfb9b06addc80dec2a0dfae9ea94fd344efeb157c41e12994fcad60a",
        "blockNumber": "0x50",
        "contractAddress": null,
        "cumulativeGasUsed": "0x5208",
        "from": "0x627306090abab3a6e1400e9345bc60c78a8bef57",
        "gasUsed": "0x5208",
        "logs": [],
        "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
        "status": "0x1",
        "to": "0xf17f52151ebef6c7334fad080c5704d77216b732",
        "transactionHash": "0xc00e97af59c6f88de163306935f7682af1a34c67245e414537d02e422815efc3",
        "transactionIndex": "0x0"
    }
}

---

eth_newFilter

Creates a topic filter with the specified options to notify (log) when the state changes. To determine whether the state has changed, call eth_getFilterChanges.

Parameters

Object - Filter options object.

Note: Topics are order-dependent. A transaction with a log containing topics [A, B] would be matched with the following topic filters:

• [] - Match any topic
• [A] - Match A in first position (and any topic thereafter)
• [null, B] - Match any topic in first position AND B in second position (and any topic thereafter)
• [A, B] - Match A in first position AND B in second position (and any topic thereafter)
• [[A, B], [A, B]] - Match (A OR B) in first position AND (A OR B) in second position (and any topic thereafter)

For example, params could be specified as follows:

params: [{
  "fromBlock": "earliest",
  "toBlock": "0x4",
  "address": "0xc94770007dda54cF92009BFF0dE90c06F603a09f",
  "topics": ["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", null, ["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc"]]
}]

Returns

result : QUANTITY - Filter ID.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":[]}],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x3"
}

Invalid params error:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"fromBlock": "earliest","toBlock": "latest","address": "0xDD37f65dB31c107F773E82a4F85C693058fEf7a9","topics": []}],"id":53}' 127.0.0.1:8545

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "error" : {
    "code" : -32602,
    "message" : "Invalid params"
  }
}

---

eth_newBlockFilter

Creates a filter in the node that notifies when a new block arrives. To determine whether the state has changed, call eth_getFilterChanges.

Parameters

None

Returns

QUANTITY - Hexadecimal integer filter ID. Each time you call this method, it creates a new filter, and the index is incremented by 1.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

Assuming you have previously called eth_newBlockFilter two times, it will assign a filter ID of 3:

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x3"
}

---

eth_newPendingTransactionFilter

Creates a filter in the node that notifies when new pending transactions arrive. To check if the state has changed, call eth_getFilterChanges.

Parameters

None

Returns

QUANTITY - Hexadecimal integer filter ID. Each time you call this method, it creates a new filter, and the index is incremented by 1.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":53}' <JSON-RPC-endpoint:port>

Result

Assuming you have previously called eth_newBlockFilter three times, it will assign a filter ID of 4:

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : "0x4"
}

---

eth_uninstallFilter

Uninstalls a filter with the specified ID. This method should always be called when notification is no longer needed. Note that filters time out when they are not requested with eth_getFilterChanges for a period of time.

This method deletes filters of any type: block filters, pending transaction filters, and state (topic) filters.

Parameters

QUANTITY - Hexadecimal integer filter ID specifying the filter to be deleted.

Returns

Boolean - true if the filter was successfully uninstalled; otherwise false.

Request

The following request deletes the block filter with an ID of 0x4:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0x4"],"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : true
}

---

eth_getFilterChanges

Polls the specified filter and returns an array of logs that have occurred since the last poll.

Parameters

QUANTITY - Hexadecimal integer filter ID.

Returns

result : Array of Object - List of logs, or an empty array if nothing has changed since the last poll.

• For filters created with eth_newBlockFilter, returns 32-byte DATA block hashes; for example ["0x3454645634534..."].

• For filters created with eth_newPendingTransactionFilter, returns transaction hashes (32-byte DATA); for example ["0x6345343454645..."].

• For filters created with eth_newFilter, returns log objects.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0xa"]:"id":53}' <JSON-RPC-endpoint:port>

Result

The following response indicates that nothing has changed since the last poll:

{
  "jsonrpc" : "2.0",
  "id" : 53,
  "result" : [ ]
}

---

eth_getFilterLogs

Returns an array of logs matching the filter with the specified ID.

Parameters

QUANTITY - Integer representing the filter ID.

Returns

Same as eth_getFilterChanges.

Request

The following example requests logs for filter ID 0x16 (22 decimal):

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x3"]"id":53}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : [ {
    "logIndex" : "0x0",
    "removed" : false,
    "blockNumber" : "0x14427",
    "blockHash" : "0x677bf4b962464e6dfd548d6a30b6c703dd78c7cc3602825a7013a6e90a001d2a",
    "transactionHash" : "0x7bf9876a9de3c0add38495e21a17b96c81b3f18e0990a4a3aecdf9f47fea0eed",
    "transactionIndex" : "0x0",
    "address" : "0xe8fe77d1576d0972d453b49bfaa84d716173d133",
    "data" : "0x0000000000000000000000001046c9bdec0e634fbd7cf91afebd93cc854432b10000000000000000000000002101416eeaf73acb66d124f79efde9631662a83a0000000000000000000000006f72045702a34c473da863945221965c61528bd3",
    "topics" : [ "0xc36800ebd6079fdafc3a7100d0d1172815751804a6d1b7eb365b85f6c9c80e61", "0x000000000000000000000000b344324aa2a82a6fda8459e40923e1fd65bfac36" ]
  } ]
}

---

eth_getLogs

Returns an array of all logs matching a specified filter object.

Parameters

Object - Filter options object

Returns

Same as eth_getFilterChanges.

Request

The request above returns the logs for the 82893 block on the Ropsten testnet. You can also view this block on Etherscan.

Note: You must be synchronized to at least the requested block for the request to return the logs.

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"blockhash":"0x677bf4b962464e6dfd548d6a30b6c703dd78c7cc3602825a7013a6e90a001d2a"}], "id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : [ {
    "logIndex" : "0x0",
    "removed" : false,
    "blockNumber" : "0x14427",
    "blockHash" : "0x677bf4b962464e6dfd548d6a30b6c703dd78c7cc3602825a7013a6e90a001d2a",
    "transactionHash" : "0x7bf9876a9de3c0add38495e21a17b96c81b3f18e0990a4a3aecdf9f47fea0eed",
    "transactionIndex" : "0x0",
    "address" : "0xe8fe77d1576d0972d453b49bfaa84d716173d133",
    "data" : "0x0000000000000000000000001046c9bdec0e634fbd7cf91afebd93cc854432b10000000000000000000000002101416eeaf73acb66d124f79efde9631662a83a0000000000000000000000006f72045702a34c473da863945221965c61528bd3",
    "topics" : [ "0xc36800ebd6079fdafc3a7100d0d1172815751804a6d1b7eb365b85f6c9c80e61", "0x000000000000000000000000b344324aa2a82a6fda8459e40923e1fd65bfac36" ]
  } ]
}

---

eth_getWork

Returns the hash of the current block, the seed hash, and the target boundary condition to be met.

Parameters

None

Returns

result : Array of DATA with the following fields:

• DATA, 32 Bytes - Hash of the current block header (pow-hash).
• DATA, 32 Bytes - The seed hash used for the DAG.
• DATA, 32 Bytes - The target boundary condition to be met; 2^256 / difficulty.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getWork","params":[],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "id":1,
  "jsonrpc":"2.0",
  "result": [
      "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
      "0x5EED00000000000000000000000000005EED0000000000000000000000000000",
      "0xd1ff1c01710000000000000000000000d1ff1c01710000000000000000000000"
    ]
}

clique_discard

Discards a proposal to add or remove a signer with the specified address.

Parameters

data - 20-byte address of proposed signer.

Returns

result: boolean - true

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"clique_discard","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73"], "id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : true
}

clique_getSigners

Lists signers for the specified block.

Parameters

quantity|tag - Integer representing a block number or one of the string tags latest, earliest, or pending, as described in Block Parameter.

Returns

result: array of data - List of 20-byte addresses of signers.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSigners","params":["latest"], "id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : [ "0x42eb768f2244c8811c63729a21a3569731535f06", "0x7ffc57839b00206d1ad20c69a1981b489f772031", "0xb279182d99e65703f0076e4812653aab85fca0f0" ]
}

clique_getSignersAtHash

Lists signers for the specified block.

Parameters

data - 32-byte block hash.

Returns

result: array of data - List of 20-byte addresses of signers.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"clique_getSignersAtHash","params":["0x98b2ddb5106b03649d2d337d42154702796438b3c74fd25a5782940e84237a48"], "id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : [ "0x42eb768f2244c8811c63729a21a3569731535f06", "0x7ffc57839b00206d1ad20c69a1981b489f772031", "0xb279182d99e65703f0076e4812653aab85fca0f0" ]
}

clique_propose

Proposes adding or removing a signer with the specified address.

Parameters

data - 20-byte address.

boolean - true to propose adding signer or false to propose removing signer.

Returns

result: boolean - true

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"clique_propose","params":["0xFE3B557E8Fb62b89F4916B721be55cEb828dBd73", true], "id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : true
}

clique_proposals

Returns current proposals.

Parameters

None

Returns

result:object - Map of account addresses to corresponding boolean values indicating the proposal for each account.

If the boolean value is true, the proposal is to add a signer. If false, the proposal is to remove a signer.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"clique_proposals","params":[], "id":1}' <JSON-RPC-endpoint:port>

Result

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "0x42eb768f2244c8811c63729a21a3569731535f07": false,
        "0x12eb759f2222d7711c63729a45c3585731521d01": true
    }
}

---

debug_metrics

Note This method is only available only from v0.8.3.

Returns metrics providing information on the internal operation of Pantheon.

The available metrics may change over time. The JVM metrics may vary based on the JVM implementation being used.

The metric types are:

• Timer
• Counter
• Gauge

Parameters

None

Returns

result:object

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"debug_metrics","params":[],"id":1}' <JSON-RPC-endpoint:port>

Result

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "jvm": {
            "memory_bytes_init": {
                "heap": 268435456,
                "nonheap": 2555904
            },
            "threads_current": 41,
            "memory_bytes_used": {
                "heap": 696923976,
                "nonheap": 63633456
            },
            "memory_pool_bytes_used": {
                "PS Eden Space": 669119360,
                "Code Cache": 19689024,
                "Compressed Class Space": 4871144,
                "PS Survivor Space": 2716320,
                "PS Old Gen": 25088296,
                "Metaspace": 39073288
            },
            ...
        },
        "process": {
            "open_fds": 546,
            "cpu_seconds_total": 67.148992,
            "start_time_seconds": 1543897699.589,
            "max_fds": 10240
        },
        "rpc": {
            "request_time": {
                "debug_metrics": {
                    "bucket": {
                        "+Inf": 2,
                        "0.01": 1,
                        "0.075": 2,
                        "0.75": 2,
                        "0.005": 1,
                        "0.025": 2,
                        "0.1": 2,
                        "1.0": 2,
                        "0.05": 2,
                        "10.0": 2,
                        "0.25": 2,
                        "0.5": 2,
                        "5.0": 2,
                        "2.5": 2,
                        "7.5": 2
                    },
                    "count": 2,
                    "sum": 0.015925392
                }
            }
        },
        "blockchain": {
            "difficulty_total": 3533501,
            "announcedBlock_ingest": {
                "bucket": {
                    "+Inf": 0,
                    "0.01": 0,
                    "0.075": 0,
                    "0.75": 0,
                    "0.005": 0,
                    "0.025": 0,
                    "0.1": 0,
                    "1.0": 0,
                    "0.05": 0,
                    "10.0": 0,
                    "0.25": 0,
                    "0.5": 0,
                    "5.0": 0,
                    "2.5": 0,
                    "7.5": 0
                },
                "count": 0,
                "sum": 0
            },
            "height": 1908793
        },
        "peers": {
            "disconnected_total": {
                "remote": {
                    "SUBPROTOCOL_TRIGGERED": 5
                },
                "local": {
                    "TCP_SUBSYSTEM_ERROR": 1,
                    "SUBPROTOCOL_TRIGGERED": 2,
                    "USELESS_PEER": 3
                }
            },
            "peer_count_current": 2,
            "connected_total": 10
        }
    }
}

---

debug_traceTransaction

Remix uses debug_traceTransaction to implement debugging. Use the Debugger tab in Remix rather than calling debug_traceTransaction directly.

Reruns the transaction with the same state as when the transaction was executed.

Parameters

transactionHash : data - Transaction hash.

Object - request options (all optional and default to false):

• disableStorage : boolean - true disables storage capture.
• disableMemory : boolean - true disables memory capture.
• disableStack : boolean - true disables stack capture.

Returns

result:object - Trace object.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"debug_traceTransaction","params":["0x2cc6c94c21685b7e0f8ddabf277a5ccf98db157c62619cde8baea696a74ed18e",{"disableStorage":true}],"id":1}' <JSON-RPC-endpoint:port>

Result

{
  "jsonrpc" : "2.0",
  "id" : 1,
  "result" : {
    "gas" : 21000,
    "failed" : false,
    "returnValue" : "",
    "structLogs" : [ {
      "pc" : 0,
      "op" : "STOP",
      "gas" : 0,
      "gasCost" : 0,
      "depth" : 1,
      "stack" : [ ],
      "memory" : [ ],
      "storage" : null
    } ]
  }
}

---

miner_start

Starts the CPU mining process. To start mining, a miner coinbase must have been previously specified using the --miner-coinbase command line option.

Parameters

None

Returns

result : boolean - true if the mining start request was received successfully; otherwise returns an error.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"miner_start","params":[],"id":1}' <JSON-RPC-endpoint:port>

Result

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": true
}

---

miner_stop

Stops the CPU mining process on the client.

Parameters

None

Returns

result : boolean - true if the mining stop request was received successfully; otherwise returns an error.

Request

curl -X POST --data '{"jsonrpc":"2.0","method":"miner_stop","params":[],"id":1}' <JSON-RPC-endpoint:port>

Result

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": true
}

JSON-RPC API Objects

Objects

The following objects are parameters for or returned by JSON-RPC Methods:

• Block
• Filter Options
• Log
• Transaction
• Transaction Call
• Transaction Receipt

Block Object

Returned by eth_getBlockByHash and eth_getBlockByNumber.

Key	Type	Value
number	Quantity, Integer	Block number. null when block is pending.
hash	Data, 32 bytes	Hash of the block. null when block is pending.
parentHash	Data, 32 bytes	Hash of the parent block.
nonce	Data, 8 bytes	Hash of the generated proof of work. null when block is pending.
sha3Uncles	Data, 32 bytes	SHA3 of the uncle's data in the block.
logsBloom	Data, 256 bytes	Bloom filter for the block logs. null when block is pending.
transactionsRoot	Data, 32 bytes	Root of the transaction trie for the block.
stateRoot	Data, 32 bytes	Root of the final state trie for the block.
receiptsRoot	Data, 32 bytes	Root of the receipts trie for the block.
miner	Data, 20 bytes	Address to which mining rewards were paid.
difficulty	Quantity, Integer	Difficulty for this block.
totalDifficulty	Quantity, Integer	Total difficulty of the chain until this block.
extraData	Data	Extra data field of this block.
size	Quantity, Integer	Size of block in bytes.
gasLimit	Quantity	Maximum gas allowed in this block.
gasUsed	Quantity	Total gas used by all transactions in this block.
timestamp	Quantity	Unix timestamp when block was collated.
transactions	Array	Array of transaction objects, or 32 byte transaction hashes depending on the specified boolean parameter.
uncles	Array	Array of uncle hashes.

Filter Options Object

Parameter for eth_newFilter and eth_getLogs.

Key	Type	Required/Optional	Value
fromBlock	Quantity |Tag	Optional	Integer block number or latest, pending, earliest. See Block Parameter. Default is latest.
toBlock	Quantity |Tag	Optional	Integer block number or latest, pending, earliest. See Block Parameter. Default is latest.
address	Data | Array	Optional	Contract address or array of addresses from which logs originate.
topics	Array of Data, 32 bytes each	Optional	Array of 32-byte topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.

eth_getLogs has an additional key.

Key	Type	Required/Optional	Value
blockhash	Data, 32 bytes	Optional	Hash of block for which to return logs. If blockhash is specified, fromBlock and toBlock cannot be specified.

Log Object

Returned by eth_getFilterChanges and transaction receipt objects can contain an array of log objects.

Key	Type	Value
removed	Tag	true when log removed due to chain reorganization. false if valid log.
logIndex	Quantity, Integer	Log index position in the block. null when log is pending.
transactionIndex	Quantity, Integer	Index position of transaction from which log was created. null when log is pending.
transactionHash	Data, 32 bytes	Hash of transaction from which log was created. null when log is pending.
blockHash	Data, 32 bytes	Hash of block in which log included. null when log is pending.
blockNumber	Quantity	Number of block in which log included. null when log is pending.
address	Data, 20 bytes	Address from which log originated.
data	Data	Non-indexed arguments of log.
topics	Array of Data, 32 bytes each	0 to 4 indexed log arguments. In Solidity, the first topic is the hash of the signature of the event (for example, Deposit(address, bytes32, unit256)) except you declare the event with an anonymous specifier.)

Trace Object

Returned by debug_traceTransaction.

Key	Type	Value
gas	Integer	Gas used by the transaction
failed	Boolean	True if transaction failed; otherwise, false
returnValue	String	Bytes returned from transaction execution (without a 0x prefix)
structLogs	Array	Array of structured log objects

Structured Log Object

Log information returned as part of the Trace object.

Key	Type	Value
pc	Integer	Current program counter
op	String	Current OpCode
gas	Integer	Gas remaining
gasCost	Integer	Cost in wei of each gas unit
depth	Integer	Execution depth
exceptionalHaltReasons	Array	One or more strings representing an error condition that caused the EVM execution to terminate. These indicate that EVM execution terminated for reasons such as running out of gas or attempting to execute an unknown instruction. Generally a single exceptional halt reason is returned but it is possible for more than one to occur at once.
stack	Array of 32 byte arrays	EVM execution stack before executing current operation
memory	Array of 32 byte arrays	Memory space of the contract before executing current operation
storage	Object	Storage entries changed by the current transaction

Transaction Object

Returned by eth_getTransactionByHash, eth_getTransactionByBlockHashAndIndex, and eth_getTransactionsByBlockNumberAndIndex.

Key	Type	Value
blockHash	Data, 32 bytes	Hash of block containing this transaction. null when transaction is pending.
blockNumber	Quantity	Block number of block containing this transaction. null when transaction is pending.
from	Data, 20 bytes	Address of the sender.
gas	Quantity	Gas provided by the sender.
gasPrice	Quantity	Gas price provided by the sender in Wei.
hash	Data, 32 bytes	Hash of the transaction.
input	Data	Data sent with the transaction.
nonce	Quantity	Number of transactions made by the sender before this one.
to	Data, 20 bytes	Address of the receiver. null if a contract creation transaction.
transactionIndex	Quantity, Integer	Index position of transaction in the block. null when transaction is pending.
value	Quantity	Value transferred in Wei.
v	Quantity	ECDSA Recovery ID
r	Data, 32 bytes	ECDSA signature r
s	Data, 32 bytes	ECDSA signature s

Transaction Call Object

Parameter for eth_call and eth_estimateGas.

Note: All parameters are optional for eth_estimateGas

Key	Type	Required/Optional	Value
from	Data, 20 bytes	Optional	Address from which transaction sent.
to	Data, 20 bytes	Required	Address to which transaction is directed.
gas	Quantity, Integer	Optional	Gas provided for the transaction execution. eth_call consumes zero gas, but this parameter may be needed by some executions.
gasPrice	Quantity, Integer	Optional	gasPrice used for each paid gas.
value	Quantity, Integer	Optional	Value sent with this transaction.
data	Data	Optional	Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI.

Transaction Receipt Object

Returned by eth_getTransactionReceipt.

Key	Type	Value
blockHash	Data, 32 bytes	Hash of block containing this transaction.
blockNumber	Quantity	Block number of block containing this transaction.
contractAddress	Data, 20 bytes	Contract address created, if contract creation transaction; otherwise, null.
cumulativeGasUsed	Quantity	Total amount of gas used by previous transactions in the block and this transaction.
from	Data, 20 bytes	Address of the sender.
gasUsed	Quantity	Amount of gas used by this specific transaction.
logs	Array	Array of log objects generated by this transaction.
logsBloom	Data, 256 bytes	Bloom filter for light clients to quickly retrieve related logs.
status	Quantity	Either 1 (success) or 0 (failure)
to	Data, 20 bytes	Address of the receiver, if sending ether; otherwise, null.
transactionHash	Data, 32 bytes	Hash of the transaction.
transactionIndex	Quantity, Integer	Index position of transaction in the block.

Note: For pre-Byzantium transactions, the transaction receipt object includes the following instead of status:

Key	Type	Value
root	Data, 32 bytes	Post-transaction stateroot