Skip to content

Commit

Permalink
Merge pull request #205 from edsonayllon/master
Browse files Browse the repository at this point in the history
Add call 95 and 99
  • Loading branch information
Souptacular authored Nov 4, 2020
2 parents 3320656 + ba132b6 commit e05120b
Show file tree
Hide file tree
Showing 12 changed files with 893 additions and 17 deletions.
6 changes: 3 additions & 3 deletions All Core Devs Meetings/Meeting 53.md
Original file line number Diff line number Diff line change
Expand Up @@ -262,10 +262,10 @@ Peter - I propose an alternative. This would change the hard fork because we rem

Proposal→ instead of removing, we define a second hard fork that only removes this code. So even clients would have testnet capabilities. So leave it and then fork it and then have another hard fork that disables this code path. These two hard forks would trigger out the same block number. This allows for a clean upgrade and cleanly disables the EIP without rolling back. This will just take a couple of new tests.

Alexy- I would add that later on when we reset all the testnests then we simply remove the code
Alexey- I would add that later on when we reset all the testnests then we simply remove the code

FJL- You would need to be able to reprocess the time between
Alexy- It would only apply for testnets so if we reset all testnets because too big, we simply remove it.
Alexey- It would only apply for testnets so if we reset all testnets because too big, we simply remove it.

Peter- Need to reach out to the community to make sure no ones private network gets broken

Expand All @@ -281,7 +281,7 @@ Dimitry- What’s the difference? If they are happening on the same block

Peter- We don’t want to kill all testnets that have already upgraded. With two hard forks, those who already upgraded can have a second hard fork in order downgrade

Alexy- Saves time for fork prep and can get Ropsten alive quicker
Alexey- Saves time for fork prep and can get Ropsten alive quicker

Dimitry- Tests would look the same

