ADR 004: IBC Whitelisting #696
Conversation
There was a problem hiding this comment.
great and concise info!
While I think increasing the amount of gas used by that tx is undesirable, as blocks with those txs would be arbitrarily small, is there a way to require the gas price to be really high for createClient transactions?
edit: that might not be a good solution either, as the fees would have to be burned or something, otherwise validators could still include a createClient transaction for free as the fee would go to themselves.
|
|
||
| ## Proposal | ||
|
|
||
| Fork IBC, and create a store of whitelisted public keys. Only `createClient` txns that are signed by private keys corresponding to whitelisted/stored public keys are deemed valid, and the rest are invalidated. Specific keys will only be required for client creation, and rest of IBC will work as is. |
There was a problem hiding this comment.
while a list of keys would probably be simplest, I'm guessing that it's also possible to rely strictly on governance?
There was a problem hiding this comment.
Yes, this is possible. Creation of clients can be strictly restricted to governance
There was a problem hiding this comment.
Note: this still requires us having to fork IBC (iiuc)
|
|
||
| ## Alternative approaches | ||
|
|
||
| 1. Simplest solution is fork to IBC, and add a small change to disallow creation/registration of new clients. Then we can create clients for the chains that we want to allow at genesis, and effectively create a whitelist. However, adding new clients or removing clients is not feasible under this. |
There was a problem hiding this comment.
agree that relying on hardforks for any changes isn't desirable imo. Not being able to move tokens for a few weeks if something weird happens seems like a non-starter.
Co-authored-by: Rootul P <rootulp@gmail.com>
Co-authored-by: Rootul P <rootulp@gmail.com>
Co-authored-by: Rootul P <rootulp@gmail.com>
| @@ -0,0 +1,27 @@ | |||
| # ADR 004: IBC Whitelist/Allowlist | |||
There was a problem hiding this comment.
[optional] one term is sufficient to describe this. Slight preference for Allowlist because rails/rails#33677
| # ADR 004: IBC Whitelist/Allowlist | |
| # ADR 004: IBC Allowlist |
Note: accepting this suggestion implies updating the filename too. Preferably: adr-004-ibc-allowlist.md to conform to #772
Co-authored-by: Rootul P <rootulp@gmail.com>
|
|
||
| 1. Simplest solution is fork to IBC, and add a small change to disallow creation/registration of new clients. Then we can create clients for the chains that we want to allow at genesis, and effectively create a whitelist. However, adding new clients or removing clients is not feasible under this. | ||
|
|
||
| 2. Add a middleware to revert packets from non-whitelisted chains. This still adds state bloat since clients and corresponding connections are allowed to be established, but adds economic incentive in terms of lost gas from the malicious user/actor |
There was a problem hiding this comment.
Another approach that @zmanian mentioned a while ago, is to allow only transfers with Celestia tokens as denomination.
|
|
||
| ## Context | ||
|
|
||
| While enabling IBC, we want to connect, and allow messages from selected chains. However, we don't want the ability for an arbitrary entity to create an IBC connection with a zone. This is so that we can keep the state machine as minimal and focused as possible. |
There was a problem hiding this comment.
I think we first need to fully understand the overhead in the state machine of IBC and its pricing.
|
Given that we opted to only allow Celestia tokens (ref: #1219), do we want to repurpose this ADR towards that or should we simply close this? |
good question, I don't have a strong opinion. I don't think its of the highest priority either way. The most important thing ofc is that we will have to document the IBC decision somewhere where users/UI implementers/relayers will see it, and it certainly wouldn't hurt to quickly document it internally like in an ADR. The error/event thrown by the token filter is also very nice, so even those who don't read the docs will likely see something. |
|
Ok I think we can close this and I will open a small ADR documenting the decision |
|
@cmwaters can you link the ADR on why we have a token filter? I couldn't find it Update: nvm, I did find #1125 (comment) which may be the next closest thing |
ADR version of #235