• Look at what features are missing from approved RFCs
    • Propose a cut-off date for new commits for the release
    • Testing will be conducted for at least a month. This also includes LR testing to identify regression issues
    • Release coordination activities will occur after testing
  • Things that could hold up a release:
    • Features that have RFCs (not new ideas)
    • Regressions; for example:

      • API

      • Security Issues


  • Discussion Topics

    • Plan and action for pending batches in a validator node (Arun)

      • Invalid transaction are only removed when the consensus engine becomes the leader (for Raft and PBFT). Always gets the status back as if it is pending. We need a mechanism that removes the invalid batches in this case (specifically when the leader does not change very often for example in Raft)

      • Probably need an RFC to figure out this issue - Shawn

      • We need a way to time out pending batches or for the consensus engine to tell the validator to purge out the bad batch. This is a specific issue with leader election and needs a lot more thought since you may not run into this during lottery - Peter

      • The leader may have rejected a batch, but the follower that becomes the leader may retry a transaction that is now considered valid. - Arun

    • Sawooth Raft - Feature addition: Change the Raft leader nodes periodically (in round robin basis) based on a time or block interval (Manoj)

      • This is related to the above issue. (This is similar to what we do in PBFT.) Give a fair chance for every node to become the leader.

      • We should have an RFC for this, but it is very similar to the PBFT RFC #29 - Logan

      • Consensus changes having an RFC is very good idea - Shawn

      • Even though this is available in the Raft rust code, we still want the RFC because it changes the way the algorithm is currently implemented - Logan

    • Issue with "maximum_peer_connectivity" (Arun)

      • Naming of the setting is incorrect? It implies the number of peers, but actual controls the number of incoming and outgoing connections

      • Check for JIRA:, need to add a check that if the public key is already authorized, we need to drop the new connection

    • Conclusion on builds in proxy network (Arun)

      • Agree on a single approach or remove the feature from the dockerfiles. - Shawn

  • Open Forum

    • Requesting re-reviews from maintainers for PRs on Github

      • Location of maintainers makes it hard to have timely response, but they do not have any way to re-request reviews on github.-Amol

      • Not everyone pays attention github emails. Please directly ping people on rockchat or in the core-dev or consensus-dev channels. Use email if you know the email address.-Shawn

    • PoET 2 PRs

      • Starting to raise PoET 2 PR, more PRs are on the way. Thank you for those that have looked at it.- Amol

      • Current ones are hung up on some build issues. Once PoET 2 PR is updated to master,  the other PRs need to be rebased on it. - Shawn

      • Happy to give an overview of the code and the organization of the code base. - Amol

      • If the spec is updated for the validator registry, we need to see that to be able to review the PR. - Shawn

    • Idea for fixing pending batches that are lingering

      • Another idea about fixing the pending batches staying around. List the batches considered in the block, to tell the other validators what is invalid. - Arun

      • Optimizing for the pending queue, but this is not needed in poet for example - Shawn

      • Each individual node needs to be able to handle what pending batches are removed. Need to be able to handle things like ignored transactions. This needs to be discussed (possibly in chat) and then write the RFC. The RFC is what gets persisted on a reference.

      • Also, this is not needed for nodes during catch up (they don't have this problem) causes larger messages sizes. - Peter

    • Consensus messages and need to be seperate form gossip

      • Raft sends a lot of messages. Create a separate channel for messages or be able to add a high priority to conesus messages. The consensus messages are at the same priority as all the other gossip messages. - Manoj

      • Important to consider making the network layer separate from other layers. Gossip is fundamental and we are only doing one type of gossip. Also, we are planning to rewrite the networking layer in rust while being careful not to make the network layer more difficult while doing so. When accepting the message from a peer, we have to just accept but could after. In Sawtooth 2.0 we need to remove the bottleneck and they are routed to the correct subsystem and that is in charge of doing all of the checks. So consensus messages would be handled in its own thread. This, however, is tied up with the rewrite activity. - Shawn

      • How do we handle requirements for rewriting the Networking Layer? We need a suitable solution to document these requirements for the next year. - Shawn

  • No labels