# ETC core devcall 18

*Antoine(BESU):* Today we have a select set of items to discuss that have been listed on the agenda on the issue on this ECIP repository https://github.com/ethereumclassic/ECIPs/issues/432.
I believe all teams are represented and I can represent BESU Hyperledger. Magneto was a success, the BESU node is keeping up with the network. We're working on private permission networks and are envisioning toward the next session.
Earlier today there was an Ethereum core devcall where they were discussing that they might want to stop implementing any big feature EIP's until the merge is done, which will freeze future development.
I implemented EIP-3074 regarding AUTH & AUTHCALL, which is pretty cool. Who wants to speak for Core-Geth? https://github.com/hyperledger/besu/pull/2636

*Isaac(Core-Geth):* Core-geth runs fine on the Astor testnet, it also mines. GPU-mining hasn't been tested yet by me, is there anyone else that done that?

*Henry(EPICblockchain):* In the sha3-coalition telegram group they GPU mined on Cor-geth and it worked pretty well.

*Isaac(Core-Geth):* Great to hear! Right now we're refactoring it regarding the assumptions in the code about consensus engines and some of the configuration options and designs around difficulty and rewards. It's not perfectly separated from some of those other potentially engine agnostic configurations that networks may or may not want. That's the largest challenge, so we're trying to really separate it. Like Antoine previously stated we can mirror the implementation of the Ethash engine and replace the hashing function.
There are also other questions. It would be great to have a document with the Astor testnet specifications. Stating what Astor is supposed to have on it. Is it supposed to have monetairy policies, difficulty bomb diffusion, what are the block rewards actually supposed to be at any given point.

*Antoine(BESU):* This is exactly why I called this meeting. When we started we wanted to make it possible to mine the Keccak mining algorithm and would be compatible with existing stratum and all the clients. At this point we should move on to bigger and better things. We have proven this particular algorithm can work. We still need Mantis support for Keccak mining. Is there anything else that the Core-Geth team would like to add?

*Chris(Core-Geth):* No, I have nothing to add to what Isaac said.

*Antoine(BESU):* Anyone from the Mantis team to give an update on their client?

*Dom(Mantis):* Mantis is in the mode of discovering dragons in the code base. We are experiencing a few setbacks to get Keccak running. Essentially we're unable to connect to the Astor testnet. The underlying problems were so fundamental that we just had to just regroup. This should be out of the way next month. Beside we're spending a lot of time dealing with the internals of Mantis itself, this is our main focus.
We're catching up to Magneto and aim to pick up to Mystique fairly quickly. Magneto should be ready first half of september, that's our current best estimate. At that same time we would like to connect to the Astor testnet. That's the current status. The team is basically taking ownership of the pieces of code that were essentially dead for three years. That's the summary.

*Antoine(BESU):* The next item is concerning the take of the developer teams concerning the next possible upgrade hard fork for ETC? Since we don't use a base fee we set the value to '0' all the time.

*Afri Schoe(Core-Geth):* Apparantly Solidity, which is the main smart contract language, doesn't bowser for different EVM versions to natively support this base fee. This means that all EVM chains who doesn't plan this EIP-1559 upgrade will end up with a broken functionality. With this in mind it might be worse considering to have some kind of stop for base fee, it makes sense to have something in place even if it returns 'zero' or something. Just to make sure maximum compatibility with tooling.

*Isaac(Core-Geth):* To add on that point, 'zero' seems like the first and most obvious value for an inoperative code. I wonder it might be worth exploring, relative to that, a value like 'one' would be nominal and avoid problems like dividing by 'zero'. If you have a contract that you expect basefee to never equal 'zero', the pint is that doing math with zero can sometimes be sketchy. For contracts that care about overflows and the likes using a value like 'one', that's neglible, would avoid problems liek that. I'm not advocating this, I just want to put it out on the table as to another option to 'zero' which is almost equivalent.

*Antoine(BESU):* Knuckleheads could go testing with base fee set to 'zero' and based on what they find out whether EIP-1559 is lied or not. Just trying to see if they're in a private network with base fee set to 'zero' and do something or do something else in a public network. It might be good to have a configuration to set a fixed base fee, which is useful for a bunch of different reasons. Anything else?

