fix(tpu-v2): fix tpu-v2 wait for payment spend and extract secret

[laruh]

• In TakerCoinSwapOpsV2 trait wait_for_taker_payment_spend function was renamed to find_taker_payment_spend_tx (to avoid misunderstanding with wait_for_confirmation logic)

  In EthCoin function find_taker_payment_spend_tx_impl was provided for trait find_taker_payment_spend_tx method

• Added new extract_secret_v2 method in TakerCoinSwapOpsV2 trait. implemented for UTXO and EthCoin.
  Did it as EthCoin legacy extract_secret doesnt fit TPU V2, so its better to require extract_secret_v2 for coins.

• in lp_connect_start_bob and in lp_connected_alice provided fallback to legacy swap protocol.

  Legacy fallback happens when:
  user sets ctx.use_trading_proto_v2() as false, or other trading side uses legacy swap protocol, then even if user set ctx.use_trading_proto_v2() as true, they have to use legacy swap as well.
  Other reason of starting legacy swap, even if ctx.use_trading_proto_v2() is true, is the trading coin which doesnt support TPU V2

- provide swap protocol version #2112 (review) reverted
See versioning here #2324

• handle require confirmations before changing taker/maker swap state as Completed
  Note: you can find the implementation above this line in taker_swap_v2.rs and in maker_swap_v2.rs

Self::change_state(Completed::new(), state_machine).await

• moved SecretHashAlgo to crypto lib and provided detect_secret_hash_algo_v2 function for TPU (starting from this commit c1a5063)
  ETH coin should use SHA256 in TPU.

[laruh]

ps: will resolve conflicts or cherrypick commits in new up to date branch after eth-maker-tpu-v2 merge #2211

[mariocynicys]

thanks, first iteration

[mariocynicys]

shouldn't we advance from_block if the event wasn't found?

[laruh]

shouldn't we advance from_block if the event wasn't found?

Shouldn't change blocks range, It introduces risks to skip necessary block.

Receiving empty events list does not necessarily indicate that there are no events, network latency can cause delays in the propagation and indexing of event logs even after a transaction is mined.
After a transaction is mined, the logs related to it need to be extracted and made available for querying. This process is not instantaneous.

Also we dont know all the nuances and differences of all blockchains. It is much safer to keep block range starting from swap start block.

[laruh]

UPD: l suggest to add if events.is_empty check to continue loop without moving forward
UPD2: added is empty check 8d5ed46

[mariocynicys]

will this ever be None? will this be a recoverable state then? otherwise we can terminate early.

[laruh]

will this ever be None?

are you talking about event.transaction_hash? This type is from a dependency, we should handle it as it is. The transaction_hash could be None if the log is emitted by a transaction in a pending state. Once the transaction is included in a mined block, the value should be Some.

will this be a recoverable state then?

For TPU V2 we aim to have automatic recover process, if find_taker_payment_spend_tx return error then refund process will be started

komodo-defi-framework/mm2src/mm2_main/src/lp_swap/taker_swap_v2.rs

Lines 1698 to 1716 in c700b59

	let taker_payment_spend = match state_machine
	.taker_coin
	.find_taker_payment_spend_tx(
	&self.taker_payment,
	self.taker_coin_start_block,
	state_machine.taker_payment_locktime(),
	)
	.await
	{
	Ok(tx) => tx,
	Err(e) => {
	let next_state = TakerPaymentRefundRequired {
	taker_payment: self.taker_payment,
	negotiation_data: self.negotiation_data,
	reason: TakerPaymentRefundReason::MakerDidNotSpendInTime(format!("{}", e)),
	};
	return Self::change_state(next_state, state_machine).await;
	},
	};

otherwise we can terminate early

Could clarify what do you mean by termination? You want to return error and break loop?
We should try to find transaction in the loop until time is out

[mariocynicys]

The transaction_hash could be None if the log is emitted by a transaction in a pending state. Once the transaction is included in a mined block, the value should be Some.

aren't we getting events till the current mined block? so this tx shouldn't be pending?

For TPU V2 we aim to have automatic recover process

I just meant we can not do nothing about the fact that tx hash is none.
nothing to do with swap recovery.

how I was thinking (which might be wrong) is that some event types don't have a tx hash which means we supplied a bad event id from the beginning meaning that we can't proceed further. this might not be the case though, gotta read more about this, excuse my eth illiteracy 😂

[laruh]

aren't we getting events till the current mined block? so this tx shouldn't be pending?

yeah, you are right as we are using from and to block filters for eth_getLogs API, tx should be confirmed

    async fn events_from_block(
        &self,
        swap_contract_address: Address,
        event_name: &str,
        from_block: u64,
        to_block: u64,
    ) -> MmResult<Vec<Log>, FindPaymentSpendError> {
        let contract_event = TAKER_SWAP_V2.event(event_name)?;
        let filter = FilterBuilder::default()
            .topics(Some(vec![contract_event.signature()]), None, None, None)
            .from_block(BlockNumber::Number(from_block.into()))
            .to_block(BlockNumber::Number(to_block.into()))
            .address(vec![swap_contract_address])
            .build();
        let events_logs = self
            .logs(filter)
            .await
            .map_err(|e| FindPaymentSpendError::Transport(e.to_string()))?;
        Ok(events_logs)
    }

some event types don't have a tx hash

