diff --git a/docs/architecture/adr-006-02-client-refactor.md b/docs/architecture/adr-006-02-client-refactor.md index 5faa77b8bcf..2f3e67a83c1 100644 --- a/docs/architecture/adr-006-02-client-refactor.md +++ b/docs/architecture/adr-006-02-client-refactor.md @@ -5,7 +5,7 @@ ## Status -Accepted and applied in v6 of ibc-go +Accepted and applied in v7 of ibc-go ## Context diff --git a/docs/architecture/adr-007-solomachine-signbytes.md b/docs/architecture/adr-007-solomachine-signbytes.md index 0a987842e80..686552e982a 100644 --- a/docs/architecture/adr-007-solomachine-signbytes.md +++ b/docs/architecture/adr-007-solomachine-signbytes.md @@ -5,11 +5,11 @@ ## Status -Accepted, applied in v6 +Accepted, applied in v7 ## Context -The `06-solomachine` implemention up until ibc-go v6 constructed sign bytes using a `DataType` which described what type of data was being signed. +The `06-solomachine` implemention up until ibc-go v7 constructed sign bytes using a `DataType` which described what type of data was being signed. This design decision arose from a misunderstanding of the security implications. It was noted that the proto definitions do not [provide uniqueness](https://github.com/cosmos/cosmos-sdk/pull/7237#discussion_r484264573) which is a necessity for ensuring two signatures over different data types can never be the same. What was missed is that the uniqueness is not provided by the proto definition, but by the usage of the proto definition. diff --git a/modules/light-clients/06-solomachine/client_state.go b/modules/light-clients/06-solomachine/client_state.go index 5148a35aa62..cae2825b087 100644 --- a/modules/light-clients/06-solomachine/client_state.go +++ b/modules/light-clients/06-solomachine/client_state.go @@ -23,7 +23,6 @@ func NewClientState(latestSequence uint64, consensusState *ConsensusState) *Clie Sequence: latestSequence, IsFrozen: false, ConsensusState: consensusState, - // AllowUpdateAfterProposal has been DEPRECATED. See 01_concepts in the solo machine spec repo for more details. } }