*Cody(ChipprBots):* The alternative refund reduction might be controversial. This is to stop the gas-token but it does change the dynamics within the chain itself in the EVM. The way it works is by removing the refunds for self-destruct, it reduces the gas-refunds for a store to a lower level where the funds are still sustainable but it's insufficient for the current exploits to be a refund mechanism to make money. I haven't looked into it but the bottom line is that you don't get anything back on self-destructs anymore. The downside is that there's no encouragement for self destructing or cleaning up after your contracts, at the same time it keeps us from having a gas-token.

*Antoine(BESU):* My perspective on this is that we should align ourselves with Ethereum. They went that way as an experiment, it was a bad idea now let's go back. I'm ok with that. Next topic EIP-3541 which is a register of contracts that we can reserve for special purposes so in the case the dev wants to have contracts that aren't pre-compiled or special,so you can deploy it in that range if I remember correctly.

*Luke(Core-Geth):* One thing to make sure is that there's no contracts deployed on Ethereum but even ETC as well.

*Isaac(Core-Geth):* Another point I have marked as admitted is the new economic model for Ethereum where it burns the fees and the bomb delay which we don't need because it's already disabled.

*Cody(ChipprBots):* None of these points on EIP-1559 are critical to the ecosystem itself. We have time to plan this out and get all the test nets activated on it. Nothing is going to shutdown if it's not done before everyone's ready.

*Antoint(BESU):* We could wait for a month just to do more research and let the Mantis team catch up. Let's have a discussion in over a month.

*Cody(ChipprBots):* Do we know what will happen now if Solidity calls for a base fee since it's not really an upcode. Will it return an error if we don't have anything for whatever it is like 48 for example?

*Luke(Core-Geth):* It should be better to set the EVM version to Berlin.

*Antoine(BESU):* It's a major upgrade of the solidity language. As long as you're under a certain version you're fine.

*Isaac(Cor-Geth):* We did that for a long time with the older pragma, we were on 4.2 forever.

*Antoine(BESU):* Now that we've proven that Keccak mining is possible, that we can have multiple clients and come to consensus on Keccak mining. A very simplistic network was used, where the first block is mined without difficulty bomb.
Isaac is looking into this from a hollistic POV. Everything regarding managing the difficulty and the consensus checks etcetera. We didn't even go into what it would take to do a transition between Etchash and Keccak. There are a couple of things we could do under the same ECIP. As far as I can tell the current ECIP is done.
Keccak mining doesn't apply cleanly to ETC. The way to engage and make a transition possible is to think about all the flags and configuration that we would want. While I was focussed to get this to work I didn't think about what it would take to bridge the two consensus layers. One thing I would like to propose is to set a fixed difficulty for that block transition. I believe that would be required at this time to transition from a very high to lower difficulty block, because you expect the Keccak mining to be have a much lower difficulty on that transaction.

*Isaac(Core-Geth):* That concern makes sense. Hard coding a difficulty is definitely one way to do it. Another way would be to consider the difficulty algorithm itself. That's a fairly succinct function itself so that it behaves differently during a transition.

*Antoine(BESU):* To be clear we would not be setting a fixed difficulty but resetting the difficulty at that block. That is a pretty significant change and is a very interesting change to clients.
What would it take to create a network that is branching off mainnet. If you wanted to do that you need to take all the balances and states to be able to change the chain ID. Then you would be in a pickle because the difficulty of the mainnet is so high that you would to mine that new block into that new network. By having a way to reset the difficulty on the transition block helps everyone to get a fresh start. That way you're not setting the difficulty so that you have a lot more mining power. So the first few blocks are very easy for people to mine, then very quickly the difficulty algorithm kicks in and gets you back to safety into normal. The first ten blocks are going to be messy and then the difficulty goes up.

*Henry(EPICblockchain):* What's the adjustment delay for the difficulty?

*Antoine(BESU):* I think it's a percent per block.

*Isaac(Core-Geth):* It's a small number, less than a percent, it might be half a percent.

*Henry(EPICblockchain):* We'll go model it and see what that means. The numbers look good, you don't want to be like Grin where the difficulty took weeks to adjust. When they did their transition it was horrible.

