이더리움 2.0 스테이킹에는 어떤 잠재적인 결함이 있을까요? 어떻게 대응할 수 있을까요?

신호 체인은 검증자 행동에 대해 여러 가지 인센티브 메커니즘을 제공하며, 이러한 메커니즘은 네트워크의 현재 상태에 따라 결정됩니다. 따라서 노드를 보호하는 방법을 결정할 때 다른 검증자들이 문제에 직면할 가능성도 고려하는 것이 중요합니다.

활동 중인 검증자의 잔액은 상승하거나 하락하며, 변하지 않습니다. 따라서 위험을 최소화하는 것은 수익을 극대화하는 방법 중 하나입니다. 검증자의 잔액이 신호 체인에 의해 차감되는 경우는 주로 다음 세 가지입니다:

• 일반 처벌: 검증자가 의무를 다하지 않을 때 부과되는 처벌입니다 (예: 오프라인 상태).
• 태만 처벌 (Inactivity Leaks): 네트워크가 확정되지 않은 상태일 때, 검증자가 의무를 다하지 않으면 이 처벌을 받습니다. 이는 오프라인 상태인 다른 검증자와 밀접하게 관련되어 있습니다.
• 벌금 (Slashing): 검증자가 모순된 블록 제안이나 증명을 할 경우 벌금을 부과받습니다 (공격 행위일 수 있음).

주의: 평균적으로 단일 검증자의 잔액은 변하지 않을 수 있지만, 작업에 참여하는 한 보상을 받거나 처벌을 받을 것입니다.

네트워크 전체가 건강하게 운영되고 있다면, 단일 검증자가 오프라인이 되거나 벌금이 부과되는 영향은 미미합니다. 즉, 처벌의 강도가 크지 않습니다. 반대로, 네트워크에 많은 검증자가 오프라인 상태라면, 오프라인 검증자의 잔액 감소 속도는 훨씬 빨라질 것입니다.

마찬가지로, 많은 검증자가 동시에 벌금을 trigger하면 신호 체인에겐 공격 행위와 다름없으므로, 이러한 검증자의 100% 스테이킹 금액은 소멸됩니다.

이러한 "반상관" 인센티브로 인해 검증자는 다른 사람에게 미치는 영향을 더 많이 고려해야 하며, 고립된 개인의 관점에서 출발해서는 안 됩니다.

고장 원인 및 가능성

몇 가지 고장 사례를 자세히 살펴보고, 얼마나 많은 다른 검증자가 동시에 영향을 받을지, 그리고 당신의 검증자가 얼마나 큰 처벌을 받을지를 살펴보겠습니다.

여기서 저는 @econoar의 의견에 동의하지 않습니다. 이러한 문제의 심각성은 중간 정도입니다. 가정용 UPS와 이중 WAN 주소 고장은 다른 사용자와 관련이 없으므로 고려 범위에서 제외됩니다.

? 네트워크 / 전력 고장

당신이 집에서 검증자를 운영하고 있다면, 앞으로 이러한 문제를 겪을 가능성이 높습니다. 가정용 네트워크와 전력 연결은 정상 운영 시간을 보장할 수 없습니다. 네트워크가 끊기거나 전력이 중단되면, 일반적으로 전체 지역이 영향을 받으며, 몇 시간 동안 지속될 수 있습니다.

당신의 네트워크나 전력이 매우 안정적이지 않다면, 이로 인해 처벌을 받는 것은 그리 가치가 없습니다. 이 몇 시간 동안 처벌을 받겠지만, 전체 네트워크가 정상적으로 운영되고 있기 때문에 당신의 처벌은 그 시간 동안 받을 수 있는 보상과 대략 동일합니다. 즉, 고장 시간이 k 시간이라면, 당신의 검증자 잔액은 고장 k 시간 전의 값으로 돌아갔다가, k 시간 후에 다시 고장 전의 값으로 회복될 것입니다.

Validator #12661의 잔액 회복 속도는 오프라인 상태에서의 감소 속도와 대략 동일합니다 - Beaconcha.in

? 하드웨어 고장

