첫 번째 수준 제목

보조 제목

1.1 AMM

AMM 알고리즘 수준에서 Uniswap V4는 V3를 수정하지 않았으며 여전히 상수 곱 x*y=k를 기반으로 하는 유동성 알고리즘을 사용합니다.

Uniswap V3에서 각 거래 쌍은 각각 0.01%, 0.05%, 0.3% 및 1% 비율의 풀을 나타내는 4개의 풀(원래 3개, 나중에 새로운 1bp 풀이 추가됨)을 가질 수 있습니다. 풀 생성 시에는 이 4가지 유형 중 하나만 선택할 수 있습니다.

Uniswap V4에서 각 거래 쌍은 이론적으로 임의 개수의 풀을 가질 수 있으며 각 풀의 수수료율도 임의의 값이 될 수 있으며 이러한 풀의 틱 공간도 임의의 값이 될 수 있습니다.

보조 제목

1.2 Hooks

후크는 제3자 또는 Uniswap 관계자가 개발한 계약 세트입니다. 풀을 생성할 때 풀은 후크 바인딩을 선택할 수 있습니다. 이후 거래의 특정 단계에서 풀은 바인딩된 후크 계약을 자동으로 호출합니다. Uniswap V4는 후크 계약 코드가 실행될 수 있는 다음 단계를 정의합니다.

• beforeInitialize

• afterInitialize

• beforeModifyPosition

• afterModifyPosition

• beforeSwap

• afterSwap

• beforeDonate

• afterDonate

이는 풀 초기화, 유동성 추가/제거, 거래, 기부 등의 작업 전후에 Hook Contract를 호출할 수 있음을 의미합니다.

Hook 컨트랙트는 위 단계 중 어느 단계를 실행할지 명시적으로 지정해야 하며, 풀은 특정 단계에서 해당 Hook을 실행해야 하는지 여부를 알아야 합니다.가스를 절약하기 위해 이러한 플래그는 컨트랙트에 저장되지 않지만, 주소를 표시하기 위해 특정 주소를 사용하려면 Hook이 필요합니다. 구체적인 판단코드는 다음과 같습니다.

Hook 주소의 처음 8비트는 Hook이 특정 단계에서 실행되어야 하는지 여부를 표시하는 데 사용되지 않음을 알 수 있습니다.

따라서 Hook 개발자는 계약을 배포할 때 풀의 요구 사항을 충족하는 주소를 생성해야 하며, 이를 달성하려면 일반적으로 Create 2 + 무작위 솔트 계산을 사용해야 합니다.

다음은 백서에 있는 Hook 실행의 예입니다.

보조 제목

1.3 동적 수수료 비율

특정 단계에서 코드를 실행하는 것 외에도 Hook은 특정 풀의 스왑 수수료율과 인출율을 결정할 수도 있습니다. 출금율은 사용자가 유동성을 출금할 때 Hook에 지불해야 하는 요율을 의미합니다. 또한 Hook은 스왑 수수료의 일부를 자체적으로 지정할 수도 있습니다.

풀을 생성할 때 수수료 매개변수(단위 24)의 처음 4비트를 사용하여 풀이 동적 수수료를 사용하는지 여부와 후크 스왑 수수료 및 인출 수수료를 활성화할지 여부를 표시해야 합니다.

동적 수수료가 활성화된 경우 풀은 각 스왑 전에 현재 스왑 수수료 비율을 얻기 위해 Hook 계약을 호출합니다. Hook 계약은 현재 스왑 수수료 비율을 반환하기 위해 getFee() 함수를 구현해야 합니다.

보조 제목

1.4 싱글톤 계약

Uniswap V3에서는 새로운 풀이 생성될 때마다 새로운 계약을 배포해야 하는데, 이로 인해 많은 가스가 소모되지만 실제로 이러한 풀에서 사용하는 코드는 동일하고 초기화 매개변수만 다릅니다. Uniswap V4는 모든 풀을 관리하는 싱글톤 계약을 도입하여 새 풀을 생성할 때 더 이상 새 계약을 배포할 필요가 없으므로 계약 배포에 필요한 가스를 절약합니다.

