L'intérêt actif pour l'ICO de Polybe que nous avons activement alimenté a été un succès retentissant - cette fois presque au sens littéral du terme. Stupéfait de l'attention de 14 000 personnes venues acheter nos tokens dans les premières minutes après le lancement des ventes, le site Polybius s'est effondré. Et ce n'était que le début. Comme promis, nous racontons ce qui s'est passé le 31 mai et ce que nous pourrions faire de mieux pour éviter ce qui s'est passé.
Bien sûr, au début de l'ICO, nous étions prêts pour les attaques DDoS et la charge élevée sur les serveurs, cependant, nous admettons, nous avons simplement sous-estimé les capacités des pirates malveillants et le degré d'intérêt pour le projet, ainsi que la probabilité de situations d'urgence.
La plate-forme technique (bureau des investisseurs, toutes les infrastructures) de Polybius ICO a été fournie par Ambisafe. En commençant par le développement de produits blockchain, l'entreprise a progressivement étendu ses intérêts pour fournir aux entreprises un ensemble de services et d'outils nécessaires à la réalisation des ICO. En choisissant un entrepreneur expérimenté, nous nous sommes entièrement appuyés sur leurs connaissances et leurs compétences, sans contrôler à nouveau les choses que nous pourrions (et devrions!) Contrôler. Et ce fut notre première erreur.
Fer trop faible
Une bonne alimentation du serveur est un détail essentiel si vous ne voulez pas que le site tombe en panne au début des ventes. Prédisant la charge possible sur le serveur dans les premières heures de l'ICO, le contractant nous a fourni des exigences quant à leur capacité, mais même alors, nous avons suggéré que ces indicateurs pourraient ne pas être suffisants et doublé les performances. Pour partager la charge entre les serveurs, nous avons également localisé le bureau de l'utilisateur et le site Polybius lui-même à différents endroits, mais nous n'avons pas séparé la base de données et les fichiers CAB principaux. Et c'était l'erreur numéro deux.
La base de données a souffert chaque fois que trop de demandes sont venues au bureau de l’investisseur (et vice versa), et le serveur est tombé en panne, devenant périodiquement indisponible. Lorsque le problème est devenu apparent, nous avons augmenté la capacité du serveur de près de 10 fois par rapport aux caractéristiques d'origine. Cependant, il a fallu du temps pour reconfigurer l'armoire et télécharger à nouveau tous les fichiers sur les nouveaux serveurs.
L'excitation autour du début de l'ICO Polybius était si forte que dès que le compte à rebours sur le site polybius.io a atteint zéro, des foules d'utilisateurs se sont précipités pour acheter des jetons, et certains de nos utilisateurs ont même réussi à prendre un faux départ. Le battage médiatique de la part des vrais utilisateurs n'est pas un gros problème. Le problème était l'attention accrue portée à Polybius ICO par les robots - une attaque DDoS a commencé. En environ 6 heures, environ 30 millions de demandes ont été déposées par des dépositaires sur le compte personnel de l'investisseur, qui s'est simplement noyé en eux. La situation a été aggravée par le fait que les premières heures ont été doublement difficiles à combattre les trafics malveillants - il n'était pas toujours clair qu'il s'agit d'une vraie personne assise et appuie sur «Actualiser» dans l'espoir de voir son compte personnel, ou est-ce un bot qui fait de même.
Puisqu'il y avait beaucoup de gens qui voulaient participer au début, ils se sont constamment rendus sur le site via DDoS et ont continué à acheter des jetons lorsque le site est devenu plus facile. En conséquence, le système a accumulé un grand nombre de transactions qui n'ont pas été achevées à temps et bloquées à l'intérieur. Et nous passons ici sans heurts à un autre problème qui, pour des raisons évidentes, a surtout inquiété les participants au financement participatif.
Congestion du réseau
Étant donné que le système dans lequel les transactions ont eu lieu était volumineux et multi-modules, chaque opération devait suivre un itinéraire clair. En raison d'une attaque DDoS à certains endroits du système, les modules ont commencé à ralentir.Par conséquent, en filtrant le trafic malveillant, nous avons dû trier manuellement les transactions bloquées dans le système. Mais même après avoir repoussé les opérations bloquées, nous n'avons pas pu garantir la réception en temps voulu des jetons achetés en raison de l'obstruction survenue sur le réseau Ethereum. C'était une situation d'urgence qui a créé une panique et une vague de commentaires du type «L'
argent m'a été retiré, mais les jetons n'ont pas été facturés. Cela fait déjà une demi-heure / heure / 5 heures ... »Maintenant que les jetons ont été accumulés depuis longtemps à tous les investisseurs concernés, nous n'avons plus qu'à nous excuser une fois de plus pour la situation qui s'est produite et expliquer la cause.
Au moment du lancement de Polybius ICO, une autre grande ICO (BAT -
BasicAttentionToken ) a eu lieu sur la blockchain du réseau Ethereum, et la concurrence entre les investisseurs a entraîné une congestion du réseau. Pour comprendre ceux de nos lecteurs qui ne connaissent pas grand-chose à Ethereum, le réseau fonctionne de telle manière que pour lui envoyer une transaction, vous devez payer une commission. Et plus la commission est élevée, plus la transaction pénètre rapidement dans le réseau. Dans le contexte de la deuxième ICO, dont les participants ont commencé à établir d'énormes commissions, les transactions de Polybius avec la commission optimale en termes de ratio de coût et de temps de confirmation ont cessé d'être confirmées et se sont alignées dans le réseau Ethereum, cette fois coincé quelque part à la frontière entre notre système et blockchain.
Pour effectuer non pas un seul, mais un ensemble de transactions dans Ethereum, comme c'était le cas dans notre cas, elles doivent être mises en file d'attente en attribuant un numéro de série (conditionnel) à chaque transaction. Les numéros de séquence doivent être en incrément absolu - c'est-à-dire que chaque transaction suivante doit avoir un numéro un supérieur à la précédente. Cela signifie que nous ne pouvons pas envoyer la transaction numéro 10 au réseau avant que les neuf premiers soient traités. Afin de ne pas charger encore plus le réseau et de ne pas augmenter le nombre de transactions bloquées, nous avons été obligés d'augmenter la commission pour toutes les nouvelles commandes - les nouvelles transactions ont commencé à être confirmées normalement et dans un délai plus acceptable. Les toutes premières transactions (nous parlons d'un grand nombre d'ordres - plus d'un millier) ont dû être laissées «en l'état», donc plusieurs jours se sont écoulés avant que les premiers investisseurs ne puissent obtenir leurs jetons.
Il s'agit d'un comportement anormal du système et de la situation que nos prestataires ont dû résoudre pour la première fois, il est donc difficile de juger si les tactiques optimales ont été choisies, ou nous pourrions faire encore plus.
Qu'avons-nous appris
La compréhension la plus importante, sinon unique, est que lorsque le problème est déjà apparu, tout ce que vous pouvez faire est de commencer à le résoudre le plus rapidement possible. La première chose que nous avons faite a été d'augmenter les caractéristiques du serveur, d'utiliser un matériel plus puissant, de diffuser la base de données sur différents serveurs, de configurer un pare-feu et de filtrer les attaques DDoS. Et tous ces processus ont pris environ une journée. Du temps supplémentaire a été consacré à l'organisation du processus de transaction via Ethereum.
Maintenant que nous avons déjà une expérience ICO, nous pouvons affirmer avec certitude qu'il est impossible d'être trop prudent en la matière. Il vaut mieux être à nouveau en sécurité, donc si vous décidez soudainement de mener votre propre ICO, pensez immédiatement à ce qui suit:
- la charge dans les premières heures peut être juste hors échelle et dépasser même les attentes les plus folles;
- si votre projet est bien connu, alors l'attention des ddosers vous est garantie, alors prenez soin de vous protéger contre d'éventuelles attaques;
- si 10 autres ICO se déroulent simultanément avec les vôtres, il est préférable de passer du temps à réfléchir aux tactiques à choisir à l'avance - que ce soit pour attendre quelques jours lorsque les transactions se dérouleront d'une manière ou d'une autre, ou investir des ressources supplémentaires et forcer l'exécution d'ordres via le réseau;
- il vaut la peine d'accorder plus d'attention à l'information en temps opportun des investisseurs sur les problèmes qui se sont posés - cela contribuera certainement à réduire le nombre de demandes identiques d'assistance technique et à libérer ses ressources pour résoudre d'autres problèmes urgents.
Et, plus important encore, vous ne pourrez jamais prévoir tous les problèmes possibles, alors préparez-vous à toute surprise. Vous pouvez passer beaucoup de temps à compter les erreurs commises par oubli, mais ils apprennent des erreurs, et nous sommes heureux qu'ils ne soient pas devenus un obstacle sérieux à la réussite de notre campagne.