All storage data is lost along the way, and yes, balance too
Therefore, it's fitting that extcodehash becomes active simultaneously as this
Cc @AlexeyAkhunov
@holiman @karalabe I tried to compare progpow verification results with https://github.com/chfast/ethash.
Single Ethash verification with the best currently available compiler is 0.9 ms.
The progpow implementation was done in this fork: https://github.com/ifdefelse/proghash/commit/dc8e918aa5cf68da0b6dc049634bde596170c14c#diff-551b1d6ef147e694c203c6e9a6dacbf7R521 but does not seem to work. At least they did not update the unit tests.
The same benchmark shows absurd 1.3 us.
it does not have data item access from progPow function itself (which contributed 2/3 of all accesses and was not actually present in the "white paper"). Also, access in the progPowLoop has been taken out of the inner loop (which has 32 iterations). Therefore we have factor 3*32 = 96
now it does exactly the same number of accesses as Hashimoto (existing ethash) = 128. And because they use simpler keccak function, it is faster than Hashimoto. Again, no wonders here too
it uses simpler keccak too, that is why maybe it faster. But I would also be sceptical. Also, since the algorithm has been changed so much (judging by the significant change of number of accesses), does it still has claimed ASIC-resistant properties? I did not look at any depth into why it has these properties, because I have a limited understanding of modern ASIC design and manufacturing processes, but I just know that innovation in that space is very fast
@chfast No, I don't know where to find them, sorry
There must be bug in the code as progpow verification should be slower (https://github.com/ethereum/go-ethereum/pull/17731#issuecomment-424519942), not 1000x faster.
"Since transistors are not getting much better (reflecting the end of Moore's Law), the peak power per mm^2 of chip area is increasing (due to the end of Dennard scaling), but the power budget per chip is not increasing (due to electro-migration and mechanical and thermal limits), and chip designers have already played the multi-core card (which is limited by Amdahl's Law), architects now widely believe the only path left for major improvements in performance-energy is domain-specific architectures. They do only a few tasks but do them extremely well".
I am also reading another book, called "Parallel Algorithms and Architectures" by F. Thomson Leighton (superficially for now)
and the intuition that I got from these two sources is that ASICs (or Domain-Specific architectures) can beat GPU not just because they do less things, but also because they can have different computing architectures, like two-dimensional arrays, or meshes, which allow systolic computations instead of GPU model, where all the computation flows through the registers
so it is not that simple
Way back in the mid-1970s I was wanting to emulate portions of the nervous system with physical networks of microprocessors. I was told that any parallel process can be simulated efficiently on a serial computer, and went back to feeding punch cards full of FORTRAN to our mainframe...
@gcolvin Ha-ha :) at that time, I suspect, the Moore's Law was still a thing, so advice you were given totally made sense. But now ASICs and Domain-Specific architectures is the only way. We already see the rise of meta-programming (programs write programs), I guess we will see the rise of meta-programming when programs design hardware, print it, and so on. This should gradually abolish the supremacy of large chip companies (I suspect a lot of their hardware design tooling is implemented in hardware itself)
Reason I am asking is I’d like to merge the PR adding it to the Solidity assembler and having confidence in:
- the opcode number
- the fact that it will be part of constantinople
- (and would be nice to be confident in the associated gas cost)
@holiman @AlexeyAkhunov Here are test vectors for Keccak-f800 from Keccak Code Package: https://github.com/XKCP/XKCP/blob/master/tests/TestVectors/KeccakF-800-IntermediateValues.txt
I am sure it depends on client's implementation. EthereumJ has a gas price threshold for Tx mem pool, Txes with gas prices lower than that threshold just skipped. And there is nothing that would be done with the peer in that case. I think it worth to reduce peer's reputation if it sends tons of spam messages.
@djrtwo I just checked in geth. There is no penalisation. In this "case" clause at the link, you can see that the only place "p" (peer) is still associated with the transaction is the call to p.MarkTransaction(). And inside that MarkTransaction, it only adds tx ID to the set of max 32k transaction that the peer "knows about", so that we do not send them back to the same peer: https://github.com/ethereum/go-ethereum/blob/4b6824e07b1b7c5a2907143b4d122283eadb2474/eth/handler.go#L666
same for parity. I think. In the code under the link, you can see that peer_id is not passed into "import_external_transactions" (this is where txs get to the pool). In the "notify.transaction_received()" no penalisation happens either. https://github.com/paritytech/parity-ethereum/blob/cc963d42a06bcae2480cec657fa4b55a829fdaa6/ethcore/src/client/client.rs#L2099
just to share it around with other PegaSysers and make sure we have all the relevant information for the call
ah
it's this I guess...
If someone whats to review some "crypto" code I sending changes related to ProgPOW here: https://github.com/chfast/ethash/pulls
zoom link to follow
@/all Core devs meeting in a little less than 12 hours
Agenda for meeting: ethereum/pm#58
Videoconference Link: https://zoom.us/j/717504189
We will be having someone who has ran new benchmarks for EIP 1108: Reduce alt_bn128 precompile gas costs.
We will also be having the team behind ProgPoW on the call so we can all sync up with what various people have been doing to test, benchmark, and otherwise explore it.
Please look over EIP 1108 and think of any questions you have for the ProgPoW team.
Trying to get this merged: ethereum/EIPs#1375 . Clarifications regarding Skinny Create2 cc @vbuterin