Mar 26, 2018 - James Watts

Ethereum, Part III: Transactional and View Contract Methods

Open Primary Tabs Configuration Options

The first two parts (here and here) in this series examined the basic setup and interactions of an Ethereum contract on the blockchain. The contract creation and owner transfer (give) method calls used so far have been submitted as new transactions to an Ethereum client, which are picked up by miners and incorporated into new blocks in the blockchain. This transactional interaction is required whenever state of the blockchain is modified (by creating contracts or changing their state); however contracts may also expose methods that may be called immediately without a transaction being mined.

Pure and View Methods

The simple example contract introduced in the first post included the following method:

function mine() public view returns (bool) {

return(msg.sender == owner);


This method is a simple check to see if the calling address currently owns this contract. This method is notable because it is declared as a view method, which means that it may not update any contract state. (Methods may also be declared as pure, meaning they cannot alter or read current state). These view and pure methods may be called on existing contract instance without issuing any new transactions, and may also be called on any state of the contract at a particular block. Note that any contract state variable declared as public has a corresponding getter function defined as a view function.

Calling View Methods

The data required for calling view methods and any necessary parameters are encoded in the same way as other method parameters (as covered in the earlier post). However, once the method signature and data packet have been assembled, the method is called in a slightly different way:

>{"from": "0x02B831775e3D48b2bc107c8431d15Aa4E0F8FD41", "to": "0x78561813fb0cfad61da69c3ca0ba6938637ca993", "data": "0x99f4b251"}, "latest");


In this example, the contract from the earlier posts is used, and the mine method is called using the address of the user we transferred the contract to earlier. The method returns a boolean type; in this case a true value (encoded as a 32 bit integer) is returned, since this user address currently owns this contract.

Notice that the call RPC method is used  here instead of the normal sendTransaction method. The call method takes the same parameters as the sendTransaction, but does not affect the blockchain. It can also take an optional second argument for the block to examine.

View Methods On Earlier States

View and pure methods can be called against any state of the blockchain and will return a result calculated on the state of the specified block. By default, the call method uses the latest block on the chain, but earlier blocks can also be specified:

>{"from": "0x498F0c603Cf19Cb5bEf5461D7D9CF0acAA2f65B0", "to": "0x78561813fb0cfad61da69c3ca0ba6938637ca993", "data": "0x99f4b251"}, "latest");


>{"from": "0x498F0c603Cf19Cb5bEf5461D7D9CF0acAA2f65B0", "to": "0x78561813fb0cfad61da69c3ca0ba6938637ca993", "data": "0x99f4b251"}, 91);


Here the mine method returns different results when called for the latest block (where the contract has been transferred to another user), and a previous block before the transfer transaction was completed. In this way, the historical state of contracts can be examined at any point on the blockchain.

Blocks can be specified by their number in the chain, or by special string identifiers—earliest, latest, and pending. The call method will use the latest block by default.

Determining Method Type

Before calling methods on a contract, the client should understand the type of function being called and whether that function requires a transaction. Luckily, the Ethereum compiler generates a JSON ABI definition for each contract, which includes information about each method. This information includes the method stateMutability, which indicates the type of the method, and whether a transaction is required.

Contract Events

While view and pure methods can be used to examine the state of the contract throughout its history, doing so to find previous events on the contracts by iterating the blockchain isn't efficient. The next post in this series covers the use of contract events for this purpose.