Проект, який ми сьогодні реалізовуватимемо, має кілька практичних складових:
Так як ми створюємо проект саме як веб-додаток, нам необхідно створити html файл і прописати в ньому:
canvas– це HTML-елемент, який використовується для малювання графіки за допомогою JavaScript;input, необхідний для вибору картинки, що цікавить користувача.<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="lab.css" rel="stylesheet">
<title>3D-Project</title>
</head>
<body>
<canvas id="myscene"></canvas>
<input type="file" id="fileInput" accept="image/*">
<script type="module" src="./lab.js"></script>
</body>
</html>
Почнемо з того, що таке JSON файл.
Файл package.json використовується в проектах JavaScript для керування залежностями, скриптами та метаданими проекту. Він зазвичай створюється в кореневій директорії нашого проекту і містить інформацію про проект, а також про необхідні пакети та команди для його складання та запуску.
Для початку встановіть Node.js, якщо у вас його ще немає, а також встановимо webpack(трохи пізніше він нам знадобиться). Команда для macOS:
brew install node
npm install --save-dev webpack webpack-cli
Після цього ми запускаємо команду npm init -y, яка створює нам файл json із базовими налаштуваннями.
Після цього, ми змінюємо вміст файлу на це:
"name": "назва нашого файлу",
"version": "1.0.0",
"scripts": {
"start": "webpack serve --open",
"build": "webpack"
},
"devDependencies": {
"html-webpack-plugin": "^5.6.2",
"three": "^0.169.0",
"webpack": "^5.95.0",
"webpack-cli": "^5.1.4",
"webpack-dev-server": "^5.1.0"
}
}
Щоб створити конфігураційний файл для Webpack, нам потрібно створити файл з ім’ям webpack.config.js в кореневій директорії нашого проекту. Цей файл міститиме настройки, які Webpack буде використовувати для складання нашого проекту.
const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
entry: './lab.js', // Вказує вхідний файл для збирання
output: {
filename: 'lab.js', // Ім'я вихідного файлу
path: path.resolve(__dirname, 'dist'), // Шлях до вихідної директорії
clean: true, // Очищає вихідну директорію перед кожним збиранням
},
devServer: {
static: {
directory: path.join(__dirname, 'dist'), // Вказує каталог для статичних файлів
},
open: true, // Автоматично відкриває браузер під час запуску сервера
port: 8080, // Порт, на якому буде запущено сервер
},
plugins: [
new HtmlWebpackPlugin({
template: './lab.html', // Шаблон HTML-файла
}),
],
mode: 'development', // Режим збирання (development чи production)
};
Як ви вже зрозуміли з минулого блоку, нам потрібно створити файл lab.js.
Для початку рекомендую в принципі ознайомитися з бібліотекою Three.js на офіційному сайті https://threejs.org. Там чудово описані основні “3 кити Three.js” і є каталог з усіма необхідними методами.
Я постараюся коротко описати всю структуру та математику проекту, тому опишу основний алгоритм виконання:
1) Необхідно завантажити бібліотеку threeтак само через brew;
2) Імпортуємо всі з цієї бібліотеки (це вже прописуємо у файлі) import * as THREE from 'three';;
3) Для можливості маніпулювати надалі картинкою (обертати її), прописуємо:import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js';
4) Створюємо необхідне полотно, де проектуватиметься 3d-фігура:
let canvas = document.getElementById('myscene'); let width = 1400; let height = 800;
5) Створюємо екземпляр рендерингу, задаючи йому значення полотна та згладжування (для 3d графіки дуже важливий аспект).
6) Встановлюємо співвідношення пікселів за допомогою методу setPixelRatio(повертає коефіцієнт пікселів пристрою. Якщо він більше 1 (що означає, що пристрій має високу роздільну здатність), ми встановлюємо співвідношення пікселів в 2, інакше – в 1.). Потім задаємо розміри полотна та його колір
7) Потім створюємо сцену та встановлюємо камеру (це базові налаштування, які можна коригувати залежно від наших переваг, тому розписувати це не буду)
8) Щоб надалі не додавати по одному елементу на сцену, я створюю групу, яка зберігатиме в собі всі елементи мого малювання (далі це допоможе при обертанні та переміщенні всього об’єкта в цілому) let group = new THREE.Group();
9) Далі йде основна частина цієї програми – малювання. У цьому блоці ми звертаємося до елемента inputі задаємо йому функцію із подієм натискання, при якому він запускатиме за фактом весь функціонал нашої програми.
Розпишу це трохи докладніше.
Для початку ми створюємо змінну, яка буде використовується для отримання першого файлу, вибраного користувачем через елемент у HTML.
Після того, як ми переконалися, що файл не порожній, ми починаємо малювання:
const img = new Image();Тут створюється новий об’єкт Image, який буде використовуватись для завантаження зображення.img.onload = function() {
// Код внутри этой функции выполнится, когда изображение будет загружено
};
Цей обробник спрацьовує, коли зображення успішно завантажено. Всередині нього буде виконуватися основний код обробки зображення.
let ctx = canvas2d.getContext('2d');
canvas2d.width = 200;
canvas2d.height = 200;
Тут створюється тимчасовий елемент, який використовується для малювання зображення у 2D. Встановлюються розміри канвасу на 200×200 пікселів.
ctx.drawImage(img, 0, 0, 200, 200);
let data = ctx.getImageData(0, 0, size, size).data;
Зображення малюється на канвасі, а потім виходять дані пікселів за допомогою getImageData. Ці дані містять інформацію про кольори кожного пікселя у форматі RGBA.
group.clear();
Тут очищається група group, щоб видалити попередні об’єкти перед додаванням нових.
for (let i = 0; i < size; ++i) {
let geometry = new THREE.BufferGeometry();
let vertices = new Float32Array(size * 3);
let colors = new Float32Array(size * 3);
У цьому циклі створюється нова геометрія кожного рядка пікселів. Vertices та colors – це масиви, які будуть містити координати вершин та кольору для кожної лінії.
for (let j = 0; j < size; ++j) {
let colorIndex = (j * size + i) * 4;
let r = data[colorIndex] / 255;
let g = data[colorIndex + 1] / 255;
let b = data[colorIndex + 2] / 255;
Внутрішній цикл проходить по кожному пікселю в рядку, витягуючи значення кольору (червоний, зелений, синій) із масиву даних пікселів. Значення нормалізуються, поділяючи на 255.
vertices[j * 3] = j - 100;
vertices[j * 3 + 1] = i - 100;
vertices[j * 3 + 2] = data[colorIndex] / 10;
colors[j * 3] = r;
colors[j * 3 + 1] = g;
colors[j * 3 + 2] = b;
Тут встановлюються координати вершин для 3D-об’єктів. z-координата встановлюється з урахуванням значення червоного каналу, поділеного на 10, щоб створити деяку висоту.
geometry.setAttribute('position', new THREE.BufferAttribute(vertices, 3));
geometry.setAttribute('color', new THREE.BufferAttribute(colors, 3));
let material = new THREE.LineBasicMaterial({ vertexColors: true });
let line = new THREE.Line(geometry, material);
group.add(line);
Після того, як масиви vertices і colors заповнені, вони встановлюються як атрибути геометрії. Потім створюється матеріал з використанням кольорів вершин, лінія додається до групи.
У принципі це все. Нам залишилося завантажити результат в об’єкт imgі відмалювати це все за допомогою функції, яка викликає саму себе та оновлює дані сцени та камери:
function animation() {
requestAnimationFrame(animation);
controls.update();
renderer.render(scene, camera);
}
animation();
Залишилося лише запустити наш проект командоюnpm start
Всі у кого є крипта рано чи пізно замислюются над тим як вивести її у справжні гроші.
Можна обміняти крипту по Р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-модулем.
Доволі таки зручною. Кому цікаво можете зареєструватись тут.
До відома пілся реєстрації надаються невеличкі бонуси. 🙂
У Xcode є симулятор, який можна використовувати для розробки та тестування веб-сайту в оригінальному iOS Safari без використання пристрою.
Щоб використовувати його,
Тепер ви можете відкрити Safari на симульованому iPhone та безпосередньо відвідати свій сайт у розробці, наприклад, через localhost:3000.
Симулятор відтворює важливу поведінку пристрою, тому це набагато краще, ніж використовувати звичайний веб-переглядач, як-от Chrome, для тестування вашого мобільного сайту.
Щоб надати вашій програмі окрему вкладку в перемикачі програм iPhone, а також щоб приховати попередній перегляд посилань та інший інтерфейс, пов’язаний із Safari, потрібно позначити свій веб-сайт як автономну програму.
Щоб зробити це,
site.webmanifestфайл у своєму /publicкаталозі та встановіть автономний режим відображення:
// public/site.webmanifest
{
"display": "standalone"
}
<link>тегу в <head>розділі вашого сайту:
<link rel="manifest" href="/site.webmanifest" />Тепер, коли ваші користувачі відвідують ваш сайт і натискають «Поділитися» > «Додати на головний екран», вони отримають ярлик разом із іншими програмами свого телефону. Натискання цього ярлика відкриє ваш сайт у власному спеціальному контексті програми та вимкне пов’язаний із браузером інтерфейс користувача, як-от кнопки вперед і назад.
За замовчуванням iOS використовуватиме ваш сайт <title>як мітку для ярлика програми, створеного за допомогою кнопки «Додати на головний екран». У файлі веб-маніфесту можна встановити short_name властивість, яку iOS використовуватиме як назву програми:
// public/site.webmanifest
{
"display": "standalone",
"short_name": "Fitness"
}Тепер, коли користувачі додають на головний екран, вони бачитимуть це ім’я за умовчанням.
За замовчуванням 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>тегам ваші користувачі тепер бачитимуть вашу блискучу нову піктограму програми на своєму домашньому екрані, а також повноекранне зображення-заставку, поки браузер завантажуватиме ваш сайт.
За замовчуванням 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, але й будь-яку специфічну форму пристрою, яка потенційно може обрізати наш вміст.
Це, безперечно, кращий підхід, тому дякуємо всім, хто вказав на це!
Зараз наш заголовок прокручується з нашим вмістом. Це виглядає неприродно, коли наш сайт є повноекранною програмою, тому давайте це виправимо.
<header class="fixed">
<!-- ... -->
</header>
<main class="mt-11 pt-safe-top">
<!-- ... -->
</main>Ми також враховуємо додатковий простір із деяким запасом на нашому <main> тегу, а також будь-який додатковий простір для вставок, використовуючи наші блискучі нові safe-*</code >значення інтервалів.
Можливість масштабувати двома пальцями — це те, чого користувачі очікують на веб-сайтах, але зазвичай не в програмах. Ми можемо вимкнути його, оновивши метатег «viewport» за допомогою правила «user-scalable=no»:
<meta
name="viewport"
content="initial-scale=1, viewport-fit=cover, user-scalable=no"
/>Ви можете залишити цей параметр увімкненим, якщо це має сенс для вашої програми, але я помітив, що у своїй програмі ми випадково масштабували її під час навігації, тому програма почувалася краще, коли її вимкнено.
За замовчуванням iOS виділить усі натискання посилань сірим полем, як це робиться для будь-якої веб-сторінки в Safari. Ми можемо встановити це, щоб колір підсвічування став прозорим, використовуючи правило CSS із префіксом постачальника:
body {
-webkit-tap-highlight-color: transparent;
}Тоді ми можемо використовувати стилі фокусування та наведення курсора, щоб надавати нашим користувачам відгук про інтерфейс користувача, який краще відповідає зовнішньому вигляду нашої програми.
Сподіваюся, вам це було корисно! Час вразити друзів своїми блискучими новими мобільними веб-сайтами 🙂
При розробці сайту важливо приділити увагу тому, наскільки він буде зручним та функціональним, відображаючись не тільки на екрані комп’ютера, але й на екранах інших пристроїв. У цій статті ми розповімо, що означає «правильна адаптація» сайту, як саме працює мобільна оптимізація і чим загрожує її відсутність.
Отже, що ми взагалі знаємо, що таке оптимізація? Це процес, при якому 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 пропонує інноваційні способи підтвердження цифрової ідентичності та аутентифікації, механізм має певні недоліки:
Відкрийте криптовалютну картку Trustee за кілька хвилин! Оплачуйте ваші покупки миттєво з автоматичною конвертацією