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

feat(tendermint): pubkey-only activation and unsigned tx #2088

Merged
merged 57 commits into from
May 14, 2024

Conversation

onur-ozkan
Copy link
Member

@onur-ozkan onur-ozkan commented Mar 13, 2024

This PR implements pubkey-only mode for the Tendermint protocol, which means we can use any external wallet for wallet and swap operations on Tendermint.

Additionally, ibc_withdraw RPC is removed and withdraw is refactored for Tendermint to support IBC transfers by automatically finding IBC channels whenever possible.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan added enhancement New feature or request in progress Changes will be made from the author labels Mar 13, 2024
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan changed the title feat(tendermint): pubkey login and unsigned transactions feat(tendermint): pubkey-only activation and unsigned tx Mar 14, 2024
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Copy link
Collaborator

@shamardy shamardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! This is an initial review since the PR is only in progress but I wanted to start reviewing it early due to the high priority of this PR.

mm2src/coins/tendermint/tendermint_coin.rs Outdated Show resolved Hide resolved
Comment on lines +249 to +250
#[cfg(target_arch = "wasm32")]
PrivKeyPolicy::Metamask(_) => unreachable!(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Metamask was supposed to be for any similar wallet once we start integrating others, you can see that it uses EthMetamaskPolicy which includes the public key

#[cfg(target_arch = "wasm32")]
Metamask(EthMetamaskPolicy),
}
#[cfg(target_arch = "wasm32")]
#[derive(Clone, Debug)]
pub struct EthMetamaskPolicy {
pub(crate) public_key: EthH264,
pub(crate) public_key_uncompressed: EthH520,
}

We have 2 options:
1 - Either use generics and rename metamask to DappCompatibleWallet or something similar
2 - keep metamask but we should move it to EthPrivKeyPolicy instead in the future.

I think this is outside this PR scope anyway but I will leave this comment as a reminder for whoever will get to refactor this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, initially I also designed this to be a central/generic implementation in mm2, but considering the time we have, I couldn't afford the time allocation to do that.

mm2src/coins/tendermint/tendermint_coin.rs Outdated Show resolved Hide resolved
mm2src/coins/tendermint/tendermint_coin.rs Outdated Show resolved Hide resolved
Copy link
Member

@borngraced borngraced left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really great work!, a question and couple changes after first review

