Skip to content

feat: optimize rpc calls#5394

Open
sbackend123 wants to merge 7 commits intomasterfrom
feat/rpc-calls-optimisation
Open

feat: optimize rpc calls#5394
sbackend123 wants to merge 7 commits intomasterfrom
feat/rpc-calls-optimisation

Conversation

@sbackend123
Copy link
Contributor

@sbackend123 sbackend123 commented Mar 12, 2026

Checklist

  • I have read the coding guide.
  • My change requires a documentation update, and I have done it.
  • I have added tests to cover my changes.
  • I have filled out the description and linked the related issues.

Description

Removed RPC patterns in the transaction flow. Added cache layer for BlockNumber rpc call.
Fixed lint issues in the new cache package and cleaned up minor lint findings in adjacent test/helper code.

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

#5388

Screenshots (if appropriate):

Screenshot from 2026-03-16 13-29-22

Highly likely hit ratio is low because of high load errors (EOF), which is fix by PR

@sbackend123 sbackend123 changed the title RPC calls optimisation Feat: RPC calls optimisation Mar 12, 2026
@sbackend123 sbackend123 force-pushed the feat/rpc-calls-optimisation branch from f8ca4e2 to e55ac11 Compare March 13, 2026 07:54
@sbackend123 sbackend123 force-pushed the feat/rpc-calls-optimisation branch from e55ac11 to 04f6520 Compare March 13, 2026 08:00
@sbackend123 sbackend123 changed the title Feat: RPC calls optimisation feat: optimize rpc calls Mar 13, 2026
@sbackend123 sbackend123 marked this pull request as ready for review March 16, 2026 12:31
blocktime,
true,
c.config.GetUint64(optionNameMinimumGasTipCap),
blocktime-2,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to note that current blocktime on our CI is 1s. So this way caching is not used there... How we could achive to use it there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In deploy.go blockTime is hardcoded by itself. But if we are talking about CI, normally cacheTTL is about 85% of block time, so even if it is 1 second, than we will get 850 ms

t.Helper()

var expSegments [][]byte
expSegments := make([][]byte, 0, len(exp))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are fine but feel like they belong in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but linter was failing so I decided to fix everything. Next time will create separate PR

pollingInterval time.Duration,
chainEnabled bool,
minimumGasTipCap uint64,
blockCacheTTl time.Duration,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo blockCacheTTl -> blockCacheTTL

}
}

func NewMetrics() Metrics {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems not used (dead code).

c.metrics.LoadErrors.Inc()
return val, err
}
c.Set(val, time.Now())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use here now from argument?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What could happen if loader takes a while?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think so because there is difference between time when we request value and time, when we set new value if we had to load it.

@gacevicljubisa
Copy link
Member

Suggestion: Instead of a fixed TTL (blocktime*85/100, blocktime-2) + BlockNumber RPC, use a single HeaderByNumber(nil) call periodically to get both the block number and timestamp, then extrapolate between syncs with zero RPC calls.

How it works:

  • Every ~20 blocks, call HeaderByNumber(nil) (latest) — returns block number + timestamp in one RPC call. Store as anchor point.
  • Between syncs, estimate the current block from pure math: currentBlock = anchorBlock + (now - anchorTimestamp) / blockTime. No RPC calls at all.
  • Cache TTL: anchorTimestamp + (currentBlock - anchorBlock + 1) * blockTime - now.
    ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants