포털 네트워크

이더리움은 이더리움 클라이언트 소프트웨어를 실행하는 컴퓨터로 구성된 네트워크입니다. 이러한 각 컴퓨터를 '노드'라고 합니다. 클라이언트 소프트웨어를 통해 노드는 이더리움 네트워크에서 데이터를 보내고 받을 수 있으며, 이더리움 프로토콜 규칙에 따라 데이터를 검증합니다. 노드는 디스크 저장 공간에 많은 양의 기록 데이터를 보관하며 네트워크의 다른 노드로부터 블록이라고 하는 새로운 정보 패킷을 받을 때마다 이를 추가합니다. 이는 노드가 네트워크의 나머지 부분과 일치하는 정보를 가지고 있는지 항상 확인하는 데 필요합니다. 이는 노드를 실행하는 데 많은 디스크 공간이 필요할 수 있음을 의미합니다. 일부 노드 작업에는 많은 RAM이 필요할 수도 있습니다.

이러한 디스크 저장 공간 문제를 해결하기 위해, 모든 정보를 직접 저장하는 대신 전체 노드에 정보를 요청하는 '라이트' 노드가 개발되었습니다. 하지만 이는 라이트 노드가 독립적으로 정보를 검증하지 않고 대신 다른 노드를 신뢰한다는 것을 의미합니다. 이는 또한 전체 노드가 해당 라이트 노드에 서비스를 제공하기 위해 추가 작업을 수행해야 함을 의미합니다.

포털 네트워크는 필요한 데이터를 네트워크 전체에서 작은 조각으로 공유함으로써 전체 노드를 신뢰하거나 추가적인 부담을 주지 않고 "라이트" 노드의 데이터 가용성 문제를 해결하는 것을 목표로 하는 이더리움의 새로운 네트워킹 설계입니다.

노드 및 클라이언트에 대해 더 알아보기

포털 네트워크가 필요한 이유

이더리움 노드는 이더리움 블록체인의 전체 또는 부분 사본을 자체적으로 저장합니다. 이 로컬 사본은 트랜잭션을 검증하고 노드가 올바른 체인을 따르고 있는지 확인하는 데 사용됩니다. 로컬에 저장된 이 데이터를 통해 노드는 다른 개체를 신뢰할 필요 없이 들어오는 데이터가 유효하고 올바른지 독립적으로 검증할 수 있습니다.

이러한 블록체인의 로컬 사본과 관련 상태 및 영수증 데이터는 노드의 하드 디스크에서 많은 공간을 차지합니다. 예를 들어, Geth (opens in a new tab)를 합의 클라이언트와 페어링하여 노드를 실행하려면 2TB 하드 디스크가 권장됩니다. 비교적 최근의 블록 세트에서 체인 데이터만 저장하는 스냅 동기화를 사용하면 Geth는 일반적으로 약 650GB의 디스크 공간을 차지하지만 주당 약 14GB씩 증가합니다(주기적으로 노드를 650GB로 다시 정리할 수 있습니다).

이는 많은 양의 디스크 공간이 이더리움에 할당되어야 하므로 노드를 실행하는 데 비용이 많이 들 수 있음을 의미합니다. 이더리움 로드맵에는 히스토리 만료, 상태 만료, 무상태성 등 이 문제에 대한 몇 가지 해결책이 있습니다. 하지만, 이러한 기능이 구현되려면 몇 년이 걸릴 것으로 보입니다. 체인 데이터의 자체 사본을 저장하지 않고 전체 노드에서 필요한 데이터를 요청하는 라이트 노드도 있습니다. 하지만 이는 라이트 노드가 정직한 데이터를 제공하는 전체 노드를 신뢰해야 하며, 라이트 노드가 필요로 하는 데이터를 제공해야 하는 전체 노드에 부담을 준다는 것을 의미합니다.

포털 네트워크는 라이트 노드가 전체 노드에서 수행해야 하는 작업에 대한 신뢰나 상당한 추가 작업 없이 데이터를 얻을 수 있는 대안적인 방법을 제공하는 것을 목표로 합니다. 이를 위해 이더리움 노드가 네트워크 전체에서 데이터를 공유할 수 있는 새로운 방법을 도입할 것입니다.

포털 네트워크는 어떻게 작동하나요?

이더리움 노드에는 서로 통신하는 방법을 정의하는 엄격한 프로토콜이 있습니다. 실행 클라이언트는 DevP2P로 알려진 하위 프로토콜 세트를 사용하여 통신하는 반면, 합의 클라이언트는 libP2P라는 다른 하위 프로토콜 스택을 사용합니다. 이는 노드 간에 전달될 수 있는 데이터 유형을 정의합니다.

