Skip to content

Commit

Permalink
Merge remote-tracking branch 'origin/cian/issue#1396-skip-distributio…
Browse files Browse the repository at this point in the history
…n-if-refund-fails-to-send-on-channel-closure' into cian/issue#1396-skip-distribution-if-refund-fails-to-send-on-channel-closure
  • Loading branch information
chatton committed Jun 10, 2022
2 parents 7ba892d + 7453287 commit 59a42df
Show file tree
Hide file tree
Showing 46 changed files with 3,162 additions and 713 deletions.
4 changes: 4 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,10 +46,12 @@ Ref: https://keepachangelog.com/en/1.0.0/
* (channel) [\#1283](https://github.com/cosmos/ibc-go/pull/1283) The `OnChanOpenInit` application callback now returns a version string in line with the latest [spec changes](https://github.com/cosmos/ibc/pull/629).
* (modules/29-fee)[\#1338](https://github.com/cosmos/ibc-go/pull/1338) Renaming `Result` field in `IncentivizedAcknowledgement` to `AppAcknowledgement`.
* (modules/29-fee)[\#1343](https://github.com/cosmos/ibc-go/pull/1343) Renaming `KeyForwardRelayerAddress` to `KeyRelayerAddressForAsyncAck`, and `ParseKeyForwardRelayerAddress` to `ParseKeyRelayerAddressForAsyncAck`.
* (apps/27-interchain-accounts)[\#1432](https://github.com/cosmos/ibc-go/pull/1432) Updating `RegisterInterchainAccount` to include an additional `version` argument, supporting ICS29 fee middleware functionality in ICS27 interchain accounts.

### State Machine Breaking

### Improvements

* (cleanup) [\#1335](https://github.com/cosmos/ibc-go/pull/1335/) `gofumpt -w -l .` to standardize the code layout more strictly than `go fmt ./...`
* (transfer) [\#1342](https://github.com/cosmos/ibc-go/pull/1342) `DenomTrace` grpc now takes in either an `ibc denom` or a `hash` instead of only accepting a `hash`.
* (modules/core/keeper) [\#1284](https://github.com/cosmos/ibc-go/pull/1284) Add sanity check for the keepers passed into `ibckeeper.NewKeeper`. `ibckeeper.NewKeeper` now panics if any of the keepers passed in is empty.
Expand All @@ -61,6 +63,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
* (app/29-fee) [\#1341](https://github.com/cosmos/ibc-go/pull/1341) Check if the fee module is locked and if the fee module is enabled before refunding all fees
* (transfer) [\#1414](https://github.com/cosmos/ibc-go/pull/1414) Emitting Sender address from `fungible_token_packet` events in `OnRecvPacket` and `OnAcknowledgementPacket`.
* (modules/core/04-channel) [\#1464](https://github.com/cosmos/ibc-go/pull/1464) Emit a channel close event when an ordered channel is closed.
* (modules/light-clients/07-tendermint) [\#1118](https://github.com/cosmos/ibc-go/pull/1118) Deprecating `AllowUpdateAfterExpiry and AllowUpdateAfterMisbehaviour`. See ADR-026 for context.

### Features

Expand All @@ -71,6 +74,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
* (apps/29-fee) [\#1225](https://github.com/cosmos/ibc-go/pull/1225) Adding Query/FeeEnabledChannel and Query/FeeEnabledChannels with CLIs to ICS29 fee middleware.
* (modules/apps/29-fee) [\#1230](https://github.com/cosmos/ibc-go/pull/1230) Adding CLI command for getting incentivized packets for a specific channel-id.
* (modules/apps/transfer) [\#1416](https://github.com/cosmos/ibc-go/pull/1416) Adding gRPC endpoint for getting an escrow account for a given port-id and channel-id.
* (modules/apps/27-interchain-accounts) [\#1512](https://github.com/cosmos/ibc-go/pull/1512) Allowing ICA modules to handle all message types with "*".

### Bug Fixes

Expand Down
8 changes: 8 additions & 0 deletions docs/apps/interchain-accounts/parameters.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,4 +47,12 @@ For example, a Cosmos SDK based chain that elects to provide hosted Interchain A
"host_enabled": true,
"allow_messages": ["/cosmos.staking.v1beta1.MsgDelegate", "/cosmos.gov.v1beta1.MsgVote"]
}
```
There is also a special wildcard `"*"` message type which allows any type of message to be executed by the interchain account. This must be the only message in the `allow_messages` array.

```
"params": {
"host_enabled": true,
"allow_messages": ["*"]
}
```
13 changes: 6 additions & 7 deletions docs/architecture/adr-026-ibc-client-recovery-mechanisms.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@
- 2020/08/06: Revisions per review & to reference version
- 2021/01/15: Revision to support substitute clients for unfreezing
- 2021/05/20: Revision to simplify consensus state copying, remove initial height
- 2022/04/08: Revision to deprecate AllowUpdateAfterExpiry and AllowUpdateAfterMisbehaviour

## Status

Expand Down Expand Up @@ -35,21 +36,20 @@ Two-thirds of the validator set (the quorum for governance, module participation
We elect not to deal with chains which have actually halted, which is necessarily Byzantine behaviour and in which case token recovery is not likely possible anyways (in-flight packets cannot be timed-out, but the relative impact of that is minor).

1. Require Tendermint light clients (ICS 07) to be created with the following additional flags
1. `allow_governance_override_after_expiry` (boolean, default false)
1. `allow_update_after_expiry` (boolean, default true). Note that this flag has been deprecated, it remains to signal intent but checks against this value will not be enforced.
1. Require Tendermint light clients (ICS 07) to expose the following additional internal query functions
1. `Expired() boolean`, which returns whether or not the client has passed the trusting period since the last update (in which case no headers can be validated)
1. Require Tendermint light clients (ICS 07) & solo machine clients (ICS 06) to be created with the following additional flags
1. `allow_governance_override_after_misbehaviour` (boolean, default false)
1. `allow_update_after_misbehaviour` (boolean, default true). Note that this flag has been deprecated, it remains to signal intent but checks against this value will not be enforced.
1. Require Tendermint light clients (ICS 07) to expose the following additional state mutation functions
1. `Unfreeze()`, which unfreezes a light client after misbehaviour and clears any frozen height previously set
1. Add a new governance proposal type, `ClientUpdateProposal`, in the `x/ibc` module
1. Extend the base `Proposal` with two client identifiers (`string`).
1. The first client identifier is the proposed client to be updated. This client must be either frozen or expired.
1. The second client is a substitute client. It carries all the state for the client which may be updated. It must have identitical client and chain parameters to the client which may be updated (except for latest height, frozen height, and chain-id). It should be continually updated during the voting period.
1. If this governance proposal passes, the client on trial will be updated to the latest state of the substitute, if and only if:
1. `allow_governance_override_after_expiry` is true and the client has expired (`Expired()` returns true)
1. `allow_governance_override_after_misbehaviour` is true and the client has been frozen (`Frozen()` returns true)
1. In this case, additionally, the client is unfrozen by calling `Unfreeze()`
1. If this governance proposal passes, the client on trial will be updated to the latest state of the substitute.

Previously, AllowUpdateAfterExpiry and AllowUpdateAfterMisbehaviour were used to signal the recovery options for an expired or frozen client, and governance proposals were not allowed to overwrite the client if these parameters were set to false. However, this has now been deprecated because a code migration can overwrite the client and consensus states regardless of the value of these parameters. If governance would vote to overwrite a client or consensus state, it is likely that governance would also willing to perform a code migration to do the same.


Note that clients frozen due to misbehaviour must wait for the evidence to expire to avoid becoming refrozen.
Expand All @@ -62,7 +62,6 @@ This ADR does not address planned upgrades, which are handled separately as per

- Establishes a mechanism for client recovery in the case of expiry
- Establishes a mechanism for client recovery in the case of misbehaviour
- Clients can elect to disallow this recovery mechanism if they do not wish to allow for it
- Constructing an ClientUpdate Proposal is as difficult as creating a new client

### Negative
Expand Down
225 changes: 225 additions & 0 deletions docs/client/swagger-ui/swagger.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -1266,6 +1266,224 @@ paths:
type: string
tags:
- Query
'/ibc/apps/fee/v1/channels/{channel_id}/relayers/{relayer_address}/payee':
get:
summary: >-
Payee returns the registered payee address for a specific channel given
the relayer address
operationId: Payee
responses:
'200':
description: A successful response.
schema:
type: object
properties:
payee_address:
type: string
title: the payee address to which packet fees are paid out
title: QueryPayeeResponse defines the response type for the Payee rpc
default:
description: An unexpected error response
schema:
type: object
properties:
error:
type: string
code:
type: integer
format: int32
message:
type: string
details:
type: array
items:
type: object
properties:
type_url:
type: string
description: >-
A URL/resource name that uniquely identifies the type of
the serialized

protocol buffer message. This string must contain at
least

one "/" character. The last segment of the URL's path
must represent

the fully qualified name of the type (as in

`path/google.protobuf.Duration`). The name should be in
a canonical form

(e.g., leading "." is not accepted).


In practice, teams usually precompile into the binary
all types that they

expect it to use in the context of Any. However, for
URLs which use the

scheme `http`, `https`, or no scheme, one can optionally
set up a type

server that maps type URLs to message definitions as
follows:


* If no scheme is provided, `https` is assumed.

* An HTTP GET on the URL must yield a
[google.protobuf.Type][]
value in binary format, or produce an error.
* Applications are allowed to cache lookup results based
on the
URL, or have them precompiled into a binary to avoid any
lookup. Therefore, binary compatibility needs to be preserved
on changes to types. (Use versioned type names to manage
breaking changes.)

Note: this functionality is not currently available in
the official

protobuf release, and it is not used for type URLs
beginning with

type.googleapis.com.


Schemes other than `http`, `https` (or the empty scheme)
might be

used with implementation specific semantics.
value:
type: string
format: byte
description: >-
Must be a valid serialized protocol buffer of the above
specified type.
description: >-
`Any` contains an arbitrary serialized protocol buffer
message along with a

URL that describes the type of the serialized message.


Protobuf library provides support to pack/unpack Any values
in the form

of utility functions or additional generated methods of the
Any type.


Example 1: Pack and unpack a message in C++.

Foo foo = ...;
Any any;
any.PackFrom(foo);
...
if (any.UnpackTo(&foo)) {
...
}

Example 2: Pack and unpack a message in Java.

Foo foo = ...;
Any any = Any.pack(foo);
...
if (any.is(Foo.class)) {
foo = any.unpack(Foo.class);
}

Example 3: Pack and unpack a message in Python.

foo = Foo(...)
any = Any()
any.Pack(foo)
...
if any.Is(Foo.DESCRIPTOR):
any.Unpack(foo)
...

Example 4: Pack and unpack a message in Go

foo := &pb.Foo{...}
any, err := ptypes.MarshalAny(foo)
...
foo := &pb.Foo{}
if err := ptypes.UnmarshalAny(any, foo); err != nil {
...
}

The pack methods provided by protobuf library will by
default use

'type.googleapis.com/full.type.name' as the type URL and the
unpack

methods only use the fully qualified type name after the
last '/'

in the type URL, for example "foo.bar.com/x/y.z" will yield
type

name "y.z".



JSON

====

The JSON representation of an `Any` value uses the regular

representation of the deserialized, embedded message, with
an

additional field `@type` which contains the type URL.
Example:

package google.profile;
message Person {
string first_name = 1;
string last_name = 2;
}

{
"@type": "type.googleapis.com/google.profile.Person",
"firstName": <string>,
"lastName": <string>
}

If the embedded message type is well-known and has a custom
JSON

representation, that representation will be embedded adding
a field

`value` which holds the custom JSON in addition to the
`@type`

field. Example (for message [google.protobuf.Duration][]):

{
"@type": "type.googleapis.com/google.protobuf.Duration",
"value": "1.212s"
}
parameters:
- name: channel_id
description: unique channel identifier
in: path
required: true
type: string
- name: relayer_address
description: the relayer address to which the distribution address is registered
in: path
required: true
type: string
tags:
- Query
'/ibc/apps/fee/v1/channels/{packet_id.channel_id}/ports/{packet_id.port_id}/sequences/{packet_id.sequence}/incentivized_packet':
get:
summary: >-
Expand Down Expand Up @@ -13682,6 +13900,13 @@ definitions:
title: >-
QueryIncentivizedPacketsResponse defines the response type for the
IncentivizedPackets rpc
ibc.applications.fee.v1.QueryPayeeResponse:
type: object
properties:
payee_address:
type: string
title: the payee address to which packet fees are paid out
title: QueryPayeeResponse defines the response type for the Payee rpc
ibc.applications.fee.v1.QueryTotalAckFeesResponse:
type: object
properties:
Expand Down
3 changes: 1 addition & 2 deletions docs/ibc/proposals.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,6 @@ See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](.

### Preconditions
- The chain is updated with ibc-go >= v1.1.0.
- Recovery parameters are set to `true` for the Tendermint light client (this determines if a governance proposal can be used). If the recovery parameters are set to `false`, recovery will require custom migration code.
- The client identifier of an active client for the same counterparty chain.
- The governance deposit.

Expand All @@ -67,7 +66,7 @@ Check if the client is attached to the expected `chain-id`. For example, for an
}
```

The client is attached to the expected Akash `chain-id` and the recovery parameters (`allow_update_after_expiry` and `allow_update_after_misbehaviour`) are set to `true`.
The client is attached to the expected Akash `chain-id`. Note that although the parameters (`allow_update_after_expiry` and `allow_update_after_misbehaviour`) exist to signal intent, these parameters have been deprecated and will not enforce any checks on the revival of client. See ADR-026 for more context on this deprecation.

### Step 2

Expand Down
Loading

0 comments on commit 59a42df

Please sign in to comment.