You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With eureka, the connection layer is removed entirely. If we want to support the ability for clients to have delay periods to increase security, we should add it to the tendermint client (any other clients which would like to add this feature should also add it)
Proposal
Add the delay period to the tendermint client. Set it to 0 by default (this should allow the client state encoding to remain unchanged for backwards compatibility - soon shouldn't be a consideration with removal of self client/consensus state validation).
In Eureka, setting the client to a non-zero delay period would be no problem and give support for delay periods.
In classic, it would be a problem, only if the two chains haven't updated to: v7.8+, v8.5+, v9+. To remedy and support a removal of the connection layer entirely, we should:
Thus, if connections have non zero delay periods, gov can choose to update or leave as is for the underlying client before we remove connections and thus create the same fundamental security layer for connections sharing the same client.
For Admin Use
Not duplicate issue
Appropriate labels applied
Appropriate contributors tagged/assigned
The text was updated successfully, but these errors were encountered:
Summary
Add a delayPeriod to the tendermint client state
Problem Definition
With eureka, the connection layer is removed entirely. If we want to support the ability for clients to have delay periods to increase security, we should add it to the tendermint client (any other clients which would like to add this feature should also add it)
Proposal
Add the delay period to the tendermint client. Set it to 0 by default (this should allow the client state encoding to remain unchanged for backwards compatibility - soon shouldn't be a consideration with removal of self client/consensus state validation).
In Eureka, setting the client to a non-zero delay period would be no problem and give support for delay periods.
In classic, it would be a problem, only if the two chains haven't updated to: v7.8+, v8.5+, v9+. To remedy and support a removal of the connection layer entirely, we should:
Thus, if connections have non zero delay periods, gov can choose to update or leave as is for the underlying client before we remove connections and thus create the same fundamental security layer for connections sharing the same client.
For Admin Use
The text was updated successfully, but these errors were encountered: