Friend.Tech를 예로 들어, 체인 상 로봇의 기본 원리를 간단히 분석하다
체인 상 로봇은 어떻게 프론트엔드를 우회하여 구매, 판매를 완료하고, 신규 구매, 매매, 수수료 사기를 수행하는가?저자：3PDAO
서문
Friend.Tech는 스마트 계약 기반의 소셜 플랫폼으로, 사용자는 자신의 트위터를 연결하여 등록하고 "키"를 발행해야 합니다. 키를 가진 사용자는 키의 소유자와 소통할 수 있는 그룹 채팅과 유사한 방에 들어갈 수 있습니다. 여전히 중앙 집중화된 소셜 플랫폼이며, 체인상의 스마트 계약을 통해 키의 구매 및 판매 논리를 구현하고, 주요 기능은 웹 기반의 IM 애플리케이션으로 구현됩니다. 또한 키를 판매하고 구매하는 과정에서 가치의 10%가 두 부분으로 나뉘어, 한 부분은 Friend.Tech 개발자에게, 다른 부분은 해당 방의 소유자에게 지급됩니다.
이러한 키가 프론트엔드를 우회하여 구매 및 판매될 수 있는 상황에서, 자연스럽게 체인상의 로봇이 등장하여 신규 구매, 매매, 수수료 사기를 수행하게 됩니다. 그렇다면 이들은 어떻게 구현될까요?
신규 구매 로봇에 대해 이야기해봅시다
Friend.Tech 운영 초기에는 신규 구매 로봇이 상당한 수익을 올릴 수 있습니다. 이 시점에서는 체인상의 저격 로봇이 아직 일정 수준으로 진화하지 않았기 때문에, 간단한 정보 판단 후 구매를 진행하고 높은 수익 기대치를 가질 수 있습니다. 이제 가장 간단한 로봇 구현 논리부터 시작하여 복잡한 봇 논리를 단계별로 완성해 보겠습니다.
물론, 그 전에 Event를 소개해야 합니다. 이벤트는 Solidity 프로그래밍 언어에서 EVM의 로그 이벤트에 대한 추상화입니다. 일반적으로 emit 문과 함께 사용되어 이벤트를 트리거합니다. 블록체인 탐색기에서 이는 거래의 로그에 해당하며, 아래의 키 구매 거래처럼 Trade 이벤트를 트리거하며 이벤트에는 일련의 정보가 포함됩니다.
Event는 DApp에서 매우 중요한 부분으로, 이를 통해 계약의 상태 변화를 감지할 수 있습니다. 예를 들어 Friend.Tech는 해당 계약을 감시하여 데이터베이스의 일련의 데이터를 조정합니다. 예를 들어 프론트엔드의 표시 가격, 보유 수량 등이 있습니다.
가장 간단한 사고 방식
가장 간단한 신규 구매 로봇의 논리는 다음과 같습니다: Friend.Tech의 계약 이벤트를 감시하고, 거래에서 발생한 이벤트가 다음 조건을 만족할 때 Friend.Tech의 계약을 호출하여 구매합니다.
이벤트가 구매일 때 (
isBuy값이 참)거래자와 소유자가 동일한 주소일 때 (
trader==subject)거래가 방 생성 거래일 때 (
supply가 1)
아래 그림은 이 과정의 흐름을 나타냅니다.
계약? 원자성!
이러한 로봇은 몇 가지 문제를 가지고 있습니다:
신규 구매가 반드시 이루어질 수 없으며, 구매 키에 필요한 이더 수량을 정확하게 제시할 수 없습니다.
거래 실행 시 특정 키 수량이나 가격에 도달하면 구매를 중단하는 상한 가격을 설정할 수 없습니다.
저격당하기 쉽고, 다른 사람들이 새로운 주소를 통해 구매 작업을 수행하여 이러한 로봇을 유인하여 수수료를 사기치고 이익을 얻을 수 있습니다.
먼저 문제 1과 2를 해결하는 것을 고려해 보겠습니다. EVM의 장점 중 하나는 원자적으로 하나의 계약 내에서 다른 계약을 호출할 수 있다는 것입니다. 따라서 구매를 수행하기 위해 하나의 계약을 배포하고 일련의 조건을 설정하면 됩니다. 예를 들어 GitHub에서 오픈 소스 계약 코드 friendrekt를 사용하면 최고 구매 가격과 수량을 설정할 수 있습니다.
문제 3에 대해서는 가장 간단한 방법은 공식 API를 이용하여 쿼리하여 해당 주소의 사용자 트위터 정보를 얻고, 트위터 팔로워 수 등의 정보를 조회하여 필터링한 후, 구매 여부와 구매 수량 및 최고 가격을 판단하는 것입니다. 이렇게 하면 로봇의 작업 흐름은 아래 그림과 같이 변합니다.
기술 폭발
이 과정을 통해 정보 요청과 스마트 계약 호출이 추가되었습니다. 로봇은 계약 이벤트를 감지한 후 간단한 논리 판단을 통해 새로운 계정이 활성화되었음을 확인하고, API를 이용해 관련 정보를 조회하여 필터링한 후, 배포된 스마트 계약을 이용해 구매를 완료합니다. 그러나 이러한 로봇은 여전히 결함이 있습니다:
피싱 트위터 계정을 판단할 수 없으며, 일부 계정은 팔로워 수가 많지만 모두 좀비 팔로워일 수 있으며, 아무런 가치가 없습니다. 구매에는 큰 위험이 따릅니다.
팔로워 수는 트위터 사용자의 가치를 판단하는 데 불편합니다. 일부 KOL은 팔로워 수가 적지만 운영을 잘 하여 쉽게 필터링될 수 있습니다.
API에는 일정한 지연이 있으며, 이 인터페이스는 사용자가 활성화된 후 일정 시간(60초) 내에만 조회할 수 있어 많은 주소를 놓치기 쉽고 지연이 큽니다.
이러한 문제를 하나씩 해결해 보겠습니다. 먼저 문제 3에 대해, 0xleo의 영감을 받아 나는 friend.tech에서 1만 달러를 잃었다 - 0xleo에서 발견한 다른 인터페이스를 통해 사용자가 등록된 후 주소 정보를 조회할 수 있습니다. 따라서 이 인터페이스를 지속적으로 모니터링하여 최신 ID를 찾고 등록자의 정보를 얻을 수 있습니다. 가치 있는 등록자로 판단되면 주소를 캐시에 저장합니다(재시작 지속성을 보장하기 위해 데이터베이스도 필요합니다). 체인 이벤트를 감시하고 캐시에 적중하면 구매를 진행합니다.
다음으로 문제 1과 2에 대해, 사용자가 가치가 있는지 판단하는 방법이 필요합니다. 이를 위해서는 일부 제3자 트위터 KOL 평가 사이트의 도움이 필요합니다. 필자는 탐색 과정에서 Twiiterscan을 사용하여 조회하였으며, 등록 정보를 미리 얻을 수 있기 때문에 활성화 전에 Twiiterscan을 조회하는 데 소요되는 시간은 큰 영향을 미치지 않습니다. 또한 수동으로 화이트리스트와 구매 가격을 설정하여 구매 구성을 완료할 수 있습니다.
마지막으로 우리가 구현한 봇의 기본 흐름은 다음과 같습니다. 추가적인 "로봇"이 API의 최신 정보를 가져오고 판단 후 데이터베이스와 캐시에 저장하며, 구매 전담 로봇은 이벤트를 수신한 후 캐시 정보를 조회하여 적중 시 구매를 진행합니다. 이 캐시에는 화이트리스트 정보도 저장할 수 있으며, 가치 있는 KOL을 선택한 후 가격과 수량을 설정하여 구매합니다.
필자가 이 봇을 구현한 시점이 늦어 수익이 그리 객관적이지 않았습니다. 9월 말부터 구현 및 최적화를 시작하여 10월 3일경 최고 1.2E의 수익을 달성하였으나, 그 며칠 동안 적시에 매도하지 않아 이익이 회수되었고, 일련의 수수료 지출로 인해 수익도 손실도 없는 상황이 되었습니다. 이러한 구조의 로봇은 등록자가 구매한 후 첫 번째 블록에서 구매를 실행할 수 있으며, base에서 메모리 풀 스캔과 같은 복잡한 작업이 없기 때문에 대부분 동일한 블록에서 구매하는 것은 미친 듯한 방식입니다: 구매를 감지한 후 계속해서 구매를 실행하여 구매가 완료될 때까지 진행합니다. 예를 들어 이 과정에서 다른 로봇을 볼 수 있습니다:
https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c
그 전략은 간단합니다. 위에서 설명한 구조를 기반으로 데이터베이스를 저장하지 않고 직접 구매를 시작하여 구매가 완료될 때까지 진행합니다. 이 정도로 최적화되면 자금량의 게임이 됩니다. 가스를 충분히 소모할 수 있다면 이러한 방식으로 진행할 수 있으며, 전략이 올바른 경우 수익도 매우 클 수 있습니다.
결론
서문에서 우리는 매매 및 수수료 사기 작업에 대해 언급했습니다. 여기서 간단히 소개하겠습니다:
매매는 일종의 추적 로봇으로, 수익성이 좋은 주소를 추적하여 그 작업을 따라갈 수 있습니다. 원리는 간단합니다. 감시하는 주소를 필터링하여 목표 주소일 경우 작업을 따릅니다.
수수료 사기는 두 가지로 나뉩니다(필자가 개발 과정에서 관찰한 바). 하나는 팔로워 수가 많은 트위터 계정을 이용하여 직접 구매하고 빠르게 판매하여 수익을 얻는 것입니다. 다른 하나는 새로운 주소를 계속 생성하고 송금한 후 구매 작업을 수행하고 빠르게 판매하는 것입니다. 두 번째 방법은 가장 간단한 로직의 봇을 겨냥하며, 초기에는 좋은 수익을 올릴 수 있습니다.
이로써 우리는 체인상의 로봇 원리에 대한 소개를 마쳤습니다. 구체적인 구현은 코드와 관련이 있으므로 더 이상 설명하지 않겠습니다. 알고 싶은 분들은 friendrekt의 구현을 참고하실 수 있습니다.
위험 경고 위험 경고
