Homestead_18 – Accessing Contracts and Transactions

Accessing Contracts and Transactions

RPC

In previous sections we have seen how contracts can be written, deployed and interacted with. Now it’s time to dive in the details of communicating with the Ethereum network and smart contracts.

An Ethereum node offers a RPC interface. This interface gives Ðapp’s access to the Ethereum blockchain and functionality that the node provides, such as compiling smart contract code. It uses a subset of the JSON-RPC 2.0 specification (no support for notifications or named parameters) as serialisation protocol and is available over HTTP and IPC (unix domain sockets on linux/OSX and named pipe’s on Windows).

If you are not interested in the details but are looking for an easy to use javascript library you can skip the following sections and continue with Using Web3.

Conventions

The RPC interface uses a couple of conventions that are not part of the JSON-RPC 2.0 specification:

Numbers are hex encoded. This decision was made because some languages have no or limited support for working with extremly large numbers. To prevent these type of errors numbers are hex encoded and it is up to the deverloper to parse these numbers and handle them appropriately. See the hex encoding section on the wiki for examples.

Default block number, several RPC methods accept a block number. In some cases it’s not possible to give a block number or not very convenient. For these cases the default block number can be one of these strings [“earliest”, “latest”, “pending”]. See the wiki page for a list of RPC methods that use the default block parameters.

Deploy contract

We will go through the different steps to deploy the following contract using only the RPC interface.

The first thing to do is make sure the HTTP RPC interface is enabled. This means for geth we supply the --rpc flag on startup and for eth the -j flag. In this example we use the geth node on a private development chain. Using this approach we don’t need ether on the real network.

geth supports CORS, see the --rpccorsdomain flag for more information.

We can verify that the interface is running by retrieving the coinbase address and balance using curl. Please note that data in these examples will differ on your local node. If you want to try these command replace the request params accordingly.

Remember when we said that numbers are hex encoded? In this case the balance is returned in wei as a hex string. If we want to have the balance in ether as a number we can use web3 from the geth console.

> web3.fromWei("0x1639e49bba16280000", "ether")
"410"

Now that we have some ether on our private development chain we can deploy the contract. The first step is to verify that the solidity compiler is available. We can retrieve available compilers using the eth_getCompilers RPC method.

The transaction is accepted by the node and a transaction hash is returned. We can use this hash to track the transaction.

The next step is to determine the address where our contract is deployed. Each executed transaction will create a receipt. This receipt contains various information about the transaction such as in which block the transaction was included and how much gas was used by the EVM. If a transaction creates a contract it will also contain the contract address. We can retrieve the receipt with the eth_getTransactionReceipt RPC method.

We can see that our contract was created on 0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d. If you got null instead of a receipt the transaction has not been included in a block yet. Wait for a moment and check if your miner is running and retry it.

Interacting with smart contracts

Now that our contract is deployed we can interact with it. There are 2 methods for this, sending a transaction or using call as previously explained. In this example we will be sending a transaction to the multiply method of the contract.

If we look at the documentation for the eth_sendTransaction we can see that we need to supply several arguments. In our case we need to specify the from, to and data arguments. From is the public address of our account and to the contract address. The data argument is a bit harder. It contains a payload that defines which method must be called and with which arguments. This is were the ABI comes into play. The ABI defines how to define and encode data for the EVM. You can readall the details about the ABI here.

The bytes of the payload is the function selector and defines which method is called. This is done by taking the first 4 bytes from the Keccak hash over the function name and its argument types and hex encode it. The multiply function accepts an uint which is an alias for uint256. This leaves us with:

The next step is to encode the arguments. We only have one uint256, lets assume we supply the value 6. The ABI has a section which specifies how to encode uint256 types.

int<M>: enc(X) is the big-endian two’s complement encoding of X, padded on the higher-oder (left) side with 0xff for negative X and with zero bytes for positive X such that the length is a multiple of 32 bytes.

This encodes to 0000000000000000000000000000000000000000000000000000000000000006.

Combining the function selector and the encoded argument our data will be 0xc6888fa10000000000000000000000000000000000000000000000000000000000000006.

The receipt contains a log. This log was generated by the EVM on transaction execution and included in the receipt. If we look at the multipy function we can see that the Print event was raised with the input times 7. Since the argument for the Print event was a uint256 we can decode it according to the ABI rules which will leave us with the expected decimal 42. Apart from the data it is worth noting that topics can be used to determine which event created the log:

This was just a brief introduction into some of the most common tasks. See for a full list of available RPC methods the RPC wiki page.

Web3.js

As we have seen in the previous example using the JSON-RPC interface can be quite tedious and error-prone, especially when we have to deal with the ABI. Web3.js is a javascript library that works on top of the Ethereum RPC interface. Its goal is to provide a more user friendly interface and reducing the chance for errors.

Console

The geth console offers a command line interface with a javascript runtime. It can connect to a local or remote geth or eth node. It will load the web3.js library that users can use. This allows users to deploy and interact with smart contract from the console using web3.js. In fact the examples in the Web3.js section can by copied into the console.

Viewing Contracts and Transactions

There are several online blockchain explorers available that will allow you to inspect the Ethereum blockchain. See for a list: Blockchain explorers.