Trustee – Як купувати товари використовуючи крипту?

Як купувати товари вікористовуючи крипту

Всі у кого є крипта рано чи пізно замислюются над тим як вивести її у справжні гроші.

Можна обміняти крипту по Р2Р. Але це, на мій суб’єктивний погляд, дуже гіморно.

Можна замовити картку яка буде підв’язана до крипти і просто розраховуватись в інтернеті та магазинах.

Всі хто має крипту чув про Вinance. Раніше вони випускали свою картку, і я її раніше використовував. Але потім їм закрутили гайки, і регулятор заборонив їм випускати картки. Це була для мене прям біда. Зручно платити в магазинах вже було не можливо. Але  самі Вinance запропонували альтернативу Trustee. Вони це запропонували відразу як тільки картки Вinance перестали працювати.

І на решті я вирішив замовити в них картку. Виявилось що картка віртуальна і приходить відразу після замовлення в аплікаціі на телефоні.

Коштує вона  10 евро.

Обслуговування картки: безкоштовно.

Конвертація в євро: 0.5%

Розрахунок онлайн/офлайн: 0%

Поповнення балансу криптовалют: 0%

Денний ліміт 5000 евро

Місячний ліміт 50000 евро

Зняття готівки в банкоматах з NFC терміналом: 1,5%+1 EUR

Добовий ліміт на зняття готівки: 2 000 EUR

Місячний ліміт на зняття готівки: 20 000 EUR

Криптокартку Trustee легко під’єднати до платіжних сервісів Google Pay та Apple Pay.

Можна отримати готівку в будь-якому банкоматі з NFC-модулем.

Доволі таки зручною. Кому цікаво можете зареєструватись тут.

До відома пілся реєстрації надаються невеличкі бонуси. 🙂

8 порад, як зробити ваш сайт схожим на додаток для iOS

Порада 1: використовуйте симулятор

використовуйте симулятор

У Xcode є симулятор, який можна використовувати для розробки та тестування веб-сайту в оригінальному iOS Safari без використання пристрою.

Щоб використовувати його,

  1. Відкрийте Xcode
  2. На панелі меню натисніть Xcode > Відкрити інструмент розробника > Симулятор

Тепер ви можете відкрити Safari на симульованому iPhone та безпосередньо відвідати свій сайт у розробці, наприклад, через localhost:3000.

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

Порада 2. Зробіть свій сайт автономною програмою

Зробіть свій сайт автономною програмою

Щоб надати вашій програмі окрему вкладку в перемикачі програм iPhone, а також щоб приховати попередній перегляд посилань та інший інтерфейс, пов’язаний із Safari, потрібно позначити свій веб-сайт як автономну програму.

Щоб зробити це,

  1. Створіть site.webmanifestфайл у своєму /publicкаталозі та встановіть автономний режим відображення: 
    // public/site.webmanifest
{
  "display": "standalone"
}
  2. Посилання на файл маніфесту за допомогою <link>тегу в <head>розділі вашого сайту: 
    <link rel="manifest" href="/site.webmanifest" />

Тепер, коли ваші користувачі відвідують ваш сайт і натискають «Поділитися» > «Додати на головний екран», вони отримають ярлик разом із іншими програмами свого телефону. Натискання цього ярлика відкриє ваш сайт у власному спеціальному контексті програми та вимкне пов’язаний із браузером інтерфейс користувача, як-от кнопки вперед і назад.

Порада 3: додайте коротку назву

додайте коротку назву

За замовчуванням iOS використовуватиме ваш сайт <title>як мітку для ярлика програми, створеного за допомогою кнопки «Додати на головний екран». У файлі веб-маніфесту можна встановити short_name властивість, яку iOS використовуватиме як назву програми:

// public/site.webmanifest
{
  "display": "standalone",
  "short_name": "Fitness"
}

Тепер, коли користувачі додають на головний екран, вони бачитимуть це ім’я за умовчанням.

Порада 4: додайте значки та заставки

додайте значки та заставки

За замовчуванням iOS використовуватиме знімок екрана вашого веб-сайту як значок програми. Крім того, під час завантаження програми ваші користувачі бачитимуть лише білий екран.

Ми можемо використовувати чудову бібліотеку pwa-asset-generator , щоб допомогти нам створити деякі піктограми та екрани-заставки для різних розмірів пристроїв, які можуть використовувати наші користувачі.

Ця бібліотека використовує просту піктограму SVG і трохи CSS і автоматично генерує різні екрани-заставки та значки, які iOS розпізнає та використає для ярлика вашої програми.

Ось команда, яку я використовував ( public/asset-generator-changes.htmlспочатку вам знадобиться порожній файл для існування):

