최근 Uniswap Lab은 차세대 AMM Uniswap V4의 개발 진행 상황을 공식적으로 발표하고 백서 및 코드 저장소를 발표했습니다. 이번에는 V4 백서가 3페이지에 불과했는데, 그 이유는 V4가 AMM의 핵심 알고리즘 논리를 너무 많이 변경하지 않고 더 많은 시나리오의 요구를 충족시키기 위해 V3를 기반으로 몇 가지 새로운 기능을 추가했기 때문입니다. 현재 오픈 소스 코드를 기반으로 SharkTeam은 V4가 제공하는 새로운 기능을 살펴보고 V4에서 도입된 중요한 기능인 Hook에 대한 최상의 애플리케이션 사례를 분석합니다.

1. V4와 V3의 차이점

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에서 각 거래 쌍은 이론적으로 임의의 수의 풀을 가질 수 있으며 각 풀의 수수료율도 임의의 값이 될 수 있으며 이러한 풀의 틱 공간도 임의의 값이 될 수 있습니다.

이것은 또한 문제를 야기합니다. Uniswap V4의 거래 쌍의 유동성은 파편화될 것이므로 사용자가 최적의 거래 경로를 찾는 데 도움이 되는 보다 효과적인 라우터/집계기가 필요합니다.

1.2 후크

후크는 제3자 또는 유니스왑 공식이 개발한 일련의 계약입니다.풀을 만들 때 풀은 후크를 바인딩하도록 선택할 수 있습니다.후에 트랜잭션의 특정 단계에서 풀은 바인딩된 후크 계약을 자동으로 호출합니다. Uniswap V4는 후크 계약 코드를 실행할 수 있는 다음 단계를 정의합니다.

풀 초기화, 유동성 추가/삭제, 거래, 기부 등의 작업 전후에 후크 계약을 호출할 수 있음을 의미합니다.

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

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

따라서 Hook 개발자는 컨트랙트를 배포할 때 Pool의 요구 사항을 충족하는 주소를 생성해야 하며, 이를 위해서는 일반적으로 Create2 + 무작위 Salt 계산을 사용해야 합니다.

다음은 백서의 Hook 구현 예입니다.

스왑을 실행하기 전후에 풀은 해당 풀에 해당하는 Hook이 해당 플래그를 활성화했는지 여부를 먼저 확인하고 활성화되면 자동으로 Hook 계약의 해당 기능을 호출하는 것을 볼 수 있습니다.

1.3 동적 수수료 비율

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

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

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

후크는 Uniswap V4를 개발자 플랫폼으로 만들고 AMM에 더 많은 가능성을 제공합니다. Hooks로 구현할 수 있는 일부 기능에는 TWAMM(시간 가중 자동 시장 조성자), 지정가 주문(지정가 주문), LP 재투자 등이 있으며 이에 대해서는 다음 장에서 자세히 소개합니다.

1.4 싱글톤 계약

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

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

또한 싱글톤 컨트랙트를 사용하는 장점은 모든 풀이 같은 컨트랙트에 있기 때문에 컨트랙트 내에서 풀 간 스왑을 바로 완료할 수 있기 때문에 트랜잭션 중 토큰 전송을 줄일 수 있고 V3에서는 풀 간 스왑 서로 다른 풀 간에 토큰을 전송해야 하므로 가스가 증가합니다.

동시에 V4에서는 모든 풀이 동일한 컨트랙트를 사용하고 컨트랙트 내부의 토큰 장부도 간소화되어 각 토큰이 풀이 아닌 토큰별로 장부가 됩니다. 많은 수의 토큰도 더 편리할 것입니다.

1.5 익스로드

Hook과 다른 컨트랙트의 통합을 용이하게 하기 위해 V4 컨트랙트는 익스트로드 기능을 추가하여 컨트랙트의 모든 내부 상태를 외부에서 읽을 수 있게 하고 모든 풀의 상태를 외부에 완전히 투명하게 합니다.

1.6 플래시 회계

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

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

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

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

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

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

