Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate validator addresses in delegation #28

Open
ethanfrey opened this issue Jun 2, 2023 · 1 comment
Open

Validate validator addresses in delegation #28

ethanfrey opened this issue Jun 2, 2023 · 1 comment
Labels
question Further information is requested
Milestone

Comments

@ethanfrey
Copy link
Collaborator

Better error handling in this case. Both in the virtual staking contract and the whole Rust logic (handling said errors)

Also, share more info to the provider chain to prevent this in the first place. Let's think more.

@ethanfrey ethanfrey added the question Further information is requested label Jun 2, 2023
@ethanfrey ethanfrey added this to the v0.2 milestone Jun 2, 2023
@alpe
Copy link
Contributor

alpe commented Jun 6, 2023

🤔 There are some different layers where the validation can happen

  • Frontent
  • Provider contracts
  • Consumer contracts
  • Consumer chain - contains this logic already

IMHO: for fast feedback and best UX the validation should happen as close to the user as possible. The frontend has already the "problem" where it get's the validator data to display it. Adding a quick check there would be low effort.

The check on the consumer chain is mandatory for safety and built into the staking module already. Nevertheless bringing this closer to the provider can be beneficial to remove complexity in the contracts.
Checking for valid addresses in the entrypoint of the consumer contracts should be still within reasonable gas costs. The contract could either check with the chain data on every request or maintain a persistent accept list. That would add more complexity there though.

Validating on the provider side requires some data replication. Probably the simplest thing would be a bech32 check to reject random strings. A full validator set comes with some cost to maintain it proper. Options are push or pulling the data via IBC.

To sumarize:
IMHO: Relying on frontend validation and basic bech32 address validation in the vault contract feel like a quick and effective solution. Unless there are other requirements to keep a valset copy on the provider side, there is only small effort on the consumer edge contract that handles the IBC part and has access to the chain data.

@alpe alpe modified the milestones: v0.3.0, v0.4.0 Nov 23, 2023
@pinosu pinosu modified the milestones: v0.4.0, v0.5.0 Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants