Polybius Bank의 ICO에서 발생한 DDoS공격, 그리고 ICO 운영에서의 주의사항 몇 가지

이 글은 폴리비우스 뱅크의 블로그에 7월 21일 포스팅된 'Technical problems, or what to consider if you have decided to run your own ICO'라는 글에 대한 번역 글입니다. 지난 진행된 폴리비우스 뱅크의 ICO에서의 여러가지 시행착오를 공유함으로써 이후에 진행될 다른 ICO에 참고가 되고자 작성된 글 인듯 합니다. 관심 있으신 분이 계실까하여 부족한 내공으로나마 번역하여 공유해봅니다.

Actively promoted by us Polybius’ ICO succeeded stunningly — and this time in a literal sense. Stunned by attention of 14,000 people … Polybius’ website went down. And that was just the beginning. As promised, what happened and what could be done better — in today’s article. Sure enough at the beginning of the ICO, we were ready for DDoS attacks and server overloads. However, frankly speaking, we underestimated not only abilities of nasty hackers and degree of interest in the project but also the potential for emergency situations.

폴리비우스의 ICO는 큰 성공을 거두었습니다. 그러나 14,000명의 참여자로 인해 폴리비우스의 웹사이트는 다운되고 말았습니다. 그리고 그것은 단지 시작에 불과했습니다. 약속한대로 그 때 우리에게 무슨일이 벌어졌고, 무엇을 더 잘할 수 있었는지 오늘의 글에 담아보고자 합니다. ICO가 시작될 무렵에는 DDoS 공격과 서버 과부하에 대비할 수있었습니다. 그러나 솔직히 말해 우리는 해커의 역량과 프로젝트 관심도를 과소 평가했을뿐만 아니라 잠재적 비상 상황에 대해서도 과소 평가했습니다.

The technical platform (user’s dashboard, all infrastructure) for Polybius’ ICO was provided by Ambisafe. Starting with the development of blockchain technology products company eventually expanded their field of interests towards providing the set of tools and services needed for running an ICO. After choosing an experienced contractor, we entirely counted on their knowledge and skills without paying additional attention to those things we should (and even must!) have checked. And that was our first mistake.

폴리비우스 ICO를 위한 사용자 대시보드나 전반적인 인프라 등의 기술 플랫폼은 Ambisafe로부터 제공 받았습니다. 블록체인 기술 제품 개발을 시작으로 ICO를 실행하는 데 필요한 일련의 도구와 서비스를 제공하는데까지 관심 분야가 점차 확대되었습니다. 숙련된 계약 주체를 선정함으로써 우리는 우리가 반드시 해야할 갓들을 충분히 확인하지 않은채 그들이 가진 지식과 기술에 전적으로 의지했습니다. 그리고 그것이 우리의 첫 번째 실수였습니다.

-

Too weak hardware / 취약한 하드웨어

Powerful servers are essential if you want your website to run at the start of the sales. Predicting the potential server load at the very first hours of the ICO, our contractor provided us power requirements, but even then we assumed that those measures might be insufficient and we doubled the characteristics. To avoid server overload, we’ve located the user’s dashboard and the Polybius’ website itself on different servers. However, database and dashboard main files remained undivided. And that was the mistake number two.

판매의 첫 시작에 웹사이트를 구동하려면 강력한 서버가 필수적입니다. ICO의 시작 이후 첫 한 시간 동안의 서버 과부하를 예측함으로써 계약 주체는 그에 필요한 전력량을 산정해주었지만 우리는 그것이 불충분할 것이라고 추정하였고 그것을 두배로 확장하였습니다. 서버의 과부하를 피하기 위해 우리는 사용자 대시보드와 폴리비우스 웹사이트 자체를 서로 다른 서버에 배치하였습니다. 그러나 데이터베이스와 대시보드 상의 주요 파일은 분리되지 않은채 남겨져있었습니다. 이것이 우리의 두 번째 실수였습니다.

