DEBUG 2020-09-14 16:07:39,822 BeamDownloader beam-sync: all=1237 urgent=965 crit=100% pred=162 all/sec=13 urgent/sec=10 urg_reqs=14 pred_reqs=10 timeouts=6 u_pend=0 u_prog=4 p_pend=0 p_prog=61 p_wait=15 p_woke=0 p_found=44 thread_Q=20+3 DEBUG 2020-09-14 16:07:49,824 BeamDownloader beam-sync: all=1503 urgent=1172 crit=111% pred=173 all/sec=14 urgent/sec=11 urg_reqs=218 pred_reqs=14 timeouts=6 u_pend=0 u_prog=1 p_pend=0 p_prog=5 p_wait=7 p_woke=11 p_found=0 thread_Q=20+1
evm_extensionsand the performance difference between using different
uintsizes. I would look into whether we can do something that is optimized for uint64 for things like tracking amount of gas used, memory sizes, etc. There are a lot of places in the EVM that never reasonably go above uint64. If it is possible for us to do simple bounds checking and fall back to the pure python implementation or something similar.... There is an EIP somewhere authored by ?axic? which changes the EVM rules to bound certain values to the uint64 range which might be worth looking into as well.
CodeStreamis a better target to focus on.
PYTHONWARNINGS=ignorefor a bit, but I will shut it off on the next run to see what's up. The shutdown seems to have been dirty recently, generally, but I haven't noticed "Task was destroyed but it is pending" in particular
I followed the cookbook:
and I want to start with just syncing the latest blocks. I tried both syncing from an Etherscan checkpoint, and also manually entering block details.
However, the process dies with:
eth.exceptions.HeaderNotFound: No canonical header for block number #10770396
Do I need to download headers first?
I tried this,
trinity --sync-from-checkpoint eth://block/byetherscan/latest
trinity --sync-from-checkpoint eth://block/byhash/0xc3ed3755bbd4322a7949687558bf027ff6467a048d58830018b269908d937fba?score=17,431,128,075,868,796,124,802
Earlier today, both failed with the above error after a few minutes. I tried both now, and it looks it is fine and the Beam protocol is running. Odd.
<Christoph Burgdorf (cburgdorf)> Yep, that looks good. For
eth://block/byetherscan/latest to work you need to have a token for their API. I think the error you ran into is this one:
This also explains why it is working now. Basically, we need to reject checkpoints that are too close to the tip but right now we just crash with this not very user friendly error message.