serveurs<\/a> c'est en soi une t\u00e2che difficile, et la blockchain doit \u00eatre lanc\u00e9e gr\u00e2ce aux efforts de participants loyaux mais ind\u00e9pendants. Et, alors que dans une entreprise, lors du lancement, les administrateurs ont un acc\u00e8s complet \u00e0 toutes les machines, journaux, surveillance centrale, les validateurs ne laisseront personne acc\u00e9der \u00e0 leurs serveurs et, tr\u00e8s probablement, pr\u00e9f\u00e9reront construire leur propre infrastructure, car elle contr\u00f4le l'acc\u00e8s aux principaux actifs du validateurs \u2014 les staking votes. Ce comportement permet de construire des r\u00e9seaux s\u00e9curis\u00e9s et distribu\u00e9s \u2014 l'ind\u00e9pendance des fournisseurs de cloud utilis\u00e9s, des serveurs virtuels et \u00ab baremetal \u00bb, diff\u00e9rents syst\u00e8mes d'exploitation, tout cela rend les attaques contre ce r\u00e9seau extr\u00eamement inefficaces \u2014 trop de logiciels vari\u00e9s sont utilis\u00e9s. Par exemple, Ethereum utilise deux principales impl\u00e9mentations de n\u0153uds, en Go et en Rust, et une attaque efficace contre une impl\u00e9mentation ne fonctionne pas pour l'autre.<\/p>\n<\/p>\n
Par cons\u00e9quent, tous les processus de lancement et d'exploitation des blockchains doivent \u00eatre organis\u00e9s de mani\u00e8re \u00e0 ce que tout validateur, ou m\u00eame un petit groupe de validateurs, puisse \u00e0 tout moment jeter ses ordinateurs par la fen\u00eatre et partir, sans que rien ne se casse, et les validateurs restants doivent continuer \u00e0 maintenir efficacement le r\u00e9seau et \u00e0 connecter de nouveaux validateurs. Lors du lancement du r\u00e9seau, lorsque l'un des validateurs est en Europe, un autre en Am\u00e9rique du Sud, et le troisi\u00e8me en Asie, il est assez difficile d'obtenir un fonctionnement coh\u00e9rent de plusieurs dizaines de groupes ind\u00e9pendants et de les int\u00e9resser au r\u00e9sultat. <\/p>\n
<\/p>\n
Validateurs<\/h2>\n <\/p>\n
Imaginons le lancement d'une hypoth\u00e9tique blockchain moderne (la majeure partie de ce qui est d\u00e9crit s'applique aux blockchains bas\u00e9es sur toute famille de blockchains moderne : Ethereum, EOS, Polkadot, Cosmos, etc., qui pr\u00e9voient un consensus proof-of-stake. Les principaux acteurs de telles blockchains sont des \u00e9quipes de validateurs, qui installent leurs propres serveurs ind\u00e9pendants, valident et produisent de nouveaux blocs, et re\u00e7oivent les r\u00e9compenses pr\u00e9vues par le r\u00e9seau pour ceux qui participent au consensus. Pour lancer de nouveaux r\u00e9seaux, plusieurs dizaines de validateurs sont n\u00e9cessaires (c'est le nombre qu'il faut actuellement pour atteindre plus ou moins efficacement le consensus en quelques secondes), c'est pourquoi le projet annonce une inscription, au cours de laquelle les validateurs partagent des informations publiques sur eux-m\u00eames avec les utilisateurs, les convainquant qu'ils vont fournir un service de qualit\u00e9 au r\u00e9seau en cours de lancement.<\/p>\n
<\/p>\n
La validation est un m\u00e9tier qui permet d'\u00e9valuer tr\u00e8s pr\u00e9cis\u00e9ment le revenu potentiel d'un validateur, de transf\u00e9rer rapidement des capacit\u00e9s entre des projets, et en cas de succ\u00e8s du r\u00e9seau choisi, le validateur peut, en tant que participant \u00e0 part enti\u00e8re d'une DAO et responsable, d\u00e9velopper le projet, ou simplement fournir un excellent service technique pour des fonds compl\u00e8tement transparents et honn\u00eatement gagn\u00e9s. Lors du calcul des r\u00e9compenses pour les validateurs, les projets essaient de tenir compte des d\u00e9penses des validateurs et de faire en sorte que la r\u00e9compense pour les blocs soit telle que cette activit\u00e9 soit rentable, tout en \u00e9vitant que les validateurs ne saccagent l'\u00e9conomie en les inondant d'argent et en privant les autres utilisateurs du r\u00e9seau.<\/p>\n
<\/p>\n
Les validateurs d'entreprise n\u00e9cessitent une haute r\u00e9silience des services, ce qui implique un niveau \u00e9lev\u00e9 de pr\u00e9paration des d\u00e9veloppeurs et des devops ainsi que des ressources informatiques co\u00fbteuses. M\u00eame sans n\u00e9cessit\u00e9 de miner des hashs dans les r\u00e9seaux proof-of-work, un n\u0153ud blockchain est un grand service consommant beaucoup de m\u00e9moire, n\u00e9cessitant de nombreux calculs, validant, enregistrant sur disque et transf\u00e9rant de gros volumes de donn\u00e9es sur le r\u00e9seau. Pour stocker le journal des transactions et les cha\u00eenes de blocs d'une blockchain avec plusieurs milliers de petites transactions par bloc, un espace de stockage d'au moins 50 Go est actuellement requis, et pour les blocs, cela doit \u00eatre un SSD. La base de donn\u00e9es d'\u00e9tat des blockchains avec prise en charge des contrats intelligents peut d\u00e9j\u00e0 d\u00e9passer 64 Go de RAM. Les serveurs avec les caract\u00e9ristiques requises sont assez co\u00fbteux, un n\u0153ud Ethereum ou EOS peut co\u00fbter entre 100 et 200 $\/mois. Ajoutez \u00e0 cela l'augmentation des salaires pour le travail 24 heures sur 24 des d\u00e9veloppeurs et des devops, qui r\u00e9solvent les probl\u00e8mes m\u00eame la nuit lors du lancement, car certains validateurs peuvent facilement \u00eatre dans l'h\u00e9misph\u00e8re oppos\u00e9. Cependant, \u00e0 certains moments propices, d\u00e9tenir un n\u0153ud validateur peut g\u00e9n\u00e9rer un revenu s\u00e9rieux (dans le cas d'EOS, jusqu'\u00e0 10 000 $ par jour).<\/p>\n
<\/p>\n
La validation n'est qu'un des nouveaux r\u00f4les informatiques potentiels pour les entrepreneurs et les entreprises, au fur et \u00e0 mesure que les programmeurs inventent des algorithmes de plus en plus sophistiqu\u00e9s. Ces algorithmes permettent de r\u00e9compenser l'honn\u00eatet\u00e9 et de punir la tromperie et le vol, et ouvrent la voie \u00e0 des services exer\u00e7ant des fonctions de publication de donn\u00e9es importantes (oracles), de surveillance (coupure de d\u00e9p\u00f4ts et punition des fraudeurs par la publication de preuves de fraude), de r\u00e9solution de litiges, d'assurances et d'options. M\u00eame la collecte des d\u00e9chets repr\u00e9sente un march\u00e9 potentiel important dans les syst\u00e8mes de contrats intelligents, o\u00f9 il est n\u00e9cessaire de payer pour le stockage des donn\u00e9es. <\/p>\n
<\/p>\n
Probl\u00e8mes de d\u00e9marrage de la blockchain<\/h2>\n <\/p>\n
La transparence de la blockchain, qui permet une participation libre au r\u00e9seau d'ordinateurs de divers pays et la simplicit\u00e9 de connexion de n'importe quel script kiddie suivant un guide sur GitHub, n'est pas toujours un avantage. La course pour un nouveau token pousse souvent les validateurs \u00e0 \"miner une nouvelle pi\u00e8ce au lancement\", dans l'espoir d'une hausse de sa valeur et de la possibilit\u00e9 de vendre rapidement les gains. Cela signifie \u00e9galement que votre validateur peut \u00eatre n'importe qui, m\u00eame anonyme, et qu'il peut \u00eatre vot\u00e9 comme les autres validateurs (bien qu'il soit difficile pour un anonyme de recueillir des voix de stakers, laissons donc les contes effrayants sur les cryptomonnaies anonymes aux politiciens). N\u00e9anmoins<\/p>\n
<\/p>\n
L'\u00e9quipe du projet a pour mission de recruter ceux qui peuvent garantir un fonctionnement stable des n\u0153uds \u00e0 l'avenir, qui comprennent la s\u00e9curit\u00e9, qui peuvent r\u00e9soudre rapidement des probl\u00e8mes, coop\u00e9rer avec d'autres validateurs et agir ensemble \u2014 la qualit\u00e9 du token dans lequel les participants du r\u00e9seau souhaitent investir leur temps et leurs ressources d\u00e9pend enti\u00e8rement de ces comp\u00e9tences. Les fondateurs \u00e9clair\u00e9s, \u00e9valuant les risques, savent bien qu'au lancement d'un logiciel d'une telle ampleur, il faudra in\u00e9vitablement faire face \u00e0 des erreurs de code, de configuration des n\u0153uds, et que la stabilit\u00e9 du r\u00e9seau d\u00e9pend de la mani\u00e8re dont d\u00e9veloppeurs et validateurs r\u00e9soudront ensemble ces probl\u00e8mes.<\/p>\n
<\/p>\n
L'\u00e9quipe est pr\u00eate \u00e0 voter dans le mainnet pour tout validateurs, mais encore faudrait-il savoir lesquels, qui sont les bons ? Ceux avec le plus grand portefeuille ? M\u00eame cela n'est presque le cas de personne. D'apr\u00e8s les profils d'\u00e9quipe sur Linkedin ? Les DevOps et les experts en s\u00e9curit\u00e9 ne vont pas vous fournir de profils sur Linkedin. D'apr\u00e8s les d\u00e9clarations dans le chat, les posts et l'aide apport\u00e9e \u00e0 d'autres lors de la phase de pr\u00e9paration ? C'est bien, mais subjectif et inexact.<\/p>\n
<\/p>\n
Dans de telles conditions, il ne reste qu'une chose \u2014 trouver une solution qui r\u00e9sout les probl\u00e8mes de tous \u2014 un jeu, o\u00f9 il sera possible de s\u00e9lectionner les meilleurs validateurs, mais surtout \u2014 tester la blockchain en profondeur et r\u00e9aliser un test complet de la blockchain dans des conditions d'utilisation active, avec des changements de consensus, ainsi que la survenue et la correction d'erreurs. Pour la premi\u00e8re fois, cette proc\u00e9dure a \u00e9t\u00e9 propos\u00e9e comme un jeu par des membres du projet Cosmos, et cette id\u00e9e est sans aucun doute une excellente fa\u00e7on de pr\u00e9parer le r\u00e9seau au lancement d'un mainnet fiable et r\u00e9silient.<\/p>\n
<\/p>\n
Jeu des Validateurs<\/h2>\n <\/p>\n
Je vais d\u00e9crire le jeu des validateurs tel que nous l'avons con\u00e7u pour la blockchain DAO.Casino (DAOBet), bas\u00e9e sur un fork d'EOS appel\u00e9 Haya, qui poss\u00e8de un m\u00e9canisme de governance similaire \u2014 les validateurs sont \u00e9lus par vote de n'importe quel compte, o\u00f9 une partie du solde utilis\u00e9 pour voter pour un validateur est gel\u00e9e. Tout compte d\u00e9tenant le jeton principal BET peut voter pour le validateur choisi avec n'importe quelle partie de son solde. Les voix sont additionn\u00e9es et un classement des validateurs est \u00e9tabli. Dans diff\u00e9rentes blockchains, ce processus est organis\u00e9 diff\u00e9remment, et c'est g\u00e9n\u00e9ralement dans cette partie que la nouvelle blockchain diff\u00e8re de la blockchain parente. Il est \u00e0 noter que dans notre cas, EOS respecte pleinement son appellation d'\"OS\", car nous utilisons effectivement EOS comme syst\u00e8me d'exploitation de base pour d\u00e9ployer une version modifi\u00e9e de la blockchain destin\u00e9e aux besoins de DAOBet.<\/p>\n
<\/p>\n
Je vais d\u00e9crire des probl\u00e8mes sp\u00e9cifiques et comment les r\u00e9soudre dans le cadre du jeu. Imaginons un r\u00e9seau o\u00f9 ton serveur peut \u00eatre ouvertement attaqu\u00e9, o\u00f9 pour maintenir la position de validateur, il faut interagir en permanence avec le r\u00e9seau, promouvoir son validateur et s'assurer qu'il produit des blocs et qu'ils sont livr\u00e9s \u00e0 temps aux autres validateurs, sinon, le validateur sera exclu de la liste.<\/p>\n
<\/p>\n
Comment choisir les meilleurs gagnants?<\/h3>\n <\/p>\n
L'exigence technique principale pour le jeu est que ses r\u00e9sultats doivent \u00eatre v\u00e9rifiables publiquement. Cela signifie que les r\u00e9sultats du jeu : le classement des meilleurs gagnants, doivent \u00eatre \u00e9tablis strictement sur la base de donn\u00e9es que tout participant peut v\u00e9rifier. Dans un syst\u00e8me centralis\u00e9, nous pourrions mesurer le \"uptime\" de chaque validateur et r\u00e9compenser ceux qui \u00e9taient le plus en ligne ou qui ont trait\u00e9 le maximum de trafic r\u00e9seau. On pourrait recueillir des donn\u00e9es sur l'utilisation du processeur, de la m\u00e9moire et r\u00e9compenser ceux qui ont travaill\u00e9 efficacement. Mais toute collecte de ce type de m\u00e9triques implique l'existence d'un centre de collecte, et de plus, toutes les n\u0153uds sont ind\u00e9pendants et peuvent se comporter comme ils le souhaitent et envoyer n'importe quelles donn\u00e9es.<\/p>\n
<\/p>\n
Ainsi, la solution naturelle est de d\u00e9terminer les gagnants sur la base des donn\u00e9es de la blockchain, car elle permet de voir quel validateur a produit quel bloc et quelles transactions ont \u00e9t\u00e9 incluses. Nous avons nomm\u00e9 ce chiffre les Points Validateur (VP), et leur accumulation est l'objectif principal des validateurs dans le jeu. Dans notre cas, la m\u00e9trique la plus simple, facilement v\u00e9rifiable publiquement et efficace pour mesurer 'l'utilit\u00e9' d'un validateur est VP = nombre_de_blogs_produits_par_le_validateur pendant une p\u00e9riode donn\u00e9e.<\/p>\n
<\/p>\n
Ce choix simple est d\u00fb au fait que la gouvernance dans EOS pr\u00e9voit d\u00e9j\u00e0 de nombreux probl\u00e8mes potentiels, \u00e9tant donn\u00e9 qu'EOS est l'h\u00e9ritier de trois g\u00e9n\u00e9rations de blockchains op\u00e9rationnelles avec une grande exp\u00e9rience en gestion complexe de r\u00e9seau. Pratiquement tous les probl\u00e8mes d'un validateur li\u00e9s au r\u00e9seau, au processeur ou au disque ne conduisent qu'\u00e0 un seul probl\u00e8me : il signe moins de blocs, re\u00e7oit moins de r\u00e9mun\u00e9ration pour son travail, ce qui nous ram\u00e8ne simplement au nombre de blocs sign\u00e9s \u2014 pour EOS, c'est une option excellente et simple.<\/p>\n
<\/p>\n
Pour d'autres blockchains, la m\u00e9thode de calcul des Points Validateur peut diff\u00e9rer ; par exemple, pour les consensus bas\u00e9s sur pBFT (Tendermint \/ Cosmos, le consensus Aura de Parity Substrate), o\u00f9 chaque bloc doit \u00eatre sign\u00e9 par de nombreux validateurs, il est judicieux de compter les signatures individuelles des validateurs, plut\u00f4t que les blocs. Il peut \u00e9galement \u00eatre pertinent de prendre en compte les tours de consensus non termin\u00e9s, qui consomment les ressources d'autres validateurs ; en g\u00e9n\u00e9ral, cela d\u00e9pend fortement du type de consensus. <\/p>\n
<\/p>\n
Comment mod\u00e9liser les conditions r\u00e9elles d'exploitation<\/h3>\n <\/p>\n
La t\u00e2che des fondateurs est de v\u00e9rifier les validateurs dans des conditions proches de la r\u00e9alit\u00e9, tout en n'ayant aucun contr\u00f4le centralis\u00e9. Ce probl\u00e8me peut \u00eatre r\u00e9solu gr\u00e2ce \u00e0 un contrat de faucet qui distribue des quantit\u00e9s \u00e9gales du token principal aux validateurs et \u00e0 tous ceux qui le souhaitent. Pour obtenir des tokens sur le solde, il est n\u00e9cessaire de former une transaction et de faire en sorte que le r\u00e9seau l'inclue dans un bloc. Ainsi, pour qu'un validateur puisse gagner, il doit constamment alimenter son solde avec de nouveaux tokens et voter pour lui-m\u00eame, le propulsant ainsi dans le haut du classement. Cette activit\u00e9 cr\u00e9e une charge constante sur le r\u00e9seau, et les param\u00e8tres peuvent \u00eatre ajust\u00e9s pour que le flux de requ\u00eates soit suffisamment important pour un test complet du r\u00e9seau. Il est donc important de planifier le contrat de faucet \u00e0 l'avance, en tant qu'outil essentiel pour le lancement du r\u00e9seau, et de commencer \u00e0 ajuster ses param\u00e8tres rapidement.<\/p>\n
<\/p>\n
La demande de tokens via le faucet et le vote des validateurs n'\u00e9mule pas compl\u00e8tement de mani\u00e8re \u00e9quitable le fonctionnement de la blockchain, en particulier dans des modes tr\u00e8s congestionn\u00e9s. Par cons\u00e9quent, l'\u00e9quipe de la blockchain devra in\u00e9vitablement r\u00e9diger des benchmarks suppl\u00e9mentaires permettant de solliciter le r\u00e9seau. Des contrats intelligents sp\u00e9cialement cr\u00e9\u00e9s \u00e0 l'avance jouent un r\u00f4le essentiel dans ce processus, permettant de tester des sous-syst\u00e8mes sp\u00e9cifiques. Pour tester le stockage, le contrat enregistre des donn\u00e9es al\u00e9atoires dans la blockchain, et pour v\u00e9rifier les ressources r\u00e9seau, le contrat de test exige un grand volume de donn\u00e9es d'entr\u00e9e, augmentant ainsi le volume des transactions \u2013 en lan\u00e7ant un flux de telles transactions \u00e0 des moments al\u00e9atoires, l'\u00e9quipe teste simultan\u00e9ment la stabilit\u00e9 du code et la r\u00e9silience des validateurs.<\/p>\n
<\/p>\n
Une question distincte concerne la mise \u00e0 jour du code des n\u0153uds et la r\u00e9alisation de hard forks. Il est n\u00e9cessaire que, en cas de bugs, de vuln\u00e9rabilit\u00e9s ou de collusion de validateurs malveillants, les validateurs aient un plan d'action d\u00e9j\u00e0 \u00e9tabli dans le cadre du jeu des validateurs. On peut envisager des sch\u00e9mas d'attribution de VP pour une mise en \u0153uvre rapide du hard fork, par exemple en p\u00e9nalisant tous les validateurs qui n'ont pas encore impl\u00e9ment\u00e9 la nouvelle version du code du n\u0153ud, mais cela est complexe \u00e0 r\u00e9aliser et rend le calcul plus difficile. Simuler une situation d'urgence n\u00e9cessitant un hard fork peut \u00eatre fait en<\/p>\n
<\/p>\n
<\/p>\n
Malgr\u00e9 la m\u00e9fiance entre les validateurs, il est b\u00e9n\u00e9fique pour tous d'obtenir des informations \u00e0 jour sur l'\u00e9tat du r\u00e9seau en temps opportun afin de prendre des d\u00e9cisions plus rapidement. C'est pourquoi l'\u00e9quipe du projet met en place un service de collecte et de visualisation de plusieurs m\u00e9triques des serveurs des validateurs, permettant de voir la situation simultan\u00e9ment pour l'ensemble du r\u00e9seau, facilitant ainsi la d\u00e9termination rapide de ce qui se passe. De plus, il est avantageux tant pour les validateurs que pour le projet que l'\u00e9quipe corrige rapidement les erreurs d\u00e9tect\u00e9es. Ainsi, en plus de la collecte des m\u00e9triques, il est pertinent de lancer imm\u00e9diatement la collecte des journaux et des donn\u00e9es d'erreur depuis les machines des validateurs vers une machine accessible aux d\u00e9veloppeurs de la blockchain. Ici, personne n'a int\u00e9r\u00eat \u00e0 d\u00e9former l'information, donc ces services sont mis en place par l'\u00e9quipe du projet et ils sont dignes de confiance. Il est judicieux de collecter des m\u00e9triques syst\u00e8me des validateurs et, obligatoirement, les m\u00e9triques les plus importantes de la blockchain elle-m\u00eame \u2014 pour DAOBet, il s'agit du temps de finalisation et du retard du dernier bloc finalis\u00e9. Gr\u00e2ce \u00e0 cela, l'\u00e9quipe peut observer l'augmentation de la consommation de m\u00e9moire sur les n\u0153uds lors de l'ex\u00e9cution d'un benchmark, ainsi que les probl\u00e8mes rencontr\u00e9s par certains validateurs. <\/p>\n
<\/p>\n
Points importants concernant la r\u00e9alisation du jeu des validateurs<\/h2>\n <\/p>\n
Il s'av\u00e8re que si vous souhaitez autoriser officiellement les validateurs \u00e0 attaquer les machines les unes les autres (officieusement, ils peuvent d\u00e9j\u00e0 le faire) - il faut le formuler l\u00e9galement comme un test de s\u00e9curit\u00e9, car selon la l\u00e9gislation de certains pays, des sanctions peuvent \u00eatre appliqu\u00e9es pour DDoS ou attaques r\u00e9seau. Une autre question importante est de savoir comment r\u00e9compenser les validateurs. Les r\u00e9compenses naturelles sont des tokens du projet, qui seront transf\u00e9r\u00e9s sur le mainnet, mais une distribution massive de tokens \u00e0 quiconque a r\u00e9ussi \u00e0 lancer un n\u0153ud n'est pas non plus la meilleure option. Il est probable que vous deviez \u00e9quilibrer entre deux options extr\u00eames :<\/p>\n
<\/p>\n
Distribuer l'ensemble du fonds de r\u00e9compenses en fonction des VP gagn\u00e9s
<\/p>\n
Distribuer le fonds de r\u00e9compenses aux validateurs top-N en fonction des r\u00e9sultats du jeu
<\/p>\n
\u00c0 vous de d\u00e9cider quelle option privil\u00e9gier <\/p>\n
<\/p>\n
Il y a aussi un autre point - il n'est pas du tout s\u00fbr que des dizaines de validateurs se pr\u00e9cipiteront pour participer \u00e0 votre appel, et parmi ceux qui d\u00e9cideront d'essayer, tous ne pourront m\u00eame pas installer et lancer un n\u0153ud - g\u00e9n\u00e9ralement, \u00e0 ce stade, les projets ont une documentation assez pauvre, des erreurs peuvent se produire, et les d\u00e9veloppeurs d\u00e9bord\u00e9s r\u00e9pondent aux questions sans grande r\u00e9activit\u00e9. Par cons\u00e9quent, avant de lancer le jeu, il faut \u00e9galement pr\u00e9voir des actions au cas o\u00f9 le nombre requis de validateurs ne serait pas atteint. Dans ce cas, au d\u00e9but du jeu, les validateurs manquants sont lanc\u00e9s par l'\u00e9quipe du projet, participent au consensus, mais ne peuvent pas \u00eatre des gagnants.<\/p>\n
<\/p>\n
Conclusion<\/h2>\n <\/p>\n
En conclusion, j'ai essay\u00e9 de rassembler dans ce qui pr\u00e9c\u00e8de une liste de ce qu'il faut imaginer, faire et lancer pour un d\u00e9roulement efficace du jeu des validateurs<\/p>\n
<\/p>\n
Que faut-il faire pour lancer un v\u00e9ritable jeu de validateurs :
<\/p>\n
\ncr\u00e9er et d\u00e9ployer une interface web et fournir une CLI pour voter pour les validateurs<\/li>\n S'assurer que les m\u00e9triques de n\u0153uds de validateurs actifs peuvent \u00eatre envoy\u00e9es \u00e0 un service centralis\u00e9 (par exemple, Prometheus)<\/li>\n D\u00e9ployer un serveur de collecte de m\u00e9triques (Prometheus + Grafana) pour le jeu des validateurs<\/li>\n Trouver comment les points de validateur (VP) seront calcul\u00e9s<\/li>\n D\u00e9velopper un script public pour calculer les VP d'un valideur \u00e0 partir des donn\u00e9es de la blockchain<\/li>\n D\u00e9velopper une interface web pour afficher le top des validateurs et l'\u00e9tat du jeu des validateurs (combien de temps reste jusqu'\u00e0 la fin, combien de VP pour chacun, etc.)<\/li>\n D\u00e9velopper et automatiser le lancement d'un nombre arbitraire de n\u0153uds propres, concevoir le processus de connexion des validateurs au jeu (quand et comment d\u00e9sactiver ses n\u0153uds, voter pour eux et retirer les votes)<\/li>\n Calculer combien de jetons doivent \u00eatre \u00e9mis et d\u00e9velopper un contrat-faucet<\/li>\n Cr\u00e9er un script de benchmark (transferts de jetons, utilisation massive de stockage, utilisation massive du r\u00e9seau) <\/li>\n Rassembler tous les participants dans un seul chat pour une communication rapide<\/li>\n Lancer la blockchain un peu avant le d\u00e9but du jeu<\/li>\n Attendre le bloc de d\u00e9part, commencer le jeu<\/li>\n Tester le r\u00e9seau avec plusieurs types de transactions<\/li>\n Appliquer un hard fork<\/li>\n Modifier la liste des validateurs<\/li>\n R\u00e9p\u00e9ter les points 13, 14 et 15 dans un ordre diff\u00e9rent, tout en maintenant la stabilit\u00e9 du r\u00e9seau<\/li>\n Attendre le bloc final, terminer le jeu, calculer les VP<\/li>\n<\/ul>\n<\/p>\n
Il faut dire que le jeu des validateurs est une histoire nouvelle, et n'a \u00e9t\u00e9 organis\u00e9 que quelques fois, donc il ne faut pas consid\u00e9rer ce texte comme un guide complet. Il n'existe pas d'analogue dans le secteur IT moderne \u2014 imaginez que les banques, avant de lancer un syst\u00e8me de paiement, rivalisent pour voir qui r\u00e9ussira le mieux \u00e0 traiter les transactions des clients. Les approches traditionnelles ne vous aideront probablement pas \u00e0 cr\u00e9er de grands r\u00e9seaux d\u00e9centralis\u00e9s, alors adoptez de nouveaux mod\u00e8les commerciaux, organisez vos propres jeux, identifiez les m\u00e9ritants, r\u00e9compensez-les et laissez vos syst\u00e8mes distribu\u00e9s fonctionner rapidement et de mani\u00e8re stable.<\/p>\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0418\u0442\u0430\u043a, \u0432\u0430\u0448\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430 \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0430 alpha-\u0432\u0435\u0440\u0441\u0438\u044e \u0432\u0430\u0448\u0435\u0433\u043e \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430, \u0438 \u043f\u0440\u0438\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c testnet, \u0430 \u0437\u0430\u0442\u0435\u043c \u0438 mainnet. \u0423 \u0432\u0430\u0441 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0439 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d, \u0441 \u043d\u0435\u0437\u0430\u0432\u0438\u0441\u0438\u043c\u044b\u043c\u0438 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u0445\u043e\u0440\u043e\u0448\u0435\u0439 \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u044c\u044e, \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c\u044e, \u0432\u044b \u0441\u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 governance \u0438 \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0440\u0430 \u0431\u044b \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u044d\u0442\u043e \u0432 \u0434\u0435\u043b\u0435. \u0412 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u043a\u0440\u0438\u043f\u0442\u043e\u0430\u043d\u0430\u0440\u0445\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u043c\u0438\u0440\u0435, \u0432\u044b \u0432\u044b\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u0435\u0442\u0435 \u0432 \u0441\u0435\u0442\u044c genesis block, \u043e\u043a\u043e\u043d\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u0434 \u043d\u043e\u0434\u044b \u0438 \u0432\u0430\u043b\u0438\u0434\u0430\u0442\u043e\u0440\u044b \u0441\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39478","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t