npx pwa-asset-generator public/weightlifting-svgrepo-com-white.svg public -m public/site.webmanifest --padding "calc(50vh - 25%) calc(50vw - 25%)" -b "linear-gradient(135deg, #2fb9e4, #ff0098)" -q 100 -i public/asset-generator-changes.html --favicon

Це перевіряє веб-сайт Apple на найновіші розміри екрану та роздільну здатність пристрою та генерує піктограми та екрани-заставки для кожного з них.

Після створення зображень вам потрібно буде скопіювати зміни у html файл, який ви надали команді, і вставити їх у <head>розділ свого сайту.

Завдяки цим новим <link>тегам ваші користувачі тепер бачитимуть вашу блискучу нову піктограму програми на своєму домашньому екрані, а також повноекранне зображення-заставку, поки браузер завантажуватиме ваш сайт.

Порада 5. Зробіть рядок стану прозорим

Зробіть рядок стану прозорим

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

<meta
  name="apple-mobile-web-app-status-bar-style"
  content="black-translucent"
/>

<meta name="viewport" content="initial-scale=1, viewport-fit=cover" />

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

Якщо на пристрої є виїмка (як на iPhone 11, показаному на відео), виїмка приховає частину вмісту у вашому заголовку.

Щоб виправити це, ви можете використовувати медіа-запит CSS у режимі відображення, щоб врахувати додатковий простір:

@media screen and (display-mode: standalone) {
  header {
    height: 88px !important;
  }
}

Бонус: якщо ви використовуєте Tailwind, ви можете додати префікс, standaloneналаштувавши screensрозділ конфігурації Tailwind:

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      screens: {
        standalone: { raw: "(display-mode: standalone)" },
      },
    },
  },
};

Тепер ви можете використовувати префікс безпосередньо у своєму HTML, щоб налаштувати програму залежно від того, чи працює вона в автономному режимі. Наприклад:

<header class="h-11 standalone:h-22"></header>

Оновлення: є кращий спосіб врахувати розмір виїмки iPhone у заголовку.

env() Ми можемо використовувати функцію CSS зі safe-area-inset-top змінною середовища, щоб врахувати додаткову висоту:

header {
  padding-top: env(safe-area-inset-top);
}

(Зауважте, що спочатку ми видаляємо клас фіксованої висоти h-11 з нашого заголовка, щоб відступ набув чинності.)

Якщо використовується Tailwind, ми можемо додати safe-* значення до шкали інтервалів нашої конфігурації

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      spacing: {
        "safe-top": "env(safe-area-inset-top)",
        "safe-bottom": "env(safe-area-inset-bottom)",
        "safe-left": "env(safe-area-inset-left)",
        "safe-right": "env(safe-area-inset-right)",
      },
    },
  },
};

і використовувати їх через утиліти padding безпосередньо в нашому заголовку:

<header class="pt-safe-top">
  <!-- ... -->
</header>

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

Це, безперечно, кращий підхід, тому дякуємо всім, хто вказав на це!

Порада 6: виправте заголовок

виправте заголовок

Зараз наш заголовок прокручується з нашим вмістом. Це виглядає неприродно, коли наш сайт є повноекранною програмою, тому давайте це виправимо.

<header class="fixed">
  <!-- ... -->
</header>
<main class="mt-11 pt-safe-top">
  <!-- ... -->
</main>

Ми також враховуємо додатковий простір із деяким запасом на нашому <main> тегу, а також будь-який додатковий простір для вставок, використовуючи наші блискучі нові safe-*</code >значення інтервалів.

Порада 7. Вимкніть масштабування користувача

Можливість масштабувати двома пальцями — це те, чого користувачі очікують на веб-сайтах, але зазвичай не в програмах. Ми можемо вимкнути його, оновивши метатег «viewport» за допомогою правила «user-scalable=no»:

<meta
  name="viewport"
  content="initial-scale=1, viewport-fit=cover, user-scalable=no"
/>

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

Порада 8: встановіть прозорий колір підсвічування

встановіть прозорий колір підсвічування

За замовчуванням iOS виділить усі натискання посилань сірим полем, як це робиться для будь-якої веб-сторінки в Safari. Ми можемо встановити це, щоб колір підсвічування став прозорим, використовуючи правило CSS із префіксом постачальника:

body {
  -webkit-tap-highlight-color: transparent;
}

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

Сподіваюся, вам це було корисно! Час вразити друзів своїми блискучими новими мобільними веб-сайтами 🙂

Джерело

Важливість мобільної оптимізації сайту

Важливість мобільної оптимізації сайту

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

Отже, що ми взагалі знаємо, що таке оптимізація? Це процес, при якому frontend-розробник та web-дизайнер адаптують верстку сайту під розміри та функціонал інших пристроїв, крім комп’ютера. Робиться це для того, щоб інтерфейс сайту, а також текст та візуальні елементи відображалися та функціонували коректно і на смартфоні, і на планшеті, і на інших пристроях, відмінних від комп’ютера.

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

