web3-proxy/TODO.md

# Todo

- [ ] eth_sendRawTransaction should return the most common result, not the first
- [ ] if chain split detected, don't send transactions
- [ ] endpoint for health checks. if no synced servers, give a 502 error
- [ ] some production configs are occassionally stuck waiting at 100% cpu
  - looks like its getting stuck on `futex(0x7fc15067b478, FUTEX_WAIT_PRIVATE, 1, NULL`
  - they stop processing new blocks. i'm guessing 2 blocks arrive at the same time, but i thought our locks would handle that
- [ ] proper logging with useful instrumentation
- [ ] handle websocket disconnect and reconnect
- [ ] warning if no blocks for too long. maybe reconnect automatically?
- [ ] if the fastest server has hit rate limits, we won't be able to serve any traffic until another server is synced.
    - thundering herd problem if we only allow a lag of 0 blocks
- [ ] tarpit hard_ratelimit at the start, but reject if incoming requests is super high?
- [ ] add the backend server to the header?
- [ ] the web3proxyapp object gets cloned for every call. why do we need any arcs inside that? shouldn't they be able to connect to the app's? can we just use static lifetimes
- [ ] think more about how multiple rpc tiers should work
- [ ] if a request gets a socket timeout, try on another server
  - maybe always try at least two servers in parallel? and then return the first? or only if the first one doesn't respond very quickly?
- [ ] incoming rate limiting (by ip or by api key or what?)
- [ ] improve caching
  - [ ] if the eth_call (or similar) params include a block, we can cache for longer
  - [ ] if the call is something simple like "symbol" or "decimals", cache that too
  - [ ] when we receive a block, we should store it for later eth_getBlockByNumber, eth_blockNumber, and similar calls
- [ ] measure latency to nodes?
- [ ] one proxy for mulitple chains?
- [ ] zero downtime deploys
- [ ] are we using Acquire/Release/AcqRel properly? or do we need other modes?
- [x] simple proxy
- [x] better locking. when lots of requests come in, we seem to be in the way of block updates
- [x] load balance between multiple RPC servers
- [x] support more than just ETH
- [x] option to disable private rpc and send everything to primary
- [x] health check nodes by block height
- [x] Dockerfile
- [x] docker-compose.yml
- [x] after connecting to a server, check that it gives the expected chainId
- [x] the ethermine rpc is usually fastest. but its in the private tier. since we only allow synced rpcs, we are going to not have an rpc a lot of the time
- [x] if not backends. return a 502 instead of delaying?
watch new heads 2022-04-25 22:14:10 +03:00			`# Todo`

check block hash and store block number fewer places 2022-05-15 09:27:13 +03:00			`- [ ] eth_sendRawTransaction should return the most common result, not the first`
			`- [ ] if chain split detected, don't send transactions`
hmmm 2022-05-13 20:58:31 +03:00			`- [ ] endpoint for health checks. if no synced servers, give a 502 error`
move todos 2022-05-13 09:54:47 +03:00			`- [ ] some production configs are occassionally stuck waiting at 100% cpu`
			- looks like its getting stuck on `futex(0x7fc15067b478, FUTEX_WAIT_PRIVATE, 1, NULL`
			`- they stop processing new blocks. i'm guessing 2 blocks arrive at the same time, but i thought our locks would handle that`
			`- [ ] proper logging with useful instrumentation`
			`- [ ] handle websocket disconnect and reconnect`
			`- [ ] warning if no blocks for too long. maybe reconnect automatically?`
			`- [ ] if the fastest server has hit rate limits, we won't be able to serve any traffic until another server is synced.`
			`- thundering herd problem if we only allow a lag of 0 blocks`
			`- [ ] tarpit hard_ratelimit at the start, but reject if incoming requests is super high?`
set overall max inside the lock 2022-05-06 23:44:12 +03:00			`- [ ] add the backend server to the header?`
move todos 2022-05-13 09:54:47 +03:00			`- [ ] the web3proxyapp object gets cloned for every call. why do we need any arcs inside that? shouldn't they be able to connect to the app's? can we just use static lifetimes`
			`- [ ] think more about how multiple rpc tiers should work`
			`- [ ] if a request gets a socket timeout, try on another server`
			`- maybe always try at least two servers in parallel? and then return the first? or only if the first one doesn't respond very quickly?`
			`- [ ] incoming rate limiting (by ip or by api key or what?)`
			`- [ ] improve caching`
cleanup 2022-05-15 04:51:24 +03:00			`- [ ] if the eth_call (or similar) params include a block, we can cache for longer`
move todos 2022-05-13 09:54:47 +03:00			`- [ ] if the call is something simple like "symbol" or "decimals", cache that too`
cleanup 2022-05-15 04:51:24 +03:00			`- [ ] when we receive a block, we should store it for later eth_getBlockByNumber, eth_blockNumber, and similar calls`
move todos 2022-05-13 09:54:47 +03:00			`- [ ] measure latency to nodes?`
			`- [ ] one proxy for mulitple chains?`
			`- [ ] zero downtime deploys`
			`- [ ] are we using Acquire/Release/AcqRel properly? or do we need other modes?`
			`- [x] simple proxy`
			`- [x] better locking. when lots of requests come in, we seem to be in the way of block updates`
			`- [x] load balance between multiple RPC servers`
			`- [x] support more than just ETH`
			`- [x] option to disable private rpc and send everything to primary`
			`- [x] health check nodes by block height`
			`- [x] Dockerfile`
			`- [x] docker-compose.yml`
			`- [x] after connecting to a server, check that it gives the expected chainId`
			`- [x] the ethermine rpc is usually fastest. but its in the private tier. since we only allow synced rpcs, we are going to not have an rpc a lot of the time`
			`- [x] if not backends. return a 502 instead of delaying?`