Основний принцип ончейн-роботів: Візьмемо для прикладу FriendTech

Передмова

Friend.Tech – це соціальна платформа, заснована на смарт-контрактах, користувачам необхідно підключити власний Twitter для реєстрації, і «видати» власний ключ, користувачі з ключем можуть увійти в кімнату, схожу на груповий чат, щоб поспілкуватися з власником ключа. Це, як і раніше, централізована соціальна платформа, але покладається на смарт-контракти в ланцюжку для реалізації ключової логіки купівлі та продажу, а основною функцією є IM-додаток, заснований на веб-сторінці. А в процесі продажу та купівлі ключів 10% від вартості буде розділено на дві частини, одна частина для Friend.Tech забудовника, а інша – для власника відповідного приміщення. Потім, у випадку, якщо такий ключ може обійти фронтенд, щоб завершити купівлю-продаж, він, природно, створить роботів у ланцюжку, щоб грати в новий, купувати, продавати та обманювати комісію. Отже, як вони реалізуються?

Поговоріть про потрапляння нових роботів

Ураження нових роботів може мати значні переваги на ранній стадії Friend.Tech роботи, тому що на даний момент роботи-снайпери на ланцюжку не еволюціонували до певної міри, і їх можна придбати після простого інформаційного судження і вони можуть мати високі очікування прибутку. Тепер почніть з найпростішої логіки реалізації бота і пройдіть через складну логіку бота.

Звичайно, перед цим нам потрібно ввести **Event**, який є абстракцією подій журналу в EVM під мовою програмування Solidity. Зазвичай він поєднується з оператором emit для запуску події**. Відповідає логам, які є транзакціями в блокчейн-браузері, наприклад, наступна транзакція для покупки ключа, яка ініціює торгову подію, що містить ряд інформації.