У чому особливість кожної з версій сайту?

Версія  для комп’ютера

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

Версія для ноутбука

Екрани ноутбуків мають меншу роздільну здатність, при цьому зберігають горизонтальну орієнтацію та аналогічний комп’ютер пристрій введення. Найголовніша особливість верстки під екран ноутбука – це збереження пропорцій тексту та візуальних елементів, але у меншому розмірі.

Версія для смартфона

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

Версія для планшета

Планшетна верстка є «гібридом» мобільним і десктопним. Розміри відображення візуального та текстового контенту схожі на комп’ютерну версію, а функціонал – на телефонну. Планшети – це пристрої із сенсорним екраном, тому необхідно вибрати розмір кнопок, враховуючи фактор зручності натискання пальцем. А завдяки достатньому розширенню екрана розмістити елементи навігації можна аналогічно комп’ютерної версії, і жодних незручностей користувачеві це не принесе.

Тепер звернемося до статистики та з’ясуємо, який тип пристроїв домінує як засіб виходу в інтернет. Наприклад, ми взяли деякі сайти, розроблені нами для наших клієнтів. Метрики показують розподіл переглядів сайту з мобільних пристроїв та з комп’ютерів (ноутбуків).

Не важко побачити, що переважна більшість відвідувань припадає саме на смартфони. І таку ситуацію ми постійно спостерігаємо. Смартфон людина користується набагато частіше, ніж комп’ютером. Це швидше, доступніше та зручніше. На даному етапі розвитку мобільних технологій можна навіть стверджувати, що для побутового користування без специфічних завдань смартфон цілком здатний замінити стаціонарний комп’ютер та ноутбук. А ось у зворотний бік такий маневр вже не спрацює, як мінімум тому, що сучасній людині потрібний постійний доступ до інтернету.

Тенденція масового переходу аудиторії на мобільні пристрої це історія, яку ми можемо спостерігати в реальному часі. Для порівняння: ще в 2014 році половина всіх виходів в інтернет вироблялася через настільний комп’ютер. Це був період, коли вже почали масово виходити в інтернет через смартфони, але все ще воліли desktop-версії сайтів. Але минуло зовсім небагато часу, і мобільні пристрої стали досить потужними, щоби дозволити з комфортом проводити час в інтернеті. Після цього «комп’ютерний серфінг» ставав дедалі менш популярним заняттям. Навіть ноутбуки та інші портативні комп’ютери не змогли «подолати» мобільні технології, що розвиваються з кожним роком.

Ще у 2021 році смартфони на порядок переганяли у популярності будь-які інші пристрої для виходу в інтернет. І природно, ця тенденція у 2024 році не зменшила обертів. Маючи таку статистику, питання про те, чи потрібно адаптувати веб-сайт для мобільних пристроїв, навіть не стоїть. У сьогоднішніх реаліях це скоріше необхідність, аніж додаткова послуга.

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

1. Ранжування у пошуковій видачі

Алгоритми пошукової системи, від яких залежить, наскільки високо знаходиться ваш сайт у пошуковій видачі, вже давно працюють за принципом Mobile First. Система підлаштовується під поведінку користувача і «розуміє» що більшість пошукових запитів здійснюються з мобільних пристроїв, тому і просуває в першу чергу ті сайти, які адаптовані під них.

2. Користувальницька поведінка.

Ще один важливий фактор, який впливає на індексацію сайту. Якщо користувачі залишають сайт у перші 5 секунд після відкриття сторінки, то пошукові системи враховують це та знижують сайт у результатах пошуку. Як показує практика, відкривши сайт, дизайн якого призначений лише для комп’ютерних екранів, людина не може правильно зорієнтуватися на ньому через некоректне відображення потрібної інформації (ціни на послуги, телефон, адресу компанії тощо). Це призводить до банального роздратування та відходу з сайту.

3. Імідж компанії.

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

4. Інтеграція з мобільними технологіями.

Адаптуючи сайт під мобільні пристрої, необхідно враховувати можливість смартфона здійснювати дзвінки або відразу переходити з сайту в месенджери. Це багаторазово збільшує конверсію та полегшує клієнту шлях від переходу на сайт до покупки. Ми, як користувачі інтернету, вже звикли, що зателефонувати за номером на сайті або розпочати діалог з компанією в 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 5.5 Що нового.

TypeScript

Предикати типу, що виводиться

Аналіз потоку управління в 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 зробить висновок, що функція повертає предикат типу, якщо виконуються такі умови:

  1. Функція не має явного типу, що повертається або анотації предикату типу.
  2. Функція має один оператор return і неявних повернень немає.
  3. Функція не змінює параметра.
  4. Функція повертає логічний вираз, прив’язаний до уточнення параметра.