The database suffered each time there were too many requests to the dashboard (and vice versa), and the server went down being periodically unavailable. When the problem became apparent, we increased the servers’ power almost ten times in comparison with original characteristics. However, it took some time to change the configurations of the dashboard and upload all files to new servers.

대시보드에 대한 요청이 지나치게 많을 때아질 때마다 데이터베이스가 손상되었으며 (그 반대의 경우도 마찬가지) 서버가 반복으로 중단되었습니다. 문제가 명확해졌을 때, 우리는 서버의 전력량을 원래보다 거의 10배까지 증가시켰습니다. 그러나 대시보드의 구성을 변경하고 모든 파일을 새로운 서버에 업로드 하는데에는 추가적인 시간이 소요되었습니다.

The furor around the start of the ICO was so high that once the counter on polybius.io showed zero, crowds rushed to buy tokens. A part of the users even managed to make a false start. The rush of real users itself was not a huge problem. The main trouble was caused by high attention from bots — the DDoS attacks had begun. The dashboard was overwhelmed by 30 million requests sent by DDoS’ers within 6 hours. In the first couple of hours, the situation escalated — it was twice as hard to fight against malicious traffic as it wasn’t always clear whether it was a real person hitting “Refresh” in hope to access the account, or it was a bot that acts in just the same way.

polybius.io 상의 카운터가 0이되었던 ICO의 시작 때 토큰을 구매하기 위한 대중들의 집중도는 매우 높았습니다. 일부 사용자의 경우에는 잘못된 시작을 관리하기까지 하였습니다. 실제 사용자들의 집중 그 자체는 큰 문제가 아니었습니다. 주된 문제는 봇에 의한 DDoS 공격으로부터 발생된 것 입니다. 대시보드는 6시간에 걸쳐 DDoS가 보낸 3000만건의 요청에 의해 압도되었고 처음 두 시간 동안 상황은 점점 악화되었습니다. 그것이 악의적인 트랙픽이건, 계정에 접속하기 위한 실제 유저들의 새로고침 조작이든간에 동일한 방식으로 영향을 미치게 되어 두 배의 어려움을 겪게 되었습니다.

Considering that there were lots of those wishing to participate — they insistently tried to access the website regardless of the DDoS and continued to buy tokens in moments of relief. As a result, system accumulated numerous amount of unaccomplished transactions that got stuck. And here we smoothly shift to the problem which for obvious reasons worried the participants of the crowdfunding the most.

ICO에 참여하고자 하는 유저들의 수가 많다는 것을 감안하여, 유저들은 DDoS 공격에도 개의치 않고 계속적으로 웹사이트에 접속을 시도하여 토큰을 구매하였고 그 결과 시스템은 많은 양의 완료되지 않은 트랜잭션을 축적하게 되었습니다. 그리고 여기서 우리의 상황은 자연스럽게 크라우드 펀딩에서 가장 우려하는 문제로 자연스럽게 이어지게 됩니다.

-

Network overload! / 네트워크 과부하

Since the system where transactions took place is complex and multi-module, each operation had to pass through a particular way to be completed. The DDoS attack caused several modules to lag, and we had to confirm stuck transactions along with traffic filtering manually. But even after the manual outthrust of stuck transactions the users still couldn’t get their tokens — now due to obstructions that appeared in the Ethereum network. That was an emergency which caused panic, and a blast of comments in the sort of “My funds have been deducted, but I haven’t got any tokens. Half an hour/hour/5 hours… had already passed, what’s going on?” Now, as all of the tokens are accounted, we can only apologize once more for the inconveniences and explain the details behind the problem.

