Ethereum에서 Dapps를 개발하는 데 병목 현상과 장벽은 무엇입니까?

区块链大本营

特邀专栏作者

2020-01-07 09:00 (UTC+8)

이 기사는 약 3710자로, 전체를 읽는 데 약 6분이 소요됩니다

Ethereum에서 Dapp을 개발할 때 피할 수 없는 문제는 무엇입니까?

AI 요약

Ethereum에서 Dapp을 개발할 때 피할 수 없는 문제는 무엇입니까?

편집자 주: 이 기사의 출처는블록체인 캠프 (ID: blockchain_camp)편집자 주: 이 기사의 출처는

블록체인 캠프 (ID: blockchain_camp)

탈중앙화 애플리케이션(Dapps)은 뱅킹(Di-Fi) 및 게임과 같은 분야에서 파괴적인 혁신으로 널리 간주됩니다. 그러나 아무리 혁신적인 솔루션이라도 소비자의 기대에 부응하지 못하면 인정받지 못할 것입니다.

소비자가 원하는 것은 원활하고 성숙한 사용자 경험이며, 이 목표를 달성하는 것은 Ethereum Dapp 개발자에게 또 다른 주요 과제입니다.

이 기사는 일반적인 Dapp 아키텍처에 대한 개요를 제공하고 개발자가 설득력 있는 사용자 경험을 생성하기 어렵게 만드는 오늘날의 표준 이더리움 스택의 고유한 제한 사항을 지적합니다. 그런 다음 개발자가 이러한 문제를 극복하는 데 도움이 될 수 있는 이더리움 인프라 분야의 몇 가지 혁신을 소개하겠습니다.

보조 제목
클래식 Ethereum Dapp 아키텍처
일반적으로 Ethereum의 Dapp은 세 가지 주요 부분으로 구성됩니다.

Java로 작성된 프론트엔드 코드.

백엔드 - 일반적으로 표준 이더리움 블록체인 노드입니다. 프런트엔드와 백엔드 간의 통신은 일반적으로 노드에서 제공하는 JSON-RPC 또는 GraphQL API를 사용합니다.

보조 제목

자체 구축 백엔드 노드

이더리움 초기에는 개발자가 자체 이더리움 노드를 운영해야 했습니다. Dapp이 출시된 후에는 프로덕션급 노드(또는 노드의 클러스터)도 운영해야 합니다. 블록체인 노드를 운영하는 것은 과중한 작업이며 개발자의 효율성에도 부담이 됩니다.

NaaS(서비스로서의 노드) 공급자

앞서 언급한 이러한 문제로 인해 Infura와 같은 회사와 Nodesmith, Quiknode, Blockdaemon, Ethernode, Chainstack, Alchemy, CloudFlare 등과 같은 비교적 새로운 회사의 "서비스로서의 노드" 플랫폼이 부상했습니다.

이러한 플랫폼은 개발자에게 클라우드 기반 이더리움 노드를 제공하여 개발자가 노드를 운영하는 수고를 덜어줍니다. 개발 및 생산을 위한 솔루션. 이러한 플랫폼은 기본 운영 체제 및 노드 소프트웨어 자체에 대한 패치 및 업데이트와 같은 시스템 관리를 개발자에게 오프로드합니다.

보조 제목

Ethereum 노드의 본질적인 한계

노드 서비스가 개발자를 시스템 관리자로 성공적으로 대체할 수 있더라도 개발자가 더 나은 Dapp을 구축하기 위해 더 나은 사용자 경험을 달성하는 데 도움이 될 수 없습니다. 노드 서비스의 아키텍처와 JSON-RPC 및 GraphQL 인터페이스의 고유한 제한 사항 때문입니다.

주요 제한 사항은 다음과 같습니다.

1. 관찰된 상태 정보가 일치하지 않습니다.

더 높은 안정성을 제공하면서 단일 노드의 용량 이상으로 확장하기 위해 서비스 플랫폼으로서의 노드는 로드 밸런서를 통해 노드 풀에 대한 액세스를 제공합니다.
이 노드들은 모두 이더리움 네트워크에서 피어 노드로 자율적으로 작동하기 때문에 특정 순간에 네트워크를 통해 정보가 전송될 때 서로 다른 노드가 서로 다른 블록 높이 또는 심지어 서로 다른 포크에 있을 수 있습니다. 이는 요청 결과가 로드 밸런서 뒤의 다른 노드에서 제공되기 때문에 Dapp이 블록체인 상태에 대해 일관되지 않은 정보를 수신할 수 있음을 의미합니다.
노드 서비스 플랫폼은 일반적으로 로드 밸런서의 세션 고정을 통해 이 문제를 해결하려고 시도합니다. 로드 밸런서는 항상 지정된 프런트엔드의 쿼리를 동일한 백엔드 노드로 보내려고 시도하지만 이 방법은 여러 상황에서 실패합니다.

