# Week 7

This week, I continued working on the issue: [Implement /eth/v1/beacon/light_client/optimistic_update](https://github.com/ReamLabs/ream/issues/211).

To test the implemented endpoint locally, I needed my Beacon node synchronized to the tip of the chain. Due to limited time and storage, a full sync was impractical, so I need to do a "quick sync". After some research I found the "quick sync" mode for censensus client is [checkpoint sync](https://ethereum.org/en/developers/docs/nodes-and-clients/#checkpoint-sync). It based on assumptions of [weak subjectivity](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/). Then I found ethPandaOps's page provides an [instruction](https://checkpoint-sync.holesky.ethpandaops.io) of correct steps to do checkpoint sync. Based on these information and Ream cli's help command, I figured out the appropriate command:
>`cargo run beacon_node --network holesky --http-port 5052 --checkpoint-sync-url https://checkpoint-sync.holesky.ethpandaops.io -e`

After displaying the startup logs, the node froze for nearly an hour while performing the checkpoint sync. It then switched to forward sync mode (also downloading blobs), and the Beacon API endpoints became accessible. Testing my endpoint against same [endpoint](http://testing.holesky.beacon-api.nimbus.team/eth/v1/beacon/light_client/optimistic_update) from nimbus team's testing node Beacon API revealed an internal server error. Subsequent testing of 3 other previously implemented light client endpoints also failed with similar error. I traced the code, found it's because `Latest Slot` of Ream DB was never set. I reported this to the Ream team. My mentor suggested switching to mainnet for test instead. So I found the checkpoint sync endpoint for mainnet on this [page](https://eth-clients.github.io/checkpoint-sync-endpoints/), then used below command to do the sync:

>`cargo run beacon_node --network mainnet --http-port 5052 --checkpoint-sync-url https://sync-mainnet.beaconcha.in/ -e`

Following the same sync process as with Holesky, I encountered the identical issue upon reaching the tip of mainnet: all 4 light client endpoints returned server errors due to the unset `Latest Slot`. Confirming this is actually a bug, I reported it again. My mentor advised pulling the latest code, and restarting the node if necessary. After pulling latest code, I removed -e/ephemeral from the command, so it could persist DB file. But when I tried to run it, I hit an error telling me the DB schema wasn't consistent. I skeemed through the code related to cli component, found the DB & data files are stored at
>/Users/xxx/Library/Application Support/ream/

I deleted all files, now running

> `cargo run beacon_node --network mainnet --http-port 5052 --checkpoint-sync-url https://sync-mainnet.beaconcha.in/`

After restarting the node several times, finally its `Latest Slot` was moving forward, I tested my endpoint against same [endpoint](http://testing.mainnet.beacon-api.nimbus.team/eth/v1/beacon/light_client/optimistic_update) from nimbus team's mainnet node Beacon API, the schema matched. This confirmed my implementation was correct.

## Resources
[Proof-of-stake (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/)
[Weak Subjectivity](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/)
[More on checkpoint](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)
[Checkpoint sync instruction on ethPandaOps](https://checkpoint-sync.holesky.ethpandaops.io)
[Checkpoint endpoints](https://eth-clients.github.io/checkpoint-sync-endpoints/)
[Holesky Beacon Chain Explorer](https://light-holesky.beaconcha.in)
[Mainnet Beacon Chain Explorer](https://beaconcha.in)
[Holesky testing optimistic_update endpoint of nimbus](https://testing.holesky.beacon-api.nimbus.team/eth/v1/beacon/light_client/optimistic_update)
[mainnet testing optimistic_update endpoint of nimbus](http://testing.mainnet.beacon-api.nimbus.team/eth/v1/beacon/light_client/optimistic_update)