Welcome (Mark Ford)
Planning for Sawtooth 1.2 Release

Open Issues (Including Bugs and Improvements) (Mark)

There are several improvements and bugs. We should take into account this list when figuring out the cut-off date. Please add to the list if there are other issues not already shown.

Feature cut-off date? (Is two weeks enough time?) (Shawn)

The list (presented above) are things we may block the release until they are done. Are there any other issues that need to go in?
What is the current branch point? (Dan)

Master (Shawn)

There are quite a few features since 1.1 in master, we are asking for any additional features that are not currently on the list, such as RFCs. For example the delete by prefix RFC (Shawn).
Given this list, should we target a feature cut-off in two weeks? Note this would not include bug fixes, as some of these are not trivial and may take more time. Are two weeks reasonable? (Shawn)

Ideally, everything will be in at that point, and we will only backport bug fixes that are breaking release criteria (Dan)
It was determined that the cut-off would be two weeks from this meeting, so Monday, May 6th.

The current master will become 1.2? (Arun)

We will branch master after the cut-off date for 1.2. Then we will backport from that point. (Shawn)

Is it possible to tag a version of Sawtooth Raft as it is now with the current master? The previous tag is old. (Arun) (Manojgop)

Yes, if you request a component release on Tuesday in the sawtooth-release channel on rocketchat and then the release will hopefully be done on Thursday. (Shawn)

After the release, the docker image will match the release? (Manojgop)

Yes (Ryan)

PRs determined as candidates for 1.2 (These will require JIRA issues tagged for Version 1.2):

Bionic Poet https://github.com/hyperledger/sawtooth-poet/pull/15

COMMENT: There were bugs around starting a consensus engine, which have been addressed. So, the Bionic Poet PR just needs to be updated and the fixes will be a part of the 1.2 release. (Peter)

Allow Transaction Header to Receive Raw Transaction Header from Client https://github.com/hyperledger/sawtooth-core/pull/1995

PBFT Updates (Logan)

PBFT is complete. We have done a good amount of testing, Long running and unit tests. If anyone would like to take a look that would be useful. We are currently working on getting the documentation ready for the PBFT 1.0 release.
What is the release criteria? (Dan)

It was the 30-40 unit tests as well as passing the LR tests (Shawn)

What is the performance testing criteria? (Dan)

It is currently better than anything else we have, but we do the test at the maximum load the network can handle (transaction per seconds) with 10-8 nodes (Shawn)

Open RFCs (Andi)

Add new peers without restarting a node (Eugene B)

The RFC author was not present on the call to field any questions

Delete by prefix RFC (Yoni Wolf)

There are a few outstanding comments (some grammatical) that need to be addressed
A “Not Extend” option should be documented in the RFC, so reviewers can consider that possibility (Shawn)

Upcoming RFCs (Shawn)

OVERVIEW: These three RFC have been heavily discussed on rocketchat and are very complicated. We identified 3 possible RFCs that could fall out of this discussion. We created 3 Google Docs that allow people to collaborate on them before they are submitted to the RFC repo. We want to make it available to anyone who wishes to participate. If you would like to have access to these docs (beyond view only) please send me a direct message and I will add you. (Shawn)
RFCs

Invalid Transaction Purging (Logan)
Transaction Expiration (Logan)

These two are two possible solutions to fix the purging invalid transaction from the pending queue. The first one is about guessing which transaction should be removed, the second adds a range that the transaction can be considered to go into a block, if the transaction is not in the block range it will be removed. (Logan)

Inclusion of All Transactions in a Block (Arun)

Arun had advocated for this in rocketchat which resulted in a document (Shawn)
The suggestion is to include all transaction into a block (valid and invalid) as a way to notify the other validators on the network if the validator found a transaction to be invalid. (Arun)

Topics Unrelated to Sawtooth 1.2 Release

Pending PRs

Sawtooth-raft grafana statistics tracking (Arun)

Adds a YAML file to bring up the sawtooth network and start grafana statistics tracking. (Arun)
How should we manage multiple grafana dashboards with the consensus engines? I would assume there are going to be raft specific dashboards. One way we could do it is have all of them on one, with only some being filled in. Another option would be ship consensus specific ones with the consensus engine. (James)

This PR does not introduce a new graph, it adds a YAML file and uses what is shipped in sawtooth core. (Arun)
This is more of a takeaway questions about thinking how we should provide a more complete solution (James)

Adding Grafana sawtooth to a sawtooth-contrib repo would allow us to define different dashboards with less of the overhead/maintenance of keeping this in sawtooth-core. (Shawn)

Do we have a sawtooth-contrib repo yet? (Arun)
- Not yet, but I am going to propose it. (Shawn)

Defects

PoET1 status and issue owners (Dan standing in for Amol))

This has been fixed by updates to sawtooth-core, this would be good to verify (Dan)
We actually do this every night as a part of nightlies (Ryan)

Plan for PoET 2 PRs and merging (Arun)

There is a PR merged that fixes the branch and we need to rebase PR on the fixed branch. That is the plan to get the rest merged. (Manojgpop)
If we have problems who should we contact, what rocketchat channel should be used? (Arun)(Manojgpop)
sawtooth-consensus can be used (Shawn)
We should have regular discussion of Poet2 in rocketchat (Arun)

Discussion on how to create empty blocks, to keep the flow (Arun)

This can wait as there are other things that need to be done in Poet2 (Arun)

State checkpoint feature, plans (Arun)

What is the timeline for this feature? (Arun)

There are still a lot of design discussions around this. Probably more of a Sawtooth 2.0 feature. Not in the immediate future. (Peter)

Proposal for plugin based reading of private keys. (Arun)

The current design is to provide a private key to the sawtooth validator. This is stored when it starts up. This is a proposal to store the keys in safe storage, and if possible the validator provides a way to read from an interface instead. (Arun)
Another place this applies is in Hyperledger Ursa. There is one possible future where sawtooth adopts Ursa (Dan)
I think we should start an RFC for this proposal with a google doc with the other one. (Shawn)
ZMQ queue is hardcoded and it would be nice to be able to dynamically update it (Arun)
I think the correct solution will be to change to using TLS instead of ZMQ (Shawn)

Open Forum

Going forward, if you introduce a topic please add your name next to it so we know who will discuss it (Mark)
What version of Sawtooth will Grid use? (Clive)

Hyperledger Grid will use Sawtooth 1.2 once it is released. (Shawn)

Browser not supported