이러한 방식으로 거래가 여러 풀에서 교환되어야 하는 경우 결제를 위해 두 번의 전송만으로 충분합니다. 예를 들어 ETH->USDC-BTC와 같은 스왑에서 USDC는 중간 토큰으로 전송이 전혀 필요하지 않습니다.

1.7 ERC1155 발행/소각

Flash Accounting은 동일한 트랜잭션에서 스왑의 토큰 전송을 줄일 수 있으며 ERC1155 토큰을 사용하여 여러 트랜잭션의 토큰 전송을 더욱 줄일 수 있습니다.

V4는 ERC1155 mint를 통해 V4 컨트랙트에 토큰을 저장할 수 있으므로 매번 V4 컨트랙트로 토큰을 전송하지 않고도 여러 트랜잭션에서 이 토큰을 사용할 수 있습니다.

V4 컨트랙트에 저장된 토큰은 ERC1155 소각을 통해 출금이 가능합니다.

ERC1155는 유동성을 자주 교환하거나 추가/제거하는 사용자에게 적합하며, 이러한 사용자는 일반적으로 사용되는 토큰을 V4 계약에 직접 저장할 수 있어 토큰 전송의 가스 오버헤드를 줄일 수 있습니다.

2. Hooks에 대한 모범 사례의 예

2.1 TWAMM(시간 가중 자동화 마켓 메이커)

앨리스는 블록체인에서 1억 달러 상당의 이더를 구매하려고 합니다. Uniswap과 같은 기존 AMM(Automated Market Maker) 플랫폼에서 이러한 규모의 주문을 실행하는 것은 이러한 플랫폼이 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 결제에 영향을 미칩니다. 이를 위해서는 샌드위치 공격이 여러 블록에서 발생해야 하며, 다른 차익 거래자가 중간에 개입하여 공격자가 손실을 입을 수 있기 때문에 의심할 여지 없이 공격자에게 큰 위험을 초래할 것입니다.

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

2.1.3 V4의 TWAMM 워크플로

(1) 이 후크는 두 개의 트랜잭션 방향의 TWAP 주문을 각각 나타내는 두 개의 TWAP 주문 풀을 유지합니다.

(2) 사용자는 이 후크를 통해 TWAP 주문을 제출할 수 있으며 트랜잭션의 토큰, 수량 및 시간 길이를 지정해야 합니다.

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

(4) 트리거된 후 Hook은 두 개의 TWAP 주문 풀의 정산을 담당합니다.

(5) 사용자는 언제든지 수동으로 정산을 트리거할 수도 있습니다.

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

2.1.4 세부 예시

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

2.1.4 세부 예시

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

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

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

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

_executeTWAMMOrders 함수

위는 주문을 업데이트하는 실행 과정이며 실행이 완료되면 twamm의 현재 주문 실행 시간이 업데이트됩니다.

2.2 지정가 주문

최종 시장가에 즉시 체결되는 시장가 주문과 달리 지정가 주문은 미리 정해진 가격에 도달하면 바로 체결됩니다. 자동 시장 조성자(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 함수를 호출합니다.후크는 사용자가 추가하려는 유동성을 먼저 저장 풀에 추가한 다음 생성합니다. 사용자에 대한 해당 제한 주문.

이 훅은 각 스왑이 종료된 후 트리거되며 현재 가격 범위에 따라 범위 가격에 존재하는 지정가 주문을 기반으로 유동성 추가 작업이 완료됩니다.

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

사용자는 원하는 유동성을 인출하기 위해 유동성을 제거하고 싶을 때 인출 기능을 호출할 수 있습니다.

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

TWAMM 및 지정가 주문 외에도 LP 재투자 및 동적 취급 수수료 변경과 같은 기능도 Hook을 기반으로 실현할 수 있습니다.공간 제약으로 인해 후속 분석에서 소개합니다.

TWAMM 및 지정가 주문 외에도 LP 재투자 및 동적 취급 수수료 변경과 같은 기능도 Hook을 기반으로 실현할 수 있습니다.공간 제약으로 인해 후속 분석에서 소개합니다.

LP 재투자: 사용자는 후크를 사용하여 유동성을 추가, 수정 및 제거할 수 있으며 후크는 afterSwap 및 afterModifyPosition을 호출하도록 등록할 수 있습니다. 사용자가 유동성을 추가하기 위해 일률적으로 hook을 사용하기 때문에 poolManager에서 유동성을 추가하는 주소는 hook뿐입니다. 토큰은 다시 풀에 유동성을 추가하여 자동으로 사용자 수입을 최적화합니다.

동적 수수료 변경: 후크는 beforeSwap 및 기타 인터페이스를 등록하여 교환 전에 동적 수수료를 수정할 수 있습니다. 동적 취급 수수료는 단순히 시간에 따라 선형적으로 변경될 수 없으며 단일 스왑으로 생성된 틱 점프 수에 따라 변동성을 정량화할 수 있으므로 취급 수수료를 동적으로 변경하고 LP 비영구성 위험 헤징을 실현할 수 있습니다. 따라서 유동성 공급자에 대한 거래로 인한 비영구적 손실의 영향을 줄입니다.

3. 후크 보안 모범 사례

require 및 revert 사용 줄이기

풀의 Hooks 호출 함수 로직에서 롤백문의 사용을 최소화해야 하며 풀 컨트랙트와 Hooks 컨트랙트는 공통 관계이므로 Hooks에서 트랜잭션 롤백이 발생한 후 풀의 트랜잭션도 풀의 정상적인 트랜잭션과 관련되지 않은 후크의 롤백 문은 사용자가 풀의 기능을 정상적으로 사용하지 못하게 할 수 있습니다.

자체 소멸 함수 사용 방지

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

엄격한 액세스 제어

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

재입국 제한 조치를 잘 수행하십시오.

풀의 외부 확장 코드인 후크는 또한 네이티브 토큰을 전송할 때 지정가 주문에서 가능한 재진입 공격과 같이 컨트랙트 자산의 손실로 이어지는 재진입 공격에 주의해야 합니다. 외부 계약 또는 소위 "check-validate-interact" 패턴을 호출하기 전에 모든 상태를 확인하고 업데이트하십시오. 이렇게 하면 모든 상태 업데이트가 완료되므로 재진입해도 아무런 영향을 미치지 않습니다. .

계약 업그레이드 제어

계약 업그레이드 제어

일부 개발자는 프록시 계약을 사용하여 향후 후크의 논리를 변경하고 업그레이드할 수 있지만 계약 업그레이드에서 발생할 수 있는 문제에도 주의를 기울여야 합니다. 우선, hook에서 프록시 모드가 채택되더라도 해당 단계는 프록시 계약에서 beforeSwap과 같이 선언되어야 합니다. 그렇지 않으면 풀이 올바른 반환 값을 확인할 수 없습니다. 둘째, delegatecall을 호출하기 전에 대상 계약이 존재하는지 확인합니다.Solidity는 이 확인을 수행하지 않습니다.확인을 무시하면 예기치 않은 동작 및 보안 문제가 발생할 수 있습니다.변수가 압축되어 저장되므로 변수 선언 순서를 신중하게 고려하십시오. 동일한 슬롯, 가스 비용, 메모리 레이아웃 및 델리게이트 호출 결과와 같은 문제에 영향을 미칩니다.

회사 소개

SharkTeam의 비전은 Web3 세계의 보안을 포괄적으로 보호하는 것입니다. 이 팀은 전 세계의 숙련된 보안 전문가와 선임 연구원으로 구성되어 있으며 블록체인 및 스마트 계약의 기본 이론에 능숙하고 스마트 계약 감사, 온체인 분석 및 비상 대응을 포함한 서비스를 제공합니다. Polkadot, Moonbeam, 폴리곤, OKC, Huobi Global, imToken, ChainIDE 등과 같은 블록체인 생태계의 다양한 분야의 핵심 플레이어들과 장기적인 협력 관계를 구축했습니다.