jakiro
Auteur: Toly, Solana Labs Source conjointe: X, @ Aeyakovenko Traduction: Shan Ouba, Bit Chain Vision Realm
Dans Solana, l’organisation de l’État est un stockage de valeur de clé plate et le programme exécute la valeur de mise à jour dans cet état, y compris les procédures de vote clés pour le consensus.L’objectif principal de l’exécution asynchrone est de permettre aux procédures de vote de fonctionner indépendamment de tous les autres programmes.Afin de toujours atteindre cet objectif, nous devons assurer plusieurs principes clés.
Domaine d’exécution
Le domaine d’exécution est un ensemble de procédures et ses clés et valeurs de fonctionnement, qui sont indépendantes les unes des autres pendant l’exécution.Le domaine d’exécution peut être exécuté sur différents threads et noyaux, et est terminé à différents moments sur diverses machines.L’important est qu’un domaine d’exécution (par exemple, le domaine A) ne peut pas lire ou écrire aucune valeur dans un autre domaine (par exemple, domaine b).Cependant, le domaine peut être partagé dans un état cohérent lors de l’exécution de n’importe quel domaine.Un protocole est nécessaire pour synchroniser l’état entre le champ et favoriser le mouvement de la clé et de la valeur.
La personne de paiement des frais de transaction détermine le domaine de l’exécution de la transaction.
Domaine clé: Ved et UED
Dans Solana, nous nous concentrons principalement sur deux domaines: le domaine d’exécution de vote (VED) et le domaine d’exécution des utilisateurs (UED).L’objectif est de permettre aux vérifications de voter avant que tous les programmes d’utilisateurs ne soient effectués.
Composant Ved
-
Programme système: Pour le transfert
-
Variable du système du programme de vote: Variable du système du programme de vote pour voter
-
Vote: Procédure de vote de base.Ce programme est statique et cohérent, et doit être disponible en UED et VED.
-
Autorité de vote: Compte avec le droit de vote
-
Paiement des frais de vote: Les comptes qui paient des frais liés à voter
-
Fonds des payeurs: Peut être utilisé pour déplacer SOL vers le compte mis à jour de Ved
-
Tous les autres comptes sont placés dans UED
Calculez l’état Ved
Dans la limite de bye entre N-1 et N, calculez l’état VED du domaine N + 1 lors de l’exécution.Ce calcul doit être achevé avant l’époque n.Les calculs UED doivent commencer une fois l’ère N-1 terminée.
Standard dans le statut VED
-
Compte de vote: Paquet de plus de 5000 sol et état actif.
-
Cordeaux de coût et autorisations de vote, fonds des payeurs de dépenses: Associé au compte de vote ci-dessus.
-
Le compte de vote nouvellement créé a été initialement mis en place comme actif.Les utilisateurs doivent activer ces comptes.Les utilisateurs peuvent arrêter le compte et le compte sera supprimé de l’état VED dans l’ère N + 1.
Déplacer des fonds à Ved
Les comptes de fonds déclarés dans le compte de vote peuvent être utilisés pour déplacer des fonds dans VED.Après avoir mis à jour le coût du paiement dans le compte de vote, le fonds de paiement des dépenses actuel restera actif avant la fin de la prochaine époque.Une fois l’activation VED ré-calculée, le nouveau fonds de paiement des coûts entrera dans l’état VED et peut être utilisé pour ajouter un SOL supplémentaire au paiement des coûts.L’ancien fonds de paiement des coûts entrera dans l’État UED, de sorte que les fonds peuvent être transférés sur le compte dans l’UED.
Bien qu’il puisse être fusionné avec le payeur de dépenses, afin de minimiser le nombre de signatures utilisées pour chaque vote, le paiement des coûts est généralement fixé à la même valeur que les autorisations de vote. et Ued.
Domaine d’exécution universel
La méthode ci-dessus est très ciblée sur les procédures de vote.Cette méthode peut être promue en outre dans le domaine d’exécution de n’importe quel nombre.Le suivi du compte du domaine d’exécution, ils sont cartographiés, tout comme le programme de gestion du système d’exploitation suit VMID dans la page physique.Pour ce projet spécifique, une petite partie de la cartographie est utile:
-
Rx-ed: Lire et exécuter dans UED
-
Rx-ed-coud: Lire et exécuter dans UED et VED
-
RW-FED: Lire et écrire dans Ved
-
RW: Lire et écrire dans UED
Étant donné que le compte ne peut pas lire et écrire en même temps dans plusieurs domaines, une autre cartographie n’est pas valide.
-
programme: Il ne peut être mappé que Rx-Eed ou Rx-Eed -ved, c’est-à-dire lisible et exécutable dans les utilisateurs ou deux domaines, mais ne peut pas être écrit.Toute transaction qui inclut le programme doit échouer.
-
Compte: Seule la carte ou RW-EED ne peut être cartographiée.
Instantané système Configurez le programme de vote et le programme système vers RX-Eed -ved.Le programme système fournit un compte système et un compte de programme de vote aux interfaces VED et mobiles de VED.La mise à jour réelle nécessite toujours une ère complète pour s’activer.
Ce n’est que lorsque le programme du propriétaire est dans le domaine cible que le compte peut être relapé entre les domaines.Par conséquent, seuls les comptes du programme de vote et du programme système peuvent se déplacer entre VED et UED.
Après avoir utilisé la méthode générale, aucun compte de fonds de paiement de coûts explicites n’est nécessaire.Les développeurs peuvent ré-fuir n’importe quel compte système entre VED et UED pour déplacer des fonds entre les domaines.
Calculer le hachage Ved
Après avoir reçu le bloc, le nœud exécute toutes les transactions.Le processus est le suivant:
-
L’exécution implique uniquement des transactions impliquant des comptes VED.
-
La transaction du paiement du coût VED mais un compte mixte a échoué.
-
Ignorer toutes les autres transactions.
La mise à jour de l’état VED générée est utilisée pour calculer le hachage bancaire, c’est-à-dire le hachage VED.Les vérifications peuvent désormais voter avec Ved Hash au lieu de l’ancien hachage de la banque.S’il y a une mise à jour du hachage UED depuis le dernier vote de la fourche, le hachage et l’emplacement seront inclus dans le vote.
Calculer le hachage UED
Après avoir reçu le bloc, le nœud traite toutes les transactions:
-
Les comptes qui ne sont pas à Ved font partie de l’UED.
-
L’exécution implique uniquement des transactions impliquant des comptes UED.
-
La transaction contenant des paiements de dépenses UED mais un compte mixte a échoué.
-
Ignorer toutes les autres transactions.
La mise à jour de l’état UED générée est utilisée pour calculer le hachage bancaire, le hachage UED.
Ultime
Le sexe final reste inchangé.
Code d’état d’exécution de la transaction
Les effets secondaires de l’exécution asynchrone ne peuvent pas être détectés immédiatement lors du vote.Si 1/3 ou plusieurs vérificateurs soumettent un hachage UED différent, tous les nœuds doivent arrêter les opérateurs de confirmation et de vote et avertissent.
Pour obtenir le code d’état, la demande de l’API RPC doit permettre aux utilisateurs de spécifier le gage observé par la même observation de hachage UED.L’état d’exécution peut être exprimé en ExecutionStatus (signature, gangs = x), où x peut être 0 ou une certaine valeur par défaut.Dans les paramètres de plusieurs nœuds et clients, la valeur X est acceptable pour 0, ce qui amène les utilisateurs la confiance qui n’est pas confirmée et impossible.
La non-éternité est le seul échec qui doit être détecté avant de renvoyer le code d’état des transactions confirmées à l’utilisateur.
Génération de leader et de blocs
Les dirigeants doivent être en mesure de commencer à créer des blocs immédiatement après la fin du VED.Cela signifie que le leader fera partie de l’État et des informations incomplètes de tout paiement des coûts UED.
-
Les dirigeants exécutent le domaine Ved uniquement pour les blocs qu’ils ont créés
-
Le chargement UED doit ignorer le paiement des coûts non valide
Activation fonctionnelle des procédures de vote
Le programme de vote doit être conçu lorsque le vote VED peut franchir la frontière de l’époque lorsque la fonction est activée et exploite le moment d’autres transactions en contact avec le programme de vote dans l’UED.
prix
Ce n’est que dans les comptes de vote de Ved devraient être récompensés.
punir
Tous les comptes de vote sont le risque d’être puni, qu’ils soient dans un État actif ou VED.
Mise à jour de l’horloge mondiale
La variable du système d’horloge est mise à jour par vote.La méthode alternative doit être utilisée.Au contraire, chaque chef de bloc peut déplacer l’horloge jusqu’à 1 seconde en avant.Au moins 40% du réseau nécessite de la malveillance et les horloges peuvent croître plus rapidement que le temps réel.L’horloge peut également avancer pour 400 millisecondes par défaut.En supposant la dérive de 50 millisecondes, seulement 12,5% des dirigeants doivent ajuster l’horloge pour maintenir la synchronisation.
