|
rippled
|
Generic implementation of consensus algorithm. More...

Classes | |
| class | MonitoredMode |
Public Types | |
| using | clock_type = beast::abstract_clock< std::chrono::steady_clock > |
| Clock type for measuring time within the consensus code. More... | |
Public Member Functions | |
| Consensus (Consensus &&) noexcept=default | |
| Consensus (clock_type &clock, Adaptor &adaptor, beast::Journal j) | |
| Constructor. More... | |
| void | startRound (NetClock::time_point const &now, typename Ledger_t::ID const &prevLedgerID, Ledger_t prevLedger, hash_set< NodeID_t > const &nowUntrusted, bool proposing) |
| Kick-off the next round of consensus. More... | |
| bool | peerProposal (NetClock::time_point const &now, PeerPosition_t const &newProposal) |
| A peer has proposed a new position, adjust our tracking. More... | |
| void | timerEntry (NetClock::time_point const &now) |
| Call periodically to drive consensus forward. More... | |
| void | gotTxSet (NetClock::time_point const &now, TxSet_t const &txSet) |
| Process a transaction set acquired from the network. More... | |
| void | simulate (NetClock::time_point const &now, std::optional< std::chrono::milliseconds > consensusDelay) |
| Simulate the consensus process without any network traffic. More... | |
| Ledger_t::ID | prevLedgerID () const |
| Get the previous ledger ID. More... | |
| ConsensusPhase | phase () const |
| Json::Value | getJson (bool full) const |
| Get the Json state of the consensus process. More... | |
Private Types | |
| using | Ledger_t = typename Adaptor::Ledger_t |
| using | TxSet_t = typename Adaptor::TxSet_t |
| using | NodeID_t = typename Adaptor::NodeID_t |
| using | Tx_t = typename TxSet_t::Tx |
| using | PeerPosition_t = typename Adaptor::PeerPosition_t |
| using | Proposal_t = ConsensusProposal< NodeID_t, typename Ledger_t::ID, typename TxSet_t::ID, typename Ledger_t::Seq > |
| using | Result = ConsensusResult< Adaptor > |
| using | AcquiredType = beast::aged_unordered_map< typename TxSet_t::ID, const TxSet_t, clock_type::clock_type, beast::uhash<> > |
Private Member Functions | |
| void | startRoundInternal (NetClock::time_point const &now, typename Ledger_t::ID const &prevLedgerID, Ledger_t const &prevLedger, ConsensusMode mode) |
| void | handleWrongLedger (typename Ledger_t::ID const &lgrId) |
| void | checkLedger () |
| Check if our previous ledger matches the network's. More... | |
| void | playbackProposals () |
| If we radically changed our consensus context for some reason, we need to replay recent proposals so that they're not lost. More... | |
| bool | peerProposalInternal (NetClock::time_point const &now, PeerPosition_t const &newProposal) |
| Handle a replayed or a new peer proposal. More... | |
| void | phaseOpen () |
| Handle pre-close phase. More... | |
| void | phaseEstablish () |
| Handle establish phase. More... | |
| bool | shouldPause () const |
| Evaluate whether pausing increases likelihood of validation. More... | |
| void | closeLedger () |
| void | updateOurPositions (bool const share) |
| Adjust our positions to try to agree with other validators. More... | |
| bool | haveConsensus () |
| void | createDisputes (TxSet_t const &o) |
| void | updateDisputes (NodeID_t const &node, TxSet_t const &other) |
| void | leaveConsensus () |
| NetClock::time_point | asCloseTime (NetClock::time_point raw) const |
Private Attributes | |
| Adaptor & | adaptor_ |
| ConsensusPhase | phase_ {ConsensusPhase::accepted} |
| MonitoredMode | mode_ {ConsensusMode::observing} |
| bool | firstRound_ = true |
| bool | haveCloseTimeConsensus_ = false |
| clock_type & | clock_ |
| int | convergePercent_ {0} |
| ConsensusTimer | openTime_ |
| NetClock::duration | closeResolution_ = ledgerDefaultTimeResolution |
| std::chrono::milliseconds | prevRoundTime_ |
| NetClock::time_point | now_ |
| NetClock::time_point | prevCloseTime_ |
| Ledger_t::ID | prevLedgerID_ |
| Ledger_t | previousLedger_ |
| AcquiredType | acquired_ |
| std::stack< typename TxSet_t::ID > | acquiredPurge_ |
| std::optional< Result > | result_ |
| ConsensusCloseTimes | rawCloseTimes_ |
| hash_map< NodeID_t, PeerPosition_t > | currPeerPositions_ |
| std::map< typename Ledger_t::Seq, hash_map< NodeID_t, PeerPosition_t > > | recentPeerPositions_ |
| hash_map< NodeID_t, std::deque< PeerPosition_t > > | recentPeerPositionsLegacy_ |
| std::size_t | prevProposers_ = 0 |
| hash_set< NodeID_t > | deadNodes_ |
| const beast::Journal | j_ |
Generic implementation of consensus algorithm.
Achieves consensus on the next ledger.
Two things need consensus:
The basic flow:
startRound places the node in the Open phase. In this phase, the node is waiting for transactions to include in its open ledger.timerEntry check if the node can close the ledger. Once the node Closes the open ledger, it transitions to the Establish phase. In this phase, the node shares/receives peer proposals on which transactions should be accepted in the closed ledger.During a subsequent call to timerEntry, the node determines it has reached consensus with its peers on which transactions to include. It transitions to the Accept phase. In this phase, the node works on applying the transactions to the prior ledger to generate a new closed ledger.
Try to avoid advancing to a new ledger that hasn't been validated. One scenario that causes this is if we came to consensus on a transaction set as other peers were updating their proposals, but we haven't received the updated proposals. This could cause the rest of the network to settle on a different transaction set. As a validator, it is necessary to first build a new ledger and send a validation for it. Otherwise it's impossible to know for sure whether or not the ledger would be validated–we can't otherwise know the ledger hash. If this ledger does become validated, then proceed with book-keeping and make a call to startRound to start the cycle again. If it doesn't become validated, pause, check if there is a better transaction set, and try again.
This class uses a generic interface to allow adapting Consensus for specific applications. The Adaptor template implements a set of helper functions that plug the consensus algorithm into a specific application. It also identifies the types that play important roles in Consensus (transactions, ledgers, ...). The code stubs below outline the interface and type requirements. The traits types must be copy constructible and assignable.
| Adaptor | Defines types and provides helper functions needed to adapt Consensus to the larger application. |
Definition at line 314 of file Consensus.h.
|
private |
Definition at line 316 of file Consensus.h.
|
private |
Definition at line 317 of file Consensus.h.
|
private |
Definition at line 318 of file Consensus.h.
|
private |
Definition at line 319 of file Consensus.h.
|
private |
Definition at line 320 of file Consensus.h.
|
private |
Definition at line 325 of file Consensus.h.
|
private |
Definition at line 327 of file Consensus.h.
| using ripple::Consensus< Adaptor >::clock_type = beast::abstract_clock<std::chrono::steady_clock> |
Clock type for measuring time within the consensus code.
Definition at line 355 of file Consensus.h.
|
private |
Definition at line 620 of file Consensus.h.
|
defaultnoexcept |
| ripple::Consensus< Adaptor >::Consensus | ( | clock_type & | clock, |
| Adaptor & | adaptor, | ||
| beast::Journal | j | ||
| ) |
Constructor.
| clock | The clock used to internally sample consensus progress |
| adaptor | The instance of the adaptor class |
| j | The journal to log debug output |
Definition at line 660 of file Consensus.h.
| void ripple::Consensus< Adaptor >::startRound | ( | NetClock::time_point const & | now, |
| typename Ledger_t::ID const & | prevLedgerID, | ||
| Ledger_t | prevLedger, | ||
| hash_set< NodeID_t > const & | nowUntrusted, | ||
| bool | proposing | ||
| ) |
Kick-off the next round of consensus.
Called by the client code to start each round of consensus.
| now | The network adjusted time |
| prevLedgerID | the ID of the last ledger |
| prevLedger | The last ledger |
| nowUntrusted | ID of nodes that are newly untrusted this round |
| proposing | Whether we want to send proposals to peers this round. |
Definition at line 671 of file Consensus.h.
| bool ripple::Consensus< Adaptor >::peerProposal | ( | NetClock::time_point const & | now, |
| PeerPosition_t const & | newProposal | ||
| ) |
A peer has proposed a new position, adjust our tracking.
| now | The network adjusted time |
| newProposal | The new proposal from a peer |
Definition at line 789 of file Consensus.h.
| void ripple::Consensus< Adaptor >::timerEntry | ( | NetClock::time_point const & | now | ) |
Call periodically to drive consensus forward.
| now | The network adjusted time |
Definition at line 974 of file Consensus.h.
| void ripple::Consensus< Adaptor >::gotTxSet | ( | NetClock::time_point const & | now, |
| TxSet_t const & | txSet | ||
| ) |
Process a transaction set acquired from the network.
| now | The network adjusted time |
| txSet | the transaction set |
Definition at line 993 of file Consensus.h.
| void ripple::Consensus< Adaptor >::simulate | ( | NetClock::time_point const & | now, |
| std::optional< std::chrono::milliseconds > | consensusDelay | ||
| ) |
Simulate the consensus process without any network traffic.
The end result, is that consensus begins and completes as if everyone had agreed with whatever we propose.
This function is only called from the rpc "ledger_accept" path with the server in standalone mode and SHOULD NOT be used during the normal consensus process.
Simulate will call onForceAccept since clients are manually driving consensus to the accept phase.
| now | The current network adjusted time. |
| consensusDelay | Duration to delay between closing and accepting the ledger. Uses 100ms if unspecified. |
Definition at line 1035 of file Consensus.h.
| Ledger_t::ID ripple::Consensus< Adaptor >::prevLedgerID | ( | ) | const |
Get the previous ledger ID.
The previous ledger is the last ledger seen by the consensus code and should correspond to the most recent validated ledger seen by this peer.
Definition at line 443 of file Consensus.h.
| ConsensusPhase ripple::Consensus< Adaptor >::phase | ( | ) | const |
Definition at line 449 of file Consensus.h.
| Json::Value ripple::Consensus< Adaptor >::getJson | ( | bool | full | ) | const |
Get the Json state of the consensus process.
Called by the consensus_info RPC.
| full | True if verbose response desired. |
Definition at line 1059 of file Consensus.h.
|
private |
Definition at line 730 of file Consensus.h.
|
private |
Definition at line 1157 of file Consensus.h.
|
private |
Check if our previous ledger matches the network's.
If the previous ledger differs, we are no longer in sync with the network and need to bow out/switch modes.
Definition at line 1213 of file Consensus.h.
|
private |
If we radically changed our consensus context for some reason, we need to replay recent proposals so that they're not lost.
Definition at line 1236 of file Consensus.h.
|
private |
Handle a replayed or a new peer proposal.
Definition at line 840 of file Consensus.h.
|
private |
Handle pre-close phase.
In the pre-close phase, the ledger is open as we wait for new transactions. After enough time has elapsed, we will close the ledger, switch to the establish phase and start the consensus process.
Definition at line 1276 of file Consensus.h.
|
private |
Handle establish phase.
In the establish phase, the ledger has closed and we work with peers to reach consensus. Update our position only on the timer, and in this phase.
If we have consensus, move to the accepted phase.
Definition at line 1445 of file Consensus.h.
|
private |
Evaluate whether pausing increases likelihood of validation.
As a validator that has previously synced to the network, if our most recent locally-validated ledger did not also achieve full validation, then consider pausing for awhile based on the state of other validators.
Pausing may be beneficial in this situation if at least one validator is known to be on a sequence number earlier than ours. The minimum number of validators on the same sequence number does not guarantee consensus, and waiting for all validators may be too time-consuming. Therefore, a variable threshold is enacted based on the number of ledgers past network validation that we are on. For the first phase, the threshold is also the minimum required for quorum. For the last, no online validators can have a lower sequence number. For intermediate phases, the threshold is linear between the minimum required for quorum and 100%. For example, with 3 total phases and a quorum of 80%, the 2nd phase would be 90%. Once the final phase is reached, if consensus still fails to occur, the cycle is begun again at phase 1.
Maximum phase with distinct thresholds to determine how many validators must be on our same ledger sequence number. The threshold for the 1st (0) phase is >= the minimum number that can achieve quorum. Threshold for the maximum phase is 100% of all trusted validators. Progression from min to max phase is simply linear. If there are 5 phases (maxPausePhase = 4) and minimum quorum is 80%, then thresholds progress as follows: 0: >=80% 1: >=85% 2: >=90% 3: >=95% 4: =100%
No particular threshold guarantees consensus. Lower thresholds are easier to achieve than higher, but higher thresholds are more likely to reach consensus. Cycle through the phases if lack of synchronization continues.
Current information indicates that no phase is likely to be intrinsically better than any other: the lower the threshold, the less likely that up-to-date nodes will be able to reach consensus without the laggards. But the higher the threshold, the longer the likely resulting pause. 100% is slightly less desirable in the long run because the potential of a single dawdling peer to slow down everything else. So if we accept that no phase is any better than any other phase, but that all of them will potentially enable us to arrive at consensus, cycling through them seems to be appropriate. Further, if we do reach the point of having to cycle back around, then it's likely that something else out of the scope of this delay mechanism is wrong with the network.
Definition at line 1331 of file Consensus.h.
|
private |
Definition at line 1617 of file Consensus.h.
|
private |
Adjust our positions to try to agree with other validators.
Share them with the network unless we've already accepted a consensus position.
| share | Whether to share with the network. |
Definition at line 1672 of file Consensus.h.
|
private |
Definition at line 1891 of file Consensus.h.
|
private |
Definition at line 1961 of file Consensus.h.
|
private |
Definition at line 2020 of file Consensus.h.
|
private |
Definition at line 1944 of file Consensus.h.
|
private |
Definition at line 2039 of file Consensus.h.
|
private |
Definition at line 578 of file Consensus.h.
|
private |
Definition at line 580 of file Consensus.h.
|
private |
Definition at line 581 of file Consensus.h.
|
private |
Definition at line 582 of file Consensus.h.
|
private |
Definition at line 583 of file Consensus.h.
|
private |
Definition at line 585 of file Consensus.h.
|
private |
Definition at line 589 of file Consensus.h.
|
private |
Definition at line 592 of file Consensus.h.
|
private |
Definition at line 594 of file Consensus.h.
|
private |
Definition at line 597 of file Consensus.h.
|
private |
Definition at line 604 of file Consensus.h.
|
private |
Definition at line 605 of file Consensus.h.
|
private |
Definition at line 611 of file Consensus.h.
|
private |
Definition at line 613 of file Consensus.h.
|
private |
Definition at line 621 of file Consensus.h.
|
private |
Definition at line 624 of file Consensus.h.
|
private |
Definition at line 626 of file Consensus.h.
|
private |
Definition at line 627 of file Consensus.h.
|
private |
Definition at line 633 of file Consensus.h.
|
private |
Definition at line 642 of file Consensus.h.
|
private |
Definition at line 647 of file Consensus.h.
|
private |
Definition at line 650 of file Consensus.h.
|
private |
Definition at line 653 of file Consensus.h.
|
private |
Definition at line 656 of file Consensus.h.
1.8.17