Загалом це працює так, як і очікувалося. Ось ще кілька прикладів предикатів типів, що виводяться:

// 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 , це означає, що:

  1. Якщо функція повертає true , x має тип T .
  2. Якщо функція повертає false , то x немає типу 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,

Джерело

Що таке Runes у мережі біткоїну і чим вони відрізняються від BRC-20?

Що таке Runes у мережі біткоїну і чим вони відрізняються від BRC-20?

Що таке Runes?

За останні два роки екосистема біткоїну значно розширилася за рахунок нових активів – взаємо-і незамінних токенів на кшталт BRC-20 і Ordinals. Загальна ринкова капіталізація таких монет подолала рубіж у $2 млрд, дозволивши майнерам заробити багатомільйонні доходи на додаток до нагород за здобутий блок та комісіям за традиційні платежі у цифровому золоті.

Однак невдовзі після своєї появи нові активи зіткнулися із запеклою критикою з боку «біткоін-пуристів» на кшталт розробника Люка Деша — молодшого, який закликав «забанити» BRC-20 та «написи» за допомогою «спам-фільтра».

У вересні 2023 року автор Ordinals Кейсі Родармор представив новий стандарт взаємозамінних токенів – Runes. За словами розробника, такий формат не залишає багато «сміття» у мережі біткоїну, на відміну від BRC-20.

«Засновані наUTXOпротоколи органічно вписуються в блокчейн біткоїну, сприяючи мінімізації зростання невитрачених транзакцій та уникаючи створення їх “сміттєвих” аналогів», – пояснив фахівець.

За його словами, Runes розроблені «для дегенів та мем-коїнів» і призначені для спрощення створення та управління взаємозамінними токенами на блокчейні першої криптовалюти.

«Але протокол простий, ефективний та безпечний. Це повноправний конкурент Taproot Assets та RGB », – написав Родармор на початку квітня.

Запуск Runes відбувся в день четвертого халвінгу – 20 квітня.

Як працює протокол Runes?

Щоб отримати уявлення про принципи роботи Runes, потрібне розуміння ключових термінів:

  • концепція транзакцій біткоїну UTXO;
  • код операції OP_RETURN.

UTXO – система, що дозволяє відстежувати залишки криптовалюти, які ще не були витрачені та можуть бути використані у нових транзакціях.

Кожен невитрачений вихід – кошти, доступні для нових ончейн-операцій. Ця система забезпечує безпеку транзакцій, оскільки кожен UTXO може бути витрачений лише один раз, що запобігає можливості подвійної витрати.

За словами аналітиків CoinGecko, кожен невитрачений вихід може містити будь-яку кількість Runes.

Опкод OP_RETURN дає користувачам можливість прикріплювати довільні дані (до 80 байт) до біткоін-транзакцій без шкоди для ефективності мережі. У випадку Runes інформація про токене записується в окремий вихід, який неможливо витратити.

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

Повідомлення Runes, що зберігаються в сегменті OP_RETURN біткоін-транзакції, також відомі як Runestone. Останні дозволяють створювати та передавати токени в мережі першої криптовалюти.

Кожна транзакція у протоколі може зазначати кілька операцій у різних «рунах». У разі надсилання токена Runes розділить невитрачений вихід транзакції на кілька нових UTXO на основі інструкцій у даних OP_RETURN. Кожен невитрачений вихід представляє різні кількості токенів, які потім надсилаються одержувачам.

Якщо транзакція «фейлиться» через некоректне повідомлення протоколу, «руни» знищуються для запобігання створенню додаткових об’єктів.

Що таке etching та minting?

Завдяки OP_RETURN користувач може здійснювати кілька типів операцій:

  • Etching («травлення») — створення активу та реєстрація його базових параметрів: назва, тикер, обсяг пропозиції, ділимість і т.д. вони стануть доступні широкому загалу;
  • після “травлення” можна згенерувати певну кількість Runes за допомогою відкритого або закритого ” мінтингу” (minting) . Перший варіант дозволяє кожному випускати руни. І тут транзакція мінтингу передбачає створення фіксованого кількості нових активів. Другий сценарій передбачає створення нових токенів лише за виконання певних умов — наприклад, заданого періоду часу. Після завершення емісія обмежується.

Ще одна функція – Edict (“указ”) – визначає правила перекладу Runes після їх “травлення” або “мінтингу”. Наприклад, «указ» дозволяє здійснювати пакетні трансфери активів, аірдропи або передачу всіх випущених «рун» на один рахунок.

Які переваги у Runes?

Виділимо основні позитивні характеристики створеної Родармор системи.

Простота . Runes пропонує користувачам більш зрозумілий спосіб створення токенів, що взаємозаміняються, поверх мережі біткоїну в порівнянні з BRC-20, RGB або Taproot Assets. Користувачі можуть генерувати різні токени та ефективно керувати ними ончейн, не покладаючись на офчейн-дані та не створюючи значної кількості «сміттєвих» UTXO.