프런트 엔드가 단일 백엔드 노드가 처리할 수 있는 것보다 더 많은 요청을 생성하는 경우

네트워크 문제로 인해 프런트엔드가 백엔드에서 연결이 끊어지고 다시 연결해야 하는 경우

여러 노드 제공 플랫폼은 다양한 유형의 프런트엔드 요청(예: 트랜잭션 전송 또는 체인 기록 검색)을 해당 쿼리 유형에 최적화된 다양한 백엔드 노드 세트로 라우팅합니다.

그러면 프런트 엔드가 종종 여러 백엔드 노드에 액세스하고 이러한 백엔드 노드에서 얻은 블록체인 상태가 서로 일치하지 않기 때문에 Dapp에서 체인 재구성을 처리하기 어렵습니다. 체인 히스토리를 거꾸로 추적할 때 Dapp은 찾고 있던 상위 블록이 더 이상 존재하지 않는다는 것을 갑자기 발견할 수 있습니다(이제 다른 포크의 다른 노드와 상호 작용하기 때문입니다). 그런 다음 Dapp 개발자는 이 문제를 해결하기 위해 코드를 작성해야 합니다(일반적으로 노드를 찾을 때까지 반복적으로 다시 연결하여). 이는 Dapp에 불필요한 복잡성을 추가하고 사용자에게 제공되는 정보의 불일치를 초래할 수 있습니다.
2. 블록체인에 대한 정보 검색이 느리고 제한적임
표준 이더리움 노드는 정확한 검색을 지원하거나 실시간 데이터의 필터링된 청취를 수행하는 데 적합하지 않기 때문에 Dapp은 트랜잭션 또는 온체인 기록을 검색하는 기능이 제한됩니다. 이를 효율적으로 수행하려면 수백만 개의 블록과 트랜잭션에 대해 많은 인덱싱을 수행해야 하지만 다음과 같습니다.
이더리움 노드는 트랜잭션 실행으로 전송된 로그의 특정 필드만 인덱싱합니다(인덱싱할 필드는 컨트랙트 배포 시 개발자가 표시해야 함)
Ethereum 노드는 내부 거래(스마트 계약이 다른 계약의 메서드를 호출할 때 발생)에 대한 데이터를 인덱싱하지 않습니다.
각 추가 인덱스 필드에 대해 각 거래 비용이 증가하여 계약 사용자에게 추가 비용이 발생하기 때문에 개발자는 추가 인덱스 필드를 추가하는 것을 꺼립니다.
Ethereum 노드는 Bloom 필터를 사용하여 검색을 수행하므로 항상 퍼지 검색이며 거짓 긍정 일치를 생성합니다. 완전 일치는 프런트 엔드의 추가 처리가 필요하며, 프런트 엔드는 퍼지 일치의 전체 블록 또는 트랜잭션을 획득하고 다시 검색하여 정확한 일치 결과를 찾아야 합니다. 이를 위해서는 개발자의 노력이 필요할 뿐만 아니라 프런트엔드와 노드 사이의 대역폭도 낭비됩니다.

사용 가능한 검색 구문은 매우 제한적입니다. 기본 선택 및 간단한 대체만 지원됩니다.

검색 결과를 가져오는 속도가 느립니다. 큰 블록에서 검색을 수행하는 데 몇 시간이 걸릴 수 있습니다.

JSON-RPC는 대역폭을 엄청나게 낭비합니다. 실제로 필요한 것보다 훨씬 더 많은 데이터를 반환합니다. GraphQL 인터페이스는 더 적은 대역폭을 사용하지만 스트리밍 기능을 제공하지 않습니다(프론트엔드에서 업데이트를 폴링해야 함).

3. 원자성 부족

다시 말하지만, 정확히 무슨 일이 일어났는지 파악하기 위해 반복적으로 폴링해야 하는 프런트 엔드 코드에 부담이 가해지는 반면, Dapp 사용자는 Dapp이 이 모든 추가 작업을 수행함에 따라 지연과 새로 고침의 필요성을 경험합니다.

4. 노드가 수동적입니다.

이더리움 노드는 수동적입니다. 즉, 이벤트나 콜백을 생성하고 웹후크를 호출할 수 없습니다. 모든 작업은 프런트엔드에서 시작해야 하며 업데이트된 정보에 대해 노드를 폴링해야 합니다. Ethereum 노드의 이벤트 스트림 읽기 기능은 대부분의 Dapp의 요구 사항을 충족하기에는 너무 제한적이며 GraphQL 인터페이스가 아닌 JSON-RPC 인터페이스에서만 사용할 수 있습니다.

