При розробці сайту важливо приділити увагу тому, наскільки він буде зручним та функціональним, відображаючись не тільки на екрані комп’ютера, але й на екранах інших пристроїв. У цій статті ми розповімо, що означає «правильна адаптація» сайту, як саме працює мобільна оптимізація і чим загрожує її відсутність.
Отже, що ми взагалі знаємо, що таке оптимізація? Це процес, при якому frontend-розробник та web-дизайнер адаптують верстку сайту під розміри та функціонал інших пристроїв, крім комп’ютера. Робиться це для того, щоб інтерфейс сайту, а також текст та візуальні елементи відображалися та функціонували коректно і на смартфоні, і на планшеті, і на інших пристроях, відмінних від комп’ютера.
Класичний процес розробки виділяє три типи пристроїв, під екрани яких розробляється адаптивна верстка: комп’ютери, смартфони та планшети. Ми ж дотримуємося ідеї, що таких типів має бути чотири та додаємо ще ноутбуки.
У чому особливість кожної з версій сайту?
Велика діагональ екрану має на увазі горизонтальну орієнтацію контенту на веб-сайті. При відвідуванні сайту з комп’ютера ми використовуємо мишу як пристрій введення, і це дає можливість додати в інтерфейс деякі особливості, пов’язані з наведенням курсору: підсвічування кнопок, спливаючі вікна і плашки, зображення, що змінюються, запуск відео і т.д. Також у десктопній версії важливі елементи навігації зазвичай розташовуються в кутку, тому що «дотягтися» до них курсором нескладно.
Екрани ноутбуків мають меншу роздільну здатність, при цьому зберігають горизонтальну орієнтацію та аналогічний комп’ютер пристрій введення. Найголовніша особливість верстки під екран ноутбука – це збереження пропорцій тексту та візуальних елементів, але у меншому розмірі.
Мобільна версія вже значно відрізняється від десктопної через вертикальне розташування екрану. Масштабуючи сторінку під смартфон, важливо враховувати, що користувач взаємодіє з елементами інтерфейсу через сенсорний екран та торкання, а значить, інтерактивні елементи повинні бути не надто дрібними та зручними для натискання пальцем. Проектуючи систему навігації, також важливо враховувати цей момент і розташовувати ці кнопки так, щоб натиснути на них пальцем було зручно.
Планшетна верстка є «гібридом» мобільним і десктопним. Розміри відображення візуального та текстового контенту схожі на комп’ютерну версію, а функціонал – на телефонну. Планшети – це пристрої із сенсорним екраном, тому необхідно вибрати розмір кнопок, враховуючи фактор зручності натискання пальцем. А завдяки достатньому розширенню екрана розмістити елементи навігації можна аналогічно комп’ютерної версії, і жодних незручностей користувачеві це не принесе.
Тепер звернемося до статистики та з’ясуємо, який тип пристроїв домінує як засіб виходу в інтернет. Наприклад, ми взяли деякі сайти, розроблені нами для наших клієнтів. Метрики показують розподіл переглядів сайту з мобільних пристроїв та з комп’ютерів (ноутбуків).
Не важко побачити, що переважна більшість відвідувань припадає саме на смартфони. І таку ситуацію ми постійно спостерігаємо. Смартфон людина користується набагато частіше, ніж комп’ютером. Це швидше, доступніше та зручніше. На даному етапі розвитку мобільних технологій можна навіть стверджувати, що для побутового користування без специфічних завдань смартфон цілком здатний замінити стаціонарний комп’ютер та ноутбук. А ось у зворотний бік такий маневр вже не спрацює, як мінімум тому, що сучасній людині потрібний постійний доступ до інтернету.
Тенденція масового переходу аудиторії на мобільні пристрої це історія, яку ми можемо спостерігати в реальному часі. Для порівняння: ще в 2014 році половина всіх виходів в інтернет вироблялася через настільний комп’ютер. Це був період, коли вже почали масово виходити в інтернет через смартфони, але все ще воліли desktop-версії сайтів. Але минуло зовсім небагато часу, і мобільні пристрої стали досить потужними, щоби дозволити з комфортом проводити час в інтернеті. Після цього «комп’ютерний серфінг» ставав дедалі менш популярним заняттям. Навіть ноутбуки та інші портативні комп’ютери не змогли «подолати» мобільні технології, що розвиваються з кожним роком.
Ще у 2021 році смартфони на порядок переганяли у популярності будь-які інші пристрої для виходу в інтернет. І природно, ця тенденція у 2024 році не зменшила обертів. Маючи таку статистику, питання про те, чи потрібно адаптувати веб-сайт для мобільних пристроїв, навіть не стоїть. У сьогоднішніх реаліях це скоріше необхідність, аніж додаткова послуга.
Звичайно, якщо ваш сайт на сьогоднішній день не адаптований під мобільні пристрої, це не означає, що вся частка аудиторії, що переглядає сайт зі смартфонів, автоматично відвалюється. Сайт відкриється, і користувач, можливо, навіть зможе отримати будь-яку інформацію, але є деякі фактори, які безпосередньо вплинуть на продаж.
Алгоритми пошукової системи, від яких залежить, наскільки високо знаходиться ваш сайт у пошуковій видачі, вже давно працюють за принципом Mobile First. Система підлаштовується під поведінку користувача і «розуміє» що більшість пошукових запитів здійснюються з мобільних пристроїв, тому і просуває в першу чергу ті сайти, які адаптовані під них.
Ще один важливий фактор, який впливає на індексацію сайту. Якщо користувачі залишають сайт у перші 5 секунд після відкриття сторінки, то пошукові системи враховують це та знижують сайт у результатах пошуку. Як показує практика, відкривши сайт, дизайн якого призначений лише для комп’ютерних екранів, людина не може правильно зорієнтуватися на ньому через некоректне відображення потрібної інформації (ціни на послуги, телефон, адресу компанії тощо). Це призводить до банального роздратування та відходу з сайту.
Враховуючи той фактор, що адаптивна верстка – це необхідність для всіх існуючих веб-ресурсів, сайт, що має лише десктопну версію, виглядає «занедбаним», неактуальним і не викликає довіри. Отже, думка про компанію у відвідувача формується так: сайтом не займаються, значить компанії не потрібні клієнти.
Адаптуючи сайт під мобільні пристрої, необхідно враховувати можливість смартфона здійснювати дзвінки або відразу переходити з сайту в месенджери. Це багаторазово збільшує конверсію та полегшує клієнту шлях від переходу на сайт до покупки. Ми, як користувачі інтернету, вже звикли, що зателефонувати за номером на сайті або розпочати діалог з компанією в WhatsApp можна, здійснивши лише один рух пальцем. Нерозумно нехтувати такою перевагою та відмовлятися від адаптивної верстки.
Висновки напрошуються самі собою. Якщо бізнесу потрібні і важливі клієнти, то першочерговим завданням є адаптувати свої веб-ресурси в зручний для користувачів формат, а це означає – під мобільні пристрої. Таким чином, ви створюєте комфортне середовище взаємодії між компанією та клієнтом, що безпосередньо впливає на прибуток та ставлення до бренду.
Цикли Беннера – графік ринкових циклів з 1872 по 2059 рік, що прогнозує розвиток бізнесу та зміну цін на сировинні товари. В його основу лягли періоди найбільшої активності на ринках металу (чавун) та врожайності (кукурудза, свинина, бавовна). Принцип простий: чим краща ситуація у металургії та сільському господарстві, тим впевненіше почувається бізнес у цілому.
Графік «Періоди, коли потрібно заробляти гроші» склав ще 1872 року бізнесмен Джордж Трітч. Однак широку популярність цій гіпотезі приніс фермер з Огайо Семюел Беннер, який у 1875 році випустив книгу «Пророцтва Беннера про майбутні злети та падіння цін».
Графік циклів Беннера – Тритча складається з трьох горизонтальних поділів: A, B, C.
Рівень A. Періоди найбільшої паніки та невизначеності на ринках з піками, що чергуються, кожні 16–20 років. Тут рекомендується залишатися поза ринком або йти на свідомий ризик.
Рівень B. Роки, що характеризуються економічною активністю та високими цінами на сировину та активи. Беннер зазначив, що в цей час найкраще продавати. Цикли чергуються кожні 8-10 років.
Рівень C. Гарний час для покупки активів та товарів. У цей період рекомендується утримувати актив до наступу років на рівні B. Цикли рівня C відбуваються кожні 7–11 років.
За словами засновника інвестиційної компанії Capriole Investments Чарльза Едвардса, тестування моделі показало 91% успішних угод. Стратегія також досить точно визначила вершини великих криз, включаючи 1929, 1999, 2007 та 2020 роки. Дані перевіряли на індексі Dow Jones.
Едвардс, відомий розробкою індикатора визначення глобального цінового дна біткоїну Hash Ribbons, дійшов такого висновку:
«Ринкові цикли повторюються. Незважаючи на те, що часи, технології, ринки та регулювання сильно змінилися за 150 років, ринкові цикли залишилися незмінними».
Крипторинок ще дуже молодий, його цінових даних недостатньо для тестування на таких глобальних моделях, як цикли Беннера — Тритча. Але якщо врахувати, що біткоїн отримав загальносвітове визнання на фінансових ринках, то можна розглянути цифрове золото як сировинний товар, як чавун.
У цьому випадку модель показала, що купувати першу криптовалюту слід було у 2012 році, утримуючи її до 2016 року з піком паніки та невизначеності на глобальному ринку у 2019 році. Навіть ці історичні дані показали подібність до рухів ціни біткоїну.
Наступний умовний сигнал на купівлю першої криптовалюти дано на 2023 рік із планом утримувати монети BTC до 2026 року.
Черговий «добрий» рік для покупки призначений на 2032 рік з метою утримання активу до 2034 року та із загальною панікою на ринках у 2035 році.
Цікаво, що деякі аналітики приходять до оцінки перспектив зростання ціни на біткоїн, використовуючи зовсім інші дані та метрики. Наприклад, співзасновник CMCC Crest Віллі Ву зазначив, що до 2035 року «справедлива ціна» біткоїну досягне позначки $1 млн. Як дані для оцінки він використав криву зростання користувачів.
CEO ARK Invest Кеті Вуд, хоч і не “потрапила” в модель Беннера – Трітча, але також прогнозує потужний цикл зростання для біткоїну. За її сценарієм перша криптовалюта може досягти ціни від $258 500 до $1,5 млн до 2030 року.
Таким чином, багато аналітиків з різних причин очікують сильний імпульс на ринку криптовалют у найближче десятиліття, як і передбачає вищеописана модель циклів півторарічної давності.
Аналіз потоку управління в TypeScript відмінно справляється з відстеженням, того як змінюється тип змінної в міру переміщення по коду, розглянемо на прикладі:
interface Bird {
commonName: string;
scientificName: string;
sing(): void;
}
// Map вміщює в себе: нузву країни -> національний птах
// Не у всіх країн є національні птахи
declare const nationalBirds: Map<string, Bird>;
function makeNationalBirdCall(country: string) {
const bird = nationalBirds.get(country); // У bird є оголошений тип Bird | undefined
if (bird) {
bird.sing(); // якщо змінна bird має тип Bird
} else {
// якщо змінна bird має тип undefined
}
}Через те, що тип змінної буває undefined , TypeScript змушує Вас перевіряти та обробляти такі випадки, тим самим підштовхуючи Вас писати більш надійний та захищений код.
А тепер подивимося на роботу з масивами в коді нижче, раніше це було б помилкою у всіх попередніх версіях TypeScript:
function makeBirdCalls(countries: string[]) {
// birds: (Bird | undefined)[]
const birds = countries
.map(country => nationalBirds.get(country))
.filter(bird => bird !== undefined);
for (const bird of birds) {
bird.sing(); // error: 'bird' is possibly 'undefined'.
}
}Незважаючи на те, що ми відфільтрували всі значення undefined , проте TypeScript не зміг це відстежити і видав помилку.
У TypeScript версії 5.5 більше таких проблем немає, перевірка типів відмінно справляється з цим кодом:
function makeBirdCalls(countries: string[]) {
// birds: Bird[]
const birds = countries
.map(country => nationalBirds.get(country))
.filter(bird => bird !== undefined);
for (const bird of birds) {
bird.sing(); // ok!
}
}Це працює, тому що TypeScript тепер виводить предикат типу для функції filter . Ви можете побачити, що відбувається, зрозуміліше, виділивши це в окрему функцію:
// function isBirdReal(bird: Bird | undefined): bird is Bird
function isBirdReal(bird: Bird | undefined) {
return bird !== undefined;
}bird is Bird – це предикат типу. Це означає, що якщо функція повертає true , це Bird (якщо функція повертає false , то він не визначений, тобто undefined ). Оголошення типів для Array.prototype.filter знають про предикат типу, тому в кінцевому підсумку ви отримуєте більш точний тип, і код проходить перевірку типів.
TypeScript зробить висновок, що функція повертає предикат типу, якщо виконуються такі умови:
Загалом це працює так, як і очікувалося. Ось ще кілька прикладів предикатів типів, що виводяться:
// const isNumber: (x: unknown) => x is number
const isNumber = (x: unknown) => typeof x === 'number';
// const isNonNullish: <T>(x: T) => x is NonNullable<T>
const isNonNullish = <T,>(x: T) => x != null;Раніше TypeScript просто виводив, що ці функції повертають boolean . Тепер він виводить сигнатури з предикатами типу, наприклад x is number або x is NonNullable<T> .
Предикати типу мають семантику “if and only if”. Якщо функція повертає x is T , це означає, що:
Якщо ви очікуєте, що предикат типу буде виведений, але цього не відбувається, ви можете порушити друге правило. Це часто призводить до перевірок «істинності»:
function getClassroomAverage(students: string[], allScores: Map<string, number>) {
const studentScores = students
.map(student => allScores.get(student))
.filter(score => !!score);
return studentScores.reduce((a, b) => a + b) / studentScores.length;
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// error: Object is possibly 'undefined'.
}TypeScript не вивів предикат типу для score => !!score , і це правильно: якщо це повертає true , то score – це number . Але якщо це повертає false , то score може бути або undefined , або number (зокрема, 0). Це реальний баг: якщо якийсь студент отримав нульовий бал у тесті, то фільтрування його балів спотворить середній бал вгору.
Як і в першому прикладі, краще явно відфільтрувати undefined значення:
function getClassroomAverage(students: string[], allScores: Map<string, number>) {
const studentScores = students
.map(student => allScores.get(student))
.filter(score => score !== undefined);
return studentScores.reduce((a, b) => a + b) / studentScores.length; // ok!
}Перевірка істинності виведе предикат типу типів об’єктів, де немає неоднозначності. Пам’ятайте, що функції повинні повертати boolean значення, щоб бути кандидатом на виведений предикат типу: x => !!x може вивести предикат типу, але x => x напевно не буде.
Явні предикати типу продовжують працювати так само, як і раніше. TypeScript не перевірятиме, чи виведе він той самий предикат типу. Явні предикати типу (is) не безпечніше затвердження типу (as).
Можливо, що ця функція зламає існуючий код, якщо TypeScript тепер виведе точніший тип, ніж вам потрібно. Наприклад:
// Раніше, nums: (number | null)[]
// Зараз, nums: number[]
const nums = [1, 2, 3, null, 5].filter(x => x !== null);
nums.push(null); // ok в TS 5.4, error в TS 5.5Виправлення полягає в тому, щоб вказати TypeScript потрібний вам тип за допомогою явної інструкції типу:
const nums: (number | null)[] = [1, 2, 3, null, 5].filter(x => x !== null);
nums.push(null); // ok,
За останні два роки екосистема біткоїну значно розширилася за рахунок нових активів – взаємо-і незамінних токенів на кшталт BRC-20 і Ordinals. Загальна ринкова капіталізація таких монет подолала рубіж у $2 млрд, дозволивши майнерам заробити багатомільйонні доходи на додаток до нагород за здобутий блок та комісіям за традиційні платежі у цифровому золоті.
Однак невдовзі після своєї появи нові активи зіткнулися із запеклою критикою з боку «біткоін-пуристів» на кшталт розробника Люка Деша — молодшого, який закликав «забанити» BRC-20 та «написи» за допомогою «спам-фільтра».
У вересні 2023 року автор Ordinals Кейсі Родармор представив новий стандарт взаємозамінних токенів – Runes. За словами розробника, такий формат не залишає багато «сміття» у мережі біткоїну, на відміну від BRC-20.
«Засновані наUTXOпротоколи органічно вписуються в блокчейн біткоїну, сприяючи мінімізації зростання невитрачених транзакцій та уникаючи створення їх “сміттєвих” аналогів», – пояснив фахівець.
За його словами, Runes розроблені «для дегенів та мем-коїнів» і призначені для спрощення створення та управління взаємозамінними токенами на блокчейні першої криптовалюти.
«Але протокол простий, ефективний та безпечний. Це повноправний конкурент Taproot Assets та RGB », – написав Родармор на початку квітня.
Запуск Runes відбувся в день четвертого халвінгу – 20 квітня.
Щоб отримати уявлення про принципи роботи Runes, потрібне розуміння ключових термінів:
UTXO – система, що дозволяє відстежувати залишки криптовалюти, які ще не були витрачені та можуть бути використані у нових транзакціях.
Кожен невитрачений вихід – кошти, доступні для нових ончейн-операцій. Ця система забезпечує безпеку транзакцій, оскільки кожен UTXO може бути витрачений лише один раз, що запобігає можливості подвійної витрати.
За словами аналітиків CoinGecko, кожен невитрачений вихід може містити будь-яку кількість Runes.
Опкод OP_RETURN дає користувачам можливість прикріплювати довільні дані (до 80 байт) до біткоін-транзакцій без шкоди для ефективності мережі. У випадку Runes інформація про токене записується в окремий вихід, який неможливо витратити.
Ця функція використовується для зберігання інформації та визначає особливості виконання операції. Відповідні відомості можуть містити основні дані про токене: назву, ID, команду для певних дій і т.д.
Повідомлення Runes, що зберігаються в сегменті OP_RETURN біткоін-транзакції, також відомі як Runestone. Останні дозволяють створювати та передавати токени в мережі першої криптовалюти.
Кожна транзакція у протоколі може зазначати кілька операцій у різних «рунах». У разі надсилання токена Runes розділить невитрачений вихід транзакції на кілька нових UTXO на основі інструкцій у даних OP_RETURN. Кожен невитрачений вихід представляє різні кількості токенів, які потім надсилаються одержувачам.
Якщо транзакція «фейлиться» через некоректне повідомлення протоколу, «руни» знищуються для запобігання створенню додаткових об’єктів.
Завдяки OP_RETURN користувач може здійснювати кілька типів операцій:
Ще одна функція – Edict (“указ”) – визначає правила перекладу Runes після їх “травлення” або “мінтингу”. Наприклад, «указ» дозволяє здійснювати пакетні трансфери активів, аірдропи або передачу всіх випущених «рун» на один рахунок.
Виділимо основні позитивні характеристики створеної Родармор системи.
Простота . Runes пропонує користувачам більш зрозумілий спосіб створення токенів, що взаємозаміняються, поверх мережі біткоїну в порівнянні з BRC-20, RGB або Taproot Assets. Користувачі можуть генерувати різні токени та ефективно керувати ними ончейн, не покладаючись на офчейн-дані та не створюючи значної кількості «сміттєвих» UTXO.
Ресурсоефективність . Система не створює невитрачені виходи, які неможливо витратити, а параметри зберігання споживають менше ресурсів. Опкод OP_RETURN займає лише 80 байт, тоді як активи BRC-20 можуть містити до 4 Мб різних даних.
Позитивний вплив на доходи майнерів . Квітневий халвінг зменшив нагороду за блок удвічі, зменшивши рентабельність видобутку цифрового золота. Runes, по суті, є додатковим джерелом доходу для майнерів. Блоковий простір обмежений, тому що більше транзакцій обробляється, то вище комісії.
Збільшення бази користувача . На думку автора протоколу, основний юзкейс Runes – створення мем-активів. Останні мають чималу популярність у межах поточного ринкового циклу. Глава відділу досліджень Messari Мартьє Бас переконана, що подібні токени «ненавмисно» знайомлять новачків у Web3 з основами криптографічних концепцій, включаючи децентралізовані біржі ( DEX ) та криптогаманці.
Розширення можливостей та екосистеми біткоїну . Аналітики CoinGecko переконані, що різні протоколи, які дозволяють створювати токени в блокчейні першої криптовалюти, приносять користь мережі та екосистемі загалом.
Зокрема, Runes надає можливість проводити транзакції у Lightning Network . Це може активізувати зростання та розвитку мережі мікроплатежів з урахуванням цифрового золота.
Як і BRC-20, Runes дозволяє створювати токени на блокчейні біткоїну. Однак «руни» позиціонуються як покращена система, менш вимоглива до ресурсів мережі першої криптовалюти.
У молодій екосистемі з’являються нові проекти. Деякі існуючі платформи анонсують додавання підтримки Runes.
Частина проектів безпосередньо взаємодіє з протоколом для створення активів на блокчейні біткоїну, інші пропонують утиліти для роботи з Runes.
На інфографіці нижче представлені основні елементи екосистеми, що розвивається, включаючи токени, платформи для запуску (лончпади і мінтпади), маркетплейси і DEX, гаманці, аналітичні платформи і т. д.
Хоча «руни» і випускаються на блокчейні біткоїну, для керування активами потрібні спеціальні додатки-гаманці – наприклад, Xverse, що підтримує також Ordinals і BRC-20. В якості альтернативи можна звернути увагу на UniSat .
Runes також підтримують деякі маркетплейси, що дозволяють розміщувати подібні об’єкти та торгувати ними. Наприклад, майданчик від OKX взаємодіє з Runes, а також стандартами «написів» Atomicals (ARC-20), Stamps (SRC-20) та Doginals (DRC-20).
На NFT-платформі Magic Eden також представлений розділ «рун».
Сервіс Luminex надає зручні інструменти для моніторингу нових колекцій, а також для створення, карбування та передачі Runes. Для доступу до ключових функцій необхідно підключити сумісний гаманець (Xverse, Magic Eden, UniSat, OKX або Leather).
Підтримка протоколу Runes також реалізована на премаркет-платформі Whales Market.
Експерти Franklin Templeton назвали Runes поряд з Ordinals та BRC-20 одним з головних драйверів відродження інновацій у біткоїні.
Ще напередодні халвінгу середній розмір транзакційної комісії у мережі першої криптовалюти перевищив $16. Аналітики The Block пояснили те, що відбувається пожвавленням ончейн-активності користувачів в очікуванні запуску Runes.
23 квітня частка «рун» у загальній кількості добових транзакцій на блокчейні біткоїну склала 81%. На традиційні операції з BTC припало 18,8%.
Ажіотаж навколо запуску Runes у день халвінгу 20 квітня підкинув середній розмір комісій до рекордних $128,45.
У наступні дні розмір зборів скоригувався ближче до колишніх значень. На момент написання (4 травня) показник становить $4,66, згідно з BitInfoCharts .
Глава TeraWulf Назар Хан назвав Runes «рятувальним колом» для біткоін-майнерів. За його словами, запуск протоколу серйозно підтримав доходи добувачів криптовалюти після халвінгу за рахунок зростання комісій.
Однак останнім часом ажіотаж навколо Runes поступово згасає. Про це свідчить падіння кількості переказів, випусків та інших операцій із новими активами.
Завдання візантійських генералів — логічний експеримент, який можна застосувати до електронних розподілених мереж. Його метою є знаходження способу синхронізації незалежних один від одного учасників.
Суть завдання:
«Армії кількох генералів (мережеві вузли) беруть в облогу місто. Спілкуватися між собою можуть тільки відправляючи гінців (транзакції). Ключове завдання – домовитися про загальний план нападу чи відступу (консенсус). Деякі генерали є зрадниками і всіляко хочуть завадити договору».
Першу наукову статтю на цю тему в 1982 опублікували Леслі Лемпорт, Роберт Шостак і Маршалл Піз. Завдання справедливе лише розподіленим системам, де немає центрального вузла, якому довіряють інші учасники мережі. У реальному світі таким вузлом може бути, наприклад, центральний банк країни, який відповідає за емісію фіатної валюти, розподіляючи її за рахунками комерційних банків.
Оскільки криптовалюти спочатку будуються на принципах децентралізації без єдиного органу управління, вирішення цього завдання стало основним у проектуванні мереж на основі технології блокчейну.
У 2008 році творець біткоїну Сатоші Накамото запропонував практичне вирішення завдання візантійських генералів. Він розробив протокол біткоїну та реалізував алгоритм консенсусу Proof-of-Work (PoW). Це дозволило виключити елемент довіри, встановивши чіткі правила досягнення консенсусу (договору) між вузлами розподіленої мережі біткоін (генералами).
PoW-алгоритм забезпечив здатність кожного вузла підтвердити, що інші вузли правильно виконали роботу та дотримуються договору. Це досягається за допомогою блокчейну, криптографією та економічними стимулами для майнерів, що захищають консенсус від зловмисних дій.
Коли один із вузлів вирішить виконати «неправильну роботу», всі інші учасники це побачать і не дозволять статися небажаною активністю.
Крім Proof-of-Work, найбільш поширеними та надійними рішеннями завдання візантійських генералів є алгоритми Proof of Stake (PoS) та Byzantine Fault Tolerance (BFT).
Proof of Stake (PoS) є найпопулярнішою версією на крипторинку. Суть механізму полягає в тому, що замість майнерів, як у PoW, керування мережею віддали власникам нативної монети. Головна перевага такого підходу – незначне споживання енергії порівняно з PoW.
Byzantine Fault Tolerance (BFT) – призначений для масштабування мереж PoS-блокчейнів. На відміну від попередніх, BFT використовує колективне ухвалення рішень у досягненні консенсусу. Вузли відправляють транзакції один одному поки що ⅔ всіх вузлів не прийдуть до однакового результату.
На ринку існує безліч модифікацій та гібридних алгоритмів. Один з таких – Tendermint, що лежить в основі блокчейну Cosmos, де одночасно застосовуються Delegated Proof-of-Stake (DPoS) та BFT. А, наприклад, Solana використовує dPoS та імплементацію алгоритму консенсусу BFT – Practical Byzantine Fault Tolerance (pBFT).
Крім цих алгоритмів у криптовалютах застосовують понад десяток варіантів консенсусу. Перерахуємо деякі з них:
Liquid Restaking Token (LRT) – токен, призначений для отримання додаткової прибутковості шляхом повторного рестейкінгу монет на алгоритмі Proof-of-Stake.
LRT-протоколи використовують безпеку та прибутковість від стейкінгу базового активу плюс можливості додаткових доходів за допомогою DeFi або сервісів активної валідації (Actively Validated Services, AVS), що включають кроссчейн-мости, оракули та сайдчейни.
Концепція LRT-додатків нагадує спільний PoW -майнінг (як, наприклад, при видобутку Dogecoin або Litecoin ), коли те саме обладнання використовується для забезпечення безпеки відразу в двох мережах.
Одним із основних способів створення прибутковості для ETH без зниження ліквідності базового активу є запуск власного валідатора, а це досить складний та дорогий процес.
Наступним етапом збільшення прибутку від стейкінгу стали токени ліквідного стейкінгу (Liquid Staking Token, LST) на кшталт stETH від Lido Finance. Але й вони обмежені прибутковістю валідаторів. Наприклад, доходність токена stETH на кінець квітня 2024 року становила 3,2%. А подальші варіанти використання LST знаходяться лише на ринку DeFi-додатків.
LRT, своєю чергою, дозволяють додатково збільшити доходність базового активу, зберігаючи його ліквідність. Наприклад, протокол EigenLayer пропонує варіанти отримання прибутку шляхом вибору AVS для повторного рестейкінгу LST. Користувач може заблокувати умовний stETH ще раз, отримавши токен рестейкінгу, що підлягає обміну на ETH у співвідношенні 1 до 1.
На квітень 2024 року EigenLayer вже має 9 активних пропозицій щодо AVS, ще більше 10 тестують на Holesky.
Такий підхід підвищує безпеку блокчейна Ethereum через застосування застібаних ETH в системах другого рівня. Наприклад, AVS-рішення від AltLayer дозволяє використовувати LRT для валідації операцій у мережах другого рівня Optimism та Arbitrum.
Ринок можливих механізмів додаткових доходів досі формується. Виплати комісійних можуть формуватись у базовому активі мережі, як це відбувається у LST, у форматі ретродропів за надану ліквідність, а також в інших токенах.
Підвищена прибутковість токенів ліквідного рестейкінгу несе у собі як можливості додаткового заробітку, нових інвестиційних стратегій, а й ризики, пов’язані з розробкою таких багаторівневих систем.
Складність подібних смарт-контрактів та невипробувана механіка в екстремальних ринкових умовах можуть призвести до виникнення невиявлених чи неврахованих проблем. Перерахуємо основні з можливих:
На кінець квітня 2024 року, згідно з даними DeFi Llama, сектор рестейкінгу маєTVLбільше $16 млрд у топі з EigenLayer (~$15,7 млрд).
Цей показник досягнуто лише за п’ять місяців із грудня 2023 року, коли TVL сектори становили лише $250 млн.
Почасти стрімке зростання зумовлене очікуванням аірдропу від протоколу EigenLayer, заявили аналітики Glassnode. LRT-протоколи також відзначені CoinGecko як основний драйвер в ETH в першому кварталі 2024 року. Аналітики виділили список найбільших протоколів, що включають Ether.fi, Renzo, Puffer, Kelp, Swell, Mantle.
Варто наголосити на LRT-ринку компанії Google. У квітні 2024 року хмарні підрозділи Coinbase і Google Cloud приєдналися до EigenLayer як оператори.
Експерти також вважають, що значне зростання EigenLayer може говорити про потенційну кризу прибутковості. На думку експертів, проект демонструє надто високі темпи зростання щодо AVS. Внаслідок цього запропонована доходність протоколу може різко скоротитися, що призведе до відтоку ліквідності.
У міру розвитку ІІ стає все важливіше розрізняти діяльність, що здійснюється людиною та нейромережею. Для вирішення цього завдання на допомогу може прийти Proof-of-Personhood (PoP), або доказ особистості.
Це механізм, який підтверджує «людяність» (personhood) та унікальність індивідуума. Метод набув поширення через те, що зловмисники створюють безліч підроблених облікових записів для маніпулювання голосуванням або розподілом нагород.
PoP також гарантує, що кожен учасник проекту отримає рівний голос та частку винагороди. Важливо, що, на відміну інших популярних механізмів консенсусу на кшталт докази роботи (Proof-of-Work, PoW) чи докази володіння (Proof-of-Stake, PoS), PoP не розподіляє право голоси чи винагороду пропорційно вкладеним ресурсам.
Необхідність у системах перевірки Proof-of-Personhood обумовлена зокрема загрозами недобросовісного використання технології дипфейк.
Передовий ІІ може стати інструментом, який розширює можливості людини. Але при цьому він уже дає чимало проблем.
Вирішити ці проблеми і покликаний Proof-of-Personhood.
По-перше, PoP забезпечує природне обмеження швидкості за рахунок верифікації облікового запису, що по суті виключає можливість проведення атаки Сівіли в помітних масштабах.
По-друге, механізм дозволяє фільтрувати контент: наприклад, допускати до перегляду лише ті облікові записи, які були підтверджені як такі, що належать унікальній людині. Це допомагає боротися з вірусним поширенням дезінформації, що генерується ІІ.
Доказ особистості може бути використаний для підтвердження людяності різними способами. Ось деякі з найпопулярніших:
Онлайн-тести Тюрінга
В даний час CAPTCHA намагаються обмежити швидкість автоматизованих атак Сівіли, використовуючи автоматичні тести Т’юрінга, щоб відрізнити людину від машини. Незважаючи на частковий успіх цього методу, він, як і раніше, не захищає від того, що одна людина може отримати кілька акаунтів. Для цього лише потрібно вирішити кілька CAPTCHA поспіль.
Цей метод має й інші недоліки. Наприклад, користувачі з поганим зором або обмеженими здібностями до навчання можуть зіткнутися з труднощами під час проходження головоломок.
Біометрична верифікація
Спеціалізовані платформи застосовують біометричні методи для верифікації особистості, такі як розпізнавання облич, відбитки пальців, геометрія долоні, сітківка або райдужна оболонка ока та підпис.
Фізичні методи верифікації
Ще один спосіб підтвердження особистості – фізична верифікація, в основному через відвідування заходів. У цьому випадку учасники можуть отримати, наприклад, SBT, що відображають їхній підтверджений статус.
Верифікація через соціальні мережі
Ще один підхід заснований на тому, що користувачі, що утворюють соціальну мережу, перевіряють особи один одного.
Цей підхід можна критикувати відсутність прямого способу перевірки того, що учасник не створив підроблені ідентифікатори, домовившись з іншими про їхнє підтвердження.
Пов’язана з цим проблема полягає в тому, що алгоритми виявлення Сівілл на основі графів зазвичай здатні знайти лише великі групи, внаслідок чого дрібні атаки важко чи зовсім неможливо виявити.
Гаманці з тимчасовим блокуванням
Інший підхід до верифікації PoP полягає в тому, що користувачі блокують кошти на певний термін, щоб відстежувати їхню активність протягом часу. Це може бути доказом унікальної поведінки людини, додаючи додатковий рівень перевірки боротьби з атаками Сивиллы. Однак цей метод також не є надійним.
Використання доказів із нульовим розголошенням
Докази з нульовим розголошенням (Zero-Knowledge Proof, ZKP) дозволяють підтверджувати певні атрибути себе, такі як вік чи національність, не розкриваючи фактичну інформацію. Це може бути реалізовано у децентралізованій системі, учасники якої доводять свою унікальність без розголошення особистих даних.
Існує кілька проектів, які працюють над протоколами ідентифікації на основі блокчейну. Вони дозволяють користувачам підтверджувати свою особистість, не покладаючись на централізовані інституції. Ці протоколи можуть бути інтегровані з різними децентралізованими програмами, щоб забезпечити послідовний доказ особистості в мережі.
Почасти недавній хайп навколо Worldcoin привернув увагу до PoP, але концепцію не можна назвати новою. 2014 року Віталік Бутерін запропонував розробити «систему унікальної ідентифікації» для криптовалют. Саме з цієї ідеї PoP розвинувся у кілька проектів, які використовують цю технологію.
Серед них:
HumanCode. Проект, що пропонує ідентифікувати особу по відбитку долоні та доступний будь-якому користувачеві смартфона. У квітні 2024 року уклав партнерство з TON Society.
Хоча PoP пропонує інноваційні способи підтвердження цифрової ідентичності та аутентифікації, механізм має певні недоліки:
Легасі (від англ. Legacy – спадщина) – реальність будь-якого програміста. Пояснюємо, як софт стає легасі і чому це нормально, а також які існують плюси при роботі з легасі. Не завжди варто ставитись до легасі як до прокляття, варто поглянути на нього як на природний етап життєвого циклу програмного забезпечення.
“Легасі” – це слово, яким програмісти лякають один одного (і менеджерів). Воно означає застарілий софт, працювати з яким зазвичай складно та/або неприємно через невеликий «вихлоп» у перерахуванні на зусилля, що вкладаються. Загалом словом «легасі» можна назвати будь-який «код», який складно підтримувати. І чим складніше, тим він «легасі».
Сьогодні розповімо, звідки він береться, як утримувати його «в рамках» і чим він може бути корисним для фахівців-початківців.
Не має значення, як добре і чисто написаний код — рано чи пізно він стане легасі.
Основні недоліки «легасі» для бізнесу, це:
Список передумов умовно поділяється на дві групи: ті, що не залежать від команди і ті, на які можна вплинути. До перших можна віднести старіння технологій, операційних систем, мов програмування, протоколів, бібліотек, фреймворків, та й підходів до проектування систем (наприклад, у разі нових можливостей, скажімо, багатоядерні процесори). Під старінням розуміється, те, що на зміну їм приходять нові технології, що дозволяють досягати результату швидше чи дешевше. Вся індустрія на них поступово перемикається, і якщо не йти в ногу з нею, то програмний продукт стає легасом.
До іншої групи можна віднести і низьку культуру чи погану організацію процесу розробки. Так, наприклад, незафіксовані вимоги до програмного продукту можуть призводити до конфліктів між користувачами та розробниками (і навіть усередині групи розробки). У міру розвитку ПЗ необхідно вносити зміни та документацію. Відсутність такої практики призводитиме до тих самих проблем. Користувачі сильно залежатимуть від експертизи розробників. А якщо останні звільняться, то відновлення знань із коду, хоч і можливо, але зазвичай це довгий і трудомісткий процес, в результаті якого залишається багато питань «чому так зробили?» чи «навіщо це?».
Основні причини виникнення легасі: старіння технологій, погані технічні рішення/практики; відсутність вимог/документації; немає людей знайомих із проектом.
Важливою властивістю «легасі» є його розростання. Якщо не докладати зусиль для мінімізації, то з кожною зміною (і навіть без них) рівень «легасі» наростатиме. Як у другому початку термодинаміки, ентропія замкнутої системи не може зменшуватися. Тому нам треба методично «вичерпувати воду з нашого човна, що протікає».
Будь-який софт повинен приносити IT-компаніям прямо чи опосередковано дохід (або знижувати витрати). Саме собою існування легасі бізнес мало хвилює, поки вкладені зусилля окупаються. Найчастіше, повільна доопрацювання великої системи вигідніше, ніж перехід нову систему (де є необхідні зміни чи де доробка ведеться швидше).
Хвилина математики!
Можна припустити, що «легасі» — L(t) — невід’ємна функція від часу. Нехай швидкість розробки S(t) = F(L(t)) , де F – деяка функція, яка враховує вплив легі на швидкість розробки при інших постійних факторах. Точний вигляд F невідомий, але для неї вірно: чим більше «легасі», тим менше швидкість розробки, а «легасі» рівно «0» – швидкість максимальна: F(0) = Fmax.
При цьому користь компанії V визначається як інтеграл від ресурсів, що витрачаються:
V = ∫K · S (t) dt , де K – це сума, яку бізнес готовий вкласти в розробку софту за інтервал часу.
Якщо До подати у вигляді суми Ks (гроші на користь) і Kl (гроші на боротьбу з легасі), такі що Ks + Kl = K , то, знаючи форму F , можна максимізувати V для компанії.
І ось це завдання, яке у тому числі вирішує СТО – визначити форму F і максимізувати V 😉
Однак підтримка системи може зіткнутися з раптовою проблемою, наприклад: у сторонній бібліотеці виявлено вразливість. А бібліотека не підтримується та оновлень не буде. Варіантів вирішення проблеми може бути багато: усунути проблему самотужки, замінити бібліотеку, побудувати якесь безпечне оточення, відмовитися від функціоналу та ін.
Бувають випадки, коли легасі «лагодження/доопрацювання» не підлягає, тільки заміни. У такій ситуації перед бізнесом постане вибір:
Одне з головних завдань СТО — мінімізувати ризики «раптових проблем» і мати план дій у разі їх настання.
Готуватися до переходу на нову систему потрібно заздалегідь, як правило, це займає багато часу (і грошей). Потрібно перенести дані і, головне, навчити людей роботі в новій системі, що часто пов’язано зі зміною внутрішніх процесів. А таких змін ніхто не любить.
СТО завчасно має відстежувати тенденції на ринку технологій та продумувати план впровадження нових технологій у свої системи або планувати перехід на інші рішення, оцінюючи вартість різних варіантів.
Фронтенд нашої внутрішньої самописної ERP-системи побудований 2009-му році на основі ExtJS (на той момент лідер серед фреймворків для написання SPA-додатків). Крім підтримки та розвитку основної ERP-системи, нашій команді потрібно розробляти окремі допоміжні невеликі сервіси. На наш погляд, ExtJS для них не дуже підходив з двох причин: обмеження викликані візуальною частиною (ви з коробки отримуєте набір готових елементів, але вони стандартні, а їх кастомізація – це головний біль), і друге вкладення на початковому етапі розробки програми вище, ніж під час походу HTML+CSS+JQuery. Трохи помучено з технологіями «кам’яного віку» у 2013-14-му роках ми розпочали пошуки альтернативних фреймворків/бібліотек та знайшли AngularJS, ReactJS, MeteorJS, пізніше до них ще додалася vue.
Здобувши досвід розробки на кожній технології протягом 2-3 років, а також оглядаючись на ринок (де ReactJS є лідером) визначилися і більшість нових сервісів вже розробляємо на ReactJS. Навіть нові частини у нашій ERP-системі розробляємо з використанням ReactJS. У цьому слід зазначити, що більшість ERP залишається на ExtJS, т.к. її заміна на ReactJS не принесе стільки вигоди, скільки коштуватиме заміна.
Отже, «легасі» присутня тією чи іншою мірою у всіх компаніях, де є розробка. То яка ж користь від нього? Для бізнесу користі ніякої немає — за інших рівних, чим більше легасі, тим для компанії гірше, проте зменшення чи підтримка легасі на заданому рівні коштує грошей, тож кожна компанія визначає цей рівень самостійно. (Звичайно ж за формулами вище, а, по інтуїції, але якось визначає).
Однак користь від легасі може бути для співробітників, які з нею працюють. Особливо для новачків, які приходять в компанію. По-перше, рівень зарплати може бути вищим, якщо ви не перший, хто влаштовується працювати з «їх легасі». Компанія може утримувати розробників, щоб їхній код хтось підтримував. По-друге, рівень стресу може бути нижчим, якщо компанія звикла до повільних впроваджень (застереження, не скрізь і не завжди). Плюс сумнівний, але для когось це може здатися комфортнішим місцем. По-третє, є можливість вивчити глибше певні технології, які використовуються в цій компанії — все одно «легасі» вивчати, можна й документацію з технологій почитати. Особливий плюс для джунів, яким потрібне перше місце роботи — якщо в компанії готові їх взяти та допомагати розбиратися з кодом, навіть вирішуючи прості завдання у складній системі — це може бути чудовим стартом кар’єри. Ще один плюс – можна подивитися, як робити НЕ треба;-)
Якщо ви «застрягли» в якійсь технології, не впадайте у відчай, можливо через кілька років, ви станете рідкісним високооплачуваним фахівцем. 🙂
У США ряд старих банківських систем написано на COBOL – застарілій мові програмування. Підтримувати системи треба, а молоді фахівці не бажають вивчати цю мову, тому фахівців не вистачає. Ситуація настільки загострилася, що ентузіаст COBOL створив власну компанію з надання екстреної підтримки банкам та навчання молоді мови, що за ним зробило і IBM.
Загалом від легасі нікуди не дінешся. Воно все одно з’являтиметься і з ним доведеться жити і боротися. Це варто сприймати як дзвінок. Або як нагода, якщо ви ще на старті кар’єри.
Іноді у свій React-додаток потрібно вбудувати сторонній компонент, який не працює з React і часто виявляється імперативним.
Такий компонент доводиться щоразу ініціалізувати, знищувати та, головне, перевіряти його стан, перш ніж викликати його методи.
Вірною ознакою того, що компонент потрібно обернути в декларативний компонент є велика кількість useEffect-ов , де перевіряються різні поєднання параметрів компонента. І, залежно від цих поєднань, викликаються відповідні методи компонента.
У статті я хочу розібрати кроки, як перетворити такий компонент на декларативний React-компонент.
Припустимо, є відео-плеєр у вигляді класу із звичайними для плеєрів методами:
Крім того, користувач може запустити/зупинити програвання, просто натиснувши на відео в плеєрі.
Наша мета: вбудувати плеєр у наш React-додаток та програмно керувати програванням.
Якщо робити в лоб, то вийде приблизно так:
import { useEffect, useRef } from "react";
import { Player } from "video-player";
const SOURCES_MOCK = "nice-cats.mp4";
export default function App() {
const playerElem = useRef<HTMLDivElement>(null);
const player = useRef<Player>();
useEffect(() => {
player.current = new Player();
player.current.applyElement(playerElem.current);
player.current.setSource(SOURCES_MOCK);
return () => player.current?.destroy();
}, []);
return (
<div className="App">
<button
disabled={player.current?.getState().status === "playing"}
onClick={() => player.current?.play()}
>
Play
</button>
<button
disabled={player.current?.getState().status === "stopped"}
onClick={() => player.current?.stop()}
>
Stop
</button>
<div ref={playerElem} />
</div>
);
}Для простоти, SOURCE_MOCK тут захардкоден.
Основні принципи тут:
Ми помічаємо, що при старті програми, а також, якщо користувач зупинив програвання клікнувши на відео, а не натиснувши на нашу кнопку “Stop”, то наші кнопки не знають про це, і не disable-ються відповідним чином.
Відбувається це, тому що при натисканні ми викликаємо методи плеєра, але не змінюємо стан компонента App. Тому немає ре-рендера, і кнопки не оновлюються.
Але плеєр має стандартний спосіб підписатися на події:
export default function App() {
const playerElem = useRef<HTMLDivElement>(null);
const player = useRef<Player>();
const [, forceUpdate] = useReducer((x) => x + 1, 0); // новое
useEffect(() => {
player.current = new Player();
player.current.applyElement(playerElem.current);
player.current.setSource(SOURCES_MOCK);
player.current.addListener("statusChange", forceUpdate); // новое
return () => player.current?.destroy();
}, []);
...Ми додали передплату на подію зміни статусу. Відписуватися від події не обов’язково, тому що ми повертаємо з використанняефект виклику методу destroy(), який запуститься при розмонтуванні компонента, і сам відпише плеєр від усіх подій.
forceUpdate — це функція милиці (див. React FAQ), щоб перерендерити App, і наші кнопки дізналися про новий стан плеєра.
Цей підхід має плюс:
Але це не React-way. У React прийнято виконувати контрольовані компоненти.
Незважаючи на те, що добре мати єдине джерело правди, краще, коли стан усіх дочірніх компонентів виводиться зі стану батьківського компонента. Тоді точно не буде гонки.
Тобто. Тепер стан клавіш виводиться безпосередньо зі стану дочірнього компонента – плеєра. І тепер ми інвертуємо потік даних: стан як кнопок, так і плеєра виводиться зі стану App, а не навпаки.
Тому компоненти роблять контрольованими: цікавлять нас параметри дочірнього компонента, як би, копіюють у стан (useState) батьківського компонента. І тоді батьківський компонент “знає”, з якими властивостями потрібно рендерити дочірній.
Бонусом, в React ми отримуємо автоматичний ре-рендер батьківського компонента, зокрема оновлення кнопок. Що нам, зрештою, і потрібно.
Давайте зробимо плеєр більш контрольованим, щоб зміни його стану відображалися у зміні стану App:
export default function App() {
const playerElem = useRef<HTMLDivElement>(null);
const player = useRef<Player>();
const [status, setStatus] = useState("stopped"); // новое
useEffect(() => {
player.current = new Player();
player.current.applyElement(playerElem.current);
player.current.setSource(SOURCES_MOCK);
player.current.addListener("statusChange", setStatus); // новое
return () => player.current?.destroy();
}, []);
return (
<div className="App">
<button
disabled={status === "playing"} // новое
onClick={() => player.current?.play()}
>
Play
</button>
<button
disabled={status === "stopped"} // новое
onClick={() => player.current?.stop()}
>
Stop
</button>
<div ref={playerElem} />
</div>
);
}Тепер замість милиця forceUpdate є нормальна установка статусу. Код став чистішим, і ми на крок ближче до React-івності.
Але проблема з таким компонентом у тому, що якщо ми захочемо десь знову використовувати плеєр, то доведеться точно повторити третину цього коду.
Давайте виділимо плеєр в окремий декларативний React-компонент, щоб його можна було легко перевикористовувати в інших місцях програми.
Для цього корисно уявити, як, в ідеалі, використовуватиметься його інтерфейс з основними властивостями. Якось так:
<VideoPlayer
source={source}
status={status}
onStatusChange={(status) => setStatus(status)}
/>Поки що цього вистачить, а в міру використання розберемося, чого не вистачає.
Виходить, що у VideoPlayer мають переїхати:
type PlayerProps = {
source: string;
status: Status;
onStatusChange: (status: Status) => void;
}
const VideoPlayer: React.FC<PlayerProps> = (props) => {
const playerElem = useRef<HTMLDivElement>(null);
const player = useRef<Player>();
useEffect(() => {
player.current = new Player();
player.current.applyElement(playerElem.current);
player.current.setSource(props.source);
switch (props.status) {
case "playing": player.current.play(); break;
case "paused": player.current.pause(); break;
case "stopped": player.current.stop(); break;
}
player.current?.addListener("statusChange", props.onStatusChange);
return () => player.current?.destroy();
}, []);
return <div ref={playerElem}/>;
};Тепер VideoPlayer можна перевикористовувати без необхідності повторювати цей useEffect.
Якщо покликати по кнопках Play і Stop, виявляється, що плеєр ніяк на них не реагує.
Це так, тому що source і status встановлюються один раз при ініціалізації компонента VideoPlayer. І при їх зміні не викликаються відповідні методи плеєра.
Давайте перенесемо їх в окремий спосібефекту, щоб відстежувати їх зміни:
const VideoPlayer: React.FC<PlayerProps> = (props) => {
const playerElem = useRef<HTMLDivElement>(null);
const player = useRef<Player>();
useEffect(() => {
player.current = new Player();
player.current.applyElement(playerElem.current);
player.current.addListener("statusChange", props.onStatusChange);
return () => player.current?.destroy();
}, []);
useEffect(() => {
player.current?.setSource(props.source); // перенесли
}, [props.source])
useEffect(() => {
switch (props.status) { // перенесли и обработали все значения
case "playing": player.current?.play(); break;
case "paused": player.current?.pause(); break;
case "stopped": player.current?.stop(); break;
}
}, [props.status]);
return <div ref={playerElem}/>;
};useEffect запускає свій колбек при зміні масиву залежностей. А там у нас лежать пропси props.source та props.status, зміни яких ми хочемо відстежувати. Тому тепер плеєр реагує на зміни джерела та статусу.
Зверніть увагу, що першим повинен бути той ефект, який створює плеєр. Тому що решті використанняефекту потрібен вже створений плеєр. Якщо його не буде, то вони не спрацюють, доки не зміниться їх масив залежностей. І відео не буде показано в плеєрі доти, доки користувач не клікне Play.
Тому, потрібно стежити за порядком прямування useEffect (див. The post-Hooks guide to React call order ).
Примітка : остання версія документації React радить відстежувати зміни пропсів не в useEffect, а прямо в тілі функції компонента. Тому що тоді можна уникнути зайвих циклів рендерингу. Але це не наш випадок — ми викликаємо методи нативного плеєра, відповідно зайвих рендерингів не буде.
З обробником onStatusChange та сама проблема — він додається зараз один раз при ініціалізації плеєра. Це погано, т.к. його не зміниш. Давайте зробимо за аналогією з пропсами-полями:
useEffect(() => {
const onStatusChange = props.onStatusChange;
if (!player.current || !onStatusChange) return;
player.current.addListener("statusChange", onStatusChange);
return () => player.current?.removeListener("statusChange", onStatusChange);
}, [props.onStatusChange]);З цікавого тут два моменти:
Плеєр має деякі властивості, які можуть змінюватися досить часто. Наприклад:
Хочеться зробити так само, як з іншими властивостями:
<VideoPlayer
position={position}
onPositionChange={(position) => setPosition(position)}
source={source}
status={status}
onStatusChange={(status) => setStatus(status)}
/>Але є три проблеми:
Саме тому бібліотеки, де потрібна висока швидкість оновлення компонента, часто доводиться відходити від декларативного підходи до імперативного. Або робити щось спеціально, щоб уникнути зайвого рендерингу.
Наприклад, у React Spring є поняття Animated Components – спеціально обгорнутих компонентів, які використовуються як звичайні декларативні, але під капотом працюють безпосередньо з DOM-елементами.
Тому краще залишити частину API VideoPlayer імперативним, наприклад, так:
type PlayerApi = {
seek: (position: number) => void;
};
const VideoPlayer = forwardRef<PlayerApi, PlayerProps>((props, ref) => {
...
useImperativeHandle(ref, () => {
return {
seek: (position: number) => player.current?.seek(position)
};
}, []);
...
}
export default function App() {
const playerApi = useRef<PlayerApi>(null);
...
<button
onClick={() => playerApi.current?.seek(0)}
>
Seek beginning
</button>
<VideoPlayer
ref={playerApi}
source={SOURCES_MOCK}
status={status}
onStatusChange={setStatus}
/>
...
}З’являється трохи зайвого коду у вигляді forwardRef, але саме useImperativeHandle пропонується документацією React для того, щоб передати батьківському компоненту своє імперативне API.
Але якщо уявити, що position знадобиться виводити зі стану інших елементів, а не задавати прямо за подією кліка. Тоді, в App доведеться завести окремий useEffect, аналогічно тому, як робили вище у VideoPlayer. І в ньому викликатиме наш API.
Для того щоб зробити з імперативного компонента декларативний, потрібно:
У контексті блокчейн-систем інтероперабельність передбачає можливість різних мереж взаємодіяти, обмінюватися даними та здійснювати транзакції. Зокрема, вона дозволяє передавати активи між різними ланцюжками, минаючи посередників на кшталт централізованих бірж.
Однією з основних перешкод масового застосування блокчейна і Web3 залишається розрізненість мереж. Користувачі, які вибрали окремий блокчейн (наприклад, Ethereum), здатні без проблем працювати з децентралізованими додатками (dapps) усередині цієї мережі, але взаємодія з іншими системами (Polkadot, Avalanche тощо) може бути утруднена. Це змушує розділяти ліквідність між різними мережами, а розробники розпорошують ресурси за підтримки проектів одразу на кілька блокчейнах.
Рішення, створені задля забезпечення інтероперабельності, покликані усунути розрізненість існуючих мереж, забезпечуючи їх ефективне взаємодія.
Встановлення єдиних стандартів і протоколів сприяє створенню взаємозалежнішої екосистеми, в якій активи та інформація безперешкодно переміщаються між різними платформами. Ця функціональність реалізується за рахунок використання спеціалізованих технологій, що ліквідують бар’єри між ізольованими блокчейн-системами.
Перерахуємо основні переваги, яких можна досягти завдяки інтероперабельності:
Кросчейн-сумісність підвищує ліквідність та доступність активів для користувачів, дозволяючи їм переміщатися між різними блокчейнами. Це відкриває нові інвестиційні горизонти, даючи можливість взаємодіяти з ширшим спектром активів на різних платформах та сприяючи диверсифікації портфелів.
Кросчейн-інтероперабельність також зміцнює інфраструктуру децентралізованих додатків, сприяючи їхньому повсюдному впровадженню.
Розподілені мережі регулярно стикаються з труднощами, зумовленими обмеженнями пропускної спроможності та швидкості обробки операцій. Протоколи кроссчейн-інтероперабельності застосовують у вирішенні цих проблем, розосереджуючи транзакції численними ланцюжками.
Це підвищує загальну масштабованість та ефективність мереж. Блокчейн-екосистеми отримують можливість задовольняти потреби користувачів і додатків, що зростають, без шкоди для загальної продуктивності.
Кроссчейн-взаємодія створює сприятливе середовище для співпраці, де розробники можуть використовувати переваги різних блокчейнів для інноваційних рішень.
Стимулюючи розвиток проектів, пов’язаних із сумісністю розподілених систем, прискорюється еволюція децентралізованих технологій. Розробники отримують можливість легко впроваджувати функціональність різних блокчейнів, що відкриває нові сценарії використання dapps.
ВикористанняCEXта інших централізованих платформ пов’язано з ризиком контрагента під час здійснення транзакцій.
Кросчейн-сумісність усуває необхідність у посередниках, знижуючи цей вид ризику та підвищуючи безпеку взаємодії з різними блокчейнами. Завдяки прямій комунікації, що забезпечується протоколами інтероперабельності, користувачі можуть надійно і безпечно здійснювати транзакції, не покладаючись на довірені треті сторони.
Використовуючи рішення інтероперабельності, криптокомпанії можуть:
Безшовні кроссчейн-операції оптимізують ланцюжки поставок та спрощують транскордонні платежі, відкриваючи нові можливості для розвитку бізнесу.
Завдяки технологіям інтероперабельності забезпечується єдине інтегроване блокчейн-середовище, що сприяє ширшому впровадженню технології. В результаті зростаєTVLсегмента DeFi та зменшується проблема фрагментації ліквідності.
З розвитком DeFi-сегменту та ринку криптовалют загалом з’явилися різні технології, що спрощують міжмережну взаємодію. У кожної їх свій унікальний підхід і характеристики.
Атомарний своп — децентралізований своп криптовалют, де дві сторони безпосередньо обмінюються активами без посередників. Угода відбувається миттєво та атомарно. Останнє означає, що обидві сторони отримують бажані монети, або обмін не здійснюється.
При реалізації атомарних свопів використовується договір хешування з блокуванням за часом (HTLC). Він вимагає, щоб одержувач платежу до закінчення встановленого терміну підтвердив отримання коштів шляхом створення криптографічного підтвердження платежу. В іншому випадку транзакція визнається недійсною, а кошти повертаються відправнику.
Такі операції можуть здійснюватися як ончейн, тобто між блокчейнами різних криптовалют, так і офчейн — за межами розподіленої системи.
Атомарні свопи можуть використовуватися для:
Переваги:
IBC -протоколи полегшують взаємодію між блокчейнами, створюючи єдине середовище для маршрутизації платежів серед різних мереж. Ці рішення забезпечують вільне переміщення вартості між незалежними екосистемами, сприяючи розвитку уніфікованої фінансової інфраструктури.
Встановлюючи загальні правила та механізми маршрутизації, міжмережові протоколи уможливлюють безшовні транзакції між різними блокчейнами. Це ефективні способи забезпечення кроссчейн-сумісності.
LayerZero – один із найвідоміших IBC-протоколів. Він покликаний усунути перешкоди комунікації між блокчейнами без шкоди безпеці та децентралізації. За словами розробників, омнічейн-рішення об’єднує економічну ефективність Polkadot та безпеку Cosmos.
З моменту заснування проект сумарно залучив $263 млн. (за підсумками п’яти раундів). Його оцінка становить $3 млрд.
Приклади інфраструктурних сервісів на базі LayerZero: Gas.zip , Telos Bridge та Decent.
Кросчейн-мости – це децентралізовані програми, що дозволяють переміщати активи між різними блокчейнами.
Вони взаємодіють з токенами різних стандартів (ERC-20, BEP-20 та інших) між мережами. Існують і кроссчейн-мости, що дозволяють переводити кошти між блокчейнами, побудованими за різними технологіями (біткоін, Ethereum, Litecoin, Dogecoin), а також серед рішень масштабування другого рівня (Arbitrum, Optimism).
Для здійснення кроссчейн-перекладів можуть створюватися обернені активи, використовувати пули ліквідності в декількох екосистемах. Також переказ коштів здатні здійснювати вузли ретрансляції, що мають у своєму розпорядженні кошти в різних блокчейнах.
Cross-Chain Interoperability Protocol (CCIP) – децентралізований протокол з відкритим вихідним кодом, розроблений Chainlink. Він має стати уніфікованим стандартом функціональної сумісності для Web3-екосистеми, дозволяючи смарт-контрактам будь-якої мережі безперешкодно взаємодіяти один з одним.
CCIP використовується у відомих Web3-проектах:
Wormhole – це децентралізований протокол, що дозволяє здійснювати безшовну передачу активів між різними блокчейнами.
Рішення забезпечує безперебійний обмін даними між розподіленими системами, що може бути корисним для розробників, що створюють dapps з мультичейн-функціональністю.
Протокол Wormhole запустили у 2021 році. З того моменту мережа щодня обробляє понад 2 млн. кросчейн-транзакцій на приблизну суму $35 млрд.
Наприкінці 2023 року проект залучив $225 млн при оцінці в $2,5 млрд.
Це протокол на базі алгоритму DPoS, що забезпечує механізм перевірки та безпеки кроссчейн-комунікації за допомогою гнучких методів досягнення консенсусу.
Валідатори мережі перевіряють транзакції у кожному блокчейні, підключеному до екосистеми. Hyperlane передбачає систему виявлення шахрайства, до якої задіяні спостерігачі (Watchtowers) з метою підтвердження коректності міжмережевих повідомлень.
Avalanche Warp Messaging (AWM) – протокол обміну даними. Він дозволяє будь-яким підмережам в екосистемі Avalanche відправляти та верифікувати повідомлення від інших підмереж або спеціалізованих блокчейнів.
Cross-Consensus Message Format (XCM) забезпечує зв’язок між системами консенсусу на Polkadot.
XCM дозволяє реалізувати різні сценарії кроссчейн-взаємодії:
Завдяки XCM платформа Polkadot стає не просто набором незалежних блокчейнів, а єдиною екосистемою, де всі учасники можуть безперешкодно взаємодіяти один з одним.
Axelar позиціонується як масштабована платформа взаємодії для Web3, що використовує алгоритм PoS. Проект прагне ліквідувати розрізненість блокчейнів, пропонуючи децентралізовану мережу валідаторів та набір інструментів для розробників.
Технологія спрощує переміщення активів серед dapps та взаємодію між різними мережами. Платформа забезпечує підвищену безпеку та дозволяє виконувати складні кроссчейн-операції.
Серед партнерів Axelar: MetaMask, Trust Wallet, Celestia, Lido, Uniswap, Microsoft та Circle.
В останні роки технології інтероперабельності продемонстрували помітний прогрес, але їх застосування, як і раніше, пов’язане з низкою складнощів.
Кроссчейн-мости — складні механізми, що працюють з різними екосистемами, які можуть використовувати різні мови програмування. Також вони передбачають концентрацію активів у єдиному смарт-контракті на конкретному блокчейні. В особливості реалізації таких рішень криються широкі можливості для хакерів .
Забезпечення незмінності даних при взаємодії блокчейнів також непросте завдання. Відмінності в механізмах консенсусу та моделях управління мережами створюють потенційні невідповідності та вразливості. Щоб зберегти цілісність та безпеку загальних даних у децентралізованих системах, потрібні надійні рішення та стандарти сумісності.
Різні блокчейни працюють з різними моделями довіри та протоколами захисту. Це ускладнює взаємодію, адже потрібно інтегрувати розрізнені системи, не знизивши безпеку та рівень децентралізації.
Ще один виклик — законодавчі норми та їхнє дотримання. Регуляторна невизначеність, необхідність відповідності правилам різних юрисдикцій — усе це перешкоджає впровадженню рішень для інтероперабельності.
Відкрийте криптовалютну картку Trustee за кілька хвилин! Оплачуйте ваші покупки миттєво з автоматичною конвертацією