8/26/2019 Agenda & Notes

We are running multiple LR7 networks to ensure the stability of v1.2 and v1.1 to identify any remaining regressions. Once we are satisfied, we will schedule and announce the release with Hyperledger.

We think we have found the source of the regression. Some changes with the consensus engines and a PR to revert a change to expire futures. Those will get us back to successful PoET runs. We are going to start up new LR7 runs for PoET and PBFT, but we expect them to succeed. (James)

There was a PR merged recently, and I think there will be an issue with the Z-test. (Arun)

We have seen any issue in the tests we have run, the only change is that if there is any pending work we wait to publish. The fix has reduced the amount of fork validation. (James)

I wanted to see if there was anything else that needs to happen to get this patch into 1.2. I have the tests passing. (William)

We will want to test this before backporting this to 1.2. So, we should plan to add this to 1.2 as a point release. We want to get the current stable 1.2 released, and then we can immediately do a point release with this change after it is tested on an LR network. (Shawn)

https://github.com/hyperledger/sawtooth-sdk-python/pull/4 The SDK changes for the raw transaction header feature, addressing comments (Arun).

I have addressed the comments left by Peter on this PR. I used an enum to keep track of the different versions. (Arun)

Is it possible to print a message when system resources are not sufficient to handle the Sawtooth application? (Arun)

This is not a best practice, this would be dependent on what is being run on the application. These seems like something that should be in the Docs but not require the application to keep track of it. (James)
It would also depend on what system resource we are talking about. We could write up guidance for this stuff but it depends on the load. I think logging a statement when we are out of memory would be useful. (Shawn)
Maybe this could be something in grafana to give alerts when a validator is using too much CPU or something is abnormal to the earlier part of the run. (Richard)

I understand that PoET should be converted to Rust first, but this is a problem because we already have PoET 2. We decided to start this project under hyperledger labs and then move this back into hyperledger. (Arun)

You should call it something besides PoET 2 as we may release a PoET 2 version. To be clear Intel is not going to provide a rust version of the current PoET Validator Registry. This is the only first order transaction processor that does not support running in Sabre. (Shawn)

It depends on who is supporting PoET and where. Here at Bitwise we are more interested in PBFT, so if there are no other maintainers working on PoET it becomes a distraction to our other development. I can't see that continuing on without other support. (Shawn)

I assume that is so it doesn't have to go through the current PoET peer review. Which is setting us up for quite a bit of testing in the future once it is ready to come over. It will be quite a lot of work on the tail end. If we can break out shared parts and test that as we go, when we get to the new consensus engines, it is easier to see where failures may have been introduced. We went through month long tests to get PBFT to be stable. Raft isn't there yet, and it is way simpler than PoET, but there aren't enough maintainers to even get Raft passing. I am concerned that when PoET 2 is done it will not be reliable enough to reach our high bar. (Shawn).
Is there a timeline for when we will see PoET 2 stuff in labs? (William)

I have put up a PR to create a repository in labs and then more work will be put up in PR. (Arun)

This is a good question. As a part of transact we have been working on more reusable network level code that would probably be nicer but we don't have it in transact yet, but it will be packaged up in a more consumable fashion. So we have the rust sdk networking piece, but most of it in the validator is currently python, so we have been talking about how we share the networking layer between the different components. My concern is in the duplication of code if we put up the networking code, and then you put in a lot of work into a component that we are planning to replace. We are working on enabling ZMQ, but also TCP and TLS socket support and be able to swap out the different transports, but its not currently working with transact. I would suggest using the easiest path for now until we have this available. (Shawn)

I think duplicating code will be easy for now, but I would also make it clean. (Arun)
We have started working on stuff for transact, we have developed a client SDK library and are trying to decide at what level the networking level belongs. We have pulled out stuff from the Go SDK, so we are also looking at this issue. (William)