Transactions
Une transaction est une instruction signée adressée à la chaîne : payer quelqu’un, émettre un jeton, passer un ordre, rattacher une adresse à un groupe. ZooBC n’a pas de machine virtuelle pour le code des utilisateurs. Chaque fonctionnalité est un type de transaction intégré, doté de règles fixes que chaque nœud applique exactement de la même manière : un portefeuille sait donc, avant de signer, tout ce qu’une transaction peut faire et quels seront ses frais minimaux.
Les types intégrés
À partir de la version 0.5.8, ZooBC définit 73 numéros de type de transaction, type 0 compris, répartis en douze familles.
Un numéro de type est un groupe plus 256 fois un sous-type, si bien que la numérotation est clairsemée : 2 est NodeRegistration, et 258 (groupe 2, sous-type 1) est sa mise à jour. Un numéro que la chaîne ne définit pas est refusé, et chaque type défini est accepté dès le bloc 1.
Deux numéros sont particuliers. Le type 0, Empty, ne déplace rien : il existe pour transporter un message, il doit quand même payer des frais supérieurs à zéro, et il n’incrémente pas le nonce de l’expéditeur, le compteur par expéditeur que tient la chaîne. Le type 53, CancelLongevity, est retiré : toutes les chaînes le refusent, et c’est CloseLongevity (309) qui est utilisé à la place.
La vie d’une transaction
- Un portefeuille construit l’enveloppe, la même disposition pour tous les types, et la signe pour une seule chaîne.
- Il soumet les octets signés avec
POST /api/v1/transactions. Le code HTTP 202 signifie que le nœud a accepté la transaction dans son pool, et non qu’elle est dans un bloc. Renvoyer les mêmes octets est sans risque : la copie est marquée comme doublon. - Les nœuds relaient la transaction, et un producteur de blocs l’inclut. Un bloc contient au plus 2 000 transactions et 524 288 octets de charge utile, et au plus une transaction de chaque compte (voir une transaction par compte et par bloc).
GET /api/v1/transactions/<hash>/statusindique sa progression : staging, mempool (avec sa position), confirmed (avec la hauteur du bloc), rejected (avec la raison) ou not_found.
Une transaction qu’aucun bloc n’inclut pendant sa fenêtre expire (voir l’expiration et les horodatages).
Quand l’état change entre-temps
Entre la signature et l’inclusion dans un bloc, d’autres transactions peuvent modifier ce dont une transaction dépend : un séquestre est réglé, une offre est prise par quelqu’un d’autre, un jeton expire. Une telle transaction devient une opération nulle payante : elle est incluse dans un bloc, elle paie ses frais, et elle ne change rien d’autre. Le bloc reste valide sur tous les nœuds, si bien que personne ne peut bloquer la chaîne en envoyant des transactions sur le point de se périmer.
Un bloc n’est invalide que pour des défauts que tous les nœuds voient de la même façon, comme une signature incorrecte, des frais inférieurs au plancher (voir les frais) ou un paiement supérieur au solde de l’expéditeur.
Articles de cette catégorie
- L’enveloppe de la transaction : les champs que porte chaque transaction, et ses frais.
- Signer une transaction : le condensé lié à la chaîne et les types de clés qui peuvent signer.
- Expiration et horodatages : combien de temps une transaction signée reste valide.
- Une transaction par compte et par bloc, et les lots : une transaction par compte et par bloc, et les lots.
- Séquestre : les paiements conservés par la chaîne jusqu’à ce qu’un approbateur décide.
- Multisignature : les comptes qui ne dépensent qu’avec plusieurs signatures.
- Paiements liquides (flux de paiement) : l’argent versé en continu à un destinataire sur plusieurs minutes.
- Transferts programmés : une série de paiements signée une seule fois.
- Déclencheurs et attestations : l’argent libéré à une hauteur donnée ou après un événement.
- Groupes de comptes : plusieurs adresses qui partagent un même compte.
Voir aussi
Articles de ce thème
- Déclencheurs et attestations
Comment un déclencheur ZooBC bloque des ZBC jusqu’à une hauteur de bloc future ou jusqu’à un événement du monde extérieur, et comment les nœuds enregistrés résolvent les événements par attestation. - Expiration et horodatages
Pourquoi chaque transaction ZooBC porte sa propre heure, combien de temps elle reste valide (une heure par défaut, un jour au plus), et comment les blocs et les règlements utilisent le temps. - Groupes de comptes
Comment un groupe de comptes ZooBC permet à de nombreuses adresses, de n’importe quel type de clé, de partager un même solde, avec un contrôleur qui décide de ce que chaque membre peut dépenser. - L’enveloppe de la transaction
Les champs que porte chaque transaction ZooBC, dans l’ordre, ce que contient chacun et ce qui manque délibérément, comme une limite de gas ou un identifiant de chaîne. - Multisignature
Comment un compte multisignature ZooBC ne dépense que lorsqu’un nombre fixé de ses participants ont signé, même s’ils utilisent des clés de chaînes différentes. - Paiements liquides (flux de paiement)
Comment un paiement liquide ZooBC verse en continu des ZBC ou un jeton à un destinataire sur un nombre de minutes donné, et comment chaque partie peut l’arrêter avec un partage équitable. - Séquestre
Comment un paiement ZooBC peut être conservé par la chaîne jusqu’à la décision d’un approbateur désigné, ses quatre issues possibles, ce qu’il coûte, et les demandes de séquestre émises par le bénéficiaire. - Signer une transaction
Ce que couvre une signature ZooBC, comment sont obtenus le hachage et l’identifiant d’une transaction, quels types de clés peuvent signer, et comment des portefeuilles étrangers signent des transactions de leur propre chaîne. - Transferts programmés
Comment un seul ScheduledTransfer ZooBC met en place une série de paiements en ZBC ou en jeton, bloqués d’avance ou prélevés à échéance, et comment l’annuler ou le rediriger. - Une transaction par compte et par bloc, et les lots
Pourquoi un bloc ZooBC ne peut porter qu’une transaction de chaque compte, et comment un lot permet à un compte d’effectuer plusieurs paiements ou transferts en une seule transaction.