Typo fix how_alephbft_does_it.md

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.