I can confirm to make it on 17th (but cannot confirm 18th), and I want to add EIP-1712 to the list. It’s a relatively simple one and related to our immutability/invariant discussions. A current benefit is in inter-blockchain / private-chain setup, where it can prevent someone accidentally deploy a contract to a chain that is incompatible. This is something I’ve heard a lot of complaints of.
1 Like
Great, thank you. Will make sure to schedule for the 17th.
Andrew Ashikhmin will make a presentation about his Red Queen Sync protocol. This is currently under State rent working group, but we might want to split it up to another working group.
I would also like to launch another working group related to the use of beacon chain as a finality gadget for Ethereum 1x
2 Likes
Great, thanks for the update.
Yes there is a lot of excitement about this for sure.
I will be in Korea on those dates, but I’ll be remotely presenting on:
- EIP 152: the Blake2 precompile
- Introducing an optional process reducing the necessary labour from by our fine EIP maintainers using OASIS Open Projects.
2 Likes
Great. Just started on getting a schedule together with @tvanepps – will need to make sure we can schedule at a time that isn’t too bad for you. Hmmm Korea is +8 hours ahead of Central Europe. OK, so you could do a morning Europe time slot and it wouldn’t be too late, even 11am is only 7pm in Korea. Let us know if certain times on 17th or 18th are better / worse.
Thinking we can maybe talk about all the precompiles together, as there are some related questions about this. Having spoken to some core client devs
Can you say more about OASIS and what you mean? Do you want a separate slot to discuss that?
(hope its okay to bring this up on this thread; if not, I will create a new thread) Does anyone need a roommate while in Berlin? If so, DM me on twitter => twitter.com/owocki
I noticed other than the Red Queen Sync protocol there isn’t much on the table for whatever would make up Eth/64 (Forming a Ring: ETH v64 Wire Protocol Ring). Do we want to add that to the agenda? Perhaps @matthalp could do a remote presentation?
1 Like
My understanding is that are currently three sync proposals/prototypes (1. fast warp 2. red queen 3. fire hose) under development where either one or some combination will be selected to be the new syncing paradigm.
There are about ten other ETH v64 proposals that have been on standby while the sync proposals progress. They are mostly simple in nature and do not seem too contentious, but now is probably a time to get the to a more mature state.
As a step towards that I’m happy to present these proposals to educate and help get buy in from the community. If this is something everyone else would be interested all I ask is that I can get a reasonable time slot to present since I’m in the Pacific time zone.
3 Likes
@tvanepps can help you get scheduling sorted. Morning in PST around 7am should be doable.
I’m based in PST normally AKA the worst time zone, so I feel your pain 
Great to hear @matthalp.
If you could fill this form out it will help me stay organised. Mention your timezone as well:
Thanks!
Besides EIP-1712, I’ll also give an overview of all of our current account versioning options. This includes EIP-1702/#154, EIP-1707 and EIP-1891.
1 Like
Any updates on livestream information?
Also, could you post what the hashtag will be? Good luck with the sessions, and thanks!
#coredevsberlin — we’ll use that here too to tag posts.
1 Like
Prepared statements for the ETH Istanbul magicians meetings
Today I am in air transit with a yet undetermined schedule, so in the event I am unable to speak live on my request for the precompile, I have prepared these notes.
Special Projects wishes greater Ethereum interopability with Zcash, IPFS, and Handshake. Coincidentally, all of these projects use the Blake2 hash function. So, this is our official request to add the Blake2b
Fprecompile to the Istanbul hardfork. The first special project here will probably be creating a wrapped ZEC (WZEC) within Ethereum as well as wrapped Ether within Zcash. After that, some yet-to-be-determined bridge architecture will allow Ethereum to benefit from Zcash’s shielded transactions.If there’s an issue of funding to get this over the finish line, I will personally cover the expenses.
That’s it really. Send questions to virgil@ethereum.org.
Prepared statements for the Istanbul magicians meetings
Today I am in air transit with a yet undetermined schedule, so in the event I am unable to speak live on my introduction of the “EIP OASIS plan”, I have prepared these notes.
My original proposal (approved by EF management) for an experimental EIP/ERC-approval process running in parallel to the existing EIP process is here: https://notes.ethereum.org/rkFOS_WLV
You can see the majority of the context there. Use of the experimental OASIS-EIP process is entirely optional. If maintainers prefer, they can keep with the same system. If, after 18 months, it is deemed that the OASIS-EIP process isn’t much better than our current one, we will discontinue the experiment and return to single-process system we use now. If, after 18 months, it’s determined that the OASIS-EIP process is a notable improvement, we can discuss making OASIS-EIP the sole EIP/ERC-approval process.
After deciding that becoming an IETF working group would generate more problems than solutions, Ethereum Foundation decided to go with OASIS as OASIS is one of the few organizations that, rather than enforce gate-keeping (like IETF, ISO, etc), OASIS uses their standards specialists as shepherds and referees to bring out the best in your standards.
Project Governing Board (PGB)
Some have asked how the initial Project Governance Board was decided. I don’t consider any of the picks to be controversial, but here’s the reasoning for each initial member:
* Ethereum Foundation - Would be bizarre to not have EF represented. I, Virgil Griffith, will be the initial EF representative, but I hope to abdicate this role as soon as possible.
* Consensys - With the exception of EF, Consensys employees have authored more EIPs than any other org. We wish to reward this behavior.
* Ethereum Enterprise Alliance - Although coming from the more corporate world, the EEA has a lot of standards experience and expertise. It seems sensible to leverage this experience. Additionally, having EEA more involved in Ethereum EIPs will improve their ability to keep their own EEA standards compatible and up to date with ours.
* Nick Johnson - Nick has been the primary steward of the EIP process for sometime. The goal is for him is to represent the values of the existing pre-OASIS process and overall be a voice of “the people” within the PGB.
As there are an even number of PGB members, if there is a tie, OASIS referees will cast the tie-breaking vote.
Technical Steering Committee (TSC)
One pleasant change in this process is that, whereas the Magicians EIP Ring was before merely the unofficial custodian of the EIP process, in the OASIS process the EIP Ring becomes the Technical Steering Committee, which has official, specific powers. This enshrines the Magicians (or at least the EIP Ring) with official standing. I have complete confidence in the Magicians for rising to the challenge of wielding these new powers.
The person to field all OASIS-related questions to is Jory Burson jory.burson@oasis-open.org.
Copied to separate thread