Exploitation d'un pool de participation(Stake pool) | Partie 2.1

[Uptodate_Developers]

Comment fonctionne le serveur IOHK SMASH ?

La première génération de SMASH est initialement déployée par IOHK et est utilisée dans le centre de délégation de Daedalus, où elle offre la possibilité de visualiser les pools de mises disponibles avec des noms vérifiés, des symboles boursiers et des sites Web.

Vous trouverez ci-dessous une description étape par étape des actions qui peuvent être entreprises lorsque vous identifiez un pool avec un nom de ticker en double ou un contenu offensant. Veuillez noter que cela s’applique au serveur SMASH qui est géré et maintenu par IOHK.

• Raisons de radiation du pool de participations

Tout d’abord, veuillez vous assurer qu’il existe une raison pour qu’un pool de participations soit retiré de la liste. Certaines raisons influencent la décision de retirer un pool de participations de la liste. Ceux-ci inclus:

1. contenu illégal ou malveillant : un pool de participation qui présente tout contenu illégal, abusif ou malveillant dans le cadre des métadonnées du pool de participation (par exemple via le lien vers la page d’accueil de l’OFS).
2. usurpation d’identité : pools de participation qui tentent de se faire passer pour d’autres individus, groupes ou organisations d’une manière qui induit en erreur, confond ou trompe les autres. Par exemple, un pool de participation réussi appelé POOL étant manifestement imité par un autre appelé P00L (en créant un lien vers le même site Web).
3. ‘réclamation’ précédente : les noms de ticker peuvent être enregistrés par les SPO sur la base du “premier arrivé - premier servi”, cependant, un nom de ticker qui a été enregistré sur le Incentivized Testnet (ITN), ne peut être enregistré que sur le réseau principal de Cardano par le même SPO qui a enregistré un tel ticker sur l’ITN. Les noms de ticker qui ont été enregistrés sur l’ITN mais qui n’ont pas été réenregistrés sur le réseau principal de Cardano avant le 19 juin 2020 seront publiés et disponibles pour enregistrement sur le réseau principal de Cardano.
4. un nom de téléscripteur inapproprié : un nom de téléscripteur qui est obscène, sexuellement explicite, offensant, blessant, profane ou autrement inapproprié. Il s’agit d’un jugement subjectif dans certains cas, donc les meilleurs efforts seront toujours faits.
5. violations des droits de propriété intellectuelle (DPI) : OPP qui violent les droits de propriété intellectuelle d’autrui, y compris les droits d’auteur et les marques de commerce, lorsque des preuves peuvent être fournies.
6. pools inactifs ou retirés : pools de participations qui sont retirés ou n’ont pas produit de blocs depuis longtemps, ou dont le SPO ne peut pas être contacté. Les pools retirés du réseau principal disposent d’un délai de six mois pour demander le réenregistrement de leur nom de ticker.

• Comment demander une radiation

1. Lorsque vous identifiez un pool de participations qui, selon vous, devrait être radié, vous pouvez envoyer une demande officielle de radiation à smash@iohk.io. Veuillez inclure votre justification et toute preuve de la raison pour laquelle ce pool de participations devrait être retiré de la liste. En particulier, indiquez l’une des raisons ci-dessus et fournissez une explication détaillée. Les pools de participation usurpant l’identité de marques doivent être signalés par le titulaire de la marque ou son représentant autorisé.
2. Après votre demande, vous recevrez un email qui accuse réception de la prise en compte de votre demande.
3. Un opérateur SMASH examinera la demande pour s’assurer que le raisonnement et les preuves sont exacts et prendra une décision de supprimer ou non le pool de mises. Il peut également être déterminé qu’un arbitrage supplémentaire ou une consultation communautaire peut être nécessaire. Cependant, la décision finale sera toujours réservée à l’entité exploitant le serveur SMASH en question.
4. Lorsqu’une décision est prise, vous recevrez un e-mail indiquant si le pool de mises sera retiré de la liste ou si la liste des tickers sera autorisée à rester. Dans les deux cas, nous fournirons toujours une explication ou une justification du choix. Veuillez noter que dans certains cas, un pool de participations peut être retiré de la liste de manière proactive - que ce soit temporairement ou définitivement. Avec la radiation appliquée, le pool de participations ne sera pas visible sur SMASH et son opérateur devra faire valoir ses arguments s’il souhaite que la décision soit annulée.