보조 제목

Dapp 인프라 재고

dfuse가 제공하는 것은 블록체인 노드에서 제공하는 기본 API보다 더 쉽게 더 많은 작업을 수행할 수 있는 상위 수준의 블록체인 API용 플랫폼입니다. Dapp 개발자에게 빠르고 원활한 인터페이스를 통해 최신 블록체인 애플리케이션을 구축하는 데 필요한 기능을 제공하여 우수한 사용자 경험을 제공하도록 설계되었습니다.

플랫폼을 통해 위에서 언급한 모든 한계가 해결되고 기존 이더리움 노드의 한계가 깨질 수 있기를 바랍니다.

1. 일관된 견해

dfuse는 로드 밸런서의 여러 이더리움 노드 모음이 아닌 통합 하이퍼스케일 데이터 플랫폼입니다. dfuse 플랫폼은 모든 연결과 모든 시점에 대한 체인 상태 정보를 제공합니다. 블록을 보거나(체인 포크와 재구성을 모두 감지) 블록을 전혀 보고하지 않거나(블록이 빠르게 재구성되고 멀리 이동하지 않는 경우).

이렇게 하면 Dapp은 체인 상태에 대한 일관성 없는 관점에 직면하지 않고 블록체인의 세부 사항을 확인하느라 바쁘지 않고 주요 기능에 집중할 수 있습니다.
2. 고속의 세분화된 검색
이를 통해 Dapp 개발자는 매우 세밀하고 놀라운 속도와 효율성으로 블록체인의 과거 기록을 검색할 수 있으며 GraphQL, gRPC 및 Websocket 인터페이스를 통해 실시간 필터링 및 스트리밍 읽기를 실현할 수 있습니다.
모든 로그 필드를 완전히 인덱싱합니다. 로그의 각 트랜잭션에서 내보낸 모든 데이터는 고정밀 검색에 직접 적용할 수 있습니다.
모든 내부 트랜잭션(송신자, 수신자, 값, 메서드, 입력 매개변수)의 전체 인덱싱으로 전체 호출의 트리 구조에서 계약 작업을 완전히 추적합니다.
인덱싱은 사용자에게 추가 가스 비용을 발생시키지 않습니다. dfuse의 인덱싱은 dfuse 플랫폼의 통합 기능이며 계약 실행의 리소스 비용을 증가시키지 않습니다.
검색은 퍼지 검색이 아니라 정확히 일치하는 항목을 찾습니다. 검색 결과를 다시 확인하기 위해 추가 프런트 엔드 코드를 작성할 필요가 없으며 불필요한 데이터를 일괄적으로 가져오기 위해 대역폭을 낭비할 필요가 없습니다.
Kibana 또는 GitHub의 쿼리 언어와 유사한 구조화된 쿼리 언어를 제공하며 완전한 부울 연산과 원하는 특정 트랜잭션 또는 명령으로 직접 드릴다운할 수 있는 기능을 제공합니다.

뛰어난 성능 제공 - 지정된 검색 기준에 따라 1초 이내에 전체 체인 기록을 검색하여 정확히 일치하는 세트를 찾습니다.

스트리밍 기능을 희생하지 않고 간결한 응답을 제공하는 GraphQL의 두 가지 장점 - GraphQL 인터페이스는 전체 실시간 필터링 검색을 제공하여 사용자에게 동적 업데이트를 효율적으로 제공합니다.

이더리움 네트워크의 트래픽과 관계없이 성능이 일관됩니다.

3. 원자적 작업

트랜잭션이 입력할 수 있는 모든 복잡한 상태를 이해하는 스트림 읽기 끝점을 제공하고 최종성을 충족하면 알려줍니다. 반복되는 설문 조사를 거치거나 여러 데이터 소스를 확인하여 트랜잭션 상태를 추적하는 대신 트랜잭션을 푸시하고 연결 상태를 유지하여 실시간 상태 업데이트를 수신함으로써 사용자에게 실시간 트랜잭션 상태를 제공할 수 있습니다.

좋은 플랫폼은 이벤트를 시작할 수 있는 활성 백엔드를 제공합니다. 예를 들어, 앞서 언급한 검색 및 기타 기능을 통해 지정한 정확한 기준에 따라 선택한 람다 함수(또는 클라우드 함수)를 호출할 수 있습니다. 이를 통해 Dapps는 데이터 업데이트가 여러 통신 채널을 통해 실시간으로 원활하게 사용자에게 릴리스될 수 있는 비동기 아키텍처를 구현할 수 있습니다.