Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Martin Holst Swende
@holiman
Well, obviously latency will impact uncle rate, the q is how large degree block processing adds to the 'natural' latency caused by e.g block size, right?
During attacks ,when block processing reached 5s-levels, uncle rate increased.
But maybe it's negligible while in subsecond range
Peter (bitfly)
@peterbitfly
It looks like that. This would mean that a dedicated block relay network for miners would help in decreasing the uncle rate
ledgerwatch
@AlexeyAkhunov
This paper (you probably have seen it): http://hackingdistributed.com/2018/01/15/decentralization-bitcoin-ethereum/ estimates Ethereum's median peer to peer latency as 152 ms (table in the chapter 4.2 - network structure)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] I'd like to see a multidimensional linear regression getting coefficients for uncle rate from (i) gas, (ii) tx count, (iii) block size
[Vitalik Buterin] it feels to me like the contribution from tx count is quite high but that seems.... so weird
Martin Holst Swende
@holiman

One thing I've been pondering... Has anyone considered doing a multidimensional benchmark? Essentially the following:

  • Record block processing times for N blocks (N might be e.g. 1000)
  • For each of those blocks, create a distribution of the op-count for each opcode.
  • Correlate/estimate the times for each opcode.

In theory, I think this could be written as a large polynom, but in practice since opcode processing varies, the method needs to be based on estimation finding the best match.

Peter (bitfly)
@peterbitfly
I have added the correlation with the block size, it looks kind of similar to the one with the tx count https://imgur.com/a/HlJdP
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] can someone construct the data for this?
[Vitalik Buterin] would be good to construct once
[Vitalik Buterin] so we can then use it for analysis
Martin Holst Swende
@holiman
@ppratscher I wonder how you measure 'uncle-rate' here.. Does it mean "the chance that this block will become non-canonical", or does it measure the "uncle-rate" in a more general manner?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] so if it's a regression analysis the y value would be "1 if this block is an uncle and 0 if it's not"
[Vitalik Buterin] though there are two ways to do it
[Vitalik Buterin] one way is that
[Vitalik Buterin] the other way is to look at periods of, say, 100 blocks
[Vitalik Buterin] if you're going to do correlation analyses then only the latter really makes sense
[Vitalik Buterin] because the correlations with "1 if this block is an uncle and 0 if it's not" are going to be low
Martin Holst Swende
@holiman
@vbuterin when you said "can someone construct the data for this?" -- which 'this' did you mean?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] for each block (including uncle), get: total gas used, gas used not including burned from reverts, tx count, block size, number of times each opcode is used, 1 if uncle else 0
[Vitalik Buterin] just make a table out of that in some nice format (eg. CSV or JSON)
[Vitalik Buterin] so we can do whatever analysis on it
Martin Holst Swende
@holiman
@ppratscher -- do you already have that data, or can extract it from whatever tooling you've used already? And @vbuterin, what can "number of times each opcode is used" be used for without block processing time too?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] ah, we could use block processing time
[Vitalik Buterin] but that might differ between nodes
[Vitalik Buterin] there might be some weird reason why some opcode is problematic that block processing time doesn't catch
[Vitalik Buterin] particularly thinking IO, which may well have wildly differing execution times between nodes
Martin Holst Swende
@holiman
Yup, definitely. But then "number of times each opcode is used" probably isn't worthwhile either (?)
Well, unless you want to correlate certain opcodes with uncle-rate, which I guess is possible, but probably pretty spotty
Peter (bitfly)
@peterbitfly
@holiman it is the actual uncle rate of the network on a given day (uncles / (blocks + uncles))
sorry but right now I don't record the opcode frequency for each transaction, also I don't think it is possible to get "gas used not includeing burned from reverts" from uncles as uncles do not include the transactions that were included in the uncle block
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] I think higher granularity than day is better
[Vitalik Buterin] even 100 blocks
Peter (bitfly)
@peterbitfly
as only the block header of the uncle block is included in the block that includes the uncle
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] so what you can do is look at those stats for regular blocks
[Vitalik Buterin] and assume uncles have similar transactions in them
[Vitalik Buterin] to blocks around the same time
Peter (bitfly)
@peterbitfly
yes, but I only have it aggregated to daily values
Peter (bitfly)
@peterbitfly
I have extended the charts to the full year 2017 https://imgur.com/a/yyzp5
it is interresting that there is in fact a strong correlation between uncle rate and total gas usage up to the point of 35G gas / day then things start to go sideways
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] 35G per day is about 6m per block
[Vitalik Buterin] aaah
[Vitalik Buterin] so that sideways component should be the dos attacks
Peter (bitfly)
@peterbitfly
no, those attacks were in 2016, the data is from 2017
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] see which of those dots correspond to dates between sep 19 and oct 16
[Vitalik Buterin] aaah right
[Vitalik Buterin] hmm
[Vitalik Buterin] ok, my next hypothesis is that those dots correspond to dates in december