Andreas Fackler

Currently the wallet associates each chain with a unique optional key pair, and the `ChainClient` is initialized with only that. `ChainClient::rotate_key_pair` would add another entry to `known_key_pairs`, but it isn't...

As discussed, it might be best to split `ChainClient` into two parts: The `ChainClient` itself will not have any key pairs, or methods that basically just put together an `Operation`...

https://github.com/linera-io/linera-protocol/tree/main/examples/counter/web-frontend https://github.com/linera-io/linera-protocol/tree/main/examples/fungible/web-frontend https://github.com/linera-io/linera-protocol/tree/main/examples/non-fungible/web-frontend

You made a good argument that it's always better to `#[witty(skip)]` anyway, and not have something like a `_phantom: tuple` field. So maybe it's actually better to not implement these...

I'm fine with the name `WitLoadStore`, too! If you prefer not to have the new trait, we could also add only the derive macro?

I'm not convinced anymore that a `close_chain` endpoint on the contract is a good idea: What if running all the `close_chain` calls on all installed applications takes too much gas...

Another use case is for e.g. the `fungible` or `non-fungible` applications to move all assets elsewhere before closing a chain.

Done in https://github.com/linera-io/linera-protocol/pull/1746.

The `close_chain` runtime method and the `CloseChain` operation could take an optional `ChainId` argument. If that is specified and the chain balance is positive, at the end of the transaction...

`ChainStateView` hopefully has the invariant that the execution state always matches the `tip_state` and the latest entry of `confirmed_log`; I'm a bit scared of just breaking that invariant. I'd rather...