또한, 싱글톤 컨트랙트를 사용하면 모든 풀이 동일한 컨트랙트에 속해 있기 때문에 컨트랙트 내에서 풀 간 스왑을 직접 완료할 수 있어 트랜잭션 중 토큰 전송을 줄일 수 있다는 장점이 있으며, V3에서는 풀 간 교환 서로 다른 풀 간에 토큰을 전송해야 하므로 가스가 증가합니다.

보조 제목

1.5 extload

보조 제목

1.6 Flash Accounting

풀 스왑에서 토큰 전송을 줄이기 위해 V4는 플래시 회계라는 방법을 사용하여 스왑 프로세스를 표준화하고 유동성/플래시 대출을 플래시 대출과 유사한 프로세스에 추가/제거합니다.

(1) 사용자가 잠금을 획득합니다.

(2) 사용자는 여러 풀에서 스왑, 유동성 추가/제거, 플래시 대출을 통해 풀에서 토큰 차용 등의 작업을 수행합니다.

(3) 모든 사용자 작업으로 생성된 토큰 전송은 잠금에 기록됩니다.

(4) 모든 작업이 완료된 후 사용자는 획득한 토큰을 가져갈 수 있으며 동시에 잠금 장치에 기록된 지불해야 하는 토큰을 지불해야 합니다.

이러한 프로세스는 하나의 트랜잭션에서 발생해야 합니다.

보조 제목

1.7 ERC 1155 mint/burn

Flash Accounting은 동일한 거래 내에서 스왑의 토큰 전송을 줄일 수 있으며, ERC 1155 토큰을 사용하면 여러 거래의 토큰 전송을 더욱 줄일 수 있습니다.

V4를 사용하면 ERC 1155 mint를 통해 V4 계약에 토큰을 저장할 수 있으므로 매번 V4 계약으로 토큰을 전송하지 않고도 여러 거래에서 이러한 토큰을 사용할 수 있습니다.

V4 컨트랙트에 저장된 토큰은 ERC 1155 소각을 통해 출금할 수 있습니다.

첫 번째 수준 제목

보조 제목

2.1 TWAMM(시간 가중 자동 시장 조성자)

앨리스는 블록체인에서 1억 달러 상당의 이더를 사고 싶어합니다. Uniswap과 같은 기존 자동화 시장 조성자(AMM) 플랫폼에서 이러한 규모의 주문을 실행하는 것은 Alice가 더 나은 가격을 얻기 위해 내부 정보를 사용하는 것을 방지하기 위해 Alice가 엄청난 수수료를 부과할 가능성이 높기 때문에 엄청나게 비용이 많이 듭니다.

더 나은 가격을 얻기 위해 Alice의 최선의 선택은 주문을 수동으로 여러 개의 작은 하위 주문으로 분할하고 몇 시간에 걸쳐 단계별로 실행하는 것입니다. 그 아이디어는 그녀가 내부 정보가 없다는 것을 시장이 깨닫고 더 나은 가격을 제시할 수 있도록 충분한 시간을 주는 것입니다. 그러나 그녀가 여러 개의 대규모 하위 주문을 보내더라도 각 하위 주문은 여전히 ​​가격에 상당한 영향을 미치며 적대적인 거래자의 샌드위치 공격에도 취약합니다.

TWAMM은 Alice를 대신하여 거래를 수행함으로써 이 문제를 해결합니다. 이는 시간 내에 원활한 실행을 보장하기 위해 그녀의 주문을 무한한 수의 작은 가상 주문으로 분해합니다. 동시에 TWAMM은 내장된 AMM 프로토콜의 특별한 수학적 관계를 사용하여 이러한 가상 주문 간에 가스 비용을 공유할 수 있습니다. TWAMM은 블록 간 트랜잭션을 처리하므로 '샌드위치 공격'에도 취약하지 않습니다.

전반적으로 TWAMM은 Alice에게 높은 수수료와 잠재적인 시장 조작을 피하면서 대규모 거래를 수행하는 보다 효율적인 방법을 제공합니다.

2.1.1 원리

