3/25/2019 Hyperledger Sawtooth Contributor Meeting Agenda

• Welcome (Mark Ford)
• Planning for Sawtooth 1.2 Release (Shawn/Mark)
• Open RFCs (Shawn)
  • #37 (Swift SDK) - https://github.com/hyperledger/sawtooth-rfcs/pull/37 - FCP Proposed
  • #29 (PBFT Regular view changes) - https://github.com/hyperledger/sawtooth-rfcs/pull/29 - FCP ends March 29
  • #30 (PBFT Consensus seal) - https://github.com/hyperledger/sawtooth-rfcs/pull/30 - FCP Proposed
  • #31 (PBFT Node Catchup) - https://github.com/hyperledger/sawtooth-rfcs/pull/31 - FCP Proposed
  • #20 (Poet 2) - https://github.com/hyperledger/sawtooth-rfcs/pull/20 - Please review; any remaining blockers?
  • #39 (delete by prefix rfc) - https://github.com/hyperledger/sawtooth-rfcs/pull/39 - Please review
  • #32 (Add new peers without restarting a node) - https://github.com/hyperledger/sawtooth-rfcs/pull/32 - Please review
• Plan and action for pending batches in a validator node (Arun)
• Sawooth Raft - Feature addition: Change the Raft leader nodes periodically (in round robin basis) based on a time or block interval  (Manoj)
• Issue with "maximum_peer_connectivity" (Arun)
• Conclusion on builds in proxy network (Arun)
• Pending PRs
• Open Forum

Discussion on sawtooth-core issues:

1. Plan and action for pending batches in a validator node. For example, in case of consensus engine like sawtooth-raft if an invalid transactions are not removed from follower nodes pending batches queue.
2. Issue with "maximum_peer_connectivity"
   1. Name suggests that it limits maximum peers a validator can connect to. But in reality it appears to be limiting the number of connections (there's one inbound and outbound connection).
   2. Seen that there are multiple connections to the same validator node. Causing the node to reach "maximum_peer_connectivity" limit and reject all other peering requests. Experimented with just 4 nodes.

Sawtooth Raft

      1.  Approve below feature request for Raft. Changes are ready and tested. Can we raise a PR

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

     This feature will initiate leadership transfer to next peer if either one of below condition is satisfied
     1) Time elapsed in leader state exceeds threshold setting
     2) Number of blocks committed by leader exceeds threshold setting

     Below are the Raft settings. Setting the value to 0 will disable the feature
     sawtooth.consensus.raft.leader_change_time_interval (time interval in millisec)
     sawtooth.consensus.raft.leader_change_block_interval (number of blocks)

Other topics:

1. Conclusion on builds in proxy network

Pending PRs:

1. PRs in sawtooth-core
   1. Allow transaction processor to receive raw transaction header.
2. PRs in sawtooth-raft
   1. Issue and discussion on need for forking in sawtooth-raft.

RFC review:

1. Delete by prefix, plan and actions.