Dans les coulisses d'un producteur de blocs EOS
Dans les coulisses d'un producteurs de blocs EOS
En mai 2018, nous avons commencé à travailler sur notre infrastructure de production de blocs EOS. Nous étions engagés jour et nuit, en essayant de suivre le mouvement à l'échelle mondiale. Nous avons un peu honte de le dire, mais c'est grâce à plusieurs bouteilles de vin et de bière, de baguettes et de fromage que nous avons survécu !
Toute notre histoire a commencé à Paris en novembre 2017, avec BitConseil. Nous avons été étonnamment impressionnés par EOS et la vision de Dan Larimer. ADAPP, en tant que fournisseur d'infrastructure pour de nombreux nœuds blockchain, était prêt à fournir ce type de fondation. Nous avions parlé de la façon dont les smart contracts d'Ethereum peuvent assurer leur résiliation, grâce au mécanisme du gaz et à l'allocation des ressources sur ce réseau peer-to-peer ; mais surtout, nous avions parlé d'EOS comme d'un changement de paradigme dans l'univers des blockchains ouvertes. EOS introduit des concepts et des technologies qu'aucun autre projet (en production) ne traite : le langage Web Assembly (WASM), les contrats Ricardiens, une confirmation de bloc à faible latence...
Pouvoir interrompre un contrat intelligent ou n'importe quelle tâche en cas de mauvaise conduite, passivement, activement, ou même en passant par une forme de tribunal, est quelque chose d'intéressant. Lorsque les gens savent comment parvenir à un consensus explicite, ils veulent tromper le système. Si cela se produit par un manque de procédure (comme nous l'avons déjà vu), ou via des procédures qui ne sont pas directement sous contrôle, c'est plus difficile. La plupart des producteurs de blocs se concentrent sur la simplification de ces processus. C'est le paradoxe bien connu du "code qui fait loi", bien décrit par la question "est-ce que je laisse le code manipuler ceci ou non ?
Cette question nous amène à une autre encore plus intéressante. Comment gérons-nous les logiciels actuels ? Avec le style de fonctionnement quotidien du logiciel, vous pouvez interrompre, patcher ou mettre à jour, appliquer en direct ou définir une procédure pour améliorer un service. La direction et l'exécution dépendent de votre équipe de production. Avec le système de contrats intelligents d'Ethereum, vous ne pouvez pas mettre fin à un smart contract. Avec les smart contracts EOS, vous ne pouvez pas arrêter un SC tant que vous n'avez pas élu quelqu'un pouvant prendre position sur sa vivacité.
En introduisant cet aspect, si tous les acteurs qui gèrent les nœuds du réseau se connaissent eux-mêmes et ne sont pas uniformément répartis dans le monde, le projet se rapproche d'une base de données distribuée gérée par un administrateur, ou pire encore, un organe centralisé similaire à ce que l'on peut voir avec le SEPA européen sur Cassandra.
franceos est une sorte de nouveau-né pour le moment. Nous voulions construire une infrastructure de production de blocs : un acteur français pour exécuter des choix communautaires sur ce qui doit vivre sur EOS ou non.
En tant que candidat à la production de blocs, c'est notre rôle de décrire notre technologie, nos spécifications techniques, et de vous donner une meilleure compréhension de ce que nous faisons en tant que producteur de blocs.
SPÉCIFICATIONS TECHNIQUES AU DÉMARRAGE
Nous avons commencé à creuser le logiciel EOSIO, le dépôt du Jungle testnet, et le dépôt hkeos/bp_infrastructure. En se basant sur le travail effectué quant à la technologie LXC, nous avons décidé de creuser plus profondément et d'éviter de l'utiliser...
Nous étions admiratifs de ce beau projet d'automatisation : par exemple, des outils de sélection comme Wireguard (grâce au travail de Jason A.Donenfeld), et HAProxy (de la société française éponyme) que nous utilisions déjà quotidiennement. Nous avons également essayé Patroneos.
Par contre, nous avons préféré ne pas inclure MongoDB pour nos premiers pas.
CHOIX DU CLOUD
Tout d'abord, franceos s'appuie sur des serveurs dédiés. Comme EOS Canada, qui a un excellent partenariat avec Google, nous avons obtenu un excellent partenariat avec OVH, car l'une de nos équipes a travaillé sur des solutions d'équilibrage de charge pour cette entreprise. Nous savons qu'ils ne sont pas parfaits, comme tous les hébergeurs, mais le CTO d'OVH est transparent et très communicatif lorsqu'il doit expliquer les raisons des échecs, et a toujours d'excellents plans d'action pour ne jamais se retrouver dans la même situation. Nous ne pouvons pas dire cela pour AWS :-).
Deuxièmement, OVH n'est pas lié au Patriot Act, grâce à notre datacenter basé en France. OVH avait protégé WikiLeaks pendant son exil, jusqu'à ce que le gouvernement français mette la main dessus. Notre infrastructure EOS sera facilement gérée grâce à l'automatisation (nous automatisons tout ce que nous faisons). Les serveurs en cloud sont un investissement accessible pour nous, et comme nous automatisons tout, nous serons capables de passer rapidement de notre fournisseur à un autre, ou même de passer du cloud à une infrastructure bare metal très rapidement.
Si ce cloud ne fournit pas tout ce dont nous avons besoin pour le réseau EOS, nous sommes prêts à bouger.
LE POINT SUR LES SERVEURS
Techniquement, nous nous appuyons sur 5 serveurs dédiés (bare metal mais hébergés par OVH), 4 x 64 Go de RAM, et un serveur de 256 Go.
- Un serveur est dédié au peering et à l'API ;
- Un serveur est dédié au peering sécurisé ;
- Un serveur est dédié au peering et aux tests ;
- Deux serveurs (maître et esclave) sont dédiés à la production de blocs ;
- Les N petits serveurs sont dédiés au VPN, à la surveillance, aux alertes, à la gestion des accès, aux services de rapports EOS, à la construction automatique de nouvelles versions et à leurs déploiements.
Rien d'extraordinaire pour une infrastructure de producteur de blocs, mais c'est toujours mieux que rien. Nous avons également un nœud de peering Jungle testnet, sur le même serveur que notre serveur de sauvegarde. Et nous prévoyons toujours de construire notre propre infrastructure pendant cette période.
Dans notre hypothèse d'infrastructure, nous avions plusieurs points clés, auxquels nous savons que la crypto-communauté attache beaucoup d'importance. Mais d'abord, voyons comment les discussions sur le matériel sont sans fin.
LE POINT SUR LES SERVEURS "BARE METAL"
Habituellement, lorsque vous proposez une infrastructure en métal nu, vous devez considérer une infrastructure dédiée pure et simple. Un endroit sûr, connu sous le nom de centre de données, qui fournit l'infrastructure réseau et le matériel physique. Mais dès que vous utilisez cette infrastructure à l'échelle mondiale, vous devez introduire plusieurs couches de pare-feu et protéger votre FAI. Pour nous, s'appuyer sur une infrastructure unique est un point unique de défaillance pour un producteur de blocs.
L'argument de certains producteurs de blocs est bien connu dans la communauté : les serveurs ne devraient pas être hébergés par une société de cloud computing, car EOS doit rester indépendant et résilient en cas de censure. Grâce à cette philosophie, nous avons nos derniers gardiens, comme LibertyBlock. Ce n'est pas la première fois que nous entendons ces arguments : les communautés françaises et notre équipe doivent faire face à des politiques injustes, utiliser des outils de protection de la vie privée ciblés pour la respecter en profondeur (rappelez-vous des attaques sur ProtonMail). Mais faites-vous confiance à votre fournisseur d'équipement, comme HP ou Dell ? Faites-vous confiance à votre fournisseur d'électricité ?
Dans notre cahier des charges technique, nous avons également dû être vigilants sur le fait que les fournisseurs d'hébergement sont actuellement mieux équipés pour donner de fortes garanties de disponibilité, comme 99,98% sur les SLA, et des réseaux de classe mondiale, via des connexions à un grand nombre de FAI. Ils ont également des accords avec les fournisseurs d'électricité.
Nous avons constaté qu'avec nos ressources actuelles, la solution la plus pragmatique est d'avoir nos propres serveurs avec une solution d'hébergement. Mais nous prévoyons également d'installer des serveurs dans les montagnes suisses. Ce n'est pas un conte de fées, nous nous y sommes engagés depuis le début et nous sommes en train d'examiner différentes options.
VIRTUALISATION
En commençant par les machines virtuelles en 2000 (VMware, Citrix Xen, Redhat KVM), la virtualisation est aujourd'hui largement utilisée. Les avantages habituellement perçus par les sociétés de cloud computing étaient d'abstraire les ressources et de fournir un accès de type serveur à l'hôte partagé, avec des pénalités de performance dues à la virtualisation. Provenant de ces entreprises, beaucoup d'investissements sont venus sécuriser leur hyperviseur contre les attaquants, et maintenant la virtualisation est largement connue comme une solution sécurisée. En fait, avec la virtualisation, vous avez tendance à émuler un nouvel ordinateur, et comme nous l'avons dit plus tôt, vous vous protégez contre les hôtes compromis. C'est pourquoi il s'agit de notre troisième niveau de sécurité. Nous avons utilisé et testé des technologies de virtualisation largement connues, afin de fournir une sécurité suffisante.
CONTENEURS
En 2013, nous avons vu une autre adoption à grande échelle des conteneurs dans l'écosystème du cloud computing : c'est fortement lié à la société Docker. Docker partage plusieurs qualités avec LXC, mais plus de flexibilité en termes d'applications de gestion du cycle de vie. Les conteneurs ont commencé comme une technique introduite dans le noyau Linux pour mettre en boîte les ressources nécessaires à un processus. Inspiré, autant que je sache, par BSD Jails, une myriade d'outils sont entrés dans l'univers de Linux avec les namespaces, la gestion de réseau ou le sandboxing.
Deux aspects font maintenant partie du monde de la sécurité des conteneurs : les services de détection des mauvais comportements et les processus de filtrage syscall qui s'exécutent à l'intérieur du conteneur. Nous comptons sur la solution CoreOS (RKT) pour notre deuxième couche de sécurité.
PROCESSUS UNIX
Ce que nous appelons sécurité active consiste à travailler avec le daemon EOS, connu sous le nom de nodeos. Plus précisément, nous avons aujourd'hui des plugins producteurs dédiés au BP, un plugin chaîne qui fait tout le travail lié à la gestion de la blockchain, et un plugin "historique", qui traite des transactions et des actions. Nous devons détecter les comportements nouveaux ou inconnus du daemon et être prêts à réagir. Nous surveillons activement nos processus et sauvegardons quotidiennement notre historique. Faisant partie du JungleTestnet, nous testons les nouvelles versions et les déployons lorsque nous avons suffisamment confiance en la qualité des fichiers binaires.
Il s'agit du premier niveau de sécurité obligatoire.
API & BP JSON
Nous avons décidé de ne pas prendre la protection CloudFlare. Quand on y réfléchit, le CEO de cloudflare lui-même dit qu'il a trop de pouvoir sur Internet. Même s'il est de bonne foi, nous savons que la centralisation conduit à des décisions arbitraires et à d'éventuelles fuites. Nous utilisons le standard Let's Encrypt et prévoyons d'avoir notre propre certificat EV. Nous utilisons les anti-DDOS d'OVH. Les communautés locales utilisent nos terminaux API et nous voulons les améliorer avec de nouveaux appels, pour permettre plus de développements.
GESTION DES CLÉS
EOS est livré avec différents outils. Comme d'habitude dans les crypto-monnaies, vous avez des multi-signatures pour gérer ce type d'infrastructure, et partager la responsabilité entre toutes les personnes impliquées dans le projet. Grâce aux fonctionnalités d'EOS, comme les rôles et les autorisations sur le système de clés, nous avons développé notre propre processus de gestion des clés propriétaires, actives et signataires. Cese fonctionnalités sont déjà utilisées par notre équipe pour gérer les mises à jour et font partie de notre processus, lors du passage aux serveurs bare-metal en cas de mauvais événements.
En ce qui concerne le matériel et la sécurisation des clés de signature, nous avons examiné les modules HSM et Yubikey, mais nous considérons notre propre solution.
PLANIFIER L'IMPRÉVU
Et Spectre, Meltdown et toutes les futures attaques liées ? Nous considérons que les serveurs fonctionnant en front d'Internet avec des accès TCP/IP sont, de par leur conception, vulnérables et dangereux. Notre système est donc similaire à celui d'autres BP, avec un nœud de production de blocs totalement indépendant de sa connexion Internet. Nous utilisons largement le réseautage privé, et toutes les suggestions que nous recevons de notre communauté.
Les cygnes noirs et la planification de l'imprévu font partie de notre travail. Comme le décrit Nicholas Nassim Taleb, nous avons tendance à faire comme pour un avion. Nous avons commencé à définir une redondance de base de 3 partout. 3 BP avec une version séparée, 3+ pare-feux, 3+ pairs, 3+ IP, etc. Tout ceci a un coût, et nous sélectionnons ces couches de redondance une par une.
C'est même vrai pour le CPU ou la RAM, en tant que fournisseur de ressources à notre communauté, nous devons planifier la distribution des ressources. Vous avez peut-être lu cette histoire de mémoire Intel 3D connue sous le nom d'Optane : nous travaillons sur son utilisation dans EOS.
OUTILS
Dernièrement, nous avons introduit EOS Report afin de fournir à notre communauté d'excellentes idées et de l'information sur le réseau. Cet outil en est encore à ses débuts, mais nous voulons l'ouvrir de plus en plus. Nous voulons partager avec la communauté davantage de moyens pour mesurer les indicateurs de santé, de robustesse et de réactivité du réseau EOS.
Si vous voulez un producteur de blocs qui est humain, non lié à une plateforme d'échange, ou un jeton, ou de grosses baleines, avec qui vous pouvez échanger sur Telegram, et avec un peu de chance dans le monde réel, votez pour nous !
Plusieurs défis sont à venir. L'hiver arrive. Nous sommes toujours là, et nous sommes là pour rester !
L'équipe franceos