*Antoine(BESU):* The difficulty between Etchash and Keccak have very little impact to each other. When the difficulty of Keccak is ten times less than Etchash, that the network is less secure. In general the difficulty of these two algorithms can't be compared, they are both different. What you want to achieve is to reach equilibrium when you get a block every certain seconds on average.

*Isaac(Core-Geth):* Does that mean that it's not necessarily the rate of one hash is going to be equivalent of one hash across both engines?

*Antoine(BESU):* That's correct, delivering hashes on Keccak is fairly easy because you're doing a different kind of computations, we're just in one switch to SHA-3. Even on CPU-mining I can do a fair number of hashes. If you do some math, it would take you a single CPU-core, max it out and see how many hashes a second you contribute with Etchash. Then you can see how many hashes you can contribute with Keccak. Even that comparison is going to be flawed because Etchash is incredibly memory intensive. This statement is to show that the network won't be less secure because the difficulty went down. We can go to a very high difficulty and there's a great video of Antonopoulos about this subject, who talks about when you go mining to a target of one or impossible to anyone to come up with a block that satisfy. We really have a really large band to find ourselves in a good position to mine.
The problem here would be that on the transition there's a gap of the Etchash difficulty that is so high compared to the amount of miners that are ready to mine on Keccak. This causes a delay before there's even enough hash power on chain before you need to be ready to take things on.

*Isaac(Core-Geth):* Our intuition is that the numbers like scalar difficulty value will be overall a greater value for Keccak that it would be for Etchash.

*Antoine(BESU):* I would venture to see that because I believe that Keccak is going to be spinning more hashes. It's easier to produce them.

*Isaac(Core-Geth):* Having a transition block with a low difficulty value is a very conservative approach that favors frequency of block production. One thing that is worth keeping in mind is that the current difficulty algorithm will grow speculatively half a percent per block for blocks that occur within the faster than average band, which is like one to eight seconds. That half percent is the maximum for blocks that occur in the average band, which is 9-17 seconds. Then the difficulty is unchanged in the child block but those bands continue all the way from 18 seconds all the way to 60 seconds, again still in eight seconds bands. For all those subsequent block times the difficulty algorithm is designed to fall at speculatively half a percent for each of those bands. The difficulty can only ever increase by half a percent but it can fall by one or two percent. When I say half a percent it's probably a quarter percent. The point is that the difficulty is designed to fall much faster than it is to rise.

*Antoine(BESU):* It's okay to be over the top and to have a hard time but for less time.

*Isaac(Core-Geth):* The problem with that approach is that although the difficulty will fall faster than it will rise, in case that the blocks are being produced slow, that it still relies on the occurence of blocks to have that calculation happen. If it's going to take seven hours and fifty minutes to produce a block after that. That's really long, even though it's falling as fast as it can. If you overestimate that difficulty then it still might not fall fast enough.

*Antoine(BESU):* If we were to make that transition, we would need to prepare some hash power in terms of Keccak mining that could be already on testnet. Then we can showcase that we have this much difficulty and when we set our sights on the transition block. We would have a configuration parameter that matches what we see in terms of hashing power from that test net to see what the capacity of it is. I think we should have the option to set the difficulty for the transition block because I find it useful regardless of this upgrade. It would be good to have and idea when or if that happens. We can put that into the configuration of the hard fork, this way we can have a smooth transition instead of having to play 'catch up' to different difficulty adjustments.

*Henry(EPICblockchain):* How much hashrate do you want to see on testnet?