TWAMM에는 AMM이 내장되어 있어 다른 AMM과 다르지 않으며, 사용자는 이 AMM을 통해 직접 현물 거래를 하거나 유동성을 추가할 수 있습니다. 그러나 TWAMM에는 양방향으로 TWAP 주문을 실행하는 데 사용되는 두 개의 TWAP 주문 풀이 있습니다. 사용자가 주문을 제출할 때 토큰 입력 수량과 거래 기간을 지정하면 TWAMM은 동일한 거래 방향의 주문을 넣습니다. 해당 풀에 넣고, 지정된 거래 속도에 따라 자동으로 거래를 진행합니다. 사용자의 주문이 완전히 실행되면 사용자는 거래에서 얻은 토큰을 꺼낼 수 있습니다. 물론, 사용자는 주문이 실행되기 전에 미리 주문을 취소하거나 주문에 필요한 토큰 수를 수정할 수도 있습니다.

이더리움에서 스마트 계약은 EOA 주소로 시작된 트랜잭션에 의해서만 실행될 수 있으며 자동으로 실행될 수 없습니다. 따라서 TWAMM은 정기적으로 EOA 계정에서 트랜잭션을 보내 주문 풀에서 거래할 토큰을 정산해야 하며, 이러한 트랜잭션을 실행하려면 키퍼 계정이 필요합니다.

물론 TWAMM은 사용자가 상호 작용할 때마다 자동으로 주문 풀을 정산할 수 있으므로 키퍼의 오버헤드를 절약할 수 있으며 이는 DeFi 프로토콜이 스트리밍 데이터를 처리하는 일반적인 방법이기도 합니다.

2.1.2 이 거래 모델이 샌드위치의 공격을 받기 어려운 이유는 무엇입니까?

이런 종류의 공격은 구현하기 어렵고 블록의 타임스탬프가 변경되지 않으므로 공격자는 블록의 마지막 트랜잭션에서 풀 가격을 높여야 다음 블록의 TWAMM 정산에 영향을 미칩니다. 이를 위해서는 샌드위치 공격이 여러 블록에서 발생해야 하며, 이는 의심할 여지 없이 공격자에게 큰 위험을 가져올 것입니다. 중간에 다른 차익거래자가 개입하여 공격자가 손실을 입을 수 있기 때문입니다.

동시에 차익거래자의 존재로 인해 이러한 가격 조작은 지속 불가능할 수밖에 없으며, TWAP 주문의 특성상 단기간에 너무 많은 토큰을 거래하지 않으므로 대부분의 경우 손실이 발생합니다. 제한되어야 합니다.

2.1.3 V4의 TWAMM 워크플로우

(1) 이 후크는 두 개의 거래 방향의 TWAP 순서를 각각 나타내는 두 개의 TWAP 주문 풀을 유지합니다.

(2) 사용자는 이 후크를 통해 TWAP 주문을 제출할 수 있으며 토큰, 수량 및 거래 기간을 지정해야 합니다.

(3) 이 Hook은 beforeSwap과 beforeModifyPosition을 등록하며, 이 Hook은 사용자가 포지션을 거래하거나 조정할 때마다 실행됩니다.

(4) 후크는 트리거된 후 2개의 TWAP 주문 풀 정산을 담당합니다.

(5) 사용자는 언제든지 수동으로 결제를 시작할 수도 있습니다.

(6) 사용자는 TWAP 주문에서 토큰 수량을 취소하거나 수정할 수 있습니다.

2.1.4 상세 예시

TWAMM은 후크의 논리 호출을 위한 3단계를 등록하고 풀 초기화 전에 TWAMM을 초기화하며 사용자가 포지션을 거래하거나 조정할 때마다 이 후크를 트리거합니다.

사용자는 TWAMM에서 submitOrder 함수를 수동으로 호출하여 계약을 실행하는 데 필요한 주문을 제출할 수 있습니다.

사용자가 계약에 실행해야 하는 주문을 추가한 후에는 풀이 스왑 및 수정 위치 작업을 수행할 때마다 해당 주문이 자동으로 실행됩니다.

사용자가 거래를 위해 v4의 스왑 기능을 호출하거나 포지션을 변경하기 위해 수정Position 함수를 호출할 때마다 TWAMM의 실행 기능이 트리거되고 함수에서 내부 함수 _executeTWAMMOrders가 호출되어 이전에 완료되지 않은 주문의 실행을 계속합니다. .

