텍스트

보조 제목

머리말

머리말

DeFi 응용 프로그램과 기존 응용 프로그램의 차이는 여전히 상대적으로 크며 비즈니스 모델도 다르고 제품 모델도 다르며 구현을 위한 기술 스택도 매우 다릅니다. 일반적으로 기존 애플리케이션은 Web2 애플리케이션이라고도 하며 DeFi 애플리케이션은 Web3로 분류할 수 있습니다.

비즈니스 모델과 제품 모델에 대해 이야기하는 대신 기술 스택에 대해서만 이야기합니다. 현재 DeFi 애플리케이션과 관련된 기술 스택에는 주로 Solidity, Subgraph, Price Oracle, Hardhat, Ethers 등이 포함됩니다. 이러한 기술 스택의 대부분은 Ali, Tencent 및 Byte와 같은 주요 인터넷 회사의 P9 수준에 있는 일부 대기업에서조차 들어본 적이 없습니다. 기존 애플리케이션 아키텍처에서 널리 사용되는 마이크로 서비스 아키텍처, 빅 데이터 아키텍처 및 클라우드 네이티브 아키텍처는 DeFi 애플리케이션에서 기본적으로 쓸모가 없습니다.

저는 2017년 중반부터 블록체인을 연구하고 있습니다. 이 업계에서 몇 년 동안 심도 있게 배양한 후 여러 DeFi 애플리케이션을 수행했고 마침내 어느 정도 기반을 갖추었습니다. 내 경험을 바탕으로 DeFi 애플리케이션의 아키텍처 디자인을 이해하는 방식에 대해 이야기하겠습니다.

보조 제목

전체 구조

DeFi 애플리케이션 시스템의 일반적인 아키텍처를 살펴보겠습니다.

• 다음 몇 가지 모듈을 하나씩 소개하겠습니다.

• 블록체인: 기본 블록체인 네트워크인 DeFi 애플리케이션은 일반적으로 여러 다른 블록체인 네트워크에 배포됩니다.

• 스마트 계약: 스마트 계약은 DeFi 애플리케이션의 핵심 비즈니스 구현이자 영혼입니다.

• 가격 오라클: 가격 정보를 제공하는 데 사용되는 가격 오라클, 일반적으로 오프체인 오라클과 온체인 오라클로 나눌 수 있습니다.

• 키퍼 서비스: 스마트 계약 자체에는 실행 작업을 자동으로 트리거할 수 있는 기능이 없기 때문에 스마트 계약의 작업 트리거 및 집행자이므로 이를 지원하려면 외부 작업 트리거가 필요합니다.

• Subgraph: 인덱서라고도 하는 Subgraph는 주로 체인의 데이터를 프런트 엔드 쿼리에 편리한 데이터로 재구성합니다.

• 그래프 노드: Subgraph가 실행되는 환경은 처리를 위해 체인의 블록 데이터를 Subgraph에 동기화합니다.

• 지갑: 지갑 어플리케이션, 가장 주류는 메타마스크

• WebUI: 일반적으로 Vue 및 React와 같은 프런트 엔드 프레임워크를 사용하여 프런트 엔드에 표시되는 UI 페이지

SDK: Subgraph 쿼리, 스마트 계약 호출, 지갑 연결 등을 캡슐화하여 프런트 엔드 UI 호출을 용이하게 합니다.

저는 많은 사람들이 의심할 것이라고 믿습니다. DeFi 애플리케이션 시스템에 왜 그렇게 많은 다른 구성 요소가 있습니까?

첫째, 스마트 계약 자체에는 자동 실행 메커니즘이 없습니다. Web2 애플리케이션에는 타이머가 있기 때문에 타이머를 사용하여 많은 작업을 자동으로 실행할 수 있습니다. 그러나 스마트 계약에는 타이머가 없으므로 일부 작업은 자동으로 실행할 수 없으며 이러한 작업의 실행을 트리거하려면 외부 프로그램이 필요합니다. 이러한 외부 프로그램을 Keeper라고 하는데, 예를 들어 Compound의 청산 업무를 수행하는 청산인이 일종의 Keeper입니다.

대부분의 키퍼는 오프체인 중앙 집중식 프로그램입니다. 지난 1년 동안 탈중앙화 Keeper 네트워크가 속속 등장했는데 제가 아는 keep3r.network, Chainlink Keepers, KeeperDAO가 있습니다.

둘째, 스마트 계약 자체의 한계로 인해 Web2 애플리케이션과 같은 데이터를 얻기 위해 외부 프로그램에 대한 네트워크 요청을 능동적으로 시작하는 것이 불가능합니다. 그렇지 않으면 스마트 계약이 가격 데이터를 얻기 위해 Coinbase 및 Binance와 같은 중앙 집중식 거래소에 네트워크 요청을 보낼 수 있다면 요청 시간과 획득한 가격이 다르기 때문에 서로 다른 노드가 합의에 도달할 수 없습니다. 그러나 스마트 계약은 가격 정보를 얻을 필요가 있으므로 Price Oracle이 있습니다.