Ресурсоефективність . Система не створює невитрачені виходи, які неможливо витратити, а параметри зберігання споживають менше ресурсів. Опкод OP_RETURN займає лише 80 байт, тоді як активи BRC-20 можуть містити до 4 Мб різних даних.

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

Збільшення бази користувача . На думку автора протоколу, основний юзкейс Runes – створення мем-активів. Останні мають чималу популярність у межах поточного ринкового циклу. Глава відділу досліджень Messari Мартьє Бас переконана, що подібні токени «ненавмисно» знайомлять новачків у Web3 з основами криптографічних концепцій, включаючи децентралізовані біржі ( DEX ) та криптогаманці.

Розширення можливостей та екосистеми біткоїну . Аналітики CoinGecko переконані, що різні протоколи, які дозволяють створювати токени в блокчейні першої криптовалюти, приносять користь мережі та екосистемі загалом.

Зокрема, Runes надає можливість проводити транзакції у Lightning Network . Це може активізувати зростання та розвитку мережі мікроплатежів з урахуванням цифрового золота.

Які відмінності у Runes та BRC-20?

Як і BRC-20, Runes дозволяє створювати токени на блокчейні біткоїну. Однак «руни» позиціонуються як покращена система, менш вимоглива до ресурсів мережі першої криптовалюти.

Як розвивається екосистема 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.

Як Runes впливає на екосистему біткоїну?

Експерти 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).

Крім цих алгоритмів у криптовалютах застосовують понад десяток варіантів консенсусу. Перерахуємо деякі з них:

  • Leased Proof of Stake (LPoS) – черговий різновид PoS, де користувачі можуть брати участь у генерації блоків, передаючи токени в лізинг “головним” вузлам. Цей консенсус застосовується в блокчейні Waves;
  • Proof of Elapsed Time (PoET) – доказ часу, що минув. Модифікація PoW використовує потужності CPU. Тут закладено принципи алгоритму справедливої ​​лотереї, де випадково вибирається валідатор пропорційно вкладеним ресурсам. Використовується у рішеннях від Hyperledger;
  • Delegated Byzantine Fault Tolerance (DBFT) – модифікація відразу двох алгоритмів: PBFT та DPoS. Цей варіант досягнення консенсусу застосовують у блокчейні NEO;
  • Directed Acyclic Graphs (DAG) – спрямований ациклічний граф. Це не консенсус, але альтернативна блокчейна технологія. DAG складається з кіл і ліній, а не блоків, і виглядає як граф. Алгоритми консенсусу в таких мережах можуть використовуватися звичні, проте спосіб запису інформації кардинально інший. Одним з таких гібридів є Hashgraph;
  • Proof of Activity (POA) – доказ активності. Використовує гібридний механізм на основі PoW та PoS. Найбільш відомий представник – Decred;
  • Proof of Importance (Pol) — на доказ важливості лежать принципи рейтингової системи. Чим вищий умовний рейтинг валідатора, тим більше шансів знайти блоки. Популярність цього виду консенсусу принесла мережу NEM;
  • Proof of Capacity (PoC) – доказ ємності. Використовує замість обчислювальних ресурсів простір на жорсткому диску. Консенсус застосовується в мережах Chia та BitTorent;
  • Proof-of-Personhood (PoP) – доказ особистості. Використовує механізми підтвердження «людяності», гарантуючи, що кожен учасник проекту отримає рівний голос та винагороду. Флагманом виступає криптовалюта Worldcoin.

Джерело

Навіщо потрібні токени ліквідного рестейкінгу (LRT)?

токени ліквідного рестейкінгу

Що таке токени ліквідного рестейкінгу?

Liquid Restaking Token (LRT) – токен, призначений для отримання додаткової прибутковості шляхом повторного рестейкінгу монет на алгоритмі Proof-of-Stake.

LRT-протоколи використовують безпеку та прибутковість від стейкінгу базового активу плюс можливості додаткових доходів за допомогою DeFi або сервісів активної валідації (Actively Validated Services, AVS), що включають кроссчейн-мости, оракули та сайдчейни.

Концепція LRT-додатків нагадує спільний PoW -майнінг (як, наприклад, при видобутку Dogecoin або Litecoin ), коли те саме обладнання використовується для забезпечення безпеки відразу в двох мережах.

У чому переваги LRT?

Одним із основних способів створення прибутковості для 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.

9 активних пропозицій щодо AVS

Такий підхід підвищує безпеку блокчейна Ethereum через застосування застібаних ETH в системах другого рівня. Наприклад, AVS-рішення від AltLayer дозволяє використовувати LRT для валідації операцій у мережах другого рівня Optimism та Arbitrum.

