블록체인 인프라의 중요한 구성 요소입니다. 이들은 분산 불변 원장과 프런트엔드 애플리케이션 간의 통신을 처리합니다. 이러한 중개 인프라는 블록체인에 구축된 노드와 서비스 간의 요청과 응답을 용이하게 하는 메신저 역할을 합니다. RPC(원격 프로시저 호출) 노드는 RPC 노드는 dApp에서 블록체인으로, 그리고 다시 블록체인으로 정보를 옮기는 것을 용이하게 하는 미국 우편 서비스(USPS)와 같습니다. 우편 서비스를 통해 한 지점에서 다른 지점으로 우편물을 전달하는 것처럼, dApp은 RPC 노드를 통해 블록체인에 액세스합니다. 그리고 이러한 노드가 없다면 분산형 애플리케이션은 작동하기 어려울 것입니다. RPC 노드는 지난 10년 동안 상당히 발전했지만 인프라의 중앙 집중화로 인해 숨겨진 취약점이 생겨났습니다. 이 글에서는 RPC 노드의 역할, 중앙 집중화의 위험성, 그리고 dApp을 취약점으로부터 보호할 수 있는 대안을 살펴보겠습니다. RPC 인프라의 진화 원격 프로시저 호출이라는 개념은 1970년대로 거슬러 올라가는데, 당시 컴퓨터 과학자들은 분산 컴퓨터를 개발자에게 투명하게 만들기 위해 서로 다른 컴퓨터 간의 통신 방법을 모색했습니다. 1980년대에 최초의 RPC는 Sun Microsystem에서 Network File System이라는 이름으로 개발되었습니다. Sun Microsystem은 Open Network Computing RPC 프로토콜을 개발했고, 이는 네트워크의 여러 프로그램 간 통신을 위한 표준이 되었습니다. 그러나 1990년대 초에 Microsoft는 Windows 기반 시스템에서 프로세스 간 통신을 가능하게 하는 RPC 버전을 개발하고 구현했습니다. 2000년대 초에 JSON을 데이터 인코딩에 사용하는 JSON RPC가 도입되었습니다. 표준화된 데이터를 전송하기 쉽기 때문에 개발자와 프로그래머 사이에서 악명을 떨쳤습니다. 지난 10년 동안 dApp은 블록체인 산업의 중요한 부분이 되었으며 RPC는 이 미로를 완성하는 데 필요한 완벽한 인프라가 되었습니다. 왜? 다른 컴퓨터에서 로컬 함수 호출처럼 원격 함수 호출을 할 수 있는 기능은 블록체인 아키텍처에 완벽합니다. 블록체인의 무상태성과 가벼움은 블록체인의 힘을 강화하고 대역폭과 컴퓨팅 제약 상황을 해결하는 데 도움이 됩니다. 이러한 이점 때문에 RPC는 빠르게 널리 사용되었습니다. RPC는 다양한 언어로 작성된 애플리케이션이 연결하고 통신할 수 있도록 제안되었습니다. RPC의 기본 아이디어는 마치 로컬 함수 호출인 것처럼 다른 컴퓨터나 서버에서 원격 함수 호출을 하는 것입니다. 수년에 걸쳐 세 가지 주요 RPC 유형(중앙 집중형, 분산형, 자체 호스팅)이 존재했으며 각각 고유한 방식을 가지고 있습니다. 중앙화된 RPC 노드의 위험 중앙 집중형 RPC 노드는 단일 엔티티가 관리하고 제어하는 노드입니다. 이러한 중앙 집중형 노드는 AWS(Amazon Web Services), Microsoft Azure, Google Cloud Protocol(GCP)과 같은 웹2 클라우드 호스팅 서비스와 유사한 모델을 가지고 있습니다. 이러한 중앙 집중형 web3 RPC 제공자는 분산형 애플리케이션을 위한 노드 인프라를 유지하지만, 시스템을 자세히 살펴보면 얼마나 중앙 집중화되어 있는지 드러났습니다. 이러한 web3 인프라 제공자는 아이러니하게도 서비스를 유지하기 위해 web2 클라우드 호스팅 서버 인프라에 의존하고 있습니다. 따라서 이러한 클라우드 제공자가 중단을 겪을 때 분산화되어야 하는 web3 서비스도 다운타임을 겪습니다. 중앙화된 RPC 노드의 예는 다음과 같습니다: Alchemy, Infura, Quicknode 등. 중앙 집중식 RPC 노드가 Web3 인프라에 미치는 위험을 살펴보겠습니다. 단일 장애점은 항상 시스템 안정성에 영향을 미칩니다. 단일 엔터티가 제어하는 단일 서버 또는 서버 네트워크는 dApp의 실패로 이어질 수 있는 중요한 지점을 도입합니다. 단일 장애점: 데이터가 라우팅되는 서버에 장애가 발생하면 블록체인과 dApp 간의 링크가 끊어지고 시스템이 실패합니다. 단일 장애점은 특히 DeFi 플랫폼과 같은 금융 관련 앱에서 시스템의 안정성에 영향을 미칩니다. : 중앙 집중형 RPC 노드는 트래픽이 많은 시간에 병목 현상이 될 수 있으며, 이는 dApp의 확장성을 제한합니다. 단일 노드에 의존하여 네트워크가 혼잡해지면 dApp의 효율성에 영향을 미치고 지연 시간을 늘려 사용자에게 영향을 미칩니다. 확장성 문제 중앙 집중형 시스템이기 때문에 dApp의 확장성을 높이는 것은 불가능합니다. 중앙 집중형 또는 전용 노드는 취약성에 노출되어 있으며, 파렴치한 개인의 쉬운 표적이 될 수 있습니다. 데이터는 노출되고 조작될 수 있으며, 궁극적으로 dApp의 의사 결정에 영향을 미칠 수 있습니다. 보안 위험 및 취약성: 게다가, 공급자에 대한 조정된 공격도 쉽게 구현될 수 있으며, 궁극적으로 Dapp 사용자를 노출시킵니다. 단일 엔터티는 정부 기관에 의해 애플리케이션을 종료하도록 강요받을 수 있습니다. 다음은 그 예입니다. 2022년에 MetaMask는 베네수엘라와 이란 IP 주소를 가진 사용자가 블록체인에서 거래를 수행하는 것을 차단한 것으로 알려졌습니다. 이는 web3 지갑에서 사용하는 중앙집중형 RPC(Infura) 덕분에 가능했습니다. 중앙화된 RPC 노드 실패 및 취약성에 대한 사례 연구 중앙집중형 RPC는 안전해 보일 수 있지만 그렇지 않습니다. 그래도 의심이 든다면, 중앙집중형 RPC의 과거 실패 사례 연구를 살펴보겠습니다. 인푸라의 경우 합의를 통해 제공되는 web3의 최초 블록체인 백엔드 인프라 서비스(IaaS) 제공자 중 하나입니다. 이 인프라는 99.9% 가동 시간으로 사용할 수 있으며 16개의 블록체인 EVM에서 사용할 수 있다고 합니다. Infura는 2020년까지 Infura는 dApp 개발의 최전선 중 하나이며 암호화폐/블록체인의 대중적 도입을 선도하는 인물로 영웅으로 여겨져 왔습니다. 2020년 11월 11일, Infura에서 운영하는 GEth 버전에 영향을 미치는 버그로 인해 서비스가 중단되었습니다. 여기서 가장 큰 문제는 Infura 시스템이 다운되어 모든 Infura 인프라 사용자가 블록체인에 연결할 수 없었다는 것입니다. 버그로 인해 서버가 중단되었고 분산형 네트워크 뒤에 중앙 집중화의 위험이 드러났습니다. 수백만 명의 활성 사용자를 보유한 가장 큰 소비자 대상 Ethereum 지갑인 Metamask가 중단되었습니다. 이는 모두 중앙 집중형 RPC 공급자인 Infura에 의존하기 때문입니다. 네트워크 업그레이드 중 중앙 집중화 문제 네트워크 업그레이드/하드포크 중에는 일반적으로 서비스 장애에 대한 우려가 있는데, 특히 중앙 집중형 인프라 공급자에 의존하는 dAapp과 관련된 우려가 있습니다. 이러한 우려에는 다음이 포함됩니다. 활동을 방해하고 가동 중지로 이어질 수 있는 단일 장애 지점. 다음은 몇 가지 과거 사례입니다. 동안 많은 중앙화된 RPC 제공자가 다운타임을 경험했습니다. 이러한 다운타임 중 일부는 네트워크가 업그레이드를 거치는 데 따른 것입니다. DeFi 앱은 거래를 처리할 수 없어 사용자는 난처한 처지에 처했습니다. 2019년 이더리움 이스탄불 하드포크 동안 RPC 서비스 제공자는 연결 문제에 직면했고 블록체인 네트워크와 동기화되지 않았습니다. 사용자는 몇 시간 동안 DeFi dApp에 액세스할 수 없었기 때문에 거래가 지연되거나 실패했습니다. Polygon Heimdall 업그레이드 2021년 솔라나 RPC 과부하 2021년에 여러 차례 중단을 겪었습니다. 악명 높은 중단 중 하나는 피크 기간 동안 중앙 집중형 RPC 서비스가 과부하되어 발생했습니다. 퍼블릭 노드가 과부하되면서 사용자는 몇 시간 동안 Solana Blockchain과 상호 작용할 수 없었고 네트워크는 몇 시간 동안 전체 서비스가 중단되었습니다. Solana는 이러한 페이스팜 사례와 수많은 다른 사례는 블록체인 유틸리티에 대한 RPC 제공자의 중요성을 보여줍니다. 중앙 집중형 제공자는 여전히 많은 dApp에서 사용되고 있지만(아마도 무지나 사려 없음으로 인해), 수년에 걸쳐 대안이 있었습니다. 다음 섹션에서는 다른 대안에 대해 살펴보고 그것들이 블록체인 개발에 있어서 어떻게 훌륭한 옵션이 되는지 알아보겠습니다. DApp 분산화: 중앙 집중형 RPC 노드에 대한 최고의 대안 자체 호스팅 RPC 노드 이름에서 알 수 있듯이 셀프호스팅 RPC 노드는 자체 하드웨어 또는 클라우드 인프라에서 호스팅하거나 관리하는 노드입니다. 타사 RPC 공급자에 의존하는 대신 자체 RPC 노드를 호스팅할 수 있습니다. 블록체인 네트워크에 직접 액세스하고, 거래를 검증하고, 블록체인 데이터를 직접 쿼리하고, dApp과 상호 작용합니다. 셀프호스팅 RPC 노드의 이점은 다음과 같습니다. : 노드를 실행한다는 것은 노드 구성을 완전히 제어할 수 있다는 것을 의미합니다. 필요에 맞게 소프트웨어를 사용자 정의하고, 재량에 따라 업데이트를 적용하고, 보안을 관리할 수 있습니다. 자율성/제어 : 제3자 중앙 노드에서 흔히 발생하는 공급자 문제로 인한 서비스 중단이나 장애를 찾아볼 필요가 없습니다. 안정성 : 인프라에서 노드를 실행한다는 것은 해당 서비스에 대한 책임이 있고 블록체인 네트워크에 저지연으로 접근할 수 있다는 것을 의미합니다. 직접 네트워크 접근 셀프호스팅 노드는 중앙집중형 대안보다 더 신뢰할 수 있는 것처럼 보이지만, 단점도 있습니다. 그리고 그 단점은 다음과 같습니다. . RPC 노드를 호스팅하려면 블록체인 기록을 저장하기 위한 상당한 디스크 공간이 필요합니다. RPC 노드를 실행하는 데 필요한 스토리지, 대역폭 및 처리 능력은 엄청날 수 있습니다. 높은 리소스 요구 사항 게다가 블록체인과 지속적으로 동기화해야 하며, 이는 엄청난 양의 대역폭을 소모할 수 있으며, 이는 압도적일 수 있습니다. 필요한 처리 능력도 압도적일 수 있으며, 특히 트래픽이 많은 상황에서 정보를 처리할 때 더욱 그렇습니다. : 셀프호스팅 노드를 설정하는 것이 더 나은 옵션인 듯하지만 그렇지 않다. 하드웨어 비용, 운영 비용, 기회 비용이 엄청날 수 있다. 관리 비용이 많이 든다 전기, 인터넷 대역폭, 클라우드 서비스 요금(클라우드 인프라를 사용하는 경우)과 같은 운영 비용은 엄청날 수 있습니다. 성공적인 노드를 실행하려면 문제를 해결하기 위해 대기하는 전담 전문가 팀이 필요하거나 몇 시간 동안 중단될 위험이 있습니다. : 블록체인 기술, 서버 관리 및 보안 모범 사례에 대한 확실한 이해가 필요합니다. 소프트웨어 업데이트, 보안 패치 및 하드웨어 업그레이드와 같은 중단을 방지하기 위한 정기적인 유지 관리를 통해 노드가 제대로 작동하도록 유지합니다. 복잡한 설정 및 유지 관리 : 이 문제를 처리할 수 있는 모델을 갖춘 타사 공급업체와 달리 여러 블록체인과 상호 작용하려면 각 블록체인에 대한 노드를 호스팅해야 하며, 이는 리소스가 많이 필요하고 지속 불가능합니다. 제한된 확장성 및 멀티체인 지원 미비 자체 호스팅 노드는 독립성, 블록체인 상호작용에 대한 뛰어난 제어 및 프라이버시를 제공합니다. 상당한 리소스, 기술 전문성 및 유지 관리가 필요하며, 이는 가장 강력한 블록체인 개발 팀조차도 불가능할 수 있습니다. 분산형 RPC 노드 분산형 RPC는 dApp이 분산 방식으로 블록체인과 통신할 수 있도록 하는 블록체인 서버입니다. 분산형 RPC 제공자는 인프라를 여러 노드에 분산합니다. 이를 통해 단일 장애 지점이 줄어들고, 네트워크 안정성과 확장성이 향상되며, 지연 시간이 줄어듭니다. 다른 노드에 비해 분산형 RPC 노드의 이점은 다음과 같습니다. : 노드 제공자의 분산 네트워크는 요청을 처리하고, 쿼리에 응답하고, 블록체인과 상호 작용합니다. 분산 네트워크 : 단일 공급자를 신뢰하지 않습니다. 요청은 여러 공급자에 분산되어 단일 당사자가 데이터나 요청을 완전히 제어할 수 없습니다. 운영은 신뢰할 수 없습니다 : RPC 노드가 동일한 관할권에 위치하지 않기 때문에 엔터티/권한은 블록체인에 대한 액세스를 쉽게 검열, 차단 또는 제한할 수 없습니다. 관할권의 정책으로 인해 RPC 인프라가 중단되면 dApp의 요청은 다른 관할권의 다른 RPC 노드로 라우팅될 수 있습니다. 검열 저항성 : RPC 서비스의 분산 모델은 중단에 대한 저항성을 제공합니다. 노드가 다운되면 다른 노드가 서비스를 대체합니다. 이렇게 하면 다운타임이 줄어들고 일관된 가용성이 보장됩니다. 장애 허용 과제는 다음과 같습니다. : 제대로 설정하지 않으면 분산 RPC 서비스는 여러 노드를 통해 라우팅될 수 있으므로 지연을 유발할 수 있습니다. RPC 노드의 분산은 쉽게 중복될 수 있으며, 그 결과 데이터가 여러 서버를 통해 라우팅되어 지연이 증가할 수 있습니다. 지연 : 노드는 여러 엔티티에 의해 관리되므로 노드의 보안이 동일하지 않을 수 있습니다. 보안 : 일관되고 신뢰할 수 있는 데이터를 보장하는 것은 어려울 수 있습니다. 악성/오류 노드를 감지하고 완화하기 위한 메커니즘이 필요합니다. 노드 간 합의 분산형 RPC 노드의 예는 다음과 같습니다. dRPC, Pocket 네트워크 및 Ankr dApp 개발에서 중앙화 위험을 피하기 위한 모범 사례 노드 제공자의 다양화 dRPC와 같은 분산형 RPC 노드 공급자를 선택하면 중앙화 위험을 피할 수 있습니다. 분산형 RPC 공급자는 로드 밸런서, 노드 공급자 모니터링, 우수한 행위자에 대한 인센티브와 같은 필요한 기능으로 노드가 작동하도록 보장하는 시스템을 갖추고 있습니다. 예를 들어, dRPC는 노드 인프라의 다각화를 모니터링하기 위한 대시보드에 대한 액세스를 제공합니다. 어떤 노드를 사용하고 얼마나 분산되어 있는지 직접 제어할 수는 없지만 대시보드를 통해 노드가 얼마나 분산되어 있는지 확인할 수 있습니다. 위의 이미지를 살펴보면 연결이 네 가지 다른 RPC 노드 공급자( ) 간에 분산되어 있음을 알 수 있습니다. 분산화 수준의 누적 숫자를 보여주며, "1"이 가장 분산화되고 "0"이 가장 중앙 집중화됩니다. Besked, drpc-free, drpc-public-multiregion, p2p-validator-optimism-free 0.563의 분산화 지수는 노드 상태 모니터링 및 관리 개발자는 dApp에서 사용하는 RPC 노드를 모니터링할 수 있어야 합니다. 이렇게 하면 dApp의 안정성이 보장됩니다. RPC 공급자가 시스템을 관리하는 방식을 제어할 수 없더라도 dRPC와 같은 분산형 RPC 공급자는 RPC 노드 공급자를 모니터링하는 시스템을 갖추고 있습니다. dApp이 인프라와 상호 작용하는 방식을 모니터링하기 위한 포괄적인 분석에 대한 액세스를 제공합니다. 예를 들어 dRPC 대시보드에서 대시보드에서 오류 로그를 모니터링할 수도 있습니다. dRPC의 SaaS 대시보드는 선택한 날짜에 dApp에서 수행한 총 요청 수를 모니터링하고, RPC 노드 분산화를 모니터링하고, API 키에 따라 요청 배포를 모니터링할 수 있습니다. dRPC 분석 대시보드 외에도 dRPC에는 노드 공급자를 모니터링하고 불량으로 가는 것을 방지하는 백엔드 메커니즘이 있습니다. 이러한 백엔드 메커니즘에 대한 자세한 내용은 여기에서 확인하세요. 결론 RPC 노드는 분산형 애플리케이션과 블록체인 간의 통신을 용이하게 하는 데 중요한 역할을 합니다. 그러나 RPC의 중앙 집중화는 dApp과 블록체인 네트워크 전체에 상당한 위험을 초래합니다. 위에서 논의한 사례 연구의 이전 실패 사례에서 볼 수 있듯이 중앙 집중형 RPC 공급자에 의존하면 단일 장애 지점의 위험이 있으며 web3 서비스의 중대한 서비스 중단으로 이어질 수 있습니다. 개발자는 대안이 없는 것은 아닙니다. 자체 호스팅 및 분산 RPC는 복원력 있는 애플리케이션을 구축하는 데 도움이 되는 안정적인 솔루션을 제공합니다. 와 같은 분산 RPC를 채택함으로써 개발자는 중앙 집중화의 위험을 완화하고 강력하고 복원력 있고 검열에 강하며 보안이 유지되는 애플리케이션을 구축할 수 있습니다. dRPC