Si un opérateur de pool de participations pense que la radiation de son pool de participations s’est produite par erreur, il peut faire appel en envoyant un e-mail à smash@iohk.io.

L’opérateur SMASH d’IOHK examine en permanence toutes les demandes de la communauté Cardano et des SPO pour s’assurer que toutes les informations sur le pool de participations sont suivies et gérées avec précision. Une demande est généralement traitée en 7 jours ouvrés.

Il est important de noter que la suppression de la liste se réfère uniquement à l’affichage des métadonnées et à la liste avec SMASH. En tant que réseau décentralisé, à aucun moment, les opérations de mise en commun ne seront affectées.

Performances du pool de mises

Un pool de participations élu en tant que leader des machines à sous est chargé de produire de nouveaux blocs pour le réseau Cardano. Si le pool de mises ne produit pas de bloc, la fente restera vide et la blockchain ne sera pas étendue. La blockchain Cardano peut tolérer un certain nombre de blocs manquants, mais la majorité des blocs censés être produits (au moins 50% + 1) doivent être générés au cours d’une époque.

Bien que les blocs parfois manqués n’affectent pas l’extension de la blockchain dans son ensemble, un pool de participation élu qui ne répond pas diminue les performances globales du réseau, ce qui n’est pas souhaitable.

La performance du pool de participations est calculée en fonction de son activité attendue comme le rapport du nombre de blocs qu’un pool de participations produit à une époque donnée par rapport au nombre qu’il était capable de produire. Par exemple, si le pool de participations pouvait produire 100 blocs (en fonction de sa participation et de la chance d’être élu) à une époque, mais qu’il ne produisait en réalité que 50 blocs, sa performance serait de 50 %.

Une mauvaise performance du pool de participations diminue le nombre de récompenses qu’un pool et ses membres reçoivent, diminuant ainsi son attrait pour les délégants. Pour améliorer ses performances, un pool de participations doit disposer d’une bonne connectivité réseau, être exécuté sur un système fiable et participer activement à la production et à la vérification des blocs.

Plus les performances du pool sont élevées, plus il sera attractif pour les délégants car il offrira des récompenses et des incitations plus élevées

Classement du pool de mises

Dans le portefeuille Daedalus et Cardano Explorer, les pools de mises sont classés en fonction du montant des récompenses que les utilisateurs recevront s’ils choisissent de déléguer à ces pools. Le classement montre le niveau de saturation du pool, simplifiant le choix du pool. Du point de vue d’un délégant, une fois qu’un pool atteint un certain point de saturation, il ne sera plus avantageux de lui déléguer. Les pools de mises les plus attractifs sont affichés en premier et classés de haut en bas.

Le système de classement est conçu pour fournir aux utilisateurs la possibilité de choisir le pool de participations le plus approprié pour un retour sur investissement (ROI) plus élevé, afin que les opérateurs de pools de participations fiables puissent maintenir et soutenir le système et maximiser la décentralisation.

Paramètres de classement

Le classement d’un pool est basé sur plusieurs paramètres : le coût et la marge, les performances du pool et le montant de la mise que le pool a déjà accumulé. Ces facteurs favorisent des pools de participations fiables qui ne sont pas encore saturés et offrent un faible coût et une faible marge.

Lignes directrices pour l’exploitation de grands pools de mises

Cette section fournit des directives aux opérateurs de grands pools de participations, en particulier sur la manière de gérer les risques et la complexité liés au maintien d’une participation importante ou de plusieurs pools. Les opérateurs de pools de participations plus petits peuvent également trouver une grande partie de ces conseils utiles pour eux.

Principales recommandations

Tenez compte de la fiabilité et de la robustesse . Les pools de participations nécessitent des serveurs hautement fiables avec :

• Capacité de calcul résiliente.
• Capacité de mise en réseau robuste.

Considérez attentivement les exigences de mise en réseau :

• Les connexions à large bande passante sont essentielles pour faire fonctionner un nœud de relais (par exemple, 5 Mbit/s + 0,1 Mbit/s par pair en aval comme numéro de planification de capacité).

