Cette API permet aux clients d'interagir avec la P-Chain (Platform Chain), qui gère le jeu de validateurs d'Avalanche et gère la création de la blockchain.
Endpoint
/ext/P
Format
Cette API utilise le format RPC json 2.0. Pour plus d'informations sur les appels JSON RPC, cliquez ici.
Méthodes
platform.addDelegator
Ajoutez un délégateur au réseau principal.
Un délégateur stake ces AVAX et spécifie un validateur (le délégataire) à valider en son nom. Le délégataire a une probabilité accrue d'être échantillonné par d'autres validateurs (poids) proportionnellement à l'enjeu qui lui est délégué.
Le délégataire facture des honoraires au délégant; le premier reçoit un pourcentage de la récompense de validation du délégant (le cas échéant). Une transaction qui délègue la participation est gratuite.
La période de délégation doit être un sous-ensemble de la période pendant laquelle le délégataire valide le réseau principal.
Notez qu'une fois que vous émettez la transaction pour ajouter un nœud en tant que délégant, il n'y a aucun moyen de modifier les paramètres. Vous ne pouvez pas annuler la période de stake ou modifier le montant de la mise, l'ID de nœud ou l'adresse de récompense. Veuillez vous assurer que vous utilisez les valeurs correctes. Si vous n’êtes pas sûr, demandez de l’aide sur Telegram.
Voir ici pour les paramètres de jalonnement (staking) comme le montant minimum qui peut être jalonné..
startTime est l'heure Unix à laquelle le délégant commence à déléguer.
endTimeest l'heure Unix où le délégant arrête de déléguer (et les AVAX stakeest retourné).
stakeAmount est la quantité de nAVAX que le délégant jalonne.
rewardAddress est l'adresse à laquelle la récompense du validateur va, s'il y en a une.
from sont les adresses que vous souhaitez utiliser pour cette opération. En cas d'omission, utilise l'une de vos adresses au besoin.
changeAddr est l'adresse à laquelle tout changement sera envoyé. En cas d'omission, la modification est envoyée à l'une des adresses contrôlées par l'utilisateur.
username est l'utilisateur qui paie les frais de transaction.
Ajoutez un validateur au réseau principal. Vous devez stake des AVAX pour ce faire. Si le nœud est suffisamment correct et réactif lors de la validation, vous recevez une récompense une fois la validation terminée. La probabilité du validateur d’être échantillonné par d’autres validateurs lors du consensus est proportionnelle à la quantité d’AVAX jalonnée.
Le validateur peut facturer des frais aux délégués; le premier reçoit un pourcentage de la récompense de validation du délégant (le cas échéant). Les frais de délégation minimum sont de 2%. Une transaction qui ajoute un validateur est gratuite.
La période de validation doit être comprise entre 2 semaines et 1 an.
Un poids total maximum est imposé aux validateurs. Cela signifie qu'aucun validateur n'aura jamais plus d'AVAX jalonné et délégué que cette valeur. Cette valeur sera initialement réglée sur min min(5 * amount staked, 3M AVAX). La valeur totale d'un validateur est de 3 millions d'AVAX.
Notez qu'une fois que vous émettez la transaction pour ajouter un nœud en tant que validateur, il n'y a aucun moyen de modifier les paramètres. Vous ne pouvez pas annuler la mise tôt ou modifier le montant de la mise, l'ID de nœud ou l'adresse de récompense. Veuillez vous assurer que vous utilisez les valeurs correctes. Si vous n’êtes pas sûr, demandez de l’aide sur Telegram.
Voir ici pour les paramètres de jalonnement (staking) comme le montant minimum qui peut être jalonné.
startTime est l'heure Unix à laquelle le validateur commence à valider le réseau primaire.
endTime st l'heure Unix où le validateur arrête de valider le réseau primaire (et les AVAX stake sont retournés).
stakeAmount est la quantité de nAVAX que le validateur jalonne.
rewardAddressest l'adresse à laquelle la récompense du validateur ira, s'il y en a une.
from sont les adresses que vous souhaitez utiliser pour cette opération. En cas d'omission, utilise l'une de vos adresses au besoin.
changeAddr est l'adresse à laquelle tout changement sera envoyé. En cas d'omission, la modification est envoyée à l'une des adresses contrôlées par l'utilisateur.
delegationFeeRate est le pourcentage de frais facturé par ce validateur lorsque d'autres lui délèguent la participation. Jusqu'à 4 décimales autorisées; les décimales supplémentaires sont ignorées. Doit être compris entre 0 et 100 inclus. Par exemple, si DelegationFeeRate vaut 1,2345 et que quelqu'un délègue à ce validateur, alors lorsque la période de délégation est terminée, 1,2345% de la récompense va au validateur et le reste va au délégant.
username est l'utilisateur qui paie les frais de transaction.
passwordest l' usernamemot de passe.
txID est l'ID de transaction
Example d'un Appel
Dans cet exemple, nous utilisons date de la commande shell pour calculer les temps Unix 10 minutes et 2 jours dans le futur. (Remarque: si vous utilisez un Mac, remplacez$(date avec $(gdate. Si vous n'avez pas installé gdate, faitesbrew install coreutils.)
Ajoutez un validateur à un sous-réseau autre que le réseau principal. Le validateur doit valider le réseau principal pendant toute la durée de validation de ce sous-réseau.
startTime est l'heure Unix à laquelle le validateur commence à valider le sous-réseau.
endTime est l'heure unix à laquelle le validateur arrête de valider le sous-réseau.
weight est le poids du validateur utilisé pour l’échantillonnage.
from sont les adresses que vous souhaitez utiliser pour cette opération. En cas d'omission, utilise l'une de vos adresses au besoin.
changeAddrest l'adresse à laquelle tout changement sera envoyé. En cas d'omission, la modification est envoyée à l'une des adresses contrôlées par l'utilisateur.
username est l'utilisateur qui paie les frais de transaction.
Créez une nouvelle blockchain. Actuellement, prend uniquement en charge la création de nouvelles instances de l'AVM et de la machine virtuelle d'horodatage.
subnetIDest l'ID du sous-réseau qui valide la nouvelle blockchain. Le sous-réseau doit exister et ne peut pas être le réseau principal.
vmID est l'ID de la machine virtuelle exécutée par la blockchain. Peut également être un alias de la machine virtuelle.
name est un nom lisible par l'homme pour la nouvelle blockchain. Pas nécessairement unique.
genesisData est la représentation de base 58 (avec somme de contrôle) de l'état de genèse de la nouvelle blockchain. Les machines virtuelles doivent avoir une méthode d'API statique nommée buildGenesis qui peut être utilisée pour générer genesisData
from sont les adresses que vous souhaitez utiliser pour cette opération. En cas d'omission, utilise l'une de vos adresses au besoin.
changeAddrest l'adresse à laquelle tout changement sera envoyé. En cas d'omission, la modification est envoyée à l'une des adresses contrôlées par l'utilisateur.
username est l'utilisateur qui paie les frais de transaction.
password est l' usernamemot de passe.
txIDest l'ID de transaction.
Example d'un Appel
Dans cet exemple, nous créons une nouvelle instance de la machine virtuelle Timestamp. genesisData provient de l'appel de timestamp.buildGenesis.
Afin de créer ajouter un validateur à ce sous-réseau, des signatures thresold sont requises à partir des adresses dans controlKeys
from sont les adresses que vous souhaitez utiliser pour cette opération. En cas d'omission, utilise l'une de vos adresses au besoin.
changeAddrest l'adresse à laquelle tout changement sera envoyé. En cas d'omission, la modification est envoyée à l'une des adresses contrôlées par l'utilisateur.
username est l'utilisateur qui paie les frais de transaction.
Envoyez des AVAX depuis une adresse sur la P-Chain vers une adresse sur la X-Chain. Après avoir émis cette transaction, vous devez appeler la méthode importAVAX de la X-Chain pour terminer le transfert.
to est l'adresse sur la chaîne X à laquelle envoyer l'AVAX
from sont les adresses que vous souhaitez utiliser pour cette opération. En cas d'omission, utilise l'une de vos adresses au besoin.
changeAddrest l'adresse à laquelle tout changement sera envoyé. En cas d'omission, la modification est envoyée à l'une des adresses contrôlées par l'utilisateur.
username est l'utilisateur qui paie les frais de transaction.
Répertoriez les validateurs actuels du sous-réseau donné.
Le champ de niveau supérieur delegators sont obsolètes à partir de la v1.0.1. Si vous l'utilisez, vous devez arrêter de l'utiliser. Au lieu de cela, chaque élément de validators contient maintenant la liste des délégués pour ce validateur. Vous devriez obtenir des informations sur les délégués de cette façon à l'avenir.
Répertoriez les validateurs dans l'ensemble de validateurs en attente du sous-réseau spécifié. Chaque validateur ne valide pas actuellement le sous-réseau, mais le fera à l'avenir.
Récupérez un assetID pour l'élément de jalonnement d'un sous-réseau. Actuellement, cela renvoie toujours le assetID de jalonnement du réseau principal.
utxos est une liste d'UTXO telle que chaque UTXO référence au moins une adresse dans les addresses.
Au maximum limit UTXOs sont retournées. Si limit est omise ou supérieure à 1024, elle est définie sur 1024.
Cette méthode prend en charge la pagination. endIndex désigne le dernier UTXO renvoyé. Pour obtenir le prochain ensemble d'UTXO, utilisez la valeur de endIndex comme startIndex lors de l'appel suivant.
Si startIndex est omis, récupérera tous les UTXO jusqu'à la limit.
Lors de l'utilisation de la pagination (c'est-à-dire lorsquestartIndex est fourni), les UTXO ne sont pas garantis d'être uniques sur plusieurs appels. Autrement dit, un UTXO peut apparaître dans le résultat du premier appel, puis à nouveau dans le deuxième appel.
Lors de l'utilisation de la pagination, la cohérence n'est pas garantie sur plusieurs appels. Autrement dit, l'ensemble UTXO des adresses peut avoir changé entre les appels.
Example
Supposons que nous voulons que tous les UTXO référencent au moins un desP-avax1s994jad0rtwvlfpkpyg2yau9nxt60qqfv023qx et P-avax1fquvrjkj7ma5srtayfvx7kncu7um3ym73ztydr.
puisque numFetched est identique à limit, nous pouvons dire qu'il peut y avoir plus d'UTXO qui n'ont pas été récupérés. Nous appelons à nouveau la méthode, cette fois avec startIndex:
Puisque numFetched est moins que la limit, nous savons que nous avons fini de récupérer les UTXO et que nous n'avons pas besoin d'appeler à nouveau cette méthode.
Suppose we want to fetch the UTXOs exported from the X-Chain to the P-Chain in order to build an ImportTx. Then we need to call GetUTXOs with the sourceChain argument in order to retrieve the atomic UTXOs:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :1,
"method" :"platform.getUTXOs",
"params" :{
"addresses":["P-avax1fquvrjkj7ma5srtayfvx7kncu7um3ym73ztydr"],
"sourceChain": "X"
}
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/P
to est l'ID de l'adresse vers laquelle l'AVAX est importé. Cela doit être le même que l'argument to dans l'appel correspondant à l'exportAVAX X-Chain.
sourceChain est l'ID ou l'alias de la chaîne à partir de laquelle l'AVAX est importé. Pour importer des fonds de la X-Chain, utilisez "X".
from sont les adresses que vous souhaitez utiliser pour cette opération. En cas d'omission, utilise l'une de vos adresses au besoin.
changeAddr est l'adresse à laquelle tout changement sera envoyé. En cas d'omission, la modification est envoyée à l'une des adresses contrôlées par l'utilisateur.
username est l'utilisateur qui contrôle l'adresse spécifiée dans to.
