비콘 체인의 Inactive Leak Penalty
- Inactive Leak Penalty 란 무엇인가?
정상적인 비콘체인 네트워크 상태에서 밸리데이터가 패널티를 물게 되는 것은, (1)밸리데이터가 비활성되어 업무를 수행하지 않는 경우와 (2)중복된 블록을 프로포져하거나 어테스트할 때 입니다. (2)는 패널티가 크지만 중복 투표를 하지 않도록 노드를 잘 관리하면 막을 수 있고, (1)의 경우 짧은 시간동안의 비활성 상태에 대한 패널티는 그렇게 심각하지 않습니다. 일반적으로 액티브된 상태에서 받을 수 있는 보상 양만큼 비활성되었을 때 패널티를 받습니다. 즉 12시간 참여하고, 12시간 비활성화 되었다면, 보상은 전체적으로 0에 가깝습니다.
그러나, 네트워크 상태가 비정상인 상태, 즉 finality를 이루어낼 수 없을 때에 발생하는 밸리데이터의 비활성 패널티는 매우 심각한 수준으로 늘어나게 됩니다. 이러한 패널티를 Inactive Leak Penalty 라고 부르는데, 이런 룰을 만든 이유가 있습니다. 네트워크에 finality를 못만든다는 것은 네트워크에 참여하고 있는 밸리데이터의 2/3의 동의를 얻어내고 있지 못하다는 것인데, 분모인 네트워크에 참여하고 있는 총수를 계산할 때, 액티브한 밸리데이터뿐만 아니라 엑싯하지 않는 모든 밸리데이터가 가지고 있는 이더의 수를 사용합니다. 즉 비활성화된 밸리데이터가 전체 네트워크의 finality 형성에 방해가 되고 있는 상태가 되는 거지요. 이러한 비활성 밸리데이터가 빨리 밸리데이션에 복귀하도록 유도하기 위해 패널티를 가중시키는 거지요. 또한 가중된 패널티를 계속 맞게 되니까, 비활성화된 밸리데이터의 이더 수는 계속 줄게 되고 그만큼 전체 퍼센트에서 차지하는 영향력이 약화되어서 결국 2/3를 동의를 확보하는게 더 쉬워집니다.
2. Inactive Leak Penalty는 언제 발동되고, 얼마나 많은 패널티를 주는가?
이 패널티가 발동되는 시점은 연속적으로 4 에포크기간동안 비콘체인이 finality를 못 만들 때입니다. 에포크 1개가 32 슬롯으로 구성되고 1 슬롯은 12초이니, 4 에포크란 43212 = 25.6분입니다. 이 기간 이후에도 계속 finality를 못 만들면 에포크마다 패널티가 가중됩니다.
finality 실패 5번째 에포크의 Total leaked는 5인데, 12번째 연속 실패 후는 68입니다. 패널티는 Total leaked 양을 INACTIVITY_PENALTY_QUOTIENT 라는 분모로 나눈 값을 현재 가진 이더의 밸런스에 곱합니다.
Inactive Leak Penalty Amount =
(Total leaked / INACTIVITY_PENALTY_QUOTIENT = 2**26 (67,108,864)) * Ether balance
예를 들자면 finality 실패 12번째 에포크의 패널티는 (58 / 67,108,864) * 현재 이더 밸런스입니다. 얼마 안되는 것 같지만, finality를 계속 실패하면 패널티는 계속 늘어납니다. 아래 그래프는 이게 장기화되었을 때의 패널티 증가를 보여줍니다.
약 1주일 되면 10% 정도를 잃고, 20일 정도되면 50% 정도를 잃습니다. 40일이 되면 현재 밸런스 기준 90%까지도 날릴 수 있습니다. 이러한 패널티는 설사 중간에 자진해서 slash를 해도, 완전히 exit 되기 전까지 계속 물어야 합니다. 패널티를 회피하기 위해서 의도적으로 slashing 당하는 것을 막기 위한 것이죠.
3. Inactive Leak Penalty 위험은 언제 높은가?
물론 이러한 패널티가 상시적으로 자주 생길 수 있는 것은 아니며, 생기더라도 몇일 이상 지속될 가능성도 매우 낮습니다. 하지만 생길 경우 밸리데이터에 주는 임팩트는 매우 클 수 있으므로 언제 이런 위험성이 올라가는지 사전에 고려해보고, 이런 상황에 생길 경우 어떻게 대처해야 될지를 미리 계획해보는 것도 좋을 것 같습니다.
네트워크의 finality가 이루어지 않는 가장 가능성이 높은 첫번째 경우는 밸리데이터 클라이언트 소프트웨어의 버그입니다. 지난번 메달라 테스트넷에서 프리즘의 타임싱크방식에 문제가 있어서 한동안 장애가 일어난 경우가 이런 예입니다. 1/3 이상의 밸리데이터가 사용하고 있는 클라이언트에 싱크 문제가 생기면 이를 사용하는 모든 밸리데이터들이 일시에 장애에 빠지고 finality 에 필요한 2/3 동의를 얻지 못할 수 있습니다. 이에 대한 대비책은 미리 다른 클라이언트를 테스트넷에서 돌려보고 비상시에 전환할 수 있는 준비를 해두는 것입니다. 특히 슬래시 프로텍션 데이타베이스를 다른 클라이언트에서 받아서 이용할 수 있는지 여부를 체크해두고, 만일 이것이 불가능했을 경우, 어떻게 처리하는 것이 바람직한 것인지 알아둘 필요가 있을 겁니다. 물론 이런 상황에 발생했을 때 클라이언트 개발팀과 커뮤니티에서 적절한 행동지침이 공유될테니 이를 잘 활용하는 것도 중요합니다.
두번째는 eth1 노드를 인퓨라와 같은 외부노드에 의존하는 밸리데이터가 많은 상태에서 이들 서비스가 다운되는 경우입니다. 인퓨라 노드가 지난번 다운되어서 대규모로 문제가 생긴 적이 있습니다. 이를 방지하는 가장 좋은 대책은 자체 노드를 운영하는 것이지만, 비상시에 사용할 수 있는 외부 클라우드 노드 서비스를 미리 셋업 해두는 것도 좋습니다.
세번째는 다수의 밸리데이터들이 아마존과 같은 클라우드를 이용해 밸리데이터를 돌리고 있는데, 이들 클라우드가 다운되는 경우입니다. 굳이 클라우드를 환경을 선택해야 한다면 아마존을 피하고, 비상시 백업으로 돌릴 수 있는 준비를 미리 해두는 것이 좋습니다.
네번째는 대형 거래소나 스테이킹 전문업체가 돌리는 서비스가 다운되는 경우입니다. 바이낸스가 같은 대형 서비스가 1/3 이상의 디파짓 금액을 홀딩하다가 다운되어 4에포크를 넘어가면, 여기에 물려있는 스테이킹 어카운트들은 전부 Inactive Leak Penalty를 물어야만 합니다.
1/3 이상의 밸리데이터가 한꺼번에 동일한 이유로 다운되면, 거기에 속해서 다운된 밸리데이터들은 전부 가중된 패널티를 물어야만 한다는 겁니다. 이런 위험을 피하려면, 가급적 이런 상황에 생길만한 곳에 들어가지 않는 것이 좋겠지요. 그리고 들어 있었다면 어떻게 빨리 이로부터 벗어날 수 있는지 대책이 있어야 하고요.
4. 독자적으로 운영하는 밸리데이터도 다운될 확률은 마찬가지이거나 더 높지 않나?
개인이 독립적으로 운영하는 밸리데이터들도 다운될 확률은 있습니다. 인터넷이 연결이 끊어지거나, 시스템이 오류가 나거나 여러가지 이유가 있겠지요. 하지만 이러한 노드들이 한꺼번에 1/3 이상 중단될 만한 이유는 클라이언트 버그 이외에는 거의 없습니다. 혼자만 중단된 경우 비활성화로 인해 패널티는 그리 크지 않습니다. 몇일 다운되었어도, 같은 기간만큼 다시 온라인되면 손해를 만회할 수 있습니다.
5. 밸리데이터 다운을 방지하기 위한 자동 복구 시스템(redundant fault tolerant system)은 충분한 가치가 있는가?
시스템이 중지되었을 때 어떻게 대처할지에 대해 미리 준비하고, 계획을 세워두는 것은 바람직하지만, 그렇다고 복수의 시스템에 동일한 밸리데이터키를 저장하고, 온라인 스탠바이 모드로 대기 시키는 것은 오히려 슬래싱 당할 위험을 증가시킵니다. 현재까지 메인넷에 일어난 슬래싱 케이스 대부분은 시스템 장애시 자동으로 서비스를 복구하기 위해 대기시킨 시스템들이 동시에 네트워크에 연결되면서 생긴 문제 때문이었습니다. 보통의 경우 스탠드바이로 대기중인 VM들이 액티브해져도 서비스에 큰 문제를 일으키지 않지만, 비콘체인 스테이킹에서는 한번의 실수로 슬래싱을 당할 수 있습니다. 네트워크 운영에 전문적인 경험이 없는 사람은 밸리데이션키를 한 곳에만 저장하고, 다른 백업 시스템은 키를 저장하지 않은채 싱크만 되도록 하는 것이 바람직합니다. 유사시에 밸리데이션 키를 옮기는데 들어가는 시간동안 물어야 하는 패널티는 매우 작습니다.
[References]
https://blog.ethereum.org/2020/12/10/validated-perfect-is-the-enemy-of-the-good/
https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md
https://notes.ethereum.org/@vbuterin/SkeyEI3xv#inactivity-quotient
