-
-
Notifications
You must be signed in to change notification settings - Fork 714
Publish confirmed transactions by address #1198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
b5dd84c
to
fe7b7fa
Compare
b7311c9
to
a4b81b9
Compare
89f62d2
to
434394b
Compare
434394b
to
920cde2
Compare
920cde2
to
b82c433
Compare
b82c433
to
b74b9d9
Compare
b74b9d9
to
7de2a79
Compare
@kaladinlight is this a finished PR ready for review? |
@etimofeeva yep, it is ready to go! |
7de2a79
to
3223295
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds support for publishing confirmed transaction notifications directly to clients subscribed to specific addresses, bypassing the need to repeatedly fetch blocks from blockbook. This optimizes performance on high-throughput chains like Base by leveraging already-parsed sync blocks to detect relevant transactions and only fetching receipts when needed.
- Adds
newBlockTxs
parameter tosubscribeAddresses
for opting into confirmed transaction notifications - Refactors address subscription tracking to include per-subscription configuration details
- Updates the block processing pipeline to pass full block objects instead of just hash/height
Reviewed Changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
static/test-websocket.html | Adds UI checkbox for testing the new newBlockTxs option |
server/ws_types.go | Adds NewBlockTxs boolean field to subscription request struct |
server/websocket.go | Core implementation of confirmed transaction publishing with subscription tracking |
server/public.go | Updates block notification interface to pass full block objects |
docs/api.md | Documents the new optional parameter with example usage |
db/sync.go | Updates block processing callback to pass block objects |
blockbook.go | Updates callback function signatures for block processing |
blockbook-api.ts | Adds TypeScript interface for the new optional parameter |
bchain/types.go | Updates callback signature and adds transaction receipt method |
bchain/coins/eth/ethrpc.go | Refactors and exposes transaction receipt fetching method |
bchain/coins/blockchain.go | Adds metrics wrapper for new transaction receipt method |
bchain/basechain.go | Provides default implementation for transaction receipt method |
api/worker.go | Exposes transaction conversion method for external use |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Currently in order to push confirmed transaction notifications to a client, you have to:
Historically this has worked without any noticeable issue, however in integrating Base, I have noticed this no longer holds up due to the fast block times and high transaction throughput on chain. The node gets oversaturated with network requests causing it to fall out of sync along with blockbook. Even when they are staying in sync, I was seeing calls to get a block taking more than 30 minutes. I did make many attempts at increasing resources, cache sizes, etc. to improve performance without avail.
To reduce most overhead related to this scenario, I chose to add an optional
newBlockTxs
param tosubscribeAddresses
which will allow subscribing to addresses for mempool AND confirmed transactions now. By leveraging the mostly parsed sync blocks, we can detect all associated addresses for a transaction to determine if a confirmed transaction should be published to a client and only then, fetch the evm transaction receipt to ensure anapi.Tx
is sent to the client. This update cuts down nearly all of the previously seen network requests and completely fixed the performance issues seen in the above scenario.(I went with
newBlockTxs
just to tie into the new block vernacular, but could update toconfirmedTxs
if that sounds better.)