Uniswap을 예로 사용하여 DEX 라우터 구성 및 분석에 사용되는 빌딩 블록에 대해 논의합니다.

星球君的朋友们

Odaily资深作者

2021-10-27 15:46 (UTC+8)

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

이 기사에서는 Uniswap V2 프로토콜 이상을 위한 라우터를 구축하고 분석하는 데 사용할 수 있는 빌딩 블록에 대해 설명합니다.

AI 요약

펼치기

이 기사에서는 Uniswap V2 프로토콜 이상을 위한 라우터를 구축하고 분석하는 데 사용할 수 있는 빌딩 블록에 대해 설명합니다.

개요

한 자산을 다른 자산으로 교환하는 것은 금융 시장의 기본 개념입니다. 암호화폐 시장에서 이것은 일반적으로 토큰이나 통화가 다른 사람과 교환되거나 거래되는 곳에서 발생합니다. Uniswap은 이러한 유형의 교환을 용이하게 하는 자동화된 유동성 프로토콜입니다. 두 자산의 풀 보유량인 쌍 또는 풀(이하 쌍이라고 함)을 사용하여 사용자가 한 자산을 다른 자산으로 교환할 수 있습니다.

그림 1.0: Uniswap 토큰 A 및 B 풀, 유동성 공급자(LP) 및 거래자를 위한 스왑 및 예금 상호 작용의 예. LP는 유동성을 제공하기 위해 풀 토큰을 받습니다.

누군가 원하는 자산이 거래하려는 자산과 쌍을 이루지 않으면 어떻게 됩니까 이 경우 원하는 자산을 얻기 위해 여러 쌍 간의 일련의 스왑 - 이를 용이하게 하는 데 사용되는 거래 쌍을 경로라고 합니다.

그림 2.0: USDC와 교환하여 DAI를 거래하는 여러 쌍을 포함하는 경로.

이미지 설명

그림 3.0: Paraswap 라우터에 의해 설명된 다중 경로 라우팅

이미지 설명

그림 4.0: 다중 라우팅

슬리피지는 자산에 대해 지불할 것으로 예상되는 가격과 실제로 지불한 금액 사이의 차이로, 주문이 시장에 진입한 시점과 거래가 실행된 시점 사이의 가격 변동 또는 낮은 볼륨 및 유동성과 같은 요인으로 인해 발생합니다.

라우터는 이러한 요소를 고려하여 트랜잭션 수에 적합한 경로를 생성해야 합니다. 또한 시장 상황이 자주 바뀌고 가스 요금과 풀 유동성에 영향을 미치기 때문에 결과 경로도 역동적일 것입니다. 지금 좋은 경로가 반드시 한 시간 후나 다음 날에 좋은 성과를 내지 못할 수도 있습니다.

이 기사의 나머지 부분에서는 Uniswap V2 프로토콜 이상을 위한 라우터를 구축하고 분석하는 데 사용할 수 있는 빌딩 블록에 대해 설명합니다.

첫 번째 레벨 제목

데이터 모델링

참고: 여기에 언급된 그래프 프로토콜은 다음 섹션에서 설명하는 그래프 데이터 유형과 다릅니다. 그래프 프로토콜은 하나 이상의 스마트 계약에 대한 블록체인 트랜잭션의 인덱스이며, 그래프 데이터 유형은 수학적 그래프 이론을 사용한 데이터 표현을 나타냅니다.
지도를 사용하여 지점 사이를 탐색하는 것처럼 그래프 데이터 유형을 사용하여 사용 가능한 유동성 쌍을 탐색하여 수익을 개선하기 위해 평가할 수 있는 경로를 생성할 수 있습니다. Uniswap 쌍을 모델링할 때 처음에 수행할 몇 가지 구현 선택 사항이 있습니다.
꼭짓점 또는 가장자리로서의 쌍, 기호 또는 자산 식별자 ?

지시 또는 무 지시?

단순 또는 다중 사진?
위의 구현 선택을 하려면 Uniswap 쌍의 속성을 이해하는 것이 중요합니다.
각 쌍에는 고유한 ID가 있습니다.
각 쌍에는 기호, 이름, ID 데이터 쌍에 대한 2개의 토큰이 포함됩니다.
토큰 기호는 고유하지 않습니다. 예를 들어 BOND 기호는 다양한 자산이나 ID를 나타냅니다.

토큰 이름도 고유하지 않아도 됩니다.