노드는 JSON-RPC API를 통해 특정 데이터를 제공할 수도 있으며, 이를 통해 앱과 지갑이 이더리움 노드와 정보를 교환합니다. 하지만 이들 중 어느 것도 라이트 클라이언트에 데이터를 제공하기에 이상적인 프로토콜은 아닙니다.

라이트 클라이언트는 현재 DevP2P 또는 libP2p를 통해 특정 체인 데이터를 요청할 수 없습니다. 왜냐하면 이러한 프로토콜은 체인 동기화와 블록 및 트랜잭션의 가십(gossiping)을 가능하게 하도록 설계되었기 때문입니다. 라이트 클라이언트는 이 정보를 다운로드하고 싶어하지 않습니다. 그렇게 하면 "라이트"라는 특성을 잃게 되기 때문입니다.

JSON-RPC API 또한 라이트 클라이언트 데이터 요청에 이상적인 선택이 아닙니다. 왜냐하면 데이터를 제공할 수 있는 특정 전체 노드 또는 중앙화된 RPC 제공자와의 연결에 의존하기 때문입니다. 이는 라이트 클라이언트가 특정 노드/제공자가 정직하다고 신뢰해야 하며, 전체 노드는 많은 라이트 클라이언트로부터 수많은 요청을 처리해야 하므로 대역폭 요구 사항이 추가될 수 있음을 의미합니다.

포털 네트워크의 핵심은 기존 이더리움 클라이언트의 설계 제약에서 벗어나, 가벼움을 위해 특별히 구축하여 전체 설계를 재고하는 것입니다.

포털 네트워크의 핵심 아이디어는 기록 데이터 및 현재 체인 헤드의 ID와 같이 라이트 클라이언트가 필요로 하는 정보를 DHT (opens in a new tab)(비트토렌트와 유사)를 사용하는 경량 DevP2P 스타일의 P2P(peer-to-peer) 탈중앙화 네트워크를 통해 제공함으로써 현재 네트워킹 스택의 가장 좋은 부분을 취하는 것입니다.

아이디어는 전체 이더리움 기록 데이터의 작은 부분과 일부 특정 노드 책임을 각 노드에 추가하는 것입니다. 그런 다음, 요청된 특정 데이터를 저장하는 노드를 찾아내고 그들로부터 데이터를 검색하여 요청을 처리합니다.

이는 라이트 노드가 단일 노드를 찾아 대용량 데이터를 필터링하고 제공하도록 요청하는 일반적인 모델을 뒤집습니다. 대신, 각각 소량의 데이터를 처리하는 대규모 노드 네트워크를 신속하게 필터링합니다.

목표는 경량 포털 클라이언트의 탈중앙화 네트워크가 다음을 수행할 수 있도록 하는 것입니다.

• 체인 헤드 추적
• 최신 및 과거 체인 데이터 동기화
• 상태 데이터 검색
• 트랜잭션 브로드캐스트
• EVM을 사용하여 트랜잭션 실행

이 네트워크 설계의 이점은 다음과 같습니다.

• 중앙화된 제공자에 대한 의존도 감소
• 인터넷 대역폭 사용량 감소
• 최소화 또는 제로 동기화
• 리소스가 제한된 장치에서 접근 가능(<1GB RAM, <100MB 디스크 공간, 1 CPU)

아래 표는 포털 네트워크를 통해 제공될 수 있는 기존 클라이언트의 기능을 보여주며, 사용자는 매우 저사양 장치에서 이러한 기능에 접근할 수 있습니다.

포털 네트워크

기본적인 클라이언트 다양성

포털 네트워크 개발자들은 또한 처음부터 4개의 개별 포털 네트워크 클라이언트를 구축하기로 설계 결정을 내렸습니다.

포털 네트워크 클라이언트는 다음과 같습니다.

• Trin (opens in a new tab): Rust로 작성됨
• Fluffy (opens in a new tab): Nim으로 작성됨
• Ultralight (opens in a new tab): Typescript로 작성됨
• Shisui (opens in a new tab): Go로 작성됨

여러 개의 독립적인 클라이언트 구현이 있으면 이더리움 네트워크의 복원력과 탈중앙화가 향상됩니다.

한 클라이언트에 문제나 취약점이 발생하더라도 다른 클라이언트는 원활하게 계속 작동하여 단일 실패 지점을 방지할 수 있습니다. 또한, 다양한 클라이언트 구현은 혁신과 경쟁을 촉진하여 생태계 내 개선을 이끌고 단일 문화의 위험을 줄입니다.

더 읽어보기

• 포털 네트워크 (Devcon 보고타에서 Piper Merriam 발표) (opens in a new tab).
• 포털 네트워크 디스코드 (opens in a new tab)
• 포털 네트워크 웹사이트 (opens in a new tab)