네트워크 문제와 유사하게, 하드웨어 고장은 무작위로 발생하며, 고장이 발생할 때 당신의 노드는 며칠 동안 오프라인 상태가 될 수 있습니다. 검증자의 전체 생애 주기에서 예상 수익과 예비 하드웨어 비용을 고려하는 것이 필요합니다. 고장의 기대값 (오프라인 벌금 곱하기 발생 확률)이 예비 하드웨어 비용보다 큰가요?

개인적으로, 고장이 발생할 확률이 낮고 예비 하드웨어 비용이 높다면 이는 가치가 없습니다. 하지만 다시 말해, 저는 거대 고래가 아닙니다? 당신은 자신의 실제 상황에 따라 모든 고장 상황을 평가해야 합니다.

☁️ 클라우드 서비스 고장

아마도 많은 사람들이 하드웨어와 네트워크 고장을 피하기 위해 클라우드 서비스를 선택할 수 있습니다. 클라우드 서비스를 사용하면 위에서 언급한 상관 위험이 도입됩니다. 얼마나 많은 다른 검증자가 당신과 같은 클라우드 서비스 제공업체를 사용하고 있나요?

창세 전 일주일 동안 아마존의 AWS가 오랜 시간 동안 중단되어 네트워크에 큰 영향을 미쳤습니다. 지금 비슷한 사건이 발생하여 많은 검증자가 동시에 오프라인 상태가 된다면, 태만 처벌 (inactivity penalties)이 발생할 것입니다.

더 나쁜 상황은, 클라우드 서비스 제공업체가 새로운 가상 머신으로 당신의 노드를 실행하는데, 우연히 이전 노드를 중지하지 않는 경우입니다. 이는 당신이 벌금을 부과받을 수 있으며 (다른 검증자에게도 영향을 미쳤다면 처벌 강도가 특히 클 것입니다).

클라우드 서비스를 사용해야 한다면, 더 작은 서비스 제공업체로 전환하는 것을 고려해 볼 수 있습니다. 손실을 줄일 수 있을 것입니다.

? 스테이킹 서비스

현재 메인넷에는 여러 가지 스테이킹 서비스가 있으며, 분산화 정도는 다양하지만, 당신의 ETH를 서비스 제공업체에 맡기는 것은 상관 위험을 증가시킵니다. 이러한 서비스는 의심할 여지 없이 eth2 생태계에서 필수적인 부분이며, 32 ETH 미만을 보유하거나 스테이킹에 필요한 기술 지식이 부족한 사용자에게 더욱 그렇습니다. 하지만 이러한 서비스는 인위적으로 설계되었기 때문에 결함이 존재할 수 있습니다.

스테이킹 풀의 규모가 결국 eth1 채굴 풀만큼 커진다면, 하나의 취약점이 사용자에게 대규모 벌금이나 태만 처벌을 초래할 수 있습니다.

? Infura 고장

지난달 Infura가 6시간 동안 중단되어 이더리움 생태계가 정체되었습니다. 마찬가지로, 이는 Eth2 검증자가 직면할 수 있는 상관 위험입니다.

또한, 제3자 eth1 API 제공자는 서비스 호출에 대한 속도 제한을 적용해야 합니다: 과거에 이는 검증자가 유효한 블록을 생성하지 못하게 했습니다 (Medalla 테스트넷).

가장 좋은 해결책은 자신의 eth1 노드를 운영하는 것입니다: 속도 제한에 걸리지 않으므로 상관 위험을 줄이고 전체 네트워크의 분산화 수준을 높이는 데 도움이 됩니다.

