—----------------------------
Tim Beiko (00:00): Okay, let's try this again.
Trenton van Epps: Alright, sorry about that everybody. I'm getting rusty used to do this for ETHGlobal and we had this problem a lot. I forgotten my large call management skills, but now everybody's muted and we should be fine going forward.
Tim Beiko (0:23): Cool. Thanks, Trent. Okay, so let me repost the two blog posts and quickly kind of go back over it. Just want to make sure we have time for a bunch of questions. So we announced the Ropsten merge transition earlier this week. The first blog post link has all the clients versions that that are compatible with the upgrade as well as like a couple of notes for node operators and stakers. I think the first one of those is that obviously, if you're on both, you need to run both an execution layer and consensus layer client to participate in the transition on Ropsten. And there's a new API over which these two communicate called the Engine API. And this API requires a JWT, a secret for authentication. Most clients will generate it upon starting but you're going to need to pass it from basically the EL to the CL or vice versa. So that's something you should pay attention to when you're kind of setting up your notes. On this shaker side. This is probably the most important thing is after the merge. Stakers are the beneficiaries of priority fees on the network. So all the transaction fees that currently go to miners go to staker after the merge and in order to receive those, if you run a validator, you need to set what's called a fee recipient as part of your consensus layer client. So different clients have different ways to set this up. But whatever you're using, it's part of their documentation. So that's something you want to look into and this basically asks you for an ETH address where you want transaction fees to be sent to when you propose a block. And it's worth noting that this is just like a regular ETH address. So those fees are not locked on the beacon chain. They're like immediately accessible to you after that block is confirmed. Please do set that up to make sure that and tested on Ropsten to make sure that you can actually get transaction fees. And finally, this is the second blog post that I think so the merge is like a two step process. First, you need to activate an upgrade on the beacon chain called Bellatrix which basically starts listening for the merge to happen. And the way that it does that is it listens for a specific total difficulty proof of work value to be hit on the network. So like it just constantly pings the proof of work network and asks it, have you exceeded this total difficulty? If yes, parents who transition if not it pings again. So when we put out the releases earlier this week, we selected a really high terminal total difficulty and the reason for that is because the hash rate on Ropsten is super low, and it's easy for people to mess with it at a fairly low cost. And we wanted to make sure that the Bellatrix upgrade on the beacon chain was ready prior to choosing the actual terminal total difficulty. And so last night, that happened, and so this morning, we've just published a second blog post, which has kind of actual terminal total difficulty value at which we expect the transition to happen. And so all you need to do there is you need to pass this value to both your execution layer and the consensus layer client. And the blog post has literally the flag that you can copy and paste for every single client and I'll just post the actual value in the chat. So if you're already running something and you know how to do the override, you basically need to override the terminal total difficulty to this value. Yeah, I'll stop here to make sure we have time for plenty of questions.
Trenton van Epps (4:17): Yeah. Yeah, so if anybody has any questions related to that, just put them in the chat. Unfortunately, I'm gonna stay away from audio questions for now.
Tim Beiko (4:30): While we're waiting just worth noting, we do expect to hit this terminal total difficulty value and for the merge to happen on Ropsten late next week, probably around like Wednesday or Thursday. It's really hard to predict this because proof of work on testnets is very unstable. But I would strongly suggest just running this TTD override either today or early next week so that you're good when the merge happens. And one final note also for folks who prefer to only use the beacon chain, one thing to note is that for when the merge happens, you want to have a fully synced consensus layer client on the beacon chain and execution layer client. If you've only ever used the beacon chain, you will think that syncing is quite fast. You will be disappointed when you try to sync on the execution layer side. So please be mindful that it could take up to a few days to sync a node on Ropsten. So if you want that by the end of next week I would suggest getting that started either today or early next week. And it's fine. Also, if you're just syncing your node, and you still don't have the merge client versions, that's totally fine. You can start your sync, update your client and then and then finish your sync with a new client. Okay, now there's like a ton of questions. So I'll just like going through that. What's the best way to determine transaction finality, at least one execution after the merge using the standard JSON RPC? Is it possible still? Yep, so basically, today there is no way to determine a transaction finality on the execution layer. Under proof of work, all you get is probabilistic finality, where as more and more blocks accumulates the odds of a reorg get much lower. At the merge, we're going to include a new flag in JSON RPC called Finalized, which you can use when creating a new block just like us latest today, and that returns the last finalized block on the chain. And this block cannot be reverted unless there's basically a major attack on the network. So if you want to determine basically finality, JSON RPC will have a flag for that and if it returns a block in the last slot that was finalized, basically. And then there's a second question about the Paris upgrade on the EL and what does that do and how does it work alongside Bellatrix, so these names are really confusing, and that's why you should try to call everything the merge, but basically, at a very high level, the merge is this entire process which has different parts, for the first part is for the beacon chain, to start pinging the execution layer chain and asking it, are you ready for the merge? And this is what we basically call Bellatrix. So the beacon chain becomes aware that there will be a transition that it will need to include specific payloads which contain user transactions at a certain time, and starts pinging the clients for that then obviously run through the entire merge. Once that happens. On the execution layer side, we also have changes which happened at the merge, and we've called those Paris and it's a bit weird because unlike a previous hard fork, these changes don't apply starting at a specific block number. They apply only when we hit this terminal total difficulty value. And so in practice, you know what those changes do is first they start handling Engine API calls from the consensus layer. They stop listening to proof of work as a way to get the next block. And then there's a couple of small changes. For example, the Difficulty opcode now becomes the Prevrandao opcode. Some parts of the block headers are are now zero going forward. So there's all these changes in behavior caused by the merge. And that set of changes on the execution layer is what we call Paris. But basically Paris is what happens on the execution layer when TTD is hit. But it's a bit confusing to call that Paris and not just the merge. So we've mostly used the merge but Paris is just like the formal name of this specification for execution layer changes when the merge happens. Are we safe to keep mining on Ropsten for that Ropsten ETH or should we switch off the current hash rate is fine on Ropsten we're getting increased hits early next week in order to hit the merge sometime next week. But if you were already mining yeah, and that's that's fine. There's no need to take it off. And the next question is kind of similar around how much hash power? I'm not sure the exact number but I think if community members want to start helping to mine, I would ask that you kind of hold off until like late Monday or Tuesday. Just because it gives more people time to upgrade their TTD. How long does it take for Geth nodes to fully sync in archival mode? I actually don't know the answer to that question. You don't need a full archive node by the way to run as a consensus layer client you can just run as an execution layer client on the merge. You can just run basically a snap sync on Geth. Snap sync takes on the order of hours assuming you have a good internet connection. I'm not sure quite how many exactly. but an archive node I don't know it would take you probably more than a week just to do a full archive sync I don't know if there's anyone from Geth on the call who can answer this? Anyways, if so, I'll try and find them. Is the expectation to hit June 8/9 as a natural hash rate. Or do we need to rent hash rate? So again, we're going to need to rent a little bit. I've seen that both the consensus client has its own databases. It's recommended to run both on the same server. Yes, like yes, they both have their database. I don't know. I see a lot of people like from client teams here. I see Fredrik from the EF does anyone like from either a client team or the EF one or maybe take a couple minutes and explain how they set up everything and what you all think the best practices are? Raise your hand I guess Trenton can unmute you.
Trenton Van Epps (11:51): Any takers?
Tim Beiko (11:54): Yeah. The short answer to the question is yes, but I think it might be helpful to get someone from a client team to walk through how to set it up and I'm gonna have to unmute person thank you.
Thorsten Behrens (12:15): Sorry, not a client team. I just run nodes professionally.
Tim Beiko (12:17): That's perfect.
Thorsten Behrens (12:19): So what we're doing is we're running CL EL combos on one machine. We typically have this be something relatively beefy for the storage like a two terabyte NVMe and then you know 32 Giga RAM or so 16 is fine, too. So short answer. Yes, you absolutely can we expect the same amount of resource usage, as we see now pre merge, as long as there's both a consensus layer and an execution layer client running on the machine. And there was a second question as to Can I still run my validator client somewhere else and pointed at wherever I want to go? Yes, absolutely. Still works.
Tim Beiko (13:04): Awesome. Thank you. Next question, is there consensus client recommended by you? Short answer is no. So in the Ropsten blog posts, we link that but client diversity matters a lot on the network, especially after the merge. So we recommend that people run minority clients, if they can, just because if there's a bug in any of the clients, you don't want that client to have more than ideally, a third and especially not two thirds of the clients on the network. Because if there was a bug in the client with more than a third of those on the network, you could stop the network from finalizing and if it was more than two thirds, it could finalize something that was wrong. And that's really a situation we want to avoid. So we really suggest that people run them and our minority clients, and in the original Ropsten blog posts, there's a link right above the client versions table that shows you what's the current mark, basically, network share of every single client. So you can make a decision based on that. And there's also a really good post by Dankrad that's linked right next to it, which goes into like technical details about what are the actual risks if there's a majority client that has more than a third or more than two thirds of the stake on the network. So I guess, or my personal recommendation would be a minority clients but I don't have a strong one beyond that. Okay, and then the second question was, the next question was answered. Then Nick had a question How different is implementing the merge on Ropsten versus other testnet if the merge is successful on Ropsten should be pretty confident the next couple of testnets. The short answer is I guess there's no short answer. The answer is we're doing Ropsten probably a bit earlier than we otherwise would in the process. And the reason is because it's such a big change relative to other upgrades for node operators. We wanted to make sure that people kind of got to try it early. And then if stuff goes wrong with your setup, you have plenty of time to fix it. And so obviously, Ropsten going well is like a good indicator. But we do know that there's like a bunch of testnets to fix clients still have some issues here and there. So it's not a given that just because Ropsten is successful then two weeks from now we move to the next testnet. I think for the next one, we'll want to have things a bit more polished. But yeah, we thought it was really important to to give the community an opportunity to run through the merge kind of ASAP so that we can find any issues before we move to the other testnets.
Tim Beiko (15:58): Yeah, good question about testnet deprecation. So, to confirm the two testnets that we intend to maintain long term after the Merge are Goerli and Sepolia. Goerli and basically the Prater beacon chain that's associated with it, which will merge and call on Goerli afterwards. But that combination and Sepolia which is a new testnet that we recently launched, Etherscan has just added support for it. And and that will be maintained in the medium to long term as well. So for the other testnets, you have Ropsten, which we're obviously running through the Merge now. We intend to deprecate it after the Merge. I'm not sure exactly when, but you can expect some time before the end of the year. We have another test that's called Rinkeby, which runs proof of authority consensus algorithm. This one is not being run through the Merge. So if you have stuff on Rinkeby, it means that once the Merge happens on mainnet, Rinkeby won't be a good copy of mainnet for you to test on. For smart contract developers, it shouldn't change too much, except from this Difficulty opcode but if you're testing infrastructure and stuff, then it'll be quite different. So Rinkeby again, we're not gonna shut it down overnight. It'll probably stay up until late this year. But as of the Merge, we basically consider it to be deprecated. And then lastly, there's Kiln that's mentioned so Kiln was the new testnet that we spun up. Basically just test the Merge. We launched it in March and the goal there was to get some early testing from the community about, do these nodes work together, can you deploy your smart contract and kind of use Ethereum and post merge? So we've launched that, and that was always the purpose was just to test the merge. So I suspect we'll leave that one up until the merge on mainnet deprecated pretty quickly after. So just to summarize, Rinkeby it's just not being transitioned and will probably be shut down by the end of this year. Kiln is already beyond the Merge and will be shut down shortly after the mainnet merge. Ropsten is transitioning as we're talking about today, and will be shut down later this year. And then Goerli and Sepolia will both transition and will carry on medium to long term.
Trenton Van Epps (18:32): I just put a link to a big summary from Avri in the chat if people want to read a little bit longer about that. And yeah, Phil, if you want to jump in now about minority clients.
Phil Ngo (18:42): Hi everyone. Yeah, so for minority clients. I mean, great thing that you mentioned, Lodestar is Ropsten ready. So for people who do want to set it up, we actually have a pretty cool merge script. That is basically like a one line command startup. They'll start up a Lodestar beacon node alongside the execution layer. Right now, you can choose between Geth, Nethermind and Besu. So you can check that out on our GitHub page github.com/chainsafe/lodestar and then under the Kiln folder, under dev nets, all the instructions are there. You can also find all of that stuff in some of our Chainsafe blog posts. We do have setup guides and some videos for you as well, which I can post into the issues for this meeting afterwards as well. In terms of hardware specs, it's nothing fancy, just a normal, even 16 gigabyte RAM, pretty modern type of processor will be able to handle it all. And we do recommend that people use Docker with Lodestar in terms of preventing NPM type, supply chain attacks and stuff like that. So if you do run Docker, you shouldn't have a problem setting up Lodestar.
Tim Beiko (20:08): Okay, do any other minority clients want to take a minute or two to shill their clients? I'm happy for us to make this space for that. I see some Nethermind people here. Yeah. Tomasz, go for it.
Tomasz Stańczak (20:30): Hey, sure, you know some of the (audio cut off) or be maintenance ready and introduced recently the stop saying that gives you something like around three, three hours to sync and snap sync mode with the mainnet. And you can use it on practically all the network that will be going for the Merge testing. It does sync with all the shadow fork assessments and so on. So yeah, like you're really encouraged to run it. It's also have a look at the documentation at docs that Nethermind.io. This one is being updated constantly. Now we have two or three people working on the new docs. There's lots of examples of how to launch the client in different configurations that the Nethermind team is also running, data mining and practically all the other like combination of nodes as part of our own validating, staking. So all works, and you're invited to ask us questions, join on Discord, share on Twitter and so on. Much appreciated. Thanks.
Tim Beiko (21:34): Thank you and Matthew from Besu.
Matthew (21:41): Yep, that's right. Similar story to what was just said. We are a minority client with Besu and we have a lot of great features that we'd love folks to test out as well like snap sync and our Banzai storage format, which we're eager to get folks using, especially on these testnets so that we can, of course make sure that we're even more merge ready, but we do have stuff up and running on Ropsten right now. So we would love for you to check us out. Try us out. We have support for a bunch of different platform types. So whatever platform you have will likely be supported with native support so you can get great performance there. And of course always want to see more and more participation in more and more usage of these features. Reach us on Discord give us some feedback, let us know how everything is going. You know, and we would always of course, we're going to be participating ourselves. So we'll probably have some results to share after the actual merge and we're looking forward to putting out some more material around the merge as well. So, of course you can find the [email protected] and you can find a lot of material on the hyper ledger discord and the consensus discord and different blog posts on Twitter and consensys.net.
Tim Beiko (22:55): Thank you. I know Geth and Prysm also here so if you guys want to give a quick shout out also, please do. It feels wrong to not allow it with the disclaimer that they are the two majority clients. Anyone from Geth and Prysm want to give a quick update?
Trenton Van Epps (23:19): They can talk but they only get seven seconds.
Tim Beiko (23:30): I got a thumbs up from Marius is that you want to talk, Marius? Okay, Marius.
Marius (23:48): Hey, yeah, we are happy that other clients are having some progress and you should really try them out. See how it works out with them. And you're also happy to try out Geth. That's it seven seconds. Awesome.
Terence Tsao (24:10): I just wanted to add that other clients are great. So definitely try every single one of these clients and give us feedback. At the end of the day the feedback is very important. So if you have one client better than the other client, please share that with the other client. I just want to add that.
Tim Beiko (24:30): Yeah, great point. Any other client teams here that I missed or just I need to like scroll back and forth the Zoom participants, but, last call client teams. I think that's that's everyone we have.
Trenton Van Epps (24:47): Okay, I'm scrolling through the questions and want to make sure. Did we answer this Kiln question?
Tim Beiko (24:54): No, that I was gonna get to that. Yeah.
Trenton Van Epps (24:57): Okay. Perfect. Okay, so yeah, the same spot. Go ahead.
Tim Beiko (24:59): Yeah, so, "Seamonkey" asks about whether it's still worthwhile to have validators on Kiln or should he shift or should they shift their resources all over to Ropsten. And there's an answer from Thorsten already in the chat, like at Kiln is the only network where we're currently testing MeV boost, so there's obviously value there. But with regards to just kind of running a bunch of validators and testing there, I want to say that it makes sense to move to Ropsten rather than Kiln but if anyone on the clients or testing team this year disagrees with me, can you please speak up? My instinct would be yes. But I would confirm it in the R&D Discord just in case there's something I'm missing. Yeah, that means it's still valuable to do it on the Kiln Okay, next question. Recently had to delete Prysm beacon chain data to fix syncing issues. It took about three days in Prysm. Is this normal? Is this normal amount of time? Terence you want to take that?
Terence Tsao (26:17): Yeah, we do get a feedback a lot. So we are actually lending we subjectively sync in our latest release. So please do try that. The documentation is out there. I will paste the documentation in the chat. So if you start with analyzed state for which is we subject the syncing it is much faster.
Tim Beiko (26:39): Awesome, thanks. Next question. Is it possible to test the merge with Ropsten first? Is is possible to lower TTD since Patrick is already activated, so that's what we did. I'm not sure I understand the question. But basically the new TTD is much lower and this is why people need to override to it and Ropsten will be the first public testnet to run through the Merge. But I'm not sure if I'm actually answering your question, Gabriel. Do you want to raise your hand I can take you off mute, if that doesn't answer your question.
Trenton Van Epps (27:20): Is there a work as faucet for Ropsten I think is the next question. Oh, that's been answered. Perfect.
Tim Beiko (27:29): Yeah. Oh, yeah, there was a question about Kovan and and I saw I think Martin from Gnosis is on the call. Do you all have a data Kovan? Or should we just consider it to be deprecated? I'm not quite sure what the status is there actually.
Trenton Van Epps (27:52): Martin if you're able to talk, just raise your hand and then we can unmute you, if not, the chat is fine.
Martin (28:08): Yes, sorry. The question was about Kovan. Whether that would or what was the question?
Tim Beiko (28:13): Yeah, is Covan gonna run through the Merge as I understand it.
Martin (28:18): Right. Right. Right. Right. So no, it will not because Kovan is essentially open Ethereum only and yeah, after announcing three times, that open Ethereum is dead. I think it's finally really dead. So, on our end, a little bit of context, maybe it's on Gnosis perform x now Gnosis chain, we will are still planning to do our merge probability, but currently targeting to do it. Yeah, shortly before Ethereum we are currently developing that we will do our own kind of our new testnet to test there, as well. Publish that roadmap very soon, but long story short Kovan will not play a role in that because the merge will be done with Nethermind in Erigon and again Kovan is open Ethereum and open Ethereum is dead.
Tim Beiko (29:22): Got it. Thanks for clarifying. Okay, and Gabriel has his hand up for the previous question. So I think I've unmuted you.
Gabriel (29:33): Thanks. Hi. I just need like 20 seconds. So my question is about the TTD because I am a node operator. So we are kind of scared to run some nodes everything on June 8. So we would like to just test that the consensus client is it's working. We made a good connection with the JWT and everything is working well before June 8. If it's possible to lower it even more.
Tim Beiko (30:00): Yes, yes, yes. Oh, so we're not going to lower it on Ropsten but basically, you should by setting up your execution and consensus layer they like you should be able to know that like they're working together to the CL is (inaudible), the El that your JWT token is set up right. So you don't need to hit the TTD for that. But you want all of those things to be set up and working before the TTD hits because that's when you actually run through the merge. So you Yeah, it should be they shouldn't be anything stopping you from from updating everything today and making sure that it works. And then once we hit TTD they're just gonna run through the merge but you should kind of that there shouldn't be like a blocker before that. Does that make sense? If you have another question maybe post it in the chat but yeah, I think you should be alright. Thorsten you want it to shill your automation tool that supports all nine clients. I think we can allow that.
Thorsten (31:19): Alright, thank you. So I'm gonna keep this brief. I have an automation tool called F-Docker at FDocker.net. It supports all nine clients for Ropsten. It uses the official releases from the client teams. It also supports MEV boost, but I think right this very second it's only Lighthouse that actually has that implemented and we don't have a relay yet for Ropsten but we might get one. So that's it. Just if you want to try things out, switch clients around quickly, all nine clients are supported.
Trenton Van Epps (31:55): Can you share a link to it? I wasn't able to find it.
Tim Beiko (32:00): Yeah in the chat that would be great.
Trenton Van Epps (32:10): Oh, I wrote I think I wrote out dash
Tim Beiko (32:14): Okay, next question was working faucet for Ropsnet there was already a couple shared and there's a link I just shared in the chat that like is pretty good across all testnets. It tells you like what are all the faucets, do they have money in them. And so it's a good just general faucet tool to see where you can find some testnet ETH. Okay, lots of comments. Have you heard from Infura or have a Ropsten CL checkpoint sync endpoint? I have not. Is anyone from
Remy Roy (32:48): I answered that one. I'm not sure if there's any Infura people here but they confirmed that they will not be doing a Ropsten CL endpoint.
Tim Beiko (32:56): Got it. Okay. How can people contribute to the Ropsten merge if you don't run a client? Yeah, running a client? I mean, so there's a couple of things like one is, running a client and reporting any issues is really good. And when I mean reporting any issues, it doesn't have to be necessarily technical issues. If you're trying to run a client and the documentation for the clients you're trying to use is just really unclear, trying to highlight that is also useful. So it doesn't only have to be an actual technical issue. I think the other bit that's really helpful is if you are a smart contract developer, or just a tool in your infrastructure provider, running through a full deploy on either Kiln or Ropsten post merge is really helpful. And we don't expect anything to break at the contract level or at the tooling level. But it's just, because I don't know if you use a bunch of automation tools or deploy scripts and stuff like that, there might be weird things that do end up breaking even though the network is stable and finding those issues is really important. Yeah, and I think that's really the two biggest ones. Beyond that, I think it's just trying to use this stuff on Kiln but yeah, most of the value is really just either running a node. And to be clear when you run a client that doesn't necessarily mean the validator, like you can just run a node and sync it and make sure that works as well. So it doesn't have to be an actual validator that's running and then trying not only to deploy a smart contract, but more to deploy an entire kind of application, it would have front end that's linked to the smart contract. And stuff like that. I suspect if there were things that broke it would be in these tool chains rather than the actual code of the smart contract itself on the network.
Tim Beiko (35:00): Okay, next question. What are the odds that somebody controls the new TTD? I mean, I don't know what the odds are, but, you know it is possible it does not cost hundreds of 1000s of dollars to do this. So the worst case scenario there is it would be a bit more annoying for end users who want to run their own at home validators who haven't already upgraded or overridden their TTD. So we recommend people do that as quickly as possible. All of the vast majority of the validators though on the network are controlled by client teams and the testing teams and whatnot. So all of those have already been upgraded. So from the network's perspective, you know, even if the TTD was hit foul, it will run through the merge and be fine from an end user who's trying to test their validator setup. If they haven't had time to do the override, it would be a bit annoying because then they need to do the override. They might have to manually set a specific block as the head or as valid as part of the chain. So it's not ideal. There's not really a great solution against this because hash rate on testnets is just so low, and it's so cheap to mess with them.
Tim Beiko (36:14): Okay, some comments about clients. Okay, does Geth need to be fully caught up for Lighthouse to be able to talk to it. I'm seeing below an error in Lighthouse while Geth is syncing. Marius, do you want to do you want to get that?
Marius (36:48): Yeah, I already answered that, but yeah, so I Geth doesn't need to be fully synced and postmarked. Of course will not be fully synced. When you start up a node. You will start both consensus layer node and the execution layer node. And yeah, it might just be a configuration problem in that case, but I also saw a bunch of times that Lighthouse would just log this error out if something seems so might just be logging issue, but yeah, you should
Remy Roy (37:41): I believe it's more like a warning.
Marius (37:43): Yes. A warning.
Tim Beiko (37:52): OK, yeah. So as sidetracking the difficulty increasing. So Trent shared right in the chat. I'm not sure. The thing is these estimates are only good if the hashrate stays stable, which we don't expect to do, because we're gonna want to accelerate the hashrate sometime next week to make sure we hit this TTD value next week. Yeah, the total difficulty is part of the block header. So if you go on Etherscan and you look at the last block, you can see the total difficulty, but I wouldn't trust the estimations too much because you can basically make it happen much quicker. Or much slower, based on pretty small changes in hashrate. So we're hoping to have it hit around Wednesday, Thursday next week. But if it hits on Monday, because someone adds a bunch of hashrates over the weekend, that is a possibility. So the best thing you can do as a user is just make sure that you have the TTD override which is literally copy pasting two lines when you start your client and that will make sure that your regardless of when it hits your client is ready.
Tim Beiko (39:19): So okay, so there's a question about ETH1 endpoints, fallbacks. Thorston you answered but I guess Gabriel if there's any follow ups, you can ask them in the chat.
Gabriel (39:36): Soon as the transaction format?
Tim Beiko (39:40): Is the transaction format gonna change after the merge? Basically, no. So the thing that does change so transaction formats in EL are unchanged. Block header formats are also unchanged, but some of the block values will be set to zero. The block format of the consensus layer does change after the merge and that's something that if you are basically using these API's the baecon API's, that will change but on the execution layer, the block format the transaction formats are the same.
Tim Beiko (40:27): Are there any plans to not publish the minutes to get to the public until about a week left from it? Yeah, that's a good question. It's hard. So there's different approaches we can do here but the thing we want to avoid is the TTD being shipped prior to Bellatrix being activated on the beacon chain. If so, one way to do that is we can activate Bellatrix on the beacon chain quite early on mainnet, and it basically does nothing in terms of functionality until the TTD is here so that gives us a chance with, we could have just a first kind release with Bellatrix and have a TTD of basically infinity and then we can choose the actual TTD. In terms of how much of a heads up we give people. I would personally prefer it to be longer than a week for people to upgrade because its mainnet. And it's also worth noting on mainnet the risk is a bit different. So on mainnet in proof of work, we have the assumption that nobody can double the hashrate overnight because otherwise it would be 51% attack the chain. So you know if we're happy to say to the properties of proof of work, we already have this assumption that 2x of the hashrate is not going to come up. So that means you can never hit, you know that the TTD more than twice as quick as you'd expect. And even in practice that the hashrate fluctuations are much much smaller than that. The thing that might happen though on mainnet is that because the merge is happening, hashrates starts to drop from the network because people sell their GPUs. So that would mean that it would take us longer to hit the TTD. So there's a world where imagine we say okay, this is the value we expected to hit in two weeks, but people start to sell their mining equipment that maybe we hit it in like three weeks instead of that because the hash rate has gone down on the network. If it were to go down, like to the extreme, you know, say instead of two weeks, it's going to take us 16 weeks to hit it. Then we can basically do another override to another even lower value and kind of not wait that entire time we'd like to reduce security on the network because of a really low hashrate for months. So yeah, we haven't quite decided the rollout plan for mainnet yet. We would (inaudible) for sure. We'd like Bellatrix to be activated well before we hit the TTD. And it's usually much easier to make sure that happens because it's highly improbable that a massive amount of hashrate just shows up out of nowhere on a chain that has like a Ethereum's level of hashrate already.
Tim Beiko (43:11): Is there any reason to expect apps to have more difficulty with the merge than any other hard fork, such as with the benign for smart contracts? No. Short answer, I think, for infrastructure and tooling providers the merge is probably a bit more complex than 50 and 59. Especially if you only cared about either the beacon chain or the application layer before so for smart contract developers and whatnot I don't think it is. There were two changes mentioned earlier in the chat where one is just the block time goes from like 13 seconds on average to like always a multiple of 12 seconds. It's not necessary, really that there's a block every 12 seconds because a validator might be offline, but you kind of get a change in the block time dynamics. If you're doing stuff like calculating API is based on the number of blocks or stuff that will be affected. And then the other thing is that this Difficulty opcode changes to Prevrandao. So it's still a pseudo random values. If you're using Difficulty for pseudo randomness and your smart contract, it's still going to keep working. The only difference is the size of the value. So off the top of my head I think the difficulty value is like two to the 64, whereas the Prevrandao is two to the 56. So that's the only thing that kind of changes like the size of that return value. And this is actually a neat way to know as a smart contract that the merge has happened. You can just call this opcode. And if the return value is a two to the 56 size, then you know that you're in a post merge Ethereum.
Tim Beiko (44:51): Okay, bunch of Lighthouse configs.
Trenton Van Epps (44:56): Thorsten do you want to just read out what you shared in the chat for the recording that question?
Thorsten (45:07): Okay, what am I saying?
Trenton Van Epps (45:10): Someone had asked whether they could just skip the testnets and validate.
Thorsten (45:17): Oh yea. It's it's really dangerous to do that or risky. At least.
Trenton Van Epps (45:22): Read out the question. First. Read up the question.
Thorsten (45:25): Yes. Okay. Sorry. So the question is validating on the BC I'm assuming that means beacon chain, can I simply stay on the BC main net and not try out the testnets and wait for the merge to happen on mainnet? So taking it literally, sorta kinda, yes, as long as you adjust your conflict to have a fee recipient, which is really important and to use the Engine API once ATTD has actually been announced on mainnet. Authenticated on typically port 8551 JWT secret. Now, that sounds like a change right? It is. If you don't test that your configuration works beforehand, then chances are your configuration won't work. If you don't make these changes you won't go through merge. So, you know, my recommendation just is find yourself a cheap little VPS somewhere, try it out. Learn how to do this, how to change your current setup to one that supports merge. And then make the change on mainnet when it's time to do so. Not now.
Trenton Van Epps (46:41) Thank you.
Tim Beiko (46:48): Okay. Yeah, we only have three minutes left, but I think we cleared the queue of questions. Anything else? Any final questions people had?
Trenton Van Epps (46:58): Pooja you do want to share your calls.
Pooja (47:02): So Catherders are planning separate talks by different EL and CL clients where you can get more information about the latest specs already we are having a lot of blogs going out from the foundation but if you have any client specific questions, you are invited to join (inaudible) talks with different clients or you can also follow the recording later on. Catherders YouTube added in the link here.
Trenton Van Epps (47:28): Yeah, I guess just generally if if you are running a validator and you haven't participated in any of the the other testnets like Kiln now would be the time. Obviously you're not obligated to like like Thorsten mentioned you don't have to but it's probably in your long term, best interest to have an understanding of how these configurations get set up. Just so you know, you have peace of mind that you understand how the merge is coming and you're prepared for it. And then like Pooja mentioned those calls will probably run this call at least a few more times before the merge. For general questions and things related to cadence or timing, just to make sure we're getting that information out there. But if you have technical questions, definitely start going into the client Discord. They're going to be the best place where you can get information for technical troubleshooting or the ETHStaker Discord is also a great, great resource as well.
Tim Beiko (48:33): Yeah, and then there's one final question that I just want to touch on this testnet thing as well. I think it's also worth noting that like Goerli and Sepolia will probably happen much closer to the mainnet merge than Ropsten, I mean, by definition, but also just in terms of delay between delays between them. So if you are just waiting, you know, obviously we can't force you to use Ropsten but if you're just waiting and then you go just on Goerli and you realize you need weeks and maybe months to update your setup. Then, you know, we might have scheduled the merge by then. So I don't think realistically should take anyone who's already reading your validator months to adapt to this. But yeah, just note that the delay will be shorter there. And yeah, Jonas asked about better articles about running validators. We are working on it. There's a bunch of different efforts on that point. So yeah, we'll have more of those definitely in the coming weeks and months. And then finally, there was a question about finality for transactions. So basically, transactions themselves don't really have the concept of finality, it's more blocks. And today on proof of work, there is kind of no explicit finality. So after the merge, basically, if a transaction is part of a block and that block has been finalized, by the proof of stake chain, then we consider it final or finalized as well. So like the transaction that's within that block would be finalized. And basically what that means is for that transaction to be reordered, an attacker would be willing with me they like have control over more than two thirds of the stakes and be able to, to basically write an alternative history and that's it. That's basically the same level more or less of guarantee that you have under under Bitcoin or under proof of work sorry, with a 51% attack. So for all kinds of intents and purposes, that's usually pretty final. And then again, this will be exposed to new JSON RPC API, so it's much easier for applications to actually query with the latest finalize block and return that information to their users.
Trenton Van Epps (51:05): And I just shared a link to the Google group that we're running for announcements. If you're interested in getting notified whenever there's a new blog post released about something related to the merge or Ethereum generally, but obviously these next few months are going to be focused on the merge. That's probably the best way to make sure you don't miss something. And then obviously, as important milestones are reached, we'll broadcast them on the typical channels like Twitter, the R&D Discord, all the client Discord, things like that. Anybody have any final questions?
Marius (51:51): You will probably run into a bunch of bugs. You might run into a bunch of bugs, setting up this stuff and if you do so, please, please please send them to client teams so that we could fix them. And make sure to test your setups, make sure to notify us if something goes really wrong. And I think we also increase the bug bounties and we will also be increasing the bug bounties around the merge, especially for like the merge with the software. And so yeah. Looking forward to all you testing our stuff.
Trenton Van Epps (52:45): Alright, if there's no other questions or comments, thank you everybody for coming. Like I said, we'll probably be running this again in the future on a more regular basis. So, however you found this, keep tracking those channels. I've been tweeting it a lot. But yeah, whenever the next one is we'll be sure to announce it. And yeah, the merge is coming soon. Tim, you have anything else?
Tim Beiko (53:11): No, that's it. Thanks, everyone who showed up.
Trenton Van Epps (53:16): All right. Have a good weekend. Bye.
- Trenton Van Epps
- Thorsten Behrens
- Phil Ngo
- Tim Beiko
- Tomasz Stańczak
- Matthew from Besu
- Remy Roy
- Gabriel
- Terence Tsao
- Hadrien Croubois
- Caio Vicentino
- Marius VanDer Wijden
- Pooja Ranjan