ethereum/EIPs#877
It’s proposing a simpler way to get contracts to pay their own gas, or tokens transacgtions to be paid in tokens themselves
I adapted now my analysis of the uncle rate vs. tx numbers & gas usage to exclude all failed transactions as suggested by @karalabe and @holiman. The results are available at https://imgur.com/a/jMYYi . Still there is a good correlation between the uncle rate and the total amount of tx processed, but even after excluding all failed transactions there is no visible correlation between the amount of processed gas and the uncle rate.
Failed tx were identfied using the parity tracing API
@ppratscher Great analysis, I like it. It might suggest that each transaction has a fixed cost that translated to the uncle rates, regardless of what it does. And as a result, the gas cost of making a transaction (21000 gas currently) might be underpriced relative to other things
During attacks ,when block processing reached 5s-levels, uncle rate increased.
But maybe it's negligible while in subsecond range
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)
[Vitalik Buterin] it feels to me like the contribution from tx count is quite high but that seems.... so weird
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.
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
[Vitalik Buterin] would be good to construct once
[Vitalik Buterin] so we can then use it for analysis
[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
[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
[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
Well, unless you want to correlate certain opcodes with uncle-rate, which I guess is possible, but probably pretty spotty
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
[Vitalik Buterin] even 100 blocks
[Vitalik Buterin] and assume uncles have similar transactions in them
[Vitalik Buterin] to blocks around the same time