Skip to content

Commit

Permalink
CAP-0034 wording improvements
Browse files Browse the repository at this point in the history 
Incorporate further code review comments to correct and
clarify several pieces of SCP-related wording and
presentation.
  • Loading branch information
@rokopt
rokopt committed Jul 15, 2020
1 parent 7652c02 commit 99e2b0e
Showing 1 changed file with 33 additions and 35 deletions.
68 changes: 33 additions & 35 deletions core/cap-0034.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -147,14 +147,13 @@ CAP. **Bold** text indicates a semantic change from the previous stage. The
proposal in this CAP embodies the **bold** semantics in the last column only;
the **bold** semantics in the middle column are for context.

| Index (for later reference) | Decision point | Released behavior | Latest unreleased behavior (PR 2608) | CAP behavior |
| --------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------- |
| 1 | Which transactions to flood? | Unexpired with respect to last ledger close | **Unexpired with respect to estimate of next ledger close** | Unexpired with respect to estimate of next ledger close |
| 2 | Which transactions to include (not to trim) in nominated `StellarValue`? | Unexpired with respect to last ledger close | **Unexpired with respect to estimate of next ledger close** | **Unexpired with respect to `closeTime` to nominate in same `StellarValue`** |
| 3 | Which close time to validate transaction sets against in nomination and ballot protocols? | Last ledger close time | Last ledger close time | **`closeTime` in same `StellarValue` as transaction set** |
| 4 | Which close time to produce when compositing candidates into single nominee? | maximum of all candidates' `closeTime`s | maximum of all candidates' `closeTime`s | **`closeTime` in same `StellarValue` as chosen ("best") transaction set** |
| 5 | Generate `BASIC` or `SIGNED` `StellarValue`s when combining candidates (in "compositing" function)? | `BASIC` | `BASIC` | **`SIGNED`** |
| 6 | Expect `BASIC` or `SIGNED` `StellarValue`s in ballot protocol? | `BASIC` | `BASIC` | **`SIGNED`** |
| Index (for later reference) | Decision point | Released behavior | Latest unreleased behavior (PR 2608) | CAP behavior |
| --------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------- |
| 1 | Which transactions to flood? | Unexpired with respect to last ledger close | **Unexpired with respect to estimate of next ledger close** | Unexpired with respect to estimate of next ledger close |
| 2 | Which transactions to include (not to trim) in the `StellarValue` a node votes to nominate? | Unexpired with respect to last ledger close | **Unexpired with respect to estimate of next ledger close** | **Unexpired with respect to `closeTime` to nominate in same `StellarValue`** |
| 3 | Which close time to validate transaction sets against in nomination and ballot protocols? | Last ledger close time | Last ledger close time | **`closeTime` in same `StellarValue` as transaction set** |
| 4 | Which close time to produce in composite value? | maximum of all candidates' `closeTime`s | maximum of all candidates' `closeTime`s | **`closeTime` in same `StellarValue` as chosen ("best") transaction set** |
| 5 | Expect `BASIC` or `SIGNED` `StellarValue` in a composite value to be used in the ballot protocol? | `BASIC` | `BASIC` | **`SIGNED`** |

## Design Rationale

Expand All @@ -175,8 +174,8 @@ And every candidate has by the time of combining been validated, including
against the new condition that it contains no transactions that are expired
with respect to its `closeTime`.

2. The proposal additionally repairs a degree of lack of Byzantine fault
tolerance which we shall call "maximum `closeTime` injection": an ill-behaved
2. The proposal additionally prevents a potential attack by an ill-behaved
validator which we shall call "maximum `closeTime` injection": an ill-behaved
validator can no longer reduce the quality of transaction sets produced by the
compositing function by nominating as large a `closeTime` as allowed (the
maximum time slip is currently one minute) and thus possibly causing some other
Expand Down Expand Up @@ -285,21 +284,21 @@ choosing the maximum. That means in particular that a single bad _validator_
can open this race window significantly, with the consequences including both
the failure of more transactions with `txTOO_LATE` and the potential for
inconsistent smart contract behavior. This reflects that the current
protocol's choice of the maximum candidate `closeTime` is, in a sense, _not_
Byzantine fault-tolerant: it externalizes a value that could have been
manipulated by a single bad actor. We refer to such manipulation as "maximum
`closeTime` injection". The proposal in this CAP is less sensitive:
a node can affect the composite `closeTime` only if it provides the transaction
set that the network as a whole agrees is the best. We force a node to do a
"good deed" for the network's clients in order to influence the eventual
externalized `closeTime`. In the presence of this CAP, one node's increasing
the `closeTime` significantly no longer triggers the smart-contract race because
that is closed completely by this CAP, and it no longer reduces the number of
applicable transactions in a ledger because a node can only increase the
`closeTime` by providing at least as good a transaction set as any other node
provided, with those transaction sets already guaranteed to be composed entirely
of unexpired transactions if they win nomination (because each of them has been
validated against its own associated `closeTime`).
protocol's choice of the maximum candidate `closeTime` is, in a sense, too
sensitive: it can externalize a value that could have been manipulated by a
single bad actor. We refer to such manipulation as "maximum `closeTime`
injection". The proposal in this CAP is less sensitive: a node can affect the
composite `closeTime` only if it provides the transaction set that the network
as a whole agrees is the best. We force a node to do a "good deed" for the
network's clients in order to influence the eventual externalized `closeTime`.
In the presence of this CAP, one node's increasing the `closeTime` significantly
no longer triggers the smart-contract race because that is closed completely by
this CAP, and it no longer reduces the number of applicable transactions in a
ledger because a node can only increase the `closeTime` by providing at least as
good a transaction set as any other node provided, with those transaction sets
already guaranteed to be composed entirely of unexpired transactions if they win
nomination (because each of them has been validated against its own associated
`closeTime`).

### Detailed argument in favor of this proposal

Expand Down Expand Up @@ -381,16 +380,15 @@ costs:
combining multiple ones in producing the `closeTime`) in the output of the
compositing function, there is little cost to doing so (we have the signature
in memory and have already checked it), so we may as well lose as little
information as possible.

6. Given that we have preserved the signature on `StellarValue`s throughout the
nomination protocol and into the ballot protocol, we must expect `SIGNED`
`StellarValue`s in the ballot protocol, and we must check the signatures again
in the ballot protocol, to make sure that the additional information that we
are preserving is _correct_ information. The additional signature-checking,
however, will be on a signature that we just checked during the preceding
nomination round, so we will likely simply hit in cache nearly all the time,
and not have to do significantly more signature checks.
information as possible. And given that we have preserved the signature on
`StellarValue`s throughout the nomination protocol and into the ballot protocol,
we must expect `SIGNED` `StellarValue`s in the ballot protocol, and we must
check the signatures again in the ballot protocol, to make sure that the
additional information that we are preserving is _correct_ information. The
additional signature-checking, however, will be on a signature that we just
checked during the preceding nomination round, so we will likely simply hit in
cache nearly all the time, and not have to do significantly more signature
checks.

Therefore, we argue that each successive change represents a clear
improvement, given the previous one (and the first represents a clear
Expand Down

0 comments on commit 99e2b0e

Please sign in to comment.