[BCN] Vendor block-by-date helper for Alchemy + MultiProvider#4172
Open
leolambo wants to merge 5 commits into
Open
[BCN] Vendor block-by-date helper for Alchemy + MultiProvider#4172leolambo wants to merge 5 commits into
leolambo wants to merge 5 commits into
Conversation
Ports the getDate path from monosux/ethereum-block-by-date as a tiny local module. Trims everything we don't use: no getEvery, no viem support, no moment dep (native Date + unix-second math). Owning the algorithm in-tree lets the Alchemy adapter and MultiProvider fallback share an interpolation-based block lookup without pulling moment into bitcore-node.
Replaces the handwritten binary search in getBlockNumberByDate with the interpolation-based EthDater. Typically converges in fewer RPC calls than vanilla bisect, and handles future-date and pre-genesis edges for us. Daters are cached per chain:network so repeated lookups reuse the boundary state.
Replaces the in-CSP binary search fallback (invoked when the bounded walk in _verifyBlockBeforeDate can't converge in 16 RPC steps) with the vendored EthDater. The bounded walk remains the fast path that nudges adapter-returned candidates; EthDater only runs when the candidate is too far off. Daters are cached per network so the boundary state survives across calls.
leolambo
force-pushed
the
alchemyBlockByDateVendor
branch
from
3736f23 to
ddad38f
Compare
The test queried a 10000-block range to verify three transfers all clustered within ~510 blocks. getErc20Transfers walks in 100-block windows, so the wide range cost ~200 sequential eth_getLogs calls and routinely tripped the 10s in-test timeout on the public Base sepolia RPC. Same expected payload, ~10 calls now.
The fakeWeb3 helper claimed 'latest' as a valid key on its input map but no caller passed it (we compute the latest block number from the max numeric key). Strict tsc on CI rejected the mismatch. Narrow the parameter type so callers compile.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The Alchemy adapter and MultiProvider's verification fallback were both running handwritten binary searches over
eth_getBlockByNumberto resolve date to block. Both now use a small in-tree helper ported from monosux/ethereum-block-by-date that uses average-block-time interpolation instead. Typically converges in fewer RPC calls than vanilla bisect and handles future-date and pre-genesis edges.This is the vendor counterpart to #4167. Same algorithm, but ported into ~120 lines under
src/utils/ethDater.tsso we don't pull inethereum-block-by-dateand itsmomenttransitive dep. Pick one PR to merge; the other can be closed.Changelog
src/utils/ethDater.ts(port of thegetDatepath, no moment, nativeDate+ unix-second math)EthDaterin the Alchemy adapter'sgetBlockNumberByDateEthDaterin MultiProvider's_verifyBlockBeforeDatefallback (replaces_binarySearchBlockByTimestamp)EthDaterinstances per chain:network (Alchemy) / per network (MultiProvider) so boundary state survives across callsTesting Notes
hit any date-to-block resolving endpoint on a chain backed by Alchemy or MultiProvider (e.g.,
GET /api/<chain>/<network>/block/before/<timestamp>) and verify the block returned matches what the previous bisect would have returned. The bounded RPC walk in MultiProvider remains unchanged, so the common case still finishes in ≤16 hops without invoking the new helper.Checklist