51% 공격이 감행되는 경우, 체인은 롤백이 될 수 있고, confirmation을 짧게 잡은 거래소의 경우 이중 출금 문제가 발생할 소지가 있습니다.
예를 들어 51% 공격에 의해서 100 블록이 lost 되고, 공격자의 블록으로 대체되는 경우, 100 블록 이상을 confirmation 길이로 잡아버리면 double spend 문제는 간단히 무위에 그쳐버립니다.
특정 거래소의 confirmation이 100 블록이라면, 공격자는 51% 공격에 의해 100블록 이상을 몰래 캐어야 하는데,
200 confirmation이 된 이후에 출금을 하도록 하면 공격자는 헛고생 하는 셈이 되는 것이죠.
(다만, 채굴자들이 애써 캔 블록이 엉클이 되거나 고아(orphan)이 되는 것은 막을 수 없고, 채굴자 분들도 공격자때문에 손해를 보게 됩니다.)
그러면 51% 공격은 어떻게 이루어질까요?
예를 들어, 공격자가 51% 해시 공격에 의해서 double spend를 발생시키려고 한다고 했을때에
0. 현재 넷 해시로 100블록을 30분만에 캘 수 있다면 => 공격자는 최소 30분만에 혼자서 101블록을 캐야 합니다.
1. 이렇게 하려면 => private 상태에서 100여블록을 캐고. (private 상태이므로 해시 기여도를 쉽게 판독할 수없음)
2. 공격 대상의 블록체인보다 최소 1블록 이상 길어야 하고.
3. private 상태에서 재빠르게 public 상태로 전환시켜 체인 재편성(reorg)를 유발시
4. 노드는 가장 긴 체인을 발견하고 체인이 재편성(reorganization, 줄여서 reorg) 되면서 이전의 100여 블록이 lost된다. => TX 기록도 블록체인에서 사라져버립니다. (여기서 double spend 발생함) (orphan 블록 비율이 높아짐)
(갑자기 orphan 비율이 높아진다면 => 해시 공격이 감행중이라고 볼 수 있죠.)
그렇다면 이 문제를 해결할 수 있는 방법은 없는 것일까요?
아예 없지는 않습니다.
비교적 최근에 Horizon(ZenCash)가 이중지불 공격을 당했고, Pirl(이더리움 소스 포크) 및 Musicoin도 이중지불 공격을 당했는데 이 문제를 해결하기 위해서 Horizon에서는 Penalty System을 고안했습니다.
(Pirl에서는 이와 거의 동등한 방식을 구현하고 이를 PirlGuard로 부릅니다)
https://www.youtube.com/watch?v=E99wpSZs6iM (Horizon에서 만든 소개 영상)
예를 들어서, 100 블록을 몰래 캐서 블록 재편성(reorg)을 일으켜 => 100블록이 증발하게 하려는 공격을 무위로 돌리려면???
"특정개수 이상의 블록이 재편성(reorg)이 일어나는 것을 막으면 됩니다."
현재 비트코인이나 이더리움은 "가장 긴 체인"을 기준이 되도록 프로그래밍이 되어있는데, 여기에
가장 긴 체인을 따르되, 너무 낡은 블록이 재편성 일으키는 경우 벌점을 주어서 너무 낡은 블록이 재정렬에 편입되지 못하게 막는 것입니다.
블록체인은 바로 이전 블록을 기준으로 연결이되어 있기때문에, 재편성이 일어나는 그 시점 블록의 해시를 blacklist로 등록시켜버리거나 하면 이어지는 블록들은 재편성에서 제외되어버립니다. 추가적으로 이러한 시도를 하는 노드를 블랙리스트로 올려서 노드간에 블랙리스토 노드 정보를 교환하도록 하는 추가 안전장치도 가능할 것입니다. (pirl Guard는 콘트랙트를 사용해서 black list 노드를 따로 관리하는 것으로 보임)
공교롭게도 저는 바로 몇일 전부터 51% 공격 방지 방식에 대해서 개인적으로 스터디를 진행하였으며,
Pirl에서 구현한 PirlGuard를 Musicoin에 적용한 사례등의 소스코드를 살펴보고 이를 정리해서 ESN 뿐만아니라 다른 이더리움 소스기반 포크 코인에서도 쉽게 적용이 가능하도록 하고, 테스트를 수행하였습니다.
https://github.com/EthersocialNetwork/go-ethereum/pull/1
테스트넷상으로 아주 잘 작동하고, 좀 더 다양한 테스트 케이스를 만들어 테스트해보아야 하겠지만, 이 방식은 이미 Horizen / Pirl / Musicoin에서 적용하여 쓰고 있는 방식이므로 이미 "어느정도 수준으로는" 검증이 된 방식이라 할 수 있을 것입니다.