 All right, welcome everybody to the August 18th Hyperledger technical steering committee call. We do have a number of people joining today who have not previously joined us. So I'm going to make sure we cover the antitrust policy notice. A bit more details. So just FYI this meeting is covered by the next foundation's antitrust policy notice here. If you have any sort of questions or concerns, please contact Hyperledger staff, your legal console, or even Andrew up to grow of the firm, Gessner up to grow within questions that you might have. The second thing that we have to abide by on this call is the code of conduct, which is linked in our agenda. Everybody is welcome to participate here, but make sure that you are respectful to the other people who are on the call. I'll go through the announcements. The first announcement here is a standard announcement. There is a dev weekly developer newsletter that goes out each Friday to hundreds of hyperledger developers. If you have something that you would like to reach those developers, please leave a link in the comment or leave a comment in the link that is linked in our agenda here. So there's a wiki page that you can provide your comments. The second announcement I have is that I would like to cancel the September 15 hyperledger type of a steering committee call, because I personally will be on a plane back from the hyperledger global forum. And I'm imagining that there will be a number of other people in some sort of travel state as well. So, I just wanted to make that announcement before we actually cancel it from the calendar. Does anybody have any objections to doing so. Thanks, Dana. All right, and then the last thing here. I don't know Emily, you want to cover this. Absolutely. Good morning all I'm Emily I'm from the PR team and I just put a note in here I think rise put this out on discord as well but as global forum is just around the corner we are looking to highlight project news. I know of a couple things that I think are out there but it would be great to have as much. And it doesn't have to be breaking news would be great if it was breaking news but anything recent and noteworthy in terms of project releases standards labs new projects, anything along those lines that you want highlighted I just need to know about it by Monday, 29th, so we can plan it into the new cycle and as appropriate plan some blog content as well just support it. So quick call for that if you have something. Please email the PR at hyperledger.org email address. That would be great. I'm also on discord some but the PR at truthfully the PR address is a more reliable way to reach me. Thank you, Emily. Any other announcements that anybody would like to make at this time. So with that, I did leave the areas in the indie reports on the agenda. They were came in. I don't know a couple weeks ago maybe, but there were still a number of people who hadn't reviewed them. I didn't see any comments coming through on those. So I will end up removing them from the agenda for next week but is there any questions or comments that has on either the areas or the indie report that we should cover. Okay, so no hands, nobody coming off mute. I'll take that as you know. We also have the Roja report, which came, it was supposed to be due last Thursday. So we will reach out to the Roja team and see if we can get them to submit their quarterly report. I think we actually have a number of people on the call today so we have completed the report. It is a different final proof review proof read will be submitted to me tomorrow at the latest. All right. Okay, so that's the announcements and the quarterly reports. We do have the double report I see has been being worked on. We kind of get at it and removed from that. So I expect that to be coming in here shortly. The grid and the transact reports are due next week. So we will look to see those as well. So with that, I think we are on to the meat of the agenda. I don't know who's sharing, but if you want my scrolling down. All right. So we have two items of discussion today. The first one is the soloing project proposal that has been provided. The second one is been added here by Rai on behalf of the Roja team to talk about the Ursa library and the way in which we get that updated. So I think I'm going to actually start with the second item. I was told it won't take a whole lot of time to cover this, but I think it is probably the place where we should start and then we will jump to the soloing project proposal and have a discussion on that. So, I don't know, Alexander, are you going to be talking about this or do we have somebody else who's going to be talking about this. It's fine. I'll cover this. So, just as a brief reminder, Hyperlegia Ursa is the unified cryptographed library, written in Rust, but it also provides a C ABI compatible library version. And it is currently in a state which is causing problems for her. The first problem that we have encountered was that we had to hold back a few major cryptographic dependencies due to Hyperlegia Ursa using older, unupdated versions of those libraries. We dug a little deeper. We identified a couple of CVEs, we have contacts with the Ursa developers and are waiting for a response for the past three months. Unfortunately, nothing happened. We contacted Rai, who generously offered us help. The way we would like it to be resolved is of course for Ursa maintainers to return and to help us with updating their library. Unfortunately, this is not possible, so an alternative was proposed, making a few of us, a few of the maintainers of Ursa, co-maintain Hyperlegia Ursa. Unfortunately for that, we would need a little bit more resources. Right now we're stretched a little thin. We already have an ad capacity team of 12 people. We can't spare more developer time, and we can't spare more than a few people's part-time attention to maintaining Ursa. However, be able to change or revise this, provided that we had a little bit more resources, so that we could hire at least someone to replace the lost time in Ursa, or ideally someone with security proficiencies so that they could also co-review our contributions to Ursa. So depending if, of course, the second option is inevitable to make some small alterations, so that Ursa is easier to maintain in the future. In particular, we're moving away from a few deprecated libraries and relying more on Rust core rather than external dependencies, just like we do. We also offer our experience with testing, buzzing, and code quality, so that we can help Ursa remain both reliable and easy to use. And I guess that's it from my side. Jim. Yeah. Hey, Alex. Alexandra. Yes. Yeah, first question from me is besides Iroha, do you know other either Hyperledger projects or customer projects that are dependent on Ursa? I'm guessing that Rai Jones would be more qualified to answer this question. I am unfortunately focused on Iroha development. I'm just curious if finding the other dependent projects and work out the resource issue might be a worthwhile effort at this point. I can imagine Iroha being the only project using Ursa. I don't know off the top of my head and unfortunately, heart is not on this call. I have to defer. I know that I think Grid was looking at it for a while. I don't know though. Okay, I guess the other question. I'll then Jim, I think it might have an answer to some of it. Yeah. And lastly, the areas projects are making use of Ursa. Indie uses it to a certain extent. We know that a row has been using it, but I don't know of any other projects that are using in production with there are have been some projects to do verifiable credentials from fabric and some of the other blockchains that Hyperledger that have, have made use of Ursa but I don't think any of them were released into a production environment. There's some of the security stuff as well if we want to dive down that track but I think the focus here is on what Iroha wants to do next so far. Okay, yeah it seems like if Indie slash Aries are using Ursa to the same extent that Iroha is, the same problem would be present there as well so maybe the teams can work together. The next related question I had is for the Iroha team, if it's not Ursa, do you have an alternative? From open source point of view, if you need something changed in the dependency and no one is doing that, usually it's the, it's dependent team that has to, to contribute resources, that's certainly been our experience. There's just no way, no other way to make it work, right? Well, certainly, yes. However, we are far from the only users as far as I can tell. It does not make sense for us to unilaterally contribute to significant architectural changes in Ursa. Unfortunately, one of the deprecated libraries is failure. And that library is an error handling library that requires a significant restructuring of the code. It is a semantically incompatible, a sember incompatible version of Ursa. And we don't want to do that unilaterally, we want to at least know if there are other people involved, know if there are other people interested in maintaining it. And if so, I'd like to be aware of their requirements and the necessities. Right. Yeah, I was going to ask, like, is there a way that we can, or maybe through the TSC or Hyperledger Foundation, like there's a way to put out like some kind of like call for, I don't know, call for participation in the Ursa project, like we could help to coordinate, you know, this maintenance if there were a few interested developers from other Hyperledger members, for instance. I think that's an interesting suggestion, Makoto. Nathan. I think one of the first steps here is to show up on the Ursa call. There has been a resurgence of interest from DSR and the vast folks and a few others in doing some of this maintenance work. But apparently, we haven't heard from the Roja folks on that call. I'm reaching out to Cam over chat right now and talking to him about what he's heard about this issue and what he hasn't heard about this issue. It looks like we have some disconnect between the things that are going on this on the security list and the maintainers and Ursa. So not everybody in the Ursa project is aware of the issues that Roja is facing. So that would probably be the first step is to try to make sure everybody on the project knows what's going on. And it could just be there's a communication gap. I know Cam in particular and the folks at Kiva we have been less connected to this than we were in the past. As Kiva pulled back some of its project work on Hyperledger areas. So, I guess I think it's just kind of a transition gap that we're seeing on Ursa and less an indicator of overall project help. But the fact that we went from the third to the 12th with for a response and that I'm asking core maintainers on Ursa and they still haven't heard about the issue is indicative of some communications problems. And I think that's probably a good step to take as far as next steps. It also brings to mind some of the work that's being done by the security task force for making sure that we have the right security contacts in the list to ensure that you know people who need to be aware of security issues coming in are aware of those issues. So that's that's probably something else we can follow up on as a next step as well as to make sure that we have communication with the Ursa maintainers and make sure that we know who the right security contacts are from that that group of people to ensure that when they're aware of these issues when they come up and can start to address them or at least have conversations in this regard so yeah I think two next steps that I heard coming out of this discussion one is for the Roja team to join the Ursa community and have discussions with them and then secondly for us to make sure that we have the right contacts and the security list to ensure that Ursa is represented as they need to be any other discussion that we should have on this particular topic. I think we can. All right. Well thank you for bringing this to our attention and hopefully this through having conversations directly with the Ursa maintainers and their community calls will help to at least get some movement on the challenges here that you have. So then the next topic here on our agenda is the selling project proposal. We do have Sean here to talk to us about this proposal I have seen a few comments here in the GitHub for requests but Sean did you want to talk us through kind of the proposal and let us know kind of where so long that at the moment. Hello. Okay, so I suppose I'm aware the comments on the pull requests being addressed. So I can give like a brief role background on so long. So originally I was working on borough and we were using the fear of the compiler to use things to passivity. I wanted to do things that compiler couldn't do. We open some issues on the on the saucy compiler, get up repo at some discussions and they showed really no interest. So I suppose that in the wider blockchain, and there will be interest in a compiler which would support stability for for other targets and even other targets and Ethereum. And so. We're building quite a few scratch. Yeah, they must use LLVM so the tricky parts for code generation would be, we do not deal with that that could be done by by LLVM. We only need to work on the front end of the compiler. So we just the parsing semantic analysis and the LLVM intermediate representation generation. So we, we support nearly all the same syntax as, as Ethereum facility. So 0.8. There are a few minor exceptions, and no one's raised any issues about that yet, and we will resolve those minor issues as well. So, while the project was growing, I have spoken to various high pleasure. So I spoke to make a moment about adding sport for city for the private data objects project. We started some initial code. Didn't really, unfortunately, couldn't really develop from there, but definitely a lot of interest. We had brief discussions with Michael about, about supporting fabric by the fabric contracts API. That seemed like a good idea. But no work was started for that but also a definite interest. We wrote a prototype for sawtooth, and lots of discussions and calls with Sean Almondson about how to further progress that. I don't know of putting bodies on the project but definitely interested in that project as well. So, so long is, isn't just a generic compiler project. It also provides building blocks for tooling. So, there's a city code format and which is being written based on so long sparser. We've written a using the high pleasure mentorship two years back a language server for stability. So this is something you can use in these code, for example, so it gives you syntax highlighting and errors and hovers and that sort of thing. It can also be used in atom and in the UVM. And the other interesting thing is that existing static analysis tools often work in LLVM IR and saucy doesn't produce LLVM IR so those tools won't work with that. So, I've been talking to Jeff one a professor from from Texas A&A University about using doing some analysis on to using so that you can see that's the green core project. So that's an interesting angle. I guess last year, what I'd like to say is that compiling smart contracts is kind of different than a traditional compiler. So, which makes this project interesting, I feel. So normally with a compiler you would balance the execution time to compiler with how optimized your compiler output is. So the contracts did the balances is different. The contract is quite small. So you're dealing with just a small amount of code. And the need for optimization is much higher on change like Ethereum, the gas cost is such that if you can optimize the output more. There are genuine cost savings, especially over many runs that can be very significant. So there are compiler techniques like super optimization, compiler execution, which is concrete and simple execution. The methods that some methods can be used to optimize smart contracts. It's very interesting field. So Solang, for example, has a pass which replaces 256-bit multiplies with 64-bit multiplies. And it uses code-cloning execution in order to implement that. And that's something you wouldn't do in a traditional compiler because if you would do that on a large program, the execution time to compiler would just be far too great. So we, yeah, so we're, there's not a subset communities are very interested. The targets are very much maturing and there's this different activity around that. And lastly, we would like to work on EVM back end. So we've only just had discussions about changing the EVM target to EVM, which would be another very interesting thing to work on. I guess that's it. Thanks, Sean. So as everybody probably remembers or might remember, this is the second time that Solang has come to the TSE to propose this project into incubation. The last time we chatted, I think that the main concern was really around the main tenorship, I think it was Sean at that point. And since then, there have been a couple of new additions to the main tenorship of the project. And so I guess at this point, open for any sort of questions that people might have for Sean on Solang or any sort of discussion items that we should talk through. So we've had a couple of conversations prior to this and our TSE calls last week in the project gap. So anything else that we should bring up at this point. I should mention that. Yeah, go ahead, Sean. I just wanted to mention that the other maintainers, Lucas and Sarah, they're also on the call available for questions. Thanks, Sean, for the presentation. So sorry, a quick question. Maybe it's a, it's a question that's bugging me for a while now. So which products are like competing that let's say Solang, for instance. So can you share some information, some thoughts on. So for the study language, there's, there's the Ethereum strategy compiler, so see, and that only targets, if you're in, so that that's a competitive for that. There's also a political soul, but that that is a study compiler, but it, it doesn't develop to cease. It can and can only target he was and be well wasn't probably isn't developing either. So, as far as compilers, the only competitors we have is the Ethereum compiler, but that only targets Ethereum. Is that that that's not your question. Sorry, yeah I have, I think my question extends to that right so the reason I was asking for that is. So when we say, so that people don't need to familiarize themselves with other programming languages, like if they are solidity developers, that this particular project can cross compile it for them across other blockchains, other non-Etherian blockchains. So, are we talking about Ethereum compatible blockchains itself for non-Etherian, since specifically I mentioned it as non-Etherian compatible, just for a time, let's say, namesake, because fabric is the other most popular one, apart from basic. Let's say people come here and they say, okay, there is a Solang project, can I write my solidity and can compile it into a chain code, for instance, that's kind of question that people can come up with right. So, just to have that understanding so what exactly is happening inside Solang or is there any competitive projects that does something like what here it's happening. So Solang can compile, so there's a generic part in Solang which compiles solidity, but there's a target specific part. So at the moment we can target Solana substrate and E-wasm, and we certainly have a lot, we have a lot of interest in developing this for fabric as well. At the moment it's not possible yet, so when the solidity state is accessed, for example, you have to hook up the blockchain specific parts, but the aim is very much for Solang to target many different blockchains. Understood, so the way we should understand currently the Solang is, it is compiling, I mean sure it is cross compiling or solidity into multiple, like the outcome binaries. However, all those binaries are currently compatible with the ones that support, let's say, E-wasm itself, right, so. No, no, no, this is not true, no. Solang to Solana polka dots and E-wasm are not EVM, but those are not EVM virtual machines, these are completely different virtual machines. E-wasm polka dots is a WebAssembly kind of virtual machine, non-EVM, E-wasm is also WebAssembly, and Solana uses a different virtual machine based on the Linux kernel BPF. So it's, this project makes sure you're available to non-EVM chains. Sorry, I should have a question that has some blockchain that supports Ethereum smart contracts, not necessarily via EVM. Okay, yes, okay, yes. So this project is so that the blockchain itself doesn't make any change to, there's no change made to the blockchain itself, and the compiler just has a target which implements all the blockchain specific parts for that, for each blockchain. Yeah, two questions. The first one was kind of answered already, so just want to confirm my understanding. I thought Solang was mainly targeting WebAssembly based runtime engines, but based on what Sean just said, that's not the case. Substrate and E-wasm is WebAssembly based, but Solana is not. Is that understanding correct? Yes, that's correct. And this is the great thing about using LLVM. Right, okay. Yeah, that's clear. My second question is, can you talk a little bit about the level of effort now and expect it in the future to add a new execution engine support, say, how much of the code has to be written to support. I don't know if Fabric is a good example. I don't know, let's say to support Cosmos, for example. It kind of, it's a bit pointless to say, learn Solidity and then compile to a full language that Fabric supports. I think that would just go to the full language directly. So I wouldn't use Fabric as a good example for future expansions, but maybe Cosmos, what would be the level of effort to add that support? Well, I'm glad you asked about Cosmos because Cosmos is something that looks at the past and to evaluate how much work it would be. So Cosmos, it's a WebAssembly based virtual machine, so generating WebAssembly is not a problem. The problem of the effort will be required in hooking up all the blockchain specific parts. So in Solidity, you can do things like ask the current block height or save something on chain or retrieve something from chain or get the time, lots of sorts of things. So all those specific, blockchain specific things need to be hooked up, and in Cosmos, that's done over Protobuf. So the effort that's required would be to, for all those things is to translate a request or compile a request in Solidity into a Protobuf request, and it goes to a WebAssembly host function at runtime and then the answer is sent back and then we have to deprotobuf the result. So for each one of those functions, we need to create a Protobuf request and pass the result, and then the next part is, well, lots of testing, writing integration tests for the chain. So, I guess another thing is when you call a Solidity contract, you call a function and function arguments. That's also done via Protobuf on Cosmos. So the function arguments and return values will have to be deserialized and serialized using Protobuf. That's essentially the work required to get Solidity working. There are a few functions in Cosmos which are very useful to have access to in Solidity. So it might be needed to add a few functions, built-in functions in Solang for Cosmos. We've done this for Solana, I've done this for Substrate, you can do an import from quote-quote, single quotes, Solana in Solidity, and you can import specific built-in Solana functions and call them. Does that answer your question? Yeah, that helps a lot. I'm trying to figure out if someone were to add support to a new smart contra-engine with that person, what's the most important skill? Would it be understanding compiler architectures? Or I just need to know how the internals of that new runtime works. I don't have to know how to build compilers. I'm just trying to figure out how likely is it, is Solana in the future going to expand to support other blockchains? The effort is very much around understanding the target VM and interface and not so much the compiler architecture. It does get quite tricky because when things don't work, you are working on quite a low level in WebAssembly also, and you might end up having to sort of step through some WebAssembly codes to understand why it doesn't work. That's very much sort of runtime VM kind of issues. The compiler side for a new target probably isn't a huge issue, and that's certainly something we can probably be able to help with should arise. Okay, that helps out. Thanks, Sean. So I just want to point out that they really did a good job fixing the two big issues that were around the last time they came up. They got the three maintainers, and they're also a large number of very viable real-world use cases along with the interest we're seeing here. So I think now is absolutely the right time to bring this in. And this doesn't impact the admission, but I think something that we're useful to see is how they handle standard solidity contracts being fed straight in like all the open Zeppelin. It would be an interesting test case to figure out where the rough spots are and might also open up a utility for people who'd want to say just run the open Zeppelin fabric, open Zeppelin tokens on fabric or some other chain, but that has no bearing on whether or not on my acceptance of this. So that's just point of information. You're absolutely right. Putting over Zeppelin is an off requested feature. So, Cyril has just opened an issue for that, and it's something which is on our roadmap. Any other comments? Any concerns that people might have with bringing Zeppelin in as a top level project? Or any other support that anybody wants to state at this point? Sorry, I definitely want to go through technical details. I'm interested more after understanding these much details, right? One more question now that Sean is on the call, just from a community support point of view. And some of the other blockchains that are listed over here are they have their own ecosystem in terms of maintainers and developers, the community, right? So how is the reception from them on this project? Is this being communicated to them as well? Absolutely. So, Lucas and I both work for Solana, and we're very, we get a lot of interest from the community. Basically for two reasons, people want to take the existing contracts, existing facility contracts on Solana, or they don't really want to learn Rust. Some people just feel that on something Rust is too much of an ask and would rather just keep to Solana. So there's a lot of interest in that community. And in substrate as well. We are, we are on various discord servers and telegram groups. Yeah, sure. I can add to it that there are, there is interest on using Solana for targeting the substrate runtime. We are aware of power chain teams that want to use it in production. And they actually plan to do that. I just wanted to compliment what Sean was saying. On the Solana side, the company promotes some events to, to devote what the network is doing and to make people build on Solana. And we've been part of some of those events trying to encourage people to use Solidity to build the projects and we've seen some interest. And as Sean mentioned, people are trying to use the existing contracts on Solana and we are making efforts to help these people build on Solana using Solidity. Any other discussion items from the TC or anyone else on the call. I have a question about the AI stability plans for the survey. If it's going to be interoperable with WebAssembly in some way. I'm sorry, I missed that. The AI stability. Sorry, in the walkway. The next point of backwards compatibility is the SO lang compiler, so to speak, going to be backwards compatible with all the smart contracts on the binary. On the binary level in the sense that all the smart contracts come out of the exact same binary representation, or effectively the same representation. The output is, I mean, we've made conscious effort to make sure that the output is deterministic. We suddenly had box fixes for that. The, we're not on the on the binary level we have to have to be compatible with what the language says that doesn't sort of change. The new version of Solidity don't retains functionality to just add functionality. They wouldn't change the execution function. Okay, thank you. So the way that the Ethereum Solidity compiler deals with this binary reproducibility problem is a lot of the contracts will lock into a specific version of Solidity. So as long as it's deterministic compiler and it always produces the same result for each version, I would expect that it would have the same security story of Solidity if you lock into a specific version of Soling. And you compile down to that specific, you know, always use that specific version of compiler you always get the same results. And that's that's about as the highest qualities you can get for people build within the EVM ecosystem so if they can do the same for wasm targets, they'll, they'll be in the same position that Ethereum is which I think is fairly fairly reasonable for for the constraints. Any other questions. I'm not hearing any. Anybody speak up against this is. So I, it's not, it's not a question it's more, more about comment. I see that Solang is mostly focusing on Ethereum based blockchain or AVS. And we have very few, like, you know, we have Bezo which is a client, but most of the blockchain projects, I'm just, I'm just trying to understand and see how it fits into the current portfolio of the projects that we have in Hyperledger and without without a roadmap or a kind of vision of how it's integrated into the major projects like fabric or soft tooth. It's very helpful to judge and see how we can help to build community around this project being, you know, being incubated into the Hyperledger. We certainly have had, have had discussions in the past about using Solang for, for, for other projects. So we've had this conversation with fabric and with sort of private data objects. So at the moment, there's no plans were definitely made. Work wasn't what she started. And but that certainly doesn't stop it from, from us doing that in the future. So we're very interested in adding more targets to do so like the, the more projects work with with so like that, the, the more successful the project is, help. Yeah, yeah, thank you. Right. Any other discussion? Should we move to vote. Yes, that's a, yes, everybody, if there's no other conversation I think that's where we're at today. I put a motion to accept Solang as incubation project in Hyperledger as described in the PR. Oh, second. Thanks to him. Did you want to take us to a vote. Of course, I will choose by the order will be who has the longest name in the list. Troy, in the matter before the TSC how do you vote. He's used to being last. Okay, we'll come back to Troy. Artem. I will abstain. Arun. We do this next week because I definitely want to read more and come back, or can I give my opening later through email. Is it okay. Jersey. Well, I mean, we've had the motion in the second I think we're at the point where we're ready to vote. I need some more time. I'll probably abstain, but I'll change my own. I may change my own after reading more. It's allowed. Okay, two abstains. Daniel. Yes. David. Yes. Grace. Yes. Jim. Yes. Kamlesh. Yes. Nathan. Yes. Tracy. Yes. Troy. Well, the motion passes anyway. But congratulations. All right. Thanks Sean. Congratulations on becoming the newest project within Hyperledger. Now the hard part. What's your new name going to be. Yeah. So, I'm just trying to forget who's on call. Daniela, do we. Do you want to take this or David, do we want to take this to the marketing committee? I know in the proposal, it's a hyper ledger selling unless somebody at the hyper ledger decided that that was not the way that we want to go. So. Sure. There's a naming process that we now jump into. So we will start that process up and reach out to. Sean and the rest of the maintainers. So, and congratulations to the maintainers. We're looking forward to working with you to get so long as a, as a project announced over the next few weeks as well. So we will take it from here. Tracy. We actually have a call with the marketing committee chairs next. So we'll put it on there and reach out. Thank you everyone. All right. Thanks Daniela. Any other discussion items that we should have. That weren't on our agenda. That we should close out with today. So with that, I guess we'll close the call for this week. And we will talk again next week. Thank you. And congratulations to the selling team. For being debated within hyper ledger. Congratulations. Yep. Bye bye.