I think you are confused a bit. Events/logs themselves don't necessarily contain the transaction hash. Instead, the transaction hash is associated with the transaction that emitted the event. So Log type from web3 just contains info about tx which emitted this log.

Note about event and log words. event in Solidity is a way for a contract to emit logs during the execution of a function.
So they are close words, just events refer to the Solidity construct used in the smart contract to emit logs, while logs refer to the actual data that is recorded in the blockchain when events are emitted.

So using from to block range we are looking for Log which was emitted by spend taker payment transaction.

As for empty tx hash I would like to refer to previous comment #2261 (comment) empty event list or none transaction_hash are not 100% that there is no tx which we are looking for, it could be just blockchain indexation delays or other reasons.

[mariocynicys]

i will read further regarding the truncated (not necessarily empty? right?) event list issue, any resourced regarding the indexaction delay issues and such would be so helpful!

regarding an event not having a transaction_hash thought, how would we successfully get the event which has None for the transaction_hash and then try again and all of a sudden we get a Some transaction_hash! is that possible? are these event logs mutable?

[laruh]

i will read further regarding the truncated (not necessarily empty? right?) event list issue, any resourced regarding the indexaction delay issues and such would be so helpful!

I would say that chain reorganization, network latency, node synchronization lag issues could cause missing information issues. These problems usually temporarily, as I understand. You should wait for more confirmed blocks also try to fetch the info from different nodes.

regarding an event not having a transaction_hash thought, how would we successfully get the event which has None for the transaction_hash and then try again and all of a sudden we get a Some transaction_hash! is that possible? are these event logs mutable?

Logs are not mutable. Also they are tied to transactions. When a transaction calls a smart contract function that emits an event, this event generates log, which is permanently recorded in the blockchain.

But there’s a nuance. Lest check doc. According to the documentation https://www.chainnodes.org/docs/ethereum/eth_getLogs, a log from a pending transaction might lack a transaction hash, but when the transaction is confirmed, the log should include it.

Therefore, ideally, when we request a list of logs using the events_from_block function with from_block and to_block filters, it should return only logs from confirmed blocks, which means confirmed transactions. In this case, event.transaction_hash should ideally always be Some.

komodo-defi-framework/mm2src/coins/eth/eth_swap_v2/eth_taker_swap_v2.rs

Lines 530 to 531 in 8d5ed46

	if let Some(event) = found_event {
	if let Some(tx_hash) = event.transaction_hash {

We dont need to change from_block. However, if Log has transaction_hash:None, it doesn't mean Log doesn't have transaction (actually its not correct by itself, as logs are not owners of txs), it means smth went wrong as eth_getLogs API with fromBlock and toBlock filters will use confirmed blocks.

[laruh]

Some additional info https://docs.alchemy.com/docs/deep-dive-into-eth_getlogs#what-are-logs-or-events

Logs and events are used synonymously—smart contracts generate logs by firing off events, so logs provide insights into events that occur within the smart contract. Logs can be found on transaction receipts.

Anytime a transaction is mined, we can see event logs for that transaction by making a request to eth_getLogs and then take actions based off those results. For example, if a purchase is being made using crypto payments, we can use eth_getLogs to see if the sender successfully made the payment before providing the item purchased.

[mariocynicys]

However, if Log has transaction_hash:None, it doesn't mean Log doesn't have transaction, it means smth went wrong as eth_getLogs API with fromBlock and toBlock filters will use confirmed blocks.

im missing u between the lines here so let me repeat that to you and see if i got it correctly. transaction_hash MUST always be Some eventually, if it was None this is a temporary reporting/mining/etc... thing.

[laruh]

However, if Log has transaction_hash:None, it doesn't mean Log doesn't have transaction, it means smth went wrong as eth_getLogs API with fromBlock and toBlock filters will use confirmed blocks.

im missing u between the lines here so let me repeat that to you and see if i got it correctly. transaction_hash MUST always be Some eventually, if it was None this is a temporary reporting/mining/etc... thing.

Yes, in the context of not using "pending" tag in "eth_getLogs" API, we expect transaction_hash always be Some.
The best we can do is to repeat loop cycle until time is out, if None occurred.

[onur-ozkan]

Could you add some PR description to describe the work and help us on review?

[laruh]

Could you add some PR description to describe the work and help us on review?

Updated PR description

[shamardy]

Last review from my side! Once these comments are resolved will approve the PR.

[dimxy]

@dimxy I found one more place which uses to_string() on address in TPU code (in taker_swap_v2.rs), so reverted commit related to your review comment and provided separate AddrToString trait to be able to convert TakerCoin::Address to correct string format without using coin instance. 62afdff

a1bb59f

I like this AddrToString trait.
Could we also make it used everywhere for eth, instead of two different eth_addr_to_hex and display_eth_address functions?
(Plus, from both of them could we retain only one and make it private, I guess it's display_eth_address?)

[shamardy]

Could we also make it used everywhere for eth, instead of two different eth_addr_to_hex and display_eth_address functions?
(Plus, from both of them could we retain only one and make it private, I guess it's display_eth_address?)

I agree, but this can be done in another PR as the current PR have been open for too long.

[shamardy]

🔥

[laruh]

I like this AddrToString trait. Could we also make it used everywhere for eth, instead of two different eth_addr_to_hex and display_eth_address functions? (Plus, from both of them could we retain only one and make it private, I guess it's display_eth_address?)

@dimxy Could you please create issue related to this refactor, so we can track it. Will be done in next PR.

[dimxy]

LGTM