Scribd
Upload
29 views

Ethereum Questions

This document discusses metrics for analyzing delays in Ethereum transaction propagation between different node providers. It defines several metrics including the delay between when a pending transaction is first seen by a provider and when other providers see it, the total number of pending transactions seen by each provider, the number missed by each provider, and the delay between a transaction first being seen and ultimately being included in a mined block. Clarification is provided on calculating each metric using transaction hash data observed by different node providers over time.

Uploaded by

Azhar Mateen
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
29 views

Ethereum Questions

This document discusses metrics for analyzing delays in Ethereum transaction propagation between different node providers. It defines several metrics including the delay between when a pending transaction is first seen by a provider and when other providers see it, the total number of pending transactions seen by each provider, the number missed by each provider, and the delay between a transaction first being seen and ultimately being included in a mined block. Clarification is provided on calculating each metric using transaction hash data observed by different node providers over time.

Uploaded by

Azhar Mateen
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Timestamp of the first time a pending tx is seen

This refers to the timestamp at which the tx was first seen by the script.

- Delay between the first time a pending tx is seen and other providers see the same
tx

Does this refer to first_tx_time; ?

If a provider has already seen a pending tx before another provider then compute the
difference between the most recent timestamp and the earliest timestamp
(delay = timestamp_seen_by_provider_a - timestamp_first_seen)

- Total number of pending tx seen by provider

Does this refer to cnt_infura, cnt_alchemy, and so on....?

Each time a new tx is seen by a provider you should increment the total number of tx
he has seen.

- Number of pending tx missed by a provider (never seen)

Does this refer to total_cnt - cnt_infura, total_cnt - cnt_alchemy, and so on...?

This should be check by looking at all the tx hashes a provider has seen and
reported to the script vs all the tx hashes seen and reported by all the providers.
(tx_missed = total_unique_tx_hashes – unique_tx_hashes_provider_a)

- Amount of pending tx seen by all providers

Does this refer to total_cnt ?

These are tx that have been seen by all providers, all of them having this tx hash in
their list of seen pending tx.

- Amount of tx missed by all providers (private tx)

This needs to be explained a bit ?

These are tx that have been missed by all providers, none of them having this tx
hash in their list of seen pending tx. To get this information you should scan the list
of tx hashes in mined blocks to see if there are tx that were never seen in the
mempool.

- Amount of pending tx seen by only one provider

Does this refer to cnt_infura, cnt_alchemy, and so on?

These are tx that only one provider has reported before it was mined in a block.
- Delay between first time a pending tx is seen and the block it is included i
This needs to be explained a bit ?

This should be the delay between the time a tx been first seen and the moment the
tx can be found in a mined block.
(mining_delay = timestamp_tx_in_block – timestamp_tx_first_seen)

For now, As per our understanding we’d be performing the following tasks.

1. We need to run Ethereum nodes on VPS in Europe. And the VPS is needed,
preferably
from the Client side.

You could use VPS to evaluate the delays closer to our current location but this is
not a requirement. To connect to the Ethereum node providers you will just need a
library such as EthersJS or Web3JS.

2. We need api keys from Infura, alchemy and so on. We can make it ourselves, but
we
need help from the client. Because free keys have limitations per day.

The study should be carried out within the limits of free API keys.

3. We’re going to scan the mempool from providers and measure the speed. and
delay...!!

Exactly

You might also like