Week 17 - Finally implementing them

I did some mistakes in documenting the process mainly in counting zeros and setting length of key and position which result in inconsitency in implementation results and documented results. Finally spotted them and applied the changes in week 14.

/eth/storage/:address/:position/:identifier

Allowing to get storage using eth_getStorageAt.

Doing some cleaning up and redoing some design decisions.

Week 14 - APIs that need the simplification most

eth_getStorageAt

Accessing values of map of contracts isn't very straight forward, for example let's say there is a map of address to balance in a contract

mapping(address => uint256) balances

then to access that value, one needs to put slot number to retrieve it from storage. There are 3 params consumed by it. Out of them 2 are required i.e., contractAddress (whose stored value here balance we want to access) and then position of variable. Let's say there is only the balances map in the contract so it would be at position 0. But if you just try to think for a moment then all of the map can't be stored at single position. So position of the particular value for a given key(here any wallet address) can be accessed by a specially crafted hash through series of steps given below:

Let's say I want to read balance of address 0x00000000000000000000000000000000deadBeef stored in the contract through that balances map.
Step 1: Left pad the address to make it of 32 bytes.
00000000000000000000000000000000000000000000000000000000deadBeef
Step 2: Left pad the position of map you want to access here it is 0.
0000000000000000000000000000000000000000000000000000000000000000
Step 3: Concatenate them.
00000000000000000000000000000000000000000000000000000000deadBeef0000000000000000000000000000000000000000000000000000000000000000
Step 4: Keccak hash of this hex encoded value.

> web3.sha3("00000000000000000000000000000000000000000000000000000000deadBeef0000000000000000000000000000000000000000000000000000000000000000", {"encoding": "hex"})

"0x49361c85d50c86f43fdb7ff3f85f3cac00c47bda054279b6563a02b9b214ccf4"

Now this value is passed to eth_getStorageAt in the place of position to retrieve the value i.e., balance of the address.

In the current situation, user is required to do all of this before calling the rpc. Now, ethRPCtoREST will do the heavy lifting for user allowing them to put required values and get appropriate response automatically.

/eth/storage/:address/:position?map=${key} will internally compute that hash by consuming position and key. Then it will proceed to call rpc with parameters plugged appropriately.

Week 12 - Extending to more APIs

/eth/block/txcount/:identifier

Supports eth_getBlockTransactionCountByHash and eth_getBlockTransactionCountByNumber

/eth/blockNumber

Returns latest block number through eth_getBlockNumber

/eth/balance/:address/:identifier

Allows getting the balance of given address at given block or in the latest block by default.

/eth/txcount/:address/:identifier

Using eth_getTransactionCount, this allows retreiving number of transactions sent from address.

I introduced a new feature - ENS name is also supported for address fields i.e., GET /eth/balance/vitalik.eth will give back balance of the resolved address at latest block through eth_getBalance.

/eth/code/:address/:identifier

Wrapper around eth_getCode method.

Week 11 - Bitcoin is THE Blockchain

Till now whole emphasis was on simplification of requests. Now it's time for response simplification.
Following are the results:

Before	After

Did you read extraData? By coincidence, I found an interesting block.

I also did some re-arrangement and making dev setup more easy by incorporating AIR.

I realized when I would build binary from main.go It would also consist of RPC_URL provided by me through environment variable!

If someone wants to use their personal RPC_URL they will have to build the binary themselves. This didn't sound modular enough. Now it would consume it through command-line argument.

This week I would release first ever version of the binary. 0.0.1

Week 10 - Easing the API interactions

Allowing use of decimal numbers wherever BlockNumber or index are used instead of hexadecimal numbers. commit
This basically allows request methods like

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", false]}'

are now simplified to

GET /eth/block/0x1b4

or

GET /eth/block/436

Proposing more simplification ideas to our mentor like one example of eth_call for interacting with contracts
Original form

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{ 
"from": "0x<sender's hash>", 
"to": "0x<contract hash>",
"value": "0x1234",
"gas": "0x55555",
"data": "0x<first 4 bytes of Keccak hash of ASCII function signature>+<parameters in hex each padded with prefix zeros to 32 bytes>"
}],"id":1}'

can be simplified to

GET /eth/call/from="0x<sender's hash>"&to="0x<contract hash>"&data="foo(uint32 69, bool true)"

Week 9 - Detailing and adding more methods

Added support for default block parameters like "earliest", "safe" etc. parameters

eth_getTransactionReceiptByHash

eth_getUncleByBlock*

Few Demo screenshots

Week 8 - Finally Developing APIs!

