스테이킹 자산의 손실로 이어지는 이더리움 중앙화가 우려되는 이유는 무엇인가요?

이 글에서 Geth 클라이언트로 스테이킹하면 자산 손실이 발생한다고 주장하는 것은 지나친 우려입니다.

작성자는 노드 슬램을 일으킨 이더마인드 클라이언트 장애 사례를 예로 들어 Geth 클라이언트의 84%가 실패할 경우 발생할 수 있는 나쁜 상황을 가정하고 있습니다. 이는 극단적인 가정이며 Geth 클라이언트 중심성 문제를 과도하게 해석한 것이라고 하겠습니다. 간단히 제 생각을 말씀드리면 다음과 같습니다.

1) 이더리움의 노드 클라이언트에는 Geth, Nethrmind, Besu, Erigon, Reth 등과 같은 클라이언트가 포함됩니다. 이러한 실행 클라이언트는 개발자가 블록 외 권한을 실행하기 위한 엔드포인트 구성 옵션일 뿐이며, 체인의 합의, 특히 블록 외 권한과는 직접적인 관련이 없습니다.

단, 일부 개발자는 친숙함이나 비용을 고려하여 이더마인드와 같은 소형 클라이언트를 선택할 수 있는 반면, 다른 개발자는 흐름에 따라 Geth를 선택할 수 있습니다. 개발자가 사용하는 클라이언트 유형에 관계없이, POS에서 블록이 발생할 확률은 담보된 이더와만 관련이 있습니다. Geth 클라이언트의 커버리지 비율이 높기 때문에 직관적으로 대부분의 차단 권한이 Geth에 있는 것처럼 느껴지지만, 실제로는 대부분의 노드가 Geth를 사용하고 상단에 서약한 이더리움의 양이 많기 때문에 논리적 상관관계가 발생하는 것일 뿐입니다.

2) Geth 클라이언트가 메인스트림 클라이언트의 84%를 차지하는 이유에 대해서는 우수한 성능과 호환성, 가장 대중적인 클라이언트라는 점 때문이라고 할 수 있죠. 우수한 성능, 호환성, 풍부한 기능, 성숙도, 안정성을 갖춘 결과입니다. 긍정적인 사이클: Geth의 성능이 좋다 - 개발자들이 활발하다 - 버그가 빠르게 수정된다 - 안정적이고 사용하기 쉽다 - 개발자들이 더 활발하다 - Geth가 더 안정적이고 사용하기 쉽다 - 개발자들이 더 활발하다 - Geth가 더 안정적이고 사용하기 쉽다. -개발자가 더 활동적일수록 Geth의 점유율은 더 커집니다. 이더재단도 지속적인 그랜트를 통해 다른 클라이언트의 비중을 늘리고 있지만, 결과는 도움이 되지 않고 오히려 Geth 클라이언트의 컨센서스가 점점 더 강해지고 있습니다.

글 작성자의 논리대로라면, Geth 클라이언트의 비중이 크기 때문에 일단 Geth에 문제가 발생하면 블록에서 이더가 불안정해져 스테이킹에 큰 문제가 발생하게 되는 것입니다. 그 이유는 이더리움 클라이언트가 좋지 않았다면 블록이 불안정해져 스테이킹에 막대한 슬래시 피해를 입혔을 것이라고 생각하기 쉽지만, 이는 잘못된 명제입니다. 왜냐하면 Geth 클라이언트가 잘 작동하지 않았다면 점유율이 가장 높지 않았을 것이고, 점유율이 높다는 것은 좋은 사용의 결과이기 때문에 가설적으로 Geth 문제가 발생할 확률이 얼마나 될까요? 이 가정이 타당하다고 하더라도 이더리움은 노드 슬래시 문제가 그렇게 단순하지 않고, 하드포크 문제가 연쇄적으로 발생해야 할 수도 있습니다.

3) 스테이킹과 리스테이킹에는 AVS(활동 검증자 세트) 개념이 있어 스테이킹에 참여하는 노드들이 자신의 데이터를 사용할 수 있어야 합니다. 이를 통해 스테이킹에 참여하는 노드는 통신 연결의 안정성, 소프트웨어 안정성 및 버그 수정률, 효과적인 차단 및 검증 프로세스 등을 보장할 수 있습니다.

이것은 스테이킹과 리스테이킹에 참여하는 노드가 Geth 클라이언트를 선호하는 경향이 있으며, 스테이킹 AVS 세트의 노드는 리스테이킹에 계속 참여하려면 성능을 더욱 향상시키기 위해 최종 부하 수준을 높이는 방법을 찾아야 한다는 것을 의미합니다. 따라서 스테이킹과 리스테이킹은 클라이언트 수준에서 경쟁을 더욱 심화시킬 뿐이며, 이는 곧 Geth 클라이언트의 비율이 더욱 증폭될 가능성이 높다는 것을 의미합니다.

따라서 스테이킹과 리스테이크가 중앙화된 Geth 클라이언트의 비중이 높기 때문에 잠재적으로 위험하다는 주장은 명백히 근거가 없습니다.

특히 탈중앙화된 세계에서 중앙화된 Geth 클라이언트의 비율은 항상 문제가 되지만, 이더재단은 스테이킹 및 리스테이킹의 성공과 직접적인 관련이 없는 클라이언트 측의 다양성을 최적화하는 방법을 연구해왔습니다. 이는 스테이킹 및 리스테이킹의 폭발적인 증가와 직접적인 관련이 없으며, 굳이 관여해야 한다면 스테이킹 및 리스테이킹의 확산이 Geth 클라이언트의 중앙 집중화를 더욱 악화시킬 수 있다고 말할 수 있을 뿐입니다. 다만 Geth 클라이언트 중앙화의 위험성에 대해 불평하는 것은 다소 무리가 있습니다.

참고: Geth 클라이언트 중앙화 및 스테이킹의 잠재적 위험을 평가하는 이니셔티브는 실제로 리도 같은 대형 노드 기관의 손에 달려 있으며, 리도가 클라이언트 노드의 다양성을 높이고 다양한 클라이언트 개발자를 후원하기 위해 의식적으로 노력한다면 문제는 개선될 수 있을 것입니다.