Due to advances in blockchain research, it was shown that significantly lower block times were possible and perhaps beneficial given the current connectivity of the internet. One of the potential risks of a low block time is a higher rate of orphaned blocks (competing blocks that do not make it into the main chain). To counter this, a GHOST protocol is used ...
A block mined by a miner that sets their computer time ahead of the current "real" time will have their winning block rejected by other Ethereum nodes. Other miners on the Ethereum network will continue mining on the latest valid block.
According to the code, from Github - Go Ethereum - consensus/ethash/consensus.go, lines 220-284:
The block number will always be correct by definition: It's number x in the chain, because it's chained on top of x-1.
However, as you say block.timestamp can be gamed a little bit - or with the cooperation of the economic majority of validating nodes a lot - which also means that the relationship of block.number to actual time can be gamed. So if you don't ...
Somewhere between 2s and 7.5s, depending on what tradeoffs we choose between maximizing speed and minimizing consensus overhead.
One of the important philosophical points imo is that very high consensus overhead is actually not that bad provided that (i) it's constant and not per-transaction, and (ii) light clients do not have to bear it; for example, even ...
PoA in Aura consensus engine of parity defaults to 5s, which has been tested to run with good stability. PoA network runs one such infrastructure.
I have tested for a 1 sec PoA using aura running across 4 different geographical regions. This is the minimum possible and one that I have successfully tested :) Stability testing across more regions is still in ...
If a miner M sees a block B with a timestamp far in the future, here's what they would probably do: instead of building on B, they would publish their own block C with a more accurate timestamp. By doing this, M is likely to get rewarded since others will likely build upon C instead of B.
As mentioned in the question, to build upon block B, a miner, such ...
First of all it seems that I am too ignorant to understand Poissons Lamda!
At least I have some R skills left:
Min. 1st Qu. Median Mean 3rd Qu. Max.
1.00 5.00 10.00 14.35 19.00 155.00
Interpretation: if you take the mean and forget the stupid outliers we count with only 10 s block time!
The good news: 99% blocks are under 1 ...
If you are using geth here's a patch that I use to accelerate mining. You could probably modify it to decelerate mining if you wish. (I'm curious why you wish to go slower). In any event, I think the answer to "how does the interval for mining get set" is "not very clear from the code"... but this patch should give you a head start in understanding the ...
This was the Difficulty Bomb, originally put in place in the lead up to Proof of Stake being implemented. The aim was to make mining gradually more difficult before the switchover.
See: What is the "difficulty bomb" and what is the goal of it?
As part of EIP-669, the Difficulty Bomb was delayed, which is why your graph returns to normal levels.
This is due to the Ethereum 'Ice Age' - an incentive implemented in the code to switch from the current Proof of Work consensus mechanism to a Proof of Stake consensus mechanism or as Vitalik puts it to "prevent protocol stagnation".
From a Tweet Vitalk made:
It's basically impossible to guarantee a transaction occurs in a given block. There's too many factors--network latency, the block gas limit, uncles, miners who mine empty blocks, other transactions, etc. Chances are, by the time you're actually looking at block X, it's too late to get in block X+1, since a miner may have already decided what transactions to ...
Miners pick up transactions by their gas cost. You can set gas price (not maximum gas limit) for your transaction. Take the default gas price value and multiple it with 2x - 3x for urgent transactions.
I think the answer is basically latency, plus giving enough of the nodes enough of a reasonable amount of time to validate. Millisecond blocks would only really get responses from a minority of nodes, it depends on how much of a consensus you want to build. Millisecond blocks would likely not allow for enough time for a majority consensus to form.
All smart contract functions calls as well as smart contract deployments are inherently transactions. Each transaction gets incorporated into a block whenever a miner chooses to do so. Currently in the public Ethereum main chain, most transactions get incorporated into the next block right away (in contrast to the Bitcoin blockchain). However, if things do ...
Theoretically, yes, code execution time is limited by the block time.
But on a practical level, gas costs and the block gas limit are what limit code execution time. Try writing a contract that takes many milliseconds and you will probably find that you have exceeded the block gas limit.
FYI the average block time is 15 seconds. Whisper is the messaging ...
Currently the average blocktime is ~ 14 s where a significant portion is just ~ 1 s. See my empirical asssesment here: https://github.com/rolandkofler/blocktime
If you run your private net you can change the blocktime or difficulty algorithm, but if you have only two nodes it should be rather fast anyway so I wonder if your setup has problems.
If you run ...
One thing to consider would be the orphan rate, which is alluded to in the comments for the thread you linked to.
The lower you set the difficulty, the shorter the block time, which is what you're aiming for.
However, the lower the difficulty, the greater the chance of multiple miners solving the block at the same time, and the chain forking. This ...
WARNING: This does not take into account the difficulty adjustments that arise when blocks are off the average block time. This means that in reality the standard deviation of multiple confirmations will not increase so much.
How about a Monte Carlo Simulation?
The Result is: The distribution of confirmation times gains high variability when you wait for ...
It is actually quite easy to edit the source code for geth to do what you want.
Simply comment out the body of CalcDifficulty (line 265 in core/block_validator.go) and replace it with
Then set the difficulty in the genesis block file.
be it a PoA, PoW or PoS chain you want to build, the main point about the timing is for your nodes to be able to synchronize.
If your network is private and you can ensure your network to have nodes with huge broadband and resources then you can decrease largely the blocktime.
It all depends on the infrastructure your network relies on. If your different ...
Currently the block time is around 17s
The average is currently between 14 and 15 seconds.
but the confirmation time is even longer around 2-3 minutes.
That depends on the gas price you're willing to pay, and the current state of the gas price market. Have a play with the "Gas-Time-Price Estimator" on ETH Gas Station to see how the average transaction ...
Average Ethereum blocktime is closer to 15 seconds.
The reason blockchains generaly have larger block times is due to uncle rates. When 2 miners mine separate blocks at the same height, the network has to decide which one is correct. Both will generally be mined on, until one gets longer. These uncles aren't included in most blockchains and the miners aren'...
The use of block.timestamp (which is what now is an alias of) is often discouraged because it is somewhat manipulable by miners. This is only an issue if you need the time to be precise to within ~90 seconds, if you care about longer time scales where precise timing is unimportant then now is perfectly fine.
To supplement this with Vitalik's answer on Gitter (quoted):
Rewarding ommer blocks means miners have lesser incentive to mine on the latest block:
basically means that miners' private incentive to make relaying
super-fast is ~3-4x lower than it normally would be this is by design,
to limit centralization concerns
Ethereum is computation-heavy. IO ...
Currently, difficulty is computed as:
adj_factor = max(1 - ((timestamp - parent.timestamp) // 10), -99)
child_diff = int(max(parent.difficulty + (parent.difficulty // BLOCK_DIFF_FACTOR) * adj_factor, min(parent.difficulty, MIN_DIFF)))
As you can see, there is nothing about gas in the formulas.
A Metropolis EIP to adjust the difficulty also does not ...
Current block number is 4154921, not 710908. The original design of 12 seconds (now more due to difficulty adjustment) was first chosen and research suggested that 12.6 seconds, but actually average is 15 seconds. So if using 15s computing, the result is:
4154921 * 15 / 3600 / 24 = 721.34days. you can find the genesis block , and timestamp formatted is 745 ...
Yes, of course. Both block timestamp and block number are equally reliable. There is an entire alarm clock system built in ethereum for executing something at a later stage. For more info on that you can even have a look at How can a contract run itself at a later time?
An ERC20 token is just an Ethereum smart contract. Any operation with tokens is a transaction which must be confirmed by the Ethereum network, just as any other transaction. Assuming that the fee is sufficient and the network is not overloaded (which sometimes happens during large ICOs), transactions are confirmed within a minute (an average block time at ...