Phân tích sơ lược nguyên lý cơ bản của robot trên chuỗi thông qua ví dụ FriendTech
Tuyển chọn TechFlowTuyển chọn TechFlow
Phân tích sơ lược nguyên lý cơ bản của robot trên chuỗi thông qua ví dụ FriendTech
Làm thế nào các robot trên chuỗi thực hiện thao tác đặt hàng mới, mua bán, gian lận phí giao dịch bằng cách bỏ qua giao diện người dùng để hoàn tất việc mua và bán?
Chuyên sâu báo cáo Web3Lời nói đầu
Friend.Tech là một nền tảng xã hội dựa trên hợp đồng thông minh, người dùng cần kết nối tài khoản Twitter của mình để đăng ký và "phát hành" key cá nhân. Những người sở hữu key có thể tham gia vào phòng chat tương tự nhóm để trao đổi với chủ sở hữu key. Đây vẫn là một nền tảng xã hội tập trung, chỉ khác ở chỗ sử dụng hợp đồng thông minh trên blockchain để thực hiện logic mua bán key, còn các chức năng chính được xây dựng dưới dạng ứng dụng nhắn tin (IM) trên giao diện web. Trong quá trình mua bán key, 10% giá trị giao dịch sẽ được chia làm hai phần: một phần dành cho đội phát triển Friend.Tech, phần còn lại cho chủ sở hữu phòng chat tương ứng.
Vì vậy, trong bối cảnh key có thể được mua bán mà không cần qua giao diện người dùng (frontend), các bot trên chuỗi (on-chain bot) tự nhiên xuất hiện để thực hiện các thao tác như săn hàng mới (đánh new), mua bán và lừa đảo phí giao dịch. Vậy chúng hoạt động như thế nào?
Nói về bot săn hàng mới
Trong giai đoạn đầu hoạt động của Friend.Tech, bot săn hàng mới có thể thu được lợi nhuận đáng kể vì lúc đó các bot sniper trên chuỗi chưa phát triển đến mức độ cao; chỉ cần phân tích sơ bộ thông tin là có thể mua vào với kỳ vọng sinh lời lớn. Bây giờ, hãy bắt đầu từ logic đơn giản nhất, từng bước xây dựng nên một bot phức tạp hơn.
Tuy nhiên trước tiên cần giới thiệu khái niệm Sự kiện (Event) – đây là sự trừu tượng hóa các bản ghi nhật ký (log) trong EVM theo ngôn ngữ lập trình Solidity. Chúng thường đi kèm câu lệnh emit để kích hoạt sự kiện. Trên blockchain explorer, điều này tương ứng với phần logs của giao dịch. Ví dụ, một giao dịch mua key như bên dưới đã kích hoạt sự kiện Trade, chứa đựng nhiều thông tin chi tiết:
Event là một phần quan trọng trong DApp, giúp theo dõi các thay đổi trạng thái của hợp đồng. Chẳng hạn, chính Friend.Tech cũng lắng nghe các sự kiện này để cập nhật dữ liệu trong cơ sở dữ liệu, ví dụ như giá hiển thị trên giao diện, số lượng holding,...
Lý luận đơn giản nhất
Bot săn hàng mới đơn giản nhất sẽ hoạt động như sau: theo dõi các sự kiện từ hợp đồng Friend.Tech, khi phát hiện một giao dịch thỏa mãn các điều kiện dưới đây thì gọi hàm mua key trên hợp đồng:
-
Sự kiện là giao dịch mua (
isBuy= true) -
Người giao dịch và chủ sở hữu là cùng một địa chỉ (
trader==subject) -
Giao dịch tạo phòng mới (
supply= 1)
Hình ảnh dưới đây mô tả quy trình này:
Hợp đồng? Tính nguyên tử!
Bot kiểu này tồn tại một số vấn đề:
-
Không đảm bảo chắc chắn mua được key mới, cũng không tính chính xác được lượng ETH cần thiết để mua;
-
Không thể đặt mức giá tối đa, ví dụ nếu giá hoặc số lượng key vượt ngưỡng nào đó thì dừng mua;
-
Dễ bị tấn công ngược: kẻ khác có thể dùng địa chỉ mới để mua trước nhằm đánh lừa bot này, qua đó chiếm đoạt phí giao dịch hoặc thoát hàng có lời.
Đầu tiên giải quyết vấn đề 1 và 2. Một ưu điểm của EVM là có thể thực hiện các cuộc gọi giữa các hợp đồng một cách nguyên tử (atomic). Do đó, ta chỉ cần triển khai một hợp đồng riêng để thực hiện việc mua key, đồng thời thiết lập các điều kiện cụ thể. Ví dụ như mã nguồn mở trên GitHub: friendrekt, cho phép thiết lập giá mua tối đa và số lượng mua.
Với vấn đề 3, cách đơn giản nhất là dùng API chính thức để truy vấn thông tin Twitter của địa chỉ tương ứng, rồi kiểm tra số lượng người theo dõi (follower) để sàng lọc. Sau khi lọc xong mới quyết định có mua hay không, mua bao nhiêu và giá trần là bao nhiêu. Quy trình bot lúc này như hình sau:
Bùng nổ công nghệ
Như thấy, quy trình này bổ sung thêm yêu cầu lấy thông tin và gọi hợp đồng thông minh. Bot sau khi lắng nghe sự kiện, đưa ra quyết định sơ bộ rằng đây là tài khoản mới kích hoạt, sau đó dùng API để lấy thông tin và lọc, cuối cùng dùng hợp đồng đã triển khai để thực hiện mua. Tuy nhiên loại bot này vẫn còn nhược điểm:
-
Không nhận diện được tài khoản Twitter giả mạo: một số tài khoản có lượng follower cao nhưng toàn là fan rác (zombie), không có giá trị thực tế, dẫn đến rủi ro cao khi mua phải;
-
Số lượng follower không phản ánh đúng giá trị thực sự: một số KOL tuy ít follower nhưng biết vận hành, dễ bị bỏ sót trong quá trình lọc;
-
API có độ trễ nhất định: API này chỉ có thể truy vấn được sau khoảng 60 giây kể từ khi kích hoạt tài khoản, khiến khả năng bỏ lỡ nhiều địa chỉ và chậm trễ cao.
Cũng lần lượt giải quyết từng vấn đề. Với vấn đề 3, nhờ cảm hứng từ 0xleo qua bài viết Tôi đã mất 10 nghìn đô la trên friend.tech như thế nào - 0xleo
Phát hiện ra một API khác cho phép truy vấn thông tin địa chỉ ngay sau khi người dùng đăng ký. Như vậy có thể liên tục tăng id để theo dõi API này, tìm kiếm id mới nhất và lấy thông tin người đăng ký. Nếu xác định là người có giá trị, lưu địa chỉ vào bộ nhớ đệm (cache); để đảm bảo dữ liệu tồn tại sau khi khởi động lại, cần dùng thêm cơ sở dữ liệu. Khi bot lắng nghe sự kiện trên chuỗi và khớp với cache thì tiến hành mua.
Tiếp đến là vấn đề 1 và 2: làm sao đánh giá một người dùng có giá trị? Cần sự hỗ trợ từ các trang thứ ba chuyên xếp hạng KOL Twitter. Trong quá trình khám phá, tác giả đã dùng Twitterscan để tra cứu. Vì có thể lấy trước thông tin đăng ký nên thời gian truy vấn Twitterscan trước khi kích hoạt không ảnh hưởng nhiều. Ngoài ra, có thể thiết lập danh sách trắng (whitelist) thủ công cùng mức giá mua để cấu hình.
Cuối cùng, quy trình cơ bản của bot do chúng tôi xây dựng như sau: một "bot phụ" riêng biệt kéo dữ liệu mới từ API, sau khi phân tích sẽ lưu vào CSDL và cache; bot chuyên mua sẽ khi nhận được sự kiện thì tra cứu cache, nếu trùng khớp thì thực hiện mua. Cache này cũng có thể lưu thông tin whitelist, chọn các KOL tiềm năng rồi thiết lập giá và số lượng mua phù hợp.
Do tác giả triển khai bot này khá muộn nên lợi nhuận không cao. Cuối tháng 9 bắt đầu xây dựng và tối ưu, đến khoảng ngày 3 tháng 10 đạt đỉnh lợi nhuận 1,2E. Nhưng vì không bán kịp vài ngày sau đó nên lợi nhuận bị rút về, cộng thêm các khoản phí giao dịch, tổng thể coi như hòa vốn. Kiến trúc bot này có thể mua vào ngay khối đầu tiên sau khi người đăng ký thực hiện giao dịch. Vì trên mạng Base không có thao tác quét mempool kiểu "ảo diệu", phần lớn các bot cùng mua trong cùng khối đều chơi kiểu liều lĩnh: sau khi phát hiện giao dịch mua, cứ liên tục thực hiện mua cho đến khi thành công. Ví dụ như một bot khác mà tôi quan sát thấy:
https://basescan.org/address/0x88e6aeb90795f586542b4062cb9f853a5582966c
Chiến lược của nó rất đơn giản: trên nền tảng kiến trúc đã nêu, không lưu vào CSDL mà mua luôn lập tức, lặp đi lặp lại cho đến khi mua được. Khi tối ưu đến mức này thì trở thành trò chơi so vốn: ai đốt được nhiều gas hơn thì có lợi thế, và nếu chiến lược đúng thì lợi nhuận cũng rất hấp dẫn.
Kết luận
Ở phần Lời nói đầu, chúng ta cũng đề cập đến các thao tác mua bán và lừa phí. Dưới đây là phần giới thiệu ngắn:
-
Loại mua bán là bot copy lệnh: theo dõi các địa chỉ đang sinh lời tốt rồi sao chép hành động của họ. Nguyên lý rất đơn giản: lọc địa chỉ được theo dõi, nếu là địa chỉ mục tiêu thì thực hiện thao tác tương tự;
-
Lừa phí có hai kiểu (theo quan sát của tác giả khi phát triển): một là dùng tài khoản Twitter có nhiều follower để mua vào rồi bán ngay lập tức nhằm thu hoạch lợi nhuận. Kiểu thứ hai là liên tục tạo địa chỉ mới, chuyển tiền rồi mua và bán rất nhanh. Kiểu thứ hai chủ yếu nhắm vào các bot logic đơn giản, và trong giai đoạn đầu hẳn đã thu được lợi nhuận tốt.
Tới đây, chúng ta đã hoàn tất phần giới thiệu nguyên lý hoạt động của các bot trên chuỗi. Việc triển khai cụ thể liên quan đến mã nguồn sẽ không trình bày sâu. Bạn đọc muốn tìm hiểu thêm có thể tham khảo cách hiện thực tại friendrekt.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@3PDAO