*Antoine(BESU):* There's a computation of how much hash rate you can buy. That is being singled out for the fashion that some miners have been using to compare the cost of 51% attacks, to understand what it would take for me to create my own block and to take over the chain. What's the cost of a hardware length of that. I think it would ideally have to cover enough hash rate in terms of adjustment, to be safe against 51% attacks. Unfortunately it comes down to economic terms.
GPU-miners are able to create some pretty good hashrate, on the Astor testnet website there's a complete set of statistics about the hashrate you can expect from different mining devices out there. As long as you can do a market analysis of GPU-miners producing a lot of hashrate by dividing the cost of the current hashrate on testnet by the average price of the miners to see how much you have to rent on the AWS, even if the price is completely out of the ballpark. Someone involved could just rent a bunch of hashrate and make your life miserable. This is not taking in account the ASICs because that's a different closed economic system, honestly I wouldn't even know how to price it. When I think of it, there might be info on the Astor testnet website about that so we could count in the price as well. You would calculate which price of those mining devices are the most cost efficient for the hashrate they provide.
Then you go to the community and ask if everyone wants to move to the Keccak testnet, which is mirroring mainnet, nearly identical in terms of functionality. If you have 'x' amount of hashrate that equals 'x' amount of money, then we can conclude the network is secure. It would be interesting to calculate the price of Etchash securing the network and compare that with the Keccak to see which one offers more security. At that point you can decide when or if you want to transition. We're not there yet and I think we would want to achieve that operational level.
This Keccak mining and growth seems to be a very elegant solution compared to Etchash, which was more involved and memory centric.

*Henry(EPICblockchain):* Let me send out a couple e-mails to FPGA- and GPU-miners and see how much hashrate we can get on and stresstest or help with the projections.

*Antoine(BESU):* Until now we really were focusing on interrupts, making sure that Keccak mining would work and if it would be compatible with GPU-mining. Now that we've proven it works we can move on and some real activity in stead of a science experiment. Let's have the discussion in the media, on Discord or elsewhere to shutdown the Astor testnet, start a new Astor-like testnet. Where we have more states and see where we go from there.

*Henry(EPICblockchain):* The miners are probably only going to be conducive for a short period of time. There's and opportunity cost of mining.

*Antoine(BESU):* In that case we'll do a campaign where we ask miners to mine in a certain timeframe where they can show their support and we'll monitor the hash rates for that duration. It doesn't need to happen rightaway. My personal position is that Keccak mining is a good deterrent like having a tool on your belt that you have ready but I don't think there's an emergency to through that yet as far as I can tell. Let's wait for engaging community sentiment, listening to everyone and in the meanwhile have fun with it.

*Henry(EPICblockchain):* Ok, we'll discuss it more on Discord or on Telegram.

*Antoine(BESU):* Sure thing, that was it. To go back to the Core-Geth discussion, one interesting thing Isaac said that much of the specifications are expected for Etchash. That's something I agree with. There's a number of things around difficulty bombs or things that are Etchash specific. Then when I ported my Keccak, I just copied your code and all the flags came over. I started deleting those because the were getting in the way, where at block 200 000 the difficulty bombs started kicking in. That's something I hadn't thought about. If we want to have equivalent flags for Keccak, we need to keep those seperate from Etchash.

*Isaac(Core-Geth): That makes sense, this sounds like we're starting a conversation about starting a next testnet. Which probably is a strong idea and gives us an opportunity to design something educational. The liberty of having a tabula rasa can be really good.

*Antoine(BESU):* I would risk it to put you on the stand to say that we sould have a design for its bomb mechanism or something in mind. This is a good time to bring up the ECIP's. Right now there's nothing, we have no configuration. If Keccak-mining goes through the roof we don't have a way to stop the chain. We don't have anything around difficulty bombs whatsoever. If you want to have a way to harness this in some way, it's a good time to bring it up. If everyone on this call have an opinion on how this should be configured and wrangled speak up sooner than later when it's close to going live.

*Isaac(Core-Geth): What I would like to see for this case, because this is done in the context relative to ETC. From a design statement standpoint, designing a testnet that is relevant to ETC. Then you can start adding designs based upon the hard forks that took place in the history of ETC. We'll want to have these forks on this network. For me that's an important thing to see in stead of squishing all of the forks and start from the Magneto hard fork to go onward. This to make sure that all the configurations are right. In my experience, the majority of bugs with problems are going to be at least configuration related. Because so much else can be unit tested. Being able to mimic the upgrade pattern and history as relevantly as possible is going to be important.
Another thing to think about is that if we want to transition from Etchash to Keccak from the beginning. We don't have to, one of the things we can do is go through the normal process just like you would with any other chain. Define the initial configuration and then two months in you decide you're ready to make the transition, decide a block number, implement the configuration and then have a hard fork. From a very high level it might be interesting to, from a brainstorming projecting, having a series of transitions going from Etchash to Keccak back to Etchash and so on. In that case you have more than one shot at what that transition, most importantly, from Etchash to Keccak is going to look like. You also have a sort of safety net, well not sure if I want to call it a safety net but when for whatever cause you want to reverse the transition, you have the practise and the code ready.

