 Hi everyone. Hello. Hello. Hello, everybody. Hey there, Francesco. Let me get the agenda up. A lot of folks today, huh? How are you, Matt? All good? Yeah, not too bad. Yeah. Cool, cool. You see my screen? Awesome. Do you want to refresh this? I just changed one thing. Oh yes, of course. We'll take the other one to take some notes. There you are. I guess we can get started. Well, I can get us started off. We have a good group of people here today. Yeah. The Any trust notice. Just go ahead and read that. If you haven't, it's very straightforward. Don't, you know, make sure you're following the code of conducts. We're being recorded and. You know, if you have questions, I'm not a huge fan of the raise hand feature. I think we're all adults here. We can figure it out. But either way, the quarter to report is due at some point in the next couple of weeks. I will work on this, but I might poll folks for. Contributions. So if you have major updates that you want to have highlighted in the Q2 report. Feel free to drop them in the contributors channel. I think we have a bunch of new. Contributors, so it should be good to highlight. So if you want some of the contributions highlighted, definitely put it in the Q2 or definitely put it in that channel and I can include everything in the report. If you're not familiar with these reports are they live on the Hyperledger GitHub. They basically just. They just put it in the Q2 report on previous updates to the project over the past quarter, including, you know, contributor growth and other good stuff. I know where the items all being sure to include all that stuff there. The CIP update. It's less relevant for folks that are on the call right now. Because Diego and Dan are both absent, but the. The client incentive program is being updated. So we're going to check some changes. With the way that ETC is contributing to basic. So nothing too urgent there, but small update. Release. Updates of 23.4.1 was put out. Last week, I believe. With the new transaction pull format. And, you know, a host of other fixes. And there is also a new to any release cooking up, but we don't have any. We also don't have Dan or Antoine on the call to discuss or Sally, who was. Pushing a 20 release. Maybe we can still do that. You know, really quick 30 second version. Justin, you have some context on this. Maybe it's worth bringing up for the, for the notes in the minutes. Sure. Okay. So in a little while, we run into changes that need to be made in the to any libraries. For those that don't know too many. Is an Apache project that allows us to do all kinds of fun operations with bites. Treating them like very large numbers, things like that. It's an important dependency per base. However, when we find issues with it, either new features that need to be added or. We need to be able to do that. We need to be able to do that. We need to be able to do that. Upstream dependency of its own. That's that needs to have a security update. The process for doing that is quite convoluted. If Sally was here, I'm sure she could give you some pretty gory details, but. Without exaggerating, it's taken her over two weeks just to get. A very simple release cut. I'm not going to go into the main line. It was just a matter of getting through some of the bureaucracy and red tape around actually getting that release out there. Antoine is one of the major contributors to the project, if not the only one that remains. And he. I don't want to speak for him, but he has forked the repository and has something now that is the same code base. Outside of Apache. And it's not going to get the updates that we need. As a result is much more fluid and how it cuts its releases. So the question that was brought up in discord is like, great. Which one do we use? Do we continue using the Apache one knowing that it is. Not going to get the updates that we need. Or do we use the one that Antoine forked? Or is there some other third way where we add a new. I think that's kind of where we are discussions are ongoing. And stay tuned, I guess, to the base who contributors channel and discord. For that conversation. Back to you, Matt. Cool. Any, anything jump out on that? I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. Cool. Any, anything jump out on that for folks? I don't know if we have any latent risks there, but I think it's. Necessary in order to keep things moving. No, okay. Sweet. You can move on. Yeah, the. Kind of bulk of. What we're looking at is in this work update section. So let's start actually from the bottom up, just because the. Those. Deprecation and the removal of forest, world state pruning. So the thing about pruning here is that the. Context for which pruning is valuable is usually only useful in a main net context. And forest is typically used in private networks. You know, with the exception of maybe some archival nodes of basu on. On main net, which would not require pruning of the world state either. So, you know, we're looking at deprecating this world state pruning. For public networks. Again, I don't think this would really impact any private networks, but I wanted to run this by everybody here. Because the point of this type of pruning, you know, might. Is lost in like a QBFT and IBFT to context. But again, it's just a plan right now. So if there's any comments or feedback here. I don't know if anyone's using this in some of their private. Networks, I don't know how it would work. Yeah, I also want to add that in the link. We already. State that forest pruning is deprecated. In favor of bonsai. And so. We already. Add this. Idea of deprecating. Now, the question I should say this out to. Maybe reach someone that is using still using it. According to the. Support channel. Probably I do not see. Any reference to forest pruning. So, but I don't know if. There is any use in the private network that is not sufficient. Maybe we can. Disable forest by default and adding a log. If someone tried to activate for a sense to. Flag. Saying that if you are using phrase planning, maybe. Rich discord to say that. So. So user will have to add this flag to enable again. So planning. And with this log, he will maybe have. To explain. We'll explain this log to say rich discord. If you are using that or something. Okay, so. Reporting in the logs that this is deprecated. And it will be removed in a future. Release. Something like that. Yeah. It's an idea. And I think the user will have to do some research to understand why. It's not enabled by the foot. So you need to. To enable it. So this is another reason. To think that the usage. Is low if any. And. Yes. I think. Of course, documenting that we are deprecating it. Private network usually don't upgrade very often, so it is possible that they don't see the warning, but of course they will when they want to upgrade, they will need to check the release notice. So I will pause something also on Discord to try to do these other deprecation nodes and logs and try to remove it in one of the next quarterly release. So to also check if anyone else that is not already on Discord that is following Discord, RACES present. But the folks on the calls that have worked with private networks, you're not using this, correct? Well, not to my knowledge as far as I know. Gotcha. Yeah, I can't imagine that the world state would be large enough in that context that you'd want pruning and it would probably not prune much just based on certain things, but yeah, okay. So we'll put the same notice out that Fabio mentioned and we'll kind of move forward. And if we have any speak up, we can always address it when we get there. All right, the technical documentation requests, I guess it's kind of a mix of on the consensus side and hopefully some others, but some of the work that we have been doing to update the plugin system including things like trilog shipping and basically just changes to the plugins in general, I'm putting out a request slash nominating ourselves to update the technical documentation around this. The plugins, the reason being for the plugin specifically is that it relates to that topic above it around discussion of consensus mechanism plugins and modularity and just some of our modularity goals and extending basic goals in general. So we're looking to kind of revamp the plugin system as part of the roadmap for the rest of the year, not much concretely to share and it's probably less of a revamp and more of just kind of revitalization of what we already have as long as a cleanup and provision of technical docs so that when folks want to use the plugin system, they don't hit their heads against the wall trying to figure this and the other thing out. We also wanted to look to get the EVM library better documented as a standalone library. That'll require me to work with Dano again who is also not available on the call. And if there are other areas, like this is kind of more of a question mark, like what, have any contributors notice deficient areas of the documentation that would benefit from more detailed technical documentation, I won't necessarily commit anyone's time to creating it but it's good to have an understanding of where the documents are largely deficient. So that's more of a question for contributors. If anyone has any ideas. Just to add, we are also working on some bonsai documentation. So I hope it would be available soon. Yeah, we have more, I'm sorry, go ahead. Yeah, I was just gonna say is that as a pretty new sort of user and contributor to Bessie, I've been sort of had my head in the docs quite a lot over the last few weeks and generally I think they're pretty good, pretty comprehensive at describing a lot of the sort of scenarios that are certainly the ones that are useful for someone who's sort of just getting into stuff from the get go. But it's useful to know if there's sort of stuff that jumps out as being useful to add detail to is what's the best way of feeding that back? Is that directly to you Matt or through through get issues being raised with docs tags or? Yeah, well, so there's also the BasuWiki or excuse me, the BasuDocs repository. If folks raise issues there, myself and the docs team at consensus will likely just take a look and I will be watching that kind of closely because the docs is a good entry point for where people are actually confused as far as the product is concerned. So the, yeah, opening issues on the docs repo is definitely one way. Or just like chatting about it in the contributors channel again, I think it's pretty open in there and we all check it. So that's useful as well. Any way to drive the feedback back in there would be useful as far as I'm concerned. So I'm not too concerned about the venue as long as it's visible. Sure, okay. All right, I think we'll end up revisiting this topic probably on the next call when we have Dan out here and Prof possibly also with the last one that I wanna discuss, there's discussion around consensus mechanism modularity. I'm gonna actually share my screen. So I've provided two links for folks in there. The reason that I wanna go through this, if you wanna share Francesco or if not, I can just share my screen. It's up to you. It's probably easier if I share my screen if you wanna just stop sharing, I'll go through it. Sounds good. There you are. Gotcha. Can folks read these diagrams? Yes. All right, that's fine. Gotcha. So, you know, the consensus mechanisms in Bayesu are kind of threefold the way that I see it. We have proof of stake, proof of authority which has a couple of sub elements and then proof of work. And we intend to support these going forward but I think that as far as the resolution of tech that is concerned, we're looking to kind of standardize around a more abstract kind of pluggable, clean interface for all of these different things. Because right now we have all of these different boxes are kind of entry, different entry points and levels of abstraction that ratchet down to tons of different changes to the behavior of the actual client. Sorry, I'm trying not to scroll so fast. So, you know, our goal here is again, kind of spurned by the post merge cleanup that we've been meaning to do for a while. We still support the merge transition in the code which actually causes a lot of kind of headaches and a lot of kind of really unclean logic slittered throughout the code base that we want to address as far as, you know, readability and making sure that we're not just kind of hacking our way around some of these issues. And as I mentioned in the previous section, you know, we're looking to kind of revitalize the plugin system. And I think that this could be a way for us to kind of double down on the plugins as the way forward for consensus mechanisms and identify any kind of weak points in that plugin system, whether it's, you know, we're not exposing enough of the API or we're not, you know, it's too hard to debug or the logging isn't great. It's too hard to do this, this and this. So, you know, I'd like to continue to do our approach at least is based around something of the plugin system and tech debt resolution. And also the fact that we're getting a lot of a new interest around POA in general, just from new contributors and folks who are looking to continue to use Basu in this private network context. One of our main goals here is that if we kind of pluginize the consensus mechanisms that the point that Fabio made earlier that private network users have to wait tons and tons of different versions to basically have images that are appropriate for enterprise use or appropriate for private network use. Hopefully this can help us remove some of that uncertainty by having consensus mechanisms be kind of applied as an abstraction on top of the client so that users and private networks can take the latest security and performance updates without having to worry too much about functionality being lost. So that's kind of the background context of why now and what we're looking to accomplish. And what I'm showing now on the screen is kind of a first attempt at outlining some of this stuff. The notes also have a link to the Wiki page that Justin has kind of come up with around modular Basu. This has been a culmination of a lot of different work and has a ton of information in there. But we have kind of a draft implementation planning thing that has been sitting there for kind of a while where we outline all of these different things, right? These are the business logic components. We have cross-cutting components that are needed to be used everywhere. And we have kind of an approach around some proofs of concepts. But more interestingly, we are looking at getting the, I think as a good first cut around tech debt and modularity, the consensus plug-in is kind of a good first approach. So the material is there for everyone to peruse if there's interest. I think that we would probably a good approach would be to, of course, review all the materials with everybody and then use one or two algorithms as templates. My guess is that main net proof of stake and proof of work will be the easiest to abstract away. Using this kind of plug-in interface purely because POW is quite simple and has the least amount of actual rules that need to be done. And proof of stake kind of in a post merge, post transition context also has really kind of well understood sets of rules. And a lot of it is actually deferred to the consensus layer. So we do checks essentially in what we're doing in Beisu but we don't necessarily apply a lot of specific rules outside of that kind of proof of stake context. All this is to say, it's gonna be complicated but I think that if we kind of work together as a group and start with a good approach that's templated, again, ideally using proof of stake as a way to kind of clean up a first cut and use the plug-in system and then create a template for everyone to kind of see what it would look like and see if it's worth pursuing on a proof of authority and proof of work side or just keeping what we have now, right? If the juice isn't worth the squeeze. So we've come up with this kind of mirror board diagram, the two big boxes. And again, I'll go over this now but my understanding is that folks probably won't be able to tie this exactly to the code base itself. So that's no problem. I encourage you if you're interested to review this later. But the two main areas we've kind of boiled it down to are the configuration of the client and the kind of runtime execution environment of the client and the plug-in system would need to be able to interface with both of these. So in today's kind of worlds, the way that we do these different kinds of consensus mechanisms is through the protocol schedule and the controller builder. These are two components in the base code base that are often generated right at the beginning of the client startup based on the Genesis file in the case of the protocol schedule alongside things like what network you're running on whether it's main net or a private network. It picks up all the kind of milestone and fork blocks and it drives the protocol schedule. So what EVM rules you're using, what block validation rules, a lot of production, et cetera. These all trickle up to the protocol schedule which kind of drives a lot of this. So as far as configuration is concerned, we would need to expand the plug-in surface area to be able to interface with this protocol schedule instead of generating it as a kind of a dynamic thing every time we are instantiating the network which will allow us to move it to that kind of plug-in component as opposed to doing it directly in code which is what's happening right now. The protocol schedule is a little unwieldy and it does a lot of interesting stuff to get to where we are at the bottom. On the flip side is what's happening kind of consistently throughout the lifetime of a client being run. So this is really kind of a one-off. You start up BASU with a specific protocol schedule config and it does a bunch of cool stuff, sets a bunch of rules around the client and then those kind of run throughout the lifetime. The execution and runtime context is a little bit different where the node actually has to instantiate specific sub-protocols if you're using Byzantine fault tolerance stuff like IBFT and QBFT. You also have to instantiate a protocol context which has all of these other components like block choice rule, mining if you're using POW, transaction selection criteria and context around the consensus mechanism. And this also kind of includes that engine API approach for those that are familiar. And then we have things like consensus specific Json RPC and block propagation rules. So I think this one will be a little more complicated but again, once we have a templated approach it will be nice to see where have we plugged all these things in the runtime? What is the kind of diff of what we're generating as far as a plugin is concerned and what's required to like maintain those plugins long-term. And I think that in the proof of stake world that'll be really interesting to see is basically how do we apply fork upgrade rules across both the base client and the plugins. I think things like the EVM will always kind of stay versioned and some of these other items will be altered directly in code or to alter at the plugin level. These are all questions that we have to sort out but again, our goal is to kind of see what the surface area of the plugin API is. Does it cover this use case in a meaningful way? Is this the right approach to doing this? Are there other approaches where we rely mostly on the engine API and not on the plugin system? What are the trade-offs, et cetera, et cetera? But yeah, I really just wanted to open this up for discussion and see how this would work because if we decide to go with a plan in this vein as contributors, it will likely impact everyone, not just of course, Ethereum mainnet, but also things like Ethereum classic and private networks. So we'd wanna make sure there's buy-in and any thoughts are considered before we actually commit to something like this. So I'll take a pause. There's also flow diagrams which are very rudimentary. They're not as useful. I would hope that if we discuss this and plan this that we can expand on this as a, you know, from the consensus side, specifically consensus with a why, we would could expand on this so that they're, whoops, excuse me, this is not what I need. There we go. We could expand on this, but at the same time, I wanna make sure that we chatted about this in this public forum and made sure that the goals and things are clear. So I'll take a breath. Any comments, questions, concerns? Kick off with one quick question, that's all right. Absolutely. Do you see this as being like a code level, plugability, presumably not like a microservice level plugability? So this is based on the existing kind of plug-in APIs. Yeah. So they're not, from what I know, there's a kind of a mix of the ways that you can do it, but the plugins themselves don't really live as microservices, correct me if I'm wrong there, Gary? No, you're right. The plugins are just dynamically loaded at runtime. We have discussed potentially abstracting the consensus mechanism and having that external to base who and having more of a microservice type of consensus driving mechanism that just leverages the engine API. But I think that when we start investigating that route, there's a lot of things that are consensus mechanism specific that are I guess they're really more network specific as they relate to those consensus mechanisms that we can't really easily abstract into the engine API, such as like changes in block propagation and changes in P2P protocols and so forth. So at least initially, it seems like the best approach is going to be to try to create plug-in APIs that will support making pluggable consensus mechanisms. And the first couple that really stand out as would be probably the prototypes or at least the most straightforward mechanisms would be proof of work and the merge consensus itself. I think the other consensus mechanisms have a little bit more surface area that it's going to require a bit more work. So it's kind of, do you want to take the hardest case first or do you want to take the easiest case first? Yeah, it makes sense. Yeah, thank you. Yeah. A timeline for goals on making a pluggable version of the consensus mechanisms that exist already. It'd be nice to have like just some target milestones that we might kind of back into so that we can scope the work to those milestones instead of trying to do all of them at once or? Yeah, I mean, I think in my opinion, the first thing we need to do is make sure that we have buy-in from contributors is at large. We kind of have represented the point of view of consensus, I think, and not necessarily want to make sure that we're getting all the points of view that we need. Gary, but then I agree. I think the milestones, I think we should just kind of approach with one that we could kind of run in parallel against the main code base for like a little while. We want to make sure that the code that we are, you know, kind of cleaning up and refactoring, it's probably going to be a one-way trip. So, you know, we have to be very careful in the way that we approach that. I think first thing we do is get stakeholder buy-in around this approach and also explore what other approaches there are like the engine API-driven approach. But yeah, that would be my suggestion. This intro call probably isn't enough because we, like I said, we have contributors that are working with different consensus mechanisms that aren't really here, especially I'm just mostly thinking around proof of work. So let's try to engage at least Diego and other folks, get their opinions. And then maybe we come back in a month's time and try to get like a firm plan in place. Maybe I'll come with like an actual action plan. We could probably also, someone might want to volunteer to take a stab at a lightweight proof of concept plug-in API around consensus that would shim the other mechanisms that we don't want to try to tackle. It might be just a nice straw man to have in the conversation. Gotcha. I still think, yeah, we would want the, we'd want one template before even creating a shame because I think we're getting ahead of ourselves and presuming that everyone is extremely competent with this API. All right, well, that's kind of all for now. I think my main goal was to just get this out in the open. I'll do some write-ups and sharing around what this really means, some finer detail. Any last questions or comments? Yes, I do, please. Sure. Okay, thank you. My name is Daniel. I just joined on this meeting agenda about a few minutes ago. Apologies, I was a bit busy somewhere. From the documentation team, Bobby sent me, I don't know, maybe a colleague of mine might have come around, but we are here. Thank you, Francisco. I'm here on behalf of the documentation team to know if there are documentation challenges you might be having, where we can come in. And I just wanted to put that out there if there's any challenge as regards documentation. I'll be able to take that feedback and be able to work with your team going forward. It does fine by your team. Yeah, absolutely. I think, as I mentioned earlier, we definitely need to collect some documentation feedback from users and from other contributors on where the documentation is a little deficient. So other implementers on the call, maintainers, please feel free to provide that feedback. Maybe I'll share some kind of Wiki page where we can start to collect preliminary feedback. And we can also share with Discord users to see where this is the documentation deficient. So I think, yeah, we should just stay in touch. But at this point in time, nothing too particular. Like I mentioned earlier in the call, we do have those kind of technical documentation requests that I'd like to get fulfilled. But right now, we kind of need the engineers to be able to drive that a little bit, which is a little separate in my opinion than what we're doing or what we're discussing as far as where the documentation needs updating or where it's confusing for just developers and users of the client. Okay, great, no problem. Going forward, I'll be joining your meetings and contribute as much as I can. Thank you. Thank you. Anything else there, folks? Does it look like or any other businesses or open topics or future topics that you wanna discuss? Gotcha. I know there was also Simon had put a request for comment around any changes to the release process. So if there's, I'm curious what folks are, who are using, who have private network customers think of this release process? There's a link in the agenda that has the request for comment from Simon around potential release changes. So if you are curious or have gripes or feedback on the release process, definitely check that out. Awesome. Thank you, everybody. Thank you, Matt, for running this again. Yeah, no problem. Last comments, questions. We give some time back to everybody. For Gary, I see you're unmuted yourself. No, I was just getting off mute so I could say thanks and bye. Okay, sounds good. Awesome. Thanks, everybody. Thank you. See you next time. All right, thanks. Bye-bye, cheers. Bye. Cheers, guys.