_executeTWAMMOders 함수

보조 제목

2.2 Limit Order

최종 시장가에 즉시 체결되는 시장가 주문과 달리 지정가 주문은 미리 정해진 가격에 도달하자마자 체결됩니다. 자동 시장 조성자(AMM)를 기반으로 하는 대부분의 DEX는 기본적으로 시장 주문 시스템을 선택합니다. 초보자도 간단하고 이해하기 쉽습니다. 시장가 주문은 최대 가격 영향과 같은 매개변수로 인해 실행되거나 실패합니다. 지정가 주문에서는 자산 가격이 지정가에 도달한 경우에만 주문이 체결되며, 그렇지 않은 경우 주문은 그대로 유지됩니다.

예를 들어, ETH가 현재 ETH/DAI 풀에서 1 ETH = 1500 DAI로 거래되고 있다고 가정합니다. 사용자는 이익 실현 주문을 할 수 있으며 주요 내용은 다음과 같습니다."1 ETH = 2000 DAI이면 내 ETH를 모두 매도하세요.". 이 가격에 도달하면 사용자의 ETH는 분산된 방식으로 완전히 온체인 DAI로 자동 교환됩니다.

이전 버전의 Uniswap에서는 지정가 주문이 사실상 불가능했습니다. 대부분의 AMM은 시장 매수 및 매도만 허용합니다. V4 버전에서는 후크의 강력한 기능과 확장성으로 인해 v4에서 지정가 주문을 구현하는 기반이 마련되었습니다.

2.2.1 원리

지정가 주문의 설계 원리는 twamm보다 간단하며 현재 유동성 추가를 위한 지정가 주문이 구현되어 있으며 거래를 위한 지정가 주문의 구현이 더 쉬워질 것입니다.

v4에는 TickLower와 TickUpper가 있기 때문에 풀의 거래조건 변화에 따라 하한과 상한이 변경되는데, 사용자가 유동성을 추가할 때 현재 가격으로 추가하고 싶지는 않습니다. 한도 주문 후크를 사용하여 이 요구 사항을 구현하고 후크에 해당 가격을 설정합니다. 매 스왑 후 후크는 현재 풀 가격을 판단합니다. 설정된 가격에 도달하면 해당 유동성을 추가하여 수입을 얻습니다.

2.2.2 V4의 지정가 주문 작업흐름

1. 한도는 다양한 최저가 및 거래 방향에 대한 지정가 주문으로 여러 시대를 유지합니다.

2. 이 후크를 통해 사용자는 자신의 가격 하한 및 거래 방향을 제출하고 계약에 지정가 주문을 추가합니다.

3. 이 후크는 각 스왑이 끝난 후 가격이 변경될 때만 트리거되는 afterSwap을 등록합니다.

4. Hook은 발동된 후 현재 가격 범위를 확인하고, 현재 가격에 유동성을 추가해야 하는 지정가 주문이 있는지 epoch부터 확인합니다.

5. 사용자는 언제든지 자금을 인출하거나 직접 유동성을 추가할 수 있습니다.

2.2.3 세부 예시

후크는 계약 등록의 두 단계로 트리거되며, 풀이 초기화된 후 후크가 초기화되고, 각 교환 후에 후크 로직이 트리거됩니다.

사용자는 place 함수를 호출하여 사용자가 추가하고 싶은 유동성의 수량, 가격, 거래 방향을 전달하는데, Hook은 먼저 사용자가 추가하려는 유동성을 Pool에 추가하여 보관한 후 생성합니다. 사용자에 대한 해당 제한 주문.

이 후크는 각 스왑이 종료된 후 실행되며, 현재 가격 범위에 따른 범위 가격에 존재하는 지정가 주문을 기반으로 유동성 추가 작업이 완료됩니다.

지정가 주문이 완료되기 전에 사용자는 kill 함수를 호출하여 지정가 주문을 취소하고 이번에 유동성을 추가하는 이점을 얻을 수 있습니다.

사용자가 유동성을 제거하고 싶을 때, 철회 기능을 호출하여 원하는 유동성을 철회할 수 있습니다.

