search

ponder-sh / ponder

A backend framework for crypto apps
https://ponder.sh
MIT License
609 stars 89 forks source link

[Feature] Better support for Anvil/Foundry #916

Closed 0xOlias closed 3 months ago

0xOlias commented 4 months ago

Per discussion in the chat, Ponder doesn't currently work very well when indexing a local chain like Anvil or Hardhat Network.

Here is the proposed workflow:

  1. Write contracts, start anvil, deploy to anvil a. anvil b. forge script ./script/0_Deploy.s.sol:Deploy --broadcast --fork-url http://localhost:8545 ...
  2. Start ponder dev server, which accurately indexes events emitted during the foundry script a. ponder dev
  3. Update contracts, reset local chain a. kill anvil process b. anvil c. forge script ./script/0_Deploy.s.sol:Deploy --broadcast --fork-url http://localhost:8545 ...
  4. Restart ponder dev server, which syncs from scratch + again indexes correctly a. kill ponder dev process b. ponder dev

We should be able to unblock this with some debugging and a few small changes. Here's a first pass:

  1. RPC request cache invalidation: Today, the workflow above breaks Ponder because on subsequent starts, the cache will contain stale data from the prior version of the chain. To solve this, we could add an option on networks that disables caching. Could call it disableCache or maybe isLocalChain. In practice, the easiest implementation would be to delete all cached data for that chain on startup. Ideally, this RPC cache invalidation function would be the same thing that powers the proposed ponder cache CLI entrypoint.
  2. Fix start block bug(s): We need better testing around edge case conditions between a contract startBlock and endBlock and the network latest and finalized blocks. Nearly certain we have bugs if the start block is in the unfinalized range. I'd like to design a durable solution here that also fixes https://github.com/ponder-sh/ponder/issues/813.
  3. Test local chain + live chain: Users have reported some events don't get processed when both chains are "uncommented", which suggests that the overall sync checkpoint gets stuck at some point in the past. This could be related to 2. I'm also curious if automine behavior plays a role here - what block timestamp gets used for blocks mined on a fresh chain vs a fork, etc? Ponder relies heavily on block timestamp, so that could be the problem here.

Checklist

trajan0x commented 4 months ago

I'd suggest one UX improvement on this:

Anvil may be open to adding a Server header that we could use to detect anvil. Obviously the isLocalChain option would take precedence if specified, but this would help new users a bunch

aureliusbtc commented 4 months ago

Anvil may be open to adding a Server header

Anvil doesn't need to add this, since Ponder could call the web3_clientVersion RPC method to determine if it's a local network:

~ cast rpc web3_clientVersion -r http://127.0.0.1:8545
"anvil/v0.2.0"

This has stayed consistent throughout Foundry version upgrades, with "anvil/vX.X.X" being the returned response.

trajan0x commented 4 months ago

Makes sense, thought a server header would be better b/c this is an additional request on startup. But makes sense

0xOlias commented 3 months ago

Done in https://github.com/ponder-sh/ponder/pull/923