구조적 관점에서 분석했을 때, 진정한 Crypto-native DApp은 무엇인가?

작성자: msfew, Foresight Research

0. Web2 앱 아키텍처

우리가 현대적인 toC 애플리케이션을 개발할 때, 웹 앱, 모바일 앱 또는 데스크탑 앱이든 기본 아키텍처는 다음 세 가지로 요약할 수 있습니다:

왼쪽에서 오른쪽으로:

• 프론트엔드: 클라이언트라고도 불립니다. 애플리케이션의 프론트엔드는 사용자가 브라우저 내에서 보는 페이지 또는 모바일 장치에서 사용하는 앱입니다. 프론트엔드는 뷰와 표시를 제어합니다.

• 백엔드: 서버 측이라고도 불립니다. 애플리케이션의 백엔드는 주로 프론트엔드에 인터페이스와 데이터를 제공하는 역할을 하며, 일반적으로 애플리케이션의 주요 비즈니스 로직은 백엔드에 존재합니다.

• 데이터베이스: 데이터베이스는 말 그대로 데이터를 저장하는 곳입니다. 백엔드는 데이터베이스의 내용을 읽거나 수정합니다.

왜 소프트웨어는 이 세 가지가 필요할까요? 왜 프론트엔드가 데이터베이스에 직접 연결되지 않나요? 중간에 왜 백엔드가 필요한가요? 이는 여러 가지 이유가 있습니다:

a) 공학화

개발자의 관점: 현대 애플리케이션의 프론트엔드는 복잡한 데이터 모델과 뷰 상태 관리를 동시에 처리할 여력이 없습니다. 공학적 관점에서, 모든 엔지니어가 모든 것을 알고 능숙하게 유지하는 것은 좋지 않습니다. 게다가 많은 로직은 프론트엔드에서 표시할 필요가 없으며, 예를 들어 전자상거래 플랫폼의 재고와 같은 것들이 있습니다.

아키텍처 관점: 각 단위는 데이터를 설명하기 위한 자체 규칙과 언어를 가지고 있습니다. 프론트엔드는 인간이 이해할 수 있는 사고방식으로 페이지를 구성하고, 백엔드는 객체 지향 언어로 데이터를 조작하며, 데이터베이스는 관계 대수 언어를 사용하여 물리적 저장소에 접근합니다. 세 단위를 통합할 수 있는 만능 규칙을 정할 수는 없습니다. 동시에 언어가 각자의 역할을 다하기 때문에 성능의 초점도 다릅니다.

b) 통신

프로토콜 관점: 그림을 보면 세 단위를 연결하는 두 가지 연결 방식이 다르다는 것을 알 수 있습니다. 일반적으로 toC 애플리케이션의 프론트엔드와 백엔드는 HTTP 프로토콜을 사용하여 통신하며, 백엔드와 데이터베이스는 MySQL과 MongoDB와 같은 서로 다른 프로토콜을 사용합니다. 우리는 얇은 백엔드(GraphQL + Hasura) 또는 새로운 프로토콜(OData)을 통해 프론트엔드가 데이터베이스에 직접 연결된 것과 유사한 효과를 얻을 수 있지만, 여전히 다른 단점은 해결되지 않았습니다.

데이터 매핑 관점: 프론트엔드는 UI를 처리하고, 백엔드는 객체를 처리하며, 데이터베이스는 데이터를 처리합니다. 프론트엔드와 백엔드의 연결은 UI와 객체의 매핑을 사용하고, 백엔드와 데이터베이스의 연결은 객체 관계를 사용하여 매핑해야 합니다.

c) 보안성

데이터 관점: 현재 우리가 사용하는 애플리케이션은 점점 더 웹 기반의 애플리케이션이 많아지고 있기 때문에, 프론트엔드가 데이터베이스에 직접 연결되면 안전하지 않고 개방적인 브라우저 환경에서 데이터 유출과 해킹 공격을 방지하기 어렵습니다. 데이터베이스는 이론적으로 다양한 인증 수단을 통해 데이터 가시성을 제어할 수 있지만, 백엔드의 또 다른 중요한 의미는 신뢰할 수 있는 환경에서 설계된 방식으로 실행되고, 알려진 보안 문제를 배제하는 것입니다.

d) Web2 애플리케이션 아키텍처가 DApp에 주는 시사점

위의 세 가지 관점에서 우리는 왜 Web2 애플리케이션이 삼단 아키텍처인지 분석했으며, 이는 블록체인 DApp에 대한 몇 가지 생각을 제공합니다:

1. 공학화: 블록체인 내의 모듈화 사상에 해당합니다. 각 구성 요소는 각자의 역할을 수행하며, 저장은 저장 체인을 사용할 수 있고, 사용자 데이터는 전통적인 공공 체인에 저장됩니다. 개발자는 높은 개발 정신적 부담을 가질 필요가 없습니다.

2. 통신: 블록체인 네트워크의 다양한 합의 메커니즘에 해당합니다. 이러한 다양한 메커니즘은 블록체인 간의 상호 운용성을 어렵게 만들지만, Cosmos와 Polkadot과 같은 상호 운용 프로토콜이 전체 네트워크를 연결하려고 시도합니다. 그러나 Web2 애플리케이션의 관점에서 볼 때, 이는 최상의 해결책을 의미하지 않습니다. 데이터 매핑은 계정 지향 또는 UTXO 설계 패턴에 해당할 수 있으며, 두 가지 모두 성능, 프라이버시 및 개발 복잡성에서 장단점이 있습니다.

3. 보안성: 블록체인의 탈중앙화 및 Verify, Not Trust 사상에 해당합니다. 블록체인 분야에서 보안성은 더욱 중요하므로, 데이터 처리 및 데이터 가시성을 조정하기 위해 검증 가능하고 심지어 완전히 투명한 공개 방식이 필요합니다. 이를 통해 투명하고 Permissionless한 DeFi, 공개적이며 소유권이 있는 NFT, 그리고 DApp에서 가장 중요한 조합 가능성을 실현할 수 있습니다.

1. Web3 DApp 아키텍처

대부분의 Web3 DApp은 다음과 같은 아키텍처를 따릅니다:

• 간단한 애플리케이션 (순수 체인 데이터 및 복잡하지 않은 상호작용), 예: Uniswap 및 순수 체인 저장 NFT 프로젝트.

• 프론트엔드는 Web2 앱과 차이가 없습니다.

• 백엔드 없음 (체인 상의 스마트 계약이 백엔드 역할을 함).

• 블록체인이 데이터베이스 역할을 함.

a) Web3 DApp 세분화 구성 요소

더 세분화하여 말하자면, 완전한 Web3 DApp의 작업 흐름은 더 많은 구성 요소를 포함합니다:

• 프론트엔드: 브라우저, 지갑, 페이지.

• 프론트엔드와 백엔드 통신: 노드 제공자, 인덱스 프로토콜.

• 개념상의 백엔드: 블록체인 네트워크의 스마트 계약.

• 백엔드 데이터베이스 통신: 노드 제공자, 저장 네트워크 게이트웨이.

• 데이터베이스: 스마트 계약 상태 및 탈중앙화 저장 네트워크.

b) Web3 DApp는 어떻게 백엔드 없이 작동할까요?

블록체인 네트워크의 튜링 완전한 스마트 계약의 존재는 블록체인이 최고의 서버리스 플랫폼이 될 수 있게 하며, 또는 Trustware로 간주될 수 있는 월드 컴퓨터로 볼 수 있습니다. 애플리케이션의 데이터와 백엔드 로직은 스마트 계약 내에서 구현될 수 있습니다.

서버리스 함수와 비교할 때, 스마트 계약은 더욱 우수하며 Web2 애플리케이션보다 더 나은 아키텍처와 패턴을 만들어냅니다:

• 지불 방식: 서버리스 함수는 일반적으로 개발자가 비용을 지불하지만, 스마트 계약의 대부분의 상호작용 비용은 사용자가 지불하며, 사용자는 체인 상의 공간에 대해 기꺼이 비용을 지불합니다.

• 실행 환경: 서버리스 함수는 매우 유연한 실행 환경을 가지고 있지만, 스마트 계약의 실행 환경은 선택이 적지만 매우 경량입니다.

• 배포 환경: 서버리스 함수는 중앙 집중식 클라우드 서비스 플랫폼에 배포되지만, 스마트 계약은 탈중앙화되고 허가가 필요 없는 네트워크에 배포됩니다. 게다가 네트워크 운영 비용은 중앙 집중식 플랫폼에서 채굴자로 전가되어 경제 시스템이 더욱 자율성을 가질 수 있습니다.

그러나 진정으로 완전한 애플리케이션의 경우, 스마트 계약만으로는 완전한 기능을 구현할 수 없으므로 Keeper 네트워크나 오라클과 같은 다른 구성 요소가 필요합니다.

2. Web3 크립토 네이티브 DApp 아키텍처

Web3 DApp는 스마트 계약을 백엔드로 구현한 간단한 탈중앙화 애플리케이션을 의미합니다. 복잡한 애플리케이션을 완성하기 위해서는 어느 정도 중앙 집중식 서비스를 도입해야 할 수 있으며, 진정으로 크립토 네이티브하고 신뢰할 수 없는 DApp을 구현하기 위해서는 아키텍처에 새로운 변화를 추가해야 합니다.

Web2의 복잡한 애플리케이션은 우리가 이전에 요약한 세 가지 이상으로, 매우 많은 모듈화, 중간 계층 및 수평 확장이 필요합니다. 아키텍처 분할.

a) 프론트엔드 ⇒ 오픈 소스 + 셀프 호스팅 프론트엔드

Web3 프론트엔드의 트리거 로직은 사실 Web2와 다릅니다. Web3의 작업은 모두 사용자가 수행하고 확인하며, 체인 상의 주소를 중심으로 하며, Web2에서는 클라이언트가 서버와 데이터베이스에 직접 데이터를 업데이트하도록 트리거합니다. Web3 프론트엔드의 발전에 대해 저는 두 가지 큰 트렌드가 있다고 생각합니다:

• 프레임워크 선택: 프론트엔드의 두 가지 주요 프레임워크인 React와 Vue 중에서 React가 Web3에서 주도적인 위치를 차지하고 있으며, 이는 생태계와 다양한 구성 요소의 축적 때문입니다.

• 예를 들어 web3-react와 Center.dev. 그러나 개인적으로 React 프로젝트의 주도권은 여전히 Meta에 있다고 느끼며, 오픈 소스 라이센스의 변경은 여러 차례 논란을 일으켰습니다. 따라서 Vue 프레임워크와 의존성이 적은 제3자 라이브러리를 사용하여 프론트엔드 개발을 하는 것이 React보다 더 좋습니다.

• 프론트엔드 호스팅: 프론트엔드는 DApp이 해킹(악의적 탈취 또는 스크립트 주입) 및 검열(Uniswap과 Flashbots의 소스 코드에 OFAC의 블랙리스트가 있음)의 주요 피해 지역입니다. Yearn Finance는 사용자에게 DApp의 프론트엔드를 직접 호스팅하도록 조기에 권장했습니다; Arweave와 같은 영구 저장 네트워크에 프론트엔드를 호스팅하면 각 버전의 프론트엔드가 삭제되지 않고 영구적으로 접근 가능하다는 것을 보장할 수 있습니다; Trustless.fi는 여러 커뮤니티에서 호스팅된 프론트엔드 중에서 선택할 수 있는 프론트엔드 마켓플레이스 개념을 제안했습니다. 이는 중립성과 "프론트엔드 다양성"을 보장할 수 있습니다; Etherscan과 같은 다른 블록체인 탐색기도 중립적인 프론트엔드로 간주될 수 있으며, 사용자는 이를 통해 직접 상호작용할 수 있습니다. 또는 계약을 위한 프론트엔드를 생성하는 전용 애플리케이션도 있습니다, 예를 들어 okcontract; 최근 Tornado가 검열을 받았고, 많은 커뮤니티(예: codeisspeech와 theshake)가 자발적으로 프론트엔드를 호스팅하고 있습니다.

이 두 가지 점의 발전은 DApp의 프론트엔드에 검열 저항성을 부여하고, DApp 전체의 보안성과 탈중앙화 수준을 크게 향상시킬 것입니다.

b) 백엔드 ⇒ ZKP + 스마트 계약

앱 아키텍처의 진화 과정은 다음과 같습니다:

1. Web2 애플리케이션: 프론트엔드 ⇒ 백엔드 ⇒ 데이터베이스

2. Web3 간단한 애플리케이션: 프론트엔드 ⇒ 스마트 계약

3. Web3 복잡한 애플리케이션: 프론트엔드 ⇒ ZKP ⇒ 스마트 계약

스마트 계약은 전체 애플리케이션을 탈중앙화하게 만들지만, 공개 네트워크의 스마트 계약을 사용하여 애플리케이션의 로직을 처리하는 것은 양날의 검입니다. 데이터와 코드가 공개되어 투명성과 조합 가능성을 보장하지만, 프라이버시와 보안 위험도 완전히 노출되며, 동시에 체인 상의 공간과 계산 비용이 매우 높습니다.

ZKP는 Web3 시대의 RSA가 되어 애플리케이션의 통신 보안성과 탈중앙화 단점을 제거하고, 진정으로 신뢰할 수 있으며 신뢰할 수 없는 DApp을 실현합니다.

ZKP의 도입은 프론트엔드와 백엔드 사이의 중간 계층 및 통신 방식으로서 두 가지 주요 장점을 잘 발휘합니다:

• 프라이버시: Web2 애플리케이션에서 프라이버시는 항상 기본 옵션으로 간주되지만, 블록체인 네트워크의 특성으로 인해 DApp은 항상 형식적으로 "프라이버시"를 가지고 있습니다. ZKP는 중간 계층으로서 민감한 데이터를 체인 외부에서 처리하여 이 문제를 해결할 수 있습니다.

• 확장성: 체인 상의 공간이 제한적이기 때문에 많은 Web2 애플리케이션의 복잡한 알고리즘을 구현할 수 없습니다. ZKP는 계산의 신뢰성을 보장하면서 알고리즘을 체인 외부에서 실행하고 체인 상에서 검증할 수 있습니다.

수많은 프로젝트가 이 두 방향으로 노력하고 있으며, 여기서는 나열하지 않겠습니다. 주로 두 가지 난제를 극복해야 합니다:

• 계산 가능성: ZKP의 계산 종류는 제한적이며, 모든 계산이 ZKP로 해결될 수 있는 것은 아닙니다.

• 최적화: 작업의 복잡성이 증가하면 계산 시간과 공간이 크게 증가하므로, 많은 소프트웨어 및 하드웨어 최적화가 필요합니다. 동시에 많은 경우에는 처리량에서 상당한 향상을 이뤄야 하며, 전체 증명 오버헤드를 줄이는 것은 매우 어렵습니다.

c) 데이터베이스 ⇒ 탈중앙화 노드 서비스

우리는 이전에 DApp이 블록체인을 백엔드 및 데이터베이스로 사용하는 방법에 대해 설명했습니다. DApp이 블록체인 네트워크에 연결되려면 노드 서비스가 필요합니다.

현재 DApp에서 일반적으로 사용되는 것은 중앙 집중식 NaaS, 예를 들어 Alchemy와 Infura입니다. 미래에는 제 생각에 세 가지 더 나은 방향이 있습니다:

• 탈중앙화 NaaS, 프로토콜화된 Infura, 그러나 이는 특별히 큰 필요성과 실행 가능성이 없습니다. NaaS의 탈중앙화 목적은 주로 검열 저항을 위한 것이며, 다른 요구는 없습니다.

• 다중 중앙 NaaS, 여러 중앙 집중식 NaaS를 백업으로 사용하는 것(Chainlink + Uniswap의 오라클 조합과 유사). 이는 더욱 실행 가능하고 신뢰할 수 있는 솔루션으로, 검열 저항성과 가동 시간을 보장할 수 있습니다.

• 자가 호스팅 NaaS. 궁극적인 솔루션으로, "데이터베이스" 연결의 신뢰성과 다양한 데이터의 프라이버시 및 검열 저항성을 보장할 수 있으며, 네트워크의 탈중앙화 수준을 높일 수 있습니다. 자가 호스팅 프론트엔드와 결합하면 전체 DApp은 매우 탈중앙화됩니다.

d) 크립토 네이티브 DApp 사례

최근 제재를 받은 Tornado.cash(특히 구버전)는 매우 크립토 네이티브 DApp으로, 우리의 많은 정의를 충족합니다:

• 프론트엔드는 일반적으로 사용되는 React 프레임워크가 아닌 NuxtJS의 Vue 프레임워크를 사용했습니다.

• 완전히 프론트엔드 코드 내의 ZK 회로와 스마트 계약으로 구현되었으며, 서버 측 코드가 없습니다.

• 코드는 완전히 오픈 소스이며, IPFS에 호스팅됩니다.

• 구버전은 개인 키나 다중 서명 제어가 없습니다.

저는 미래에 더 많은 애플리케이션이 Tornado.cash의 패러다임을 따라 아키텍처를 구축할 것이라고 믿습니다. 이는 현재 제가 생각하는 가장 완벽한 탈중앙화 Web3 애플리케이션 아키텍처입니다.

3. Web3 인프라

위에서 설명한 것은 간소화된 아키텍처이며, 아래는 보다 구체적인 실제 DeFi 애플리케이션의 아키텍처입니다:

여기에는 노드 서비스 외에 몇 가지 보충 인프라가 포함됩니다:

• 인덱서: 왼쪽의 The Graph. 체인 상의 데이터는 편리하게 조회할 수 없으므로, 인덱서가 계약 관련 데이터를 조합해야 합니다.

• 오라클: 오른쪽 하단의 Chainlink. 체인 상에서 계약이나 네트워크 외부의 가격 등의 데이터를 얻기 위해 체인 상(Uniswap TWAP) 또는 체인 외 오라클(Chainlink)로 가격을 제공해야 합니다.

• Keeper: 오른쪽 하단의 Keep3r Network. 스마트 계약 자체는 자동으로 실행 작업을 트리거할 수 없으므로, 외부 트리거가 필요합니다.

이러한 기본 인프라는 DApp 구축에서 매우 중요하며, 우리는 향후 기사에서 오라클과 인덱서의 문제 및 혁신 기회를 자세히 소개할 것입니다.

왜 이 몇 가지 기본 인프라만 고려되었고, NFT 창작 도구, No-Code 계약 생성 도구 및 계약 프론트엔드 생성기가 고려되지 않았을까요? 개인적으로 좋은 Web3 인프라는 지속적인 가치 포착 능력이 필요하며, 이를 사용하는 애플리케이션과 함께 성장해야 한다고 생각합니다. 이는 일회성 지불로 끝나는 것이 아니라, Web2 SaaS와 Web3 프로토콜에서 얻은 경험이기도 합니다.

약세장은 인프라를 구축하고 향상시킬 수 있는 매우 좋은 기회입니다. 저는 이러한 혁신적인 Fat Infra가 다음 DApp 혁신을 지탱하고, Base Layer로서 막대한 가치를 포착할 것이라고 믿습니다.