app: Thank you.
app: Everyone um welcome to the
app: first by weekly meeting after a long hiatus. Um, we're going to mostly be talking about the internal release of our C Ten
app: um,
app: and we'll go a little bit deeper into Why, it's an internal release. Um! So there with us. And
app: I was not,
app: Of course, Today we'll also talk about the you know one
app: happenings, particularly the internship program that um Gosh is
app: having, and his students, Andre, who has completed his task on uh creating a need for one library
app: which
app: going to present after this Um, once the Yes, once the uh microphone issues have been sort of that,
app: so i'll see you as an internal release. Why, um! You
app: either has too many or too few changes to the Api to be qualified.
app: Um. Most of the changes are under the hood. They have already been back ported into the Lts. Um, So there was no point in
app: creating a release for two, maybe three changes, although those changes are beneficial for the Api being rich, the events system and they add a lot more depth
app: to numerical types. Unfortunately. Um! They don't sell. They didn't themselves a warrant. The amount of work that would be necessary to update the as the case. So we decided not to release. Obviously ten to the public is that we are just going to use it as a
app: sounding board for a few ideas. I'll see eleven is coming um when it was supposed to um. Naturally we're going to talk about it next week
app: next fortnight. Robber um, when we'll have a a set amount of features that will be changed.
app: So, whatever you found, we have identified the duplication bug, which was
app: causing quite a bit of a headache. Actually, um! It can in some cases
app: cause a large genesis block to just be rejected out right,
app: and in terms of Genesis, the zombie genesis, but which was referred to as it's only Genesis because of
app: the way it acted. Um wasn't itself a single, but it was actually several,
app: and this is one of them.
app: Um, of course. Given that we've identified a small issue with how the Ptp system worked
app: primarily to find that it could be denial service. Um, we have started working on making it more in line with the architecture of similar, I guess, in line with the active system.
app: Uh, and we back porting this to the Lts.
app: We have much better handling of fixed point operations.
app: Uh, we're going to add exponentiation to the mix which is going to use arbitrary precision and perhaps add a better precision. Fixed point numbers.
app: Um, we have. That's a user experience for youatic operations and values, particularly. Um. Now all passes that uh of numerical types uh their own type numerical value. Um. These values, of course, will be extended, and there will be room for
app: extended precision, like I mentioned previously.
app: You Don't, know self reports diagnostics on that that includes for the health check uh the get hash with from which it know how it's built,
app: which should be sufficient to any development to figure out what's wrong. Um! We'll be adding information to this as we go.
app: Perhaps we should also consider having feature sets, but those should not affect the Api. They are only for debugging purposes.
app: Um,
app: of course we've done the bare minimum, and hopefully that
app: what will be sufficient
app: query for a total amount of any given asset. This is primarily useful for a blockchain. It's prototype application where you want to be
app: able to investigate the liquidity of the entire blockchain rather than do specific things to specific accounts. Um! This is not as precise as it can be. Um! We might extend this to use arbitrary precision as well.
app: If we need to um. The below precision is good enough for a ballpark estimation, and if you're interested in broad stroke statistics,
app: this is sufficient for your purposes.
app: The you know one internship is fantastic.
app: Um, like I said, n of course, is going to present um the work done.
app: Perhaps there will be um more sort of explanation what was actually done. But um
app: keep in mind. This is really you have one. So if there are any users, and you don't have one. They might be more interested in this, and the rest of what we're talking about. Um!
app: We have fixed quite a few minor bugs in this release as well,
app: and we have reviewed the other internship. Um related to You know how small, in fact, these three points are related to external contributors eight, nine, and ten. Um. Unfortunately, the on this one that was created by the external contributor is in no way she perform Usable as is,
app: it needs to be refacted
app: and very much written from scratch.
app: Um!
app: Of course we've identified opportunities to reduce what communicate website and communication eyes.
app: Uh, We remove one round trip. We've added a few extra guard rails which would prevent communication between binary compatible peers to go through the handshake and end up in a deadlock situation,
app: where half the peers cannot understand what the hell they are supposed to consent on,
app: and therefore no consensus passes. Um. This is very useful for later visiting from tolerance as well. Given that networks will often have binary compatible Ps. For and in just for the kick of it as an audit matter
app: now. Permission Events are omitted for roles, too.
app: What does that mean? Well, if you had a trigger that was supposed to monitor a specific permission being added to, revoked from a user previously that would have only triggered if you were specifically, explicitly removing that permission. If um the user was revoked a role which wanted them that permission
app: you would not get an event, and this is semantically incorrect. We fixed it.
app: Um, We've We fixed the two out of five potential bugs that are related and symptomatically similar to the zombie genesis.
app: Um. We've added a limit on the size of the genesis block. We've added some guardrails to prevent uh genesis from being committed when it contains incorrect transactions. Um duplication book, as I said, um
app: is in progress. It's actually a bit of a difficult one to fix. Given that we need to restructure the will. Say you
um, and
app: there's work on going on this,
app: of course, that's a museum on New Texas.
app: It turns out that the rough standard library, Mutex is
app: Jack of all Tr. But it doesn't very well to specialize for what we are actually using use access for.
app: So we have found a few potential candidates which could improve for a good
app: which we will be testing
app: as another bonus um. If you're using this in the Web assembly context. Well,
app: not in the weather. In the context. If you're trying to fork around um add some extra stuff to it. Um! The newly taxes are supposed to be more economic as well, because they can't have been possible.
app: Um!
app: We also have the blockchain explorer. Demo happening very soon.
app: Well, actually, we already had the blockchain explorer. Demo. Um, we've completed it. We've recorded it. Um! The version that is internal has already been circulated. The version that will be available to the public will be circulated very soon.
app: Um!
app: Just to recap the state of the project. It is perfectly functional.
app: It is up to date with the latest it can work on a live environment. The only thing that is missing is a synthetic environment which could demonstrate the behavior.
app: Um,
app: but we make. We made extremely good progress, and in fact, he's with us today. Um! He's made excellent work um working completely independently from the team um on making this happen, and this has provide applications for testing as well.
app: Of course. Um, we need don't forget about generic filter and judge combinators.
app: Um. This is going to be The first one is going to be useful, for if you want to combine arbitrary types of filters,
app: we've already had this. In fact, the filter Combinator Api is what's served as the baseline for the Judge Company, so the only issue was that it was binary. We need it. It's It's a ternary operation for judges which will definitely react to back to binary when we have the opportunity to do so. Um,
app: the idea being that um if you want to know how to combine filters, Judges are filters of the sort. You give them a transaction, and they give you um Yes, no,
app: I don't know
app: as the ternary part, and if you wants to be able to combine them
app: to create complex permission sets.
app: This is the way to go.
app: Uh, it's not quite as index as Graphql would be. But Graphql is a
app: well. It's good for queries. It's not very good for
app: identifying
app: whether or not the transaction should be passed through. Um, especially given. The Graphql is extremely heavy,
app: and we needed something much more like
app: specifically closer to what we have in house.
app: Um, C. I is back online.
app: We
app: had a few issues in October, and in November
app: beginning of November. To be more precise, um associated to um, the Cia runners being taken offline
app: better machines, and for cheaper
app: um, and this would allow us to restore some of the ci features which were disabled temporarily, for you know one.
app: The only adjustment that needs to be made is that from now on any changes made to you, how one need to be made and not be a personal folks like for you to have to. But actually the the um
app: feature branch in the main repository
app: Hyper Ledger slash,
app: you know.
app: So yeah,
app: we are back online. We are continuing with making the Ci process more quick, lower latency and higher throughput, so that we can host more interns.
app: So what is in progress?
app: Runtime permission. Nowadays we are in progress as moving
app: everything that we had in terms of hard Covid rust nowadays, since it was on plugins.
app: That's one step. Secondly, we haven't actually agreed upon what that system is going to look like, because some uh types of validators have assistant state, some that those that Don't would benefit from not having to clean the
app: persistent storage and the virtual machine for Webassembly.
app: What's more important, Um. I actually don't think that we might necessarily end up using Web assembly
app: For this purpose
app: we have alternatives, and Webassembly was chosen for small contracts for different reasons. Um! It might make sense for us to do something a little bit more in-depth
app: this.
app: In the final stages of
app: testing every single integration that we have,
app: we're almost completely done
app: so. This was a big project, and I have great respect to uh, senior developers south of Sun. And
app: uh, Mr. Message,
app: you have contributed very heavily to this. Sorry i'm getting messages. What's going on?
app: Yeah. Sorry. Um
app: Web Assembly Dynamic linkage is on. Hold um! Naturally, once we're done with, we will come back to this problem,
app: and it's extremely likely
app: that we will be in a position
app: where
app: will present dynamic linkage as its own presentation,
app: because writing Webassembly is its own thing. Um optimizing web assembly to take up less space, is, It's only thing. But there's also the question that I have to link with the provided library,
app: and that library is going to be
app: extremely heavy,
app: and it's a
app: um, of course,
app: unified configuration interface.
app: Oh, sorry uh
app: it. The library is supposed to make it extremely lightweight and easy to integrate with. You Just need to know what to do, and that's what it was coming. Sorry I'm. I was distracted by your message.
app: Um. The unified configuration interface
app: we have moved most object from configuration to isite meaning that these are network configurations, and we are synchronized when we are not yet consolidated. The will see you, and we are not yet finished. This process and runtime up to these
app: are still quite a bit away Because there's ordering issues. Do you execute these with every other transaction?
app: What happens if you change the ordering
app: of these transactions? And should you just define an ordering in such a way that everything that pertains to a configuration is the first transaction of it in the block.
app: Once we figure that those questions out, this will be complete.
app: Um! The tutorial is almost fully up to date.
app: We are good with sorting pagination inquiries. We're not fully there yet. The filtering.
app: This is related to the fact that the
app: filtering combinators uh changing,
app: and they are going to use the same Api for query judges. And this is development documentation.
app: Um. We also have improvements to the loans script. In fact, the most important changes are in the script, because these are related to the testing and to the
app: profiling. But with you
app: we have diverse instructions. Now we can register assets; we can limit them, we can transfer them.
app: We have more accurate transactions per second estimation, still not as accurate as i'd like to be there. Um! And we're still working on how to uh put this on a
app: on the consistent basis. We want to make sure that this produces the right answer in most cases, and that's difficult, considering that we're mostly running this on weak machines which do not have most of the assumptions that we can make like multi-
app: But we do have graceful jump down.
app: And This is very useful, for when we are trying to check
app: the extreme
app: behavior of you.
app: And of course there's a demo mode
app: which has been added
app: very, very um late in the game precisely because um we wanted to
app: for lack of a better what we needed to.
app: Sorry I need to make this one Um,
app: because we didn't think that we would need one.
app: Um, because we didn't need that. You would need to interface with it as if it were a demon. It was enough to run it as a script. Um! Given the way. We want to restructure the longevity load testing
app: um.
app: There had to be some concessions for the infancy for um
app: recovering from failures, if you still want to keep going, and so on, and so forth,
app: in terms of the Ui and ux um, There's quite a few cool requests in review. Right now,
app: we want to.
app: We have identified that in most cases, whenever we have a problem with it, or it's not actually related to any software bug.
app: In fact, it is mostly relations in the fact that the logging doesn't provide special information.
app: So how are we going to fix this. Well, um, First of all, every error needs to be Eva presented in the form that is addressable by the user
app: um to lead to the termination of, you know, if it is a high priority era,
app: or it needs to be ignored and clear explanation for why it is a Google needs to be provided in code.
app: Otherwise we have the we run the risk of either handling too many errors, and by using the logs with too many error messages which are not even error messages. Um or not providing enough feedback
app: is a next step.
app: Um, right now. The way that it works is that uh,
app: a few kinds of errors which gets printed out with a full trace back; some that
app: some errors just get caught and ignored, Some errors get logged and ignored, and
app: most of the time
app: we are dealing with situations where we don't even know how many errors character do they occur, and when do they occur?
app: As a as such we are unable to provide good feedback to the user
app: um. What should you do with this era? Because
app: which brings me back to point? C. Um! It's not enough to say that something went wrong.
app: Um, we. The developers have the entire code based in our heads. That's just the way it is, even though um it should be. It should be said that we don't actually have the up to great version of the code base.
app: The users do not, and whenever something goes wrong they need to know what to do. Os Era Eleven tells next to nothing. Um. Failure to buy into socket. Um tells the user that. Okay, something is wrong, but they don't know what to do, what to check. Precisely. Um.
app: They need to check the firewall. Do they need to check for that specific port, and which specific quote, because in most cases um the error doesn't say which port it tried to bind to it just says that it failed to bind to it. Um! If a file is not right, or is it because the file doesn't exist? Is it because the block still cannot be found,
app: you know, next to no diagnostics trying to change that.
app: And of course, um believe it or not. There's very
app: few ways you can check whether or not the trigger actually got executed.
app: We have omitted this kind of event for security reasons, because if you were to be able to process the trigger executed events in the same block as this one.
app: Um!
app: You could lead that could lead to infinite recursion, and we don't want that
app: uh infant recurring within well one block, and it's in the recursion in general. Isn't the problem
app: um In order for the trigger events, Trigger executed that to be processed in the next block. There needs to be some extra pipeline which was laid down by
app: one of our uh senior junior developers. Let's just say,
app: of course,
app: you want your access to everything we've done profiling as well. We've collected a lot of feedback um, especially from bogdam.
app: Um. We have identified several performance issues. Um, we've manifested as if they were bugs, but they're not. It's just that the Pr. Is slow, and it is not able to process the transactions on time, and therefore we adjust them.
app: Um, we're going to standardize testing on the legendary stunt to the extent to which,
app: with between each release,
app: each release version is going to go on the longevity stand, and we should know if it has any particular issues that need to be fixed,
app: due to the fact that we were mostly featured in the focus on feature releases and optimizations, namely, the um. So the regular structuring
app: um, The unit test coverage for most of our crates has gone down
app: significantly.
app: Um! We want to bring it back to reasonable amount. I think sixty-five percent units as coverage plus integration as coverage should be enough,
app: and of course, in some cases we have identified that while on stronger machines we perform better on weaker machines we perform the worse, and we wanted to understand why we still not have a full picture for why that happened.
app: Um! One hypothesis is that the P. Twop was in on the servicing, but that isn't the only thing that could cause that sort of behavior, and we need to identify
app: whether or not there are any other.
app: So
app: if you with us, then you probably have seen this exact slide several times in a row.
app: We have been pushing these changes, unfortunately for a very long time, and they have become a bit of a
app: but this time
app: cross my heart, since where to die we're actually implementing them.
app: The key centric account is structuring is something that we will start working on next week.
app: We've already started some work. Um, you know I will. Unfortunately, that was due to other projects.
app: The local reputation system is coming. It's not coming necessarily in the immediate future, but expected to come
app: early.
app: January meeting in February
app: offline transactions is something we have already started thinking about
app: um. The hardware solution is something that we've
app: worked on
app: on and off since June. Um!
app: The solution seems sound. It just needs to be settled so we can't really say that we've done this.
app: Um.
app: But there's also the issue of hardware being really expensive and not really suitable for cases where you would expect uh offline transactions to be useful. That is why we're working on the software solution, and the software solution takes a lot longer.
app: Um, We
app: kind of have to start doing this already,
app: but I didn't expect us to make anything again progress until January.
app: The patching compatibility. It's it's it's up to you.
app: It's coming, but it will take a while, of course. Um!
app: You also have to take into account. The protocol has changed significantly since we started working on this,
app: and so that means, as a company has um changed its position with relation to the substrate power chain. So we have a little bit more leeway, and we have a little bit more influence.
app: Um. As a drawback. That means that we have to do all that.
app: Of course, transaction fees and bootstrap. Here is probably the first thing of this list that will go into in progress,
app: and
app: with that out of the way.
app: Um! The you know how to presentation is complete.
app: If you have any questions, how is the time to awesome
app: anyone?
app: Okay,
app: Now that we've done this, I
app: sounds for
app: the uh screen to
G.Bazior (baziorek): and but uh, hello, everyone! It we have to intel intern so they would present. They They they work. But I I would like to ask you to cut the
G.Bazior (baziorek): and probably for Hyper ledger. I don't know um what what are those rules, but probably we need a separate recording for each presentation,
G.Bazior (baziorek): so I would like to ask for this,
app: that I think we should stop the recording.