Чому більшість блокчейнів важко реалізувати «рідну» підтримку умовних ордерів? Багато хто при першому знайомстві з автоматизацією на ланцюгу виникає інтуїтивне питання: оскільки смарт-контракти настільки потужні, чому не можна, як на біржах, встановити «продати BTC, якщо ціна вище 100000, і купити, якщо нижче 50000», а система сама слідкує за ціною та автоматично виконує? Відповідь у тому, що: основний спосіб роботи популярних блокчейнів більше нагадує «пасивний розрахунковий механізм», а не «постійно працюючу фонову службу». По-перше, смарт-контракти зазвичай не «прокидаються самі». Вони виконуються лише тоді, коли хтось ініціює транзакцію, що викликає їхню роботу, і не постійно слухають ринок або перевіряють умови за таймером, як серверні програми. Тому, щоб реалізувати функцію умовних ордерів на ланцюгу, потрібно, щоб хтось у момент виконання умови надіслав транзакцію для її активації. По-друге, на ланцюгу немає природної ціни «BTC/USD». Блокчейн за замовчуванням знає лише дані з ланцюга: баланс акаунтів, стан контрактів, ціни пулів DEX тощо. Ваша ціна 100000 доларів — це ціна з поза ланцюга, яку потрібно подати через оракул. Чим частіше оновлюється ціна, тим вищі витрати; повільне оновлення може пропустити важливі рівні; неправильний вибір джерела ціни може збільшити ризик маніпуляцій або відхилення від реального ринку. По-третє, навіть якщо умова виконується і транзакція ініційована, це не означає, що вона буде зафіксована за «вашою» ціною. Виконання на ланцюгу потребує Gas, очікування включення у блок, і ціна може вже змінитися; до того ж, можливо, доведеться мати справу з MEV (вилучення додаткової цінності через переривання або фільтрування транзакцій), що може погіршити ціну виконання. При низькій ліквідності можливий проскальзинг, а у найгіршому випадку — повний провал транзакції (наприклад, якщо ви встановили суворий захист за мінімальною ціною). Тому традиційні рішення на ланцюгу зазвичай складаються з «трьох компонентів»: оракул для ціни, смарт-контракт для збереження правил і прав, а також мережі keeper/ботів, що слідкують за ринком і у разі виконання умов надсилають транзакції. Це працює, але за своєю суттю залежить від «зовнішніх виконавців», і тому не є «рідним» досвідом. А ідея Rialo — зробити цю можливість базовим компонентом ланцюга: так звані Reactive Transactions (реактивні транзакції). Це — поєднання «умови спрацювання + транзакція для виконання», яке автоматично запускається системою, коли умова виконується, мінімізуючи залежність від зовнішніх keeper-ів. Приклади, які вони пропагують, включають цінові тригери, автоматичне інвестування, захист від ліквідації тощо — імітуючи досвід «одним натисканням встановити умовний ордер» на біржі. Однак «рідність» також має межі: ланцюг не може самостійно знати ціну BTC у доларах без надійного джерела даних (оракулу або каналу даних). Що ще важливіше, чим сильніша автоматизація, тим вищі вимоги до безпеки та управління ризиками: як обрати джерело ціни, як балансувати між частотою оновлень і витратами, як запобігти маніпуляціям, як обмежити проскальзинг і повторні спроби, а також як зменшити вплив MEV — все це визначає, наскільки стабільно ця система працюватиме у реальних умовах. Блокчейни не уявляють собою неможливості створення умовних ордерів, але «контракти пасивно виконуються + ціна залежить від зовнішніх даних + виконання залежить від вартості та ігрових механізмів у ланцюгу», що ускладнює досягнення такої гладкості та «рідного» досвіду, як на біржах. @RialoHQ Хоче зробити «автоматичне виконання за подіями» базовою можливістю протоколу — це крок у еволюції досвіду; але для цього потрібно знайти баланс між надійністю даних і ризиками виконання у ланцюгу, щоб справді перетворити «автоматизацію» з демо у довгострокову інфраструктуру. Якщо хочете спробувати, можете перейти за посиланням, де доступна реактивна візуалізація! @RialoHQ@rialo_zw@itachee_x@dj673285379 @LinYue93820@JanCamenisch