트랜잭션이 발생하는 시스템은 복잡하고 다중 모듈 기반이기 때문에 각각의 작업은 완료를 위한 독특한 방법을 거쳐야했습니다. DDoS 공격으로 인해 여러 모듈의 지연이 발생했고, 우리는 트래픽을 필터링하는 것과 동시에 누적된 트랜잭션을 수동으로 승인해야했습니다. 그리나 그 이후에도 이더리움 네트워크 상에 나타난 장애로 인해 사용자들은 여전히 자신의 토큰을 얻어갈 수 없었습니다. 그리고 그것은 결국 "내 자금은 빠져나갔지만 아무런 토큰도 얻지 못했다"는 두려움의 상황을 야기하였습니다. 30분, 1시간, 5시간이 지나고 마침내 모든 토큰이 발급되었고 우리는 오로지 불편을 끼쳐서 죄송하고 한번 더 사과하는 것 이외에는 할 수 있는 것이 없었습니다.

Along with the start of Polybius’ ICO, another large ICO (BAT — BasicAttentionToken) took place on Ethereum blockchain, and competing investors led the network to an overload. To understand the basis of the issue we had, it is necessary to comprehend how Ethereum works. To send a transaction to the Ethereum network you need to pay a commission fee — the higher the commission fee is, the faster the transaction reaches the network. The participants of the second ICO increased their commission fees to speed up their transactions. With such “competition,” Polybius transactions (having an optimal cost-time ratio) couldn’t get through and formed a queue in Ethereum network, hanging somewhere between our system and the blockchain.

폴리비우스의 ICO가 진행되는 동안 또 다른 거대 ICO인 BAT (Basic Attention Token)가 이더리움 블록체인을 차지하였고 경쟁적인 참여자들은 네트워크의 과부하를 유발하였습니다. 우리가 겪은 문제들을 이해하기 위해서는 이더리움이 어떻게 작동하는지 이해할 필요가 있습니다. 이더리움 네트워크를 통해 트랜잭션을 보내려면 그에 대한 수수료를 지불해야 하는데 이 수수료가 높으면 높을수록 더 빠르게 트랜잭션이 네트워크에 전달되게 됩니다. 두 번째로 ICO에 참가하는 참가자들은 그들의 트랙잭션을 좀 더 빠르게 전달하기 위해 높은 수수료를 설정하였습니다. 이러한 경쟁으로 인해 폴리비우스가 설정한 최적의 비용과 시간의 비율은 이더리움 네트워크 내에서 대기열을 형상하지 못하고 우리의 시스템과 블록체인 사이의 어딘가를 배회해야만 했습니다.

To make not a single but multiple transactions in Ethereum, as it was in our case, we had to form a queue of transactions, giving a conditional number to each of them. These numbers have to be in an absolute order of increment which means that each next transaction must have a higher number than the previous one. That means that the transaction number 10 cannot be sent to the network if the transaction number 9 is still undispatched. To avoid network overload and multiplication of stuck transactions we were forced to raise commission for all new orders — new transactions started to get normally confirmed, now in acceptable time. The very first transactions (that is a huge amount of orders — more than a thousand of them) we had to leave “as is,” so our first participants weren’t quite the first to receive the tokens.

이더리움에서 단일 트랜잭션이 아니라 다중 트랜잭션을 만들기 위해서 우리는 트랜잭션 대기열을 만들어 각각의 트랜잭션에 조건부 번호를 부여해야했습니다. 이 숫자는 절대 증가 순서대로 있어야하며 이는 다음 트랜잭션이 이전 트랜잭션보다 많은 수를 가져야 함을 의미합니다. 즉, 트랜잭션 번호 9가 여전히 디스패치되지 않으면 트랜잭션 번호 10을 네트워크로 보낼 수 없다는 것입니다. 지연된 트랜잭션의 네트워크 과부하 및 증가를 피하기 위해 모든 신규 주문에 대한 수수료를 인상하였고, 새 거래가 다시 정상적으로 승인되기 시작했습니다. 그러나 가장 최초의 1000건이 넘는 주문의 참가자들은 처음으로 토큰을 받지 못하게 되었습니다.

