 All right, I would like to welcome everyone to the 30 June 2022 edition of the technical steering committee of the hyper ledger hyper ledger technical steering committee. Let me get a screen ready. Oh, there we go. So, as we preface and all of our meetings, there are two rules. The first one is the antitrust rule. Linux foundation wants to make sure everything is legal. And if it's not legal, it doesn't happen in this meeting. So that's a nice quick summary of the antitrust policy. If it's not legal, it shouldn't happen anyway, but especially in this meeting. The second rule is non legal things. And that is the code of conduct. We all need to be nice to each other. All are welcome here. We need to make sure everyone feels like they have a space here if they want to show up and participate. So those are the two ground rules for all of our meetings. So we will go into our announcements. First, the devil weekly newsletter. It goes out every week. If you have any developer information that you would like shared to a developer community. There is a link, you can leave a comment on the wiki page. Target of this is developers. So it's a great place to get them to read it. The second big announcement is that the hyper ledger global forum is going to be happening. It's going to be on the 14th September and last week the schedule was released. So you can look at the schedule and see what people are speaking and see what talks have made and you can outline your schedule for where you want to go. Any other announcements from anyone else in the on the call that they want to make at this point. All right, seeing none quarterly reports we had two quarterly reports they were both due last week they both came in about it they are too late. I don't know if there's been any comments on either one of them. Nothing on base you. And nothing on caliper that I see we don't have too much adoption too much reviews on that. So, please read these project reviews. You have any questions leave a leave a comment in there. And we'll get to it. There are no reports due next week, but there are reports. Oh wait. Next week, they are due next week. I can't read correctly. There was no reports due this week with our reports due next week, hyper ledger cactus and hyper ledger fabric I'm getting my calendar messed up in my head all wrong. So next week. Yeah. Any other questions about reports or announcements before we go on to the presentation. So for this week's meeting we're going to start off with a presentation from that Nelson, he's a, he's from consensus, working on the Ethereum clients there, check it in basu. And he's going to give a presentation for us outlining details of the theory emerged that is coming up when it's ready. So, let's see, do I need to give you any privileges that I need to let you share the screen. Yeah. I should be sharing now can everyone see. Yep. We see it. Awesome. All right, I'll be brief. Again, thanks. Thanks for the floor here and I just want to give a quick update around kind of more broadly what the merge means for basu and for Ethereum at large, and how kind of the basu team is working kind of across the community to to really be ready for to make sure that it's a really big success for, you know, all parties but also getting kind of the participation of some of the, you know, the users in the community users of basu really excited around mainnet so that's kind of the purpose of this presentation. But you know, to reiterate here that we, we see that Ethereum is leading blockchain technology in both adoption and activity at this time. And a lot of this is happening, of course, on those public networks so we're really excited to see kind of the merge drive interest in public networks and continue to add more users developers and open the door for enterprises and institutions to jump on board. But at this time, you know, we're seeing a ton of active developers in the community, though these are not all client blockchain client developers like those who might build a blockchain client like basu. So we're seeing a ton of active developers across decentralized applications across client teams and across, you know, kind of new paradigms and with three. So really very excited around the kind of growth of developers. And, you know, we're seeing a ton of different transactions and a ton of different assets that are kind of moving around on chain and in different kind of protocols whether those are D5 or other stable coins kind of really picking up speed and seeing adoption kind of the market conditions at this point. But we're really excited again around kind of the adoption of these public networks and kind of what's next for Ethereum here. And what we see is something formerly known as Ethereum 2.0, which is kind of a set of design upgrades for the protocol itself with a bunch of different goals that have kind of been broken up piecemeal. And the first of those large major changes is the merge. So the merge of course is something a process is going to be happening over the next couple of months. There is no specific date it is kind of based on the community consensus around when everything is ready, when the client teams are ready, but its goals are built specifically around these kind of four pillars as we see it. In the meantime, building a more sustainable and easy to use Ethereum, where creators and infrastructure providers and enterprises can confidently innovate on kind of public networks. So the four pillars as we see them, the merge is focused around four key things here so our first pillar is around diversity and openness. And to make Ethereum a much more robust network by providing a diversity of clients and when I say client I mean node software things to let you connect to the network. And this diversity is really key because as we move to the proof of stake system, we're looking to have a robust decentralized network and we're having more technologies like basu step into that kind of niche in order to provide that network security. Previously there were super majorities there were a lot of different kind of client softwares that were focused only around specific implementations and now we're looking to capitalize on this merge to bring in more things like like basu to the forefront here. The second pillar around energy efficiency, this is the key one that we're kind of signaling to the market is that Ethereum is moving away from that costly kind of proof of work mining and moving towards a consensus mechanism based on economic stake. And this will again reduce that energy efficiency around 99% upwards, which really means that the kind of Ethereum network itself is open for business. It's not necessarily a PR nightmare to transact on Ethereum. And we want to get enterprises interested in the kind of next generation of creators and Web 3 value on this network because of this energy efficiency. It's a really great gateway for these kind of new developers and experimentation with the network itself. The third pillar here is that the merge is intended to transition seamlessly from what we have today. The metaphor that I like to hear that I hear a lot that I like is that you're basically replacing a gasoline engine. With an electric engine in a vehicle while you're driving down the freeway. And the reason we say this is because we're using a lot of the same components to make the merge happen that we were using previously. As I mentioned, there's execution clients like basu, which are being run today they're using proof of work mining. And when the merge happens they'll seamlessly switch over to the proof of stake mechanism. They'll connect to some new technical technology components, but we're reusing a lot of the same components we're using a lot of the same API to provide a seamless developer experience, and to reduce kind of the moving parts. We're excited for the fact that developers and institutions that get involved will have the same experience on mainnet. For the most part, pre and post merge so we're really trying to build confidence and developers and in partners to create a good developer experience and a lot of that comes down to the fact that that these different teams and researchers have worked really hard to make sure that what we have today is still valuable tomorrow. The fourth one is around kind of a lot of the crypto economics of of ether itself and public networks and how the consensus mechanism works around proof of stake. But the net with this one is is that the, you know, the changes that are being made at the protocol level will make the currency a lot more robust. There will be a lot more deflationary and there'll be different security guarantees that are built into the consensus mechanism which will hopefully engender more trust with developers with users and with institutions that are looking to get involved in some of these different protocols built on top of the And a lot of these kind of changes are not limited to a theory and the fact of the matter is that kind of the the theory and virtual machine or EVM is, you know, gobbling up a lot of the blockchain world here. And we're seeing that, you know, across all these different networks we have EVM compatible public chains that will hopefully all benefit from this merge to proof of stake. So it's really a proliferation of, you know, benefits across the ecosystem that we're really excited to, you know, evangelize and bring out to the public and talk more with businesses about and how that could impact their their innovation with blockchain and with Web 3 tech. So the roadmap is on schedule for 2022. Like I mentioned, this is kind of a little bit of a zoom in on what the is happening technically with the merge. So today we have of course the Ethereum proof of work chain as it stands. That is what's running in kind of the production peer to peer network today. So nodes run the mind blocks and include transactions, and that all runs well and good until we have the merge here in tandem with the proof of work network that we have today. We also have a beacon chain running, which is essentially kind of a, a network that sits to the left of that proof of work network. It's to test out the implementation of all those proof of stake kind of components. So, you know, making sure that the stakes are secured, making sure that the technology that runs the validators is secured and that the consensus mechanisms work correctly. When we experience the merge those kind of two separate layers will become one, and we'll shut off proof of work. We'll use the beacon chain to run the consensus mechanism of the network. And we'll continue to use the technology those Ethereum one clients to run execution on the new chain. And when I say execution I mean things like executing smart contracts, or building blocks and and talking about those blocks with the folks in the peer to peer networking, keeping track of things like the world state and sinking. So the execution clients like base you are still very important. But they, you know, they will be, thankfully running a much cheaper consensus mechanism thanks to those beacon clients and beacon chain, which will allow us again to kind of get all the benefits of proof of stake and shut off the costly So our key goal here was is obviously sustainability, but it also sets up a lot of the other next generation of upgrades with Ethereum, and it also helps us to improve kind of scalability in some other means so you might have heard of roll up technology or layer to roll ups. This move to the beacon chain kind of consolidates a lot of these outstanding challenges and hopefully makes things a little more consistent around scaling. And, you know, after this, I won't get too deep into this due to the interest of time. There are a lot of protocol upgrades planned around data availability which should help scaling as well. This date is definitely not going to be happening, but it's a good barometer and there's more details here I'll share these slides you can follow these links and get a little bit more background there. Here we specifically come in with basu in the merge. So, as I mentioned before, it's an execution client and what that means is that it's part of the node infrastructure that will run post merge. And it's kind of a key component here. So this big black and white box is what you'll need to run a node on Ethereum mainnet going forward. The node will require you to run a consensus client like take you or like prism or lighthouse, some of these east to clients. And then it will require you to run an execution client like basu or if you've heard of other clients like geth or another mind these are all execution layer clients and they talked to each other via this engine API which is kind of a really great invention that allows specifically the reuse of these execution clients. So people can get, you know functionality that they're familiar with. As I mentioned the developer experience is pretty seamless around this, and this somewhat slash mostly invisible API really manages the heavy lifting between the kind of new components of the node. And at the end of the day, the user gets a new API to interact with the consensus client, they have the same exact JSON RPC API that they expect today with a few different options here and there. And then there is of course the networking between the other nodes. So, basu, you know is really managing that execution layer, it's executing the transactions updating the world state it's still a very key component of the infrastructure, but it allows us to be a lot more inflexible as we shut off some of those proof of work related components. And then here the engine API is basically a new set of API is to enable maximum reuse technology. And again allows us to keep basu as a key part of the stack, because it really offloads only what is necessary to that consensus client to keep everything as lightweight as possible. So why change, you know, why change basu to kind of meet where this is going, as opposed to continuing down the road that we've been down. And the answer was that we want to both refine our mission and make sure that we are up to date with the spec of the merge and kind of capitalize on this opportunity to get basu in the hands of more users. With, you know, testing the merge we've seen a lot of adoption of basu. As I had mentioned there's initiatives around client diversity to prevent bugs to prevent challenges within the network that can be that can arise due to more than a certain portion of the network using one technology. So, right now on the execution layer as it's called basu sits at around three to 4% of the total network nodes, whereas some get the majority client is you know fluctuates anywhere from 60 to 80%. There's a number that we ideally want to get to around 20% per client. So we're looking to kind of capitalize on these diversity initiatives to really make basu a key part of the proof of stake ballot or stack. And that kind of client combo that I had mentioned on the previous slide. So we're following the Ethereum specification and maintaining compatibility with mainnet. Looking how we can prioritize enterprise shift to public networks, bringing institutional features to the public networks, focusing on security on mainnet, simplifying things like staking and interacting with the network. And, you know, post merge kind of focusing on what's next around performance, resolving some of the tech debt that we have and thinking through modularization. So that's kind of, you know, a term that's thrown around a lot. But right now we have things around basu plugins and we're looking to explore how we can really open the client up to kind of a multi chain world. And ultimately the goal I think is around network participation. So Ethereum clients are made for what rather these node client softwares are made to allow you to participate in networks. And those networks could be a variety of different things right now today it's a public network or a private network even when you're running you know private nodes and you have privacy and permissioning using basu. And even things like hybrid networks where we have the palm network which uses bridges to make sure that a sidechain can can port back to the Ethereum mainnet and vice versa. So really we're looking to enable network participation with basu. And I think that this kind of change to the structure has allowed us to really reevaluate how basu connects to different components, how it works with things like a consensus client. And I think that in the future it'll allow us to kind of aim at kind of a multi chain world. So whether that means other EVM compatible chains, things like roll up technology where basu could become an execution engine for layer twos, or just continuing to proliferate and hybrid networks with things like palm. We're really looking to kind of refine our mission around network participation and giving enterprises the best tools and kind of implementations to work with this for their infrastructure. So, you know, it again we continue to provide a familiar licensing, familiar programming language and institutional grade feature for running low overhead nodes, ultimately for staking ether and interacting with blockchain networks. And today that's a variety of networks, it's not just public Ethereum, and we're really pleased with that and we want to continue those trends to have basu enable, you know, participation with blockchain networks across the board. We want to be the best and most flexible infrastructure provider for institutions looking to participate in these blockchain networks, whatever they may be, and whatever form, you know, and seeing how we can kind of enable that new refinement of this mission. What does this mean for enterprise, and what does specifically Ethereum participation mean for enterprise on public networks. So, you know, broad strokes public network participation is rewarding. Not only can institutions looking to get involved involved with public networks learn a lot more quickly about how blockchain and distributed ledger technology works. They can learn to operate their node infrastructure. They will literally help with the security of the network. We've seen some large institutions getting involved in staking to, you know, to help with the security of Ethereum and, you know, stand up hundreds of nodes in order to whoops, in order to get rewarded, but also to help with network security. So they're gaining you know staking rewards around something around 12% post merge on their initial stake. They're gaining rewards now and those numbers will go down as rewards, or as more and more people join the network. But you know it is a role it is financially and education and rewarding to get participated, and it provides new opportunities. Like I mentioned before, proof of stake Ethereum is is a sustainable scalable technology, you know network layer, and it's open for business there's not much of a PR nightmare around deploying applications on a proof of work network. So we have a lot of public proof of work off and we're very excited about that, and we're hoping that more and more enterprise can capitalize on that kind of PR change in order to get involved in public network as, as we shed this, you know boogeyman of carbon, you know emissions and all the all the negativity that comes there. And lastly, it provide public networks provide really interesting and new ways of interacting with these financial and cryptographic primitives, launching distributed apps, doing business with self sovereign users and accessing liquidity and services with D5. What this is to say is that there's a lot of interesting and novel things happening on public networks. And since all of it is done. For the most part on chain, a lot of these components can be mixed and matched, they can be combined together, and it allows for the institutions to experiment and really, you know, novel and unique ways. So we want folks to not only can participate in these kind of private network consortium fashions but explore what it would look like to port some of the business to public networks, and to interact with a new set of users to interact with a new set of, you know, applications, and to see how all those components work together. Ultimately what we're trying to say is that enterprises should feel safe and secure participating public networks. And I think that where, you know, hyper ledger and this group gets gets involved is is spreading these messages that I had mentioned in the slide deck. Talking about education, provide education around staking business and apps on public networks, and talking to enterprises and institutions about what their requirements might look like a public networks. And there's more details to come on these workshops. I'm hoping that we can, you know, solidify some stuff going forward and get the, you know, kind of the energy of this group behind it. But again, we really want this message to hit home that enterprises can feel safe and secure participating public networks and that there are opportunities in doing so. And of course, basu remains for the most part the same Ethereum client that they know today but is gaining a bunch of new functionality. When it comes to the merge around participating in public networks, and that we will of course, you know, be kind of focusing on this as we look to the future and continuing to follow the Ethereum public specification and continuing to watch the ecosystem evolve so that basu can stay at the leading edge of these, you know, these clients and making sure that we're providing new use cases and new functionality that infrastructure providers and enterprises are looking for. So as I mentioned, more details not only to come around the topic of this presentation, but also to come around workshops and where we see kind of basu evolving in the short term, and then in the medium term of course post merge. But with that, I will take a very deep breath and pause for questions. I know I breezed through the first couple of slides so if you have general questions around the merge. Feel free to let me know. And, you know, my email is also in this deck, which will be likely shared so feel free to go there. I don't know how much time I have left, Dana, but how much time is we need? Thanks for the presentation. So I have one probably basic question and trying to understand and where this is coming from right so the preliminary question that I have is to understand. And right now is basu is moving into a modularized architecture where it will be the consensus part of it would be split up into its own engine, where the execution engine would interact with it and are you going to continue maintaining those existing consensus engines as part of hyperlature foundation or what does that roadmap for those look like apart from the execution engine itself. Absolutely. So we have no plans to deprecate any of the existing consensus modes. And what that means is that when you want to participate in any given network, you basically just have to if you're if you're looking to use public Ethereum when you specify the network name in the kind of basugenesis file, it'll force you to kind of set up a code in order to sync with the network right so it really depends on the network that you're connecting to. We're not looking at deprecate any features we're going to continue to keep even mining in the codebase. So if you're looking to work with Ethereum classic for example, you can still use basu as a client that will be able to mine on those networks. And we're going to continue to keep our private network consensus mechanisms as well. We're not looking to deprecate any of those. We're just looking to shift kind of our focus on on a modular set of features around this new set of functionality that is being introduced. However, we're not removing any of the previous functionality. And as I had mentioned, these changes are being done in such a way that is very delicate to the client. So there is not really a need for us to refactor the codebase around kind of the merge so to say. So we're going to plug into that engine API and the magic of kind of the two clients talking to each other and you know pointing them to Ethereum mainnet does the rest of the work. So thankfully we don't have to upend any of the existing private network functionality we have or existing mining network functionality. We're simply adding additional options that make use of that great kind of modular architecture that the merge has been built around to make all that stuff work. Awesome. See we have Angelo the question here. Yes, thank you Matt very interesting very interesting presentation. By the way, I'm at the summer school and blockchain summer school where I was teaching and there were discussion also about that there are people from the foundation and they were also discussing or presented this kind of roadmap. Very interesting. I have three questions if I may. Can you argue about this three topics. Why is not on the table, the option of moving the VM to the blockchain systems like Algorand and Cardano which are already proof of stakes very well known very well tested. Algorand even solves the trial and second question. What happened to the enterprise the enterprise Ethereum Alliance specification is that that are still alive. Third, third question. How do you solve for the business for the enterprises who want to use the public, the public blockchains. How do you solve the problem of predictability of costs, even the fluctuations that the cryptocurrency might have. Thanks. Yeah, absolutely. I'll start with your first question around the EVM. So, frankly, Dan would be a great person to answer that question, but we've already done a lot of work to kind of modularize the EVM as a component itself. So, as I had mentioned in the slide about refining the kind of the mission we are looking actively at seeing where that might be useful. You know, the basu team is not ignorant to the fact that there are other networks besides Ethereum with different components different, you know, benefits and pros and cons, etc, etc. And there are a lot of those based around the EVM. So we're looking to, of course, explore what that looks like, you know, we do have EVM implementations of basu that are not for public Ethereum, which I think is fantastic. And we're looking to, as we modularize the client even further in the post merge kind of phase, we're going to definitely kind of explore how that looks from a priorities perspective so that we can enable those other chains. I'll let Dan out chime in here for sure. And then I'll go to your second question. So as far as migrating to other chains. One of the reasons why we can't go to Algrand and what they don't know is Cardano or Tezos. There are existing applications working on the Ethereum chain. So the desire to take it from proof of work to proof of stake. We're also at the same time keeping those applications running large defi trading operations games distributed autonomous organizations. Those are all live on Ethereum and you can't it's it's not really easy to just simply move it from one major chain with another major chain. So that's one one one reason why it's not just going to Algrand or or Tezos or Cardano, apart from also the issues of ownership of ether and economics. But a second thing I want to point out there is there are chains that are adding EVM compatibility layers, or directly integrating EVM into their chains. The work I did with modularizing the EVM in Basu so it's a separate include a library that doesn't bring along the rest of Basu with it. It's something we're using in hyper ledger, not hyper ledger to any h words is something we're using in Hadera. So we're using that library in Hadera to provide our EVM operations in that now that's always been an EVM chain for the smart contracts. But I think a more interesting example would be moon beam network and Aurora which runs on a near network. The base networks on both of those are not EVM based chains that they have a compatibility layer on top of it that provide the EVM compatibility. So this vision is playing out it's just not always the basis software I think moon beams written in Rust. And I'm not sure what Aurora is written in. So the idea of putting EVM on other existing chains is public chains is very much happening and I think there's a lot of industry pressure to make it happen. I personally would compare the EVM and the JSONRPC interface to the IBM PC compatible world of the 80s computers. I mean, whether using compact or whether using HP or whether using an IBM underneath that you still have the same API is that still works the same. So I think the next two questions I will let Matt Matt answer on the EA and cost fluctuations. Yeah, thanks for the reminder because I was thinking those through. Yeah, as for the EA. It's a great question. They're moving relatively slowly around these specifications. As far as what the what the merge will do to the EA spec, the answer is not much as the EA spec is is sort of based around consensus mechanisms closely but it's mostly based around you know the privacy functionality and permissioning functionality. As to that I don't have a great answer I can circle back though and see if that's still valuable I will definitely make a note to follow up on that. And as the third one. Yeah, I think that that's an absolutely great question when when discussing with enterprises and institutions this is how do we get around, not get around but how do we engage things like gas fees in a way that makes sense and scalability concerns which are also very valid. And you know there are a number of things that I like to point to, I think that one of the great ones is the palm network. You know it's a side chain that was that it runs for NFTs with the intention of being sustainable, and the intention of lowering fees, and the users only pay a fee to bridge back to main net. I'm going to see some of these kind of side chain environments proliferate where, if there's a consortium or even a single entity that wants to work with public networks. They can build kind of their own little world that has bridging functionality to main net and back to allow users to port their assets between the two, between the two locations with predictable gas, or with at least the caveat that, you know, there is no gas no fees over here but there are some fees over here, depending on what you want to do. I think that a lot of the developments around layer two scaling solutions that are going to continue to ramp up. You know the first kind of round of layer two roll ups were based around you know some one set of technology called optimistic roll ups, but I believe we're about to see an explosion of second generation roll up technologies based around zero knowledge and I think that as these proliferate a lot more we'll see in general fees come down across the board that again that doesn't address things like volatility, but you know there are stable coins do exist, and you know there are improvements to a consortium in the works around things called, you know, multi dimensional gas or networks specific gas where I can pay potentially for fees in stable coins so I know how or have a predictable model of how things work, depending on network traffic, or if I can work, you know go to a layer two to get my own scaling for a much more predictable or lower fee, but these are all problems that are actively looking to be addressed, and we need to understand the bet we need to better understand the institutional costs themselves I'd say, before we're ready to kind of tackle those as a community, because again it's it's it's a little bit more complicated than just saying the fees are high. The fees are high if you do things in certain ways, the fees are low if you do things in other ways, but there are trade offs of course to each around you know security, liveness of data, data availability. It's it's it's really a mix and match and it honestly depends so much on the use case that I, you know, want to continue to engage these institutions to really get to the root of, of what the issues are there. And predictability of fees is not just a, a non sorry, it's not just an issue that some people are facing it's an issue across literally every user of the entire network. There's something that post merge is kind of the first targets are around scaling heavily the data availability of Ethereum and and the, just the execution throughput. So hopefully we'll see progress there. But I, again, I point to layer two roll up technologies in the short term. There are also private network rollups and kind of hybrid network rollups. So those aren't exclusive to public chains. Again, kind of this interoperability layer that is looking to be built, which can greatly reduce the burden of fees on users and fees on institutions. Hope that answered the question. Yeah, very, very interesting actually there are so many problems there are research problems for this for the students is just perfect. Thanks. Yeah, absolutely. All right. Another question here. So another curious question just to this while you're explaining I got more curious to now learn about. Is there any specific reason that why basic community especially is looking to like, advertise that public networks are better for enterprises so from my understanding, I was saying use cases around defy and and within fintech word right on the public network side also on the gaming industry. So is there any other use cases such as trade finance or it could be like within supply chain domain that you foresee and why specific push towards that just was curious. Yeah, so I think that as kind of some of the fundamentals improve around, you know, things like KYC ML throughput and scalability of fees as we had just mentioned, and things like, you know, just lower cost of value and the infrastructure costs of running on a public network as these kind of become more known quantities on chain, the real cost to implement any of these networks whether it's supply chain, whether it's trade finance or a lot of the kind of, you know, traditional blockchain use cases that we've seen across a number of hyper ledger projects. It becomes an astronomically less expensive to it, and less complex to kind of operate to to iterate and to build out these networks on public infrastructure for a number of reasons. But again, there are those there are those few problems to work out. And I think that as we get those on chain fundamentals correct, the public network at large becomes a one it is the infrastructure is essentially free in theory, you only pay for those fees to use the compute time of the network. But to it becomes a lot easier and simple to deploy these applications, you don't have to set up nodes or complex consortiums, it's all kind of done on the software layer. And that's what we're looking to see is like, if institutions want to get involved from an infrastructure perspective to run their own nodes to get data from the network to to experiment with the network. And then potentially to deploy these smart contracts in the public that will run these supply chain use cases or run those trade finance use use cases with, you know, potentially say for example they're using a roll up and they get the privacy that is provided there, or they want to use a specific side chain where you know they're they're selling NFTs related to a certain gaming use case, but they want to make sure that those users can buy and trade and sell NFTs elsewhere. Right, we're going to see a proliferation of these kind of unique public focused things where we want users and institutions to be able to access kind of the openness of public networks to be able to access the infrastructure public networks which already runs today. And to do so in a way that's a lot more predictable so we're working on the predictability component. But again it's it's mostly rooted in the fact that we've seen struggle around the scaling and adoption of some of these consortiums, and I think that's due to some of the barriers to entry around the complexity of the technical setup around the complexity of the permissioning and you know kind of access control layer and you know some of the complexities of the regulatory compliance and those are not necessarily lost on the public side. The challenges are just tweaked a little bit. And I think that as we see user experience improve on the public network side, we will hopefully be able to convince these enterprises to explore that more and more. And again that will hopefully lead to a proliferation of more users and more customers on mainnet, or even just you know interparty kind of business to business use cases and that are done in public on a public ledger. To answer your question Darrell, I don't think I need much more time. If there's any more questions here. Sorry everyone. Hopefully that was a good enough answer there. And I'm going over time. Like I said, I think that the that this has been absolutely great that my email is in the slides that I'm sure will be shared and circulated. So if you have any follow ups that I don't want to take the rest of the time here. Please feel free to reach out to me on email. And I would be more than happy to go through any of these topics. And I think it's a great discussion and these are all good questions that I want to continue to work through. Because I don't necessarily think that we should approach this topic as an either or like either private or public. I think that we really need to be bringing all of these things into the basic project in a more serious way. And that's exactly why these questions have been absolutely great. They're giving me lots of think about and I want to continue to engage this group on these topics and I think that they'll help, you know, definitely drive that message around. What are our blind spots with public networks enterprise, and kind of going from there so I thanks thanks everyone for the great questions. Thanks for coming Matt it was a very informative. Not everyone is aware of quality Ethereum landscape it's it's growing and changing and you didn't even cover everything slides it's it's crazy large. Great. So move on to our next discussion item. We're trying to get some consensus on the proposed charter changes and if we could bring up the word doc. The Google doc charter changes proposal. So before we go into the comments that came in after the last day that I just want to open the floor. Are there any questions or comments about the TOC proposed changes from people on the call that aren't already captured in the comments as last time. Okay. So I detected three when I sorted by comments that little little word captioned by the pictures of the of the skunk in the starfish. So there's the top three that were new since the last meeting, the one came right after the meeting was a question of whether TSE members should vote. The TSE members would not vote in the the pick of the six would only be maintainers. And the thesis being that their interest should be represented by the governance vote the same as non maintainer contributors. Comments or questions about that or concerns. Okay, so that was Tracy's comments. So open questions and may require some some editing of it. The first one was the question from Tracy about our hyper at hyper ledger labs to maintainers who vote. I think she had a, there we go that link links to the question. How do we get these to link to the doc section. Okay. So, to add to maintainers, a hyper ledger labs maintainer this would be a change to the charter. So, if you start a labs project and you are one of the maintainers of the projects you would have the same level of vote as a maintainer of an admitted project. Any comments or questions, everyone's got a stand up. Go ahead and read. Not for the current item I had for the previous item, I guess. Okay, thanks for, thanks for adding more clarification around, like, who can the governing board, like nominate or elect. So this should be among the nominated members. Right. That's the third item. Yeah. Right. There is no definition of individuals and that I see added. So, should we add the clarification of who those individuals are. It just says who are active within the scope of hyper ledger. Okay, that was the third item. I guess we could table these first two items and then just deal with that one directly first since that one is the one getting comments. And just written right there just says active individuals. What proposal would you have to define active individuals would be contributors and maintainers. Or should we just let anyone propose themselves to the board, regardless of connection to hyper ledger and rely on the votes to correct any issues there. If I can find my mute button. Yeah. So I'm fine with anybody I think if we go outside of the maintainers then we have to do this whole thing of like what's a contributor again which isn't, you know, isn't awesome. And I think our maintainers are probably probably, you know, smart enough to vote for, you know, people who are involved in the community, you know, except for extenuating circumstances right maybe if Shafi Goldwasser wants to run for the TSE. She should win anyway. So yeah, cool. Right. No, I want. I want people who are maintainers. I mean, yeah, I'm not against it in concept, but it's as hard to said, once we say you don't have to be a maintainer. I'm super uninterested in having anything to do with elections anymore, because it's going to make life hard. So this is not. I think we're talking about two things maintainers who vote versus maintainers who nominate for a seat. Right, so I was thinking if someone nominates them. So, are we talking about a person who is not a maintainer being nominated. Right. So I'm in theory I'm for that. But I would, I would like I would not like to have that. I don't want to run those elections because if someone nominates themselves and you have to go in and do the whole, you know, SCI interview thing. So, um, SCI, sorry. Yeah, sorry. Yeah, you'd have to do some some digging to figure, figure things out. I guess the my guess is the volume of people who do that will be low enough that won't be terrible but I, I guess I feel either way, but I don't want 500 nominations. Right. So, if there are 500 nominations then it's the, the maintainers have to pick through those. I'd like to point out that currently on the TOC, the TSC, we do have non-maintenors represented in CSC and I think they add value, and I would like them to continue. So personally, I would not be in favor of limiting nominations to just maintainers. So that's, you know, maybe it's something we need to discuss a little bit, but because it looks like there's three levels there's maintainers only. There's the maintainers and contributors, which would be one way to judge activity, or anyone who chooses to fill out a nomination. And yeah, in theory, there could be 500 people that are going to come in on the vote and that's, you know, but it's the maintainers that need to assess through that list. And then it would be the governing board that we need to assess through that list, not the, not, we wouldn't be adding more people eligible to vote. We wouldn't be adding, it'd be the same list of people eligible to vote in the maintainer selection and the governing board selection. I withdraw my objection then. So, but Yeah, so I think, you know, I agree with Roy's point we don't, the big thing is we don't want to have to like verify everyone for requirements. And it seems like you're worried about maybe too many people applying. What if we require something very basic like an LFID that prevents people from sort of just spamming a form and then at least if they want to spam us they have to spend like five or 10 minutes on it. And the requirement is an LFID or something like that. Does that make sense. For me, it would, but I don't want to write that into the charter. I would prefer to just leave this as it is, and just people can nominate through a pull request or whatever. I would just not spell that mechanism out because I don't want to LFID might be rebranded as, you know, open LFID or something next year. I don't know. What if we had individuals be nominated, although they nominate themselves but with the require a second from a maintainer. Would that alleviate any years with that produced too much. Would that change it too much I guess. No, I that is a great way to do it for me. Okay. And the other TSC members have opinions on this or people on the call to warrant TSC. The second would add additional process however, and we're trying to simplify the process to the degree possible. Right, but the person doing the second would just edit on their page. Say hey I second it and you can verify who said it. Okay. Grace. I just know I was the one who asked about the active individuals and after hearing rice comments. I think I agree we don't win the charter we don't have to have the process or the definition I think, as heart said, you know, so it's fine as is what I want to say. And then, as heart said if it's just a basic LFID to nominate nominate yourself in the TOC that that sounds reasonable but we can figure that out later. Okay, Angelo. So, you know, in just to more broader argument. So democracy is a cost any election, any, any formal government as a cost so we should not. I think we should it's not. It's not reasonable or I don't buy the argument says that that's it's too much work so we should not do that. If it makes sense to open up to these people that are not maintenance because this can be we find value in them bringing in bringing these people in. I think if I mean the cost should not be a problem. Of course, even better that we say that we think it's not good that these people that are not maintenance coming. I would better appreciate this this kind of argument but the cost should not be a problem I mean it's like saying, if you want to start saying then like something like this is how democracy is very costly, but it's still very good system. Thank you. Okay. Do you have any objection just to limiting it to just individuals who have nominated themselves and write no weather process in there and let the process figure it out. Not for me. Okay. All right, so let's let's put that on on edit that as one of the ideas for this individual so the other two questions. The other question was open was whether hyper ledger labs should be included in the maintainer vote. The maintainer of a hyper ledger labs project via maintainer. They would then be included in the maintainer vote for selection for for TSC members. What is the, what's the opinion on that from the, from the people on the call. Thumbs up from rice heart has his hand up. If no one else wants to say anything I'll run my mouth some more. I think if they're active it's fine right. I mean, I think we have a list of active labs and active maintainers and an active labs and active maintainers. And it's great. You know, if we want the active labs to participate in this. Okay. Anyone wants to limit it just to admitted projects and graduated product projects. Okay, so hearing none. I think we'll leave the edit for or hyper ledger labs in it. And if we can go up and do the edits. I'll do that. I got my own copy here. Individuals and I would propose we just say individuals. I'm the anonymous badger apparently who have nominated themselves for the TSC. So anyone have any other preferred language or is that sufficient. Okay. Um, I thought we were not going to change the wordings and just leave it. Okay. Let it be understandable kind of a thing. Okay, so. Active with a scope of hyper ledger foundation consists of anybody. Okay. So we'll have a very loose interpretation of that. You should probably record that in the notes then that active within this scope of hyper ledger foundation will have. The loosest reasonable interpretation. Okay. So there's no reason that heart mentioned right so somebody who don't even understand hyper ledger should not come and say. I want to nominate. Okay. Cool. So if there's no changes to this. Are people okay voting on today. Does anyone. That's a thumbs up, but there's some magic words I need to hear. Is anyone going to motion and second for a vote. Okay. There's okay. Right. Okay, I'll do a roll call vote here. Angelo and the matter before the technical steering committee. How do you vote. I abstain. Abstain. Artem. I support. Okay. I support. Bobby. I support it. I support it. David. I support it. I support it. I. Grace. Kim Lush. I abstain. Nathan. Oh, Nathan's not here. Peter. Yes. And Troy's out. So we have. It looks like the motion passes to me. One, two, three, four, five, six, seven, eight, nine. We have an absolute majority. Yes. I just want to remind everybody that this ultimately, this is a charter change. So we have to get the governing board to handle it. So we will take being the. Staff and Tracy will take and others who are on the. Governing board will take this to the governing board for a final approval. Okay. Just to remind her that nothing can happen until the governing board approves this. Okay. But the majority of the technical steering committee is in favor of the change for the governing board's information. And we usually find that when the technical steering committee approved something in the governing board, we've never had the case where they haven't as well. So. Cool. Until the TSC tries to pass a motion saying that the governing board has to buy the TSC free beer. I just want to. We have other. I just wanted to thank everybody for. Helping get this done. Thank you all. Cool. We can discuss free beer next week. Arun, you have your hand up. Do we have enough time for your security task force recommendations? Probably not, but I just want to add for the recording purpose, right? So the proposal looks good to me now that we are planning to bring in the process change in the way to see our TSC is getting elected. So even though I voted as that numbers are located for election versus nomination or I consider whatever governing board elects, those members has nominated. Those numbers seem that number seems to be still big to me. There reason being governing board is very specific representation within Appalachia foundation. So the overall proposal itself looks good, but just the numbers. I'm not sure if that's the right distribution. That's, that's all. So the governing board should like more or less. For from me personally it was. Yes. Yeah. Okay. Because when I, when I copy this, I copy this from CNCF. The governing board elected the most seats. And then the maintainers selected a smaller. And then there was an even smaller from the end user tab, and then they selected another. Organization wrangle around and then they selected two of their own. So. Yes, I see your concern. Can add those notes to the governing board recommendations then. You see it because they might, I can see the governing board making some changes there. Hart. Yeah, I was going to say if you have any, if anyone has any comments or suggestions on this, maybe like added in the wiki or something or put in a comment. So the governing board can see it all because I imagine they will. You know, I certainly think they'll go with the spirit of the proposal, but they may want to tweak things. So if you have things like, hey, we're not sure about the final seat allocation or, you know, stuff like that, definitely please post it. And it will get brought up in the governing board meeting. So. Was the term of the TLC written in this either? Cause I know we discussed going to a calendar year, but I just suddenly realized I don't think it's in here. But the term is not written into the charter. Is it? No, it's not even today. I think we hit it. Planned that it would be going to the calendar year. I think the original plan was to run the current TSC until. Through the end of this year and then start. To the next year, you know, when we're running the meeting. And I'm not sure, you know, I don't know if Jan one, but. You know, obviously if people have other suggestions. Yeah, we're, we're two minutes late. So we don't have time to discuss that we could. I won't be here next week. So Tracy will be running the meeting as always. But I think that's an excellent discussion to add on to next week's agenda. Along with the security task force recommendations. You know, if what we want to recommend, or we can handle it offline on the wiki and just let the. Yeah. Yeah. Yeah. When is the governing board make a decision? When is the governing board meeting next? September 10th. Or no, September 11th. Really? It's that late. They meet. I thought it was. The second Monday of every month. Okay. July. Yeah. July, but I can't find it. Yeah, it's July. That's right. Okay. So we have this recommendation, but it's not going to go can be considered by the governing board for a vote until the 18th of July. So. Yeah. So there's, there's room to amend this if we need to. But I will let Tracy handle that next week. As I will be in the middle of Wyoming with no electronics. It's going to be awesome. Great. Any closing comments? Right. I'd like to thank everyone for coming today. And it's great to get progress done. Thank you. Bye. Thanks everybody. Thanks everyone. Bye bye.