Ринок можливих механізмів додаткових доходів досі формується. Виплати комісійних можуть формуватись у базовому активі мережі, як це відбувається у LST, у форматі ретродропів за надану ліквідність, а також в інших токенах.

Які ризики несе використання LRT?

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

Складність подібних смарт-контрактів та невипробувана механіка в екстремальних ринкових умовах можуть призвести до виникнення невиявлених чи неврахованих проблем. Перерахуємо основні з можливих:

  • ліквідність. Синтетичні активи, якими є LRT, мають ризик відсутності ліквідності в моменти підвищених стресів на ринку. Як приклад наведемо протокол Renzo, токен якого втратив прив’язку до ефіру після розкриття токеноміки. На Uniswap курс у моменті впав майже на 80% по відношенню до ETH;
  • безліч точок відмови. Багаторівнева екосистема створює ризик виникнення каскаду проблем через «неприємності» навіть на одному рівні або в одного сервісу-посередника;
  • розробка та управління. Загальна складність архітектури примножує всі ризики, притаманні традиційним DeFi-додаткам: помилки в коді, зломи, неефективність управління протоколами.

Як розвивається ринок LRT?

На кінець квітня 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)?

Proof-of-Personhood

Що таке доказ особистості?

У міру розвитку ІІ стає все важливіше розрізняти діяльність, що здійснюється людиною та нейромережею. Для вирішення цього завдання на допомогу може прийти Proof-of-Personhood (PoP), або доказ особистості.

Це механізм, який підтверджує «людяність» (personhood) та унікальність індивідуума. Метод набув поширення через те, що зловмисники створюють безліч підроблених облікових записів для маніпулювання голосуванням або розподілом нагород.

PoP також гарантує, що кожен учасник проекту отримає рівний голос та частку винагороди. Важливо, що, на відміну інших популярних механізмів консенсусу на кшталт докази роботи (Proof-of-Work, PoW) чи докази володіння (Proof-of-Stake, PoS), PoP не розподіляє право голоси чи винагороду пропорційно вкладеним ресурсам.

Необхідність у системах перевірки Proof-of-Personhood обумовлена ​​зокрема загрозами недобросовісного використання технології дипфейк.

Навіщо це потрібно?

Передовий ІІ може стати інструментом, який розширює можливості людини. Але при цьому він уже дає чимало проблем.

  • 2014 рік: атака Сівіли тривалістю п’ять місяців здійснена невідомими в мережі Tor. Пізніше розробники створили програмний засіб, який дозволив знайти безліч вузлів-псевдонімів. Були розкриті схеми перезапису адрес біткоін-гаманців, перенаправлення на фішингові сайти, а також ряд вузлів, які застосовуються для дослідження можливості деанонімізації мережі.
  • 2024: користувач Reddit виграв суперечку, пройшовши верифікацію за допомогою згенерованого зображення. ID-карта була створена ІІ-моделлю Stable Diffusion. Цікаво, що ім’ям згенерованого персонажа було зазначено «Your Mom». Ця технологія викликає особливу тривогу у представників фінансового сектора: за даними The Wall Street Journal, кількість випадків шахрайства з використанням ІІ у 2023 році зросла одразу на 700%.

Вирішити ці проблеми і покликаний Proof-of-Personhood.

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

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

Які існують способи підтвердження особистості?

Доказ особистості може бути використаний для підтвердження людяності різними способами. Ось деякі з найпопулярніших:

Онлайн-тести Тюрінга

В даний час CAPTCHA намагаються обмежити швидкість автоматизованих атак Сівіли, використовуючи автоматичні тести Т’юрінга, щоб відрізнити людину від машини. Незважаючи на частковий успіх цього методу, він, як і раніше, не захищає від того, що одна людина може отримати кілька акаунтів. Для цього лише потрібно вирішити кілька CAPTCHA поспіль.

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

Біометрична верифікація

Спеціалізовані платформи застосовують біометричні методи для верифікації особистості, такі як розпізнавання облич, відбитки пальців, геометрія долоні, сітківка або райдужна оболонка ока та підпис.

Фізичні методи верифікації

Ще один спосіб підтвердження особистості – фізична верифікація, в основному через відвідування заходів. У цьому випадку учасники можуть отримати, наприклад, SBT, що відображають їхній підтверджений статус.

Верифікація через соціальні мережі

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

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

Пов’язана з цим проблема полягає в тому, що алгоритми виявлення Сівілл на основі графів зазвичай здатні знайти лише великі групи, внаслідок чого дрібні атаки важко чи зовсім неможливо виявити.

Гаманці з тимчасовим блокуванням 