Exploitez suffisamment de nœuds relais ainsi que des pools de participation :

• Les nœuds relais sont nécessaires à la maintenance du réseau.
• Provisionnez deux nœuds de relais pour chaque pool de participations actif.

Tenez compte des performances du système et du réseau , en particulier si vous utilisez des serveurs virtualisés ou partagés :

• Chaque pool de participations peut avoir besoin de ses propres ressources matérielles dédiées (calcul, mémoire et réseau).
• Il est recommandé d’utiliser des serveurs différents pour les pools de mises et les nœuds de relais.
• La virtualisation peut compliquer le processus consistant à déterminer si les pools de participations disposent de ressources adéquates.

Ne répliquez pas les pools de mises sur le réseau :

• La réplication du pool de participations est un comportement contradictoire, ce qui peut entraîner le rejet de blocs.
• Utilisez des techniques de haute fiabilité pour basculer entre les serveurs dupliqués ou de secours sans exposer les deux simultanément au réseau.

Les pools de participation doivent avoir des connexions réseau limitées :

• Cela réduit l’exposition du pool de mises aux attaques par déni de service (DOS) et améliore les performances.
• Les nœuds de relais doivent gérer la plus grande partie du trafic réseau.
• Les pools d’enjeux ne doivent être connectés qu’à des nœuds de confiance (relais et/ou générateurs d’enjeux).
• Les pools de participation et les nœuds de relais doivent restreindre les services qui sont exposés (par exemple, en utilisant un pare-feu).

La sécurité est primordiale :

• Utilisez l’écart d’air lors de la signature des transactions - ne stockez pas les clés froides sur un serveur en ligne (y compris celui qui exécute un pool de participation ou un nœud de relais).
• Utilisez des portefeuilles matériels pour les clés privées de grande valeur, si possible.
• Lorsque les clés privées ne peuvent pas être stockées dans des portefeuilles matériels (par exemple, des clés froides), stockez-les hors ligne.
• Tenez compte des rotations de clés imposées et planifiez-les à l’aide du schéma de signature évolutive de clé (KES).

Gérer les risques et la complexité

L’exploitation efficace des pools de participations est cruciale pour assurer la santé et la vivacité à long terme de la décentralisation sur Cardano. Lorsqu’un opérateur de pool de participations (SPO) exploite plusieurs pools de participations (ou dispose d’un pool unique qui contrôle directement un pourcentage important du total de l’ada jalonné), ils peuvent avoir un effet significatif sur le débit global du système en raison de la «preuve- principe d’« enjeu ».

La conception et l’analyse de la sécurité de Cardano supposent que chaque pool de participations fonctionne de manière largement indépendante et se renforce mutuellement (non contradictoire). Cela signifie que les grands OPP ont la responsabilité particulière de s’assurer que leur fonctionnement répond aux besoins du réseau dans son ensemble. Pour cela, il est essentiel d’évaluer et de traiter les risques communs qui peuvent être rencontrés dans les opérations de mise en commun.

• Risques de virtualisation et de conteneurisation

Étant donné que les pools de participations et les nœuds relais ont des exigences spécifiques en temps réel, il n’est généralement pas recommandé d’exécuter des nœuds Cardano sur des ressources virtualisées sans entreprendre des analyses approfondies des performances, de la fiabilité et de la sécurité. Le mappage des nœuds Cardano à l’infrastructure physique sous-jacente doit tenir compte des problèmes de synchronisation pour la production et la propagation des blocs.

• Défaillances de sécurité et de mode commun

Les risques liés à l’exploitation d’un pool de participations à l’aide de la virtualisation basée sur des conteneurs incluent des risques accrus de défaillances du système en mode commun, des conflits de ressources et une exposition accrue aux risques de sécurité (y compris les attaques DOS et la perte de clés privées). L’utilisation d’environnements conteneurisés, où les nœuds relais partagent la même infrastructure physique que les nœuds de pool de participation, peut avoir un impact sur les exigences en temps réel sur la production de blocs et l’infrastructure de mise en réseau, réduisant ainsi les revenus du pool de participation. De plus, la concentration des connexions réseau (comme cela peut arriver avec des services virtualisés ou conteneurisés) augmente les risques d’attaque DOS, tout en réduisant la redondance du réseau de manière non évidente. Dans un environnement virtualisé ou partagé, une seule panne de carte réseau/câble ou une attaque DOS, par exemple, peut alors affecter plusieurs pools de participations ou nœuds de relais, y compris ceux qui peuvent être exécutés par différents SPO.

