포털 네트워크
이더리움은 이더리움 클라이언트 소프트웨어를 실행하는 컴퓨터들로 구성된 네트워크입니다. 이러한 각각의 컴퓨터를 '노드'라고 부릅니다. 클라이언트 소프트웨어를 통해 노드는 이더리움 네트워크에서 데이터를 주고받을 수 있으며, 이더리움 프로토콜 규칙에 따라 데이터를 검증합니다. 노드는 디스크 저장소에 많은 과거 데이터를 보관하며, 네트워크의 다른 노드로부터 블록이라고 알려진 새로운 정보 패킷을 수신할 때마다 이를 추가합니다. 이는 노드가 네트워크의 나머지 부분과 일치하는 정보를 가지고 있는지 항상 확인하기 위해 필요합니다. 이는 노드를 실행하는 데 많은 디스크 공간이 필요할 수 있음을 의미합니다. 일부 노드 작업은 많은 RAM을 요구하기도 합니다.
이러한 디스크 저장소 문제를 해결하기 위해, 모든 정보를 직접 저장하는 대신 풀 노드에 정보를 요청하는 '라이트' 노드가 개발되었습니다. 하지만 이는 라이트 노드가 정보를 독립적으로 검증하지 않고 다른 노드를 신뢰한다는 것을 의미합니다. 또한 풀 노드가 이러한 라이트 노드에 데이터를 제공하기 위해 추가적인 작업을 수행해야 함을 의미하기도 합니다.
포털 네트워크는 네트워크 전체에 필요한 데이터를 작은 조각으로 공유함으로써, 풀 노드를 신뢰하거나 추가적인 부담을 주지 않고 "라이트" 노드의 데이터 가용성 문제를 해결하는 것을 목표로 하는 이더리움의 새로운 네트워킹 설계입니다.
노드와 클라이언트에 대해 더 알아보기
포털 네트워크가 필요한 이유
이더리움 노드는 이더리움 블록체인의 전체 또는 부분 사본을 자체적으로 저장합니다. 이 로컬 사본은 트랜잭션을 검증하고 노드가 올바른 체인을 따르고 있는지 확인하는 데 사용됩니다. 이렇게 로컬에 저장된 데이터를 통해 노드는 다른 주체를 신뢰할 필요 없이 수신되는 데이터가 유효하고 올바른지 독립적으로 검증할 수 있습니다.
이러한 블록체인의 로컬 사본과 관련 상태 및 영수증 데이터는 노드의 하드 디스크에서 많은 공간을 차지합니다. 예를 들어, 합의 클라이언트와 쌍을 이루는 Geth (opens in a new tab)를 사용하여 노드를 실행하려면 2TB 하드 디스크가 권장됩니다. 비교적 최근 블록 세트의 체인 데이터만 저장하는 스냅 동기화를 사용할 경우, Geth는 일반적으로 약 650GB의 디스크 공간을 차지하지만 매주 약 14GB씩 증가합니다(주기적으로 노드를 프루닝하여 다시 650GB로 줄일 수 있습니다).
이는 이더리움을 위해 많은 디스크 공간을 할당해야 하므로 노드 실행 비용이 많이 들 수 있음을 의미합니다. 이더리움 로드맵에는 이 문제에 대한 몇 가지 해결책이 있으며, 여기에는 기록 만료, 상태 만료 및 무상태성이 포함됩니다. 하지만 이들이 구현되기까지는 수년이 걸릴 가능성이 높습니다. 또한 체인 데이터의 자체 사본을 저장하지 않고 필요한 데이터를 풀 노드에 요청하는 라이트 노드도 있습니다. 그러나 이는 라이트 노드가 정직한 데이터를 제공할 것이라고 풀 노드를 신뢰해야 함을 의미하며, 라이트 노드가 필요로 하는 데이터를 제공해야 하는 풀 노드에게도 부담을 줍니다.
포털 네트워크는 풀 노드를 신뢰하거나 풀 노드가 해야 할 작업을 크게 늘리지 않고도 라이트 노드가 데이터를 얻을 수 있는 대안적인 방법을 제공하는 것을 목표로 합니다. 이를 달성하는 방법은 이더리움 노드가 네트워크 전체에서 데이터를 공유하는 새로운 방식을 도입하는 것입니다.
포털 네트워크는 어떻게 작동하나요?
이더리움 노드에는 서로 통신하는 방법을 정의하는 엄격한 프로토콜이 있습니다. 실행 클라이언트는 devp2p로 알려진 하위 프로토콜 세트를 사용하여 통신하는 반면, 합의 클라이언트는 libp2p라는 다른 하위 프로토콜 스택을 사용합니다. 이들은 노드 간에 전달될 수 있는 데이터의 유형을 정의합니다.
노드는 또한 JSON-RPC API를 통해 특정 데이터를 제공할 수 있으며, 이는 앱과 지갑이 이더리움 노드와 정보를 스왑하는 방식입니다. 하지만 이들 중 어느 것도 경량 클라이언트에 데이터를 제공하기에 이상적인 프로토콜은 아닙니다.
경량 클라이언트는 현재 devp2p나 libp2p를 통해 특정 체인 데이터를 요청할 수 없습니다. 해당 프로토콜들은 체인 동기화와 블록 및 트랜잭션의 가십(gossip) 전파만을 가능하게 하도록 설계되었기 때문입니다. 경량 클라이언트는 이러한 정보를 다운로드하는 것을 원하지 않는데, 그렇게 하면 더 이상 "경량"이 아니게 되기 때문입니다.
JSON-RPC API 역시 경량 클라이언트의 데이터 요청에 이상적인 선택은 아닙니다. 데이터를 제공할 수 있는 특정 풀 노드나 중앙화된 RPC 제공자에 대한 연결에 의존하기 때문입니다. 이는 경량 클라이언트가 해당 특정 노드/제공자가 정직하다고 신뢰해야 함을 의미하며, 또한 풀 노드가 많은 경량 클라이언트로부터의 수많은 요청을 처리해야 하므로 대역폭 요구 사항이 증가할 수 있습니다.
포털 네트워크의 핵심은 기존 이더리움 클라이언트의 설계 제약에서 벗어나, 경량성을 위해 특별히 전체 설계를 재고하는 것입니다.
포털 네트워크의 핵심 아이디어는 현재 네트워킹 스택의 장점을 취하는 것입니다. 즉, 과거 데이터나 현재 체인 헤드의 식별자와 같이 경량 클라이언트에 필요한 정보를 DHT (opens in a new tab)(비트토렌트와 유사)를 사용하는 경량화된 devp2p 스타일의 피어 투 피어 탈중앙화된 네트워크를 통해 제공할 수 있게 합니다.
이 아이디어는 전체 이더리움 과거 데이터의 작은 부분과 일부 특정 노드 책임을 각 노드에 추가하는 것입니다. 그런 다음, 요청된 특정 데이터를 저장하고 있는 노드를 찾아 그들로부터 데이터를 검색하여 요청을 처리합니다.
이는 라이트 노드가 단일 노드를 찾아 대량의 데이터를 필터링하고 제공하도록 요청하는 일반적인 모델을 뒤집습니다. 대신, 각각 적은 양의 데이터를 처리하는 대규모 노드 네트워크를 빠르게 필터링합니다.
목표는 경량 포털 클라이언트로 구성된 탈중앙화된 네트워크가 다음을 수행할 수 있도록 하는 것입니다.
- 체인의 헤드 추적
- 최근 및 과거 체인 데이터 동기화
- 상태 데이터 검색
- 트랜잭션 브로드캐스트
- EVM을 사용한 트랜잭션 실행
이러한 네트워크 설계의 이점은 다음과 같습니다.
- 중앙화된 제공자에 대한 의존도 감소
- 인터넷 대역폭 사용량 감소
- 동기화 최소화 또는 불필요
- 리소스가 제한된 기기(<1GB RAM, <100MB 디스크 공간, 1 CPU)에서도 접근 가능
아래 표는 포털 네트워크를 통해 제공될 수 있는 기존 클라이언트의 기능을 보여주며, 사용자가 매우 낮은 사양의 기기에서도 이러한 기능에 접근할 수 있게 해줍니다.
포털 네트워크
| 비콘 경량 클라이언트 | 상태 네트워크 | 트랜잭션 가십 | 기록 네트워크 | 표준 트랜잭션 인덱스 |
|---|---|---|---|---|
| 비콘 체인 라이트 | 계정 및 컨트랙트 저장소 | 경량 멤풀 | 헤더 | TxHash > 해시, 인덱스 |
| 프로토콜 데이터 | 블록 바디 | |||
| 영수증 |
기본적으로 제공되는 클라이언트 다양성
포털 네트워크 개발자들은 또한 첫날부터 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로 작성됨
여러 개의 독립적인 클라이언트 구현체를 보유하는 것은 이더리움 네트워크의 회복탄력성과 탈중앙화를 향상시킵니다.
한 클라이언트에 문제나 취약점이 발생하더라도 다른 클라이언트가 계속해서 원활하게 작동할 수 있어 단일 장애점(single point of failure)을 방지합니다. 또한, 다양한 클라이언트 구현체는 혁신과 경쟁을 촉진하여 생태계 내에서 개선을 주도하고 단일 문화(monoculture)의 위험을 줄입니다.