Expand Down
6 changes: 3 additions & 3 deletions All Core Devs Meetings/Meeting 54.md
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,7 @@ All videos for the Ethereum Stanford presentations can be found online:
- [Ethereum 1.x Afternoon Day 3](https://www.youtube.com/watch?v=HAK3ijgLRoM)

## 2.2 State Fees
- Alexy was hot available to provide update.
- Alexey was hot available to provide update.

## 2.3 EWasm
- Guillaume: Ewasm is independent of the rest of the Ethereum 1.x
Expand All @@ -117,7 +117,7 @@ All videos for the Ethereum Stanford presentations can be found online:

## 2.5 Simulation
- Zak (Whiteblock): Vanessa presented on simulations on uncle rates using agredated data from the mainnet.
- We are working on a test plan on validating the hypothesis on sync failure and increasing state size. Working on generating 240 millions users. Generate this state probably by Wednesday. Save it and use it to run multiple tests using this state. Been documenting the process and will share it in due course. Working with Alexy and Andre. Suggest it is not just bandwidth.
- We are working on a test plan on validating the hypothesis on sync failure and increasing state size. Working on generating 240 millions users. Generate this state probably by Wednesday. Save it and use it to run multiple tests using this state. Been documenting the process and will share it in due course. Working with Alexey and Andre. Suggest it is not just bandwidth.
- Martin: Keen to find out how the state was generated.
- Zak: Shared how it was being done. And provided a twitter link: https://twitter.com/0xzak/status/1091019925970251778?s=20

Expand Down Expand Up @@ -152,7 +152,7 @@ All videos for the Ethereum Stanford presentations can be found online:
It is the old standard but the new Ethereum 1.x is not yet ready.

## 4.8 Turbo Geth
-Alexy not available to provide update.
-Alexey not available to provide update.

## 4.9 Nimbus
-No one available to provide update.
Expand Down
4 changes: 2 additions & 2 deletions All Core Devs Meetings/Meeting 56.md
Original file line number Diff line number Diff line change
Expand Up @@ -182,7 +182,7 @@ In general, a few people came to me and said that they want to help, so, I am go

**Lane**: That was going to be my question. Do we see this something that falls under the purview of the cat herders?

**Alexy**: It is still not clear and I hope it will get clear that what are the decisions that these people are going to make. Because what we do want them to do is essentially is to aggregate some information, make a decision or we don't want them to make any decisions and they are going to be information aggregators? What is it?
**Alexey**: It is still not clear and I hope it will get clear that what are the decisions that these people are going to make. Because what we do want them to do is essentially is to aggregate some information, make a decision or we don't want them to make any decisions and they are going to be information aggregators? What is it?

**Husdon**: We have a blog out, did we release yesterday? Pooja do you know about it?

Expand Down Expand Up @@ -299,7 +299,7 @@ The blog describes in detail what are these problems , how are we planning to ha

**Hudson**: There was an Ewasm working group if it is still a working group or not. Lane do you have any updates or comments on that.

**Lane**: I think there is some confusion here. I think the Ewasm working group is like the Ewasm team and unfortunately neither Casey nor Alexy is on the call. Pawel, do you have anything to say? I don't know if I have anything to say on that.
**Lane**: I think there is some confusion here. I think the Ewasm working group is like the Ewasm team and unfortunately neither Casey nor Alexey is on the call. Pawel, do you have anything to say? I don't know if I have anything to say on that.

**Pawel**: I don't have anything in particular. We are actually preparing for EthCC.

Expand Down
2 changes: 1 addition & 1 deletion All Core Devs Meetings/Meeting 57.md
Original file line number Diff line number Diff line change
Expand Up @@ -211,7 +211,7 @@ I think it answers both of your questions. The way I would like this discussion

**FJL**: Just with this EIP, because it is just the data format, the way like the magician consensus will be achieved, people will have to just implement it. We can then compare with the record generated by the one implementation to the other by unit test or something. We would know that all of this can generate these records correctly and they are actually valid. When it comes to integrating it to the discovery, this is something that doesn't require any specific cut over date. We can make this change in a backward compatible way such that nodes that do support it will or can use it and those that do not support it will just ignore it.

**Alexy**: I would recommend to include this comment that you just made.
**Alexey**: I would recommend to include this comment that you just made.

**FJL**: It is in the [other EIP](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-868.md) that uses the format. Again, it is just about the format. The thing I wanted to get for a long time was someone to look at it and sign off on it. And say, I am a client implementer, I read this EIP. I think it is good way to represent arbitrary node information. This is really all I wanted.

Expand Down
2 changes: 1 addition & 1 deletion All Core Devs Meetings/Meeting 59.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,7 +110,7 @@ No updates on Turbo-Geth.

**Martin**: The idea is not to schedule hardfork every 3 months but to speed to finish. If there are access test cases in clients then we can't pretty soon.

**Joseph**: Let me try to ask the question of who is having more information of Alexy's idea. Is it the possibility of windows open for hardfork every 3 months?
**Joseph**: Let me try to ask the question of who is having more information of Alexey's idea. Is it the possibility of windows open for hardfork every 3 months?

**Boris**: It was me who was putting words in Alexey's mouth. The context was he was having this multi hardfork plan and he is going to be anxious thinking about certain features are waiting for 6-9 months for implementation. I wanted to just jump in Joseph story for stepping because there has been a suggestion to what you're saying "hardfork window". I think other people are saying including Martin is let's ship stuff when it's ready. So I'm not saying things need to be every 3 months but more frequent and it sounds like 3 months is like lower end of event that people say that's really tight and then 6 months. I have to look up but discussion around this where somewhere between 3-6 months shipping smaller features on a regular basis and coordinating among client. So that they shooting their process to support that is okay as long as it doesn't impact client maintenance.

Expand Down
6 changes: 3 additions & 3 deletions All Core Devs Meetings/Meeting 61.md
Original file line number Diff line number Diff line change
Expand Up @@ -121,7 +121,7 @@ Status: WIP

**Alexey**: Well I understand this. The intention is clear to me, but I do not think that the EIP is the correct thing to be putting in. Because as far as I understand the EIP is the specification of the change. The specification of the change, from my point of view, cannot be produced in a high quality.

**Boris**: Alexey, let me cut you off there. So, I understand that you have a particular hang up about not putting an EIP until its perfect. In part this is signaling to understand and plan. I personally, if you put an EIP up, it says ALexey will fill it later with high-quality but I intend to get in the Istanbul, that would be awesome from a signaling perspective. Is that ideal, that like 30 different people; all put in things that basically said the same thing - not useful. But what we have got today, I think that if you want to bring it an EIP past the deadline it will be considered because that's what ACD can do but in the meantime we'd like to push anyone else not named Alexy get there EIP set. Is that a fair thing that?
**Boris**: Alexey, let me cut you off there. So, I understand that you have a particular hang up about not putting an EIP until its perfect. In part this is signaling to understand and plan. I personally, if you put an EIP up, it says ALexey will fill it later with high-quality but I intend to get in the Istanbul, that would be awesome from a signaling perspective. Is that ideal, that like 30 different people; all put in things that basically said the same thing - not useful. But what we have got today, I think that if you want to bring it an EIP past the deadline it will be considered because that's what ACD can do but in the meantime we'd like to push anyone else not named Alexey get there EIP set. Is that a fair thing that?

**Alexey**: Well, yes! Maybe I'm just too hung up on this. we probably need to redifine, we need an EIP or just like a couple of lines saying that this is what I think should be happening.

Expand All @@ -146,7 +146,7 @@ c. intention to get your change into the next hardfork

**Alexey**: Yes, so I can do that. I can describe what I would like to get there but I can't write EIP because from what I understand EIP, it has to be formal specification. So if we were agree that the EIP is basically not formal specification I'm going to do this. Or tell me what are the things I need to produce ?

**Boris**: You and I dis updates to EIP 233. What if we say EIP XXX Alexy TBD but here is the name of it. Then at least we have a record in the same spot , in 1679. We would actually have that listed.
**Boris**: You and I dis updates to EIP 233. What if we say EIP XXX Alexey TBD but here is the name of it. Then at least we have a record in the same spot , in 1679. We would actually have that listed.

**Alex**: My **understanding of the EIP process** was that, that the first deadline lists EIPs which are in draft mode and we don't really have a concrete specification of what draft mode means, even for core EIPs. But I would assume the draft signals that it may not be fully specified, it has a general idea and it is likely to improve for the process. Probably the draft mode doesn't mean that it is fully formally specified. It has an intention that it will be and where the first deadline my assumption was that whatever is proposed by the first deadline is the list of EIPs which are going to be deliberated on and it's very few exceptions new EIPs should not be possible to be proposed because that may just lengthen the process.

Expand Down Expand Up @@ -177,7 +177,7 @@ c. intention to get your change into the next hardfork
3. And furthermore that as of this particular deadline 7 days from today, these EIPs today may still be in draft form they're not expected necessarily to be thorough and complete. And of course not expected to have implementations ready because there's two months following that, until July, I believe, for that to happen.
Anyone opposed to those that summary otherwise we can keep moving.

**Greg**: I'd like to volunteer but I'm too busy as an EIP editor Alex is an EIP editor. Can someone volunteered just help very busy Alexy with the mechanics of what an EIP is very well defined and someone just said, get them going get an abstract get them in, so we have numbers to refers to what Alexey wants to do. It so important that it gets done. It helps a lot to have numbers to point at and say these things.
**Greg**: I'd like to volunteer but I'm too busy as an EIP editor Alex is an EIP editor. Can someone volunteered just help very busy Alexey with the mechanics of what an EIP is very well defined and someone just said, get them going get an abstract get them in, so we have numbers to refers to what Alexey wants to do. It so important that it gets done. It helps a lot to have numbers to point at and say these things.

**Boris**: I'm fine to help you with the mechanics of it, but the other side, we need people in ACD that you can merge them.

Expand Down
2 changes: 1 addition & 1 deletion All Core Devs Meetings/Meeting 64.md
Original file line number Diff line number Diff line change
Expand Up @@ -287,7 +287,7 @@ Thursday July 18, 2019 at 22:00 UTC
* Alex Beregszaszi
* Alex Gluchowski
* Alex Vlasov
* Alexy Akhunov
* Alexey Akhunov
* Brett Allsop
* Brett Robertson
* Danno Ferrin
Expand Down
2 changes: 1 addition & 1 deletion All Core Devs Meetings/Meeting 65.md
Original file line number Diff line number Diff line change
Expand Up @@ -400,7 +400,7 @@ There was [an AMA](https://ethereum-magicians.org/t/eip-1283-1706-ama/3467) with

**Danno**: Another questions I asked on Eth Magician wasn't answer.As a developer I would have a nightmare trying to have to cram all of parameters in binary string. And I would like to hear what do you solidity invite things about the usability of the interface. Cryptography sounds great in everything, I have concerns about its usability as a developer.

**Tim**: Just to be mindfulness of time again and based on what Alexy and James had previously said, does it make sense to deal with those questions offline and come back to this EIP on the next call similarly to 1344?
**Tim**: Just to be mindfulness of time again and based on what Alexey and James had previously said, does it make sense to deal with those questions offline and come back to this EIP on the next call similarly to 1344?

**Danno**: Yes, I asked my question 11 days ago. We can keep discussion on Eth Magician.

Expand Down
2 changes: 1 addition & 1 deletion All Core Devs Meetings/Meeting 90.md
Original file line number Diff line number Diff line change
Expand Up @@ -192,7 +192,7 @@ Video | [1:24:33](https://youtu.be/IZEcukn9J0Y?t=5073)

- Alex (axic)
- Alex Vlasov
- Alexy Akhunov
- Alexey Akhunov
- Artem Vorotnikov
- Edson Ayllon
- Greg Colvin
Expand Down
2 changes: 1 addition & 1 deletion All Core Devs Meetings/Meeting 92.md
Original file line number Diff line number Diff line change
Expand Up @@ -298,7 +298,7 @@ Moved to EFI.
## Attendance

- Alex Vlasov
- Alexy Akhunov
- Alexey Akhunov
- Artem Vorotnikov
- Daniel Ellison
- David Mechler
Expand Down
Loading

0 comments on commit e05120b

Please sign in to comment.