• Ressources partagées

La diffusion d’un bloc nouvellement frappé provoque une « impulsion » d’activité. Les pools de participation et les nœuds de relais qui partagent des ressources informatiques physiques seront obligés de se faire concurrence pour le CPU partagé, la mémoire, le stockage, la mise en réseau et d’autres ressources. La demande de ces ressources n’est pas lisse, elle est corrélée par la diffusion du bloc. Cela peut affecter négativement la production de blocs ou entraîner des échecs de synchronisation de la blockchain. Dans certaines conditions, les performances peuvent se dégrader de manière non linéaire (par exemple, l’ajout d’un deuxième nœud peut réduire les performances de plus de 50 %). Pour éliminer ces risques, il est important d’analyser les exigences de performance non seulement pour la charge typique mais aussi pour les cas limites.

• Entretien et mise à niveau

La maintenance et les mises à niveau du système doivent toujours être prises en considération. Bien que la migration d’une instance virtualisée vers un nouveau matériel ou la duplication d’une instance en cours d’exécution puisse sembler facile, cela entraîne généralement des perturbations temporelles. Ceci est plus important dans un environnement en temps réel (tel que Cardano) que pour les applications de traitement de données typiques, qui ont souvent des niveaux élevés de réplication et de redondance. Les mises à niveau du système peuvent également avoir des effets inattendus sur les performances du système virtualisé ou, occasionnellement, sur ses fonctionnalités. Les OPP doivent donc être conscients de la maintenance sous-jacente du système et prendre les mesures appropriées pour éviter de perdre des blocs (et des revenus).

• Concentration géographique et physique

Les systèmes virtualisés sont souvent concentrés dans quelques grands centres de données. Cela crée des points potentiels de défaillances communes du réseau, y compris la dépendance à des parties spécifiques des infrastructures nationales (backbones Internet, réseaux électriques, etc.). Les grands SPO devraient viser à disperser leurs opérations dans plusieurs régions, et les très grands opérateurs devraient viser une présence mondiale.

Approvisionnement

Pour assurer la résilience et la robustesse globales du réseau, les SPO qui gèrent de grands pools de participations doivent veiller tout particulièrement à :

Configuration du pool de mises

1. Les configurations de réseau doivent assurer une connectivité suffisante aux autres pools de participations (y compris ceux qui sont gérés par d’autres opérateurs).
2. Les effets de la virtualisation doivent être examinés attentivement : compte tenu de la nature pulsée de la diffusion des blocs, il est facile de surcharger les ressources physiques de calcul, de mémoire et de mise en réseau. Contrairement à une opération typique de base de données ou de service Web, les pools de participations Cardano ont des exigences de calcul et de mise en réseau en temps réel. Le non-respect de ces exigences peut avoir un impact sur les rendements du pool de mises. Il n’est généralement pas recommandé de partager les ressources du serveur entre plusieurs pools de mises ou nœuds de relais.
3. Les pools de participation doivent toujours être pris en charge par suffisamment de nœuds relais (deux ou plus). Cela réduit le risque de défaillance d’un nœud relais unique, qui peut potentiellement isoler un nœud producteur de blocs. L’échec d’un nœud producteur de blocs ne devrait affecter la production de blocs que pour ce pool de mise unique. Il est particulièrement important que les grands OPP assument cette responsabilité puisqu’ils reçoivent une proportion plus élevée des récompenses d’exploitation du réseau.
4. Pour prendre en charge la mise à l’échelle de la capacité de relais, il est souhaitable d’utiliser des noms DNS mappés sur plusieurs adresses IP et/ou d’utiliser plusieurs entrées DnsName sur la chaîne. Idéalement, ces entrées devraient être prises en charge sur une infrastructure réseau disjointe (par exemple, différents FAI ou chemins physiques).

Préférences de sécurité

