У розробці часто виникають ситуації, коли точність типів та небажання допускати неясності в коді стають першорядними завданнями. У таких випадках розробникам доводиться шукати інструменти, що надають максимальну ясність та строгість у визначенні даних. Один із таких інструментів — ключове слово as const. У цій статті ми розглянемо, як as constможе підвищити рівень суворості та передбачуваності, а також розглянемо практичні приклади його використання для створення незмінних та точних типів.
Коли ви використовуєте as const змінну або значення, TypeScript уточнює тип цієї змінної до її точного значення або комбінації літеральних типів. Це часто використовується для створення незмінних значень та гарантування того, що TypeScript розглядатиме значення як конкретні літерали, а не розширюватиме типи.
Приклад :
Уявіть, що нам потрібно написати функцію для відкриття вхідних дверей до будинку. Пишемо функцію, яка приймає параметром ключ, та проводить з ним будь-які операції.
const wallet = {
key: "open_door_pls"
}
const openDoor = (key: "open_door_pls") => {
//...
}Але коли ми намагаємося використовувати функцію openDoor з ключем з нашого гаманця, чомусь відбувається таке:
const wallet = {
key: "open_door_pls"
}
const openDoor = (key: "open_door_pls") => {
//...
}
openDoor(wallet.key) // ERROR: Argument of type 'string' is not assignable to parameter of type '"open_door_pls"'Чому ж ми потрапили до такої ситуації?
Вся справа в тому, що wallet.key у нас ніяк не прив’язаний до значення "open_door_pls”, і по суті є просто елементом з типом string, значення якого можна легко змінити на інше:
const wallet = {
key: "open_door_pls"
}
wallet.key = "cucumber" // код отрабатывает без ошибокЩоб уникнути такої поведінки, і зробити всі елементи wallet повноцінними, незмінними ( readonly) значеннями, ми можемо скористатися конструкцією as const:
const wallet = {
key: "open_door_pls"
} as const
wallet.key = "cucumber" // ERROR: Cannot assign to 'key' because it is a read-only property.Елементи wallet прив’язалися до своїх значень і тепер мають прапор readonly.
Що зрештою вирішило нашу проблему з параметром функції openDoor:
const wallet = {
key: "open_door_pls"
} as const;
const openDoor = (key: "open_door_pls") => {
//...
};
openDoor(wallet.key) // код отрабатывает без ошибокПроблема Object.freeze() полягає в тому, що після заморожування об’єкта readonly присвоюється лише елементам на верхньому рівні вкладеності.
const car = Object.freeze({
name: "Porshe Cayenne",
equipment:{
engine: "MDC.AB"
}
});
car.equipment.engine = "F8CV";При використанні as constкомпілятора на будь-якому рівні вкладеності вкаже, що програміст намагається змінити константу.
const car = {
name: "Porshe Cayenne",
equipment:{
engine: "MDC.AB"
}
} as const;
car.equipment.engine = "F8CV"; // ERROR: Cannot assign to 'engine' because it is a read-only property.as constчудово підходить як альтернатива enum.
Про мінуси enum можна докладно почитати у цій статті.
Приклад переходу коду enumз as const:
Код, з використанням enum:
enum Wallet {
KEY = "open_door_pls"
};
const openDoor = (key: "open_door_pls") => {
//...
};
openDoor(Wallet.KEY)Код, переписаний на as const:
const wallet = {
key: "open_door_pls"
} as const;
const openDoor = (key: "open_door_pls") =>{
//...
};
openDoor(wallet.key);Ще одна дійсно крута особливість as const полягає в тому, що використання as const дозволяє бути дуже гнучким у поводженні з ключовим об’єктом:
const friendsDict = {
Alfred: "101 Pine Road, Toronto, ON M5A 1A1, Canada",
Liam: "777 Sycamore Lane, Tokyo, 100-0001, Japan",
Mia: "666 Willow Street, Paris, 75001, France",
} as const;
type FriendName = keyof typeof friendsDict; // "Alfred" | "Liam" | "Mia"
type FriendAddress = (typeof friendsDict)[keyof typeof friendsDict];
//"101 Pine Road, Toronto, ON M5A 1A1, Canada" | "777 Sycamore Lane, Tokyo, 100-0001, Japan" | "666 Willow Street, Paris, 75001, France"Ми розглянули конструкцію as const у TypeScript та її роль у створенні більш строгих та передбачуваних типів даних. Сподіваюся, що ця стаття допомогла вам краще зрозуміти, як використання as const може підвищити рівень безпеки та ясності вашого коду.
Таким чином, впровадження as const у ваш код може бути ключем до полегшення його підтримки у майбутньому та зменшення ймовірності помилок. Користуйтеся цим інструментом з розумом, і ваш код стане чистішим, надійнішим та легко підтримуваним!
Попит на функції пошуку зростає, і багато розробників намагаються впровадити їх у свої програми. Однак створення таких додатків з нуля – складне та трудомістке завдання. На щастя, існує безліч бібліотек з відкритим вихідним кодом, які дозволяють звільнити розробників від цього тягаря.
У цьому посібнику читач знайде перелік найкращих пошукових пакетів для JavaScript. У статті буде проведено огляд та порівняння пошукових пакетів з урахуванням швидкості, простоти використання, типу пропонованого пошуку, бази даних та інших характеристик. Крім того, читачі зрозуміють, що таке функціональність пошуку та навіщо вона потрібна.
Один з ключових способів покращити дизайн сайту, щоб допомогти користувачам знайти потрібну інформацію, – це зробити програму доступною для пошуку за допомогою функції пошуку. Користувачі можуть швидко знаходити контент, задаючи пошук за певними фразами на сайті або у додатку, не вникаючи та не вивчаючи всю структуру. Нижче наведено причини, з яких це доцільно:
Існує три різні типи пошуку:
Функція пошукової системи, яка відображає ключові фрази та інші пропозиції в режимі реального часу. Її також називають передиктивним пошуком чи автоповідомленням. Пропозиції ґрунтуються на ключовому слові, яке користувач вводить у поле пошуку.
Пошукова система пропонує кілька прогнозів на основі введеного запиту та зіставляє його з даними у пошуковому індексі. Наприклад, якщо ви введете слово “електроніка” на веб-сторінці, присвяченій електроніці, пошукова система запропонує “електроніку” на цій сторінці.
Це функція пошукової системи, що дозволяє ефективно знаходити дані, коли користувач розуміє потрібну інформацію лише частково. Система шукає текст у великих текстових даних, сховище яких перебуває у електронному вигляді. У відповідь система видає результати, які містять деякі або всі слова із запиту, а не точні збіги.
Наприклад, якщо в полі пошуку ввести слово “пшениця”, результати будуть містити не тільки слово “пшениця”, але й елементи, пов’язані з ним, наприклад “хліб” та “паста”.
Це функція пошукової системи для пошуку рядків, що майже збігаються із заданим рядком. Її також називають нечітким пошуком. Нечіткий пошук повертає результати, що базуються на приблизному збігу пошукового запиту. Крім того, він діє як коректор орфографії та робить пошук гнучким. Він може виконувати вставку, видалення та заміну запитів.
Наприклад, при пошуку “strng” буде запропоновано “string”, а при пошуку “husttle” – “hustle”.
Для пошуку інформації на сайті користувачам потрібна вкладка пошуку, яка забезпечує доступ до функцій пошуку. Пошукова функціональність JavaScript дозволяє користувачам сайту знаходити вміст за певними фразами без необхідності розумітися на структурі сайту.
Але реалізація пошукової функціональності з нуля може зайняти багато часу та роботи. Веб-розробка стала простішою, оскільки розробникам не потрібно щоразу вводити складний код, щоб додати функцію пошуку. Деякі компанії пропонують безкоштовний доступ до своїх пошукових програм.
Пошукові програми дозволяють заощадити час та ресурси, забезпечуючи кращий контроль для підприємства.
Нижче наведено пошукові бібліотеки JavaScript для створення продуктивного та миттєвого пошуку. У цьому розділі ми розглянемо пошукові пакети JavaScript та порівняємо бібліотеки за їхніми можливостями. Без зайвих слів, почнемо.
Fuse.js – це бібліотека, побудована на JavaScript, яка використовується для додавання полегшеного пошуку на стороні клієнта у браузері користувача. Функції пошуку корисні на веб-сайтах та програмах, щоб користувачі могли ефективно знаходити те, що їм потрібно. Fuse.js надає можливості нечіткого пошуку для програм та веб-сайтів.
Fuse.js можна використовувати і на бекенді, оскільки він не має залежностей від DOM. З іншого боку, Fuse.js може бути повільним під час роботи з величезними масивами даних. Визначаючи, який обсяг даних надто великий для Fuse.js, майте на увазі, що вам доведеться завантажувати весь набір даних на стороні клієнта, оскільки Fuse.js необхідний доступ до всього набору даних. Fuse.js не дуже добре працює з великими наборами даних.
Як застосувати Fuse.js
Щоб використовувати Fuse.js, вам не потрібно створювати окремий бекенд лише для пошуку. При створенні цієї бібліотеки основними міркуваннями були простота та продуктивність.
Fuse.js – це швидка та проста у використанні бібліотека, і реалізація функції пошуку на JavaScript стала легкою. При реалізації пошукової функціональності Fuse.js потребує конфігурацій, які дозволяють вносити зміни та створювати потужні рішення.
Щоб встановити Fuse.js , вам потрібно спочатку ініціалізувати проект Node.js. Потім додайте його у свій проект за допомогою npm:
$ npm install --save fuse.js
Якщо ви шукаєте потужний, легкий пошуковий пакет Javascript з функцією нечіткого пошуку, fuse.js– найкращий варіант.
Apache Solr – це пошукова система з відкритим вихідним кодом, яка використовується для створення пошукових програм. Solr побудований на базі пошукової бібліотеки Apache Lucene . Він готовий до роботи на підприємствах, має високу масштабованість і швидкість. Solr дозволяє створювати складні та високопродуктивні додатки.
Apache Solr збирає структуровані, напівструктуровані та неструктуровані дані з різних джерел у сховищі, індексує їх, а потім робить їх доступними для швидкого пошуку. Бібліотека може працювати з великими масивами даних. Вона підтримує розраховану на багато користувачів архітектуру, що дозволяє масштабувати, розподіляти і підтримувати індекси для великих додатків.
Балансування навантаження на запити, автоматизація завдань, централізоване налаштування, розподілене миттєве індексування, готова до масштабування інфраструктура – ось лише деякі з можливостей Solr.
Як застосувати Apache Solr
Apache Solr дає змогу розширити можливості користувачів. Це стабільна, надійна та стійка до відмови пошукова платформа. Розробники бекенда можуть скористатися такими функціями, як об’єднання, кластеризація, можливість імпорту документів у різних форматах та багато інших.
Solr – це платформа повнотекстового пошуку з REST-подібним API. Розробники можуть легко передавати документи через JSON, XML і HTTP. Apache Solr простий у використанні. Його легко встановити та налаштувати. Він орієнтований працювати з текстом, оптимізований для пошуку, а результати пошуку сортуються по релевантності.
Щоб встановити та розпочати роботу з apache solr. Перейдіть на сайт Solr, щоб отримати інструкції зі встановлення .
Lunr.js – це пакет повнотекстового пошуку для JavaScript. Він дозволяє здійснювати всебічний пошук набору даних. Він невеликий, потужний і, що найголовніше, простий у використанні.
Повнотекстовий пошук – це просунута техніка пошуку у базі даних. Ця техніка зазвичай використовується для швидкого пошуку документів або записів за ключовим словом. Вона також дозволяє ранжувати документи щодо релевантності за допомогою системи оцінок.
Як застосувати Lunr.js
Lunr.js працює на стороні клієнта за допомогою веб-застосунків, створених на JavaScript. Він здійснює пошук даних у індексі, створеному за клієнта. Це дозволяє уникнути складних зворотних мережевих викликів між клієнтом та сервером.
Lunr.js – це більш компактна альтернативна бібліотека Apache Solr. Вона має повнотекстову підтримку 14 мов та пропонує нечітке зіставлення термінів. Lunr.js – одна з найкращих пошукових бібліотек для створення додатків на JavaScript. Реалізувати функціональність повнотекстового пошуку шляхом жорсткого кодування дуже складно, особливо у браузері. На щастя, lunr.jsце потужний і простий у використанні інструмент для додавання пошукової функціональності.
Lunr.js – гарний вибір для миттєвого пошуку. Це пов’язано з тим, що він підтримує потужну систему ранжирування та систему плагінів для обробки ключових слів під час індексації та запиту.
Щоб розпочати роботу з lunr.js , спочатку ініціалізуйте проект Node.js. Потім установіть пакет lunr.jsза допомогою npm:
$ npm install lunr
ElasticLunr.js – це легкий пакет повнотекстового пошуку із вбудованим JavaScript для пошуку у браузері та офлайн. Він був створений на основі Lunr.js, але є більш гнучким. Він пропонує додаткові можливості налаштування та швидшу обробку запитів.
Як застосувати ElasticLunr.js
Пошуковий пакет не вимагає розгортання та пропонує функції автономного пошуку. Він легко працює з програмами, створеними за допомогою гібридних фреймворків JavaScript та Cordova. Швидкість – важлива характеристика, elasticlunr.jsдуже швидка в порівнянні з тим lunr.js, що полегшує пошук.
Щоб розпочати роботу з ElasticLunr.js, перейдіть на цей сайт та отримайте інструкції з встановлення.
InstantSearch.js – це бібліотека пошуку з відкритим кодом для Vanilla JavaScript. Вона дозволяє швидко створити пошуковий інтерфейс, використовуючи пошуковий API Algolia у вашому зовнішньому додатку. Пошуковий пакет створює продуктивні та миттєві пошукові можливості. Algolia – це платформа пошуку як послуги, яка дозволяє вам легко впровадити пошук у реальному часі у вашу програму за допомогою настроюваних, попередньо створених віджетів та інструментів для створення блоків.
Як застосувати InstantSearch.js
InstantSearch прагне максимально спростити розробку відмінних пошукових програм, пропонуючи повноцінне пошукове середовище. InstantSearch пропонує зовнішні віджети, які ви можете зібрати в унікальний пошуковий досвід, щоб задовольнити значну частину цієї величезної мети. Також використовуйте InstantSearch, якщо вам потрібно налаштувати компоненти на власний розсуд.
Щоб почати роботу з instantsearch.js , вам необхідно мати встановлений Node.js та yarnабо npm. Вам знадобляться базові знання JavaScript та обліковий запис в Algolia.
$ npm install instantsearch.js algoliasearch
FlexSearch – це бібліотека повнотекстового та незалежного пошуку на JavaScript для веб-браузерів та Node.js. Це одна з найшвидших пошукових бібліотек для розробників JavaScript завдяки алгоритму скорингу, що називається контекстним пошуком .
Як застосувати FlexSearch
Якщо говорити про швидкість, то FlexSearch перевершує всі інші пошукові бібліотеки. Крім того, вона надає гнучкі можливості пошуку, такі як частковий збіг, фонетичні перетворення та пошук по кількох полях. FlexSearch пропонує безліч варіантів налаштування для підвищення ефективності використання пам’яті та швидкості роботи.
Щоб почати роботу з flexsearch, встановіть бібліотеку пошуку за допомогою npm:
$ npm install flexsearch
List.js – це проста у використанні, потужна та надшвидка бібліотека пошуку для Vanilla JavaScript. Це ідеальна бібліотека для додавання пошуку, сортування, фільтрів та гнучкості до таблиць, списків та HTML-елементів. List.js створена так, щоб бути невидимою та працювати з існуючим HTML.
Як застосувати List.js
List.js простий і непомітний, немає залежностей. Він малий, дуже швидкий, легко застосовується до існуючих HTML-елементів та обробляє тисячі елементів. Бібліотека пошуку працює зі списками, таблицями та іншими HTML-елементами, наприклад, <table>, <ul>, <div>і т.д.
Щоб розпочати роботу з list.js , установіть бібліотеку пошуку за допомогою npm:
$ npm install list.js
JS Search – це потужна бібліотека пошуку на стороні клієнта для об’єктів JavaScript та JSON. Вона є полегшеною реалізацією Lunr.js і має широкі можливості налаштування для підвищення продуктивності.
Як застосувати JS Search
JS Search – це швидкий та простий у використанні пошуковий пакет. Щоб почати роботу з js-search , ви можете встановити його за допомогою npm:
$ npm install js-search
MiniSearch – це крихітна, легка, повнотекстова та потужна бібліотека пошуку для JavaScript. Вона призначена для роботи як у Node.js, так і у веб-браузері.
Як застосувати MiniSearch
MiniSearch має функції повнотекстового пошуку, серед яких (нечіткий пошук, пошук за префіксами, ранжування тощо). Бібліотека пошуку також може працювати в автономному режимі та швидко обробляти запити без затримок мережі.
MiniSearch має ефективний індекс пам’яті, дає точний збіг, має механізм автопідбору пошукових запитів та не має зовнішніх залежностей.
Щоб розпочати роботу з minisearch , встановіть його за допомогою npm:
$ npm install --save minisearch
У статті було розглянуто найкращі пошукові пакети на JavaScript, які має знати кожен розробник. Створити пошукову функціональність з нуля не так просто. Використання будь-якого з пакетів пошуку заощадить вам значну кількість часу та роботи. Це керівництво допомогло вам дізнатися про деякі поширені пакети пошуку в JavaScript та їх можливості. Бібліотеки пошуку покращать роботу сайту або програми, оскільки користувачі зможуть легко отримати потрібну їм інформацію.
Регенеративні фінанси (Regenerative finance, ReFi) – концепція та напрямок децентралізованих фінансів (DeFi), в рамках якого створюються комплексні економічні моделі. Останні, крім матеріальної винагороди, припускають сприятливий вплив на довкілля та вирішення суспільних проблем.
Головна мета ReFi полягає в підтримці зростання регенеративної економіки, наголошуючи на екологічному аспекті, соціальному благополуччі та ресурсній стійкості, також сприяючи великомасштабному співробітництву з таких глобальних питань, як зміна клімату та втрата біорізноманіття.
Основні принципи та концепція регенеративних фінансів запропонована у 2015 році Джоном Фуллертоном із Capital Institute.
ReFi має багато спільного з економікою замкнутого циклу, оскільки проекти цього сегменту також фокусуються на відновленні ресурсів та чистої енергії.
Традиційні економічні системи часто критикують за нерівномірний розподіл ресурсів та пріоритизацію короткострокового прибутку над довгостроковою стійкістю.
У свою чергу, ReFi властиві:
Для реалізації поставленої мети ReFi-проекти можуть використовувати залучений капітал, у тому числі за допомогою токенсейлів, а також принципи ДАО. Відповідні платформи зазвичай ґрунтуються на смарт-контрактах, що ріднить сегмент зі сферою DeFi.
ReFi також перетинається з рухом децентралізованої науки (DeSci), який використовує Ethereum та інші екосистеми для фінансування, створення, зберігання та розповсюдження наукових знань.
Один із головних напрямів ReFi — токенізація вуглецевих кредитів , покликана сприяти скороченню шкідливих викидів в атмосферу.
Добровільний вуглецевий ринок (Voluntary carbon market, VCM) — це механізм фінансування ініціатив, які мають перевірений позитивний вплив на викиди CO₂. Після перевірки ці проекти отримують активи, іменовані вуглецевими кредитами, які можуть продавати окремим особам та організаціям, бажаючим підтримати діяльність у сфері клімату.
Перехід VCM на новий цифровий вуглецевий ринок (Digital carbon market, DCM) покликаний відкрити доступ широкого кола користувачів, усунути посередників, сприяти зростанню ліквідності та підвищення швидкості операцій.
Значними елементами ландшафту DCM є проекти Verra, Gold Standard, Toucan Protocol, C3, Moss.Earth, Klima Infinity, Senken та Nori. Вони сприяють інвестуванню у вуглецеві кредити та сприяють організації ініціатив щодо збереження клімату.
Відомий проект ReFi-екосистеми – Celo. Він позиціонується як «мобільно-орієнтований» та «вуглецево-негативний» блокчейн. Ініціатива “Ультразелені гроші” заснована на механізмі спалювання токенів, який відправляє 20% комісій за транзакції в мережі до фонду компенсації викидів вуглецю, що робить токен CELO дефляційним.
Регенеративні фінанси також покликані допомогти зберегти історичні записи та артефакти культурної спадщини , використовуючи технологію блокчейн та NFT. Зокрема, на цьому напрямі сфокусовано компанію Monuverse.
До ReFi також можна віднести проекти, що спеціалізуються на соціально відповідальному кредитуванні . За допомогою подібних платформ позичальники можуть отримати доступ до фінансування освітніх та інших ініціатив, що відповідають «регенеративним принципам».
Web3 також уможливлює випуск і торгівлю децентралізованими «зеленими облігаціями» . Останні дають можливість широкому колу користувачів брати участь у фінансуванні екологічних ініціатив, де блокчейн та смарт-контракти роблять платежі прозорими та автоматизують нарахування відсотків на вкладені кошти.
Як і будь-якому іншому сегменту криптоіндустрії, ReFi властиві ризики та підводні камені.
Наприклад, під питанням може бути фінансова стійкість проектів сегмента децентралізованих фінансів. Критики концепції стверджують, що орієнтовані на довгострокову перспективу вкладення з фокусом на екологію та соціальний ефект поступаються за рентабельністю інвестиціям у традиційні проекти.
Наступний аспект — складність та трудомісткість оцінки соціальних та екологічних наслідків фінансових рішень. ReFi-проекти можуть пом’якшити проблему шляхом впровадження універсальних стандартів використання технологій, а також за допомогою блокчейну та інших передових технологій для підвищення прозорості моніторингу процесів.
Важливо враховувати і потенційні регуляторні перешкоди , які можуть виникнути через прогалини в нормативно-правовій базі. Шляхом вирішення проблеми може стати конструктивний діалог з владою, традиційними фінансовими установами та бізнес-структурами, а також просвітницька робота для популяризації ReFi.
Немаловажна й проблема масштабування — ReFi-проекти можуть надавати обмежений вплив на глобальному рівні через труднощі із залученням коштів та логістичних труднощів. Змінити ситуацію може розвиток технологій, створення глобальних мереж та спільних підприємств, а також партнерства із спільнотами, що поділяють принципи регенеративних фінансів.
Деякі ReFi-проекти ставлять високі цілі, пропонуючи розпливчасті формулювання про те, як ці цілі будуть досягнуті. Найчастіше подібні компанії прагнуть отримати зиск на хайпі навколо екологічних та інших соціальних ініціатив.
Інвесторам слід проявляти особливу пильність, якщо:
Перш ніж вкладати кошти у нову ReFi-ініціативу, учасникам ринку слід уважно вивчити бекграунд команди проекту.
Якщо платформа пропонує користувачеві розкрити сид-фразу – це шахрайство, націлене на спустошення гаманця. Слід взаємодіяти лише з перевіреними проектами, наприклад, із тими, хто залучив інвестиції від відомих венчурних фірм.
Використовуючи блокчейн та смарт-контракти, DeFi та ReFi багато в чому схожі між собою. Однак, будучи тісно взаємопов’язаними напрямками, вони служать дещо різним цілям.
У контексті криптоіндустрії в цілому DeFi можна як більш широку категорію, де ReFi – її складова частина. Цей напрямок розвивається паралельно з іншими безпосередньо не пов’язаними з фінансами новими підсегментами на кшталтDeSci,DePINіDeSoc.
За всієї значущості концепції регенеративних фінансів ще рано говорити про практичну користь відповідних проектів. Головна причина в низькому інтересі широкої аудиторії — поки що мало хто готовий брати участь у подібних ініціативах.
Наприклад, добовий обсяг торгів токеном Moss Carbon Credit (MCO2) складає $39 400, за даними CoinGecko на 23 грудня. Актив низьколіквідний і не представлений на популярних платформах, таких як Binance або OKX.
Модель ReFi ще слабо поширена у реальних проектних розробках. Представленими на ринку рішеннями поки що користується лише невелика кількість по-справжньому зацікавлених учасників.
Прихильники регенеративних фінансів намагаються вирішити важливе, певною мірою утопічне завдання. Однак розвиток сегменту та популяризація концепції з часом можуть зробити ReFi набагато популярнішим, змінивши ставлення громадськості до криптовалютів загалом.
Вилучення прибутку не є головною метою при взаємодії із платформами регенеративних фінансів. Рух ліквідності розуміється як ланка в ланцюзі та засіб для комплексного вирішення екологічних, суспільних та наукових завдань.
Значна частина громадськості, як і раніше, сприймає використання криптоактивів у відриві від «реального світу». У багатьох блокчейн-індустрія асоціюється тільки зі спекуляціями монетами, що не мають цінності, для швидкого збагачення. З можливою популяризацією ідеї ReFi у сфері децентралізованих фінансів і криптовалют в цілому з’являється шанс на оновлення іміджу.
Real World Assets (RWA) — термін, що означає ринок активів «реального світу», випущених у формі токенів на блокчейні. У RWA включають нерухомість, право власності, предмети мистецтва, коштовності та метали, традиційні фінансові інструменти на ринках капіталу.
Концепція має на увазі токенізацію вже існуючих активів для перенесення цінності в децентралізовані фінансові програми, скорочення витрат або підвищення ефективності управління коштами на традиційних ринках.
Ринок Real World Assets ще остаточно не сформований, але вже встиг розділитись на категорії проектів, що належать до загального тренду токенізованих активів реального світу.
Централізовані стейблкоіни. Популярні монети, такі як USDT від Tether або USDC від Circle, за своєю природою є RWA. Компанії-емітенти таких токенів блокують фіатні валюти, державні або комерційні цінні папери на своїх рахунках як забезпечення. Потім вони випускають стейблкоіни, що є своєрідною токенізацією.
Приватне кредитування Одним із учасників цього сектору єДАНО MakerDAO, емітент стейблкоіна DAI. У середині 2022 року організація відкрила кредитну лінію на $100 млн у токенах для американського Huntingdon Valley Bank. Як забезпечення банк заклав позабалансові кредити. Свої розробки на цьому ринку запропонував і емітент стейблкоіна USDC — він запустив протокол з відкритим кодом Perimeter, який є основою для створення токенізованих ринків кредитування.
Державні облігації. Сектор представлений компаніями, що випускають стейблкоіни, у забезпеченні яких лежать казначейські облігації будь-якої країни. Наприклад, Ondo Finance випускає стабільну монету USDY під заставу короткострокових казначейських облігацій США. Сюди слід віднести проект Mountain Protocol, що запустив стейблкоїн USDM на базі блокчейна Ethereum. Він також забезпечений казначейськими облігаціями, які приносять пасивний дохід у розмірі 5% річних.
Токенізовані цінних паперів. Новатором у цьому секторі стала біржа криптовалют Bitfinex. У вересні 2021 року розпочала роботу її дочірня платформа Bitfinex Securities, орієнтована на RWA-ринок. У жовтні 2023 року вона випустила першу токенізовану облігацію з трирічним періодом погашення та ставкою 10%.
Інтерес до сектору виявили й інституційні інвестори. Найбільший банк Великобританії HSBC планує у 2024 році запропонувати клієнтам сервіс для зберігання токенізованих цінних паперів. У жовтні 2023 року конгломерат JPMorgan запустив Tokenized Collateral Network (TCN), сервіс конвертації акцій у цифрові активи. У розробці брали участь фінансові гіганти BlackRock та Barclays.
Нерухомість. У січні 2023 року конгломерат Société Générale зайняв у MakerDAO $7 млн у DAI. Як актив для забезпечення кредиту виступили регульовані законодавством Франції іпотечні облігації на $40 млн.
Сертифікати вуглецевих кредитів . 2022 року набрав популярність ринок «зелених» сертифікатів. Наприклад, проект KlimaDAO, який інвестував мільярдер Марк Кьюбан, пропонував криптокористувачам вуглецеві кредити. Теоретично зростання цін такі сертифікати мало спонукати компанії, забруднюючі довкілля, скоротити викиди. Однак це дуже нерозвинений ринок, повний шахрайства.
Твори мистецтва та предмети колекціонування. Цей сегмент представлений за допомогою ринку NFT. У 2021 році відразу кілька компаній та інвесторів перенесли цінність у блокчейн шляхом токенізації картин відомих художників. Так, швейцарський криптобанк Sygnum випустив серію NFT на основі роботи Пабло Пікассо «Дівчинка у береті», розділивши її на 4000 токенів. А засновник Tron Джастін Сан купив картини Пікассо та Енді Уорхола за $22 млн із наміром токенізувати їх через JUST NFT Fund.
Дорогоцінні метали. Учасниками цієї галузі ринку RWA є емітенти стейблкоїнів, які мають у забезпеченні дорогоцінні метали у фізичній формі. Як приклад можна навести токени від компанії Paxos або XAUT від Tether.
Головний аргумент, який дозволяє говорити про перспективи токенізованих активів «реального світу» — вартість глобального ринку перевищує сотні трильйонів доларів США незадіяної ліквідності. Станом на 2020 рік лише ринок нерухомості оцінили більш як на $326 трлн. Передбачається, що, принаймні, мала його частина перейде на блокчейн.
На кінець листопада 2023 року, згідно з даними сервісу Rwa.xyz, обсяг заблокованих коштів у протоколах RWA становив $4,5 млрд при $571 млн виданих кредитів. З листопада 2021 року зростання суми кредитів склало понад 6700% з $8,5 млн.
Однак, судячи з прогнозів інституційних компаній, основне зростання ще не відбулося, і ринок має величезні перспективи. Наприклад, аналітики Coinbase вважають, що “бум токенізації” відбудеться в наступні один-два роки. А оцінка зростання всього ринку RWA становить від $5 трлн до $16 трлн до 2030 року, згідно з прогнозами Citigroup та Boston Consulting відповідно.
20 листопада 2023 року команда TypeScript випустила TS 5.3.
Одна з найважливіших змін у TypeScript 5.3 не була згадана у примітках до релізу.
// Це було б помилкою у 5.2, але дозволено у 5.3!
const array = ["a", "b", "c"] as const satisfies string[];
const returnWhatIPassIn = <const T extends any[]>(t: T) => {
return t;
};
// результат - any[] в TS 5.2, но ['a', 'b', 'c'] в 5.3
const result = returnWhatIPassIn(["a", "b", "c"]);Робота з масивами, доступними для читання, TS може іноді доставляти деякі незручності.
Допустимо, ви хочете оголосити масив роутів як const.
Це дозволить вам повторно використовувати роути, оголошені типу.
const arrayOfRoutes = [
{ path: "/home", component: Home },
{ path: "/about", component: About },
] as const;
// type Route = "/home" | "/about"
type Route = (typeof arrayOfRoutes)[number]["path"];Але якщо ви хочете переконатися, що масив arrayOfRoutes відповідає певному типу?
Для цього можна використовувати satisfies.
const arrayOfRoutes = [
{ path: "/home", component: Home },
{ path: "/about", component: About },
] as const satisfies {
path: string;
component: React.FC;
}[];
// Тип є "readonly" і не може бути // присвоєний типу, що змінюєтьсяЄдина проблема полягає в тому, що TypeScript 5.2 це призведе до помилки! Але чому?
Це тому, що arrayOfRoutes доступний лише для читання, а ви не можете використовувати масив, доступний для зміни, для масиву, доступного для читання.
Тому виправлення полягало в тому, щоб зробити тип, який ми покриваємо, масивом readonly:
const arrayOfRoutes = [
{ path: "/home", component: Home },
{ path: "/about", component: About },
] as const satisfies readonly {
path: string;
component: React.FC;
}[];
// Помилок більше немає!Тепер, коли ми використовуємо масив, доступний лише читання, TypeScript щасливий.
Те саме відбувається і при використанні параметрів типу const, але ще більш згубно.
У цьому випадку const виводить річ, передану в T, ніби вона була const.
Але якщо ви спробуєте обмежити його масивом, це не спрацює!
const returnWhatIPassIn = <const T extends any[]>(t: T) => {
return t;
};
// Результат: any[] в TS 5.2!
const result = returnWhatIPassIn(["a", "b", "c"]);До версії TS 5.3 виправлення полягало в додаванні readonly до параметра type:
const returnWhatIPassIn = <const T extends readonly any[]>(
t: T
) => {
return t;
};
// Результат: ['a', 'b', 'c']!
const result = returnWhatIPassIn(["a", "b", "c"]);Але це виправлення було важко знайти і вимагало глибоких знань про те, як працюють параметри типу const.
Починаючи з версії 5.3 TypeScript пом’якшив правила роботи з масивами, доступними для читання.
У цих двох ситуаціях TypeScript діє ефективніше.
Ключове слово satisfies тепер дозволяє передавати масиви з readonly:
// Це було б помилкою у 5.2, але дозволено у 5.3!
// const array: ["a", "b", "c"]
const array = ["a", "b", "c"] as const satisfies string[];Параметри типу Const тепер визначають переданий тип замість того, щоб за промовчанням використовувати свої обмеження:
const returnWhatIPassIn = <const T extends any[]>(t: T) => {
return t;
};
// Результат: any[] в TS 5.2, но ['a', 'b', 'c'] в 5.3
// const result: ["a", "b", "c"]
const result = returnWhatIPassIn(["a", "b", "c"]);Зверніть увагу на невелику різницю! Якби ви вказали readonlystring[] замість string[], то отримали б назад масив readonly.
Тому вам все одно потрібно вказати readonly, якщо ви хочете отримати назад масив, доступний для читання.
// Це було б помилкою у 5.2, але дозволено у 5.3!
// const array: readonly ["a", "b", "c"]
const array = [
"a",
"b",
"c",
] as const satisfies readonly string[];
const returnWhatIPassIn = <const T extends readonly any[]>(
t: T
) => {
return t;
};
// результат - any[] в TS 5.2, но ['a', 'b', 'c'] в 5.3
// const result: readonly ["a", "b", "c"]
const result = returnWhatIPassIn(["a", "b", "c"]);Але це значне поліпшення, що робить роботу з параметрами типу const, так і з задовольнячими набагато простіше.
TypeScript – ви повинні кричати про такі речі!
Переклад статті “The TypeScript 5.3 Feature They Didn’t Tell You About“
Рішення третього рівня (Layer 3 чи L3) — загальна назва протоколів, розгорнутих з урахуванням вже існуючих L2-решень. Як і у випадку з L2, третій рівень мереж призначений для масштабування та розширення функціональних можливостей основного блокчейну.
Концепція подібних розробок існує вже понад вісім років. Одним із перших ідею про багаторівневе масштабування блокчейнів сформулював у 2015 році засновник Ethereum Віталік Бутерін. Найбільшу популярність цієї концепції принесли напрацювання StarWare, опубліковані наприкінці 2021 року.
На листопад 2023 року проектування рішень третього рівня зосереджено навколо блокчейну Ethereum.
<h2Для чого це потрібно?
L2-рішення призначені масштабування базового блокчейну. Вони усувають проблему низької пропускної спроможності та високих комісій за транзакції. У свою чергу, L3 має дві фундаментальні цінності, які важко реалізувати на другому рівні:
L3 можна представити як рівень запуску окремих унікальних додатків чи мереж, пов’язаних стандартами L2.
Ринок L3-рішень лише почав формуватися. Основну розробку ведуть команди L2-рішень на блокчейні Ethereum, включаючи Optimism, Arbitrum та zkSync. Кожна з них має власне бачення.
Hyperchains . Компанія Matter Labs, що стоїть за zkSync, розраховує створити мережу взаємопов’язаних блокчейнів, які використовують доказ із нульовим розголошенням. Щоб реалізувати цей план команда випустила технологічний стек для розробників ZK Stack. Архітектура дозволить розгортати «гіперцепи» як паралельні рішення L2, так і протоколи третього рівня.
У рамках Hyperchains вже запустили тест L3-рішення Pathfinder. На початку 2024 року очікується реліз гібридної криптобіржі GRVT, що поєднує в собі інтерфейс централізованої біржі типу Robinhood та функції некастодіального зберігання активів, як у Uniswap.
Superchain. Це концепт масштабування Ethereum від команди L2-рішення Optimism на основі технологічного стека OP Stack. Поки що ідея команди полягає у створенні паралельних рішень, що діють незалежно один від одного, з подальшою можливістю розробки L3.
У рамках Superchain вже працює накопичувальний клієнт OP Stack від однієї із найбільших венчурних криптокомпаній a16z. У серпні 2023 року американська біржа Coinbase на основі архітектури Optimism запустила мережу другого рівня Base.
Інтерес у перенесенні своїх мереж у Superchain виник і в інших L2. Так, перейти на архітектуру OP Stack запропонувала спільноті компанія cLabs – розробник L2-мережі Celo.
Orbit. Команда Offchain Labs, відповідальна за L2-рішення Arbitrum, у червні 2023 року випустила свій набір інструментів для розробників, націлений на реалізацію L3-рішень на базі Arbitrum. Orbit націлена на створення саме L3-додатків із високим ступенем індивідуальних налаштувань.
Екосистема L3 на Arbitrum вже представлена десятком проектів, що включають Web3 – фінансові ігри, dappsта NFT -проекти.
L3-рішеннями можуть називатися будь-які мережі та інфраструктурні проекти, побудовані поверх існуючих L1 та/або L2, але не конкурують з ними. Вони виконуватимуть складні обчислення, роботу зі сторонніми даними, пропонуватимуть нові сценарії використання. Наприклад, L3-рішення може принести в блокчейн дані з реального світу, щоб використовувати їх на першому та другому рівнях у DeFi.
До L3 відносять децентралізовану мережу оракулів Chainlink, що відповідає за поставку правильних офчейн-даних для виконання смарт-контрактів на всіх рівнях блокчейну.
До рішень третього рівня також відносять інфраструктурні проекти на кшталт Orbs, що працює як надбудова до різних мереж із чудовим консенсусом та архітектурою. Orbs працює з Ethereum, TON, Polygon, BNB Chain, Avalanche та Fantom, забезпечуючи розробникам та компаніям додатковий функціонал та сумісність для їх додатків.
У цій же області знаходяться рішення від Polkadot, відомі як парачейни. Саме цей функціонал створює додатковий шар для взаємодії Web3-додатків, спрощуючи обмін даними та активами.
Content-Security-Policy(CSP) – це HTTP заголовок, який покращує безпеку веб-застосунків за рахунок заборони небезпечних дій, таких як завантаження та відправка даних на довільні домени, використання eval, inline-скриптів і т.д. У цій статті буде зроблено фокус на директиві style-srcта її використання разом із CSS-in-JS бібліотекою emotion.
Content-Security-Policyзаголовок повинен бути виставлений у відповіді разом із завантажуваною веб-сторінкою (наприклад, index.html). Це виглядає так:
Content-Security-Policy: style-src 'self'
style-src– це директива, яка відповідає за те, які стилі можна завантажувати та застосовувати на сторінці. Можливі значення:
'none'– усі стилі заборонені'self'– Дозволені файли стилів, які завантажуються з того ж домену, що і основний документ (сторінка)<url>, наприклад https://example.com– дозволені файли стилів з цього домену, також допускаються wildcard (*) на місці під-домену та порту'<hash-algorithm>-<base64-value>', наприклад 'sha256-ozBpjL6dxO8fsS4u6fwG1dFDACYvpNxYeBA6tzR+FY8='– дозволені файли стилів та inline -стилі (тег <style>), у яких хеш збігається із зазначеним значенням'nonce-<value>', наприклад 'nonce-abc'– дозволяються inline -стилі, у яких атрибут nonceзбігається із зазначеним (у прикладі – abc)'unsafe-hashes'– дозволяє inline -стилі, зазначені в атрибуті styleрядком, наприклад <div style="color:red;"></div>, при цьому хеш значення атрибута повинен збігатися з хешом, вказаним у'<hash-algorithm>-<base64-value>''unsafe-inline'– дозволяє всі inline -стилі, створені через тег<style>'unsafe-eval'– дозволяє додати/змінити CSS declarations, які призводять до парсингу рядка, наприклад, за допомогою CSSStyleDeclaration.cssTextДиректива може приймати кілька значень через пропуск. У цьому випадку це сприймається як логічне “або” – при задоволенні хоча б одного значення стилі дозволяються.
emotionдодає styleелементи динамічно і в останніх версіях не може виймати всі стилі в окремий файл під час складання програми. Це означає, що для того, щоб можна було використовувати emotionразом з style-src, є такі опції:
'unsafe-inline'– Найпростіша опція з усіх. Не вимагає будь-яких налаштувань з боку emotion. При цьому ми знижуємо безпеку нашої програми, тому це рішення можна використовувати лише як тимчасове.'nonce-<value>'– можна дозволити inline-стилі, створені emotion. Для цього потрібно задати nonceпри створенні cache.При використанні @emotion/reactабо @emotion/styledце можна зробити так:
import { CacheProvider } from "@emotion/react";
import createCache from "@emotion/cache";
export function App() {
const cache = createCache({
key: 'my-app',
nonce: getNonceValue(),
});
return (
<CacheProvider cache={cache}>
{/* children */}
</CacheProvider>
);
}Якщо використовується @emotion/cssбезпосередньо, то потрібно створити свій екземпляр emotion:
import createEmotion from '@emotion/css/create-instance';
export const {
flush,
hydrate,
cx,
merge,
getRegisteredStyles,
injectGlobal,
keyframes,
css,
sheet,
cache
} = createEmotion({
key: 'my-app',
nonce: getNonceValue(),
});При використанні createEmotionпотрібно змінити всі місця, де раніше імпортувався @emotion/cssна цей модуль:
// import { css } from "@emotion/css";
import { css } from "./emotion";Т.к. значення CSP заголовка недоступне коду, що виконується на клієнті, значення потрібно додатково передати іншим чином. Один із варіантів – це створення inline-скрипту зі значенням, яке виставляється на бекенді:
<script id="nonce" type="application/json">
"abc"
</script>На фронтенді це можна використовувати таким чином:
function getNonceValue() {
const nonceElement = document.getElementById("nonce");
return JSON.parse(nonceElement.textContent);
}Зверніть увагу на type="application/json"– таким чином браузер не вважає це виконуваним кодом, і особливе значення script-srcне потрібно.
Ліквідність — фундаментальна категорія як традиційного, так криптовалютного ринків. Вона характеризує можливість продати активи швидко та безперешкодно за ціною, близькою до ринкової.
Ліквідність, як правило, забезпечується безліччю покупців та продавців. Якщо фінансовий інструмент малопопулярний і, відповідно, неліквідний, може знадобитися деякий час для його конвертації у готівку.
Крім того, операція може бути пов’язана зі значним прослизанням. Останнє означає різницю в ціні, за яку учасник ринку хотів продати актив у порівнянні з тією, за якою він був фактично реалізований.
Ключовим елементом сегмента децентралізованих фінансів (DeFi) є пули ліквідності. Останні є сукупністю криптоактивів, заблокованих в смарт-контракті.
Пули ліквідності використовуються у широкому спектрі платформ «фінансового Lego», охоплюючи сектори криптокредитування, DEX, децентралізованого страхування, синтетичних активів тощо.
Важливим компонентом є автоматичний маркетмейкер (AMM). Цей програмний алгоритм задіяний у більшості DeFi-протоколів. Механізм служить контролю ліквідності і ціноутворення криптоактивів на децентралізованих платформах, забезпечуючи автоматизовану торгівлю.
Створити пул ліквідності може будь-який учасник DeFi-екосистеми. Для цього інвестору потрібно заблокувати в смарт-контракті кілька криптоактивів рівними за вартістю частинами, встановивши початкові ціни.
Користувачі AMM-платформ, що надають гроші в пули, називаються провайдерами ліквідності (liquidity providers, LP). Ціни LP токенів, що розміщуються, визначаються в залежності від співвідношення попиту та пропозиції (ринкова вартість монети зростає, якщо багато користувачів її купує, і навпаки), а також за допомогою задіяної в алгоритмі конкретної платформи формули.
За криптоактиви, що надаються, провайдери ліквідності отримують частку від торгових комісій. Розмір цієї винагороди залежить від обсягу внесеної ліквідності, що виражається у спеціальних криптоактивах – LP-токенах. Останні можна задіяти на різних платформах фінансового Lego.
Процес пасивного заробітку на криптоактивах шляхом їх розміщення на DeFi-платформах у співтоваристві називають «прибутковим фермерством» («фармінгом доходу», yield farming) або «майнінгом ліквідності».
Розміщеними у пулі криптовалютами може торгувати будь-який учасник ринку. При цьому не потрібні контрагенти (покупці та продавці, як на традиційних платформах) і книга ордерів — у роботу вступає механізм АММ, який передбачає торгівлю безпосередньо з пулом.
Більшість DEX працює відповідно до моделі Constant Product Market Maker (CPMM). Остання вперше з’явилася на платформі Bancor, але справжньої популярності набула з появою біржі Uniswap.
Відповідно до CPMM добуток вартості двох активів у пулі є постійною величиною:
Токен A * Токен B = K
де:
Токен А: вартість Токена А
Токен В: вартість Токену В
К: константа
Співвідношення між токенами у пулі диктує ціни. Наприклад, якщо хтось купує ETH у парі DAI/ETH, пропозиція ETH у пулі зменшується, а DAI – збільшується. Як результат, ціна ефіру зростає, стейблкоїну зменшується. Вплив такої операції на ринкову вартість активів залежить від обсягу правочину щодо величини пулу. Якщо TVL останнього значний, а операція всього на кілька доларів вплив на ціни активів буде невеликим.
При необхідності LP може будь-якої миті вийти з пулу ліквідності, просто погасивши свої LP-токени. Учаснику ринку на гаманець відразу ж повернеться спочатку внесена кількість монет та відсотковий дохід, нарахований завдяки торговій активності.
Більшість DEX базується на AMM-механізмі відповідно до моделі CPMM. Частка цього бірж у сегменті наближається до 90%.
Відповідний показник “гібридних” DEX – ~9,5%, децентралізованих бірж на основі книги ордерів – ~1%.
Uniswap – беззмінний лідер сегменту по TVL та обсягу торгів. На момент написання матеріалу (20.10.2023) біржа підтримує 8 мереж, включаючи Ethereum, Arbitrum, Optimism, Polygon, Base, BNB Chain, Avalanche та Celo.
У липні Uniswap Labs представила UniswapX — протокол агрегування ліквідності децентралізованих бірж з відкритим вихідним кодом. У тому ж місяці розробники окреслили терміни запуску Uniswap v4 – протягом чотирьох місяців після хардфорку Dencun у блокчейні Ethereum.
Значною популярністю серед учасників криптовалютного ринку користується платформа Curve. Вона розроблена для ефективної торгівлі між стейблкоінами та іншими токенами однакової вартості з мінімальним ковзанням та комісією.
Вагома частка ринку також припадає на Balancer. Ця платформа дозволяє створювати пули для трьох та більше токенів.
Будучи ключовим елементом DeFi-екосистеми, що постійно розвивається, пули ліквідності пропонують можливість будь-яким учасникам ринку отримувати пасивний дохід від криптоактивів.
Найважливіша їхня властивість — permissionless. Це означає, що будь-який користувач може створити пул ліквідності та, відповідно, новий ринок. При цьому немає жодних процесів розгляду чи схвалення — все відбувається децентралізовано, без посередників.
Учасником DeFi-екосистеми може стати як великий, так і дрібний інвестор – вхідний бар’єр практично відсутній. Така відкритість сприяє розвитку більш інклюзивної та справедливої фінансової системи, де кожен може привнести ліквідність ринку і допомогти активізувати торговельну активність.
DEX ґрунтуються на смарт-контрактах із відкритим вихідним кодом, припускаючи прозорість та доступність для зовнішнього аудиту.
DeFi-екосистема все ще далека від стадії зрілості. Поряд із незаперечними перевагами, ключовим елементам децентралізованих фінансів властива низка недоліків:
Крім іншого, учасники DeFi-сегменту схильні до ризику непостійних збитків (Impermanent loss, IL). Йдеться про ситуацію, коли ціни активів у пулі ліквідності суттєво відрізняються від тих, що були при депонуванні коштів у пули. За сильних рухів ринку іноді вигідніше просто тримати монети в гаманці, ніж блокувати їх у смарт-контрактах для отримання пасивного доходу.
Наведемо спрощений приклад такої ситуації.
Припустимо, користувач створив на новій DEX пул WBTC/USDT, депонувавши для цього 1 WBTC та 20 000 USDT відповідно.
Ціна біткоїну різко пішла вгору, за короткий час цифрове золото подорожчало до 25 000 USDT. Дізнавшись про нову біржу, арбітражери побачили можливість заробити на курсовій різниці. Для цього вони почали активно викуповувати «обгорнуті» біткоїни
з пулу, доки ціна не досягла паритету з ширшим ринком.
Тепер у пулі переважає USDT, а запас WBTC практично вичерпано.
Отже: Початковий депозит: 20 000 USDT + 1 WBTC. Зважаючи на те, що кошти вносяться на DEX рівними частинами, загальна вартість активів у пулі еквівалентна 40 000 USDT.
На тлі ралі біткоїну до 25 000 USDT вартість ліквідності в пулі має становити 45 000 USDT. Але оскільки WBTC вичерпано, у пулі міститься 40 000 USDT і 0 BTC. Альтернативні витрати становитимуть 5000 USDT.
Ця різниця і є Impermanent loss. Такі збитки називають «непостійними», тому що вартість активів у пулі все ще може досягти паритету зі значеннями ширшого ринку. Збиток стає «постійним» лише тому випадку, якщо постачальники ліквідності виходять залишають пул у разі виникнення IL.
Існують калькулятори непостійних збитків, наприклад, від платформ dilydefi.org та CoinGecko .
Торгові операції через пули ліквідності також можуть бути пов’язані зі значними прослизаннями. Особливо якщо йдеться про нові, маловідомі і (можливо, поки що) неліквідні монети.
Прослизання означає різницю між очікуваною ціною та фактичною ціною здійснення торгової операції. Причина такого розбіжності у тому, що ринкові вартості активів у пулі не перебувають у сталості, змінюючись від угоди до угоди і щоразу знаходячи новий рівноважний рівень.
Торгові операції в контексті AMM не проводяться миттєво — у проміжку між ініціюванням та підтвердженням транзакції користувача може статися кілька інших досить великих угод. Останні можуть суттєво впливати на ціни, особливо якщо обсяг ліквідності в пулі невеликий.
Ретродроп – ретроактивний аірдроп, що розподіляється у нативному токені проекту. Це один із способів винагороди за використання криптопрограми, його тестування або іншу пов’язану з проектом активність на ранній стадії його розвитку.
Один з перших ретродропів провела децентралізована біржа (DEX) Uniswap у вересні 2020 року, роздавши від 400 UNI кожній блокчейн-адресі, що коли-небудь взаємодіє зі смарт-контрактами платформи.
Токени популярних L2-рішень Optimism та Arbitrum також розподілялися за принципом ретроспективної нагороди, тобто за корисні, на думку проектів, дії в минулому.
Найчастіше критеріями для ретродропа служать дії, результатом яких стали фінансові витрати користувача певний проміжок часу.
Такі критерії називають мультиплікаторами. Розглянемо найпопулярніші їх.
Депозит у мережу чи додаток. Чим більше в обігу активів, краще для всієї екосистеми. Сюди можна віднести корисну ліквідність, що відноситься до взаємодії з окремими додатками. Це блокування активів для стейкінгу, фармінгу, кредитування та в пулах ліквідності.
Мережевий ID, домени. Ідентифікація адрес та надання їм особистісного характеру з допомогою реєстрації доменів чи отримання спеціальних ID.
Голосування в ДАТ. Фундаментально важлива активність, коли користувач зберігає свої токени на балансі, не продаючи їх і голосуючи ними за нововведення в екосистемі, у тому числі пропонуючи свої ідеї розвитку.
Створення та запуск смарт-контрактів. Експерименти та нові розробки в екосистемі завжди вітаються. Заохочення та залучення розробників – одне з найважчих завдань.
Створення мультисиг -адрес. Передбачається, що такими операціями займаються професійні команди, фонди, групи інвесторів. Це цінний вигляд учасників екосистеми.
Обсяг транзакцій у доларовому еквіваленті. Чим більше операцій у доларовому вираженні проходить у мережі, краще для всіх з погляду статистики та інших мережевих метрик.
Кількість транзакцій. Чим вище кількість операцій, тим більше сумарний обсяг сплачених комісій. Це джерело доходів для валідаторів та окремих проектів у мережі.
Час використання мережі або програми. Чим довше і частіше користувач знаходиться в екосистемі, тим цінніший для проекту.
Взаємодія з великою кількістю програм. Проекти цінують дослідників та залучених користувачів. Наприклад, Optimism оцінювала та заохочувала взаємодію з додатками навіть поза своєю мережею.
Донати. Проекти заохочують безоплатні вкладення на ранній стадії розвитку, коли замість венчурних раундів команди звертаються до збору пожертв від небайдужої спільноти.
Дропхантери – мисливці за аірдропами. У контексті ретродропів це користувачі, які намагаються передбачити, які проекти будуть нагороджувати своє активне співтовариство в майбутньому через розподіл нативних токенів.
Ця категорія учасників крипторинка розраховує, що активне використання окремих програм у таких екосистемах, як, наприклад, Base, Linea, zkSync і Starknet буде відповідати потенційним мультиплікаторам для ретродропу.
Щоб зробити прибуток максимальним, користувачі вдаються до створення численних блокчейн-адрес, званих сибіл-аккаунтами – така діяльність називається мультиаккаунтинг. Суть цього підходу полягає в управлінні однією людиною або групою осіб цілою мережею нібито не пов’язаних адрес, які можуть претендувати на аірдроп у майбутньому. Так, у 2023 році невідомий створив 21 877 адрес в Ethereum-мережі другого рівня zkSync.
Команди, які стоять за розподілом аірдропів, вважають практику мультиаккаунтингу шкідливою. У рамках боротьби з сибіл-аккаунтами проекти аналізують мережну активність і відмовляють таким користувачам у нагородах. Наприклад, розробники Optimism виключили близько 17 000 ETH-адрес зі списку ретродропу токена OP.
Великі ретродропи Uniswap, Optimism та Arbitrum показали, що полювання за нагородами стало окремим видом професійної діяльності на крипторинку, націлену на отримання прибутку. Так само, як у трейдингу та інвестиціях, тут є безліч стратегій. У ретрохантінг можна виділити наступні тренди:
Використання спеціалізованого програмного забезпечення. Цей напрямок у звіті Binance названо аірдроп-фармінгом – автоматичним виконанням дій у блокчейн-мережах та окремих децентралізованих додатках для збільшення шансів на отримання аірдропу.
Такі софти діляться на встановлене ПЗ, ресурси з урахуванням Web2 і навіть телеграм-боты. Цей підхід дозволяє створювати десятки, сотні і навіть тисячі адрес, які потенційно підходять під критерії ретродропу. Наприклад, двоє учасників ринку консолідували на двох адресах токени ARB на $3,3 млн, отримані з 1496 гаманців – таку кількість дуже важко створити вручну.
Ручна стратегія аірдроп-фармінг. Цей підхід обмежений ресурсами людини чи групи людей, адже створення сотень адрес вимагатиме колосальних витрат часу. Однак стратегія вважається відносно безпечною, адже виявлення таких облікових записів може бути ускладнене.
Комбінована. Це спосіб диверсифікувати ризики. Хантери ділять свої акаунти на виконання дій за ручною та автоматичною стратегіями одночасно. Це потенційно знижує ризики, але водночас збільшує можливе повернення від вкладень за рахунок кількості акаунтів та економії часу.
На сьогоднішній день будь-яке підприємство, чи це магазин будівельних товарів чи компанія з надання послуг у сфері бізнесу, всі вони прагнуть «викласти» свої товари та послуги в інтернет. Це і зрозуміло – ми живемо у вік бурхливих технологій і доступ в інтернет має більше 65% населення світу (близько 5.3 млрд. осіб), а до 2025 року це число збільшиться до 6.54 млрд. (значно, чи не так?). Так, про що я, їх треба обслуговувати, всім їм потрібно пропонувати послуги, товари і т.д. Як то кажуть: «На смак і колір – товариша немає» і справді скільки людей – стільки думок, а в нашому випадку товарів та послуг. На тлі цього виникає резонне питання: «А як все це відобразити у мене на сайті, щоб користувач не чекав до наступного року завантаження сторінки сайту, коли на той час встигнуть з’явитися ще товари, які потрібно буде підвантажити?». За такої картини світу та найоптимістичніших прогнозів про темпи появи нових речей, ми маємо необережність увійти до якоїсь рекурсії.
З дитинства нас вчили їсти маленькими порціями і ретельно пережовувати, то чому б і в ситуації, що склалася, отримувати всю інформацію не одним скопом, а порційно? Саме таке рішення пропоную розглянути у статті. І якщо вже стосуватися теми їжі (мабуть, не варто писати на голодний шлунок), то варто ковтати їжу, яку ми вже прожували, а не збирати її в роті, інакше колись він порветься (Джокер, до тебе претензій немає). Так і ми видалятимемо елементи з DOM-дерева, які не доступні погляду користувача, щоб не перевантажувати наш сайт.
Технології, які я вибрав, а точніше сказати, які мені вибрав роботодавець для виконання тестового завдання: React, RTK Query. Моя потяг до знань і пізнання, а також бажання писати, змусили мене піти трохи далі, тому нижче зроблю порівняння часу рендерингу при нескінченному скролі з віртуалізацією і якби ми завантажили всі наші дані відразу.
Перейдемо до реалізації. Нашими піддослідними даними будуть пости з https://jsonplaceholder.typicode.com . Створюємо програму за допомогою команди create-react-app, встановлюємо RTK Query (у мене: “@reduxjs/toolkit”: “^1.9.5”). Повертаємо наш кореневий компонент у провайдер і переходимо до налаштування store.
Створюємо api:
export const postApi=createApi({
reducerPath:'post',
baseQuery:fetchBaseQuery({baseUrl:'https://jsonplaceholder.typicode.com'}),
endpoints:(build)=>({
fetchAllPosts: build.query<IPost[],{limit:number,start:number}>({
query:({limit=5, start=0 })=>({
url:'/posts',
params:
{
_limit:limit,
_start:start,
}
})
}),
fetchPostById: build.query<IPost,number>({
query:(id:number=1)=>({
url:`/posts/${id}`,
})
})
})
})
Прокидаємо його в rootReducer і визначаємо функцію setupStore, яка встановить нам store для провайдера:
const rootReducer= combineReducers({
[postApi.reducerPath]:postApi.reducer
})
export const setupStore=()=>{
return configureStore({
reducer:rootReducer,
middleware:(getDefaultMidleware)=> getDefaultMidleware().concat(postApi.middleware)
})
}
Index.tsx
const store=setupStore()
const root = ReactDOM.createRoot(
document.getElementById('root') as HTMLElement
);
root.render(
<Provider store={store}>
<App/>
</Provider>
);
Створюємо наш компонент для одного посту:
interface IPostItemProps{
post:IPost
}
const PostItem:FC<IPostItemProps> = ({post}) => {
const navigate=useNavigate()
return (
<div className='container__postItem'>
<div>№ {post.id}</div>
<div className='postitem__title'>Title: {post.title}</div>
<div className='postitem__body'>
Body: {post.body.length>20?post.body.substring(0,20)+'...':post.body}
</div>
</div>
);
};
Переходимо безпосередньо до логіки відтворення наших компонентів.
Визначимо в контейнері постів два стани: один визначення моменту, коли скролл досяг верхньої частини сторінки, інший – коли нижньої. А також хук, який нам сформував RTK Query, куди ми передаємо наші ліміт (кількість постів) та стартовий індекс (індекс першого посту):
const [isMyFetching,setIsFetchingDown]=useState(false)
const [isMyFetchingUp,setIsMyFetchingUp]=useState(false)
const {data:posts, isLoading} =postApi.useFetchAllPostsQuery({limit:7,start:currentPostStart})
Створимо функцію, яка вираховуватиме досягнення верху чи низу і повертатиме скролл у середнє положення:
const scrollHandler=(e:any):void=>{
if(e.target.documentElement.scrollTop<50)
{
setIsMyFetchingUp(true)
}
if(e.target.documentElement.scrollHeight-e.target.documentElement.scrollTop-window.innerHeight<50)
{
setIsFetchingDown(true)
window.scrollTo(0,(e.target.documentElement.scrollHeight + e.target.documentElement.scrollTop));
}
}
Де
e.target.documentElement.scrollHeight – висота всього скролла;
e.target.documentElement.scrollTop – скільки ми вже прокрутили від верхньої частини;
window.innerHeight – висота видимої частини сторінки.
Потім необхідно при першому рендерингу цього компонента навісити слухачі подій на скролл та прибрати його при розмонтуванні, щоб не накопичувати їх:
useEffect(()=>{
document.addEventListener('scroll',scrollHandler)
return ()=>{
document.removeEventListener('scroll',scrollHandler)
}
},[])
Визначимо хук useEffect, який відпрацьовує при досягненні нижньої частини екрана:
useEffect(()=>{
if(isMyFetching)
{
setCurrentPostStart(prev=>{
return prev<93?prev+1:prev
})
setIsFetchingDown(false)
}
},[isMyFetching])
Варто тут зазначити, що при зміні стартового індексу ми працюємо з попереднім значенням і якщо воно вже менше 93, тобто ми досягли деякого максимуму (JSONPlaceholder нам надає лише 100 постів), то повертаємо поточне значення, інакше збільшуємо індекс на одиницю.
Аналогічно чинимо при досягненні верхньої частини сторінки:
useEffect(()=>{
if(isMyFetchingUp)
{
setCurrentPostStart(prev=>{
return prev>0?prev-1:prev
})
setIsMyFetchingUp(false)
}
},[isMyFetchingUp])
Код усієї компоненти:
const PostContainer: FC = () => {
const [currentPostStart,setCurrentPostStart]=useState(0)
const {data:posts, isLoading} =postApi.useFetchAllPostsQuery({limit:7,start:currentPostStart})
const [isMyFetching,setIsFetchingDown]=useState(false)
const [isMyFetchingUp,setIsMyFetchingUp]=useState(false)
useEffect(()=>{
if(isMyFetching)
{
setCurrentPostStart(prev=>{
return prev<93?prev+1:prev
})
setIsFetchingDown(false)
}
},[isMyFetching])
useEffect(()=>{
if(isMyFetchingUp)
{
setCurrentPostStart(prev=>{
return prev>0?prev-1:prev
})
setIsMyFetchingUp(false)
}
},[isMyFetchingUp])
useEffect(()=>{
document.addEventListener('scroll',scrollHandler)
return ()=>{
document.removeEventListener('scroll',scrollHandler)
}
},[])
const scrollHandler=(e:any):void=>{
if(e.target.documentElement.scrollTop<50)
{
setIsMyFetchingUp(true)
}
if(e.target.documentElement.scrollHeight-e.target.documentElement.scrollTop-window.innerHeight<50)
{
setIsFetchingDown(true)
window.scrollTo(0,(e.target.documentElement.scrollHeight + e.target.documentElement.scrollTop));
}
}
return (
<div>
<div className='post__list'>
{posts?.map(post=><PostItem key={post.id} post={post}/>)}
</div>
{isLoading&&<div>Загрузка данных</div>}
</div>
);
};
Настав час для експериментів.
Розглянемо приклад, коли ми завантажуємо усі 100 постів одним запитом. Загальний час рендеру, який відображається у вкладці Profiler React DevTools, в даному випадку склав 44,1 мс.
Якщо ж завантажувати порціями по 7 постів, час скоротиться до 23,2 мс.
Окрім виграшу за часом до першого відтворення контенту, ми також виграємо за продуктивністю, за рахунок того, що нам не потрібно зберігати в DOM всі елементи, а лише ті, які видно користувачеві на екрані.
Якщо подивитися на нижче розташований малюнок, то можна побачити, що у нас кількість вузлів, що відображають пости, залишається рівним 7.
Також при скролі вгору не відбуваються запити на отримання попередніх постів, тому що RTK Query їх кешує, що дозволяє знову ж таки збільшити продуктивність.
На закінчення статті можна зробити висновок, що запропонована реалізація дозволила виграти в часі першого відтворення контенту – одна з метрик Google PageSpeed Insights, що впливає на рейтинг сайту в інтернеті. Також нескінченний скролл+віртуалізація є гідною альтернативою пагінації та іншим технологіям, які передбачають видачу інформації порціями.
Відкрийте криптовалютну картку Trustee за кілька хвилин! Оплачуйте ваші покупки миттєво з автоматичною конвертацією