Uniswap 쌍의 이러한 속성은 토큰 ID를 그래프 데이터 유형의 정점으로 사용하도록 제안합니다. 그래프의 가장자리가 고유한 ID 쌍을 나타내는 것을 볼 수 있습니다. 이 형식에서 그래프는 무방향 또는 방향이 될 수 있으며 각 에지는 ID, 토큰 가격 및 준비금 쌍을 나타냅니다. 그러나 토큰 가격과 예약 정보를 지속적으로 업데이트해야 하는 필요성은 이 데이터를 적절한 실시간 설정으로 캐시 구조에 저장하는 것이 정적 분석보다 특히 실시간 트랜잭션이 있는 애플리케이션의 경우 더 효율적이고 확장 가능할 수 있음을 시사합니다.

앞으로 Uniswap V2와 V3 프로토콜 쌍 간의 라우팅이 바람직합니다. 이 시나리오에서는 동일한 토큰 ID 쌍이 여러 개 있을 수 있습니다. 한 쌍의 ID 사이에 여분의 에지를 추가하는 것이 가능하지만 다른 솔루션은 동일한 에지에서 서로 다른 ID 쌍을 그룹화하여 다중 그래프를 순회하는 성능 비용을 피하는 것입니다. 다음은 기호 ID가 기호 이름을 대체하는 그룹화된 쌍 ID의 단순한 무향 그래프 구조의 부분적인 예입니다.

이미지 설명

그림 5.0: 단순한 무방향 그래프에서 Uniswap V2 및 V3 프로토콜 쌍 모델링(실제 구조는 토큰 기호가 아닌 토큰 ID를 사용하므로 여기서는 복잡할 것입니다).

처음에 깊이 우선 검색(DFS)은 일반적으로 깊이 제한이 4인 그래프를 탐색하는 것으로 나타났습니다. 이 깊이에 대한 예외는 연결된 노드 수가 30000을 초과하는 WETH의 경로입니다. 경로가 WETH에서 출발하면 통과 시간을 줄이기 위해 DFS는 2로 제한됩니다.

그래프 데이터베이스 Neo4J 및 RedisGraph를 포함하여 그래프 데이터 유형 작업을 위한 많은 도구가 있습니다. 이러한 논의는 이 기사의 범위를 벗어나며 현재 프로젝트 요구 사항은 Javascript 라이브러리 Graphlib에서 충족할 수 있습니다. 그러나 라우팅 문제가 LinkedIn 또는 기타 대규모 네트워크의 규모로 확장되는 경우 위에서 설명한 그래프 데이터베이스의 규모는 비용과 개발 복잡성을 상쇄하면서 이러한 요구 사항을 충족합니다.

강제

WETH
DAI
USDC
USDT
COMP
MKR

제약 조건은 그래프 데이터 구조에서 경로를 계산할 때 유용합니다. 예를 들어 제한된 수의 쌍만 통과하는 경로를 식별하는 데 도움이 되거나 특정 자산이 포함된 쌍을 무시하는 데 사용할 수 있습니다.

기존 Uniswap V2 라우팅은 주로 공항 허브와 비교할 수 있는 6개의 자산을 통한 라우팅입니다. 이 6가지 자산은 다음과 같습니다.

이 6가지 자산은 일반적으로 사용되기 때문에 유용하고 다른 자산과 쌍을 이룰 때 유동성 제약을 부과하지 않습니다(즉, 희소하지 않고 새로운 검증되지 않은 암호화 자산과 경쟁하지 않으며 동일한 위험을 내포함). 그러나 이를 사용하면 다음과 같이 효율성 문제가 발생할 수 있습니다.

"Uniswap은 분산된 방식으로 교환을 라우팅하지 않습니다."
위에서 언급한 6개의 "피벗" 자산을 무시하는 것과 같은 제약 조건을 사용하면 현재 Uniswap V2 인터페이스가 사용자에게 제공하는 것보다 더 효율적인 잠재적 라우팅을 탐색할 수 있습니다. 제약 조건은 다음과 같은 다른 기준으로 확장할 수도 있습니다.

특정 가격으로 특정 풀을 통한 라우팅. (Uniswap V3 프로토콜용).

제약 조건이 구성 가능하다는 점도 주목할 가치가 있습니다. 즉, 라우팅이 각각 X 이상의 유동성을 가진 최대 2개의 풀로 제한될 수 있도록 결합할 수 있습니다. 현재 데이터 모델은 그래프 데이터 유형과 조회 테이블 간에 데이터를 분할합니다. 즉, 그래프 순회 중 및 이후에 쌍 데이터가 발견되면 라우팅을 정리할 수 있습니다.

첫 번째 레벨 제목

확장하다
확장 프로그램은 주로 현재 시장 데이터를 기반으로 경로를 계산하기 위해 공용 API를 라우터에 노출하는 것을 고려합니다. 성능은 다음의 함수입니다.
경로 계산 시간

라우팅 요청의 영향을 계산하는 데 필요한 시간