1. Les clés froides ne doivent jamais être stockées sur des serveurs actifs (en particulier des serveurs cloud).
2. Les clés de paiement doivent être conservées séparément des clés de signature de bloc. Des écarts d’air doivent être maintenus entre les pools de mises et les systèmes utilisés pour la signature des transactions.
3. Des portefeuilles matériels ou d’autres moyens sécurisés doivent être utilisés pour protéger les clés froides. Un portefeuille matériel peut être nécessaire par jeu de clés (par exemple, par pool de mises), et celles-ci peuvent devoir être physiquement sécurisées.
4. Les clés de secours doivent également être conservées en toute sécurité pour chaque pool de mises.

Conseil général :

1. Tenez compte des performances matérielles, notamment des capacités de mémoire, de stockage et de mise en réseau.
2. Effectuez une analyse des effets du mode de défaillance pour vous assurer que les défaillances uniques d’un composant de livraison sont convenablement limitées.
3. Examinez attentivement les performances de conteneurisation et de virtualisation pour éliminer les conflits excessifs pour les ressources communes (par exemple, les cœurs de processeur).
4. Soumettez des certificats de groupe de participation qui incluent à la fois l’adresse IP et les noms DNS.
5. S’assurer qu’une surveillance appropriée est en place : (Recevoir la grande majorité des blocs (> 90%) dans les 4 000 ms de leur créneau horaire associé. Suivez les temps de production des blocs pour vous assurer que les ressources allouées restent suffisantes (cela augmentera à mesure que les taux de transaction et la taille des blocs augmenteront).)
6. Planifiez l’expansion des nœuds relais (potentiellement à un emplacement différent) qui sont associés à votre enregistrement de mise (atténuation DDoS / augmentations rapides de la charge en raison de l’augmentation de la délégation aux pools de mise de SPO, etc.).
7. Planifiez des événements de maintenance réguliers (pour minimiser les temps d’arrêt du pool de mises et/ou pour effectuer la maintenance lorsque le calendrier des dirigeants indique un bon intervalle).
8. Planifiez et effectuez une reprise après sinistre tous les 3 à 6 mois.
9. Lorsque vous exploitez plusieurs pools de participations, répartissez vos nœuds de producteurs de blocs sur plusieurs continents pour limiter les perturbations de la production de blocs et éliminer les pannes de réseau à grande échelle.

Exemples de configurations de topologie de système et de relais

Il n’y a pas de configuration système standard car chaque pool de mises a des exigences et des préférences opérationnelles différentes. C’est le choix d’un SPO sur la manière de configurer la topologie.

Cependant, en tenant compte des conseils précédents, il est recommandé qu’un SPO maintienne au moins deux nœuds relais supplémentaires par pool de participations. Dans le cas de la gestion de plusieurs pools de participations, il est préférable que les SPO utilisent des pairs géographiquement diversifiés, répartissent les nœuds relais à travers le monde et contactent d’autres SPO (en particulier les autres grands) en concluant des accords pour ajouter les nœuds relais les uns des autres. Plus il y a de SPO avec lesquels ils ont des accords de partage entre pairs, plus leurs blocs se propageront et seront inclus dans la chaîne.

La surveillance est importante pour tous les SPO, et c’est essentiellement la responsabilité d’un opérateur d’assurer la qualité de la fonctionnalité de ses pools.

• Exemple de topologie de relais

Veuillez noter que les nœuds de relais IOHK sont décrits à titre d’exemple.

`

{`

`  "Producers": [`

`    {`

`    "addr": "north-america.relays-new.cardano-mainnet.iohk.io",`

`    "port": 3001,`

`    "valency": 4`

`    },`

`    {`

`    "addr": "asia-pacific.relays-new.cardano-mainnet.iohk.io",`

`    "port": 3001,`

`    "valency": 4`

`    },`

`    {`

`    "addr": "europe.relays-new.cardano-mainnet.iohk.io",`

`    "port": 3001,`

`    "valency": 4`

`    }`

`  ]`

`}`

Options de configuration du nœud

L’option de configuration MaxConcurrencyDeadline contrôle le nombre de tentatives que le nœud exécutera en parallèle pour récupérer le même bloc. Étant donné qu’il est important d’obtenir le même bloc le plus tôt possible pour les nœuds relais et les nœuds producteurs de blocs, nous vous recommandons de définir la valeur MaxConcurrencyDeadline sur 4.

