Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

ethereum/py-evm

People

Repo info

Activity

Jan 11 09:15

cburgdorf commented #1966
Jan 08 16:40

montsamu opened #1966
Jan 05 22:33

carver on master

Issue #1942 remove linting erro… (compare)
Jan 05 22:33

carver closed #1964
Jan 05 20:59

Elnaril commented #1964
Jan 05 20:58

Elnaril synchronize #1964
Jan 05 20:49

carver commented #1964
Jan 05 20:46

carver commented #1964
Jan 05 19:39

Elnaril commented #1964
Jan 05 19:34

Elnaril commented #1964
Jan 05 19:32

Elnaril commented #1964
Jan 05 19:24

Elnaril commented #1964
Jan 05 19:20

carver commented #1964
Jan 05 19:03

Elnaril commented #1964
Dec 18 2020 16:37

Elnaril commented #1964
Dec 03 2020 08:20

gsalgado commented #1965
Nov 28 2020 07:58

gsalgado opened #1965
Nov 19 2020 16:08

Elnaril opened #1964
Nov 18 2020 18:04

Elnaril commented #1942
Nov 17 2020 09:06

Peppece commented #1937

Jason Carver

@carver

Cool, thanks for reporting. Have you filed an issue yet? If you tag me on it, I'll be sure to take a look today

Voith Mascarenhas

@voith

@fubuloubu @carver Why is the istanbul fork inheriting everything from Constantinople and not Peterburg? IIUC, Petersberg is the fixed version of Constantinople. So shouldn’t Istanbul inherit from Peterburg? Am I missing something?

ethereum/py-evm@8cfe336

Nick Savers

@nicksavers

Agreed

Voith Mascarenhas

@voith

*Petersburg (lol, I have some really bad typos there)

Jason Carver

@carver

Yup, that's a bug

Just some guy

@fubuloubu

I think I made it before Petersburg

Jason Carver

@carver

We should update it, but I don't think it changes anything in practice, since sstore gets redefined, and that was the only change in Petersburg, iirc

Voith Mascarenhas

@voith

@carver I just checked. Tests are failing. Looks likes sstore changes were to Constantinople rather than Petersburg.

Voith Mascarenhas

@voith

Oops, I spoke too fast. EIP1283 was removed in Petersburg. So the tests are broken IMO. Lets see

Voith Mascarenhas

@voith

Tests are correct. I had to re-enable allow_negative_refund_strategy for Istanbul

Voith Mascarenhas

@voith

fixed ethereum/py-evm#1842

Voith Mascarenhas

@voith

I got py-evm to pass all ethereum/tests for Istanbul locally. However, tests are crashing on CircleCI. Details for the test failure are here: https://github.com/ethereum/py-evm/pull/1852#issuecomment-533900250

Noel Maersk

@veox

@voith Sorry I can't help better with PR #1852 ATM. I made some bad choices y-day, and ended up with a hangover.

But from the failing test names, it looks like the same bunch as already in INCORRECT_UPSTREAM_TESTS.

There's still the disconnect between py-evm and all other implementations - including parity-ethereum, which caved in and did it like go-ethereum does.

The particular issue is not covered in any EIP, and is about a "synthetic" state of a contract that can't be arrived to by regular EVM operation.

Noel Maersk

@veox

So, perhaps add the _Istanbulvariants of InitCollision et. al. to INCORRECT_UPSTREAM_TESTS, and see what actual issues remain.

Voith Mascarenhas

@voith

I made some bad choices y-day, and ended up with a hangover.

Haha, hope it was good :D

@veox Thank you for your help

I have some free time now and I will dig into the tests just to double check that these tests are in fact incorrect.

irenemae

@irenemae

@cburgdorf hi everyone!!!newbie here:)

Dimitri Saingre

@Prygan

Hi everyone :) does anyone knows here if it is possible to read the leveldb chain data generated by geth from python with py-evm ?

Jason Carver

@carver

I know it's possible to read state data out of the geth leveldb store, but can't natively read out chain data. It would be reasonable to write an adapter, if you're interested in a project :)

Jason Carver

@carver

eth-tester with istanbul support is out: v0.2.0-beta.3 @/all

Noel Maersk

@veox

@voith I'm taking a look at PR #1852, if you don't mind. Not even past the "run successfully locally" step yet: the fixtures take too long, SLOWEST_TESTS is unpopulated with static_Call50000 (and family) for Istanbul, and on some test (don't know the name yet, because I first ran it in tox) it just hangs... Might be GeneralStateTests/stTimeConsuming/CALLBlake2f_MaxRounds.json, will see.

Voith Mascarenhas

@voith

@veox Please feel free to take it over. I won’t be able to look at it before Devcon

Noel Maersk

@veox

(Plus, Python 3.6 (as in PR) is slow IIRC.)

Voith Mascarenhas

@voith

Blake2f implementation in python is not very efficient and its expected to be slow. But need to find out which tests needed to be marked as slow

Noel Maersk

@veox

Yup, that's what I'll be doing first. I'm assuming stTimeConsuming will all be there.

Voith Mascarenhas

@voith

yeah seems reasonable. There’s a test called CALLBlake2f_MaxRounds_d0g0v0_Istanbul which has high possibility of running extremely slow.

Just learnt that the old blake2b library has been replaced by a better performing one:
ethereum/py-evm#1854.
But the tests will still need to be marked slow

Jason Carver

@carver

@veox that faster blake2b implementation is in a newer release of py-evm. I highly recommend upgrading to that as part of the branch

Noel Maersk

@veox

@carver Thanks, didn't notice.

Jason Carver

@carver

:+1:

Noel Maersk

@veox

Test passes, but still takes minutes. Will re-visit SLOWEST_TESTS list later (files have changed names). (94.68s call says CircleCI.)

Voith Mascarenhas

@voith

Yeah, some tests were moved to LegacyTests

Voith Mascarenhas

@voith

@veox Ethereum tests has a new release for istanbul: https://github.com/ethereum/tests/releases/tag/v7.0.0-beta.1

Noel Maersk

@veox

It's the cursed RIPEMD160 precompile again: https://github.com/ethereum/py-evm/issues/1857#issuecomment-538433394

We do try to catch this: https://github.com/ethereum/py-evm/blob/master/eth/vm/forks/spurious_dragon/_utils.py#L46-L50

... but it seems that geth is not as stringent as py-evm on when this should happen. We only do it if computation.is_origin_computation.

Noel Maersk

@veox

Not 100% sure this is the culprit, though - still looking...

Noel Maersk

@veox

Yup, that's it. yield THREE (unconditional) passes the test. So, just need to cherry-pick the conditions, so that other tests don't all fail...

Noel Maersk

@veox

OK, I can't figure out how to do this without a double-pass through the nested computations, or ugly hacks - not today, at least, and got to run anyway.

I liked it more when aleth was filling the tests. :/

Summary of noise: https://github.com/ethereum/py-evm/issues/1857#issuecomment-538460472

Tan

@tanmaster

hi, i kinda feel stupid for asking this, but is there a way to set the code of an address with vm.state.setCode() and then persist it without getting a validation error when mining the block?

Tan

@tanmaster

nevermind, i solved it: i extended the IstanbulVM class and the MiningChain class, overrid mine_block in both and commented out the lines in which the validation happens.

Voith Mascarenhas

@voith

@veox nice work! With my current knowledge it would have taken me ages to figure that out 😅

Noel Maersk

@veox

veox/py-evm@6c6db73 - supposed fix (for 4 of 6 failures).

Noel Maersk

@veox

I'm relatively certain that the branch will now pass all the tests (i.e. fixed the remaining 2).