일반적으로 이 지정가 주문 후크는 사용자에게 보다 편리한 방법을 제공합니다. 사용자는 유동성을 추가하고 싶을 때 가격을 설정할 수 있습니다. 풀의 가격 범위가 가격에 도달한 후 후크는 자동으로 사용자를 위해 풀에 들어갑니다. 유동성 추가 작업을 수행하며, 사용자는 언제든지 유동성을 취소하고 철회할 수 있습니다.

TWAMM 및 지정가 주문 외에도 LP 재투자, 동적 수수료 변경 등의 기능도 Hook을 기반으로 구현할 수 있으며, 공간상의 이유로 후속 분석에서 소개하겠습니다.

LP 재투자: 사용자는 후크를 사용하여 유동성을 추가, 수정, 제거할 수 있으며 후크는 afterSwap 및 afterModifyPosition을 등록하여 호출할 수 있습니다. 유동성 추가를 위해 사용자들은 일률적으로 Hook을 사용하기 때문에 poolManager에서 유동성을 추가하는 유일한 주소는 Hook입니다. Hook은 실행될 때마다 현재 시간을 확인할 수 있습니다. 일정 시간이 지나면 유동성 보상을 철회하고 LP를 받을 수 있습니다. 토큰은 풀에 유동성을 다시 추가하여 사용자 소득을 자동으로 최적화합니다.

첫 번째 수준 제목

보조 제목

require 사용을 줄이고 되돌리기

Hook을 호출하는 Pool의 함수 로직에서는 Rollback문의 사용을 최소화하고, Pool Contract와 Hooks Contract는 공통 관계를 가지므로 Hook에서 트랜잭션 롤백이 발생한 후에는 Pool에 있는 트랜잭션도 롤백됩니다. 풀 내 일반 트랜잭션과 관련되지 않은 후크의 롤백 문으로 인해 사용자가 풀 내 기능을 정상적으로 사용하지 못할 수 있습니다.

자기 파괴 기능을 사용하지 마세요

Hook에서 selfdestruct 기능을 사용하지 마십시오.Hook에서 self-destruct 함수를 호출하면 Hook의 로직에 문제가 발생할 뿐만 아니라 Pool의 기능이 실패하여 Pool에 있는 자산이 손실될 수 있습니다. 전체 풀이 손실되고 기능이 실패합니다. 제대로 작동합니다.

엄격한 접근 통제

과도한 권한을 가진 역할을 방지하기 위해 후크 계약에서 권한을 엄격하게 제어하고, 권한 있는 역할에 대해 다중 서명 관리를 수행하여 단일 지점 공격을 방지합니다. 권한 있는 역할이 계약 상태 변수를 임의로 수정할 수 있는 상황을 방지하기 위해 논리 오류가 발생하여 전체 트랜잭션이 롤백되어 풀의 정상적인 사용에 영향을 미칠 수 있습니다. 최소 권한 원칙을 확인하려면 openzeppelin의 AccessControl 계약을 사용하여 액세스를 제어하기 위한 보다 세분화된 권한을 구현해야 합니다. 이 방식은 각 시스템 구성 요소가 최소 권한 원칙을 따르도록 제한하기 때문입니다.

재입국 금지 조치를 잘 수행하십시오.

풀의 외부 확장 코드로서 후크는 네이티브 토큰을 전송할 때 제한 주문에서 재진입 공격이 발생할 수 있는 등 계약에서 발생할 수 있는 재진입 공격에도 주의해야 하며 이로 인해 계약 자산이 손실됩니다. 외부 계약이나 소위 확인-검증-상호작용 패턴을 호출하기 전에 모든 상태를 확인하고 업데이트해 보십시오. 이렇게 하면 모든 상태 업데이트가 완료되므로 재진입도 아무런 영향을 미치지 않습니다. .

계약 업그레이드 제어

첫 번째 수준 제목

About Us

공식 웹 사이트:

공식 웹 사이트:https://www.sharkteam.org

Twitter：https://twitter.com/sharkteamorg

Discord：https://discord.gg/jGH9xXCjDZ

Telegram：https://t.me/sharkteamorg