mm2src/coins/tendermint/tendermint_token.rs Show resolved Hide resolved
Comment on lines 724 to 727
tx: TransactionData::Signed {
tx_hash: tx_hash.to_string(),
tx_hex: msg.into(),
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that we are constructing TransactionData::Signed a lot of time. what about creating an helper function e.g

fn construct_signed_tx_from_hash_hex<Hash: ToString>(hash: Hash, hex: BytesJson) -> TransactionData {}

just some thoughts 💭

Copy link
Member Author

@onur-ozkan onur-ozkan Apr 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about TransactionData::new_signed(tx_hash, tx_hex) ? The construct_signed_tx_from_hash_hex name makes it even more complicated than before in my opinion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok better

@onur-ozkan
Copy link
Member Author

Thanks for reviews. As this is an early-stage PR, things can be very different depending on the other blocker tasks I am working on. I will be working on the other/blocker tasks and come back here once I finish other parts.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan force-pushed the keplr-and-external-sign-swap branch from b431563 to f776f38 Compare May 8, 2024 05:42
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
@onur-ozkan onur-ozkan added under review and removed in progress Changes will be made from the author labels May 10, 2024
Copy link
Collaborator

@shamardy shamardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing Work! Only some minor comments, I will do another recheck of tendermint_coin.rs and tendermint_token.rs early next week before approving the PR!

mm2src/coins/lp_coins.rs Outdated Show resolved Hide resolved
mm2src/coins/rpc_command/tendermint/mod.rs Show resolved Hide resolved
mm2src/mm2_core/src/mm_ctx.rs Outdated Show resolved Hide resolved
Comment on lines +239 to +243
if ctx.is_watcher() || ctx.use_watchers() {
return MmError::err(TendermintInitError {
ticker: ticker.clone(),
kind: TendermintInitErrorKind::CantUseWatchersWithPubkeyPolicy,
});
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Watchers are not implemented for tendermint yet but I believe they can be implemented for external wallets too. It's up to you if you want to remove this check at this stage or not.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you give a little bit more context about watchers using external wallet?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just another signed transaction that gets sent to the watcher where they can add the secret once revealed by the maker, so it will be one more transaction signed by keplr. Maybe for Tendermint watchers support, we will need some additions to nucleus codebase, I need to check this but it's not a priority currently.

Copy link
Member Author

@onur-ozkan onur-ozkan May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly, we made watchers so people don't have to keep the mm2 open for the swaps. If user has to be online/active on the keplr window, how does using watcher make sense? I think we should not allow doing that as it doesn't seem beneficial for users and adds tons of complexity on the codebase to maintain.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly, we made watchers so people don't have to keep the mm2 open for the swaps. If user has to be online/active on the keplr window, how does using watcher makes sense?

The main reason we need watchers is not offline swaps but to fix some security issues, if the taker goes offline after sending their payment for a long time the maker can get both payments. Watchers start their work after the taker sends their payment, so for keplr the taker will sign 2 transactions, one for the taker payment and another to send to the watchers, then if anything happens and they went offline, the watcher can complete the swap or refund it before the maker refunds theirs.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P.S. if a swap fails, the taker has to wait some time before they can refund it. If they didn't get back online after some time to refund it, and the maker is malicious, they can lose their payment.

Comment on lines +3040 to +3049
let metadata_list = git_controller
.client
.get_file_metadata_list(
CHAIN_REGISTRY_REPO_OWNER,
CHAIN_REGISTRY_REPO_NAME,
CHAIN_REGISTRY_BRANCH,
CHAIN_REGISTRY_IBC_DIR_NAME,
)
.await
.map_err(|e| IBCTransferChannelsRequestError::Transport(format!("{:?}", e)))?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's our repo, but is it completely secure to rely on this repo for ibc channels data? We have to consider supply chain attacks, what would happen if a wrong channel id is used for a transfer?
P.S. the alternative would be to load a file like the coins file and it will be updated with each new GUI release while relying on the user to enter custom channel ids for new IBC channels similar to custom token imports. What do you think @onur-ozkan?

c.c. @ca333

Copy link
Member Author

@onur-ozkan onur-ozkan May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's our repo, but is it completely secure to rely on this repo for ibc channels data? We have to consider supply chain attacks, what would happen if a wrong channel id is used for a transfer?

Either our repo or user's hostname configuration must be hacked (which is already ..... situation) in order to provide incorrect channels. But that's already more dangerous than providing incorrect channels.

The things which may happen when using wrong channel:

  • By default, if using a channel id that doesn't exists, funds will be recovered (except the tx fee part).

  • If channel id belongs to a relayer that is customized by malicious person, then anything can happen depending on what this person changed on his/her relayer.

P.S. the alternative would be to load a file like the coins file and it will be updated with each new GUI release while relying on the user to enter custom channel ids for new IBC channels similar to custom token imports. What do you think @onur-ozkan?

Channels can be changed very frequently, I don't think we can keep up with it by releasing komodo-wallet for each change on the channels.

Copy link
Collaborator

@shamardy shamardy May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either our repo or user's hostname configuration must be hacked (which is already ..... situation) in order to provide incorrect channels. But that's already more dangerous than providing incorrect channels.

Only one dev with write auth getting hacked is enough to write incorrect channels info to this repo and it will be used straight away by komodo wallet and the defi framework release. We can't lock this to a certain commit hash too to have auto update.

Channels can be changed very frequently, I don't think we can keep up with it by releasing komodo-wallet for each change on the channels.

We can leave it as is for now but I wanted to raise this issue for the sec review team to see their opinion.
One more question, do channels change for already running and established chains or is this needed for new chains to be always available in komodo wallet?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only one dev with write auth getting hacked is enough to write incorrect channels info to this repo and it will be used straight away by komodo wallet and the defi framework release. We can't lock this to a certain commit hash too.

We can but that kills the whole idea. I would just put the json file in the mm2 source code instead of using the locked hash, but as I mentioned above we can not make mm2 release each time a channel info changes in the repo. Giving the write access to someone irrelevant is not an easy accident and that's already pretty bad situation in my opinion.

We can leave it as is for now but I wanted to raise this issue for the sec review team to see their opinion.
One more question, do channels change for already running and established chains or is this needed for new chains to be always available in komodo wallet?

They can be removed/updated for any new/old chain.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
Copy link
Collaborator

@shamardy shamardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥

Copy link
Member

@borngraced borngraced left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work and well done!

@shamardy shamardy merged commit 52326c4 into dev May 14, 2024
21 of 25 checks passed
@shamardy shamardy deleted the keplr-and-external-sign-swap branch May 14, 2024 02:26
dimxy added a commit to dimxy/komodo-defi-framework that referenced this pull request May 14, 2024
* dev:
  feat(tendermint): pubkey-only activation and unsigned tx (KomodoPlatform#2088)
  fix(tests): set txfee for some tbtc tests (KomodoPlatform#2116)
dimxy added a commit to dimxy/komodo-defi-framework that referenced this pull request May 14, 2024
* dev:
  feat(tendermint): pubkey-only activation and unsigned tx (KomodoPlatform#2088)
  fix(tests): set txfee for some tbtc tests (KomodoPlatform#2116)
  fix(eth): remove my_address from sign_and_send_transaction_with_keypair (KomodoPlatform#2115)
  fix(utxo-swap): apply events occurred while taker down (KomodoPlatform#2114)
  refactor(memory): memory usage improvements (KomodoPlatform#2098)
  feat(app-dir): implement root application dir `.kdf` (KomodoPlatform#2102)
  fix tendermint fee calculation (KomodoPlatform#2106)
  update dockerfile (KomodoPlatform#2104)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request under review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants