You are on page 1of 2

Ethereum Block & Transaction Info via Aggregated Views

(API by Block 16)


medium.com/block-16/ethereum-block-transaction-info-via-aggregated-views-api-by-block-16-aa9b175da929

June 19, 2018

When working with web applications that interface with Ethereum nodes, I’ve always found
that I need more information than is provided by singular JSON-RPC calls. For instance, you
can get the information about the block —but then have to run another call to get information
about a transaction — and yet another call for the transaction receipt. If you are gathering and
organizing this information at scale, it oftentimes requires over 500 HTTP requests and can
take a lot of time (not to mention a burden on Infura). At Block 16 we have created internal
APIs to present this information quickly along with different “views” or organizations of
blockchain information. Today we are making some of these public.

Get All Block Information by Number. Get all block information, uncles, transactions and
receipts by block number. The datastructure is much like what’s returned from normal
eth_getBlockByNumber RPC but includes a list of uncles, transactions, and receipts achieved
from eth_getUncleByBlockNumberAndIndex, eth_getTransactionByHash and
eth_getTransactionReceipt calls respectively. More information can be found here, by invoking
the following command in terminal or clicking the link within the command:

curl -X GET https://api.block16.io/v1/block/5000000 \


-H 'Accept: application/json'

Get All Current Block Information. Get all block information, uncles, transactions and
receipts for the current block. Internally we track all transactions on the network and perform
various operations — so we tend to run about 1–10 seconds behind the current block.

curl -X GET https://api.block16.io/v1/block/current \


-H 'Accept: application/json'

Subscribe to Current Block via Websocket. Same as the endpoint described above but the
websocket pushes the current block information upon connection and receives updates as
blocks are processed. A sample application can be viewed here with source code available
here.

Get Last 100 TXs by Address. We have an interesting data format for this endpoint that is
informed by availability and database space:

1/2
{
"address": "0000000000000000000000000000000000000008",
"transactionDate": 1528012206000,
"value": "1000000000000000000",
"toAddress": "0000000000000000000000000000000000000008",
"fromAddress": "dfa5d32e82ce9d131ca77f5e260c3d0d68deb61b",
"ethereumContract": "3543638ed4a9006e4840b105944271bcea15605d",
"transactionHash":
"945ab5e688660478b0bb813cc6c2f4c8a17bb1d8bed810634ec203a26e7a74d8",
"blockNumber": 5724039,
"transactionType": "token_transaction",
"fee": "16440820000000000"
}

Notice that all hex prefixes are removed and that there is a “toAddress”, “fromAddress” and an
“address” field. Incoming transactions are found by matching “address” with the “toAddress”
and outgoing by matching “address” with “fromAddress”. The “value” property is the base 10
raw value of the transaction in wei if it was not a token transaction. If it was a token
transaction, the “value” property is the raw token amount without decimals. The “fee” is in base
10 wei. For more information about the structure of the data visit the documentation. Curl
invocation:

curl -X GET
https://api.block16.io/v1/address/0x0000000000000000000000000000000000000001/transactio
ns -H 'Accept: application/json'

Get All Token Contracts Associated with an Address. This endpoint lists all token contract
addresses that an Ethereum address has ever been associated with. As with the previous
endpoint, the “0x” hexadecimal prefix is removed in order to save space in the database.

curl -X GET
https://api.block16.io/v1/address/0x0000000000000000000000000000000000000001/assets -H
'Accept: application/json'

The formal slate documentation can be found at https://docs.block16.io/ . All of the endpoints
have crossorigin headers included so you’ll be able to use them in a webapp, though there is a
30 request per minute limit implemented per IP. If these endpoints become popular we’ll
consider increasing the request per minute limit and scaling/sharding our public databases.

Our goal is to help the ecosystem create more responsive and informative webapps. Any
feedback is greatly appreciated!

2/2

You might also like