How does one check the number of "block confirmations" for a given transaction?
I tried checking the transaction hash in block heights of +1, +2, etc. but they don't contain the transaction ID.
Would I instead need to wait for future blocks to be mined, and the transaction status to still be considered valid? the Receipt.Status.
After lots of research, I can say that it is the number of blocks that have been mined after the block your transaction was included in, and your transaction is still considered valid. So to check block confirmations, you would check whether the transaction is still valid, and see how many more blocks above the transaction block height have been mined.
Therefore, if your transaction has 13 block confirmations (see above graphic), then there have been 12 blocks mined since the block was mined that included your transaction.
https://jaredstauffer.medium.com/what-is-a-block-confirmation-on-ethereum-e27d29ca8c01#:~:text=A%20block%20confirmation%20is%20simply,mined%20that%20included%20your%20transaction.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 months ago.
Improve this question
In case if an Ethereum transaction was mined into an orphaned block:
Would it still make it into a different "confirmed" block, or it would be reverted?
Can this disrupt the nonce sequence of transactions in the confirmed blocks? For example, can we get transactions with reverse order of nonces in different blocks? (transaction with nonce 1 in block 10 and transaction with nonce 0 in block 11)
The longest chain is the source of truth.
Orphaned blocks (aka uncle blocks) are valid blocks that are not part of the longest chain.
Even though the transaction has been included in an orphaned block, it is not part of the longest chain. Which means it's not mined yet, state changed resulting from this transaction have not been accepted by the network, and it can be still included in a "confirmed" block.
Applied to your example from point 2: The "transaction nonce 0" has not happened yet, even though it's part of an orphaned block. So it can be mined in some next block. And because it has lower nonce, it has to be executed before the "transaction nonce 1".
i know what is a gas, gaslimit and gasprice, but still have confusion even after searching and reading through the Internet.
There is a gaslimit per block, but why many blocks did not reach it? in other words, can a miner send a block to the network without reaching the gaslimit for the block?
Assume the block gaslimit is 4 million and i sent a transaction with 4 million gaslimit. But when the miner executed it (used gas was 1 million). Can the miner add extra transactions to the block to fill the remaining 3 million or not. In another way, does a transaction with a big gaslimit (but uses a fraction of that gas) affects the miner of adding more transactions to the block?
Each Opcode coast some value of gas. How Ethereum measure the cost of each EVM opcode? (any reference for explanation?).
Thanks
Q1 The block gas limit is an upper bound on the total cost of transactions that can be included in a block. Yes, the miner can and should send a solved block to the network, even if the gas cost is 0. Blocks are meant to arrive at a steady pace in any case. So "nothing happened during this period" is a valid solution.
Q2a The gas cost of a transaction is the total cost of executing the transaction. Not subject to guesswork. If the actual cost exceeds the supplied gas then the transaction fails with an out-of-gas exception. If there is surplus gas, it's returned to the sender.
Q2b Yes, a miner can and should include multiple transactions in a block. A block is a well-ordered set of transactions that were accepted by the network. It's a unit of disambiguation that clearly defines the accepted order of events. Have a look here for exact meaning of this: https://ethereum.stackexchange.com/questions/13887/is-consensus-necessary-for-ethereum
Q3 I can't say for sure (possibly someone can confirm) that this is an up-to-date list: https://docs.google.com/spreadsheets/d/1m89CVujrQe5LAFJ8-YAUCcNK950dUzMQPMJBxRtGCqs/edit#gid=0
The CUDA documentation tells us that the result of a warp shuffle is undefined if the origin thread is "inactive". Does that mean we can safely shuffle with only part of the threads, and only need to pay attention to the junk data coming from the inactive ones? Or might the entire shuffle output be garbage?
If the target thread is inactive, the retrieved value is undefined.
My understanding is that the value returned to the thread that targeted an inactive thread is undefined. Threads that target an active thread behave as normal.
So you can get correct answers from shuffle in diverged code, so long as your target has followed the same path through the divergence.
I wonder — if I have have an SQL transaction where in one statement I do a select query, and then in a later statement an update query, is it guaranteed that nothing has been changed by outside factors in between the two?
So I select a number of rows ⟵ in the transaction
Another procedure changes one of the rows ⟵ outside the transaction
Than I want to do the update ⟵ in the transaction
So can this happen? I know the total transaction either happens or it doesn't, but are all individual statements in 1 transaction also executed as 1 atomic unit where nothing can happen in between two different statements? Or is the only way to ensure that the database is locked in between the two statements by setting a manual table lock?
This problem is about this by the way: I transfer money from one user (the buyer) to another (the seller). However, the buyer already deposited money when placing the buy order. Now he may cancel this buy order at any moment. I will then give him back the deposited money. So now it can happen that I'm in the process of transferring the deposited money from the buyer to the seller, while the buyer cancels his order, and I give him back his money. So now the money is given to the buyer, AND to the seller. This requires some high level isolation right?
It depends on transaction isolation level.
Default isolation level on all of databases I have ever used is Read Committed and this level allows to see changes made by other committed transactions.
In contrast Serial or Snapshot isolation levels isolate current transaction from others but it does not scale as good as Read Committed.
You can change isolation level per transaction or globally on all of modern databases but I would not suggest to do it without a very good reason, Read Committed is a good isolation for typical use cases because it needs no locking for reads, Serial isolation uses heavy locking to make transactions serial instead of concurrent and it might not scale for typical uses cases.
Can anyone provide exhaustive explanation, please? I'm diving into concurrent programming and met those registers while trying to understand consensus.
From Lamport's "On interprocess communication": ...a regular register is atomic if two successive reads that overlap the same write cannot obtain the new then the old value....
Assume, that first comes thread0.write(0) - with no overlapping. Basically, one can say using Lamports definition that thread1 can read first 1 and then 0 again, if both reads are consequent and overlap with thread0.write(1). But how is that possible?
Reads and writes to a shared memory location take a finite period of time, so they may either overlap, or be completely distinct.
e.g.
Thread 1: wwwww wwwww
Thread 2: rrrrr rrrrr
Thread 3: rrrrr rrrrr
The first read from thread 2 overlaps with the first write from thread 1, whilst the second read and second write do not overlap. In thread 3, both reads overlap the first write.
A safe register is only safe as far as reads that do not overlap writes. If a read does not overlap any writes then it must read the value written by the most recent write. Otherwise it may return any value that the register may hold. So, in thread 2, the second read must return the value written by the second write, but the first read can return any valid value.
A regular register adds the additional guarantee that if a read overlaps with a write then it will either read the old value or the new one, but multiple reads that overlap the write do not have to agree on which, and the value may appear to "flicker" back and forth. This means that two reads from the same thread (such as in thread 3 above) that both overlap the write may appear "out of order": the earlier read returning the new value, and the later returning the old value.
An atomic register guarantees that the reads and writes appears to happen at a single point in time. Readers that act at a point before that point will all read the old value and readers that act after that point will all read the new value. In particular, if two reads from the same thread overlap a write then the later read cannot return the old value if the earlier read returns the new one. Atomic registers are linearizable.
The Art of Multiprocessor Programming by Maurice Herlihy and Nir Shavit gives a good description, along with examples and use cases.