diff --git a/All Core Devs Meetings/Meeting 53.md b/All Core Devs Meetings/Meeting 53.md index b41394b8..cc11b7d7 100644 --- a/All Core Devs Meetings/Meeting 53.md +++ b/All Core Devs Meetings/Meeting 53.md @@ -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 @@ -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 diff --git a/All Core Devs Meetings/Meeting 54.md b/All Core Devs Meetings/Meeting 54.md index 769fc67f..0fc0313e 100644 --- a/All Core Devs Meetings/Meeting 54.md +++ b/All Core Devs Meetings/Meeting 54.md @@ -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 @@ -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 @@ -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. diff --git a/All Core Devs Meetings/Meeting 56.md b/All Core Devs Meetings/Meeting 56.md index eee4bcc6..24583093 100644 --- a/All Core Devs Meetings/Meeting 56.md +++ b/All Core Devs Meetings/Meeting 56.md @@ -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? @@ -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. diff --git a/All Core Devs Meetings/Meeting 57.md b/All Core Devs Meetings/Meeting 57.md index e99602e0..4318077e 100644 --- a/All Core Devs Meetings/Meeting 57.md +++ b/All Core Devs Meetings/Meeting 57.md @@ -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. diff --git a/All Core Devs Meetings/Meeting 59.md b/All Core Devs Meetings/Meeting 59.md index fc191975..92382e82 100644 --- a/All Core Devs Meetings/Meeting 59.md +++ b/All Core Devs Meetings/Meeting 59.md @@ -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. diff --git a/All Core Devs Meetings/Meeting 61.md b/All Core Devs Meetings/Meeting 61.md index 5d8fd3b1..80edc1d3 100644 --- a/All Core Devs Meetings/Meeting 61.md +++ b/All Core Devs Meetings/Meeting 61.md @@ -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. @@ -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. @@ -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. diff --git a/All Core Devs Meetings/Meeting 64.md b/All Core Devs Meetings/Meeting 64.md index e539ce91..192fbf5a 100644 --- a/All Core Devs Meetings/Meeting 64.md +++ b/All Core Devs Meetings/Meeting 64.md @@ -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 diff --git a/All Core Devs Meetings/Meeting 65.md b/All Core Devs Meetings/Meeting 65.md index 2a361427..fb119465 100644 --- a/All Core Devs Meetings/Meeting 65.md +++ b/All Core Devs Meetings/Meeting 65.md @@ -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. diff --git a/All Core Devs Meetings/Meeting 90.md b/All Core Devs Meetings/Meeting 90.md index 7af55b71..c4fd68c4 100644 --- a/All Core Devs Meetings/Meeting 90.md +++ b/All Core Devs Meetings/Meeting 90.md @@ -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 diff --git a/All Core Devs Meetings/Meeting 92.md b/All Core Devs Meetings/Meeting 92.md index 9de63ff4..27941e0b 100644 --- a/All Core Devs Meetings/Meeting 92.md +++ b/All Core Devs Meetings/Meeting 92.md @@ -298,7 +298,7 @@ Moved to EFI. ## Attendance - Alex Vlasov -- Alexy Akhunov +- Alexey Akhunov - Artem Vorotnikov - Daniel Ellison - David Mechler diff --git a/All Core Devs Meetings/Meeting 95.md b/All Core Devs Meetings/Meeting 95.md new file mode 100644 index 00000000..19649918 --- /dev/null +++ b/All Core Devs Meetings/Meeting 95.md @@ -0,0 +1,606 @@ +# All Core Devs Meeting 95 Notes +### Meeting Date/Time: Friday 4 Sept 2020, 14:00 UTC +### Meeting Duration: 1.5 hrs +### [Github Agenda](https://github.com/ethereum/pm/issues/203) +### [Audio/Video of the meeting](https://youtu.be/-Jefyrs4f70) +### Moderator: Hudson Jameson +### Notes: Edson Ayllon + +--- + +# Summary + +## EIP Status + +EIP | Status +--|-- +2718, 2929, 2935 | Going into YOLOv2 +2930, 2315 | Continue discussion for YOLOv2 + +## Decisions Made + +Decision Item | Decision +-|- +95.1 | Add [EIP 2718](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2718.md): Typed Transaction Envelope to YOLO v2. +95.2 | Add [EIP-2929](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2929.md): Gas cost increases for state access opcodes to YOLO v2. +95.3 | Continue to discuss [EIP-2930](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2930.md): Optional access lists. +95.4 | Continue discussion of [EIP-2315](https://eips.ethereum.org/EIPS/eip-2315): Simple Subroutines for the EVM in Eth Magicians forum. +95.5 | Add [EIP-2935](https://eips.ethereum.org/EIPS/eip-2935): Save historical block hashes in state to YOLO v2. +95.6| [EIP-2711](https://eips.ethereum.org/EIPS/eip-2711): Sponsored, expiring and batch transactions was only discussed today as an overview for the purpose of future discussion and not to be considered for inclusion, EFI, or anything else as of this meeting. +95.7 | Add Account Abstraction item to next ACD meeting agenda. See this comment: https://github.com/ethereum/pm/issues/203#issuecomment-686923605 +95.8 | Add Ethereum Cat Herders Survey Results to the next ACD meeting agenda. + +--- + +# Contents + +- [Contents](#contents) +- [1. EIP Discussion](#1-eip-discussion) + - [1.1 Potentially removing gas refund (see comment).](#11-potentially-removing-gas-refund-see-comment) + - [1.2 EIP 2718: Typed Transaction Envelope (general-purpose standard for adding new transaction types).](#12-eip-2718-typed-transaction-envelope-general-purpose-standard-for-adding-new-transaction-types) + - [1.3 EIP-2929: Gas cost increases for state access opcodes.](#13-eip-2929-gas-cost-increases-for-state-access-opcodes) + - [1.4 EIP-2930: Optional access lists.](#14-eip-2930-optional-access-lists) + - [1.4 EIP-2315: Simple Subroutines for the EVM.](#14-eip-2315-simple-subroutines-for-the-evm) + - [1.5 General discussion on the idea of combining some of the above EIPs that create a new transaction type, so we just create a single new transaction type that has a whole bunch of the features together.](#15-general-discussion-on-the-idea-of-combining-some-of-the-above-eips-that-create-a-new-transaction-type-so-we-just-create-a-single-new-transaction-type-that-has-a-whole-bunch-of-the-features-together) + - [1.6 EIP-2935: Save historical block hashes in state.](#16-eip-2935-save-historical-block-hashes-in-state) + - [1.7 EIP-2711: Sponsored, expiring and batch transactions.](#17-eip-2711-sponsored-expiring-and-batch-transactions) + - [1.8 EIP-1057 Next Steps.](#18-eip-1057-next-steps) +- [2. EIP & Upgrades Updates](#2-eip-upgrades-updates) + - [2.1 YOLO / YOLOv2 & Berlin state tests update](#21-yolo-yolov2-berlin-state-tests-update) + - [2.2 EIP-1559 Update](#22-eip-1559-update) + - [2.3 Account abstraction: AA EIP and AA DoS study](#23-account-abstraction-aa-eip-and-aa-dos-study) + +--- + + +# 1. EIP Discussion +## 1.1 Potentially removing gas refund (see comment). + +Video | [0:00](https://youtu.be/-Jefyrs4f70) +-|- + +Alexey, by observing transactions, noticed it's like an order book. Where people bid for the gas prices. Low bid orders are there to scoop the dips. However, in exchanges you can cancel orders at no cost. But, in Ethereum, you can send another transaction to yourself at a higher gas, or spam the pool so much that it takes it out. + +This may be a reason we can't reach high gas prices. As people buy the dip, they go high again. + +Looking at Chi token, the magnitude wasn't congruent with it causing the gas prices to rise. Chi tokens only consumed 10% of all gas consumed. We can't blame Chi tokens for sustained high gas prices. + + +## 1.2 EIP 2718: Typed Transaction Envelope (general-purpose standard for adding new transaction types). + +Video | [10:12](https://youtu.be/-Jefyrs4f70?t=612) +-|- + +From Micah Zoltou, in draft status right now. It's in EFI right now. + +There are no formats defined that defines an access list. This only is a format to provide extensibility in transactions. The access list EIP is 2930. + +There is discussion about combining some EIPs into new transaction types, as there is overlap. + +This EIP changes transactions to have an outer envelope, and a leading integer that denotes the type of transaction. + +Traditionally, we've only had 1 transaction type. But we have a couple EIPs that want to introduce changes to transactions. Rather than guessing what transaction type it is by the elements, there may be errors, we specify the transaction type. + +It's an integer with a payload field. How you interpret the payload field is dependent on the initial integer. + +This also allows clients to drop transaction types they don't recognize. It may not be used, but it's there as a feature. + +Legacy transaction types, current transactions, they'll be wrapped as they are. For all other transaction types, they'll include a transaction number in the signature. This prevents the replay problem. + +The signature is included in the payload. Future transaction types can use a different way to sign. + +In the Cat Herder's call, it was suggested, when there are a lot of questions in the ACD call, that we can have break out sessions after. This dsicussion will be tabled there. + +It may be best to have 2718 not bundled with other EIPs to get it released without much complexity. It may be good for YOLOv2. + +There is specification for what to do with pending transactions on the fork block. + +## 1.3 EIP-2929: Gas cost increases for state access opcodes. + +Video | [28:41](https://youtu.be/-Jefyrs4f70?t=1721) +-|- + +Increases the gas cost for first time accesses. This mitigates against DOS attacks and have gas costs more accurately reflect computation time. The blocks that take the longest to process are the IO heavy ones. + +Gas costs of average applications would only increase by 2%. Most applications are written very efficiently. It surgically targets making the thing that needs to be expensive. + +This EIP may supercede other EIPs people have been trying to push historically. + +**Alexey**: This EIP introduces a read list. Before we only had a write list. The correct solution I see is, yes increase the gas cost. But instead, introduce a specialized primitive so we can cache. + +**Vitalik**: I see it being less complicated. This uses transaction wide global variables, which are used in refunds, and self destruct. There is value having this out in the fairly short term. + +**Alexey**: First of all, is this really important? Do people really do that? If it is, we should introduce a mechanism for that. + +**Martin**: Solidity does it every time you make calls. We're not adding another cache layer. We're adding a boolean. Implementation wise, it's not too hard. + +**Vitalik**: If you want to get the benefit of not double charging ERC20 tokens, you have to redeploy every ERC20 token. + +**Alexey**: My main concern isn't performance. My main concern is complexity. + +**Vitalik**: These are things we've already done. + +**Martin**: I shared those concerns, that's why I made an implementation. + +**Hudson**: I'll table this. Continue on EthMagicians. Or if you want to request a breakout room, reach out to me or Pooja or Edson from the Cat Herders. + + +## 1.4 EIP-2930: Optional access lists. + +Video | [43:29](https://youtu.be/-Jefyrs4f70?t=2609) +-|- + +It allows you to prepay higher gas cost for accessesing storage costs and addresses for the first time. This mitigates breaking contracts that rely on fixed gas limits. + +The EIP itself is not super complex. If we want to have another transaction type, this is the simplest one to include. + +Geth would like to implement this, along with another client. Geth wants it in YOLOv2. + +This EIP may be in YOLOv2, but not accepted yet. + +For 2718, at first, only the clients need an implementation. As more transaction types are added, contracts may also need compatability. + + +## 1.4 EIP-2315: Simple Subroutines for the EVM. + +Video | [54:33](https://youtu.be/-Jefyrs4f70?t=3273) +-|- + +This one is in YOLOv1. Will go over into YOLOv2. + +Did write custom fuzzer targeting subroutine, and no issues found. + +The last feature, not jumpting into subroutines. Should continue in the Magician's thread. + +## 1.5 General discussion on the idea of combining some of the above EIPs that create a new transaction type, so we just create a single new transaction type that has a whole bunch of the features together. + +Video | [56:49](https://youtu.be/-Jefyrs4f70?t=3409) +-|- + +Skipped for now. + + +## 1.6 EIP-2935: Save historical block hashes in state. + +Video | [57:40](https://youtu.be/-Jefyrs4f70?t=3460) +-|- + +You stick the hash of the previous block into a storage slot before processing the current block, keeping a simple and dumb method of ensuring blocks have a quick merkle path to all historical blocks since the EIP was introduced. + +In terms of state size growth, it would add a gain of 1% to the current state growth size. + +The benefits are in the category of creating layer 2 protocols. + +It's simpler than putting an accumulator in the header. + +There are some DeFi projects that would greatly benefit from this. + +This would also allow tracking the history without a header chain. + +This EIP may go into YOLOv2. + +Something to consider for YOLO version, clients have to implement all EIPs going into the testnet, or tney'll be kicked out. So, a lot of these EIPs going into YOLOv2 are very simple. This one is 2 lines of specification. + +## 1.7 EIP-2711: Sponsored, expiring and batch transactions. + +Video | [1:08:01](https://youtu.be/-Jefyrs4f70?t=4141) +-|- + +This was supposed to be the first 2718 transaction. A new transaction type that handles user experiences annoyances in the Dapp space. + +Sponsored transactions: Instead of having a single signer, we have 2 signers. The second signer is the one who pays for gas. This is in layer 1, which is much cleaner than solving it in the Dapp layer. + + +Batch transactions: One or more transactions, atomic in that they make it in the order you specify, with nothing in-between. They are not atomic in that they all fail or they all succeed. Instead of having Dapps that send multiple transactions, one to approve, and the other to commit the action, it's a single transaction. + +Also adds optional expiration field, that invalidates a transaction after a specified timestamp. Uniswap has this currently. But, the transactions still exist on chain, so after their expiry in uniswap, it just fails instantly, which leads to large losses of gas. + +There's one gas price for the entire batch. + +Time boxed until later. + + +## 1.8 EIP-1057 Next Steps. + +Video | [1:19:09](https://youtu.be/-Jefyrs4f70?t=4749) +-|- + +Instead of going into decisions, just going into updates. + +Andrea, one of the authors, just got out of the hospital, so he's reviewing code just before he went into the hospital. It looks like the kik exploit is nothing to worry about. + +It looks like existing exploits will fall out of the network in November, so that's a time to deploy ProgPoW if it will be deployed. + + +# 2. EIP & Upgrades Updates + +Video | [5:29](https://youtu.be/-Jefyrs4f70?t=329) +-|- + +A lot of questions about Berlin and timing for Berlin. Why the timing for Berlin hasn't been announced is that it's dependent on YOLOv2. For EIPs that go into YOLOv2, it is possible they go into Berlin, but it doesn't mean they are slated for the Berlin upgrade. + +EIPs in YOLOv2 are considered for testnet first, then client integration testing, and that will determine its inclusion. + +As for the name, it's not called Berlinv2, as EIPs that are in YOLOv2 may not go into a hardfork at all. Testnets after Berlin may be YOLOv3, or something else. YOLO is meant to show that the testnet will live for a short time. + +## 2.1 YOLO / YOLOv2 & Berlin state tests update + +Video | [1:20:54](https://youtu.be/-Jefyrs4f70?t=4854) +-|- + +Going into YOLOv2: +- 2718 +- 2929 +- 2935 + +Continue discussion on: +- 2930 +- 2315 (already on YOLOv1) + +Continue EFI Discussion +- 2711 + +2 left to talk about: 2565, 2046. 2565 is moving into final. The other is 2046. 2929 would supercede 2046. 2046 is pending until 2929 is decided on. + + +## 2.2 EIP-1559 Update + +Video | [1:31:32](https://youtu.be/-Jefyrs4f70?t=5492) +-|- + +Implementors call last week. + +Testnet between Besu and Geth from Vulcanize. + +EF is doing some simulations on the EIP. Looking at what happens when there's spikes. Next for having agents outbid each other. + +Formal analysis will be done by a game theorist. + +Next steps will be to get more client implementations, and have a proof of work testnet. + + +## 2.3 Account abstraction: AA EIP and AA DoS study + +Video | [1:27:26](https://youtu.be/-Jefyrs4f70?t=5246) +-|- + +One of the concerns for account abstraction is the DOS vectors and vulnerabilies. Study released on EthResearch. + +The goal is to expand the set of conditions transactions have for valid inclusion in the chain. + +The use cases are: Single tenant account transaction. Smart contracts, multisigs, etc. + +Too complex and too new to be considered for Berlin. + +--- + +# Annex + + +## Attendance + +- Alex (axic) +- Alex Vlasov +- Ansgar Deitrichs +- Ansgar Deitrichs +- Artem Vorotnikov +- Daniel Ellison +- David Mechier +- David Murdoch +- Edson Ayllon +- Greg Colvin +- Hudson Jameson +- James Hancock +- Jason Carver +- Kelly +- Martin Hoist Swende +- Micah Zoltou +- Pawel Bylica +- Peter Szilagyi +- Piper Merriam +- Pooja Ranjan +- Rai Sur +- Sam Wilson +- Tim Beiko +- Tomasz Stanczak +- Vitalik Buterin +- Will Villanueva +- lightclient + + +## Next Meeting Date/Time + +Friday 18 Sept 2020, 14:00 UTC + +## Call Chat + + +From Edson Ayllon to Everyone: (10:04 AM) + +Agenda: https://github.com/ethereum/pm/issues/203 + +From Micah to Everyone: (10:12 AM) + +Essentially "YOLO" is the pre-hardfork integration network? + +From Tomasz Stanczak to Everyone: (10:13 AM) + +the name YOLO was to suggest users to not expect it to surviveit went sideways :) + +From Micah to Everyone: (10:13 AM) + +๐Ÿ‘So it is the ephemeral integration test network. ๐Ÿ‘ + +From James Hancock to Everyone: (10:14 AM) + +Yes, for client integration testing and fuzz testing + +From Micah to Everyone: (10:14 AM) + +2718 was EFI2711 I don't think was discussed.No mic.I can *find* a mic if it is necessary.Sec. + +From Hudson Jameson to Everyone: (10:15 AM) + +Yeah find a mic plz + +From Tomasz Stanczak to Everyone: (10:16 AM) + +We introduce a new EIP-2718 transaction type, with the format rlp([3, [nonce, gasPrice, gasLimit, to, value, data, access_list, senderV, senderR, senderS]]).EIP starts this waywhich is already using iton 2930https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2930.md + +From Micah to Everyone: (10:18 AM) + +Have mic now, and fixed feedback. + +From Tomasz Stanczak to Everyone: (10:22 AM) + +you can sign and then extract some of the signed dataas designedmakes sense + +From Tomasz Stanczak to Everyone: (10:22 AM) + +one is protecting against replay, the other gives hint on serialization format + +From Micah to Everyone: (10:26 AM) + +๐Ÿ‘ I support breakouts. I always feel bad taking time up from ACD calls. ๐Ÿ˜ฌ + +From lightclient to Everyone: (10:26 AM) + +also supportbtw i'm working on an impl of 2718, please ping me on discord to coordinate if interested + +From Pooja Ranjan to Everyone: (10:27 AM) + +sure + +From Tomasz Stanczak to Everyone: (10:28 AM) + +agreedI am for + +From Micah to Everyone: (10:32 AM) + +Sounds like James wants it on YOLO v2. ๐Ÿ˜‰ + +From James Hancock to Everyone: (10:32 AM) + +:) + +From lightclient to Everyone: (10:32 AM) + +IMO, transaction propagation doesn't need to *immediately* transition all txs to the new type -- they just have to be properly encode them in new blocks past the FORK_BLOCK + +From James Hancock to Everyone: (10:32 AM) + +Happy to have anyone disagree + +From James Hancock to Everyone: (10:33 AM) + +I just don't want to get held up on what will happen for mainnet at this point, as we can address that on another callas it progresses forward. + +From lightclient to Everyone: (10:34 AM) + +also, i went searching for the comment from Micah regarding eip-2930 and it not being a good fit for eip-2718, but couldn't find it -- could someone point it to me please? + +From Micah to Everyone: (10:39 AM) + +@lightclient you are probably thinking of my commentary that we should maybe combine 2930, 2711, and 1559. + +From James Hancock to Everyone: (10:40 AM) + +My suggestion to that is if we have them in the same integration testnet, you get the optimization of work for the clients without having to bundle the decisions around them.So you don't need to combine the EIPs + +From lightclient to Everyone: (10:41 AM) + +@micah: ah okay, maybe misheard earlier, but it sounded like there was miscommunication with Martin where he thought you had said 2930 shouldn't be a 2718 tx type + +From Micah to Everyone: (10:41 AM) + +I don't think I have argued against 2930 as 2718. + +From lightclient to Everyone: (10:42 AM) + +got it, ty + +From Micah to Everyone: (10:43 AM) + +@James The problem at the moment is that if we combine them into one testnet, they are currently planned as separate transaction types, but I think (maybe) there is value in having most of them be one new transaction type with several optional fields. + +From James Hancock to Everyone: (10:44 AM) + +Got it, That is a different discussion than I understood. + +From Micah to Everyone: (10:44 AM) + +๐Ÿ‘ + +From Hudson Jameson to Everyone: (10:44 AM) + +Time boxing this soon. + +From Tim Beiko to Everyone: (10:51 AM) + +What is 2935? + +From Vitalik Buterin to Everyone: (10:51 AM) + +https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2935.md + +From James Hancock to Everyone: (10:52 AM) + +historical block hashes + +From Vitalik Buterin to Everyone: (10:52 AM) + +Happy to talk about it for a few seconds if people want, it's super simple + +From Tomasz Stanczak to Everyone: (10:52 AM) + +2929 for sure in + +From Tim Beiko to Everyone: (10:52 AM) + +How about 2929 in and 2930 on hold? + +From Micah to Everyone: (10:52 AM) + +Make all blockhashes available, instead of the last 256 (very short version).My 0 votes says 2929 is pretty important, 2930 is "would be cool". + +From Tomasz Stanczak to Everyone: (10:53 AM) + +2929 is a must + +From Tomasz Stanczak to Everyone: (10:53 AM) + +2930 I believe there may be a redesign for it and we are not using it yetI think it makes sense to call current transactions 'naked' like a naked burrito without a wrap + +From Micah to Everyone: (10:56 AM) + +๐Ÿฅ— + +From Micah to Everyone: (10:56 AM) + +I think the clients should be able to build the access list on behalf of the user for 2930? + +From Tomasz Stanczak to Everyone: (10:56 AM) + +this is also why I think that 'access list' is awkward for the current YOLO - it will be even hard to test + +From Micah to Everyone: (10:57 AM) + +Hmm, but only if they are doing the signing I guess.That is, the *signer* needs to be able to deal with access lists.So... MetaMask. ๐Ÿ˜‰ + +From Tomasz Stanczak to Everyone: (10:57 AM) + +yes2315 implemented in Nethermind + +it is in YOLO + +From Tomasz Stanczak to Everyone: (11:00 AM) + +do we have the test cases for benchmarking 2565? + +From Alex (axic) to Me: (Privately) (11:01 AM) + +I know that ignoring the transactiontype field for type=0 for signing is there so they can be upgraded easily, but is it a good idea to exclude the leading byte?Sorry meant to send to everyone :) + +From Alex (axic) to Everyone: (11:02 AM) + +I know that ignoring the transactiontype field for type=0 for signing is there so they can be upgraded easily, but is it a good idea to exclude the leading byte? + +From James Hancock to Everyone: (11:02 AM) + +I think there is some for some of the clients + +From kelly to Everyone: (11:02 AM) + +Tomasz - I can provide the new expected gas costs in the ACD costs for EIP-2565oops in the ACD chat*Micah also had a few suggestions for the EIP before it is finalized and it may be a good idea to put the updated test vector results in there as well + +From kelly to Everyone: (11:04 AM) + +All test vectors for EIP-2565 are carried over from EIP-198 since EIP-2565 just changes the gas pricing formula + +From Tomasz Stanczak to Everyone: (11:04 AM) + +we would love to see 2935we have lots of use casesaround DeFi solutions + +From Micah to Everyone: (11:05 AM) + +I have a project that already is live but is limited to 1 hour instead of infinity hours. :) + +From Tomasz Stanczak to Everyone: (11:05 AM) + +exactly + +From Micah to Everyone: (11:07 AM) + +https://github.com/Keydonix/uniswap-oracle/ for an example use case. (trustless price feed via Uniswap)Heh, I think 1559 is less complex than 2929. ๐Ÿ˜‰ + +From Vitalik Buterin to Everyone: (11:12 AM) + +There's complexity of specification and complexity of consequences :) + +From Tomasz Stanczak to Everyone: (11:12 AM) + +EIP-2046: Reduced gas cost for static calls made to precompiles.cost change only, need benchmarks so need testnet EIP-2315: Simple Subroutines for the EVM. already implemented EIP-2537: Precompile for BLS12-381 curve operations (already in YOLOv1). already implemented EIP-2711: Sponsored, expiring and batch transactions. demanding EIP 2718: Typed Transaction Envelope (general-purpose standard for adding new transaction types). simple and we need it EIP-2565: Repricing of the EIP-198 ModExp precompile. repricing only - worth to have for benchmarks EIP-2929: Gas cost increases for state access opcodes. repricing mainly, critical EIP-2930: Optional access lists. (Nethermind slighlty against for YOLOv2) EIP-2935: Save historical block hashes in state. yes, please (from Nethermind) + +From Vitalik Buterin to Everyone: (11:12 AM) + +Agree that the new 1559 is quite simple spec-wise + +From Tomasz Stanczak to Everyone: (11:13 AM) + +2711 is great and needed but 2718 first wouldbe great + +From Micah to Everyone: (11:21 AM) + +I'll get it for you, one sec. + +From lightclient to Everyone: (11:21 AM) + +EIP-2803: https://eips.ethereum.org/EIPS/eip-2803 + +From Micah to Everyone: (11:21 AM) + +https://eips.ethereum.org/EIPS/eip-2803 (Rich Transactions) + +From Alex Vlasov to Everyone: (11:25 AM) + +We are in a state when decision on 2046 can be made without extra dependencies + +From Vitalik Buterin to Everyone: (11:27 AM) + +Do we need 2046 if 2929 is going in? It de-facto includes the functionality + +From Alex Vlasov to Everyone: (11:27 AM) + +This one is just simple to implement immediatelly + +From Tim Beiko to Everyone: (11:31 AM) + +What was the outcome for 2046? + +From James Hancock to Everyone: (11:31 AM) + +2929 is in yolo, 2046 is in pending + +From James Hancock to Everyone: (11:32 AM) + +https://github.com/ethereum/eth1.0-specs/projects/1Working from a project board here + +From Hudson Jameson to Everyone: (11:34 AM) + +Correction 2929 will be in Yolov2, not Yolo. + +From James Hancock to Everyone: (11:35 AM) + +Yes, thank you hudson + +From Hudson Jameson to Everyone: (11:35 AM) + +Here are the "Decisions Mae" for the note taker: + +From Hudson Jameson to Everyone: (11:35 AM) + +Decisions Made:Add EIP 2718: Typed Transaction Envelope to YOLO v2. Add EIP-2929: Gas cost increases for state access opcodes to YOLO v2. Continue to discuss EIP-2930: Optional access lists. Continue discussion of EIP-2315: Simple Subroutines for the EVM in Eth Magicians forum. Add EIP-2935: Save historical block hashes in state to YOLO v2. EIP-2711: Sponsored, expiring and batch transactions was only discussed today as an overview for the purpose of future discussion and not to be considered for inclusion, EFI, or anything else as of this meeting. Add Account Abstraction item to next ACD meeting agenda. See this comment: https://github.com/ethereum/pm/issues/203#issuecomment-686923605 Add Ethereum Cat Herders Survey Results to the next ACD meeting agenda. Note taker: Please hyperlink the EIP URLs to the EIPs referenced in the decisions made section in the notes. You can find them in today's agenda. + +From Pooja Ranjan to Everyone: (11:36 AM) + +Sure! diff --git a/All Core Devs Meetings/Meeting 99.md b/All Core Devs Meetings/Meeting 99.md new file mode 100644 index 00000000..5e25bb8d --- /dev/null +++ b/All Core Devs Meetings/Meeting 99.md @@ -0,0 +1,270 @@ +# All Core Devs Meeting 99 Notes +### Meeting Date/Time: Friday 30 Oct 2020, 14:00 UTC +### Meeting Duration: 1.5 hrs +### [Github Agenda](https://github.com/ethereum/pm/issues/219) +### [Audio/Video of the meeting](https://www.youtube.com/watch?v=GOWSrHtNZOQ) +### Moderator: Hudson Jameson +### Notes: Edson Ayllon + +--- + +# Summary + + + +## Decisions Made + +Decision Item | Decision +-|- +**99.1** | For now, 2537 is out of YOLOv3, and delayed until after the next hardfork. + + +--- + +# Contents + +--- + +# 1. YOLOv3 & Berlin discussion + +## 1.1 YOLOv3 spec + +Video | [3:59](https://youtu.be/GOWSrHtNZOQ?t=239) +-|- + +Each client status on YOLOv2: + +### Besu + +Merged and syncing. On YOLOv2, 2537, subroutines, access lists. Aligned with 2929 requirements. Haven't done YOLOv3 work yet. + +### Geth + +Merged and syncing. Done with YOLOv2. Composite tests regenerated with Berlin named tests. Should start seeing failures within the next few days for clients who haven't been made activatable. YOLOv3 open PR. Merged 2565 PR, but not activatable. + +### Nethermind + +Merged, not syncing. Some failure on the Besu Nethermind EIP-1559 equation. For Berlin YOLOv2, will join as soon as Geth and Besu has a running version, which should be done for 2929, so soon. Still looking for what's being added. 2935, 2666. Trying to build and connect library to support modex repricing. + +### Open Ethereum + +Not participating on YOLOs at the moment. + + +## 1.2 Discord conversation + +Video | [12:16](https://youtu.be/GOWSrHtNZOQ?t=736) +-|- + +Things to figure out: +1. Do we agree that successful YOLOv3 EIPs can go into Berlin? +2. Are client teams comfortable implementing YOLOv3 in 2-4 weeks development time? +3. How comfortable are people moving forward with 2537? + +2565, why not pull it into YOLOv3? The argument last time was that it was so small, there's no need to put it in. But, on the counter, it's so small, why don't we put it in? + +Besu states it will be easier to implement YOLOv3 with 2565, than without it. + +Martin noted that 2537 and 2315 are linked with a certain commit hash in the specification. He asked if that's the same hash that was used in YOLOv1 and v2. It is the same. + +Once gas is redone, there needs to be benchmarking. Alex Vaslov will merge an update to the EIP to have a new commit hash for YOLOv3. + +The updated spec won't change the logic, only constants. + +Besu thinks 2-4 timeframes is reasonable for YOLOv3 implemented for launch. + +Geth can possibly do in 2-4 weeks. + +Nethermind is on their way, so 2-4 weeks is good for them. + +Open Ethereum is not participating on YOLOv2, but will be ready in 2-4 weeks for YOLOv3. + +As for 2537, some consider EVM-384 as a safter alternative for the BLS precompiles. There are still unknowns for the EVM release date. There are also questions about how optimized EVM-384 is for gas prices on mainnet. + +**Alex Vaslov**: Has a proposal to salvage work done with 2537 while using EVM=384. The same work, op codes, addition, subtraction, multiplication, we can migrate the precompile using these set of op codes. It can be EVM without all the functions of EVM. The functionality just hidden one layer down. + +**Martin Hoist Swende**: This proposal will capture the worst in both cases. It would reduce the concerns for consensus flaws. + +**Alex Vaslov**: However, without numbers for performance, with how the final contract will look, we can't make judgements on this proposal. + +**Alex Vaslov**: would like see both, in case there is something needed, we can get it immediately without waiting for another precompile. If there is an implementation that is faster, he'd like to optimize for performance. + +**Martin Hoist Swende**: Wouldn't like to optimize for performance if it means adding new precompiles for each curve that would like support, if we can add the basic bricks. + +**Alex Vaslov**: In regards for "every new curve" the number of curves is very limited. + +**James**: Would this already be sufficient for BLS6? + +**Alex Vaslov**: It wouldn't, because the fill size is different. However, right now, I don't know how many curves people would want to use. But I cannot project into the future. + +**Axic**: In regards for BLS12 using EMV384 will be hard to achieve, there's almost a completely working implementation. It's a system to write these operations. It uses a code generation script. This way, it's easy to change how the arguments are encoded. This is almost finished, which wasn't the case when the discussion started. It is still limited to 384 bits. But the same instructions can be introduced to bigger bits, to cover more curves. + +**Danny Ryan**: Given the limited amount of people who do understand these curves, putting it into EVM might be risky, I'd be worried about the safety of putting these low level operations into EVM. In libraries, it's hard, but experts are available to audit. + +**Alex Vaslov**: Even if there is a tooling, we'd also need to worry about the safety of these tools as well. EVM 384 is progressing. The question is, how will it perform in different clients, as we've seen different performance in Go. + +**Axic**: EVM 384 performance requirement has been met. Upgrading precompiles is a lengthy process. EVM updates don't need a hardfork. With complexity, the EVM 384 op codes in most cases are the building blocks which BLS12 implementations use internally. + +**Danny Ryan**: If these implementations are completed, do we have someone capable of audititng them? + +**Axic**: I would say we do. I don't think it would take an order of 2-3 years. + +**Hudson Jameson**: Not to take all the time on this topic. The question wasn't if EVM384 is a good idea. But if EVM384 should replace EIP-2537 in Berlin. Otherwise, Berlin could be pushed well into next year if more discussion keeps happening. Personally, I think we should have both of them in. + +**Martin Hoist Swende**: There's a safety concern. + +**Tim Beiko**: Well, there's a safety concern with both of them. Having both of them just doubles the concern. But the risk doesn't multiply in any way. + +**Martin Hoist Swende**: Well it's not one to one. They both have unique attack surface. + +**Alex Vaslov**: Will we take a year testing and optimizing to give users a tool as cheap as possible to use? Or we ask them to pay 3x the price. + +**Hudson Jameson**: Also, Open Ethereum may have an audit for this EIP. + +**Marcelo**: Yes, the audit for this may be quite expensive, so we want to be sure it's going in. + +**Hudson Jameson**: It seems people are more on the fence on it. Martin, how do these security concerns level up to security concerns on other EIPs. + +**Martin Hoist Swende**: The client implementors can't audit the EVM code, or the test cases. So, it's a big unknown. If we implement it, there may be consensus issues, which may not be the end of the world. I have a preference for having a smaller service on the platform layer, and have people build on layer 2 (EVM layer) as much as possible. + +**James Hancock**: Say we do go ahead with it. It feels like this may take longer than 2-4 weeks to figure out. + +**Hudson Jameson**: How long until 384 is ready? + +**Axic**: The op codes are ready. But, I guess the question is whether a pairing operation will be ready. It's really hard to tell. Based on the progress of the past 4 weeks, I really hope we should have it done by next All Core Devs. + +**Martin Hoist Swende**: That work wouldn't need any hardfork to finish. We just deploy it, right? + +**Axic**: Having this pairing implementation, the reason is to have a fair comparison in terms of speed and cost. + +**James Hancock**: Let's say we decide this will not be in Berlin, but the next fork, how hard is it to remove from YOLO? + +**Martin Hoist Swende**: 10 minutes. + +**Danny Ryan**: When's the earliest and latest you estimate Berlin may happen? + +**Hudson Jameson**: Earliest is 2-3 months. + +**Tim Beiko**: If we rush, we could get it out by mid-December. But mid-January is probably a better estimate. That's by not considering arguing about BLS. + +**James Hancock**: My concern is less the performance, but the timeline with the community. There are scaling solutions who want to use the bLS curves. + +**James Hancock**: I'm leaning towards taking BLS out of Berlin, and putting it in later. + +**Danny Ryan**: As far as Eth2, people want it to add verification to avoid loss of funds. This is not a pre-requisite. For genesis deposits, this won't help. So it would be in subsequent deposits. The longer term thing is Eth2 client verification inside of Eth1. That's the major one, 10-12 months out. + +**Alex Vaslov**: For this particular purpose, with addition operations that require inversion may be prohibitively expensive, about 3x, on top of suboptimal performance. Specifically on BLS aggregation. + +**Danny Ryan**: It may be one transaction, out of 128, maybe 256, per 6.5 minutes. I don't know if that's cost prohibitive. + +**James Hancock**: Say the timeline is March/April of next year, does that timeline work? + +**Danny Ryan**: On the longterm, yes. + +**James Hancock**: I don't feel comfortable making a decision between EIP 2537 and EVM, but will push the EIP out of Berlin because it's taking too long. It keeps holding back all the other EIPs. + +**Tomasz**: I think we should separate Berlin into 3 paths. + +**James Hancock**: Berlin may come out in December, maybe January, but BLS would come after that. + +**Tomasz**: People will be pushing for additional new things. So, we may do some work in parallel. + +**Hudson Jameson**: Let's not have 2537 or EVM 384 in the next hardfork. We may do something where we split Berlin into two, as done with other hardforks. Hopefully by Berlin, we'll have a clearer way to show how people can push their EIP through the process. + +### Decisions + +- **99.1**โ€”For now, 2537 is out of YOLOv3, and delayed until after the next hardfork. + + +## 1.3 EIP-2537 fuzzing update + +Video | [59:43](https://youtu.be/GOWSrHtNZOQ?t=3583) +-|- + +Fuzzer was running on 8 cores, but bumped up to 32. + +The fuzzer generates valid and invalid inputs to Fuzz the Rust against the Golang implementation. + +Ran over a week, with 270 million iterations with no issues or incompatibilies. And an additional million rounds using the Geth RPC to get the full end-to-end intregation test. + +We expect to keep running this several more weeks. + + +# 2. Other updates / discussion + +## 2.1 EIP-2938 (Account Abstraction) + +Video | [1:15:28](https://youtu.be/GOWSrHtNZOQ?t=4528) +-|- + +We left off looking for feedback from last time. The author is interested in knowing what the remaining steps to be `CFI`? The author is looking to motion it into CFI the next ACD meeting. + +May review in a breakout room in Eth research discord. + +## 2.2 Ropsten issues + +Video | [1:22:53](https://youtu.be/GOWSrHtNZOQ?t=4973) +-|- + +Very few people mine on Ropsten. If anyone decides they want to take over Ropsten, it's random what damage they do. The only thing we can do is get people to mine on Ropsten. + +A few people have reached out for fixing Ropsten. + +Tomasz suggests creating a permissioned Ethash. Where it is PoW, but the block producers are under our control. That would solve the issue, otherwise, we just wait for the attacker to get bored, and it'll fix itself. + +Clients can make a list of addresses that are allowed to mine. + +Looking for someone to lead this. Will be discussed in the ACD chat, or maybe on the next agenda. + +## 2.3 EIP-2666 + +Video | [1:28:14](https://youtu.be/GOWSrHtNZOQ?t=5294) +-|- + +All developers have sent the benchmarks. The final numbers on the proposal are the status of things. Should not add any DOS attacks, but will streamline prices of operations. It's a simple constants change. + +Will discuss in the next meeting. + +--- + +# Annex + + +## Attendance +- Adri Massanet +- Alex (axic) +- Alex Vlasov +- Ansgar Deitrichs +- Brent Allsop +- Danny Ryan +- Dragan Rakita +- Greg Colvin +- Guillaume +- Hudson Jameson +- James +- James Hancock +- Jim Bennett +- Kelly +- Lightclient +- Marcelo Ruiz +- Martin Hoist Swende +- Micah Zoltou +- Peter Szilagyi +- Pooja Ranjan +- Rai Sur +- Sam Wilson +- Tim Beiko +- Tomasz Stanczak + + + +## Next Meeting Date/Time + +Friday November 13, 2020 14:00 UTC