Looking at few examples like web3go and description of ethclient methods. To create API, I started with eth_getBlockBy* methods which don't return full transaction with false parameter as mentioned in the specs but the twist is it doesn't returns all transactions even when true is passed into it. Yay! New easter egg unlocked! Really? I also looked at ethClient package and it mentions that you would need to send request two times if you want to get all transactions and uncles.
Currently I moved forward with what is JSON RPC doing. Simply shuttling the responses as it is by making use of HeaderBy{Hash/Number}.
Following methods got covered till now, corresponding commits are linked into them:

eth_getBlockBy*

eth_getTransactionByHash

eth_getTransactionByBlock*

Week 6 - Creating a parallel universe in my brain

Learning Fiber and Golang at the same time 🫣
https://dev.to/fenny/getting-started-with-fiber-36b6
"Learn GO" course from https://boot.dev

Mapping golang commands to analogous nodeJS commands in my mind.

Week 5 - Finalising project proposal

Finalised Project proposal which got merged. Wrote a blog post to quantify the impact of the project and increasing awareness for the purpose of it.

Week 4 - Project presentation and Drafting proposal

Creating a presentation which was presented during office hours.

Week 3 - Half of the RPC methods got spec'd out successfully on OPENAPI

/eth/uncle/block/{identifier}/{index}:

eth_getUncleByBlockHashAndIndex and eth_getUncleByBlockNumberAndIndex are wrapped by above api.

/eth/transaction/receipt/{hash}:

This one binds to eth_getTransactionReceipt

/eth/unclecount/block/{identifier}:

eth_getUncleCountByBlockHash and eth_getUncleCountByBlockNumber got covered by it.

Also proposed implementation of them which makes interacting with execution-apis more user friendly by using a boolean flag like ?useInt for using integers in place of hashes for parameters like Index.
For example, currently if one wants to call eth_getTransactionByBlockHashAndIndex then according to current specifications, request would look like following:

GET /eth/transaction/block/{32-bytes BlockHash}/0x41

Notice number mentioned at the place of Index in above request isn't simply 41 but it's in hexadecimal and is actually 65 of decimal.

So, I wanted to provide a simple layer of easeness included in wrapper which will allow to call above mentioned call as

Simplified form

GET /eth/transaction/block/{identifier}/65?useInt
or
GET /eth/transaction/block/{identifier}/65?useInt=true

Week 2 - Finding purpose of life (or proposal for EPF)

So, after reading stories (history) on inevitable ethereum, learning about EIPs and having a read on JSON RPCs when I was going through cohort-four repository again to see - What other things are there? At the end, the purpose is to explore and research well before diving into a specialised area. This was probably 4th or 5th time when I was re-reading project ideas already proposed and this time I felt ideas were looking a lot familiar and clear than my last visit.
And then I stumbled upon JSON RPC improvement ideas, for some reason this time Rest Wrapper made lot of sense for me. It was very clear that, given the fact - I had visited JSON RPCs recently I was able to draw a clear picture of requirements and responsibilities under the idea.
I expressed my interest to intended mentor and got started same day for REST API on OPENAPI yaml specifications.

I made first ever implementation with one API for each method like for eth_getBlockByHash which takes two parameters one Hash and another boolean value for whether to includeTransaction or not.

So, I proposed API like following:

GET /eth_getBlockByHash/{32-Bytes Hash}?includeTxn={boolean}

Then our mentor suggested to rather implement a more generalised API. For example, eth_getBlockByHash and eth_getBlockByNumber can be merged into:

GET /eth/block/hash/{HashOrNumber}

Also speced out eth_getTransactionByBlockHashAndIndex and eth_getTransactionByBlockNumberAndIndex under

/eth/transaction/block/{identifier}/{index}:

And eth_getTransactionByHash by

/eth/transaction/{hash}:

There was lot of other stuff going behind the scenes like getting something like swagger editor which can allow working offline or locally and can give visual docs for the APIs. Downloading literally every random binary from aur and pacman which mentions OPENAPI in its description because of the inconsistency of schema around versions or absence of a standard.

Week 1 - Dora the Explorer

I had heard lot about ethereum whitepaper but haven't ever read it ever just because I always felt that those things are for researchers or academics purposes and are of no use for builders.
After reading I feel I was quite right. Certainly there was a good refresher of UTXO which I had last studied when learning about zk applications and trying to understand how Tornado protocol works.
However, Ethereum whitepaper is one of those resources which will give a broad and deep enough understanding of ethereum and its most intuitive applications which can be helpful from day one and are much better solution compared to current options, without getting into buzzwords in a single read.