app: Hello, everyone uh welcome to another fortnight releasing of me. You know It's a community
app: today is a very special community meeting, because we have an announcement.
app: The Hyp: another um technical oversight committee election. Um,
app: Everyone is welcome to balance um, as you know. And um, it was collectively decided that I would need to put forward my candidate
app: to have a say in Walmart as I as you.
app: It's basically improving new projects in discussing old ones
app: and in re-releasing all projects which also have new developments just like you know how to
app: so please anyone who is present, and anyone who isn't present, but has contributed to Hyper Ledger projects. Um,
app: if you'd like to please vote for whichever candidate you think is best suited to become a voting number
app: i'm biased, but i'll be.
app: No,
app: we do have quite a bit of things to go through. So let's start
app: First of all, A. New Q. A. Process has yielded some really good results. We have identified Um, the triage, all of the bugs that we had.
app: We have. We tested them, and we have confirmed that
app: about sixty percent of them are not bugs. Most of them were. Uh you want a ux issue where people
app: didn't get the expected result of the reason that they didn't actually uh understand what was supposed to be done. And this is a failure on our side. We should be fixing this, and we have started a process already.
app: Um foreign function interface for Web Assembly is called an ice
app: Um. We have produced a documentation for it. Um! And we will revisit this at some later points
app: uh those laser points will unfortunately have to be after the mid November, because um the people who are involved in that
app: um.
app: They are a little preoccupied.
app: We have any consensus. We have managed it,
app: and it has shown to be, uh in immaculate improvement in some ways. Uh but it also has a bug it's manages to deny on service. Um! They have to be a communication system, and because this is based on actors, it was incredibly difficult to debug, and it wasn't
app: actually, until uh last Sunday that we
managed to figure out what was wrong,
app: because problem was that
app: we have assumed that if it worked on normal machines, the the machines that we develop on that it would automatically mean that it would work on more machines.
app: That was far from the case, and we have found that we can. Machines like the ones that are deployed in the Kubernetes, for example, have trouble.
app: Um. We have back ported a temporary workaround
app: into the Lts. We're also working on a dynamical solution which we also should be back porting into the Lts. Um. That should resolve all those issues in the future,
app: and would give us a little bit more certainty about what's going on.
app: Of course, uh we have better ui and user experience for the genesis block
app: simply put. We have
app: come up with a few ideas how we can simplify the entire process of meeting transactions, and that has to do with improving the Json language that we use for submitting new transactions. The way that we pass it we'll necessarily a little bit more code from our side. But as a result,
app: uh, we get a domain specific language for free,
app: and that language is similar to Jason, allowing people to use browsers and other tools for creating the appropriate things. Of course we'll be releasing a companion. Applications as well.
app: Configuration in general now has better default. Handling
app: What this means is things that should be set
app: explicitly by the user and now required things that shouldn't be set by the user are not required.
app: Um, if there are any conflict between the two uh an explicit message stating that an override has taken place in the people. Um, if they miss spelled an environment variable or something like that. They know something went wrong.
app: Uh,
app: and in general the documentation is up to date,
app: and it is pruned in the sense that we no longer have legacy pieces of information on the repository
app: that could mislead you users. They might find documentation things that are no longer present, things which were planned and have not yet been implemented, and things which have decided never to implement at all.
app: Of course, um like of great importance to present company
uh typical requests related to your home.
app: Um,
app: but I wish it will request seventeen seventy-six um with most uh through a little effort.
app: But eventually we did manage that um twenty, six, sixty, and J's work uh requires a little bit more attention.
app: I found that it was written very well, but it did not conform to us down guidelines. Um, it's missing a little bit in the documentation department that I have suggested. Um fixes for that.
app: Um. There are some architectural decisions like using springs and calls channel stars, which
app: again, the up to which standard of the language people are using. Otherwise it's
app: very much, architecturally sound and ready to merge even with these uh statistic differences.
app: Um, of course we have bug fixes. Um! Let's look at communication, for example, uh block streaming. We'll talk about them later.
app: Uh, and you know as well Um. A piece of code that was designed by one of our interns is in review
app: in a sense that is completed. It just hasn't been
app: Address: Yes,
app: um! We are fixing the block streaming. Api
app: um! It is useful for practice, actually, mostly um, and the website communication is saving up on a lot of round trips. Um,
app: it's a little bit complicated, if you wish. I will explain this in more detail after the community meeting
app: permission. Events are admitted for roles to now, in the sense that if a permission has been revoked from an account, no matter which mechanism you use, you were in explicit revocation of that specific permission
app: or um implicit for vacation through our role in both cases. Now you can set up a listener for that particular event.
app: No,
app: we had hoped for. We have fixed the zombie genesis bug
that isn't the case
app: we have identified that it is not, in fact, just a problem with the era uh binary.
app: It is, in fact, related to
app: let's just say how it's being used as well.
app: Again, this is a ui ux problem as much as it is a binary problem.
app: And we should okay to the used case where those things do happen, and we should be providing enough feedback in the logs, so that people know that something that wrong
app: as of today we don't.
app: Okay, what else do we have? We have? That's a new type of
app: what does that mean? Well,
app: you know, high is a concurrent process. It requires quite a bit of effort to actually write things in a concurrent manner.
app: Sometimes it may mutual exclusion, and the new text that we have been using so far the Standard Library new text
app: makes a few, makes very few assumptions actually,
app: which makes it useful. For when you're writing generic or generalized code,
app: but not in fact, when you're writing a very specific application like you know,
app: we found that the fairness was a much more important than the ability to recover from panics. Given that all panics in Iraq course
app: your hands are shut down. And so there is no handling of that.
app: As a result, we are coming up with
app: uh a global replacement with one of the indirect dependencies,
app: and it can yield a significant performance. Improvement as well as um improve the Api
app: in a sense that it's easier to write things for you know how in
app: finally, uh, Victor, here
app: is going to be presenting the blockchain all right at some later date. Um! Everyone is invited. Of course this demo is mostly for internal use, but anyone who's using it. You know how based
app: projects might be interested in um. An error related to
app: we'll show what's working um,
app: and we'll explain why things are done. Certainly.
app: Now runtime permission validate this implementation. It's on hold. In general. We don't have an Rfc. It. We have not designed a common plugin system. Uh, but we have the stubs for that. We can now accept base sixty-four encoded um webassembly blocks, as input.
app: What this allows us to do is this allows us to in the future submit an entire dimension validated set. We'll have to decide on the Api. But what this means is that you know he's no longer confined to um one type of private blockchain, and, in fact,
app: both of these kinds of blockchains can go to this on the same network,
app: incredibly fascinating design. I would recommend anyone who is interested to let us know, so that we keep you posted when the Rfc. Very
app: practice interoperability. We done the first steps
app: um where
app: i'm route to deploying the first functional bridge.
app: In fact, this is something that will be having by Monday,
app: and we'll be demonstrating this on a real world example,
app: although i'm not sure whether that example
app: it's public in the sense that we are allowed to share the details.
app: But i'm sure but some parts of it are, and we'll be happy to demonstrate um how tactics can be used to bridge. You know how to er
app: how it could be used to bridge your hard to another compatible blockchain. Uh, say, after you call them, or
app: and of course, Webassembly dynamic linkage
app: again, I said, it's on hold.
app: What have we managed to do? Well, the ffi is not quite done.
app: Um! The
app: thankfully uh while we were doing this wasn't time, the library that we used to host a webassembly
app: robber, javascript virtual machine inside of it, or
app: mit ctl, and has decided on a method of dynamic linkage. So we no longer need an in-house implementation. We can actually rely on the one that's provided. One.
app: It does require us to adapt a few things, and if those things might actually have profound implications for run time, the mission that it's given both subsystems with assembly, and the lot of code is going to be shared,
app: it is preferable to not store the repeated code several times as statically linked by this. On the other hand, there are security advantages to having statically linked binaries, particularly in terms of performance. Given that runtime permission, Validators
app: are going to be run
app: on all transactions, and in that case a little bit of trade off between memory, usage
app: and speed of processing is actually worthwhile,
app: you know, if I could be raised into this um we have i'm route to finishing this as well.
app: We are moving some objects from conflict to is, What does that mean? Well, if you think about it, there are certain instructions
app: which has to be applied globally in the sense that these are not variables that exist on any of the individual peers. They exist on the blockchain, and every valid pier, i. E. Appear that has been given the right information one way or the other, has to have it
app: some configuration. Parameters that used to be treated as configuration. Parameters inside of a config file
app: do affect consensus,
app: as such
app: block hashes might not be agreeable
app: if one of the peers has a different configuration file. Now, this is a user experience problem. You should make sure that they're one way to do this is to be a bootstrap.
app: Actually, that is not necessarily the right approach to this. So, instead of having these things defined in the configuration, Json file instead, what they're going to be defined is inside the genesis block
app: via special instructions. What this also allows you to do is it allows you to set up uh a blockchain with one set of premises, then upgrade those sets of parameters, and also massively track the consensus process
app: in that sense. If you add a new pier,
app: it doesn't have to have manual intervention in order to validate all the blocks, Even with these changes, and you get runtime upgrades for free.
app: For this to work, we actually need to consolidate what we call the worst like view. Object. Um. It contains quite a bit of information. It's basically a god object, and we're not happy about it. We Haven't had time to uh work on the technical debt. So it looks awful.
app: We
app: i'm not in a very good position right now to address this,
app: but I think we will have some time later
app: to actually fix all of this and produce a lean, neat, and usably configurable system.
app: In a sense that user experience. Errors, uh, just user errors in general are not as fate.
app: So we have a place at the as well. Um. In fact, this is largely um. The accomplishments of one person.
app: Um, with considerable amount of help from um. Both myself and William will have been overseeing this. Um,
app: but in general we have sorting,
app: explained. Um, it's sorting by metadata. He had nothing else. And this is a deliberate design choice, in fact, sorting with something we didn't plan to implement at all.
app: So we've made that clear.
app: Pagination is still not very well documented. Given that we've not actually frozen the pagination Api. The reason why i'm implemented sorting was because people want it for
app: the well. If you made a paginated query, and then you added some data the next time you would have gotten data. You would have repaginated the new results, and you could have
app: gotten weird
app: pages, so to speak.
app: Um, we'll need to think of a way Given the new world to you, as I mentioned previously, and the fact that it's long term process to actually fix pagination separate from sourcing, and probably remove something altogether, eventually
app: filtering uh the Api, for which is
app: more or less done.
app: But it still requires a bit of effort on our part in order to make mainstream, and in order to be used widely, we don't have lots of examples, and we don't have lots of example. Use cases,
app: but what we do have good documentation for is queries um Queries are used by everyone, and they run our high priority.
app: Finally, we have load script improvements. Well, calling it a script is a bit of a miss Now, when it's actually a rust binary that uses
app: uh
app: the client's api um! It's one of the things that it's very much single that it's in the sense that it produces.
app: It listens and produces load from the same main loop. Um, We might actually extend this a little bit, so that we can produce higher loads.
app: Uh previously it's used to bombard, you know, with them to instructions only. Now we have more opportunities to submit instructions in the type of register. It's type of mint of the type of grounds and revoke.
app: Of course, these instructions, and not particularly by us themselves. We only registered Council assets. There are many other things which we could register,
app: and they make no assumptions, so we can't have a set preset number of failing instructions and a preset number of succeeding instructions. But we're getting that,
app: and of course, the more I can, it's transactions for second estimation.
app: It largely depends on how we do things again. Um. The limiting factor here is the Io throughput,
app: because we're bombarding pretty much one pier we have to bombard from several
app: threads have a tendency to not work predictably so. A transactions per second estimation will have to be done some other way, so to speak.
app: So one is plan long term the key set of account restructuring has been hotel. Unfortunately, um! It's still one of the long term plans. It's not a short term plan, precisely because of the issues that we've been having with Uiux and uh
app: some teams um having trouble with the new uh definitions, so to speak, and the new syntax, the local reputation system.
app: Well, again, it's put off offline transactions, patching compatibility, transaction, these, and boost up here. They're all in the back of my mind. Uh Bootstrap here is is probably the one that's the most likely to come up soon,
app: because the unified configuration interface is supposed to lead into that,
app: and we are making a progress on this, because the developers who are working on it um
app: don't work on anything else, and frankly, wouldn't be bothered
app: because I wouldn't allow them to be.
app: Let me paraphrase this. Um.
app: The people who are working on the unified configuration interface um
app: all right. Immune from having to pivots to other types of work
app: which is a common occurrence, and the reason why both
app: web, assembly, dynamic linkage,
app: keycentric accountary, structuring and offline transactions had to be put off
app: right. Thank you for your time, And now I would like to take questions.
app: I I would have a few questions, but they don't have to be recorded that. So?
app: Any other questions
app: ones that should be recorded.
app: I any of the present company.
app: Okay,
app: um Andre uh, we uh, I approve. Okay, let's discuss this as always.
app: Um,
app: uh victor. I think we can finish the recording, and we can move on to Andre and.