일전의 Pirl에서 제안한 것으로 알려진 Penalty System을 알려드린바 있습니다.
https://www.ddengle.com/develop/10694967
위 글에서 Pirl의 Penalty System 코드를 분리해서 ESN에 적용하여 테스트한 다음의 코드도 함께 참고하실 수 있습니다.
https://github.com/EthersocialNetwork/go-ethereum/pull/1 (2019년 1월)
이 패널티 시스템은 ESN 2분기 로드맵에 명시되어 있는데,
Pirl의 Penalty System을 다시 리뷰하고 이를 ESN에 적용할 것인지 검토하였습니다.
사실 Penalty System은 Pirl에서 고안했던 것은 아니고, Zen Cash(지금은 이름을 바꿔서 Horizon)에서 최초 고안했던 것과 같은 것이며,
다음과 같은 여러 이더리움 소스코드 기반의 포크 코인에 적용되어있습니다.
- Music 코인
- 칼리스토
- Ether-1 (Ether-1은 재밌게도, 제가 리팩토링 한 Penalty System을 적용하였습니다. https://github.com/Ether1Project/Ether1/pull/2 )
패널티 시스템의 단점: 분리된 체인은 누가 도태시키는가?
이 코드를 리뷰했을 당시에 잠재적인 문제가 있음을 발견하였고,
https://www.ddengle.com/develop/10694967 이 글의 댓글에도 "체인분리"에 대한 대책이 있는지 없는지를 @사과야채 님이 질문하고 계시는데, 페널티 시스템의 가장 큰 단점이 바로 체인 분리입니다.
체인 분리는 ESN도 경험한 바 있고, 칼리스토 최초 채굴 러시때에도 경험하신 분이 계실것입니다만,
분권화를 중요시하는 블록체인에서는 소규모 체인 분리는 수시로 일어나며, 이러한 국소적 체인분리는 금방 복구됩니다. (이를 체인 reorganization (체인 재편성)줄여서 chain reorg. 라 부름) 즉, 국소적으로 노드간의 연결이 원활하지 않은 경우 A가 캔 블록이 B가 캔 블록에 의해 취소되고 엉클 블록으로 처리되거나 아예 고아(orphan) 블록이 되는 경우가 발생합니다. 이 잠깐동안의 체인 분리는 "가장 빨리 문제를 풀고, 가장 긴 체인을 선택한다"는 블록체인 기본 컨센서스에 의해 금방 복구되어버리고 마는 것입니다.
그러나 패널티 시스템의 경우에는 가장 긴 체인이라 할지라도, 패널티값이 너무 높은 체인은 도태시키는 "패널티" 컨센서스가 추가됩니다.
패널티 시스템에서는 51% 공격을 감행하게 되면 공격자는 이중 지불을 발생시키기 위해 약간 늦은 타이밍에 블록을 캐내게 되는데,
적게는 60블럭에서 100블록 이상의 약간 늦은 타이밍에서 캤지만, 가장 긴 체인을 만들어 대규모 체인 재편성(chain reorg)를 일으키는 체인은 패널티 시스템에서는 체인 분리를 일으키는 것입니다.
이러한 체인 분리가 된 체인 및 노드는 일반적인 상황이라면 자연적으로 도태가 되기 마련인 것입니다만,
문제는 "게으른 채굴자와 게으른 풀 관리자"가 네트워크 풀상에 항상 상존한다는 것입니다.
패널티 시스템이 제대로 작동하려면, 이러한 체인 분리를 풀 관리자 혹은 채굴자가 지속적으로 모니터링하고 분리된 체인을 도태될 수 있도록 하는 최소한의 관리가 추가적으로 필요한 것입니다.
안타깝게도, 불특정 다수의 채굴자는 채굴을 주업으로 하는 것이 아닌 취미로 하고 있으며, 일부 풀 관리자는 상당히 관리를 소홀히 하고 있으며, 패널티 시스템을 개발했던 Pirl 네트워크는 지난 수개월 동안 이러한 체인 분리로 수차례 문제를 겪게됩니다.
minerpool.net 의 경우 체인 분리가 발생했는데도 수일동안 이를 방치했고, 이곳에서 캤던 Pirl은 무용지물이 되게 됩니다.
이런 일이 수차례 발생하자 Pirl에서는 minerpool.net을 퇴출시킵니다.
그러나 여전히 이곳에서 Pirl을 캐고 있는 채굴자도 있습니다;; http://pirl.minerpool.net/
패널티 시스템은 소규모의 잘 관리되는 네트워크에는 유용할 수 있으나, 퍼블릭 블록체인의 특성상 적용하기 힘든이유이며,
여전히 수많은 이더리움 소스코드 기반 네트워크에서 이를 적용하지 않는 이유이기도 한 것입니다.
공격감지 시스템
그렇다면 51% 공격 발생이 가능한 ESN 네트워크에서는 패널티시스템 적용을 하지 않으면서 51% 공격을 어떻게 방지할 수 있을까요? 어떻게하면 컨센서스 변경 없이 이중지불을 방지할 수 있을까요? 결국 51% 공격은 이중 지불문제가 거래소에서 발생할 수 있다는 것인데, 이더리움 클래식과 같은 상당히 큰 규모의 네트워크도 51% 공격이 가능한 것이 최근에 알려졌는데 이를 어떻게 하면 방지할 수 있을까요?
이더리움 클래식이나 기타 여러 코인들이 패널티 시스템을 적용하지 않았으나, 그들은 블록 confirmation 회수를 적게는 300에서 많게는 500이상까지 늘려서 51% 공격을 하기 어렵도록 조치하고 있습니다.
300블록 컨펌이 필요한 거래소에서 이중 지불을 일으키려면 적어도 301 블록 x 15초 = 대략 1시간 30분 정도의 시간동안 51%의 네트워크를 동원해서 캐야 하며, 공격이 실패할 하거나, 공격이 중간에 발각되기라도 1시간 30분동안 캔 블록이 무용지물이 될 수 있다는 점을 감수해야 합니다.
이렇게 해시 공격이 일어나게 될 때 네트워크는 몇가지 현상이 일어나게 됩니다.
- 네트워크 해시가 급격히 늘어나 난이도가 올라가게 되면 엉클 확률이 5% 이상으로 확 올라간다.
- 공격자가 주도면밀하지 않은 경우, 예를 들어 20블록 수준의 체인 재편성(chain reorg.)을 공격자가 테스트로 일으키는 경우 => chain reorg. 확률이 올라간다.
이러한 미동의 이상한 현상이 감지되기라도 하면 거래소는 컨펌 회수를 300에서 1000으로 확 올려버릴 수도 있습니다. 이 경우 공격자의 실패 확률은 더 올라가게 되고 51% 공격은 무위에 그칠 가능성이 높아지게 됩니다.
이더리움 소스코드는 내부적으로 체인 재편성을 감지하는 코드가 있으며, 이러한 공격 감지 시스템을 노드 소스코드 간단히 개선하는 방식으로도 고칠 수 있고 (https://github.com/ethereum/go-ethereum/pull/18950 참고. 본인이 제출하여 approved되었으나 아직 적용 안됨),
노드를 고치지 않고도 공격 감지를 할 수 있게 만드는 것이 얼마든지 가능합니다.
이더리움 클래식의 경우에는 classic-geth의 로그 데이터를 분석하는 방식으로 만든 바 있으며 https://github.com/etclabscore/classic-geth-supervisor.sh https://etcstatus.live/ 참조)
ESN의 경우에는 이더 클래식에서 제공하는 서비스와 유사하나 더 간단한 모니터링 툴을 제공하고 있고 https://stats.ethersocial.org/ 이를 좀 더 개선하여 엉클 확률과 체인 재편성(chain reorg.)를 디스코드 메신져를 통해 즉각적으로 알려주는 공격감지 시스템 초기 버전을 만들었습니다. (아직 https://stats.ethersocial.org 에 적용하지 않았으나, ESN 공식 디스코드의 #netstat 채널(https://discord.gg/zjFNJMQ )에서 공격 감지 봇이 이를 알려주게끔 하였습니다.
디스코드 메신져를 통한 공격감지 봇의 알림의 예
- 1개 체인의 체인 재편성은 매우 빈번하며, 이를 알려주고 있습니다. (덜 빈번하게 알려주게 하려면 세팅을 고칠 수 있음)
- 엉클 확률이 올라가면 붉은색으로 경보. 5% 이하로 낮아지면 파란색으로 경보 알림.
공격 경보시스템의 장단점
이러한 경보시스템은 다음과 같은 장단점을 가집니다.
- 패널티 시스템처럼 추가적인 컨센서스를 필요로 하지 않으며, 체인 분리도 일어나거나 하는 단점은 없습니다.
- 경보시스템은 chain reorg가 공격에 의한 체인 재편성인지 아니면 정상적인 체인 재편성인지 구별하지 않습니다. 단지 경고만 합니다.
- 공격자가 매우 치밀하지 않은 이상 체인 재편성 초기에 조기 징후가 발생하는 것을 가정합니다.
- 일반적인 상황이라면 긴체인의 chain reorg가 거의 일어나지 않으나, 전체 네트워크의 불안정 혹은 단속등으로 인해 정상적인 체인 재편성도 가능합니다. 경보시스템은 정상적인 체인 재편성과 공격에 의한 체인 재편성을 구별하지는 않습니다.
- 갑자기 난이도가 올라가는 경우 추가적으로 엉클 비율이 높아지게 되는데 이를 함께 경보로 알려줍니다.
- 대규모 체인 재편성이라 할지라도 상당히 짧은 시간 안에 체인 재편성이 발생됩니다. 따라서 경보 알람 => 수동으로 거래소에서 컨펌 회수 조정의 과정이 원활하지 않은 경우 이중지불 발생이 가능합니다.
- 따라서 경보시스템의 소스를 공개하여 거래소 시스템이 이를 활용할 수 있도록 해야 합니다.