Інший підхід до верифікації PoP полягає в тому, що користувачі блокують кошти на певний термін, щоб відстежувати їхню активність протягом часу. Це може бути доказом унікальної поведінки людини, додаючи додатковий рівень перевірки боротьби з атаками Сивиллы. Однак цей метод також не є надійним.

Використання доказів із нульовим розголошенням 

Докази з нульовим розголошенням (Zero-Knowledge Proof, ZKP) дозволяють підтверджувати певні атрибути себе, такі як вік чи національність, не розкриваючи фактичну інформацію. Це може бути реалізовано у децентралізованій системі, учасники якої доводять свою унікальність без розголошення особистих даних.

Які існують проекти PoP?

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

Почасти недавній хайп навколо Worldcoin привернув увагу до PoP, але концепцію не можна назвати новою. 2014 року Віталік Бутерін запропонував розробити «систему унікальної ідентифікації» для криптовалют. Саме з цієї ідеї PoP розвинувся у кілька проектів, які використовують цю технологію.

Серед них:

  • Gitcoin Passport. Проект збирає“марки”з автентифікаторів Web2 і Web3, які є обліковими даними для кросплатформної перевірки особистості без розголошення приватної інформації.
  • Idena. Передбачає участь у грі CAPTCHA у призначений час, щоб запобігти багаторазовій участі.
  • Proof of Humanity. Проект поєднує мережі довіри зі зворотними тестами Тьюринга, реалізує вирішення суперечок та створює список підтверджених користувачів.
  • BrightID. Проводить «верифікаційні вечірки» з відеозв’язку для взаємної верифікації через систему Bitu, яка вимагає, щоб за людину доручилася достатня кількість верифікованих користувачів.
  • World ID проекту Worldcoin. Відкритий протокол ідентифікації, який не вимагає дозволу, анонімно перевіряє особу людини, використовуючи докази нульового знання.

HumanCode. Проект, що пропонує ідентифікувати особу по відбитку долоні та доступний будь-якому користувачеві смартфона. У квітні 2024 року уклав партнерство з TON Society.

Які недоліки у PoP?

Хоча PoP пропонує інноваційні способи підтвердження цифрової ідентичності та аутентифікації, механізм має певні недоліки:

  • проблеми з конфіденційністю та збереженням даних. Хоча ZKP допомагає зняти деякі питання захисту особистих даних, користувачі можуть не наважуватися брати участь у перевірці PoP;
  • вартість та складність. Створення та підтримка децентралізованої системи PoP, яка була б надійною та безпечною, пов’язана з необхідністю залучення великих інвестицій та висококваліфікованих інженерів;
  • погрози кримінального характеру. Біометрика може забезпечити унікальну ідентифікацію, але виникають потенційні ризики, включаючи крадіжку чи неправомірне використання даних;
  • помилки автентифікації. Існує ризикхибнонегативнихабохибнопозитивнихрезультатів, що підриває ефективність та справедливість PoP-платформи.

Джерело

Legacy: переписати не можна підтримувати.

Legacy

Легасі (від англ. Legacy – спадщина) – реальність будь-якого програміста. Пояснюємо, як софт стає легасі і чому це нормально, а також які існують плюси при роботі з легасі. Не завжди варто ставитись до легасі як до прокляття, варто поглянути на нього як на природний етап життєвого циклу програмного забезпечення.

“Легасі” – це слово, яким програмісти лякають один одного (і менеджерів). Воно означає застарілий софт, працювати з яким зазвичай складно та/або неприємно через невеликий «вихлоп» у перерахуванні на зусилля, що вкладаються. Загалом словом «легасі» можна назвати будь-який «код», який складно підтримувати. І чим складніше, тим він «легасі».

Сьогодні розповімо, звідки він береться, як утримувати його «в рамках» і чим він може бути корисним для фахівців-початківців.

Не має значення, як добре і чисто написаний код — рано чи пізно він стане легасі.

А що поганого у «легасі»?

Основні недоліки «легасі» для бізнесу, це:

  • низьке співвідношення користі до вкладених зусиль зміни;
  • повільні зміни;
  • складнощі з підбором команди до роботи над кодом.

Причини, через які з’являється «легасі»

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

