diff --git a/docs/architecture/ADR-002-QGB-ValSet.md b/docs/architecture/ADR-002-QGB-ValSet.md index b7a7b9f29a..e875a9702d 100644 --- a/docs/architecture/ADR-002-QGB-ValSet.md +++ b/docs/architecture/ADR-002-QGB-ValSet.md @@ -8,7 +8,7 @@ To accommodate the requirements of the [Quantum Gravity Bridge](https://github.c Add the `ValSet` and `ValSetConfirm` type of messages in order to track the state of the validator set. -PS: The `ValsetConfirm` have been updated in `ADR-005-QGB_reduce_state_usage`. Please take a look on it to know how we will be handling the confirms. +PS: The `ValsetConfirm` have been updated in `ADR-005-QGB-reduce-state-usage`. Please take a look on it to know how we will be handling the confirms. ## Detailed Design @@ -137,7 +137,7 @@ The significance of power difference is calculated using a pre-defined constant. ```go // SignificantPowerDifferenceThreshold the threshold of change in the validator set power // that would need the creation of a new valset request. -const SignificantPowerDifferenceThreshold = 0.05 +const SignificantPowerDifferenceThreshold = 0.05 ``` For more information on the normalization of power, check [here](https://github.com/celestiaorg/celestia-app/blob/df46d122da5f1fab1bd99bfb2bfcf9002f5bc154/x/qgb/types/validator.go#L101 diff --git a/docs/architecture/ADR-001-ABCI++.md b/docs/architecture/adr-001-abci++-adoption.md similarity index 100% rename from docs/architecture/ADR-001-ABCI++.md rename to docs/architecture/adr-001-abci++-adoption.md diff --git a/docs/architecture/ADR-003-QGB-DataCommitment.md b/docs/architecture/adr-003-QGB-data-commitments.md similarity index 96% rename from docs/architecture/ADR-003-QGB-DataCommitment.md rename to docs/architecture/adr-003-QGB-data-commitments.md index d9e2714b6f..e404a15c16 100644 --- a/docs/architecture/ADR-003-QGB-DataCommitment.md +++ b/docs/architecture/adr-003-QGB-data-commitments.md @@ -8,7 +8,7 @@ To accommodate the requirements of the [Quantum Gravity Bridge](https://github.c Add the `DataCommitmentConfirm` type of messages in order to attest that a set of blocks has been finalized. -PS: The `ValsetConfirm` have been updated in `ADR-005-QGB_reduce_state_usage`. Please take a look on it to know how we will be handling the confirms. +PS: The `ValsetConfirm` have been updated in `ADR-005-QGB-reduce-state-usage`. Please take a look on it to know how we will be handling the confirms. ## Detailed Design @@ -123,10 +123,10 @@ Then, we continue to broadcast an event containing the message: ```go ctx.EventManager().EmitEvent( sdk.NewEvent( - sdk.EventTypeMessage, + sdk.EventTypeMessage, sdk.NewAttribute(sdk.AttributeKeyModule, msg.Type()), - sdk.NewAttribute(types.AttributeKeyDataCommitmentConfirmKey, msg.String()), - ), + sdk.NewAttribute(types.AttributeKeyDataCommitmentConfirmKey, msg.String()), + ), ) ``` diff --git a/docs/architecture/ADR-004-QGB_relayer_security.md b/docs/architecture/adr-004-QGB-relayer-security.md similarity index 97% rename from docs/architecture/ADR-004-QGB_relayer_security.md rename to docs/architecture/adr-004-QGB-relayer-security.md index 6ebaefc238..f46e61ff62 100644 --- a/docs/architecture/ADR-004-QGB_relayer_security.md +++ b/docs/architecture/adr-004-QGB-relayer-security.md @@ -1,4 +1,4 @@ -# ADR 4: QGB Relayer security design +# ADR 004: QGB Relayer Security ## Changelog @@ -7,21 +7,21 @@ ## Context The current QGB design requires relayers to relay everything in a perfect synchronous order, but the contracts do not. -In fact, the QGB smart contract is designed to update the data commitments as follows: +In fact, the QGB smart contract is designed to update the data commitments as follows: -- Receive a data commitment -- Check that the block height (nonce) is higher than the previously committed root -- Check if the data commitment is signed using the current valset _(this is the problematic check)_ +- Receive a data commitment +- Check that the block height (nonce) is higher than the previously committed root +- Check if the data commitment is signed using the current valset _(this is the problematic check)_ - Then, other checks + commit So, if a relayer is up to date, it will submit data commitment and will pass the above checks. -Now, if the relayer is missing some data commitments or valset updates, then it will start catching up the following way: +Now, if the relayer is missing some data commitments or valset updates, then it will start catching up the following way: -- Relay valset -- Keep relaying all data commitments that were signed using that valset -- If a new valset is found, check that: up to the block where the valset was changed, all the data commitments that happened during that period are relayed -- Relay the next valset +- Relay valset +- Keep relaying all data commitments that were signed using that valset +- If a new valset is found, check that: up to the block where the valset was changed, all the data commitments that happened during that period are relayed +- Relay the next valset - And, so on. The problem with this approach is that there is constant risk for any relayer to mess the ordering of the attestations submission, ie relaying the next valset before relaying all the data commitments that were signed using the previous valset, and end up with signatures holes. @@ -63,10 +63,10 @@ This approach consists of switching to a synchronous QGB design utilizing univer Update the QGB contract to store the valset hashes + their nonces: - Cons: - - Would make the contract more complex + - Would make the contract more complex - Pros: - - Would make the relayer parallelizable (can submit data commitments and valsets in any order as long as the valset is committed) - - would allow the QGB to catchup correctly even in the existence of a malicious relayer + - Would make the relayer parallelizable (can submit data commitments and valsets in any order as long as the valset is committed) + - would allow the QGB to catchup correctly even in the existence of a malicious relayer ### A request oriented design diff --git a/docs/architecture/ADR-005-QGB_reduce_state_usage.md b/docs/architecture/adr-005-QGB-reduce-state-usage.md similarity index 99% rename from docs/architecture/ADR-005-QGB_reduce_state_usage.md rename to docs/architecture/adr-005-QGB-reduce-state-usage.md index 3c2a86501a..df9535b0e9 100644 --- a/docs/architecture/ADR-005-QGB_reduce_state_usage.md +++ b/docs/architecture/adr-005-QGB-reduce-state-usage.md @@ -1,4 +1,4 @@ -# ADR 5: Reduce QGB state usage +# ADR 005: QGB Reduce State Usage ## Context