! [Основи ончейн-роботів: приклад FriendTech] (https://cdn-img.panewslab.com/panews/images/6yihX4ZR6n.png)

Термін виконання контракту

Події є важливою частиною DApps, за допомогою якої вони можуть прослуховувати зміну стану контракту, наприклад, Friend.Tech також прослуховують контракт, щоб налаштувати ряд даних у базі даних, таких як ціна відображення інтерфейсу, кількість утримання тощо.

Найпростіша ідея

Тоді найпростіша логіка нового робота така: прослухайте контрактні події Friend.Tech, і коли він виявить, що подія, ініційована біржею, відповідає наступним умовам, зателефонуйте контракту Friend.Tech, щоб слідувати за покупкою

* Подія - це покупка (значення isBuy відповідає дійсності)
* Трейдер і власник - це одна і та ж адреса (трейдер == суб'єкт)
* Транзакція - це транзакція, яка створила кімнату (пропозиція дорівнює 1)

На наступному малюнку показана блок-схема процесу

! [Основи ончейн-роботів: приклад FriendTech] (https://cdn-img.panewslab.com/panews/images/cTUYN1J80k.png)

Мінімальний бот

Договір? Атомарность!

З таким роботом є певні проблеми:

1. Немає гарантії, що новий вдасться купити, а по-друге, неможливо дати саме ту суму ETH, яку можна придбати за ключ;
2. Також неможливо встановити граничну ціну, наприклад, скільки ключів або яка ціна досягається на момент виконання угоди;
3. Легко бути снайпером, інші можуть виконувати операції купівлі через нові адреси для залучення таких роботів, щоб досягти мети обману комісії за обробку та продажу прибутку;

Спочатку розглянемо вирішення завдань 1 і 2, однією з переваг EVM є те, що він може атомарно викликати інші контракти в одному контракті, тому вам потрібно лише розгорнути контракт, щоб здійснити покупку, і встановити ряд умов, таких як код контракту з відкритим вихідним кодом на Github [friendrekt] , ви можете встановити максимальну ціну покупки, а також кількість.

Для питання 3 найпростіший спосіб - скористатися офіційним інтерфейсом для запиту, отримати відповідну адресу інформації користувача в Twitter, а потім запросити кількість підписників у Twitter та іншу інформацію для фільтрації, а потім визначити, чи варто купувати, скільки купувати і яка максимальна ціна. У цей момент робочий потік робота стає таким, як показано на малюнку нижче.

! [Основи ончейн-роботів: приклад FriendTech] (https://cdn-img.panewslab.com/panews/images/16OzVP13Ts.png)

Введення контрактів дайгоу

Технологічний вибух

Видно, що цей процес збільшує інформаційні запити та виклики смарт-контрактів, і робот визначає активацію нового облікового запису після прослуховування події контракту, після простого логічного судження, а потім використовує API для запиту відповідної інформації для фільтрації, і, нарешті, використовує розгорнутий смарт-контракт для завершення покупки. Але недоліки у таких роботів все ж є:

1. Не в змозі судити про фішинговий аккаунт в Twitter, деякі облікові записи мають велику кількість шанувальників, але всі вони фанати зомбі, і вони не мають ніякої цінності, а покупка пов'язана з великим ризиком;
2. За кількістю підписників не зручно судити про те, чи цінний користувач Twitter, у деяких фанатів KOL невелика кількість шанувальників, але вони будуть діяти, тому цих людей легко відфільтрувати;
3. Є певна затримка в API, цей інтерфейс можна запитати лише протягом періоду часу (60 секунд) після активації користувача, легко пропустити багато адрес і мати високу затримку;

Знову ж таки, вирішуйте ці проблеми одну за одною. Давайте спочатку розглянемо питання 3, завдяки нагадуванню про 0xleo [як я втратив 10 000 ножів за friend.tech - 0xleo], я виявив, що інший інтерфейс може запитувати інформацію про адресу після реєстрації користувача, потім ви можете постійно та поступово контролювати цей інтерфейс, щоб знайти останній ідентифікатор та отримати інформацію про реєстранта. Якщо реєстрант вважається цінним, він зберігає адресу в кеші (база даних також потрібна для забезпечення стійкості перезапуску) і купує її після прослуховування подій у ланцюжку та потрапляння в кеш.

Друге – питання 1 і 2, як оцінити, чи є користувач цінним? Тоді необхідно використовувати деякі сторонні сайти оцінки Twitter KOL для допомоги, автор використовує Twiiterscan для запиту в процесі дослідження, тому що реєстраційну інформацію можна отримати заздалегідь, тому час, витрачений на запит Twiiterscan перед активацією, не має великого впливу. Крім того, ви можете вручну встановити білий список і ціну покупки, щоб завершити конфігурацію покупки.

Нарешті, основний ланцюжок бота, який ми реалізуємо, полягає в наступному. Додатковий «бот» витягує останню інформацію API і зберігає її в базі даних і кеші після судження, в той час як робот, призначений для покупки, запитує інформацію про кеш після отримання події і робить покупку після попадання в кеш. Цей кеш також може зберігати інформацію з білого списку, вибирати деякі цінні KOL і встановлювати ціну та кількість для покупки.

! [Основи ончейн-роботів: приклад FriendTech] (https://cdn-img.panewslab.com/panews/images/2G0v64Q8N0.png)

Попередній моніторинг та аналіз впливу

Оскільки автор впровадив цього бота відносно пізно, прибуток не дуже об'єктивна. Наприкінці вересня він почав реалізовувати та оптимізувати, і досяг максимального доходу 1,2E приблизно 3 жовтня, і прибуток відновився після того, як у ті дні не зробив своєчасних кроків, і не було прибутку чи збитків після додавання серії комісій за обробку. Боти цієї архітектури можуть досягти покупки в першому блоці після покупки реєстранта, а оскільки на базі немає такої бурхливої операції, як сканування мемпулу, більшість покупок, які слідують за тим же блоком, по суті є божевільною грою: після прослуховування покупки покупка виконується до тих пір, поки покупка не буде завершена, наприклад, інший робот, помічений в процесі: .

Його стратегія проста, виходячи з архітектури, яку ми описали вище, не зберігайте базу даних, а починайте купувати безпосередньо до завершення покупки. Після такої оптимізації це гра в боротьбу за кількість грошей, і в неї можна грати так, якщо ви можете дозволити собі спалити газ, а прибуток особливо значний, коли стратегія правильна.

Висновок

У преамбулі ми також згадували про операцію купівлі-продажу, шахрайство з комісією, ось побіжний вступ:

1. Купівля та продаж - це робот-копіювання, відстеження до кращої прибуткової адреси може стежити за його роботою, принцип також дуже простий, фільтруйте адресу прослуховування, якщо це цільова адреса, щоб стежити за операцією;
2. Існує два типи накрутки гонорарів (як помітив автор під час розробки), один здійснюється за допомогою облікового запису Twitter з великою кількістю підписників, купівлі його безпосередньо та швидкого продажу, щоб завершити збір урожаю. Інший – постійно створювати нові адреси, переказувати гроші, потім виконувати операцію купівлі та швидко продавати. Другий тип в основному націлений на найпростішого логічного бота, який також повинен бути дуже прибутковим на ранній стадії.

Поки що ми завершили впровадження принципу ончейн-робота, конкретна реалізація передбачає код, більше не пояснюється, друзі, які хочуть зрозуміти, також можуть посилатися на нього [friendrekt] здійснення.