-

What have we learned / 우리가 배운 것들

The most important (and obvious) knowledge we obtained is related to problem-solving in general — when you’ve got a problem, the best you can do is to start solving it with maximum speed and efficiency. The first thing we did was increasing the server capabilities, switching to more powerful hardware, dividing the database among multiple servers, optimizing the firewall and filtering the DDoS attacks. And only that took us about 24 hours. Tuning the process of carrying out transactions through Ethereum took additional time.

우리가 얻은 가장 중요한 (그리고 명백한) 지식은 일반적인 문제 해결과 관련되어 있습니다. 문제가 발생하면 최선의 속도와 효율로 문제를 해결하는 것이 가장 좋습니다. 우리는 우선적으로 서버 용량을 확장하고 좀 더 강력한 하드웨어로 전환한 후 데이터베이스를 여러 서버로 분할하고 방화벽을 최적화하고 DDoS 공격을 필터링했습니다. 그리고 그것은 단지 약 24 시간이 걸렸습니다. 이더리움을 통한 트랜잭션 전달을 수행하는데에는 추가적인 시간이 더 소요되었습니다.

Now, with a substantial ICO experience, we can surely say that you cannot be too prudent with that sort of things. It is always better to be overly cautious — that’s why if you ever decide to have an ICO, you should consider the following points

실질적인 ICO 경험을 통해 이제 우리는 당신이 지나치게 신중하다고 결코 말할 수 없을 것입니다. 지나치게 신중하다는 것은 언제나 좋은 일입니다. 당신이 만약 ICO를 결정하게 된다면 다음과 같은 사항을 고려해야할 것입니다.

• During the first hours the server load can be sky high and leave behind the bravest expectations;

• 처음 몇 시간 동안은 서버의 부하가 하늘로 치솓을 수 있을며 예상을 훨씬 뛰어넘을 것입니다.

• If your project (or the company behind it) is known, attention from DDoS’ers is guaranteed — be ready to be attacked;

• 프로젝트(또는 그 뒤에있는 회사)가 이미 알려져있는 이상, DDoS 공격은 확실히 보장됩니다. 공격을 받아낼 준비가 되어 있어야합니다.

• If other ICOs would happen at the same time when yours, it is better to think about your strategy in advance. You can either wait a couple of days until transactions eventually go through or you can invest additional resources and force orders through the network;

• 다른 ICO가 동시에 일어날 경우 사전에 전략을 세워두는 것이 좋습니다. 해당 거래가 끝날 때까지 며칠 정도 기다리는 방법, 혹은 추가 리소스를 투입하는 동시에 강제로 네트워크에 주문하는 방법이 있을 것입니다.

• It is also important to inform your participants about such issues. That will decrease the number of similar queries to technical support, allowing them to focus on more relevant issues.

• 참가자들에게 이러한 문제에 대해 인지시키는 것 또한 중요합니다. 그것은 기술적 지원에 대한 유사한 쿼리의 수를 줄임으로써 좀 더 밀접한 문제에 집중할 수 있게 됩니다.

Incidentally, it is impossible to foresee all the potential problems, so you have to be ready for all kinds of emergencies. You can spend a lot of time on counting the number of mistakes you’ve done inadvertently, but learning from mistakes is just another way of improvement. After all, we are glad that our technical issues haven’t opposed the successful accomplishment of our campaign.

부수적으로, 잠재된 모든 문제를 예측하는 것은 불가능하기 때문에 모든 비상 상황에 대비해야합니다. 당신이 부주의로 실수한 횟수를 세는 데 많은 시간을 소모할 수 있지만, 실수를 통해 배우는 것은 개선을 위한 또 다른 방법입니다. 어쨌거나 우리는 우리의 기술적인 문제가 우리의 캠페인이 성공하는 것을 막아서지 않았다는 점에 대해서 기쁘게 생각합니다.