Eth2 클라이언트는 여러 eth1 노드를 지정할 수 있는 가능성을 추가하기 시작했습니다. 주요 엔드포인트에 문제가 발생할 경우 쉽게 대체 엔드포인트로 전환할 수 있는 장점이 있습니다 (Lighthouse:--eth1-endpoints, Prysm: PR#8062, Nimbus와 Teku도 이후 지원할 가능성이 있습니다).

비용이 적거나 무료인 대체 API (EthereumNodes.com) 추가를 강력히 추천합니다. 무료 및 유료 API 엔드포인트와 현재 상태가 있습니다. 당신이 자신의 eth1 노드를 운영하든 아니든, 이 조치는 매우 필요합니다.

? 특정 eth2 클라이언트 고장

코드 감사, 감사 및 테스트가 이루어졌음에도 불구하고, eth2 클라이언트의 버그는 어딘가에 숨겨져 있습니다. 그들 중 대부분은 사소한 문제이며, 제품 출시 전에 발견되지만, 당신이 선택한 클라이언트가 오프라인 상태가 되거나 당신이 벌금을 부과받을 가능성이 있습니다. 이러한 상황이 발생하면, 대부분의 사람들이 사용하는 클라이언트를 운영하고 싶지 않을 것입니다 (＞1/3).

당신은 가장 적합한 클라이언트와 그 인기 사이에서 균형을 잡아야 합니다. 다른 클라이언트의 문서를 읽어보는 것을 고려하여, 당신의 노드에 문제가 발생했을 때 다른 클라이언트를 설치하고 구성하는 방법을 알 수 있도록 하십시오.

많은 ETH를 스테이킹했다면, 다른 클라이언트를 운영하는 것이 매우 필요합니다. 모든 계란을 한 바구니에 담지 않도록 하십시오. Vouch는 다중 노드 스테이킹을 제공하는 인프라로, 현재 비밀 공유 검증자 (Secret Shared Validators)도 빠른 발전을 이루고 있습니다.

? 블랙 스완 사건

물론, 가능성이 낮고 예측할 수 없지만 큰 영향을 미치는 사건들이 위험을 초래할 수 있습니다. 이는 당신의 스테이킹 설정 및 결정과는 무관합니다. 예를 들어 하드웨어 수준의 Spectre와 Meltdown, 또는 커널 취약점 (BleedingTooth는 전체 하드웨어 스택에 위험이 존재함을 시사합니다). 즉, 우리는 이러한 문제를 완전히 예측하고 피할 수 없으며, 문제가 발생한 후 적절한 조치를 취해야 합니다.

무엇을 걱정해야 할까요?

결국, 이는 주어진 고장의 기대값 E(X)에 달려 있습니다: 사건 발생 가능성과 해당 사건의 비용. 상관 요인이 처벌 강도에 상당한 영향을 미치므로, eth2 네트워크의 다른 구성원 맥락에서 이러한 고장 사건을 고려하는 것이 중요합니다. 고장의 예상 비용과 이를 희석하는 비용을 비교하면, 시도할 가치가 있는지 판단할 수 있는 합리적인 답을 얻을 수 있습니다.

아무도 노드에서 발생할 수 있는 모든 고장 상황을 알지 못하며, 각 고장이 발생할 가능성도 알지 못하지만, 각 고장 유형의 가능성을 독립적으로 추정하고 최대 위험을 희석함으로써 "집단 지혜"가 작용할 것입니다. 또한, 각 검증자가 직면하는 위험이 다르고 이러한 위험에 대한 평가도 다르기 때문에, 당신이 고려하지 않은 위험이 다른 사람에게 발생할 수 있으므로 상관성이 줄어들 것입니다. 분산화의 힘!

? 당황하지 마세요

마지막으로, 만약 당신의 노드에 정말로 어떤 일이 발생했다면, 당황하지 마세요! 태만 처벌 (inactivity leaks)을 받더라도, 단기적으로 처벌 금액은 크지 않습니다. 무슨 일이 발생했는지, 왜 발생했는지를 차분히 생각한 후 문제를 해결하기 위한 계획을 세우세요. 시작하기 전에 깊게 숨을 쉬세요! 서둘러 잘못된 결정을 내려 벌금을 부과받는 것보다, 자신에게 5분의 생각할 시간을 주는 것이 더 바람직합니다.

가장 중요한 점: ?같은 검증 키로 두 개의 노드를 운영하지 마세요!?

같은 키로 두 개 이상의 검증자를 운영하여 발생한 벌금 - Beaconcha.in