MultiversX (EGLD) : EGLD couvre les coûts de réseau et de contrat
MultiversX est un réseau de contrats intelligents qui partitionne les comptes et l'exécution entre les shards. EGLD est sa monnaie native pour les frais, le staking, la sécurité des validateurs et la valeur transférable. Cette page se concentre sur le réseau de paiement eGLD et les coûts des contrats, ainsi que sur les vérifications que les utilisateurs doivent effectuer avant d'envoyer des fonds, de payer des frais ou d'utiliser le réseau.
Utilisez ou stakez EGLD tout en comprenant le sharding, les frais, la gestion des jetons et la finalité.
Objet :
MultiversX
Mode de marché :
Snapshot uniquement
Actif de frais :
EGLD
Fuseau horaire :
UTC
Cette page n'estime pas de frais en direct, ne sélectionne pas de fournisseur de staking, ne valide pas un identifiant ESDT et n'audite pas un contrat intelligent.
Propriété du contenu : Équipe éditoriale de BitcoinToolkitRéférences techniques : documentation officielle du protocole et des développeurs.Approche de révision : les explications techniques sont vérifiées par rapport aux sources primaires et mises à jour lorsque le réseau ou l'actif change.Dernière revue du contenu : Dernier test d'intégration des données :
Coûts du réseau et des contrats EGLD Pays
Les frais combinent des composants d'exécution minimale et data-related.
Flux de travail MultiversX, de la première décision de l'utilisateur à un résultat vérifié.
Limite de gaz et coût de traitement
Un simple transfert EGLD utilise une allocation minimale de gaz du protocole plus tout coût pour les données attachées. Les opérations de contrats intelligents et de jetons consomment plus de gaz selon le travail effectué. EGLD paie ces frais même lorsque l'actif transféré est un jeton ESDT.
Les portefeuilles estiment le gaz avant de signer, mais les chemins de contrat et les messages inter-shards peuvent affecter le flux de travail total. Gardez du EGLD liquide pour les frais et distinguez le gaz des frais d'application, de l'impact du prix de swap et de tout montant verrouillé dans le staking.
Risques MultiversX avant l'achèvement
Une adresse MultiversX appartient à un shard d'exécution à la fois.
Shards d'exécution et Metachain
MultiversX répartit les comptes, les contrats intelligents et le traitement des transactions entre les shards d'exécution. L'attribution des shards basée sur l'adresse détermine où l'état est stocké. La Metachain coordonne les affectations des validateurs, les en-têtes de shard et d'autres informations au niveau du réseau, plutôt que d'exécuter des contrats utilisateur ordinaires de la même manière qu'un shard d'exécution.
Le sharding adaptatif permet au système de réorganiser les responsabilités des validateurs et de l'état lorsque les conditions du protocole changent. Cela ne revient pas à exécuter des blockchains indépendantes : les shards forment un seul réseau et communiquent via des messages inter-shards authentifiés.
Les actions inter-shards ont des étapes
Un transfert entre comptes dans différents shards produit une transaction de shard source et un traitement de shard de destination. Les appels de contrats intelligents peuvent créer des résultats asynchrones supplémentaires. Un explorateur peut donc afficher des hachages et des étapes associés plutôt qu'un seul changement d'état immédiat partout.
Les applications doivent attendre le résultat de destination requis avant de considérer le flux de travail comme terminé. Une transaction source finale ne signifie pas toujours que chaque effet inter-shards a déjà été exécuté.
Les validateurs sécurisent les shards individuels tandis que le protocole fait tourner les affectations.
Sélection et signatures des validateurs
MultiversX Secure Proof of Stake sélectionne les validateurs en utilisant le stake et le hasard vérifiable, puis agrège les signatures BLS pour les blocs. Les validateurs sont mélangés entre les shards au fil du temps pour réduire le contrôle persistant. La documentation actuelle décrit une finalité déterministe à bloc unique après la mise à niveau Andromeda lorsque le seuil de validateurs requis signe.
Les délégateurs peuvent participer via des fournisseurs de staking sans opérer de validateur, mais dépendent des performances, des frais et du comportement du contrat du fournisseur. Le staking verrouille ou retarde l'accès à EGLD et peut exposer les participants à des pénalités de protocole. Les minimums actuels et les règles de déblocage doivent être vérifiés avant de s'engager.
L'identité du jeton et l'achèvement asynchrone nécessitent des vérifications explicites.
Avant d'envoyer ou de staker
Confirmez l'adresse bech32, l'identifiant ESDT, le montant et le support de destination. Gardez EGLD pour les frais et attendez tout résultat de shard de destination. Ne sélectionnez pas un jeton uniquement par son ticker et ne supposez pas qu'une adresse de contrat EVM correspond à MultiversX.
Pour le staking, examinez les frais du fournisseur, les performances, la capacité et les conditions de déblocage. Ne stakez pas la totalité du solde liquide et ne traitez pas une récompense estimée comme fixe. Vérifiez chaque portefeuille et domaine de staking via les ressources MultiversX actuelles.
Continuez avec le sharding, le staking ou la gestion des jetons.
Documentation réseau ou outils
Utilisez la documentation MultiversX actuelle pour les règles de statut de transaction, de gaz et de validateur. Comparez NEAR pour une approche de sharding différente, ou utilisez les outils de portefeuille après avoir vérifié l'identifiant officiel ESDT et le réseau. Suivez l'achèvement du shard de destination avant de continuer.
Pour un flux de travail de contrat, enregistrez le hash de la transaction source et tout résultat de destination afin que les équipes de support puissent distinguer une livraison inter-shards en attente d'un échec au niveau de l'application.
Le sharding adaptatif de l'état attribue les comptes et les transactions à travers les shards d'exécution, tandis qu'une Metachain coordonne les informations des shards. Le Proof of Stake sécurisé sélectionne les validateurs et, sous la conception actuelle de l'ère Andromeda, utilise une signature large des validateurs pour une finalité déterministe des blocs.
Une transaction MultiversX peut s'exécuter avec succès alors que l'état de l'application, la permission du contrat ou la sortie ultérieure restent incorrects pour l'objectif de l'utilisateur. EGLD est l'actif affiché dans l'aperçu du marché. EGLD paie les frais de transaction, de données et de contrats intelligents MultiversX.
Ce que les utilisateurs de MultiversX doivent vérifier et pourquoi cette conception diffère
Les paramètres du protocole et les exigences des validateurs peuvent changer. L'achèvement inter-shards dépend du chemin complet du message.
Pour MultiversX, la séquence pratique est Choisir le réseau, Financer l'actif de frais, Examiner l'action, Exécuter, Vérifier la finalité. Confirmez la destination officielle et le réseau actuel, puis inspectez le solde final, la position, le reçu ou l'état de sortie documenté qui complète réellement la tâche : Utiliser ou miser EGLD tout en comprenant le sharding, les frais, la gestion des jetons et la finalité.
FAQ sur l'utilisation du réseau MultiversX
Qui paie les frais MultiversX ?
EGLD paie les transferts, les données et le gaz des contrats intelligents.
Qu'est-ce que la Metachain ?
Il coordonne les informations des fragments et des validateurs plutôt que de servir de fragment d'exécution ordinaire.
Un transfert inter-chaînes est-il terminé après l'étape source ?
Pas toujours. Le shard de destination doit traiter le message authentifié et le changement d'état qui en résulte.
Limites connues
Les paramètres du protocole et les exigences des validateurs peuvent changer.
L'achèvement inter-shards dépend du chemin complet du message.
La page ne valide pas un jeton ESDT ou un fournisseur de staking.
Méthodologie des données de marché
La page utilise un instantané agrégé CoinGecko EGLD/USD. Aucun graphique d'échange n'est rendu pour cette entité.
Source de l'instantané du marché
Données de marché agrégées CoinGecko (EGLD/USD)
Cache
Le cache de l'instantané est d'environ 60 secondes.
Gestion des échecs
Les données mises en cache vérifiées sont étiquetées Cached ou Delayed. Les valeurs manquantes restent indisponibles.
