 Hello everyone, I am Aasthavish and I am a computer science undergraduate student from Deradunetia. For the past six months, I have been working on building a declarative specification for workloads under the Hyperlogic Caliper project. Attila has been the mentor during the past six months for this project and he has been an amazing guide. Coming to the more detailed parts, so a bit of an introduction about Hyperlogic Caliper. It is a framework for benchmarking blockchain systems. When Hyperlogic Caliper is run over a blockchain system, the system is subjected to a large number of transactions and towards the end, a report is generated with all the relevant benchmarking parameters. Now for these transactions, each of them is created or say initialized by a workload module. This project focuses on simplifying the implementation of those workload modules for the people who are using Caliper. So currently, the workload modules have to be written in JavaScript and there are a lot of things to take care of during that. So this project focuses on building out a more declarative specification for workload modules and trying to convert it into more of a low code solution. Coming to how a declarative specification differs from one written encode. So this is how a part of the workload module looks when it is written in JavaScript. All the relevant parameters here are initialized. Then there's a contract function that's also declared and all of these, all of this information is sent through to the system under test. And this is only a small fraction of what the workload module looks like. There are also other parameters like Caliper's own internal parameters and then there are also things that the user defines that have to be either modified or passed into the transaction. So this can get a little bit more detailed. So in order to make it simpler, a declarative specification was our idea of implementing the solution. Here there are on the lower level parameters that go into a transaction. There are also functions associated with those parameters and contracts that maybe present in the system that is being tested under Caliper. So this cuts down the implementation to just specifying what is required rather than handling everything else as well. Coming to project objectives. So the first objective was to build the YAML schema that has to be implemented. And this was done just to give an idea of how things would flow inside the project. Based on that, a modular implementation for how parameters would go was created. The third objective is to integrating and testing how the values defined using YAML schema and implemented using the modular classes would work out in Caliper's environment. The fourth objective is to migrating existing workloads or say existing tests that are proven to work within Caliper's environment to this new schema. And the fifth is to provide user documentation and developer-level documentation for people who intend to use Caliper's declarative schema. Coming to project deliverables, they are more of a breakdown of the already state objectives. So first was again building out the schema, then building out the value providers. So these are associated with the likely parameters or the kind of parameters that might be sent through to a transaction. The third deliverable was testing out these value providers thoroughly because there might be a lot of edge cases in declarative schema like, for example, the minimum range of random number provided might be greater than the maximum range provided. The fourth deliverable is integrating the schema through higher-level classes. So since these are just the value providers and the parameters that might be used, there are also functions and contracts to look after. The fifth deliverable is migrating existing workload to the schema. Again, the tests that have been proven to work with Caliper have to be written in terms of the schema. And the sixth is creating documentation coming to project execution. So it started out the project by looking into other tools that were doing similar things. So these consisted of blockchain benchmarking tools and also load testing frameworks. So most of them were either using scripts to declare the parameters which are similar to port or they were just using very minimalistic configurations like passing in a CSV file, the user defined parameters that might be there. So it was mostly code-based configurations in that area. So what we were trying to do here kind of ended up being different form what was already done. The second was creating a YAML schema. The third was building out classes and testing how values are linked within that YAML schema and how the edge cases were being handled. The fourth deliverable is something I'm still working on and it's integrating the schema through function and contract classes. I also intend to work on system six deliverables which is testing it through something that has already worked out and writing user and developer documentation. I expect to complete these by the end of November. Coming to recommendations for future works there can be more complex value providers under Caliper like weighted Boolean values or randomly generated string. The value providers right now are relatively simpler. I hope there can be more complex ones so that it's easier to define values. Coming to the second point the current schema is more platform oriented. So started out with taking the difference of a fabric integration test in order to build out the initial schema and it doesn't take into account how say the same system might work for Ethereum. So this is something that is worth looking into and the third point is scheduling of contracts and functions like round robin instead of just randomly picking them out. So these are the recommendations. Coming to the outputs these are all links associated with the project. The initial project proposal the project plan that was written after I got accepted into the mentorship. This is the declarative workflow directory that consists of the results of value providers that were written and the final is the bullet points that were put in during the mentorship program. Coming to insights I learned a lot during this project and one of them was one of those things was that the solution could not come out to be perfect on the first try and things have to be improved iteratively. Also I learned a lot about good coding practices in code documentation, a little bit of GitHub magic and considering a lot of edge cases while writing your board and testing it out again and figuring out where things can go wrong and it's a lot of thinking outside the box. So and if I had to give an advice for other mentees or someone new to open source it would be to communicate a lot and also plan out things a lot and that was all from my side I am now open to any questions. Thank you. I do see your mentor Athila, clinic on Zoom. Do you have any comments? Yes I would just like to add that Asta performed a lot of complex tasks and a lot of challenges during this mentorship. I mean she performed surveys of other tools and essentially designed domain-specific language for workloads and from that she created modular sub-framework inside of CaliPer. So I think it was really challenging and it was a lot of work for her but she did it admirably and I would just like to say congratulations. Great. Thank you. I'm glad to see that Asta persisted and even though the project was fairly challenging and big scopes and it sounded like she learned a lot and there's still one or two items to be worked on during the remaining months and I hope that Asta you will stay involved in the hyperledger community. We'll hope to see your contributions again in the near future. Yes I plan to stay involved. Thank you so much. I may not like to echo that. Asta is fantastic to see this work and we look forward to further contributions from you and thank you Athila for mentoring Asta as well. This is fantastic work.