### 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](https://github.com/Amit0617/ethRPCtoREST/commit/b810f45d59ec50616e10d512fb1178b9e5f44f51)
Allowing to get storage using `eth_getStorageAt`.

Doing some cleaning up and redoing [some design decisions](https://github.com/Amit0617/ethRPCtoREST/commit/625b1e02a2b59096aa5edb5005faaea5caf44567).

### 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](https://github.com/Amit0617/ethRPCtoREST/commit/31d6f6a1fbdbbc363a2fc1c264abc631b46456cc)

Supports `eth_getBlockTransactionCountByHash` and `eth_getBlockTransactionCountByNumber`

##### [/eth/blockNumber](https://github.com/Amit0617/ethRPCtoREST/commit/1958475e9aea82de2ee7a45d750263d2313baad9)

Returns latest block number through `eth_getBlockNumber`

##### [/eth/balance/:address/:identifier](https://github.com/Amit0617/ethRPCtoREST/commit/5ea9d2d80e62f395cf48a85fe3227fbe8db5d549)

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

##### [/eth/txcount/:address/:identifier](https://github.com/Amit0617/ethRPCtoREST/commit/6967fb5d17b046e207128574c70ebbdcceaaa25f)

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](https://github.com/Amit0617/ethRPCtoREST/commit/97bd03842108eb8f6e9f14167d4a8f506f7d5ca9)

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](https://github.com/cosmtrek/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](https://github.com/Amit0617/ethRPCtoREST/commit/d7daa267b0d2a00090eef616d49ea02e6e3de7d0)
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](https://github.com/Amit0617/ethRPCtoREST/commit/8cb1e88b593d6639ab693382ec549982f58e24d7) like "earliest", "safe" etc. parameters
#### [eth_getTransactionReceiptByHash](https://github.com/Amit0617/ethRPCtoREST/commit/1dcd92fdfefb7e6481fb1d0b596bc136244f1560)
#### [eth_getUncleByBlock*](https://github.com/Amit0617/ethRPCtoREST/commit/5db25b2bf904ffaad3a8bfddd69fcfd0fd117a44)

#### Few Demo screenshots


### Week 8 - Finally Developing APIs!

Looking at few examples like [web3go](https://github.com/MariusVanDerWijden/web3go) and [description](https://pkg.go.dev/github.com/ethereum/go-ethereum/ethclient) 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](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbyhash) 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*](https://github.com/Amit0617/ethRPCtoREST/commit/9bc02f13ae949d943ae36296e6a332b2cd52d75d)
#### [eth_getTransactionByHash](https://github.com/Amit0617/ethRPCtoREST/commit/8542d99403c01a78cb1436e9dce61a9bbec37820)
#### [eth_getTransactionByBlock*](https://github.com/Amit0617/ethRPCtoREST/commit/6684625853fc3dcfc7dd2c180eea904c027f7bac)

### 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.

| NodeJS Universe | Golang Universe |
| -------- | -------- |
| `npm init` | `go mod init <module name>` |
| `npm install` | `go mod tidy` |
| `node server.js` | `go run main.go` |
| `package.json` & `package-lock.json` | `go.mod` & `go.sum` |

### Week 5 - Finalising project proposal

Finalised [Project proposal](https://github.com/eth-protocol-fellows/cohort-four/blob/master/projects/REST-wrapper.md) which got merged. Wrote a [blog post](https://amit0617.hashnode.dev/web2-to-web3-in-one-shot) 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](https://drive.google.com/file/d/1RoFP3nbU8xhzfa7nP6B5SioDfrzaMao-/view?usp=sharing) 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}](https://github.com/Amit0617/ethRPCtoREST/commit/9bb683bbb317ff633f6417076bae093fecd7c435):
`eth_getUncleByBlockHashAndIndex` and `eth_getUncleByBlockNumberAndIndex` are wrapped by above api.

##### [/eth/transaction/receipt/{hash}](https://github.com/Amit0617/ethRPCtoREST/commit/d16e09d56a557ea4bb1f0e443d3f6d1129c4afc7):
This one binds to `eth_getTransactionReceipt`

##### [/eth/unclecount/block/{identifier}](https://github.com/Amit0617/ethRPCtoREST/commit/d16e09d56a557ea4bb1f0e443d3f6d1129c4afc7):
`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](https://inevitableeth.com/en/home/background), learning about EIPs and having a read on [JSON RPCs](https://ethereum.org/en/developers/docs/apis/json-rpc) 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](https://github.com/eth-protocol-fellows/cohort-four/blob/master/projects/project-ideas.md#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}:](https://github.com/Amit0617/ethRPCtoREST/commit/65e650a0a695164c9445224289317ccf168d10ed)

And `eth_getTransactionByHash` by
##### [/eth/transaction/{hash}:](https://github.com/Amit0617/ethRPCtoREST/commit/65e650a0a695164c9445224289317ccf168d10ed)

There was lot of other stuff going behind the scenes like getting something like [swagger editor](https://github.com/swagger-api/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.