솔로 스테이킹은 인터넷에 연결된 이더리움 노드를 실행하고 32 ETH를 예치하여 검증자를 활성화하며, 네트워크 합의에 직접 참여할 수 있게 하는 기능입니다.
이더리움 노드는 실행 계층(EL) 클라이언트와 합의 계층(CL) 클라이언트로 이루어져 있습니다. 해당하는 클라이언트는 유효한 서명 키와 함께 작동하는 소프트웨어이며, 블록과 거래를 확인하고, 올바른 체인의 헤드를 증명, 증명을 관리하거나 블록을 제안합니다.
솔로 스테이커는 이러한 클라이언트를 실행하기 위해 필요한 하드웨어를 운영하는 역할을 맞습니다. 이 작업을 위해 집에서 작동하는 전용 컴퓨터를 사용할 것을 강력하게 추천합니다. 네트워크 상태에 큰 도움이 되기 때문입니다.
솔로 스테이커는 검증자가 온라인에서 올바르게 작동하도록 유지하여 프로토콜에서 직접 보상을 받을 수 있습니다.
솔로 스테이킹이 왜 필요한가요?
솔로 스테이킹에는 더 많은 책임이 따르지만, 자금 및 스테이킹 설정에 대한 가장 많은 관리 권한을 제공합니다.
새로운 ETH 얻기
완벽한 제어
네트워크 보안성
솔로 스테이킹 전에 고려할 사항
솔로 스테이킹에 모두 접근할 수 있고 위험 부담이 없기를 바라지만, 현실은 이와 다릅니다. ETH를 솔로 스테이킹하기 전에 염두에 두어야 할 실용적이고 중요한 고려 사항이 있습니다.
자신의 노드를 직접 운영할 때 선택한 소프트웨어를 사용하는 방법에 대해 알아봐야 합니다. 여기에는 관련 문서를 읽거나 해당하는 개발 팀의 통신 채널에 주목하는 것도 포함됩니다. 실행하는 소프트웨어와 지분 증명 작동의 원리를 잘 이해할수록 스테이커로서의 위험 부담이 낮아지며 노드 운영자로서 도중에 발생할 수 있는 문제를 더 쉽게 해결할 수 있습니다.
새로운 도구를 통해 작업이 더 쉬워지더라도 노드를 설치하려면 컴퓨터를 사용하는 작업에 어느 정도 친숙해야 합니다. 명령줄 인터페이스를 이해하는 것이 도움은 되지만 더 이상 반드시 필요한 것은 아닙니다. 또한 매우 기초적인 하드웨어 설치 및 최소 권장 사양에 대해 어느 정도 이해하고 있어야 합니다.
개인 키가 이더리움 주소를 보호하는 방법처럼 검증자를 위한 특별한 키를 생성해야 합니다. 시드 문구 또는 개인 키를 안전하게 보호하는 방법을 반드시 이해해야 합니다.
스테이킹된 ETH를 출금하거나 검증자 잔고에서 보상은 아직 지원되지 않습니다. 인출은 향후 예정된 상하이 업데이트 이후에 지원될 예정입니다. ETH가 최소 1년에서 최대 2년까지 동결된다는 점을 예상하십시오. 상하이 업그레이드 후에는 스테이크 중 일부 또는 모두를 원하는 대로 출금할 수 있습니다.
가끔 하드웨어에 문제가 발생하고, 네트워크 연결에 오류가 생길 때 클라이언트 소프트웨어는 주기적으로 업그레이드해야 합니다. 노드를 유지 관리하는 작업은 꼭 필요하며 가끔 주의를 기울여야 합니다. 예상되는 네트워크 업그레이드 또는 기타 중요한 클라이언트 업그레이드에 대해 알고 있는 것이 좋습니다.
보상은 검증자가 온라인 상태일 때 적절하게 증명 작업에 소요한 시간에 비례합니다. 가동 중지 시간이 발생하면 동일한 시간에 오프라인인 다른 검증자의 수에 비례하여 불이익을 받지만 슬래싱을 당하지는 않습니다. 적시에 받지 못한 증명이 있는 경우 보상이 줄어들기 때문에 대역폭 또한 중요합니다. 요구 사항은 달라질 수 있지만 최소 10Mb/s 내외의 대역폭이 권장됩니다.
오프라인 상태가 되어 받는 비활동 상태에 대한 불이익과는 달리, 슬래싱은 악의적 행동에 대한 훨씬 심각한 불이익입니다. 한 번에 하나의 시스템에만 로드된 키를 사용하여 소수의 클라이언트를 실행하면 슬래시 처리될 위험성이 최소화됩니다. 이를 통해 알 수 있듯이 모든 스테이커는 슬래싱의 위험성을 주의해야 합니다.
<p><a href="https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50/">슬래싱 및 검증자의 주기 자세히 알아보기</a></p>
Comparison with other options
서비스로서 스테이킹(SaaS)
SaaS 제공 업체의 경우 여전히 32 ETH를 예치해야 하지만, 하드웨어를 실행할 필요는 없습니다. 일반적으로 검증자 키에 대한 액세스를 유지하지만 운영자가 검증자를 대신할 수 있도록 서명 키도 공유해야 합니다. 이는 자신의 하드웨어를 실행할 때 존재하지 않는 신뢰 층을 도입하며, 집에서 솔로 스테이킹을 하는 것과 달리 SaaS는 노드의 지리적 배포에 그다지 도움이 되지 않습니다. 하드웨어 운영이 불편하지만 여전히 32 ETH를 스테이킹하려는 경우, SaaS 제공 업체를 이용하는 것이 합당한 선택일 수 있습니다.
솔로 스테이킹은 풀링 서비스에서 스테이킹할 때보다 훨씬 더 복잡하지만, ETH 보상에 대한 완전한 액세스와 검증자의 설정 및 보안에 대한 완벽한 제어를 제공합니다. 풀 스테이킹은 진입 장벽이 현저하게 낮습니다. 사용자는 소량의 ETH를 스테이킹할 수 있으며 검증자 키를 생성하지 않아도 되고, 표준 인터넷 연결 이상의 하드웨어 요건이 없습니다. 유동성 토큰을 사용하면 프로토콜 수준에서 활성화되기 전에 스테이킹을 종료할 수 있습니다. 이러한 기능에 관심이 있다면 풀 스테이킹이 적합할 수 있습니다.
검증자는 이더리움 상에 존재하고 이더리움 합의 프로토콜에 참여하는 가상의 주체입니다. 검증자는 잔고, 공개 키 및 기타 속성으로 나타납니다. 검증자 클라이언트는 검증자의 개인 키를 보유하고 사용하여 검증자 역할을 대신하는 소프트웨어입니다. 하나의 검증자 클라이언트는 여러 개의 키 페어를 보유하며 여러 검증자를 제어할 수 있습니다.
검증자와 연계된 각각의 키 쌍이 활성화되려면 정확히 32 ETH가 필요합니다. 검증자마다 32 ETH의 유효 잔고(opens in a new tab) 제한이 있기 때문에 한 개의 키 세트에 ETH를 더 예치해도 보상이 증가하지는 않습니다. 이는 스테이킹은 32 ETH 단위로 이루어지며 각각 고유한 키와 잔고가 있음을 의미합니다.
하나의 검증자에 32 ETH보다 더 많은 금액을 예치하지 마세요. 이러한 작업이 보상을 증가하지는 않으며 계획된 상하이 업데이트 시기까지 동결됩니다.
솔로 스테이킹이 너무 부담스럽다면 스테이킹 서비스 제공 업체의 이용을 고려해 보세요. 또는 32 ETH보다 적은 금액을 스테이킹하려면 스테이킹 풀을 확인해 보세요.
네트워크가 적절하게 최종 확정될 때 오프라인 상태가 된다고 슬래싱되지는 않습니다. 작은 비활동 패널티는 검증자가 특정 에폭(각 6.4분 길이)에 대해 증명할 수 없는 경우에 발생하지만, 이는 슬래싱과는 완전히 다릅니다. 이 패널티는 검증자가 정상적으로 증명할 수 있는 경우의 보상보다 약간 낮게 설정되며, 손실은 동일한 시간만큼 다시 온라인 연결이 되었을 때 메꿀 수 있습니다.
비활동 패널티의 정도는 같은 시간 동안 오프라인이었던 검증자의 수에 비례한다는 점을 참고하세요. 네트워크의 대부분이 한꺼번에 모두 오프라인이 된 경우, 각 검증자에 대한 불이익은 한 개의 검증자를 사용할 수 없는 경우에 비해 더 큽니다.
극단적으로 만약 1/3 이상의 검증자가 한꺼번에 오프라인이 되어 네트워크가 멈추게 된다면, 각 사용자는 이른바 2차 비활동 누출을 겪게 되며, 오프라인 검증자 계정에서 ETH를 기하급수적으로 잃게 됩니다. 이는 해당하는 비활성 검증자의 잔고가 16 ETH가 되어 검증자 풀에서 자동으로 탈락될 때까지 ETH를 계속 제거함으로써 결국엔 네트워크가 자생할 수 있도록 합니다. 나머지 온라인 검증자들이 다시 네트워크의 2/3 이상을 차지하게 되면 체인은 다시 작동하기 시작합니다.
요약하자면 (물론 100% 확신은 불가하지만) 지침에 따라 한 번에 한 기계에만 서명 키를 유지하는 방식으로 소수 클라이언트를 실행한다면, 슬래싱이 일어날 확률은 거의 0에 가까워지게 됩니다.
검증자가 네트워크에서 슬래싱되어 제거되는 이유는 몇 개밖에 없습니다. 현시점에서 슬래싱은 서명 키가 동시에 두 개의 서로 다른 기계에 보관되는 중복성 하드웨어 설정이 이유였던 경우가 대부분이었습니다. 이는 실수로 키에서 2중 투표가 일어나는 원인이 될 수 있으며, 이러한 경우에 슬래싱 대상으로 간주되기 때문입니다.
대규모 클라이언트(네트워크의 2/3 이상을 사용하는 클라이언트)를 운영하는 경우에도 슬래싱을 당할 수 있으며, 이 클라이언트에 체인 포크를 야기하는 버그가 있을 경우에 발생합니다. 오류로 인한 포크가 일어나서 최종 확정될 수 있습니다. 원래의 체인으로 되돌리려면 확정된 블록을 취소하기 위한 서라운드 투표를 제출해야 합니다. 이 또한 슬래싱의 원인이 될 수 있으며, 단순히 소수 클라이언트를 실행함으로써 피할 수 있습니다.
소수 클라이언트에서 유사한 버그가 발생할지라도 최종 확정되지 않으므로 서라운드 투표 및 슬래싱은 발생하지 않으며, 그저 비활동 패널티로만 그치게 됩니다.
개별 클라이언트는 다양한 팀들이 다양한 언어로 개발한 것이므로 성능과 사용성 면에서 차이를 보일 수 있습니다. 즉, "최고"의 클라이언트는 존재하지 않습니다. 모든 프로덕션 클라이언트는 우수한 소프트웨어이며 블록체인을 활용하고 동기화하기 위한 동일한 핵심 기능을 제공합니다.
모든 프로덕션 클라이언트에서 동일한 기본 기능을 제공하기 때문에 소수 클라이언트를 선택하는 것이 매우 중요합니다. 즉, 현재 네트워크 상에서 아직 검증자들이 많이 사용하고 있지 않은 클라이언트를 선택하는 것이 중요합니다. 처음에는 와닿지 않을 수 있지만, 대다수 혹은 대규모 클라이언트를 실행하면 해당 클라이언트에 버그가 있는 경우에 슬래싱될 가능성이 높아집니다. 소수 클라이언트를 실행하면 이 리스크를 크게 줄입니다.
가상 사설 서버(VPS: Virtual Private Server)가 가정용 하드웨어 대신 사용될 수는 있지만, 검증자 클라이언트의 물리적인 액세스 및 위치가 실제로 중요합니다. 아마존 웹 서비스나 디지털 오션과 같은 중앙화된 클라우드 솔루션은 하드웨어를 직접 소유하고 운영하지 않아도 된다는 편리함을 제공하지만, 네트워크를 중앙화한다는 단점이 있습니다.
하나의 중앙화된 클라우드 스토리지 솔루션에서 더 많은 검증자 클라이언트가 실행될수록 해당 사용자들은 위험해집니다. 해킹, 규제 또는 단순한 정전/인터넷 오류에 의해 해당 서비스가 오프라인이 되는 경우, 이 서버를 사용하는 모든 검증자 클라이언트도 동시에 오프라인이 됩니다.
오프라인 패널티의 정도는 동시에 오프라인 상태에 있는 클라이언트 수에 비례합니다. 따라서 VPS를 사용하면 오프라인 패널티에 대한 리스크를 현저히 증가시키며, 고장이 대규모인 경우에 2차적 누출이나 슬래싱을 당할 리스크 또한 키웁니다. 귀하의 리스크와 네트워크의 리스크를 최소화하기 위해 사용자는 자신의 하드웨어를 확보하고 운영할 것을 강력히 권장합니다.
