## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
• Create your own community
##### Activity
• Feb 28 2019 19:45
• Feb 17 2019 00:56
• Apr 09 2018 04:14
• Oct 21 2017 19:12
@Arachnid banned @Musk11
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
[Vitalik Buterin] when the tx count was going up to 1.4m
[Vitalik Buterin] and on all of those days, the tx count was very high
Peter (bitfly)
@peterbitfly
yes, all those dots are from that period
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] there you go
Peter (bitfly)
@peterbitfly
for me it is strange that the uncle rate varies between 20% and 40% at the same gas usage / day
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] that's not strange at all; it happens because when it's 20% it
[Vitalik Buterin] that's not strange at all; it happens because when it's 20% it's gas usage that's not transaction-heavy, and when it's 40% it's all transactions