Feature Requests

Currently, Blockscout does not provide a way to distinguish between L2 and L3 rollups in its UI and metrics. Many teams deploying rollups, would benefit from this distinction to ensure accurate labeling and a better UX. Feature Request: Add a way to classify rollups as either L2 or L3. Update relevant UI elements and metrics that currently use "L1/L2" to support "L2/L3" where applicable.

Currently, adding token logos to Blockscout is cumbersome, as it relies on listings from CoinMarketCap (CMC), CoinGecko, which only support publicly listed tokens. This creates a challenge for rollups and custom deployments where tokens are not (yet) listed on these platforms. Another way is the Blockscout Admin Panel, which requires manual intervention of the Blockscout team to update. A widely adopted community standard, https://tokenlists.org/ , allows projects to define and host their own token metadata, including logos. Supporting this standard would streamline the process of displaying token logos in Blockscout. Feature Request: Add an endpoint that allows BlockScout to fetch token metadata (including logos) from a self-hosted Token List URL. Support the Token Lists JSON schema to ensure compatibility with existing tools. Provide a way for users to specify a custom Token List URL within the config settings. This feature would significantly improve the experience for teams launching rollups with native tokens that are not yet listed on centralized aggregators.

Add AI assistant to search for blockchain data

Upgradable smart contracts are essential in the Ethereum ecosystem, enabling developers to enhance functionality and fix issues without deploying entirely new contracts. However, the current auto-verification mechanisms primarily support older upgradeability standards, such as EIP-1967. With recent advancements, minimal proxy patterns like ERC-7760 have gained significant adoption due to their efficiency and cost-effectiveness. These proxies are widely used by the community, yet they are not yet supported by existing auto-verification tools. To improve transparency and streamline the verification process, I request the addition of auto-verification support for ERC-7760: 🔗 EIP-7760 Specification: https://eips.ethereum.org/EIPS/eip-7760 Furthermore, Solady , a highly optimized Solidity library, has been fully audited by the Spearbit team and is now production-ready. Since Solady natively implements ERC-7760 proxies, integrating auto-verification support would benefit developers leveraging this standard. For reference, here is an analysis of ERC-7760 proxy deployments: 📊 Dune Analytics Report: https://dune.com/vectorized/erc-7760-proxy-counts Adding support for ERC-7760 in verification tools will enhance security, reduce manual verification overhead, and align with the latest industry standards.

https://ethereum.github.io/execution-apis/api-documentation/

Since debug_traceTransaction is way more expensive than a normal transaction, a node that is operating even at a fraction of its max TPS capacity might not be able to finish all debug_traceTransaction requests for a block faster than a new block is created, even if running those calls in parallel. Having a config that only traces failed TXs would be interesting because one of the more useful use-cases for having tracing enabled is knowing why a transaction failed, and since usually successful transactions are way more common than failed ones it would reduce the load on the node.

Observations: The name of the network currency subdenomination 'wei' can be customized through the NEXT_PUBLIC_NETWORK_CURRENCY_WEI_NAME environment variable. By default, the gwei unit becomes 'G' + weiName, which is only a partial customization. Request: Add the NEXT_PUBLIC_NETWORK_CURRENCY_GWEI_NAME environment variable to allow full customization of the gwei unit. Behavior Enhancement: If NEXT_PUBLIC_NETWORK_CURRENCY_GWEI_NAME is specified, use it as the gwei currency unit. Else, if only NEXT_PUBLIC_NETWORK_CURRENCY_WEI_NAME is specified, use the existing behavior ('G' + weiName). Otherwise, default to 'Gwei'. 5 files changed, 11 insertions(+), 4 deletions(-).

I am trying to run the blockscout-stack in Kubernetes. For security reasons, I am providing it a specific uid/gid (non-root user/group) but the 'blockscout' pod (backend?) is logging these errors: {"time":"2024-05-13T14:52:25.694Z","severity":"error","message":"GenServer :tzdata_release_updater terminating\n** (File.Error) could not write to file \"/app/lib/tzdata-1.1.1/priv/latest_remote_poll.txt\": permission denied\n (elixir 1.14.5) lib/file.ex:1104: File.write!/3\n (tzdata 1.1.1) lib/tzdata/data_loader.ex:43: Tzdata.DataLoader.last_modified_of_latest_available/1\n (tzdata 1.1.1) lib/tzdata/release_updater.ex:81: Tzdata.ReleaseUpdater.loaded_tzdata_matches_remote_last_modified?/0\n (tzdata 1.1.1) lib/tzdata/release_updater.ex:42: Tzdata.ReleaseUpdater.poll_for_update/0\n (tzdata 1.1.1) lib/tzdata/release_updater.ex:19: Tzdata.ReleaseUpdater.handle_info/2\n (stdlib 3.17) gen_server.erl:695: :gen_server.try_dispatch/4\n (stdlib 3.17) gen_server.erl:771: :gen_server.handle_msg/6\n (stdlib 3.17) proc_lib.erl:226: :proc_lib.init_p_do_apply/3\nLast message: :check_if_time_to_update\nState: []","metadata":{"error":{"initial_call":null,"reason":"** (File.Error) could not write to file \"/app/lib/tzdata-1.1.1/priv/latest_remote_poll.txt\": permission denied\n (elixir 1.14.5) lib/file.ex:1104: File.write!/3\n (tzdata 1.1.1) lib/tzdata/data_loader.ex:43: Tzdata.DataLoader.last_modified_of_latest_available/1\n (tzdata 1.1.1) lib/tzdata/release_updater.ex:81: Tzdata.ReleaseUpdater.loaded_tzdata_matches_remote_last_modified?/0\n (tzdata 1.1.1) lib/tzdata/release_updater.ex:42: Tzdata.ReleaseUpdater.poll_for_update/0\n (tzdata 1.1.1) lib/tzdata/release_updater.ex:19: Tzdata.ReleaseUpdater.handle_info/2\n (stdlib 3.17) gen_server.erl:695: :gen_server.try_dispatch/4\n (stdlib 3.17) gen_server.erl:771: :gen_server.handle_msg/6\n (stdlib 3.17) proc_lib.erl:226: :proc_lib.init_p_do_apply/3\n"}}} I'd like to update the Dockerfile to create a user and group with a specific UID/GID (maybe as args?) and modify the /app directory to be owned by this user/group. Would you be open to such a change? I believe it's generally a best practice to run containers as non-root. If so, I'll create a PR. If there's a concern for compatibility, I could create a separate nonroot.Dockerfile (for example) but your CI/CD would need to build/publish that with the current Dockerfile -- perhaps with a nonroot tag. I haven't looked at your CI/CD but I'm happy to take that on too if you'd like.

Looking at the environment variables, the API uses a replica database when reading. It seems that select clauses are used in various ways in indexers, and it would be good to use a replica database in this case as well.