fix: typos

consensus/src/extension/election.rs

@@ -104,7 +104,7 @@ impl<U: UnitWithParents> CandidateElection<U> {
         let relative_round = voter.round() - self.round;
         let vote = match relative_round {
             0 => unreachable!("just checked that voter and election rounds are not equal"),
-            // Direct descendands vote for, all other units of that round against.
+            // Direct descendants vote for, all other units of that round against.
             1 => voter.parent_for(self.candidate_creator) == Some(&self.candidate_hash),
             // Otherwise we compute the vote based on the parents' votes.
             _ => {

consensus/src/member.rs

@@ -623,7 +623,7 @@ where
 /// = H>`] it is enough to provide implementation of [`FinalizationHandler<DP::Output>`]. We provide
 /// implementation of [`UnitFinalizationHandler<Data = DP::Output, Hasher = H>`] for anything that satisfies
 /// the trait [`FinalizationHandler<DP::Output>`] (by means of [`FinalizationHandlerAdapter`]). Implementing
-/// [`UnitFinalizationHandler`] directly is considered less stable since it exposes intrisics which might be
+/// [`UnitFinalizationHandler`] directly is considered less stable since it exposes intrinsics which might be
 /// subject to change. Implement [`FinalizationHandler<DP::Output>`] instead, unless you absolutely know
 /// what you are doing.
 pub async fn run_session<

docs/src/how_alephbft_does_it.md

@@ -185,7 +185,7 @@ One of the differences between the paper and the AlephBFT implementation is in t
 1. The `CommonVote(round_diff)` for `round_diff >= 5` is not deterministic, but is a random bit that is obtained from a seed that is generated as part of the protocol execution specifically for the unit `U` the CommonVote concerns (thus in particular the `CommonVote` function takes a unit `U` as an additional parameter).
 2. The ordering over units in `Head(r, D)` is also random and seed is generated specifically for the round `r`.
 
-The corresponding seeds are generated with an appropriate timing, so that the randomness cannot be predicted well in advance. In the AlephBFT implementation both the common votes and the permutation of units are deterministic. The consequence of this is that the version of the protocol implemented in AlephBFT does not have the theoretical property called _Asynchronous Liveness_. This property means that in a theoretical scenario when the whole network is under control of a powerful adversary, who can schedule all the packets (even from honest nodes) according to its liking, the protocol should still make progress in producing the output stream. That being said there are two imporant comments to be made here:
+The corresponding seeds are generated with an appropriate timing, so that the randomness cannot be predicted well in advance. In the AlephBFT implementation both the common votes and the permutation of units are deterministic. The consequence of this is that the version of the protocol implemented in AlephBFT does not have the theoretical property called _Asynchronous Liveness_. This property means that in a theoretical scenario when the whole network is under control of a powerful adversary, who can schedule all the packets (even from honest nodes) according to its liking, the protocol should still make progress in producing the output stream. That being said there are two important comments to be made here:
 
 - Even without randomness AlephBFT is _Asynchronously Safe_ and enjoys all the properties of the state-of-the art partially synchronous protocols such as _HotStuff_, _Tendermint_ or _Streamlet_. Moreover the asynchronous design of the protocol makes AlephBFT especially robust and resistant against practical network issues that classical partially synchronous protocols might have troubles with. Asynchronous liveness is an important theoretical property and there is a lot of technical sophistication that comes in the design of the protocol in order to achieve it, however on the practical side there is still little evidence that performing such attacks against liveness in real-world scenarios is possible.
 - Still, no matter how unlikely such attacks might be, we take them very seriously and plan to add randomness to AlephBFT in one of the future releases. We decided to go for a version without randomness first, as it gives an incredibly simple and at the same time secure and robust BFT consensus protocol. Adding randomness introduces some complexity into the protocol, so it makes sense to add it on top of a well-tested, working product. The API of the protocol will not change and we will make the use of randomness configurable.