가격 오라클은 주로 오프체인 오라클과 온체인 오라클의 두 가지 범주로 나눌 수 있습니다.

오프체인 오라클은 체인링크로 대표되며 기본 원칙은 여러 수준에서 여러 거래소(중앙화 및 분산화 거래소 포함)의 데이터 소스를 집계한 다음 최종 가격 데이터를 온체인 인텔리전스 계약으로 업데이트하는 것입니다. 체인에서 스마트 계약의 가격 정보를 직접 읽습니다.온체인 오라클은 이전 기사에서 언급한 원칙인 Uniswap의 TWAP(시간 가중 평균 가격)를 기반으로 합니다."DeFi 거래 상품에 대한 Uniswap 분석: V2의 2부"

이미 논의되었으므로 반복하지 않겠습니다.

또한 스마트 계약에 저장된 데이터는 기존의 Web2 데이터베이스와 완전히 다르며 MySQL 및 MongoDB 데이터베이스와 같은 데이터를 인덱싱 및 쿼리하는 것이 불가능하며 데이터를 그룹화, 정렬 또는 결합하는 것도 불가능합니다. 그리고 이 수요 또한 경직된 수요인데, 이러한 수요를 충족시키기 위해 블록체인 데이터 인덱스 프로토콜인 The Graph가 등장했습니다. Subgraph는 프로토콜의 핵심 구성 요소이며 Graph Node는 운영 환경입니다.

각기 다른 DeFi 애플리케이션에 따라 실제 아키텍처는 약간 다를 수 있습니다.예를 들어 Uniswap에는 Keeper Services 또는 Price Oracle이 필요하지 않습니다. 그러나 대부분의 약간 더 복잡한 DeFi 애플리케이션에는 기본적으로 이러한 구성 요소가 필요하므로 이 아키텍처는 대부분의 DeFi 애플리케이션의 일반적인 아키텍처가 되었습니다.

보조 제목

스마트 계약 설계

전체 DeFi 응용 시스템에서 가장 핵심적이고 복잡한 것은 스마트 계약이며, 스마트 계약은 여전히 ​​오픈 소스여야 하고 보안도 중요하므로 스마트 계약의 설계는 당연히 매우 중요한 부분입니다.

특정 디자인은 특정 제품마다 다르지만 상대적으로 우아한 스마트 계약 제품을 디자인하는 데 도움이 되는 몇 가지 일반적인 디자인 원칙이 여전히 있습니다. 소위 말하는 상대적 우아함은 보안, 기능, 확장성과 같은 몇 가지 특성을 충족하는 것이 가장 중요하다고 생각합니다.

모든 스마트 계약은 오픈 소스여야 하므로 다양한 보안 허점을 피하기 위해 보안이 최우선 순위여야 하며, 특히 플래시 대출 공격, 재진입 공격, 권한 허점 등을 방지해야 합니다. 메인넷 정식 런칭 전에 내부 보안 감사와 외부 감사는 물론 내부 테스트와 외부 공개 테스트를 포함한 적절한 테스트, 심지어 공개 보상까지 실시하여 더 많은 전문가들이 함께 숨겨진 비밀을 찾을 수 있도록 해야 합니다. 허점.

예를 들어 입출금, 차입이 가능한 대출 상품이 기본 요건이고 레버리지 거래를 확대할 수 있는 파생 DEX도 기본 요건이다. 그러나 그것이 만족되는 정도는 다른 제약에 의해 제한될 수 있습니다. 예를 들어, 플래시론 공격을 방지하기 위해 파생 상품 DEX는 동일한 계정이 동일한 블록에서 포지션을 열고 닫는 것을 금지할 수 있습니다.

확장성도 매우 중요한 기능인데, 결국 한 가지 버전의 응용 시스템만 출시하는 것으로는 부족하고, 항상 반복적으로 새로운 기능을 추가해야 합니다. 예를 들어 파생상품 DEX의 경우 첫 번째 버전은 시가 거래 기능만 구현할 수 있고 두 번째 버전은 가격 제한 거래 기능을 추가해야 하며 세 번째 버전은 손절매 및 손절 기능을 추가해야 합니다.

이러한 기능은 모두 긍정적인 상관관계가 있는 것은 아닙니다. 예를 들어 보안을 더 향상시키면 기능과 확장성이 감소할 수 있습니다. 선택은 균형 상태에 도달하는 것입니다.

목표를 달성하기 위해 따라야 할 설계 원칙과 그 뒤에 있는 필수 설계 아이디어는 실제로 단일 책임 원칙, 개폐 원칙, 종속성 역전 원칙, 인터페이스 격리와 같이 건축가에게 친숙한 것입니다. 등의 원리와 분리, 낮은 결합, 높은 응집력, 적당한 디자인과 같은 아키텍처 아이디어에 초점을 맞춥니다.

아키텍처 설계의 핵심은 복잡한 문제를 단순화하는 것이며, 이는 오픈 소스 스마트 계약에 적용될 때 더욱 중요합니다.

보조 제목

디자인 실습

제가 현재 담당하고 있는 DeFi 애플리케이션을 예로 들어 저의 실무 요약 중 일부에 대해 이야기해 보겠습니다.

먼저 배경에 대해 간단히 소개하자면 제가 최근에 새로운 팀에 합류하여 DeFi 제품, 정확히는 파생 DEX를 담당하고 있다는 사실을 몇몇 친구들은 알고 있습니다. 트랜잭션 모드는 주로 AMM 모드를 채택하지만 Uniswap과 같은 이중 통화 유동성을 제공하는 AMM이 아니라 Elastic AMM이라고 하는 단일 통화 유동성을 제공하는 AMM입니다. 구체적인 사업은 진행하지 않을 예정이며, 자세한 내용은 추후에 다루도록 하겠다.

전체 애플리케이션 시스템의 전체 아키텍처는 위에서 언급한 것과 대략 동일하므로 전체 아키텍처를 반복할 생각은 없지만 주로 스마트 계약의 설계에 대해 이야기하고 싶습니다.

스마트 컨트랙트 수준에서는 사실상 주합의와 주변합의로 나뉜다. **그리고 제가 주로 이야기하고 싶은 것은 주계약의 설계입니다.다음 그림은 주계약의 아키텍처입니다.

녹색은 시스템에 참여하는 여러 역할만 나타내며 다른 색상은 스마트 계약의 하위 모듈입니다.

우선 레이어드 아키텍쳐라는 개념을 채택하여 시스템을 레이어로 나누었는데, 상위 레이어는 하위 레이어에 의존하지만 하위 레이어는 상위 레이어에 의존할 수 없습니다. 둘째, 모듈은 특정 구현이 아닌 인터페이스에만 의존합니다. 이러한 방식으로 모듈 간의 낮은 결합을 달성할 수 있습니다.

Trader 및 LP 사용자로서 그들은 모두 라우터와 균일하게 상호 작용하며 라우터는 라우팅 게이트웨이 역할을 하는 것과 같습니다. 또한 기본 레이어에 종속성이 없기 때문에 업그레이드 및 교체가 쉽습니다.

각 거래 쌍에는 Amm 계약과 마진 계약이 있으며 Amm과 마진은 서로 연결되어 있습니다. 따라서 팩토리 패턴을 사용하여 다양한 거래 쌍을 생성하는 것을 생각하는 것은 당연합니다. 원래 디자인에서는 사실 팩토리 컨트랙트가 하나밖에 없었지만, 실제 구현에서는 팩토리 컨트랙트가 스마트 컨트랙트의 최대 바이트 수를 초과한 것으로 최종 밝혀져 팩토리 컨트랙트를 3개로 분할했다.

Amm의 책임은 기본 교환 거래에 대한 책임이며 Margin의 책임은 사용자의 위치를 ​​관리하는 것입니다. LiquidityERC20은 Amm이 물려받은 유동성 토큰 계약입니다. Vault는 Margin이 상속한 실제 자산을 기본 계약으로 관리합니다. 이 모듈은 전체 프로토콜의 핵심이며 마진 추가 및 빼기, 포지션 열기 및 닫기, 유동성 추가 및 제거 등과 같은 하위 계층의 기본 기능만 구현합니다. 확장 가능한 기능은 라우터에 의해 실현되는 ETH 및 WETH의 교환 지원과 같은 상위 계층 모듈에 의해 구현될 수 있으며 가격 제한 주문, 손절 및 손절 등을 지원하기 위해 상위 계층 계약을 추가할 수 있습니다.

보조 제목

요약하다

요약하다

DeFi 애플리케이션 시스템의 전반적인 복잡성은 실제로 Web2 애플리케이션 시스템보다 훨씬 열등하지만 기술 스택이 거의 완전히 다르고 제품 사고도 상당히 다르고 DeFi 애플리케이션이 모두 오픈 소스이기 때문에 이 산업의 문턱이 됩니다. 따라서 경험이 없는 사람이 지금 시작하는 것은 사실 쉽지 않으며, Web2의 고급 인재라도 Web3에 진입한 후에는 여전히 배우고 축적하는 데 시간이 필요합니다.