This repository was archived by the owner on Jul 31, 2026. It is now read-only.
ci: isolate public benchmark runners from fork code - #7
Open
odyslam wants to merge 29 commits into
Open
Conversation
reth creates HTTPS clients at startup (ERA history import) and reqwest 0.13 panics when the system CA store is empty, crash-looping the node. The ubuntu:24.04 base image ships no ca-certificates, and upstream's published images avoid this via Dockerfile.depot, not ./Dockerfile. Adds a fork-owned Dockerfile.phylax (copy of ./Dockerfile plus ca-certificates in the runtime stage) so upstream rebases don't conflict, and points phylax-docker.yml at it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Removes book.yml, hive.yml, and bench-scheduled.yml. These fire automatically but depend on upstream-only infra (self-hosted runners, GitHub Pages publishing) this fork doesn't operate.
credible_call_overrides resolved the block tag to a concrete number for the marker, but the original tag was re-resolved independently by the EVM call. If the chain tip advanced in between, the marker targeted block N while the call executed at N+1, intermittently reverting marker-aware calls. Resolve the tag once and pass the pinned block to both the override and the call.
credible_block_number_override truncated block_overrides.number from U256 to u64 while the EVM uses the full width, so a block number above u64::MAX would inject the marker into the wrong mapping slot. Thread U256 through slot derivation so the marker matches the block number the registry lookup sees.
The marker-block pinning replaced every non-pending block id with a resolved number, including an explicit block hash. That dropped reorg safety: a non-canonical or reorged hash could resolve to a different block at the same height. Pin only moving tags (latest, safe, finalized) and leave an exact hash or number unchanged.
The raw-transaction broadcast ran before a forwarded tx was marked private, so with --rpc.credible-retain-forwarded-private the tx was still exposed through the raw-transaction subscription channel despite being filtered from the pool-read RPCs. Resolve the retained origin first and skip the broadcast when it is private.
The single-call marker paths (eth_call, eth_estimateGas, eth_createAccessList) resolved the target block number with a separate provider read in the RPC handler, then let the execution path resolve the block again. For `pending` the two reads could straddle a new block, so the marker was written for `latest + 1` while the call executed at `latest + 2`, leaving `_credibleBlocks` unset for the executed block. Move the marker injection down to where the resolved EVM env already exists (`prepare_call_env`, `estimate_gas_with`, `create_access_list_with`), deriving the block number from `evm_env.block_env.number()` after any block override is applied. Marker slot and execution now resolve the same block by construction. This also folds in eth_callMany, which previously carried a bespoke per-bundle injection, and covers the trace/debug call paths that share `prepare_call_env`. All remain no-ops without a registry. `apply_credible_block_override` now takes and returns the call's `Option<StateOverride>` directly instead of round-tripping through `EvmOverrides`, so every injection site is a single call.
Retaining forwarded transactions as private must be overlay-only: it may hide a retained transaction from pool enumeration and its raw bytes, but a lookup by hash still needs to resolve it so callers can track it before inclusion. The pool branch of the by-hash lookup was suppressing the retained transaction, which broke that tracking path. Restore the upstream pool lookup so `eth_getTransactionByHash` returns the retained transaction. Filtering stays on the enumeration surface (`eth_pendingTransactions`) and the raw-byte surface (`eth_getRawTransactionByHash`).
eth_getRawTransactionByHash checked the pool entry's origin and fetched its raw bytes through two independent pool reads. A private transaction inserted between the two could be returned, because the origin check ran before it was present and so saw it as non-private, leaking its bytes before inclusion. Gate the raw-byte fetch on a single origin check of the same pool entry. The fetch runs only once the entry is seen as non-private, and a hash maps to one immutable-origin transaction, so it can only return that authorized entry; a mined transaction is still returned by the provider lookup.
Hiding retained-private transactions keys off `Private` transaction origin, which is exact only because forwarder retention is the sole path assigning that origin on this node. Record the assumption so a future `Private` source doesn't silently widen what gets hidden.
Add RPC handler-level tests that execute eth_call, eth_estimateGas and eth_createAccessList through a mock provider with a registry contract, and assert the credible marker reaches the EVM: disabled-config parity, an explicit block number, a block-number override, and the pending path (marker derived from the resolved env at latest + 1). eth_callMany shares the same injection point as eth_call, and eth_simulateV1 requires block recovery the mock provider does not support, so those remain covered by the external node test suite.
Retention only filtered eth_pendingTransactions; the txpool namespace read the pool directly and still exposed private-origin transactions through txpool_content, txpool_contentFrom and txpool_inspect, and counted them in txpool_status. Thread the Credible Layer config into TxPoolApi and drop private-origin transactions from those methods when retention is enabled, keeping the cheap count path when it is not.
Assert the txpool namespace hides retained-private transactions when retention is enabled and exposes them when it is not.
txpool_status walked the whole pool and cloned every entry via all_transactions() to exclude private-origin txs under Credible Layer retention, turning a cheap, frequently-polled endpoint into O(n) work with two allocations per call. The pending and parked sub-pools now maintain a running private-origin count alongside their size tracker, so private_pending_and_queued_txn_count is O(1) and txpool_status reads it instead of scanning. Also wires the count through the TransactionPool trait, which previously fell back to the (0, 0) default on the concrete pool.
…t const The credible-blocks base slot is fixed to the CredibleRegistry storage layout, not configurable. The DEFAULT_ prefix implied a configurability that does not exist.
The maintained private-origin count is decremented on removal. If a future removal path ever skips the paired increment, a plain subtraction would panic in debug and wrap in release, permanently corrupting the count. Assert the count is positive in debug builds and saturate in release.
txpool_status read the pool totals and the private counts through two separate pool snapshots. A private transaction moving between the pending and queued sub-pools between the reads could be counted in one snapshot but subtracted from the other, leaving a private transaction in the public count under Credible Layer retention. Add a combined accessor that returns totals and private counts from one pool view and use it in the handler so the subtraction is consistent.
…_txn_counts Clearer than pending_and_queued_txn_count_with_private for a method returning ((pending, queued), (private_pending, private_queued)).
feat(rpc): add credible block override
ci: cache docker builds via GHCR registry buildcache
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
Summary
mainValidation
git diff --check