Fluffy 클라이언트: Ethereum을 위한 매우 가벼운 클라이언트
클라이언트가 네트워크에 적은 양의 데이터만 제공하면 전체 네트워크(이러한 기여)가 많은 의미를 가질 수 있도록 네트워크를 어떻게 설계할 수 있습니까?
—— Piper Merriam
Nimbus가 Portal Network의 출시 클라이언트 중 하나로 Ethereum Foundation의 "Portal Network" 팀에 합류하게 되었음을 발표하게 되어 기쁩니다.
한 문장 요약: "포털 네트워크"는 이더리움의 라이트 클라이언트를 재구상하고 사용 가능하고 실용적인 라이트 클라이언트 경험을 개발하기 위해 개발 중인 크로스 클라이언트 프로젝트입니다.
사양을 직접 인용하려면:
"포털 네트워크"는 리소스가 제한된 장치의 프로토콜에 대한 경량 액세스를 허용하기 위해 개발 중인 프로젝트입니다.
"게이트웨이"라는 용어는 이러한 네트워크가 프로토콜 작동의 현상 유지를 관찰할 수 있지만 핵심 이더리움 프로토콜 작동에는 무관심하다는 것을 의미합니다.
포털 네트워크는 표준 JSON-RPC API를 노출하는 데 필요한 데이터와 기능을 집합적으로 제공하는 하나 이상의 분산형 P2P 네트워크로 구성됩니다.
이러한 네트워크는 이러한 클라이언트가 가입하기 위해 최소 네트워크 대역폭, CPU, RAM 및 기계 하드 디스크 리소스만 지불하면 되도록 특별히 설계되었습니다.
"포털 네트워크"라는 용어는 이러한 네트워크에 참여하고 표준 JSPN-PRC API를 노출하는 소프트웨어를 설명하는 데에도 사용됩니다.
특히, 우리의 목표는 EF와 협력하여 기존 이더리움 프로토콜을 중심으로 새로운 이더리움 프로토콜 세트를 개발하는 것입니다. 이 프로토콜은 특히 이더리움 데이터에 액세스하는 이 새로운 방법을 제공할 수 있습니다.
전반적인 목표는 전체 상태를 실시간으로 추적하는 것(현재 클라이언트가 수행하는 작업)이 아니라 일반적인 사용 패턴을 제공할 수 있는 이더리움용 운영 모델을 제공하는 것입니다.
우리가 논의하고 있는 것은 지갑을 위한 완벽한 클라이언트, 네트워크에 기여할 수 있지만 블록체인 동기화가 필요하지 않은 매우 가벼운 클라이언트를 개발하는 것입니다(즉, 오프라인 후 다시 시작할 수 있고 설치 후 즉시 사용 가능).
그것은 또한 들리는 것만 큼 어렵지 않습니다. 대부분의 지갑이 라이트 클라이언트를 직접 포함한다고 생각합니다. 예를 들어 @ethstatus는 @ethnimbus 라이트 클라이언트를 통합합니다. 따라서 대부분의 사용자가 자신도 모르는 사이에 라이트 클라이언트를 실행하기 시작하는 상황이 있을 수 있습니다.
May 24, 2021
따라서 우리의 궁극적인 목표 중 하나는 이러한 종류의 클라이언트가 상태 앱에 바로 들어가도록 하는 것입니다.
배경
배경
포털 네트워크는 기존 네트워크 위에 경량 클라이언트를 개발하려는 개발자 Piper Merriam과 Trinity 팀의 원래 목표에 뿌리를 두고 있습니다. 기존 네트워크가 그들이 구상한 클라이언트 유형에 대해 충분히 유연하지 않다는 것을 깨달았기 때문에 탄생했습니다.
파이퍼의 말:
Trinity 클라이언트 개발을 시작했을 때 우리의 목표는 경량 클라이언트를 개발하는 것이었습니다. 그러나 거의 3년 동안 프로토콜을 깊이 있게 이해하고 우리가 구상한 클라이언트를 개발하는 방법을 모색한 후 마침내 기존 네트워크에서는 불가능하다는 결론에 도달했습니다.
이것이 포털 네트워크의 본래 의도입니다. 우리는 원하는 클라이언트 모양으로 돌아가서 작동하는 데 필요한 네트워크 기능을 설계할 것입니다.
첫 번째 레벨 제목
동기 부여(라이트 클라이언트 관점)
기존 DevP2P LES 네트워크는 클라이언트/서버 아키텍처로 설계되어 라이트 클라이언트를 클라이언트로 풀 노드를 서버로 사용합니다(지금까지 "라이트 클라이언트"라는 용어는 기존 DevP2P LES를 네트워크의 클라이언트로 지칭함).
이 아키텍처는 전체 노드에 모든 부하를 할당하고 전체 노드의 운영 비용이 이미 높기 때문에 노드 운영자는 이 기능을 활성화하는 것을 꺼립니다.
따라서 현재 네트워크 설계는 원래 목표를 잘 달성하지만 라이트 클라이언트 관점에서는 크게 실패합니다.
이 문제를 어떻게 해결합니까? Piper의 Trinity 팀이 발견한 것처럼 현실은 이 문제에 대한 쉬운 해결책이 없음을 보여줍니다. 기존 네트워크는 효율적인 라이트 클라이언트 설계를 위해 충분히 유연하지 않습니다.
첫 번째 레벨 제목
설계
가벼운 클라이언트 친화적인 네트워크는 각 노드가 높은 부하(즉, : in 블록체인의 전체 히스토리는 메모리에 보관됩니다.)
즉, 그러한 네트워크는 추가 클라이언트가 네트워크에 가입할 때마다 네트워크 용량이 증가하도록 라이트 클라이언트가 실제로 네트워크에 기여할 수 있도록 허용해야 합니다.
특히 이것은 산발적으로 요청된 데이터의 유효성 검사 오버헤드를 줄이고 네트워크를 통해 메시지를 전달하는 기본 오버헤드를 줄이는 네트워크 설계를 제안하는 것을 의미합니다.
포털 네트워크는 이더리움 프로토콜의 전체 구조를 Gossip(트랜잭션 및 블록) 상태 및 기록의 세 가지 개별 네트워크로 분할하여 이를 수행하는 것을 목표로 합니다. 초기 개발 초점은 상태 네트워크에 있습니다.
이러한 네트워크는 ETH 프로토콜과 공존하지만 ETH 프로토콜과 달리 완전히 무적일 필요는 없지만 거의 쉬지 않고 작동할 수 있어야 합니다.
이러한 새로운 네트워크가 시간이 지남에 따라 기존 네트워크와 더욱 긴밀하게 통합될 수 있기를 바랍니다. 예를 들어, 모든 기능을 갖춘 클라이언트가 기록 포털 네트워크를 사용하여 노드 운영자에게 전체 블록체인(200MB 이상) 대신 관심 있는 기록(200MB)만 저장하는 추가 옵션을 제공할 수 있는 세상을 상상할 수 있습니다. 영국). 상태 데이터도 마찬가지입니다.
대체로 데이터(상태 및 블록체인 기록)가 P2P 방식으로 공유되고 트랜잭션 및 블록이 가십을 통해 전파되는 이 모듈식 아키텍처를 통해 라이트 클라이언트는 데이터 및 기록 데이터를 저장/제공할 상태의 양을 선택할 수 있습니다.
첫 번째 레벨 제목
JSON RPC 참고 사항
중국어 번역중국어 번역): 당사를 포함한 대부분의 지갑은 JSON RPC API를 표준화합니다.
상태 지갑이 올바르게 작동하려면 다음 JSON RPC 엔드포인트가 필요합니다.
eth_blockNumber는 체인의 상단을 추적하는 데 사용됩니다.
eth_getBalance 및 eth_getTransactionCount는 계정 정보를 얻는 데 사용됩니다.
eth_call은 계약 정보를 읽는 데 사용됩니다.
eth_estimateGas 및 eth_gasPrice는 가스 요금을 추정하는 데 사용됩니다.
eth_sendRawTransaction은 사용자의 트랜잭션을 전송하는 데 사용됩니다.
eth_getTransactionReceipt 거래가 온체인된 후 영수증 받기
eth_call, eth_estimateGas, eth_getBalance 및 eth_getTransactionCount를 지원하기 위해 계정 및 계약 저장 항목(상태)에 액세스합니다.
가십 네트워크(Gossip)에 액세스하여 체인의 상단을 따르고 eth_sendRawTransaction
eth_getTransactionReceipt에 사용되는 액세스 체인의 기록(기록)
지갑 기능을 실현하는 데 필요한 구성 요소를 더 분류하면 다음과 같은 하위 수준 요구 사항을 얻을 수 있습니다.
상태, 가십 및 기록에 대한 가벼운 액세스를 제공하는 Portal Networks는 블록체인을 동기화하거나 개인 정보 보호 및 보안 섹스를 희생하지 않고도 이러한 요구를 충족할 수 있는 지갑 내장 라이트 클라이언트의 문을 엽니다.
첫 번째 레벨 제목
프로젝트 상태
우리는 Nimbus를 위한 작동 모드 개발을 시작했습니다. 원래 이름은 nlpn이지만 현재 이름은 푹신푹신합니다. 이 모드는 Ethereum 1 클라이언트와 함께 존재하고 실행될 것입니다.
푹신푹신하면 nimbus-eth1 클라이언트가 네트워크에서 매우 가벼운 클라이언트 노드로 작동할 수 있습니다.
초기 작업은 Node Discovery v5.1 프로토콜 위에 구축된 보조 프로토콜인 Portal Wire 프로토콜을 개발하는 것이었습니다.
다음 단계
다음 단계
다음 단계는 Portal Wire 프로토콜을 통해 데이터를 전송하는 것입니다. 우리는 상태 데이터를 다루고 있습니다.
포털 네트워크에 대한 상태 데이터를 입력하려면 "브리지 노드"가 필요합니다. 현재 접근 방식은 Nethermind 클라이언트 플러그인을 맞춤형 JSON-PRC API로 사용하여 브리지 노드 역할을 하려는 포털 노드에 데이터를 제공하는 것입니다. 이 작업은 이미 시작되었습니다(초안 사양은 여기).
첫 번째 레벨 제목
자원
Nimbus Portal Network Client(nlpn)는 nimbus-eth1 저장소에서 찾을 수 있습니다: https://github.com/status-im/nimbus-eth1/tree/master/fluffy
Portal Wire 프로토콜이 노드 검색 프로토콜 v5.1의 보조 프로토콜로 nim-eth 코드베이스에 추가되었습니다: https://github.com/status-im/nim-eth
사양: https://github.com/ethereum/stateless-ethereum-specs/
홈페이지: https://www.ethportal.net/
ddht 및 trin을 사용한 첫 번째 Portal Wire 프로토콜 테스트에 대한 정보: https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53
Piper Merriam의 블로그 시리즈: 기능적인 라이트 클라이언트로의 구불구불한 길
주제에 대한 비디오 강의
참고: 편리하게 기능적인 라이트 클라이언트를 구현하는 데 필요한 모든 인프라도 자연스럽게 상태 비저장 클라이언트로 확장되므로 상태 비저장 이더리움과 많은 부분이 겹칠 것입니다. 실제로 stateless 클라이언트가 대부분의 JSON-PRC API를 제공할 수 있도록 하는 것은 포털 네트워크의 핵심 동기 중 하나입니다.
