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 ...
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 ...
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 ...
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:
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 ...
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.
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.
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.
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 ...
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'...
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 ...
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.
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.
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 ...
Ethfinex just published a function that does exactly that.
It's to "pixel perfect" but it's working really well so far, you give it a timestamp and it will walk the blockchain backwards until it finds a block that is very close.
During my tests it always found the nearest block, you might need to tweak it a little bit more.
In addition to goodvibration's answer, OpenZeppelin recently released their openzeppelin-test-helpers package. This library contains all kinds of helpers for testing smart contracts, including methods to increase the block number or timestamp, such as:
I haven't used the ...
The 15s block time is false assumption, making your question invalid. Ethereum was ticking 12s block times 2 years ago. It is not standard and fluctuates a lot of over longer period of time.
You should not connect time based conditions to block numbers.
The community likes to use exact things like "block numbers" which cannot be tampered with by the miners.
The now / block.timestamp can be manipulated by the miner to a certain degree as it relies on the machine's time that actually found the block, and that's why the linter is telling you not to use it.
If you're not using that time for really important ...