Chaque compte est un contrat
Sur Ethereum, il existe deux types de comptes : les comptes détenus en externe contrôlés par une clé privée, et les comptes de contrat contrôlés par du code. Starknet n’a que le second type.
Votre portefeuille Starknet est un smart contract. Il définit sa propre validation de signature, ce qui signifie qu’il peut utiliser des schémas de signature qu’Ethereum ne peut pas, prendre en charge plusieurs signataires, implémenter des clés de session, ou permettre à quelqu’un d’autre de payer vos frais.
C’est de l’abstraction de compte native, et c’est une véritable amélioration par rapport au modèle EVM, où les mêmes capacités nécessitent des standards rajoutés. Cela signifie aussi que chaque transaction est un appel de contrat, sans cas particulier de simple transfert.
Starkscan présente cela correctement : les pages de compte montrent le contrat de compte et sa classe, pas un faux compte détenu en externe. Une fois que vous connaissez le modèle, l’explorateur a du sens ; avant cela, c’est déroutant d’une façon qui est le fait du modèle plutôt que de l’explorateur.
Classes et instances
Starknet sépare le code de contrat de son déploiement. Le code est déclaré comme une classe, identifiée par un class hash. Des instances sont ensuite déployées depuis cette classe, chacune avec sa propre adresse et son propre stockage.
De nombreux portefeuilles partagent une classe de compte. De nombreux tokens peuvent partager une classe de token. Le code existe une fois sur la chaîne ; les instances sont bon marché.
C’est plus efficace que l’approche EVM consistant à déployer un bytecode identique à répétition, et cela change ce que signifie la vérification. Vérifier une classe vérifie chaque instance de celle-ci — ce qui est une propriété nettement plus forte que la vérification par adresse de l’EVM.
Starkscan montre les deux dimensions : la classe avec son code déclaré, et les instances déployées depuis celle-ci. Pour évaluer un contrat peu familier, vérifier si sa classe est une classe vérifiée largement utilisée est une vérification rapide et véritablement informative sans équivalent EVM.
Cairo et la calldata
Cairo est le langage de Starknet, conçu pour que l’exécution puisse être prouvée avec des preuves STARK. Ce n’est pas Solidity et cela ne compile pas vers du bytecode EVM ; la sémantique diffère véritablement.
La conséquence pratique pour lire les transactions concerne la calldata. La calldata de Starknet est un tableau d’éléments de champ — des nombres bruts — et sans connaître la signature de la fonction cible, cela n’a aucun sens. Starkscan la décode contre l’ABI du contrat, transformant une liste d’entiers en arguments typés nommés.
Là où il ne peut pas décoder, il montre le tableau brut. C’est le bon comportement, et cela vaut la peine de vérifier la forme brute quand quelque chose paraît étrange, puisqu’un décodeur travaillant à partir d’un ABI incorrect produit une sortie erronée avec assurance.
Voyager est la seconde opinion ici, et sur un écosystème aussi jeune, avoir deux décodeurs indépendants est plus précieux que ça ne le serait sur Ethereum.
Preuves de validité, pas fenêtres de contestation
Starknet est un rollup de validité. Plutôt que de supposer que les transactions sont correctes et de permettre une période de contestation, il génère une preuve cryptographique qu’un lot a été exécuté correctement et vérifie cette preuve sur Ethereum.
La différence avec Arbitrum et Base est significative. Il n’y a pas de fenêtre de contestation de sept jours, car il n’y a rien à contester — la preuve se vérifie ou ne se vérifie pas. Les retraits sont bornés par le temps de génération et de vérification de preuve plutôt que par une période de litige fixe.
La génération de preuve est lourde en calcul, donc les lots ne sont pas instantanés, et Starkscan montre dans quel lot se trouve une transaction et si sa preuve a été vérifiée sur Ethereum. C’est le champ qui vous dit si une transaction est réglée au sens le plus fort.
La même distinction s’applique à Linea et Scroll. Quand vous comparez des rollups, « combien de temps pour retirer » se répond par le système de preuve, pas par le marketing.
Ce que nos tests de référence ont montré
Starknet nécessitait un ensemble de référence modifié, car la moitié de nos éléments EVM habituels n’existent pas ici — il n’y a pas de comptes détenus en externe ni de simples transferts qui ne soient pas des appels de contrat.
Ce que nous avons testé à la place : un déploiement de compte, un transfert de token via un contrat de compte, un appel à une classe vérifiée largement utilisée, un appel à un contrat non vérifié, et un multicall regroupant plusieurs opérations.
Le déploiement de compte s’est affiché correctement, avec le class hash identifié et lié à d’autres instances de la même classe — ce qui est la vue sans équivalent EVM et véritablement informative. Voir qu’un compte peu familier utilise la même classe de portefeuille largement déployée que des milliers d’autres est un signal significatif d’une manière qu’un badge de vérification par adresse ne l’est pas.
Le décodage de calldata a fonctionné sur chaque classe vérifiée que nous avons essayée, produisant des arguments typés nommés plutôt que des tableaux d’éléments de champ. Sur le contrat non vérifié, il est revenu au tableau brut, clairement étiqueté comme non décodé plutôt que présenté comme une meilleure supposition. C’est le bon comportement et nous l’avons spécifiquement vérifié, car un décodeur qui devine silencieusement est pire qu’un qui admet ne pas pouvoir.
Le multicall a été rendu comme ses appels composants, ce que rend possible l’abstraction de compte et ce qui rend les transactions Starknet lisibles tout court.
Nous avons contre-vérifié trois des cinq contre Voyager. Les trois correspondaient. Sur un écosystème aussi jeune, lancer la comparaison occasionnellement vaut les trente secondes, car une divergence de décodage entre deux implémentations indépendantes est le moyen le plus rapide de découvrir que l’une d’elles a un ABI erroné.