More practically, relayers use this default when submitting IBC transactions to create a new client.

Hmm not sure. Typically users run the create connection CLI which automatically creates a new client with default security parameters and then it creates a connection on top of that. The default trust threshold in Hermes is 1/3. Ref: https://github.com/informalsystems/ibc-rs/blob/2be4012598a7c2562f70f83729a412646a098fa8/config.toml#L203.

Relayer users can also create IBC clients individually with specific security parameters eg they could do hermes create client .. --trust-threshold 2/3. Ref: https://hermes.informal.systems/commands/path-setup/clients.html#create-client. I doubt create client got much use in production to parametrize the client's security parameters. The majority of clients were created either with hermes create connection or hermes create channel.

In the case of IBC, where transactions to update the client are submitted very frequently (every 1 to 10 blocks)

This is true depending on the channel traffic conditions. 10% of channels in production (related to DExes) might have traffic every O(1) blocks, but the majority of channels are less heavy in traffic (once every hour or less).

chains get the upside of extra security without slowing down ibc tx latency by requiring multiple messages.

I agree with this (there is extra security due to a larger overlap) and likely no additional cost of extra messages assuming the channel is indeed high traffic. Not sure how I would quantify that security though, and how to think of its importance in the broader context of the other security parameters (trusting period, clock drift).

In the go relayer we use the default set by tendermint and will follow whatever the team decides here.

https://github.com/cosmos/relayer/blob/main/relayer/chains/cosmos/tx.go#L1063

Thanks for your responses @adizere and @jackzampolin.

The default trust threshold in Hermes is 1/3

Is the default level in Hermes just copied from Tendermint or was there another reason for the choice?

but the majority of channels are less heavy in traffic (once every hour or less).

Perhaps it might be helpful to do some concrete research around this but I'd assume that chains (even across an entire day) wouldn't experience validator voting power turnover in excess of 1/3. This means all client updates can happen in a single message (actually is it possible to just have multiple update client messages in a single transaction?)

Not sure how I would quantify that security though, and how to think of its importance in the broader context of the other security parameters (trusting period, clock drift).

Trust period and clock drift are less directly attributable to security. Trust period which is modelled around the unbonding period merely indicates how long a client can go without being updated before it loses the additional security of being able to punish the malevolent validators. Clock drift, AFAIK, is tweaked to improve latency. Too short of a clock drift and if one chain drifts with respect to another, messages will take longer to be bridged across. Too long of a clock drift and relayers that want to challenge a fraudulent header need to wait longer before being able to send the conflicting header.

As a question, how does IBC handle weak subjectivity i.e. how are clients first initialised? - can they be challenged if I were to use a fraudulent header?

Is the default level in Hermes just copied from Tendermint or was there another reason for the choice?

I doubt we copied it from Tendermint codebase, but possibly we copied it from the light client specs. One reason we choose it is also likely because its the optimal value (intuitivelly, this is the smallest value that provides the same security as the consensus core algorithm).

how are clients first initialised?

The relayer pulls a header from a trusted RPC node of the counterparty chain and uses that header to create the client. Does your question refer to some specific detail of initialization?

can they be challenged if I were to use a fraudulent header?

I don't think so. If the client is initialized with a fraudulent header, then I only know of one way to "challenge" or "fix it" -- run misbheavior detection, freeze the client, then recover the client via gov proposal.

We should have a default that tends to a more secure setup than a less secure setup.

I think this makes sense. Two remarks:

1. The new defaults should be tested in practice, to double-check on the performace impact, especially on high-activity channels. I agree the overlap in validators will likely be very common, and likely will be true that we "get the upside of extra security without slowing down ibc tx latency by requiring multiple messages". That being said, relayer operators are already paying a lot for tx fees, and client update messages are the most expensive messages, so it would be wise to double-check all our assumptions here are valid.

2. Like I said above (see remark about ".. relayers use this default when submitting IBC transactions to create a new client"), changing the default in Tendermint side will not change the default trust threshold value that IBC clients get initialized with. We'd need to change relayer code for that. Changing on Tendermint side makes sense as a signal, however! Or am I missing something?

The new defaults should be tested in practice, to double-check on the performace impact, especially on high-activity channels.

I could write a tool to grep chain validator sets and try measure the rate of change. I need to think what's the best way to represent the degree with which validator sets change.