You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: always use finalized block header for transaction signing (#918)
* handle fetching the block header ourselves, and cache it for 6 seconds--because we have a high transaction volume, every network round trip to the node that we can save is important.
* always use the finalized block for transaction signing, which should eliminated at least some problems.
* eliminating the fetch of one of the block headers cuts down on network round trips to the chain RPC node.
* Gets the block hash and number of the latest block for signing. We cache this info & update asynchronously. This
324
312
* eliminates unnecessary RPC calls to get the latest block info, since it's okay if we're a little behind in the block number/hash we
325
313
* use for signing and mortality checking.
326
-
* @returns The block hash & number of the latest finalized block if the finality lag is greater than the maximum allowed, otherwise the block hash of the latest block.
314
+
* @returns The block hash & number of the latest finalized block
315
+
*
316
+
* NOTE: the polkadot-js logic that inspired this would fetch both the latest & latest finalized blocks, and choose
317
+
* between them based on the block number delta compared to MAX_FINALITY_LAG. But because we're caching this and don't
318
+
* really care if we're a little behind, and because issues with the fork-aware transaction pool can sometimes make this
319
+
* problematic, it's better to just rely on the latest finalized block. Also, eliminating the need to get both block
320
+
* headers cuts down on network round trips to the chain node.
0 commit comments