이더리움에 대한 다섯 가지 질문: 클라이언트 다양성 문제는 어디에서 오는가?
편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans)편집자 주: 이 기사의 출처는
이더리움 애호가(ID: ethfans)
이더리움 애호가(ID: ethfans)
최근 90차 핵심 개발자 회의는 거의 내내 한 가지 문제에 전념했습니다. 모든 분들이 이 세션을 직접 들어보시길 강력히 권장합니다.
이 세션에서 Alexey는 클라이언트 개발자 과부하 문제를 제기했습니다. 이 토론이 중요한 시작이라고 생각하지만 우리는 문제를 완전히 이해하기 위한 해결책을 찾기에 너무 열심입니다. 잠시 시간을 내어 문제를 분석하는 것이 중요합니다. 질문의 의미 분석에서 "Five Whys"는 가장 간단하고 효과적인 방법 중 하나입니다.
더 이상 고민하지 않고 첫 번째 질문이 무엇인지 봅시다.
Geth: 75%
Parity & OpenEthereum: 20%
Nethermind: 1%
보조 제목
첫 번째 질문: 왜 Geth 개발팀에 과부하가 걸릴 정도로 압박감이 큰가요?
etherscan을 통해 다음과 같이 각 클라이언트의 설치된 용량 통계를 볼 수 있습니다.
나머지 4%는 시장 점유율이 1% 미만인 일부 클라이언트로 구성되므로 무시됩니다.
중요한 것은 컴퓨팅 파워의 51% 이상이 Geth 클라이언트에 집중되어 있다는 것입니다. 다가오는 베를린 하드 포크에서 Geth가 EIP(Ethereum Improvement Proposals) 중 하나의 구현에 버그가 있다고 가정합니다. 이 클라이언트의 다른 구현에 버그가 없더라도 블록이 이 버그를 만나는 한 이더리움 네트워크가 포크됩니다. 논리적으로 이 블록은 유효하지 않으며 다른 클라이언트는 이를 유효하지 않은 블록으로 취급합니다. 그러나 채굴 노드의 51% 이상이 Geth 클라이언트를 실행하고 있으므로 전체 네트워크가 잘못된 포크 체인으로 이동하게 됩니다.
따라서 첫 번째 질문에 대한 답은 다음과 같습니다.
Ethereum 네트워크의 클라이언트에는 충분한 다양성이 부족하기 때문입니다.
클라이언트 다양화가 갑자기 클라이언트 개발을 쉽게 만들지는 않을 것이라는 점을 언급할 가치가 있습니다. 그러나 클라이언트 다양성 자체는 여전히 탐구할 가치가 있는 영역이며, 이는 개발 팀의 부담을 줄이면서 클라이언트 개발의 효율성을 개선하는 방법을 찾는 데 도움이 될 것입니다. Geth 팀에서 단독으로 작업하는 것이 이 문제를 해결할 가능성이 없다는 것은 부인할 수 없습니다.
보조 제목
두 번째 질문: 이더리움 네트워크에 클라이언트 다양성이 부족한 이유는 무엇입니까?
이더리움 메인넷이 가동되었을 때 우리는 여러 클라이언트를 보유하고 있었습니다. 주요한 것 중 두 가지는 Geth와 CPPEthereum입니다. 그런 다음 Parity가 등장했고 CPPEthereum은 제거되었습니다.
그 이후로 Parity 이외의 어떤 클라이언트도 상당한 시장 점유율을 얻지 못했습니다. 지난해 네더마인드가 떠오르는 샛별으로 떠올랐지만 현재 시장점유율은 1%에 불과하다. 최근 Parity의 시장 점유율은 일부 기복과 Parity의 암울한 미래로 인해 크게 떨어졌습니다. 우리는 이상적으로 이더리움 네트워크가 3개 이상의 클라이언트를 가져야 하고 각 클라이언트의 클라이언트 점유율이 너무 높지 않아야 하며 어떤 클라이언트도 시장 점유율의 51% 이상을 차지할 수 없다고 믿습니다. 이상적으로는 클라이언트 다변화가 이루어져야 하지만 우리는 클라이언트 헤게모니에 익숙합니다.
그렇다면 왜 여러 클라이언트가 필요할까요?
누군가는 뒤쳐져 있는 클라이언트를 지원하고 돕는 방법을 알아내라고 즉시 제안할 수 있습니다. 저는 소프트웨어 개발의 어려운 문제에 더 많은 엔지니어를 투입하는 것이 거의 효과가 없으며 그렇게 될 것이라고 기대하지도 않는 이 "신화적인 맨먼스" 솔루션을 경계합니다.
대신 복잡성에 초점을 맞춰야 한다고 생각합니다.
참고: Mythical Man-Month, Mythical Man-Month는 많은 사람과 짧은 시간이 소프트웨어 개발의 진행을 단축할 수 없음을 지적합니다. 크라우딩은 소프트웨어 생산에 도움이 되지 않으며 문제를 일으키고 더 나쁜 소프트웨어를 생산합니다. 일정보다 뒤쳐진 프로젝트에 인력을 추가하면 일정이 더 늦어질 뿐입니다.
보조 제목
이제 우리는 문제의 근원에 가까워지고 있습니다.
대부분의 어려움은 이더리움 클라이언트 소프트웨어가 서로 연결하고 블록체인에 대한 정보를 공유하는 데 사용하는 도구 세트인 네트워킹 프로토콜에서 비롯된 것으로 밝혀졌습니다. Ethereum의 네트워킹 규칙(devp2p 코드베이스에 정의됨)은 궁극적으로 Ethereum 클라이언트의 설계 및 요구 사항에 영향을 미치고 결정합니다.
일부 네트워킹 도구는 최적화되지 않은 아키텍처를 지정하고 Ethereum 클라이언트가 불필요한 기능을 실행하도록 요구하기도 합니다. 클라이언트 개발자는 이러한 제약 조건 내에서 작업해야 합니다.
보조 제목
질문 4: 네트워크 상호 연결 프로토콜이 클라이언트 구현의 어려움을 증가시키는 이유는 무엇입니까?
이 질문에 대한 답은 기본적으로 두 부분으로 나눌 수 있다고 생각합니다.
상태 관리
전체 네트워크 상호 연결 요구 사항
상태 관리에 관한 한 이더리움 클라이언트는 네트워크에서 전체 상태를 동기화하고 해당 상태의 로컬 복사본을 유지할 수 있어야 합니다. 둘 다 하기가 어렵습니다. 상태를 동기화하려면 상태 요청을 읽고 처리하며 디스크 I/O를 포화시킬 수 있는 클라이언트 및 서버에 대한 수백만 건의 요청이 필요합니다. 데이터베이스가 새 블록을 충분히 빠르게 실행할 수 있도록 새로 동기화된 상태를 유지하고 정리해야 합니다. 공학적 관점에서 이것은 심각한 도전입니다!
GetNodeData는 특정 상태 데이터베이스 형식(일반적으로 "네이티브 레이아웃"이라고 함)에 최적화된 상태 동기화에 사용하는 유일한 네트워킹 도구입니다. Turbo Geth에 의해 대중화된 "플랫" 데이터베이스 레이아웃은 상태 유지 측면에서 큰 성능 이점이 있지만 이 레이아웃을 사용하면 GetNodeData 요청을 처리하기가 더 어려워집니다.
가장 최근 블록에서 생성된 상태에 액세스하기 위한 GetNodeData 요청을 처리합니다.
블록 헤더, 블록 본문 및 영수증을 포함하여 온체인 데이터의 기록에 대한 액세스 요청을 처리합니다.
질문 5: 왜...
해결책
근본 원인에 도달하기 위해 네 가지 "이유"만 물으면 된 것 같습니다. Ethereum 프로토콜은 아직 완전히 성숙하지 않았습니다. 이더리움 프로토콜을 설계할 때 우리는 오늘날 발견되는 대부분의 문제를 인식하지 못했거나 당시에는 상태가 작고 개발 역사가 짧았기 때문에 문제가 되지 않았습니다.
보조 제목
해결책
나는 지난 1년 동안 이 질문을 따라다녔다. 이더리움의 많은 문제의 근원이 실제로 네트워크 계층으로 거슬러 올라갈 수 있다는 사실에 놀랐습니다.
아마도 가장 분명한 예는 디스크 I/O가 역사적으로 클라이언트의 병목 현상이었다는 것입니다. 이 병목 현상은 클라이언트가 트리 구조(Trie)의 순진한 표현을 사용하여 상태 데이터베이스를 구현하는 경향이 있기 때문에 존재합니다. 상태 데이터베이스가 구성되는 방식은 GetNodeData 네트워크 요소에 의해 결정됩니다.
이 문제를 해결하려면 이더리움 합의 계층과 네트워크 계층의 다양한 부분을 점검해야 합니다. 현재 유지 보수 작업이 시작되었습니다. Alexey와 제가 8개월 동안 공동 주도한 "Stateless Ethereum"이라는 이름으로 많은 작업이 이루어졌습니다. 우리가 수행한 작업 중 일부는 Geth 팀이 수년에 걸쳐 개발한 SNAP 동기화 프로토콜을 사용하므로 적어도 부담을 덜었습니다. 여전히 문제를 깊이 이해하고 가능한 해결책을 생각하는 인재들이 맡아야 할 부분이 있습니다.
현재 이러한 거대한 DevP2P ETH 프로토콜은 완전히 해체되지 않았습니다. 우리는 이 네트워크를 세 개의 별도 사설 네트워크로 분할하는 방법에 대한 기본적인 이해가 있지만 아직 아무도 직접 수행하지 않았습니다.
