Reported by @elliedavidson on behalf of Cartesi
It was noticed that the transaction TX~A6pK2Y4YIxcV8clkKkWmuKaUMazQ2liFCorRnAZExdf6 wasn't returning any results from the Block Explorer on Decaf.
After investigating, it was determined that this transaction corresponds to this transaction:
https://explorer.decaf.testnet.espresso.network/transaction/105336-0
However, at the time when attempting to search for it in the Block Explorer, nothing was immediately being presented beyond the "no results found" result. This was due to the Explorer API taking a while to actually return the result. With the investigation of the underlying query with @imabdulbasit, it was determined that the underlying query was just not able to be made efficiently, and posed a potential DoS vector. As a result, the underlying query has been modified from a prefix search to an exact match search, as prefix search doesn't really seem like a use-case we want to support:
https://github.com/EspressoSystems/hotshot-query-service/blob/8f64921843d4cb27ad0e88b86a789869c369975a/src/data_source/storage/sql/queries/explorer.rs#L518
https://github.com/EspressoSystems/hotshot-query-service/blob/8f64921843d4cb27ad0e88b86a789869c369975a/src/data_source/storage/sql/queries/explorer.rs#L535
These two lines will be changed from LIKE statements to equality statements instead.
The proposed suggestion was to add a loading indicator to the search results. This initially makes sense to indicate that results are being loaded. The current behavior of the Search Bar is predicated on this auto complete / prefix search however, and with the query change we might eliminate / severely reduce the wait time for finding transactions / blocks.
Another point of confusion is that the search results show whenever something is typed within the search bar, and the search criteria is not empty, instead of after relevant search results are found. In the case of Etherscan, there is a delay in performing search results, but it won't show the search results in the following cases:
- A valid TxnHash is provided
- No Results are Found
Perhaps this approach can be leveraged to provide a better UX for search as well. Though we do not guarantee unique Transaction Hashes, so we might have to change this to the following:
- A valid Hash is Provided that has a single Block Result
- No Results are Found
By eliminating the need to show the "no results found" on the page indicated, we can eliminate the potential confusion caused by needing to wait for new search results to come through.
We could still add a loading indicator to indicate that the search is being performed in the future. Etherscan does not seem to do this, and the resulting UX implications are unclear.
In either case, the Search behavior needs to be changed to match the Explorer API before everything else
Reported by @elliedavidson on behalf of Cartesi
It was noticed that the transaction
TX~A6pK2Y4YIxcV8clkKkWmuKaUMazQ2liFCorRnAZExdf6wasn't returning any results from the Block Explorer on Decaf.After investigating, it was determined that this transaction corresponds to this transaction:
https://explorer.decaf.testnet.espresso.network/transaction/105336-0
However, at the time when attempting to search for it in the Block Explorer, nothing was immediately being presented beyond the "no results found" result. This was due to the Explorer API taking a while to actually return the result. With the investigation of the underlying query with @imabdulbasit, it was determined that the underlying query was just not able to be made efficiently, and posed a potential DoS vector. As a result, the underlying query has been modified from a prefix search to an exact match search, as prefix search doesn't really seem like a use-case we want to support:
https://github.com/EspressoSystems/hotshot-query-service/blob/8f64921843d4cb27ad0e88b86a789869c369975a/src/data_source/storage/sql/queries/explorer.rs#L518
https://github.com/EspressoSystems/hotshot-query-service/blob/8f64921843d4cb27ad0e88b86a789869c369975a/src/data_source/storage/sql/queries/explorer.rs#L535
These two lines will be changed from
LIKEstatements to equality statements instead.The proposed suggestion was to add a loading indicator to the search results. This initially makes sense to indicate that results are being loaded. The current behavior of the Search Bar is predicated on this auto complete / prefix search however, and with the query change we might eliminate / severely reduce the wait time for finding transactions / blocks.
Another point of confusion is that the search results show whenever something is typed within the search bar, and the search criteria is not empty, instead of after relevant search results are found. In the case of Etherscan, there is a delay in performing search results, but it won't show the search results in the following cases:
Perhaps this approach can be leveraged to provide a better UX for search as well. Though we do not guarantee unique Transaction Hashes, so we might have to change this to the following:
By eliminating the need to show the "no results found" on the page indicated, we can eliminate the potential confusion caused by needing to wait for new search results to come through.
We could still add a loading indicator to indicate that the search is being performed in the future. Etherscan does not seem to do this, and the resulting UX implications are unclear.
In either case, the Search behavior needs to be changed to match the Explorer API before everything else