Problèmes connus de Blockchain Analytics

Cette page liste les problèmes connus et les solutions de contournement pour Blockchain Analytics. Pour obtenir une liste des bugs, des nouvelles fonctionnalités et d'autres informations de version, consultez les notes de version.

Pour filtrer cette page, effectuez une ou plusieurs des opérations suivantes : sélectionnez une catégorie, saisissez un terme de recherche ou cliquez sur un en-tête de colonne pour trier les résultats.

Catégorie Objet Description
Ethereum Données de compte
  • Le tableau accounts_state stocke les données sur les comptes visibles dans la position to ou from des transactions initiées par des comptes appartenant à des tiers. Aujourd'hui, Blockchain Analytics ne calcule pas les mutations de l'état du compte à la suite de transactions internes (transactions entre contrats intelligents).
  • Le tableau accounts_state affiche un instantané statique de tous les comptes vus sur la chaîne, du bloc de genèse au bloc 17 399 999 (inclus). À partir du bloc 17 400 000, Blockchain Analytics ajoute une ligne au tableau accounts_state chaque fois qu'un compte est observé participant à une transaction initiée par un compte appartenant à un tiers.
  • La table accounts_state ne contient pas d'état de stockage ni de preuves de stockage pour les contrats intelligents.
Avalanche
Ethereum
Fantom
Optimism
Tron
Adresses

Étant donné que Blockchain Analytics indexe les adresses telles qu'elles sont renvoyées par l'API JSON-RPC du nœud en amont, les adresses des ensembles de données Blockchain Analytics sont indexées en minuscules.

Utilisez LOWER() lorsque vous utilisez des adresses en casse mixte.

Exemple :

SELECT
  *
FROM
  bigquery-public-data.blockchain_analytics_ethereum_mainnet_us.transactions
WHERE
  to_address = LOWER("0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48")
AND
  block_number = 17641663;
Ethereum Fraîcheur des données Blockchain Analytics indexe Ethereum une fois l'engagement finalisé. L'indexeur attend la validation des deux tiers des validateurs Ethereum avant d'indexer les données. Les données sont donc généralement en retard de deux époques (ou 64 emplacements) par rapport au dernier bloc. Il s'agit d'une version antérieure d'environ 12 à 15 minutes.
Polygone Fraîcheur des données Les données Polygon resteront en retard d'environ 24 heures par rapport à la pointe de la chaîne.
Ethereum Traces Blockchain Analytics indexe et normalise les traces Ethereum au format Parity.
Avalanche
Ethereum
Fantom
Optimism
Tron
UINT256 Pour effectuer des calculs UINT256 sans perte, vous devez utiliser des UDF. Les UDF sont soumises à des limites de quota, de débit et de délai d'expiration, comme décrit dans Fonctions définies par l'utilisateur, limites.
Avalanche
Fantom
Optimism
Tron
Reçus de transactions manquants Il peut manquer des lignes dans le tableau des reçus de transactions pour les chaînes concernées. Cela affecte actuellement moins de 0,1 % de toutes les transactions par chaîne.
Avalanche
Fantom
Optimism
Tron
Partitionnement et clustering des tables

Les tables pour les chaînes concernées ne sont pas partitionnées. Les tables sont mises en cluster par les colonnes utilisées pour former la clé primaire de la table. Reportez-vous à Table Info pour chaque tableau.

Informations sur la table BigQuery. Cliquez pour agrandir l'image.

Avalanche
Ethereum
Fantom
Optimism
Tron
Cohérence des schémas entre les chaînes

Les ensembles de données pour toutes les chaînes comportent les tables suivantes :

  • Blocs
  • Transactions
  • Reçus
  • Journaux

Les tables des ensembles de données Avalanche, Fantom, Optimism et Tron partagent les mêmes schémas de table.

L'ensemble de données Ethereum inclut des tables supplémentaires et de légères différences de schéma par rapport à Avalanche, Fantom, Optimism et Tron.

Toutes les tables de l'ensemble de données Ethereum incluent la colonne "Timestamp du bloc".

Pour en savoir plus, consultez la page Schémas.