It seems transactions on polygon can get automatically dropped and replaced.
original: 0xa67609bacf51ab83b1989e4097b4147574b4e26399bec636c4cfc5e12dfa2897
replaced: 0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555
What is happening here?
On Ethereum, I believe this can only happy if someone proactively replaces the tx by submitting another with the same nonce and higher gas price. Is that correct?
{"level":"error","message":"Error: transaction was replaced [ See: https://links.ethers.org/v5-errors-TRANSACTION_REPLACED ] (cancelled=true, reason=\"replaced\", replacement={\"hash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"type\":2,\"accessList\":[],\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\",\"blockNumber\":39285028,\"transactionIndex\":60,\"confirmations\":2,\"from\":\"0x90Be1Ef5EEa48f1d33e2574a73E50D208bB3680E\",\"gasPrice\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"maxPriorityFeePerGas\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"maxFeePerGas\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"gasLimit\":{\"type\":\"BigNumber\",\"hex\":\"0x0186a0\"},\"to\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"value\":{\"type\":\"BigNumber\",\"hex\":\"0x00\"},\"nonce\":112,\"data\":\"0xe3ee160e00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e00000000000000000000000000000000000000000000000000000000000027100000000000000000000000000000000000000000000000000000000063eb95950000000000000000000000000000000000000000000000000000000063eb9b71c726f5f957d29df36c915d2f2816a5906bdb096a68d79abeb83102359a3c51ef000000000000000000000000000000000000000000000000000000000000001cbaca5b2bb8c9b3a25ba94b3303be256a72cc37172886b67140c788f53eacfa0526f4bc5dd18d1e0154a0c574c12ff67b656846a731cc55e32b7d60a8ae5b21ee\",\"r\":\"0x2503d5645a7620c94678ef0a5de4bca4e03b18943cec0511d58b7e444412b467\",\"s\":\"0x72c2cf739e2bfeb8335faab2c4b87b7b0464c9681a488456fa7c8fe25aef89c6\",\"v\":1,\"creates\":null,\"chainId\":137}, hash=\"0xa67609bacf51ab83b1989e4097b4147574b4e26399bec636c4cfc5e12dfa2897\", receipt={\"to\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"from\":\"0x90Be1Ef5EEa48f1d33e2574a73E50D208bB3680E\",\"contractAddress\":null,\"transactionIndex\":60,\"gasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x0110bc\"},\"logsBloom\":\"0x00000000000000001000000000000000000000000000000000000000000000000000000000000000020000000000000000008000000000000000000200000000000000000000000000000008000000800000000000000000000100000000000000000000000000000000000000000000020000000000000180000010000000000001000000400000000000008000000000008000000000004000000000000000200000000000000000000000000000000004000000000000000000000000004000100002000000000081000000000000000000000000000000100000000000000000008000000000800000000000000000000000000000000000000000100000\",\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\",\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"logs\":[{\"transactionIndex\":60,\"blockNumber\":39285028,\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"address\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"topics\":[\"0x98de503528ee59b575ef0c0a2576a82497bfc029a5685b209e9ec333479b10a5\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\",\"0xc726f5f957d29df36c915d2f2816a5906bdb096a68d79abeb83102359a3c51ef\"],\"data\":\"0x\",\"logIndex\":250,\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\"},{\"transactionIndex\":60,\"blockNumber\":39285028,\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"address\":\"0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174\",\"topics\":[\"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\"],\"data\":\"0x0000000000000000000000000000000000000000000000000000000000002710\",\"logIndex\":251,\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\"},{\"transactionIndex\":60,\"blockNumber\":39285028,\"transactionHash\":\"0xec0d501619b5fc9cde6af41df929eeded252138a49965f15a7598bf2e532e555\",\"address\":\"0x0000000000000000000000000000000000001010\",\"topics\":[\"0x4dfe1bbbcf077ddc3e01291eea2d5c70c2b422b415d95645b9adcfd678cb1d63\",\"0x0000000000000000000000000000000000000000000000000000000000001010\",\"0x00000000000000000000000090be1ef5eea48f1d33e2574a73e50d208bb3680e\",\"0x000000000000000000000000e7e2cb8c81c10ff191a73fe266788c9ce62ec754\"],\"data\":\"0x00000000000000000000000000000000000000000000000000080d77c3b67cb80000000000000000000000000000000000000000000000003005ebfb86a0d1350000000000000000000000000000000000000000000003ebfb8e3e34e504eca50000000000000000000000000000000000000000000000002ffdde83c2ea547d0000000000000000000000000000000000000000000003ebfb964baca8bb695d\",\"logIndex\":252,\"blockHash\":\"0x252f663dfb64dd82dff77b5e4fbe2073cd77248c5ce8dff1191c87ac22d97cf9\"}],\"blockNumber\":39285028,\"confirmations\":2,\"cumulativeGasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x8d88d1\"},\"effectiveGasPrice\":{\"type\":\"BigNumber\",\"hex\":\"0x6cdbaaf8e5\"},\"status\":1,\"type\":2,\"byzantium\":true}, code=TRANSACTION_REPLACED, version=providers/5.7.1)"}
On Ethereum, I believe this can only happy if someone proactively replaces the tx by submitting another with the same nonce and higher gas price. Is that correct?
Yes, and the same is possible on Polygon and other EVM chains.
Senders can replace their transactions for multiple reasons. For example, high-frequency trading bots continuously check if their pending transactions are still likely to be profitable - and if the transaction is not going to be profitable, the bot replaces it with another one. Either with new recalculated params that they expect to be profitable or simply with transaction from/to the same address so at least they don't lose any more funds than just the gas fees.
Note: Once you send a transaction, it's impossible to drop it completely from the mempool. That's why it is sent back to the sender address.
Or sometimes transactions are replaced by regular users that specified insufficient gasPrice and want to speed up the transaction by replacing the gas price with a higher value.
what's the average size of a smart contract on Ethereum ?
I already searched for it on google , twitter , reddit , duckduckgo but everything in vain
The maximal size allowed by the network is 24576 (hex 0x6000) bytes, as per the EIP-170. An empty contract compiled with the latest compiler version results in 92 bytes. So the average is somewhere between those numbers.
How to calculate the average contract size:
Loop through all existing blocks, get their transaction hashes
Loop through all transaction hashes and query the respective transaction receipts (docs)
You're interested only in those that contain non-empty contractAddress field, meaning these transactions were contract deployments
Each of the contractAddress fields point to a contract address
Query the eth_getCode method (docs) for each of these addresses, which returns the contract binary. Add the binary length to your calculation, and finally divide by the number of results.
Mind that some contracts might have been selfdestruct, so they'll return 0 size even though they have been previously deployed. Depending on your method, you may or may not want to include the selfdestruct contracts in your calculation, or possibly query their (non-zero) size at the block of their creation.
I am asking this question so that I want to easily know how many transactions occurred at a particular Bitcoin price. For example, at the price of $20T per BTC, how many are they?
There could be other ways finding this correlation, but my question is: Does the block stores this dollar value?
It does not.
Each block contains a list of transactions and other metadata such as block number, timestamp when it was mined, etc... But the fiat monetary value is not part of the block, nor a part of a transaction.
You'll also need to define a source of truth for the price. While a specific block was mined on a specific time, the price of Bitcoin at that specific time was slightly different on each exchange.
Example (values are made up):
Block number 500,000 was mined on 2022-01-01 00:00:00.
At this exact time, the highest bid on Binance was $19,990, the lowest ask on Binance was $20,000, the highest bid on Coinbase was $20,050, the lowest ask on Coinbase was $20,070, etc.
Exchanges and aggregation services (such as Coinmarketcap) often offer some average prices through their API for a specified timeframe. But there's no "one price of Bitcoin at a specified time".
I am reading through UniswapV2 docs and can't understand the inputs of addLiquidity method properly.
As listed in the docs:
amountAMin (uint): Bounds the extent to which the B/A price can go up before the transaction reverts. Must be <= amountADesired.
amountBMin (uint): Bounds the extent to which the A/B price can go up before the transaction reverts. Must be <= amountBDesired.
What does it mean? Can you please give an example? Let's say, I set amountADesired and amountBDesired to 4 and amountAMin and amountBMin to 1. What will happen?
blockchain transactions are not immediate, but must queue before being mined on the blockchain and be effective
When you add liquidity given amountADesired you have to give it amountBDesired in proportion to the existing pair (example pair: 2:1 you have to put 2 tokens A and 1 token B)
once you send the transaction, before it is mined it may happen that others make operations on that liquidity pool, changing the proportion accordingly
by entering amountAmin and amountBmin you are practically telling him: "as long as the proportion is between amountADesired:amountBDesired and amountAMin:amountBmin accepts my liquidity addition, if instead the proportion exceeds my range, cancel my transaction"
Well i have some questions regarding the UTXO model -
1) How is it decided how many transactions will a block contain? Are these transactions related in any sorts?
2) Where are the details of sender and recipient of a transactions stored? If they are not stored, how is it decided where to transfer bitcoins?
1) Miners will usually fill the next block with as many of the highest paying (by fee rate, satoshis/kb) valid (not spent already and pass validation checks) transactions as they can. That way they maximize the transaction fee that they are paid if they win the block reward. There is a limit to the number of bytes a block can contain and it is calculated based on a maximum block weight of 1M virtual bytes, see Weight Units, and is theoretically slightly less than 4MB.
2) They are stored in the transactions which are stored in the blocks. By details all that is stored is the scripts, for the sender, the input script (previous output's scriptPubKey and scriptSig), and for the receiver, the output script (scriptPubKey). See Transaction for more detail.
1> Transactions are broadcasted by anyone in the system and at random intervals. Which transactions, of all the ones broadcasted, are included is very dependent on the miner, as he/she is the one who groups them up and includes them in the block. As Nate noted below, there is also a 1MB block size limit which limits how many transactions can be included in a block. This limit is to prevent huge blocks that clog the network and may be removed if the number of transactions in the network ever grows such that the limit is a serious factor.
2> Sender and recipient transactions are stored in the Blockchain Blocks.Transaction data includes scripts used to spend cryptocurrency amounts listed in the transaction data. The most common of these scripts specify what is commonly called an "address" but that is derived from a public key and is nowadays usually unique to a transaction. It is designed to be difficult or impossible to identify a sender or recipient from these "addresses".
If it is not stored then the transaction will not happen.