# EPF5 Week3 Update

This week, I tried to solve the issue of missing `enode` and `enr` information in the `admin_peers` RPC response for reth, ref https://github.com/paradigmxyz/reth/pull/9043.

I received an alert this week on my locally running geth node that had fewer peers (<5). After logging into the server, I found that the reth node on the same server had more peers (100+). I attempted to retrieve the peers from the local reth node using the `admin_peers` RPC and then add them to the geth node using `admin_addPeer`. However, I noticed that the `admin_peers` RPC for reth was missing the `enode` and `enr` information.

In the process of fixing this issue, I realized that I was lacking some knowledge about devp2p, particularly the definition and generation of `enode` and `enr`. I learned about the following topics:

1. [Discv4 protocol](https://github.com/ethereum/devp2p/blob/master/discv4.md): I'm mainly focus the tcp/udp ports related topics, so find devp2p defines the `FindNode`/`Neighbors` packates to find the nearest neighbor nodes, and use `Ping`/`Pong` to validate and check the liveless of each peer;
2. [Ethereum Node Records]( https://github.com/ethereum/devp2p/blob/master/enr.md): This specification defines the format of a Ethereum p2p endpoint, contains id, ip, tcp, udp information;
3. [Diving into the Reth p2p stack](https://fiber.chainbound.io/blog/reth-p2p/): The p2p stack in reth, especially the peer management module.

The next week, I will continue to fix the part of reth’s `admin_peers` that generates `enr`. Additionally, I will implement the `ots_getContractCreater` RPC.