아래 다이어그램은 가장 자주 요청되는 경로에 대한 캐시와 라우팅된 요청의 영향을 계산하는 데 사용되는 캐시 쌍 데이터가 있는 초기 시스템 아키텍처를 보여줍니다. 이 아키텍처는 매우 유연하며 다양한 방식으로 수평 확장이 가능합니다. 예를 들어, 그래프 데이터 구조와 라우팅 캐시, 요청 수집기 및 쌍 캐시를 완전히 복제하거나 단순히 캐시를 복제하고 캐시 간에 라우팅 요청을 배포합니다.

그림 6.0: 확장 가능한 구성 요소, 캐싱 및 주기적 업데이트가 포함된 라우팅 서비스 아키텍처.

또 다른 잠재적인 확장성 수정은 라우팅 요청 및 수량을 고려하는 전체 라우팅 솔루션 캐시일 수 있으며, 수량이 특정 허용 범위 내에 있는 경우 최근에 계산된 결과를 재사용할 수 있습니다. 사용자 경험과 응용 프로그램의 요구 사항에 따라 가장 최근에 계산된 결과를 중간 결과로 사용할 수도 있고 사용자를 위해 더 정확한 결과를 계산할 수도 있습니다.

라우팅 캐시

경로 캐시는 데이터 원본의 정기적인 업데이트 빈도와 관련된 TTL(Time-to-Live)과 함께 가장 자주 요청된 경로의 결과로 구성됩니다. 예를 들어 WETH와 DAI 사이의 경로가 이전에 요청된 경우 그래프 순회 결과는 가능한 경로의 배열로 경로 캐시에서 찾을 수 있습니다. [WETH -> USDC -> DAI, WETH -> WBTC -> DAI , ...]. 토큰 가격 및 준비금과 같은 쌍 데이터와 달리 라우팅 확률(특히 쌍의 존재)은 덜 변경되므로 이 캐시의 TTL은 쌍 데이터 캐시보다 훨씬 클 것으로 예상됩니다. 또한 이 구성 요소는 작동하지 않는 경로(즉, 만료되거나 대체된 토큰 주소 또는 비유동 쌍)에 대한 휴리스틱을 포함하도록 확장될 수 있습니다.

첫 번째 레벨 제목

페어링된 데이터 캐시

또한 사용자 경험을 향상시키기 위해 업데이트된 데이터를 가져오고 계산할 때 이전 데이터를 기반으로 한 사전 결과가 표시될 수 있습니다.

정적 분석

첫 번째 레벨 제목

생성된 경로를 기존 Uniswap V2 라우터의 경로와 비교하여 라우팅 성능을 평가합니다. 특히, 주어진 양의 소스 토큰에 대한 보상을 계산합니다. 예를 들어, DAI에서 COMP로의 트랜잭션에서 100만 DAI 토큰에서 수신한 COMP의 양을 계산하고 Uniswap V2 라우터가 제안한 경로에서 얻은 동일한 결과를 확인하여 라우터의 성능을 비교하게 됩니다. 성능은 다양한 입력(예: 서로 다른 초기 숫자, 검색 깊이에 대한 서로 다른 제한 등)에 대해 측정됩니다.

정적 분석을 수행할 때 그림 6.0과 같이 데이터에 대한 캐싱 및 번들링 요청이 필요하지 않습니다. 정적 분석은 블록체인의 특정 블록 시간에 트랜잭션을 계산하는 것입니다. 비교를 위한 결과의 일관성과 재현성을 용이하게 합니다. Uniswap V2용 새 라우터를 설계하기 위한 초기 작업 범위는 트랜잭션 집합을 한 블록 시간에 평가하고 기존 라우팅 알고리즘 또는 변형과 비교할 수 있는 정적 분석의 도움을 받았습니다. 기본 쌍 데이터가 변경되면 거래 결과의 개선 또는 감소가 알고리즘 변경 또는 쌍 유동성 및 가격 책정으로 인한 것인지 명확하지 않습니다.

첫 번째 레벨 제목

데이터 소스
블록체인 기술이 발전함에 따라 블록체인에서 현재 및 과거 데이터를 제공하는 수많은 서비스가 등장했습니다. 데이터 소스 선택에는 다음 사항을 고려해야 합니다.
예산
개발 노력 및 비용

지연

데이터 정확도

스위치 라우터 설계가 평가되면 실시간 데이터의 경쟁력이 필요하기 때문에 이 데이터 소스는 경로 생성에 적합하지 않은 것으로 판명됩니다. 이러한 시나리오에서는 Alchemy, Infura 또는 기타 소스의 Ethereum 노드와 같은 블록체인의 현재 상태에서 직접 데이터가 필요합니다.