[update] MD-3: add request for D5 #95
Conversation
| **Rationale**: for a continued Fork B to be rational for Partition B, we state that | ||
|
|
||
| ```math | ||
| U_B = U_{B, s} + \frac{U_{B, r}}{1 - \gamma} + U_{B, p} \geq U_{A, s} + \frac{U_{A, r}}{1 - \gamma} = U_A |
|
|
||
| That is, the utility of the state represented by Fork B $U_{B, s}$ plus the discounted repeated utility of the rewards $\frac{U_{B, r}}{1 - \gamma}$ plus some penalty $U_{B, p} < 0$ must be greater than or equal to the utility of the state represented by Fork A $U_{A, s}$ plus the discounted repeated utility of the rewards $\frac{U_{A, r}}{1 - \gamma}$. (Note the utility of the state could also be assigned a discounting model, however, this is considered extrinsic to the model of the problem provided herein.) | ||
|
|
||
| **Positive Rewards for Fork B**: since rewards on Fork B are non-zero and Partition B is in agreement with Fork B, it follows that $\frac{U_{B, r}}{1 - \gamma} > 0$ |
There was a problem hiding this comment.
copied review from old PR:
i suggest to use F_B for Fork B and P_B for Partition B. (or change one of the symbols) its confusing to use the same symbols
|
|
||
| ## Fork Stake Problem | ||
|
|
||
| The allowance of long-lived forks presents another problem for MCR. That is, currently MCR only rewards in one token. However, if this continues whilst allowing forking, network would be incentivized to create spurious forks to use the minting capabilities of MCR to create more tokens. |
There was a problem hiding this comment.
copied review from old PR:
not sure i understand the issue.
the L1 contract should recognize the different forks. ideally the rewards are agreed at the beginning of an epoch and planned forks are only possible at the beginning of an epoch. forks within an epoch are unplanned and at most only one fork should survive. whereas with planned upgrades rewards are agreed on. Nodes that vote for two forks during an epoch (and for the same block height) should get slashed to prevent the option of forking into two chains during an epoch.
I guess my question can be reduced to : do we use epochs and have an RFC that describes them (or if not why do we not use epochs)?
|
|
||
| Finally, in many BFT protocols, temporary forks are allowed before they are reconciled by selecting the appropriate fork by a fork choice rule. The rewards earned by contributing to the temporary fork are represented only along this fork and thus $\frac{U_{B, r}}{1 - \gamma} = 0$ if the fork is indeed temporary. | ||
|
|
||
| Unfortunately, MCR is restricted by representation and synchronicity problems in this regard. Because there is only one canonical replica of the chain decided upon by the base layer's, ETH's, BFT and because rewards need to be issued synchronously on this base layer, we would be unable to ensure $\frac{U_{B, r}}{1 - \gamma} = 0$ if rewards are issued immediately. |
There was a problem hiding this comment.
it makes sense to pay out rewards at end of epoch
|
|
||
| ## Solving the Problem with Partially Synchronous Forks | ||
|
|
||
| The Asynchronous Upgrades Problem can be resolved by allowing the network to fork in a partially synchronous manner. That is, the network can agree at a defined point in time $t_{h - 1} + \epsilon$ to fork into two chains w/o loss of generality, one with state derivation $S_A(h)$ and the other with state derivation $S_B(h)$. |
There was a problem hiding this comment.
@apenzk apenzk [on Oct 10, 2024]
I dont understand why we would introduce time here. why not use blockheight and run two instances of protocols P0 (old) and P1 (new). start signing with P1 at height H, continue (surviving hardfork) or discontinue (dead hardfork) with P0
@l-monninger l-monninger [on Oct 14, 2024]
The situation above is one where an unforked set of commitments are being gathered at a given block height. To prevent the process of agreeing from lasting indefinitely, the fork choice would be made in time.
That is, block height is fixed, some other value needs to be considered for the decision to fork.
| @@ -0,0 +1,81 @@ | |||
| # MCR: Asynchronous Upgrades, Fork Creation, and Fork Stake Problems | |||
|
|
|||
| The _Asynchronous Upgrades Problem_ is an issue with the [current implementation of MCR](https://github.com/movementlabsxyz/movement/tree/baa83356a14d44fd4e8346e1eddfc184cebc17d3/protocol-units/settlement/mcr) that arises when a partition of the network upgrades to a new version of the protocol while another partition remains on the old version. This can lead to failure to agree upon the current block height and currently would require the deployment of a new settlement contract to resolve. | |||
There was a problem hiding this comment.
apenzk [on Oct 10, 2024]
it has not become clear until later that this also may be simple a desired upgrade in the protocol. (like a desired hard fork). This should be made more clear before this paragraph.
franck44
added
Ready to Review
apenzk
removed
Committee review
Summary
this PR re-adds
which has deleted a few commits as it was not clear if D5 is relevant for postconfirmations.