Conseil en délégation et nantissement

Délégation

La délégation de participation est le processus d’attribution des fonds des parties prenantes individuelles à des pools de participations collectives. La délégation est effectuée à des fins de production de blocs pour garantir que la création de blocs est conforme au consensus de preuve de participation. En déléguant, les parties prenantes ne transfèrent pas la propriété du capital, le droit de vote ou d’autres droits.

Les grands SPO contrôleront généralement une quantité importante de participation de tiers pour maintenir la confiance dans la blockchain, étant ainsi responsables de :

• produire des blocs
• traitement des transactions
• maintenir le réseau Cardano
• s’assurer que le gage du propriétaire est fait
• sécuriser le pool (par exemple, protéger ses clés privées)
• fournir des communications publiques sur le pool, y compris des annonces de retrait, des changements de prix ou d’autres paramètres du pool.

Les grands opérateurs ne sont pas responsables de la distribution des récompenses de production de blocs aux délégants car cela est géré automatiquement par la blockchain. Les SPO ne sont pas non plus responsables de la sécurisation des clés de délégation ou de la délégation, du vote ou d’autres actions au nom des parties prenantes. Les parties prenantes individuelles doivent assumer personnellement la responsabilité de leur propre sécurité et doivent prendre leurs propres décisions en termes de délégation, de vote, etc.

Mise en gage

La mise en gage est un mécanisme important pour produire l’écosystème sain de Cardano. Les OPP peuvent choisir de nantir une partie ou la totalité de leur ada au pool afin de le rendre plus attractif pour les autres délégants, et ainsi d’augmenter la taille du pool dans son ensemble. L’ada gagé peut être fourni soit par un SPO, soit par d’autres propriétaires.

Récompenses de promesse de don

L’engagement influence les récompenses qu’un pool de mises peut gagner, et donc les récompenses que les délégants peuvent obtenir du pool. Le montant de la mise en gage peut être spécifié, si vous le souhaitez, lors de l’inscription au pool, et peut ensuite être modifié d’une époque à l’autre. Aucun engagement minimum n’est requis, cependant, il n’y a pas non plus d’engagement maximum.

Étant donné deux pools de mises équivalents, celui avec le plus grand engagement gagnera plus de récompenses et sera donc plus attrayant pour les autres délégants. Cependant, l’OFS ou d’autres propriétaires de pool doivent respecter collectivement l’engagement en déléguant. Il est également important de s’assurer qu’il y a suffisamment de fonds dans les adresses qui utilisent l’adresse ou les adresses du propriétaire du pool comme référence de mise. Le non-respect de l’engagement signifie qu’aucune récompense ne peut être gagnée pour le pool par un propriétaire ou un délégant. Cela entraînera généralement une perte de délégation et peut-être un effondrement du pool.

Contrairement à la délégation, l’OFS est responsable de la distribution de toutes les récompenses de promesse de don. Cela peut être fait de n’importe quelle manière convenue et n’est pas appliqué par la blockchain.

L’exploitation d’un pool de participations collectives (maintenu par un opérateur et un groupe de propriétaires, nantissant leur participation) nécessite une confiance mutuelle et constitue un bon moyen de constituer un pool plus important tout en partageant les risques et les avantages.

Défense contre les attaques de Sybil

Le mécanisme de mise en gage est conçu pour atténuer les attaques Sybil, qui pourraient théoriquement permettre de prendre le contrôle d’un réseau de preuve de participation sans fournir une participation personnelle significative. En rendant les pools avec des engagements plus élevés plus attrayants, de telles attaques sont évitées. La formule de gage est conçue pour qu’un pool avec un gage plus élevé produise des récompenses plus élevées et devienne ainsi plus attractif. Pour mener une attaque Sybil, un adversaire doit diviser son gage entre un grand nombre de pools. Étant donné que cela diluera chaque engagement de pool, les délégants seront motivés par le mécanisme de récompenses pour redéléguer à des pools non contradictoires.

Source : https://docs.cardano.org/development-guidelines/operating-a-stake-pool/about-stake-pools