feat(spec): discussion of consensus getValue() function

specs/consensus/overview.md

@@ -229,7 +229,7 @@ thus `⟨PROPOSAL, h, r, validValue_p, validRound_p⟩`.
 
 If the proposer `p` of a round `r` of height `h` has `validValue_p = nil`, `p`
 may propose any value it wants.
-The function `getValue()` is invoked and returns a value to be proposed.
+The [function `getValue()`](#proposal-value) is invoked and returns a value to be proposed.
 The message it broadcasts when entering the `prevote` step of round `r` is
 thus `⟨PROPOSAL, h, r, getValue(), -1⟩`.
 Observe that this is always the case in round 0 and the most common case in
@@ -492,13 +492,37 @@ selection algorithm becomes more challenging.
 
 ### Proposal value
 
-The external function `getValue()` is invoked by the proposer of a round as
-part of the transition to the [propose round step](#propose).
-It should return a value to be proposed by the process `p` for the current
-height of consensus `h_p`.
-
-> TODO: synchronous/asynchronous implementations, currently discussed
-> [here](../english/consensus/README.md#asynchronous-getvalue-and-proposevaluev).
+The `getValue()` function  is invoked by the [proposer](#proposer-selection) of
+a round when it is free to produce a new value to be proposed, namely in the
+first round of a height or when `validValue_p = nil` (more details in the
+[Value Selection](#value-selection) section).
+
+In other words, the `getValue()` function is the way in which Tendermint
+implements the **propose** consensus primitive.
+Instead of having the context/application that uses the consensus protocol
+invoking it with a value to be proposed, when a process running Tendermint can
+propose a value, it invokes this function so that the context/application can
+provide the value to be proposed.
+
+> Notice that this is a design concern that is encoded in Tendermint's
+> pseudo-code.
+> A priori, every process running a consensus height could provide its proposed
+> value for that height, but this approach has some disadvantages:
+> - During regular execution, typically a single or few processes are allowed
+>   to propose new values (i.e., the proposers of the first round or rounds).
+>   The values produced by most processes are therefore likely to be completely
+>   disregarded by the algorithm, which becomes particularly inefficient when
+>   producing a value to propose is expensive;
+> - Proposed values are likely to aggregate multiple inputs received from
+>   clients (e.g., transactions that form a proposed block).
+>   By providing the proposed value at the beginning of a height to a process
+>   that will only be the proposer of a high-numbered round, when this round is
+>   reached the proposal is likely to be incomplete or outdated.
+
+Since only proposed values can be decided, if `v` is decided at height `h`,
+then `v` was the value returned by the context/application running at a process
+`p` when in invoked, as part of a round `r` where `proposer(h, r) = p`,  the
+`getValue()` function.
 
 ### Validation