*Antoine(BESU):* This is a great idea, that's a follow up for us to look into the test net make-up and how we go about it. I'm feeling pretty content, this ECIP is reaching its logical hand. Let's see how this PR goes, now it depends on other things. Around the configuration flags of Core-Geth, I'm not going to intervene or continue coding unless you ask me for help on this particular thing.

*Isaac(Core-Geth):* The only thing I would like to ask you in person is if it's all right, if we push another PR in lua of replacing yours. Only because we rebased it on master, there's going to be incompatibilities in Geth but if you're okay with either just moving to next PR or having us force on your PR.

*Antoine(BESU):* That's okay, at the end of the day I mean the goal is to get that support inside targets not how we go about it. It's your project, you own it.

*Isaac(Core-Geth):* It's your work, it's your commits, so yeah...

*Antoine(BESU):* One last item on the agenda that's relevant about Eth66 support coming up to Geth. It would be good to educate to our friends at Mantis. If the Eth66 support changes the way you would think about message exchanges inside the client. So if you're already catching up and having issues with the way the client communicates, Eth66 makes your life much easier. It adds an adaptive failure to each requested response. Before you had to guess about what you requested, you receive something but it doesn't really match but okay fine. That way you need to keep a lot of states around to make sure that you're getting what you thought you were getting right. Some languages like Go can actually do all sort of things, core things. Can I keep the state in there?
For example in Java and in Scala too I guess, because it's quite similar, you would have to have a mental model about how to communicate that. In Eth66 they changed everything, they added a wrapper that actually identifies every regression response. If you get a response and don't have a request for it you get an immediate disconnect. Everything else just works, you can have timeouts for any request not coming back to you with a response in some allotted time. Your whole logic for your communication layer goes from huge to five likes. If you you want to save yourself some trouble, my opinion is to go for Eth66. Don't even try to support anything else in between.
It's been fast-tracked because the Geth team said they're going to remove all other Eth sub protocol versions in the next release, that's comming up in the next two weeks.

*Dom(Mantis):* We're well aware, but thank you for making it plain and obvious that we need to move to it. It gives us more urgency around this topic.

*Antoine(BESU):* I know what keeps compatibility to EIP-1565 and lower. There are so many basic private networks that have good personal use. They perform so well so they need to have some level of backward compatibility. It's not going to be disregarded or removed from this zoo anytime soon.
FYI in approximately six months to a year from now, we would gladly get rid of that additional code if you can.
For the Core-Geth team do you have Eth66 support this time?

*Isaac(Core-Geth):* Yes, we have Eth65&66 support and snap one.

*Antoine(BESU):* In that case BESU needs to catch up to that. We will be in a good shape going forward on that.

*Cody(ChipprBots):* If you want to create a testnet more similar to the mainnet, the easiest way to do this would be to fork the mainnet once all the clients are online. Just set a block number the clients that fork off will be on that testnet.

*Antoine(BESU):* Yeah, I agree, I wanna fork mainnet that's a lot more fun, then everybody got account and balances. We can play a lot harder than if we have an empty testnet because just this faucet.

*Cody(ChipprBots):* When you fork off mainnet no one will probably have a problem with creating tokens just for the testnet, putting it in dev accounts.

*Antoine(BESU):* We came up with an idea to create a testnet that is forked of mainnet. Then it's running ahead of mainnet, making all sorts of weird promises, breaks etc. The interesting part was that if everybody gets the balances in that new mainnet, it's like an airdrop. All of sudden it gives the ability for everyone to continue playing, a much more realistic environment.
Thanks for attending, feedback is important. Anything you noticed that could've been done better, you can reach out to me on Discord. Ask me questions, I try to make myself available.
Next month we'll have another meeting to catch up. Where we will have a similar agenda, check-in on the teams, hard fork for Mystique and see if there's other topics of interest. https://github.com/ethereumclassic/ECIPs/issues/441