До іншої групи можна віднести і низьку культуру чи погану організацію процесу розробки. Так, наприклад, незафіксовані вимоги до програмного продукту можуть призводити до конфліктів між користувачами та розробниками (і навіть усередині групи розробки). У міру розвитку ПЗ необхідно вносити зміни та документацію. Відсутність такої практики призводитиме до тих самих проблем. Користувачі сильно залежатимуть від експертизи розробників. А якщо останні звільняться, то відновлення знань із коду, хоч і можливо, але зазвичай це довгий і трудомісткий процес, в результаті якого залишається багато питань «чому так зробили?» чи «навіщо це?».

  • Невірна архітектура або погано спроектований код провокують написання «милиць» (погане рішення, на момент написання якого ми знаємо, що з ним будуть або можуть бути проблеми в майбутньому, проте яке вирішує проблему «тут і зараз»). Обговоренню архітектури та проектування можна присвятити окрему статтю або навіть книгу, але якщо коротко, то порушення загальноприйнятих практик написання ПЗ, зокрема SOLID, призводитиме до проблем.
  • Обрано невідповідні технології (СУБД, фреймворки, бібліотеки, або сторонні сервіси); не враховано особливості масштабування.
  • Погано написаний код: невиразні назви модулів, класів та змінних, надто довгі функції (без явної необхідності), висока цикломатична складність, дублювання коду.
  • Відсутність тестів (краще автоматизованих, але хоч би ручних) призводить до появи помилок, які неможливо швидко виявити.
  • Погано організований проект: немає системи контролю версій; відсутність задачника (системи фіксації запитів зміни до системи); немає зв’язку між комітами та завданнями (вимогами);
  • Відсутність людей, які мають навичку підтримки коду продукту, також робить код більш «легасі».

Основні причини виникнення легасі: старіння технологій, погані технічні рішення/практики; відсутність вимог/документації; немає людей знайомих із проектом.

Легасі з «позитивним зворотним зв’язком»

Важливою властивістю «легасі» є його розростання. Якщо не докладати зусиль для мінімізації, то з кожною зміною (і навіть без них) рівень «легасі» наростатиме. Як у другому початку термодинаміки, ентропія замкнутої системи не може зменшуватися. Тому нам треба методично «вичерпувати воду з нашого човна, що протікає».

Чому легасі неохоче замінюють

Будь-який софт повинен приносити 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 не принесе стільки вигоди, скільки коштуватиме заміна.

Як боротися з Легасі

  • Виділяти час моніторинг промисловості. Якщо якісь технології чи ПЗ застаріють, треба планувати перехід на нові технології / оновлення ПЗ;
  • Організувати процес розробки так, щоб вимоги були чіткі та зафіксовані в якійсь системі, щоб зміни до коду були прив’язані до цих вимог;
  • Покривати систему тестами;
  • стежити за актуальністю документації;
  • Припиняти розробку та проводити рефакторинг коду у випадках, коли «милиць» стає надто багато (тут важливий баланс, оскільки постійний рефакторинг у боротьбі за «швидкість розробки» забирає час від розробки);
  • Передавати володіння коду від програміста до програміста: 1) більше людей знайомі — менше ризиків, що код залишається безхазяйним; нова людина зможе розібратися;
  • Слідкувати за чистотою коду (як мінімум налаштувати лінтери, проводити ревью).

Користь від Легасі

Отже, «легасі» присутня тією чи іншою мірою у всіх компаніях, де є розробка. То яка ж користь від нього? Для бізнесу користі ніякої немає — за інших рівних, чим більше легасі, тим для компанії гірше, проте зменшення чи підтримка легасі на заданому рівні коштує грошей, тож кожна компанія визначає цей рівень самостійно. (Звичайно ж за формулами вище, а, по інтуїції, але якось визначає).

Однак користь від легасі може бути для співробітників, які з нею працюють. Особливо для новачків, які приходять в компанію. По-перше, рівень зарплати може бути вищим, якщо ви не перший, хто влаштовується працювати з «їх легасі». Компанія може утримувати розробників, щоб їхній код хтось підтримував. По-друге, рівень стресу може бути нижчим, якщо компанія звикла до повільних впроваджень (застереження, не скрізь і не завжди). Плюс сумнівний, але для когось це може здатися комфортнішим місцем. По-третє, є можливість вивчити глибше певні технології, які використовуються в цій компанії — все одно «легасі» вивчати, можна й документацію з технологій почитати. Особливий плюс для джунів, яким потрібне перше місце роботи — якщо в компанії готові їх взяти та допомагати розбиратися з кодом, навіть вирішуючи прості завдання у складній системі — це може бути чудовим стартом кар’єри. Ще один плюс – можна подивитися, як робити НЕ треба;-)

Якщо ви «застрягли» в якійсь технології, не впадайте у відчай, можливо через кілька років, ви станете рідкісним високооплачуваним фахівцем. 🙂

У США ряд старих банківських систем написано на COBOL – застарілій мові програмування. Підтримувати системи треба, а молоді фахівці не бажають вивчати цю мову, тому фахівців не вистачає. Ситуація настільки загострилася, що ентузіаст COBOL створив власну компанію з надання екстреної підтримки банкам та навчання молоді мови, що за ним зробило і IBM.

Загалом від легасі нікуди не дінешся. Воно все одно з’являтиметься і з ним доведеться жити і боротися. Це варто сприймати як дзвінок. Або як нагода, якщо ви ще на старті кар’єри.

Джерело

TAXER: Електронна звітність для підприємців