Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Alexander
@shamatar
@Souptacular I can not find him by handle in this chat, so contact would be appreciated
Tim Beiko
@timbeiko
@madeoftin
Alexander
@shamatar
Ok, thank you!
James Hancock
@MadeofTin
@shamatar @axic
I put thursday as a placeholder until a time is settled. Does the normal 16:00 UTC work for you? I’ll wait for some thumbs-up before settling the time.
@holiman
Please tag anyone who you think would like to join. I can add you to the call invite list.
James Hancock
@MadeofTin
Updated to friday re Axic suggestion
Alexander
@shamatar
@karalabe Peter, do you have any idea for a large performance difference between Go and Rust for keccak256? I’ve seen your contribution to the Golang repo and may be you have some ideas?
Martin Holst Swende
@holiman
@shamatar are you talking about the keccak256 precompile? I did some benchmarking yesterday. https://gist.github.com/holiman/9b65aa58495b48b6cffa785eda906fff . The parity number is from an older benchmark. They're very much in the same league
If they're a lot faster now, it must be some optimization parity has done in the last 2 years
Martin Holst Swende
@holiman
Even your spreadsheet ( which I have a bit of trouble understanding) seems to indicate that rust/go is roughly equivalent?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Péter Szilágyi (karalabe)> @shamatar: nope
<Péter Szilágyi (karalabe)> Our keccak256 is the official asm code, I just ported it over to GOASM
<Péter Szilágyi (karalabe)> I'd guess it should be the same spede wise as rust asm
<Péter Szilágyi (karalabe)> Can't imagine either being noticably faster if both are pure asm
Alexander
@shamatar
Spreadsheet’s tabs just list gas spent for hashing using Rust and Go implementations for different input length, that are then fitted with linear function using updated block size of the hash function. Parameters that are interesting are slope and intercept
I’ll check the spreadsheet once again anyway
Alexander
@shamatar
I went through my data and looks like slope and intercept values were swapped. Now per-length contribution is the same for Keccak256 in Rust in Go (they still differ quite a lot for SHA256 and RIPEMD, but it's a separate issue). Larger problem is a constant part of Keccak256 call (independent of length) that is quite large in Go (most likely due to an extra memory allocation or copy) and it makes hashing on small inputs twice more expensive compared to Rust
matkt
@matkt
Do we agree that this is the final version of the EIP 2315 for the ephemeral testnet https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2315.md (e8accf22cdc5562d6982c560080c6cd6b7f94867)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<poojaranjan19> The next EIPIP meeting is tomorrow, Wednesday, June 3, 2020, at 15:00 UTC.
Agenda: ethereum-cat-herders/EIPIP#16, feel free to add more items.
Martin Holst Swende
@holiman
@matkt we merged that one into geth today, will make a yolo-1 release soonish
James Hancock
@MadeofTin
@gcolvin can you confirm that is the version? I can add the commit hash to the Yolo spec
Péter Szilágyi
@karalabe

Yolo V1 testnet is up and running https://yolonet.xyz/

  • Support is baked into Geth master branch via --yolov1
  • Genesis config json is at https://yolonet.xyz/yolo.json
  • EF bootnode at enode://9e1096aa59862a6f164994cb5cb16f5124d6c992cdbf4535ff7dea43ea1512afe5448dca9df1b7ab0726129603f1a3336b631e4d7a1a44c94daddd03241587f9@35.178.210.161:30303
  • There is one Geth signer only, I don't think it makes sense to complicate things with more signers
  • Stats page secret is YOLOv1, with geth you can --ethstats='yournode:YOLOv1@stats.yolonet.xyz'
  • Faucet is unauthenticated, you can reach it from the dashboard
  • Will try to deploy a blockscout too, but don't get your hopes up

Everything's running from one machine, so hope it doesn't choke. If it does, sorry, we can fix it.

Péter Szilágyi
@karalabe
Ok, deployed a blockscout too, it kind of maybe sometimes looks as if it's trying to attempt to make an effort to possibly but not probably work
Péter Szilágyi
@karalabe
Btw, if anyone very strongly believes we need more signers, maybe from different clients on the network, I have no issue in voting more in. It just seemed simpler to have one and run with it. I do see the issue if Geth turns out to not be implemented correctly and the chain diverges off on an invalid fork. I just don't want things stuck.
Regarding funds for testing, the faucet is not authenticated, so you can just make a new account and request funds for it. I think this is a reasonable compromise, but if any client team wants to have their own big stash for whatever reason, just ping me and I'll send however much you want.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<poojaranjan19> Reminder: EIPIP meeting in ~45 mins
Agenda: ethereum-cat-herders/EIPIP#16
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
Alexander
@shamatar
Is there an estimate for OpenEthereum and other clients to join the testnet?
Alexander
@shamatar
Also looks like EIPs repo CI is dead
James Hancock
@MadeofTin
:clap: :clap: :clap: Re:yolo
James Hancock
@MadeofTin

Also looks like EIPs repo CI is dead

Where can I check this @shamatar

Alexander
@shamatar

Also looks like EIPs repo CI is dead

Where can I check this @shamatar

I just see that on my PRs updated few hours ago there is no report from CI

Alex Beregszaszi
@axic
You just need to rebase/merge master as CI is working on master.
Alexander
@shamatar
One of the PRs is indeed updated by merging ethereum/master into local branch, but there is no report on it too (2666)
Artem Vorotnikov
@vorot93
I've written the chainspec today, should be good to go after we finish reviewing the EIP PRs
we're on track to go live this week I think
Alexander
@shamatar
Just from some manual testing on YOLO: contract that does two storage writes and a call to BLS12_G1_ADD returns gas estimate of 230545 gas. Cost of G1 addition is 600 gas, plus all the overhead should me much smaller that 230k
Alexander
@shamatar
Such behavior persists for all precompile calls that are expected (and do) fail, but they should nevertheless consume the expected gas I think.
For non-failing cost it's around 36k that is close to reality
James Hancock
@MadeofTin
Updated the Ephnet EIP with the most recent information. https://github.com/MadeofTin/EIPs/blob/patch-17/EIPS/eip-2657.md
Alex Beregszaszi
@axic

The EIP says

Prevention of DDoS on error handling
This precompile performs extensive computations and in case of any errors during execution it MUST consume all gas from the the gas schedule for the corresponding operation.

And addition on G1 one says:

Error cases:

Either of points being not on the curve must result in error
Field elements encoding rules apply (obviously)
Input has invalid length

I think your “consume all gas from the gas schedule” is a confusing sentence. All precompiles consume all gas or return an empty output in case of errors. None of them consume all “suggested” gas.

I suggest that you should clarify your EIP.

Alexander
@shamatar
@axic Do you mean that failing call to the precompile with gas = X will consume X and not the precompile price, and it's an an intended design decision?
Alex Beregszaszi
@axic
I think that's how most people interpretered the EIP (as that is the out-of-gas / exception halt conditition described in the Yellow Paper). If you want to deviate from this, then make sure to write it out loud and clear so that people pick it up.
Alexander
@shamatar
Is such behavior even implementable? 2537 implementations do not touch any existing logic of handling an error from precompile, so it was a pre-2537 behavior
Alex Beregszaszi
@axic
There is no “existing logic of handling an error from a precompile”. An EIP describing a precompile is defininig every conditiond and handling.
Alexander
@shamatar
Such behavior does not make any sense anyway. If precompile is properly made and priced it would never consume more CPU cycles than it's expected cost
May be I don't understand something about EVM and how it works, but if I do STATICCALL with a limit of X gas and precompile fails, than at what point all this X amount is burned? Here is an entry point to the precompile (a pure function), and all it does is subtracts precompile cost from gas of the current frame (?) and runs a computation Geth impl