Що таке Angular Ivy?

Якщо ви останнім часом стежили за розвитком Angular, ви, мабуть, зіткнулися з словом “Ivy”.

За цим кодовим ім’ям ховається величезна робота для Angular team, і крок у майбутнє. Але важко зрозуміти, що таке Ivy. Давайте дізнаємося.

Ваш JS framework є компілятором

Ваш JS framework є компілятором. Це вірно для більшості систем JS, але це особливо актуально для Angular.

У Angular, коли ви пишете компонент, ви пишете компонент в TypeScript і його шаблон в HTML, доповнений синтаксисом Angular template ( ngIf, ngForі т.д.).

Те, що багато розробників не знають, це те, що цей HTML ніколи не буде відображатися у браузері. Він буде скомпільований Angular в інструкції JavaScript, щоб створити відповідний DOM, коли компонент з’явиться на сторінці, і оновити компонент при зміні його стану. Ось чому велика частина Angular є її компілятором: він бере весь ваш HTML і генерує необхідний код JS. Цей компілятор (і час виконання) був повністю переписаний за останній рік, і це є Ivy. Це не перший перезапис: Ivy означає “IV”, 4 – римськими числами. Останнє переписання було зроблено в Angular 4.0, і, можливо, ви навіть не помітили його. Але це, безумовно, найглибше переписування внутрішніх пристроїв з моменту першого випуску Angular: Angular команда буквально змінює двигун (раніше називався View Engine) під час руху.

Цілі Ivy

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

Якщо паралель має певний сенс, він дуже схожий на React і “Fiber rewrite”. React Fiber – це повна переписування внутрішніх елементів React, і особливо пропонується більш інтенсивне візуалізація. Перезапис тривав більше року, і відкрив двері для нових можливостей (наприклад, знамениті Hooks, які були випущені в React 16.8 і які спираються на Fiber).

Angular досягає цього ж з цим зусиллям: Ivy – це повна переписування компілятора (і середовища виконання), щоб:

• Досягнення кращого часу збірки
• Досягнути кращих розмірів збірки
• Неможливо відкрити нові потенційні можливості (метапрограмування або компоненти вищого порядку, ліниве завантаження компонентів замість модулів, нова система виявлення змін, яка не базується на zone.js…)

Ніяких зусиль з вашого боку

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

Але може статися, що Ivy не має точно такої ж поведінки для деяких випадків. Щоб уникнути порушення додатків, коли ми переходимо до Ivy, команда Angular написала сценарії міграції (схеми оновлення), щоб проаналізувати ваш код і підготувати його до Ivy, якщо це необхідно. Таким чином, коли ви будете оновлювати до Angular 8, схеми будуть працювати і налаштувати кілька речей у вашому коді, щоб бути “Ivy-ready”, коли настане час. План полягає в тому, щоб включити Ivy за замовчуванням в майбутньому, можливо, у V9.

Відмінності у створеному коді

Давайте зануримося в подробиці 🤓.

Для компонента PonyComponentз шаблоном:

<figure>
  <img [src]="getPonyImageUrl()">
  <figcaption>{{ ponyModel.name }}</figcaption>
</figure>

Двигун перегляду, движок попереднього Ivy, згенерований код:

function View_PonyComponent() {
  return viewDef([
    elementDef(2, 'figure'),
    elementDef(0, 'img', ['src']),
    elementDef(1, 'figcaption'),
    textDef()
  ], (checkBinding, view) => {
    var component = view.component;
    const currVal_0 = component.getPonyImageUrl();
    checkBinding(view, 1, currVal_0);
    const currVal_1 = component.ponyModel.name;
    checkBinding(view, 4, currVal_1);
  });
}

Це те, що називається ng_factory , функція, що визначає визначення подання з двома частинами:

• статичний опис DOM для створення
• функція, яка викликається, коли стан компонента змінено

Ivy генерує інший код для одного компонента. Спочатку він більше не генерує ng_factory : він вбудовує сформований код в статичне поле. @DirectiveДекоратора стає поле під назвою ngDirectiveDef. @InjectableДекоратора стає полем під назвою ngInjectableDef. @ComponentДекоратора стає поле під назвою ngComponentDef.

Таким чином, наш компонент стає:

class PonyComponent {
  static ngComponentDef = defineComponent({
    type: PonyComponent,
    selectors: [['ns-pony']],
    factory: () => new PonyComponent(),
    // number of elements, templates, content, bound texts to allocate...
    consts: 4,
    vars: 2,
    template: (renderFlags: RenderFlags, component: PonyComponent) => {
      if (renderFlags & RenderFlags.Create) {
        elementStart(0, 'figure');
        element(1, 'img');
        elementStart(2, 'figcaption');
        text(3);
        elementEnd();
        elementEnd();
      }
      if (renderFlags & RenderFlags.Update) {
        select(1)
        property('src', component.getPonyImageUrl());
        select(3)
        textBinding(3, interpolation1('', component.ponyModel.name, ''));
      }
    }
  });
}

Зауважте, що код, створений у templateчастині, має приблизно однакову форму, ніж ng_factory(частина створення та оновлення), але використовує різні інструкції.

Але найбільша різниця – це, мабуть, новий locality principle. Це може мати велике значення при розробці програми Angular та скорочення часу відновлення. Але це також дозволяє відправляти заздалегідь скомпільований код до NPM безпосередньо!

Простіше публікувати

Якщо ви хочете опублікувати Angular бібліотеку на NPM, вам доведеться скомпілювати код TypeScript у JavaScript, а потім запустити компілятор Angular для створення metadata.jsonфайлів.

Потім, коли хтось будував програму з вашою бібліотекою, ng buildбудував ng_factory.jsфайли для ваших компонентів і для компонентів, що надходять з бібліотек. Це означає, що якщо програма використовувала 3 бібліотеки з 10 компонентами кожна, а сама програма мала 50 компонентів, ng buildбуло складено 80 компонентів.

У Ivy, як ви вже зрозуміли, не існує більше ng_factory.jsабо metadata.jsonфайлів. Це означає, що, як автор бібліотеки, ви можете безпосередньо відправити до NPM скомпільований код JS, з результатом компіляції Ivy (зі статичними полями, що генеруються для кожного компонента, директиви, сервісу…).

Потім, коли хтось створює програму з вашою бібліотекою «Ivy-ready», вони не витрачатимуть ресурси на складання компонентів вашої бібліотеки! Це повинно прискорити час відновлення в циклі розробки, коли ми працюємо, ng serveі ми чекаємо перевірки модифікації, яку ми зробили.

(Re) час побудови

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

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

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

Візьмемо приклад з нашим, PonyComponentякий оголошує його вхід таким чином:

@Input('pony') ponyModel: PonyModel;

Зазвичай, властивість ( this.ponyModel) виводиться як вхід з іншим ім’ям ( pony). Тому, коли компонент використовує PonyComponentу своєму шаблоні, він виглядає так:

<ns-pony [pony]="myPony"></ns-pony>

А згенерований код в Ivy, виглядає так:

// ...
  if (renderFlags & RenderFlags.Update) {
    select(0);
    // updates the public `pony` property
    property('pony', component.myPony);
  }
},
directives: [PonyComponent]

Але з видом двигуна виглядав так:

// ...
elementDef(0, 'ns-pony'),
// updates the private `ponyModel` field
directiveDef('PonyComponent', { ponyModel: [0, 'ponyModel'] }
// ...

Можливо, це не схоже на велику різницю, але View Engine посилається лише на приватне поле, а не на його загальнодоступне ім’я.

Це принцип місцевості. Щоб скомпілювати AppComponentцей PonyComponentшаблон, Ivy не знає нічого про компонент pony. Висновок компілятора Ivy Appcomponent залежить тільки від коду AppComponent.

Це було невірно в ViewEngine, де код, згенерований для, AppComponent також залежав від коду PonyComponent (в даному прикладі, від імені поля, що ponyModelпідтримує вхід pony).

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

Трохи дрібниць історії Angular: модулі були введені досить недавно в розвитку Angular, всього за кілька місяців до стабільного випуску. Раніше під час бета-фази 2.0 ви повинні були вручну посилатися на кожен компонент і директиву, що використовуються в компоненті, безпосередньо в декораторі. Модулі були введені, щоб уникнути цього, але недоліком було те, що він став найменшою одиницею компіляції: зміна одного елемента модуля призводить до перекомпіляції всіх елементів модуля. Ви можете побачити, як код, згенерований в Ivy, повертає нас до того, що було спочатку розроблено командою Angular, з directivesвластивістю, сформованою в ngComponentDefполі.

Розміри пакетів

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

Ось чому команда очікує великих поліпшень розмірів невеликих додатків, а особливо програми Hello World (яка раніше виробляла великий пакет для Hello World), або для Angular Element .

Для середніх і великих додатків ситуація не повинна сильно змінитися з першим випуском Ivy. Пакети повинні мати приблизно однакові розміри (або навіть трохи більші), як і з View Engine. Команда Angular встигне зосередитися на цьому, коли вони впевнені, що немає регресії з Ivy, і ми можемо сподіватися на менші пачки в кожному випадку в майбутньому.

Час виконання

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

Ivy відкриває кілька можливостей для майбутнього. Тепер має бути можливим запускати додаток без zone.js і вручну управляти виявленням змін (подібно до React). Ці API вже існують, але є експериментальними, не задокументованими і, ймовірно, зміниться найближчим часом.

Краща перевірка типу шаблону

Кутове компілятор має варіант , який часто упускається з виду , на мій погляд: fullTemplateTypeCheck. Якщо увімкнено, компілятор намагається глибше аналізувати шаблони. Я показав деякі приклади того, на що він здатний, коли він був введений в Angular 5 . Ця опція в даний час більш потужна в Ivy, і, ймовірно, буде ще більш потужним в майбутньому.

Наприклад, однією з функцій, які вже доступні в Ivy, є перевірка типу компонентних і директивних входів. Уявіть собі, ImageComponentщо вхід називається sizeтипом number. Якщо інший компонент використовує ImageComponentі намагається передати логічне значення в sizeвласність, ви побачите повідомлення про помилку: Type 'boolean' is not assignable to type 'number'..

Це лише приклад того, на що Ivy буде здатна, і ці функції дуже цікаві для великих додатків.

Зворотна сумісність

Я пояснив, що компілятор Ivy приймає декоратори в коді TypeScript, а потім генерує статичне поле в класі. Але поточні бібліотеки, що поставляються на NPM, більше не мають свого декоратора, вони зазвичай відправляють код JavaScript, отриманий в результаті компіляції. А Ivy потрібні ці статичні поля для правильної роботи, так що ми застрягли, поки кожна бібліотека, яку ми використовуємо, не поставила нову версію?

Команда Angular створила компілятор сумісності ngcc. Цей компілятор має одне важливе завдання: він приймає node_modulesвашу програму, шукає кутові бібліотеки, читає їхні metadata.jsonфайли і код JS, і виводить той самий код JS, але з статичними полями, яким потрібно Ivy!

Це справді вражаючий інженерний пристрій, в основному прихований від наших очей, оскільки він безпосередньо вбудований в CLI. Так що в перший раз ви будете працювати ng serveабо ng build, ви помітите, завдання займає більше часу, ніж зазвичай, як ngccі робити свою магію за лаштунками. Але не бійтеся: це треба робити тільки один раз, а потім він знову не запуститься (за винятком випадків, коли ви додаєте до вашої програми іншу бібліотеку Angular).

Майбутні можливості

Angular 8.0 – перший крок для Ivy. Коли він буде достатньо стабільним, він стане типовим. І тоді команда може почати працювати над додаванням інших функцій легше. Як сервіс i18n , можливо, одна з найбільш очікуваних функцій. Або можливість мати метапрограмування або компоненти вищого порядку . Або ліниво-завантажувати один компонент замість модуля. Або мати компоненти JiT і компоненти AoT працювати один з одним. Або створити шаблон вручну, написавши вручну згенеровані інструкції, щоб вичавити найкращі показники. І, мабуть, тонни інших ідей, яких команда має, і про які ще не говорили.

Я сподіваюся, що це трохи роз’яснило, про що Ivy, і що ви спробуєте в наступні місяці!

Переклад статті “What is Angular Ivy?“

Що нового в Angular 8.0?

Angular 8.0 має трохи більше мій код, ніж інші випуски 😊.

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

TypeScript 3.4

Angular 8.0 тепер підтримує TypeScript 3.4 і навіть вимагає його, тому вам потрібно оновити.

Ви можете перевірити, що надає TypeScript 3.3 і TypeScript 3.4 у блозі Microsoft.

Ivy

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

TL; DR: Ivy – новий компілятор / час виконання Angular. В майбутньому він дозволить створити дуже цікаві функції, але наразі він зосереджен на не порушенні існуючих програм.

Angular 8.0 – це перший реліз, який офіційно пропонує перейти до входу в Ivy. Зараз немає реальних переваг для цього, але ви можете дати йому спробу побачити, чи нічого не руйнуеться у вашій програмі. Тому що в певний момент, ймовірно, в v9, Ivy буде за замовчуванням. Отже, команда Angular сподівається, що громада очікує на перемикання та надасть зворотній зв’язок, і що ми розглянемо всі інші питання до v9.

Ми спробували його на декількох наших програмах і вже потрапили до декількох регресій, тому ми настійно рекомендуємо не використовувати його сліпо у виробництві.

Якщо ви відчуваєте пригоди, ви можете додати "enableIvy": trueу свій angularCompilerOptionsі перезапустити програму: вона тепер використовує Ivy! Перегляньте статтю та офіційний довідник для отримання додаткової інформації .

Підтримка Bazel

Що стосується Ivyб ми написали спеціальну статтю про те, як створити ваші програми Angular з новою підтримкою Bazel 🛠.

Форми

markallastouched

AbstractControlКлас пропонує новий метод markAllAsTouched на додаток до існуючих markAsDirty, markAsTouched, markAsPendingі т.д. AbstractControlє батьківським класом FormGroup, FormControl, FormArray, тому метод доступний на всіх реактивних форм юридичних осіб.

Як markAsTouched, цей новий метод позначає контроль як touched і його нащадків.

form.markAllAsTouched();

FormArray.clear

FormArrayКлас тепер також пропонує clearспосіб, щоб швидко видалити всі елементи управління , які він містить. Раніше вам довелося прокрутити елементи керування, щоб видалити їх по одному.

// `users` is initialized with 2 users
const users = fb.array([user1, user2]);
users.clear();
// users is now empty

Router

Lazy-loading з синтаксисом import()

Новий синтаксис був введений для оголошення маршрутів import()із зайвим завантаженням, використовуючи синтаксис з TypeScript (введений у TypeScript 2.4 .

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

Таким чином, ви можете змінити свої loadChildrenдекларації з:

loadChildren: './admin/admin.module#AdminModule'

до:

loadChildren: () => import('./races/races.module').then(m => m.RacesModule)

Схема, запропонована CLI, автоматично мігрує ваші декларації для вас, тому це має бути безболісним, якщо ви запускаєте ng update @angular/cli. Перегляньте нашу статтю про Angular CLI 8.0, щоб дізнатися більше про це.

Location

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

PlatformLocationтепер пропонує доступ до hostname, port і protocol, а новий getState()метод дозволяє отримати history.state. MockPlatformLocationТакож доступна для полегшення тестування. Все це дійсно корисно, якщо ви використовуєте ngUpgrade, інакше вам, мабуть, це не знадобиться.

Service worker

Стратегія реєстрації

Реєстрація Service worker має новий варіант, який дозволяє уточнити, коли має відбутися реєстрація. Раніше Service worker очікував на стабільність програми для реєстрації, щоб уникнути уповільнення запуску програми. Але якщо ви починали повторювану асинхронну задачу (наприклад, процес опитування) на початковому завантаженні програми, то програма ніколи не була стабільною, оскільки Angular вважає програму стабільною, якщо відсутня завдання. Так що Service worker ніколи не реєструвався, і вам довелося вручну обійти його. За допомогою нової registrationStrategyопції ви можете дозволити Angular впоратися з цим. Можливі кілька значень:

• registerWhenStable, за замовчуванням, як описано вище
• registerImmediately, який не чекає, поки програма стане стабільною, і відразу реєструє Service worker
• registerDelay:$TIMEOUTз $TIMEOUTчислом мілісекунд очікування перед реєстрацією
• функція, що повертає Observable, для визначення користувацької стратегії. Потім Service worker реєструватиметься, коли об’єкт спостереження випускає своє перше значення.

Наприклад, якщо ви бажаєте зареєструвати Service worker через 2 секунди:

providers: [
  ServiceWorkerModule.register('/ngsw-worker.js', {
    enabled: environment.production,
    registrationStrategy: 'registerDelay:2000'
  }),
  // ...
]

Обхід Service worker

Тепер можна також обходити Service worker для окремого запиту, додавши ngsw-bypassзаголовок.

this.http.get('api/users', { headers: { 'ngsw-bypass': true } });

Кілька додатків на субдоменах

Раніше було неможливо мати декілька додатків, що використовувалися @angular/service-workerна різних підпрограмах одного і того ж домену, тому що коженService worker перезапише кеші інших… Це тепер виправлено!

Notable і breaking зміни

Кілька речей змінилися і вимагають певної роботи з вашої сторони. Деякі зміни керуються Ivy, і вони знаходяться там для підготовки наших додатків. Але приємна новина полягає в тому, що Angular команда вже написала схеми, щоб полегшити наше життя.

Просто запустіть ng update @angular/core і схеми оновлять ваш код. Що роблять ці схеми? Давай дізнаємось!

Час запитів

В ViewChildі ContentChildдекоратори повинні тепер мати новий варіант називається static. Дозвольте мені пояснити, чому з дуже простим прикладом ViewChild:

<div *ngIf="true">
  <div #dynamicDiv>dynamic</div>
</div>

Давайте зробимо цей елемент в нашому компоненті і занотуємо його в гаки життєвого циклу ngOnInit і ngAfterViewInit:

@ViewChild('dynamicDiv') dynamicDiv: ElementRef<HTMLDivElement>;

ngOnInit() {
  console.log('init dynamic', this.dynamicDiv); // undefined
}

ngAfterViewInit() {
  console.log('after view init dynamic', this.dynamicDiv); // div
}

Має сенс, коли AfterViewInit викликається, коли виконується ініціалізація шаблону.

Але насправді, якщо запитуваний елемент є статичним (не загорнутий в ngIfані ngFor), то він доступний ngOnInitтакож:

<h1 #staticDiv>static</h1>

дає:

@ViewChild('staticDiv') staticDiv: ElementRef<HTMLDivElement>;

ngOnInit() {
  console.log('init static', this.staticDiv); // div
}

ngAfterViewInit() {
  console.log('after view init static', this.staticDiv); // div
}

Це не було задокументовано або рекомендовано, але саме так він працює.

Хоча з Ivy, поведінка змінюється більш послідовно:

ngOnInit() {
  console.log('init static', this.staticDiv); // undefined (changed)
}

ngAfterViewInit() {
  console.log('after view init static', this.staticDiv); // div
}

Введено новий static прапор, щоб не порушувати існуючі програми, тому, якщо ви хочете зберегти стару поведінку, навіть коли ви перейдете на Ivy, ви можете написати:

@ViewChild('static', { static: true }) static: ElementRef<HTMLDivElement>;

і поведінка буде такою ж, як і поточна (елемент також доступний ngOnInit).

Зверніть увагу, що якщо ви додасте static: true на динамічний елемент (загорнутий у стан або цикл), то він не буде доступний ngOnInit ні в, ні в ngAfterViewInit!

static: false буде як Ivy поводиться за замовчуванням.

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

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

Перша стратегія використовується за замовчуванням при запуску, ng updateоскільки вона є найбезпечнішою, але ви можете спробувати використати стратегію використання NG_STATIC_QUERY_USAGE_STRATEGY=true ng update.

Додаткову інформацію можна отримати в офіційному довіднику .

Так виглядає міграція (з помилкою в одному компоненті):

------ Static Query Migration ------
With Angular version 8, developers need to
explicitly specify the timing of ViewChild and
ContentChild queries. Read more about this here:
https://v8.angular.io/guide/static-query-migration

Some queries could not be migrated automatically. Please go
those manually and apply the appropriate timing.
For more info on how to choose a flag, please see:
https://v8.angular.io/guide/static-query-migration
⮑   home/home.component.ts@43:3: undefined

Зауважимо, що це стосується тільки ViewChildі ContentChild, а не ViewChildrenі ContentChildren (яке буде працювати так само в Ivy і View Engine).

Перепризначення змінної шаблону

Наразі з інструментом “Перегляд” виконуються такі дії:

<button
  *ngFor="let option of options"
  (click)="option = 'newButtonText'">{{ option }}</button>

працює.

У Ivy, це не буде так: більше не буде можливо перепризначити значення змінної шаблону (тут option). Щоб підготувати комутатор до Ivy, схема аналізує ваші шаблони під час оновлення до Angular 8.0 і попереджає вас, якщо це так.

Потім її потрібно вручну виправити:

<button
  *ngFor="let option of options; index as index"
  (click)="options[index] = 'newButtonText'">{{ option }}</button>

ДОКУМЕНТ

DOCUMENTМаркер переміщається від @angular/platform-browserв @angular/common. Ви можете вручну змінити його у вашій програмі, але надана схема буде подбати про неї.

Застарілий пакет webworker

@angular/platform-webworkerПакет включено працює вашому Angular додатоку в Web Worker. Оскільки це виявилося складнішим, ніж очікувалося (для побудови програми, SEO…), і не дуже добре, продукти були застарілими і будуть видалені в майбутньому.

Заборонений пакет HTTP видалено

@angular/httpбуло видалено з 8.0, після заміни @angular/common/httpв 4.3 і офіційно застаріло в 5.0 , 18 місяців тому. Ви, напевно, вже перенесли на @angular/common/http, але якщо ви цього не зробили, тепер вам доведеться: надана схема буде лише видалити залежність від вашого package.json.

Ви також можете знайти всі застарілі API у офіційному довіднику знецінення .

Це все для Angular 8.0! Ви можете переглянути наші інші статті про Ivy , випуск CLI 8.0 або нову підтримку Bazel .

Переклад статті “What’s new in Angular 8.0?“

Інструменти доступності кольорового контрасту

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

Спочатку це Accessible Color Generator, який є чудовим інструментом для вибору альтернативних кольорів. Припустимо, ви працюєте над торговою маркою з кольором X. Ви можете створити безліч інших безкоштовних кольорів, наприклад:

Далі йде Contrast, досить великий додаток MacOS, який постійно знаходиться в рядку меню і допомагає визначити доступні сполучення кольорів на основі Керівництва WCAG. Це особливо корисно, якщо ви є дизайнером:

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

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

Потім команда пішла вперед і побудувала ColorBox.io, яка дозволяє систематично вибудовувати тонну кольорів для роботи дизайнерських систем. Це досить здорово!

Плюс люди на GOV.UK зробили свій власний інструмент доступності кольору під назвою Contrast Checker, який (як ви здогадалися за назвою) допомагає перевірити контраст між фоном елемента і самою сторінкою

І, звичайно, є надійний WebAIM contrast checker, який є для багатьох розробників.

Поки що ми розглянули інструменти, які перевіряють контраст. Але є клас інструментів, який може автоматизувати доступні контрасти під час розробки. Джош Бадер написав підхід, який забезпечує високу контрастність, об’єднуючи власні властивості CSS з calc() функцією. Факундо Коррадіні зробив щось подібне, що перемикає колір шрифту на основі фонового кольору за ним.

О! Іми можемо щось з нетерпінням чекати з color-adjustмайном. Він пропонується в специфікації CSS Color Module Level 4 і може дати браузерам більше контролю для налаштування значень кольорів, які оголошені в таблиці стилів. Це насправді не спрямоване на колірний контраст, але є щось цікаве про передачу відповідальності за надання кольорових значень браузеру на основі певних умов.

Переклад статті “Color contrast accessibility tools“

Підвищуємо продуктивність на GitHub

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

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

Швидкий пошук файлів в репозиторіях

Це один з найбільш швидких методів пошуку файлів – правда, лише тоді, коли ви знаєте, що шукаєте. Відкрийте будь-який репозиторій і натисніть T. Тепер ви можете шукати файли за назвою, для зручності використовуючи кнопки напрямки своєї клавіатури. Для відкриття файлу натискаємо Enter.

Pull request, пропозиції щодо зміни коду

Для pull request передбачена відмінна функція Suggested Changes. Якщо внести свою пропозицію, то автор коду, вирішивши прийняти вашу правку, може це зробити натисканням кнопки, не залишаючи GitHub. Для того, щоб внести свою пропозицію, необхідно обгорнути сниппет з кодом markdown сніпетів і вибрати тег suggestion.

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

Навігація як в IDE

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

Особливо корисним Octotree буде, якщо ви вивчаєте масштабний проект з великою кількістю вкладених директорій. Для отримання метаданих використовується GitHub API.

Підтримуються і приватні репозиторії (інструкції по використанню – тут). Крім того, підтримується GitHub Enterprise.

Перехід до функції при рев’ю коду

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

Створення постійної посилання для файлу

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

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

Git blame і heatmap

При перегляді файлу натисніть B – і побачите Git blame і недавно змінені рядки. Інструмент показує, хто автор змін, також ви отримуєте клікабельним лінк з відсиланням до повного коммітов, частина змін якого переглядаєте.

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

Потужний пошук коду

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

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

Збережені відповіді

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

Навіть мишею можна не користуватися, просто використовуючи поєднання ctrl + / і ctrl + 1.

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

Переклад статті “How to be more productive on GitHub“

Все, що потрібно знати про помилку ‘ExpressionChangedAfterItHasBeenCheckedError’

Схоже, що останнім часом майже кожен день виникає питання на stackoverflow щодо ExpressionChangedAfterItHasBeenCheckedError помилки, що видає Angular. Зазвичай ці питання виникають тому, що розробники Angular не розуміють, як працює виявлення змін і чому необхідна перевірка, яка дає цю помилку. Багато розробників навіть розглядають це як помилку. Але це, звичайно, не так. Це запобіжний механізм, який запобігає невідповідності даних моделей та інтерфейсу користувача, щоб помилкові або старі дані не відображалися користувачеві на сторінці.

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

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

Відповідні операції виявлення змін

Запуск програми Angular – дерево компонентів. Під час виявлення змін Angular виконує перевірку для кожного компонента, який складається з наступних операцій, що виконуються в заданому порядку:

1. оновлювати прив’язані властивості для всіх дочірніх компонентів / директив
2. виклик ngOnInit, OnChanges а також ngDoCheck гаки життєвого циклу для всіх дочірніх компонентів / директив
3. оновлення DOM для поточного компонента
4. виявлення змін для дочірнього компонента
5. називати ngAfterViewInit гачок життєвого циклу для всіх дочірніх компонентів / директив

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

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

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

Подивимося приклад. Припустимо, що у вас є батьківський компонент A і дочірній компонент B. A Компонент має name і text властивість. У його шаблоні використовується вираз, що посилається на name властивість:

template: '<span> {{name}} </span>'

І він також має B компонент у своєму шаблоні і передає text властивість цьому компоненту через вхідну властивість:

@Component({
    selector: 'a-comp',
    template: `
        <span>{{name}}</span>
        <b-comp [text]="text"></b-comp>
    `
})
export class AComponent {
    name = 'I am A component';
    text = 'A message for the child component`;

Так ось що відбувається, коли Angular запускає виявлення змін. Починається перевірка A компонента. Перша операція в списку полягає в оновленні прив’язки, тому вона оцінює text вираз A message for the child component і передає її на B компонент. Він також зберігає це значення в перегляді:

view.oldValues[0] = 'A message for the child component';

Потім він називає гаки життєвого циклу, згадані в списку.

Тепер він виконує третю операцію і порівнює вираз {{name}} та текст I am A component. Він оновлює DOM за допомогою цього значення та додає оцінене значення до oldValues:

view.oldValues[1] = 'I am A component';

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

Якщо Angular виконується в режимі розробки, він запускає другий дайджест, виконуючи операції перевірки, перераховані вище. Тепер уявіть собі, що як-то властивість text було оновлено в A компоненті до updated text після Angular передає значення A message for the child component в B компонент і зберігатє його. Таким чином, тепер він запускає перевірку дайджесту і перша операція полягає в тому, щоб перевірити, що властивість text не змінюється:

AComponentView.instance.text === view.oldValues[0]; // false
'A message for the child component' === 'updated text'; // false

І все ж зміна є і тому Angular викидає помилку ExpressionChangedAfterItHasBeenCheckedError.

Те ж саме для третьої операції. Якщо name властивість було оновлено після рендеринга в DOM і збережено, ми отримаємо таку ж помилку:

AComponentView.instance.name === view.oldValues[1]; // false
'I am A component' === 'updated name'; // false

У вас, напевно, виникає запитання, як можна змінити ці значення. Подивимося це.

Причини зміни значеннь

Винуватцем завжди є дочірній компонент або директива. Давайте зробимо швидку просту демонстрацію. Я буду використовувати найпростіший приклад, як тільки можливо, але після цього я покажу реальні сценарії. Ви, напевно, знаєте, що дочірні компоненти та директиви можуть вводити свої батьківські компоненти. Отже, давайте зробимо наш B компонент ін’єкційним батьківським A компонентом і оновлюємо пов’язану властивість text. Ми оновлюватимемо властивість у ngOnInit гачку життєвого циклу, оскільки вона спрацьовує після обробки прив’язок, яка показана тут:

export class BComponent {
    @Input() text;

    constructor(private parent: AppComponent) {}

    ngOnInit() {
        this.parent.text = 'updated text';
    }
}

І, як очікується, ми отримаємо помилку:

Error: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'A message for the child component'. Current value: 'updated text'.

Тепер давайте зробимо те ж саме для властивості, name яка використовується у виразі шаблону батьківського A компонента:

ngOnInit() {
    this.parent.name = 'updated name';
}

А тепер все працює нормально. Як?

Якщо ви уважно подивитеся на порядок операцій, ви побачите, що ngOnInit гачок життєвого циклу спрацьовує перед операцією оновлення DOM. Тому немає помилок. Нам потрібен гачок, який викликається після операцій оновлення DOM, і ngAfterViewInit це хороший кандидат:

export class BComponent {
    @Input() text;

    constructor(private parent: AppComponent) {}

    ngAfterViewInit() {
        this.parent.name = 'updated name';
    }
}

І на цей раз ми отримуємо очікувану помилку:

AppComponent.ngfactory.js:8 ERROR Error: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'I am A component'. Current value: 'updated name'.

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

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

Спільний сервіс

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

Трансляція синхронних подій

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

Динамічна реалізація компонентів

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

Можливі виправлення

Якщо ви подивитеся на опис помилки, в останньому реченні сказано наступне:

Expression has changed after it was checked. Previous value:… Has it been created in a change detection hook?

Часто виправлення полягає у використанні гачка для виявлення відповідних змін для створення динамічної складової. Наприклад, останній приклад у попередньому розділі з динамічними компонентами можна виправити, перемістивши створення компонента на& ngOnInit гачок. Хоча в документації зазначається, що ViewChild доступна тільки після ngAfterViewInit, вона заповнює дітей при створенні перегляду і тому вони доступні раніше.

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

Асинхронне оновлення

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

Протестуємо:

export class BComponent {
    name = 'I am B component';
    @Input() text;

    constructor(private parent: AppComponent) {}

    ngOnInit() {
        setTimeout(() => {
            this.parent.text = 'updated text';
        });
    }

    ngAfterViewInit() {
        setTimeout(() => {
            this.parent.name = 'updated name';
        });
    }
}

Дійсно, помилка не викидається. У setTimeout розкладі функції а макрозавдання потім буде виконано в наступному VM черзі.

Також можливо виконати оновлення в поточному повороті віртуальної машини, але після того, як поточний синхронний код закінчився, використовуючи then зворотний виклик promise:

Promise.resolve(null).then(() => this.parent.name = 'updated name');

Замість макрозавдання Promise.then створюється мікрзавдання. Черга мікрозавданнь обробляється після завершення поточного синхронного коду, тому оновлення властивості відбудеться після кроку перевірки. Щоб дізнатися більше про мікро- та макро-завданнях у Angular, ви можете прочитати I reverse-engineered Zones (zone.js) and here is what I’ve found.

Якщо ви використовуєте, EventEmitter ви можете передати true опцію асинхронно:

new EventEmitter (true);

Примусове виявлення змін

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

export class AppComponent {
    name = 'I am A component';
    text = 'A message for the child component';

    constructor(private cd: ChangeDetectorRef) {
    }

    ngAfterViewInit() {
        this.cd.detectChanges();
    }

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

Чому нам потрібний цикл верифікації

Angular накладає так званий ;unidirectional data flow from top to bottom. Жоден компонент нижчий в ієрархії не дозволяється оновлювати властивості батьківського компонента після обробки батьківських змін. Це гарантує, що після першого циклу переривання все дерево компонентів буде стабільним. Дерево нестійке, якщо є зміни властивостей, які потрібно синхронізувати з споживачами, які залежать від цих властивостей. У нашому випадку дочірній B компонент залежить від батьківської text властивості. Всякий раз, коли ці властивості змінюють дерево компонентів, стає нестабільним, поки ця зміна не буде передано до дитини B компоненту. Те ж саме стосується і DOM. Вона є споживачем деяких властивостей компонента і передає їх на інтерфейс користувача. Якщо деякі властивості не синхронізовані, користувач побачить неправильну інформацію на сторінці.

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

Так чому б не запустити виявлення змін, поки дерево компонентів не стабілізується? Відповідь проста – тому що вона ніколи не може стабілізуватися і працюватиме назавжди. Якщо дочірній компонент оновлює властивість батьківського компонента як реакцію на цю зміну властивості, ви отримаєте нескінченний цикл. Звичайно, як я вже говорив раніше, тривіально виявити таку картину з прямим оновленням або залежністю, але в реальному застосуванні як оновлення, так і залежність зазвичай непрямі.

Цікаво, що AngularJS не мав односпрямованого потоку даних, тому він намагався стабілізувати дерево. Але це часто призводило до сумнозвісної 10 $digest() iterations reached. Aborting! помилки. Виконайте цю помилку, і ви будете здивовані кількістю питань, які виникли у цій помилці.

Останнє питання, яке ви можете мати, чому це запускається тільки в режимі розробки? Я думаю, це тому, що нестабільна модель не є такою драматичною проблемою, як помилка під час виконання, яку створює фреймворк. Адже вона може стабілізуватися в наступному запуску. Однак краще отримувати повідомлення про можливу помилку при розробці програми, ніж налагоджувати запущену програму на стороні клієнта.

Переклад статті “Everything you need to know about the `ExpressionChangedAfterItHasBeenCheckedError` error“

Blockstream розробив нову мову програмування смарт-контрактів – Simplicity

Компанія Blockstream, що спеціалізується на блокчейн- і біткойн-розробках, опублікувала початковий код Simplicity – нової мови програмування для створення смарт-контрактів. Мета розробки полягає в створенні ефективної альтернативи існуючим мовам для роботи з блокчейном. Simplicity пропонує більш просунуті комплексні рішення, у порівнянні з Bitcoin Script і велику гнучкість, ніж Solidity Ефіріума.

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

Simplicity значно перевершує по функціоналу скриптову мову біткойнов і за можливостями більше нагадує Java або Python. Simplicity також надає можливість змінювати код смарт-контракту, після його активації. Це серйозний прорив, так як основна проблема існуючих смарт-контрактів на Solidity полягає в їх незмінності, навіть в разі виявлення помилки. З новою архітектурою у розробників з’явиться можливість змінювати контракти за умови досягнення консенсусу.

Серед інших важливих особливостей Simplicity можна відзначити:

• Simplicity є Тьюринг-неповною мовою;
• Можливість реалізації кінцевих автоматів;
• Органиченно рекурсії, захист від нескінченних циклів;
• Можливість статичного аналізу коду;
• Підтримка формальної семантики, формальної верифікації;
• Інтеграція мерклізованних абстрактних синтаксичних дерев (MAST), Simplicity має вбудовану підтримку MAST;

Джерело

Ходлери – революціонери.

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

На початку змін патріоти завжди рідкісні. Їх ненавидять і зневажають. Але коли справа патріотів вдається, боязкі охоче приєднуються до них, тому що тоді їм нічого не варто бути патріотом – Марк Твен.

Сатоши опублікував білу книгу біткойнов 31 жовтня 2008 року – через місяць після того, як банкрутство Lehman Brothers похитнуло всю фінансову систему. Біткойн з’явився тоді, коли він був вкрай необхідний – в той час, коли в світі, побудованому на довірі, можливість довіри виявилася втрачена.

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

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

Час, в якому ми живемо, унікален, тому що ніколи ще така кількість країн не існувала так довго без профіциту бюджету. Наприклад, в США дефіцит спостерігається протягом 40 з останніх 44 років (включаючи 2012 рік).

До початку XX століття прості люди завжди могли переключитися на тверду валюту (золото), щоб убезпечити себе від наслідків провальної інфляційної політики центрального банку. Більшість країн світу припинили цю практику у XX столітті. Ніколи раніше така кількість країн не відмовлялася від валюти на базі дорогоцінних металів на такий довгий термін. Закон про золотий стандарт, прийнятий в 1971 році, дозволив створити умови для практично необмеженого потенціалу кредитування і утворення боргу, що для економічної історії було безпрецедентним явищем.

Через 41 рік використання фіатной валюти, з безпрецедентною сумою боргу, який дуже складно погасити, ми вступаємо на незвідану територію.

Біткойн був створений для побудови нової фінансової системи, яка не вимагала б довіри і дотримувалася б принципів стійких грошей. Чому стійкі тверді валюти настільки важливі?

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

І знову фінансова система була дискредитована … але повстання американської молоді проти культури грошей так і не сталося – Майкл Люіс “Велика гра на пониження. Таємні пружини фінансової катастрофи”.

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

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

Сатоши хотів запустити мережу з механізмом заохочення учасників мережі – винагородою за блок. Таке заохочення допомогло б (а) контролювати обсяг пропозиції токенов біткойнов і (б) створити стимули для користувачів брати участь в роботі мережі.

Ходлінг допоміг біткойн народитися. Ходлінг збільшує вартість Койнів, що збільшує попит на них, хешрейт і безпеку мережі, що в свою чергу приваблює нових Ходлер і розробників. Цей самореалізуємий зворотний зв’язок забезпечує мережеві ефекти, безпеку і цінність біткойнов – @TobiasAHuber

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

Не кажіть мені, що ви думаєте краще просто покажіть мені своє портфоліо – @nntaleb

Володіння біткойнами – це повна протилежність спекуляцій. Торгівлю можна назвати спекулятивною, коли стимули для купівлі та продажу засновані виключно на ринкових настроях. Ви сподіваєтеся продати продукт, незважаючи на те, що він не придбав жодної внутрішньої цінності для суспільства за той час, поки ви ним володієте. У володіння грошима немає цього недоліку, скоріше навпаки. Володіючи грошима, ви вкладаєте в економіку в цілому. Кожен раз, коли ви вирішуєте зберегти гроші, ви скорочуєте доступну в зверненні грошову масу … Це призводить до збільшення купівельної спроможності за одиницю цих грошей. В результаті ціни в цій валюті знижуються, і всі учасники цієї економіки стають багатшими. Утримуючи біткойни, ви збільшуєте їх ціну. Чим більше людей буде інвестувати свої кошти в біткойни на тривалий термін, тим швидше його волатильність поступиться місцем поступового зростання в ціні. Ця тенденція до стабільного підвищення вартості токенов робить біткойн більш привабливим для нових користувачів, створюючи цикл зворотного зв’язку –Willem_VdBergh.

Збільшення вартості біткойнів веде до більш активного його поширення. І в міру його поширення ходлінг стає популярним також серед людей з більш низькою схильністю до ризику, що забезпечує для біткойнів ще більший мережевий ефект – @robustus

З кожним таким злетом і падінням ми бачили, як біткойни переходили – в результаті торгівлі – від старих Ходлерів до нових, що сприяло зниженню коефіцієнта Джині. За один тільки 2017 рік ми спостерігали, як 15% всіх біткойнів перестали належати старим Ходлерам.

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

Завдяки ефекту Лінді, чим довше існує біткойн, тим більше суспільство впевнене в тому, що він буде існувати і в майбутньому.

Протоколи вмирають, коли в них більше ніхто не вірить – Naval.

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

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

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

Біткойн – це цифрове золото в очах [Ходлерів]. В якійсь мірі ця група вже мислить в біткойнов-стандарті: інвестиції оцінюються за їхньою здатністю приносити дохід в біткойнах – @TuurDemeester.

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

Ходлери змінять ринок капіталу. Річна норма прибутку ваших біткойнів – це безризикова ставка з додатковими рівнями прибутку на одиницю ризику. Наприклад, мережа Lightning надає можливість вимірювання вартості біткойнів в різні періоди часу в Lightning Network Reference Rate або LNRR – Нік Бхатія.

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

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

Переклад статті “Hodlers are the revolutionaries“

Уявлення про біткойн

Ця стаття про те, як з часом змінювалася основна концепція біткойну.

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

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

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

Таким чином, конфлікти з біткойнами виникають через наявність взаємовиключних уявлень про його протоколі. Якщо ці уявлення примирити не можна, виникають проблеми. Уявлення про біткойн постійно змінюються. Технологічні розробки, практичні обставини і події в реальному світі формують загальне уявлення про біткойн. У цій статті я спробую об’єднати різні основні уявлення про біткойн, що виникали протягом 9-річної історії його життя. Стаття заснована на чудових роботах Мурада Махмудова і Адама Таше, які я рекомендую прочитати.

Зміна концепції

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

Отже, в грубому порядку появи:

1. Доказ концепції електронної валюти. Ця перша основна ідея визначила загальну думку про біткойн, коли він тільки з’явився. Тоді киберпанки і шифрувальники ще тільки оцінювали проект і визначали, чи буде він працювати. Так як всі попередні електронні валюти зазнали невдачі, то людям знадобилося час, щоб переконатися в технічній і економічній спроможності біткойна і перейти до більш широким концепціям протоколу.
2. Дешева платіжна p2p-мережа. Неймовірно популярна і переконлива ідея. Деякі вважають, що саме це Сатоши і мав на увазі – прямолінійна валюта для інтернет-транзакцій без посередників. Так як мікротранзакції є ключовим компонентом онлайн-торгівлі, прихильники цієї ідеї зазвичай вірять, що низькі комісії і зручність є основними характеристиками такої валюти.
3. Стале до цензури цифрове золото. Ідея, протилежна попередньої. Тут біткойн вважається невразливим, які піддаються надування та захопленню засобом зберігання для декількох поколінь, яке непідвладне банкам і державі. Прихильники цієї ідеї принижують значимість біткойну для щоденних транзакцій, підкріплюючи свою позицію тим, що безпека, передбачуваність і консерватизм в розробці більш важливі. В цей табір ми безсердечно поміщаємо всіх, хто вірить в стійкість грошей.
4. Приватна і анонімна валюта даркнета. Біткойн можна використовувати для анонімних онлайн-транзакцій, зокрема, для забезпечення роботи чорного онлайн-ринку. Цей факт не виключає можливість існування цифрового золота, так як багато прихильників цифрового золота вірять, що взаємозамінність і конфіденційність є важливими атрибутами біткойну. Ця ідея була популярна, поки аналізують блокчейни компаніям не вдалося розкрити особистість користувачів біткойнів.
5. Резервна валюта для кріптовалютной індустрії. Біткойн грає важливу роль в якості основної валюти для індустрії криптовалют / кріптоактивів. Таку точку зору підтримують трейдери, для яких валютою розрахунків є BTC, а ціни на інші активи ґрунтуються на вартості біткойну. Крім того, в цей табір автоматично потрапляють трейдери, компанії і розподілені мережі, які зберігають резерви в BTC.
6. Програмована загальна база даних. Це більш оригінальна точка зору, яка зазвичай має на увазі, що біткойн може обробляти будь-які дані, не тільки валютні транзакції. Прихильники цієї ідеї бачать біткойнов як програмований протокол, який може бути використаний в ширших цілях. У 2015-2016 рр. існувала популярна думка, що біткойн, врешті-решт, придбає набір різних функцій за допомогою сайдчейнов. Сюди відносяться такі проекти, як Namecoin, Blockstack, DeOS, Rootstock і деякі сервіси для формування тимчасових міток.
7. Незалежний фінансовий актив. В цьому випадку біткойнов розглядається строго як фінансовий актив, його найголовнішим властивістю є виплата дивідендів. Тут мова йде скоріше не про низьку або нульову кореляції індексів, валют і товарних активів, що робить біткойн привабливим різноманітністю для портфелів. Прихильники цієї ідеї захопити не спотовими угодами, а впливом на актив. Іншими словами, вони хочуть купувати ризики, а не самі біткойни. Біткойн все більше проникає в існуючу фінансову сферу, тому ця концепція і набула популярності.

На графіку нижче ми порівняли різні ідеї щодо їх популярності в часі.

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

Після винаходу ICO і розвитку широкого ринку альткойнов BTC став резервним активом для більшої економіки. Це стало важливою характеристикою біткойнів, особливо під час підвищення цін в 2014 та 2017 років рр. Варто відзначити, що ідея p2p-мережі залишалася популярною до середини 2017 року, коли її прихильники почали підтримувати Bitcoin Cash (деякі перейшли на Litecoin або Dash). Проте, з появою в 2018 році мережі Lightning був помічен новий спалах ентузіазму щодо онлайн-мікротранзакцій і онлайн-платежів без комісії.

У 2015-2016 рр. почали набирати популярність сайдчейни. Передбачалося, що біткойн незабаром розширить свій функціонал, знищивши більшість альткойнов. Такі розширюють функціонал проекти, як Mastercoin (тепер він називається Omni), кольорові монети, Namecoin, Rootstock, Blockstack і Open Timestamps підтримували цю точку зору. Проте, виявилося, що впроваджувати сайдчени складно, і додаткові способи використання біткойну стали неактуальними.

Після завершення ринкової тенденції зниження ціни біткойну в 2014-2015 рр. аналітики почали міркувати над його статусом як унікальних товарних грошей. У листопаді 2015 року Туурі Демеестер опублікував інвестиційну замітку під назвою «Як приготуватися до ралі біткойну», в якій стверджував, що біткойн володіє унікальними характеристиками активу для портфелів. В середині 2016 року Бурніске і Уайт висунули серйозний аргумент на користь того, що біткойн є абсолютно новим класом активу. Аналітики відзначили, що біткойн не схожий на традиційні активи і, відповідно, біткойн став популярним засобом диверсифікації портфелів серед далекоглядних учасників індустрії управління активами. Сьогодні це дуже популярна точка зору, яка підтримується попитом на фінансові продукти, що викликають інтерес до біткойну у традиційних інвесторів.

Концепція цифрового золота була впливовою протягом всієї історії біткойну. Сьогодні з нею згодна більшість, вона стала популярнішою жалюгідного табору p2p-готівки, який розпався після появи Bitcoin Cash. Після багатьох років ворожнечі і внутрішні тертя цю ідею підтримує більшість. Проте, не всі користувачі біткойну є його ідеологічними прихильниками, і ми хотіли відобразити це на графіку. Багато власників біткойнів використовують їх для диверсифікації свого портфеля,  деякі до цих пір користуються біткойнами для здійснення анонімних транзакцій в даркнета, а прихильники p2p-готівки знову набирають силу після появи Lightning.

Напруга і звільнення

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

Серйозних обертів конфлікт набрав у 2015 році після створення BitcoinXT, хоча ворожі обговорення велися і задовго до цієї події. Наступні провокації, включаючи Bitcoin Classic і Unlimited, тільки посилили конфлікт, який досяг свого піку в середині 2017 року під час створення Форк Bitcoin Cash. Під час тенденції підвищення в кінці 2017 року комісії біткойнов піднялися до неймовірного рівня, завдяки чому ряди прихильників Bitcoin Cash поповнилися. Проте, з того моменту комісії вже зменшилися і необхідність у великих блоках здається не такою терміновою.

Крім того, на початку 2018 року було розпочато впровадження Lightning, з’явилася можливість проводити мікроплатежі в мережі біткойна. Таким чином, напруга ослабла, і обидва табори зосередилися на власних цілях. У 2018 році оптимізм щодо платежів другого рівня відродився, і ми помітили збільшення інтересу до дешевих платежів біткойну.

З цього аналізу можна зробити цікавий висновок: біткойн переживає рідкісну стадію відносної гармонії. Єдиної домінуючою концепції не існує, але ідея цифрового золота сьогодні є найвпливовішою. Громадянські війни 2015-2017 рр. завершилися Форком Bitcoin Cash і міграціями в інші табори p2p-платежів, серед яких Litecoin, Dash і Nano. Сьогодні основна напруга спала, і ми опинилися в незвично спокійній епосі історії біткойну. З суб’єктивної точки зору здається, що в таке відносно спокійний час розробка буде вестися швидше. Нескінченні війни в соцмережах, угоди після конференцій і створення сумнівних ФОРКІВ, безсумнівно, ускладнювали роботу розробників. Проте, на горизонті видніється новий конфлікт.

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

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

Послідовність подій

Ми розуміємо, що велика частина нашого аналізу заснована на нашій суб’єктивної інтерпретації старих постів на BitcoinTalk. Якщо ви не згодні з цим, то ми готові розглянути альтернативні думки. Для того щоб полегшити подальший аналіз ми створили графік послідовності ключових подій біткойну, що відображає всю його історію. (За основу ми взяли грубу інтерпретацію цінового графіка 99bitcoins з примітками). Ми радимо вивчати наші кольорові графіки «мінливих припливів» разом з тимчасової схемою, наведеної нижче. Їх протиставлення допоможе зрозуміти, чому ми зробили такі висновки.

Висновок

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

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

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

Переклад статті “Visions of Bitcoin“

Блокчейн: захист персональних даних

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

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

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

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

Частина 1: Фізична особа

Фізособи

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

Конституційний захист

У США конфіденційність важлива для реалізації конституційних прав, включаючи право на свободу слова, свободу створення громадських об’єднань, свободу преси, захист від необгрунтованих обшуків і вилучень, і захист від свідчення проти себе. Відсутність конфіденційності з боку державних суб’єктів ставить під загрозу ці права. Знаючи, що авторство висловлювань легко може стати доступним громадськості, людина може не дозволити собі висловитися за справедливість, особливо в разі суперечливості чи непопулярності подібної думки або предмета обговорення. Оскільки багато важливих думок непопулярні або суперечливі, самоцензура повинна розглядатися суспільством як серйозна проблема. Знання того, що за тобою спостерігають, може також перешкодити зустрітися з однодумцями. Громадські інформатори і інші викривачі правопорушень, відповідальність за які несуть корпорації, куди більш схильні займатися подібною діяльністю, якщо можуть залишатися анонімними. У міру розвитку технологій суди визначили межі поведінки держави.

Інформація про здоров’я

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

Фінансова інформація

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

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

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

Особиста поведінка

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

Анонімність і псевдоніми

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

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

ЗМІ і економіка послуг за запитом вимагають розкриття особистих даних

Розквіт Facebook, Twitter та інших соціальних мереж змінив очікування щодо конфіденційності в Інтернеті. Люди, які використовують ці платформи, добровільно надають особисту інформацію та погоджуються поділитися нею з обмеженою аудиторією або з усіма. Проте, навіть люди, які не хочуть ділитися своєю особистою інформацією (наприклад, ті, у кого немає аккаунта Facebook або Twitter), можуть відчувати необхідність зробити це заради кар’єри або в рамках маркетингу. Роботодавці часто шукають відомості на своїх кандидатів в Google. І оскільки відсутність результату краще, ніж поганий результат, сьогоднішні кандидати на роботу зазвичай використовують Інтернет для власного просування, або створюючи обліковий запис LinkedIn, Або демонструючи досягнення через персональний сайт, блог або статті. Те ж саме відноситься і до малих підприємств: у більшості з них або є присутність в Інтернеті, або, за відсутності такого, вони втрачають бізнес.

Ще однією важливою тенденцією в сфері технологій в останнє десятиліття стала поява економіки послуг за запитом (або, простіше кажучи, економіки обміну), де постачальники і споживачі товарів або послуг з’єднуються через веб або мобільні додатки або за допомогою сайтів для здійснення транзакцій. Це призводить до виключення з ланцюжка традиційного посередника (процес, званий дезінтермедіаціі). Так само, як сервіси райдшерінга (сервіси спільно-попутних поїздок), такі як Uber і Lyft, зробили традиційні служби таксі і системи міського таксі майже застарілими, Вікіпедія замінила великі приватні редакційні енциклопедії, такі як Microsoft Encarta. Сьогодні мандрівники перевіряють не тільки ціни на готелі в інших містах, але і ціни на Airbnb в пошуках короткострокової оренди номерів або будинків безпосередньо від інших людей. У міру появи на ринку послуг за запитом таких компаній, як Airbnb, вони зіткнулися з необхідністю забезпечення безпеки клієнтів, і стали вимагати від господарів і гостей надання особистої інформації. Крім того, після проживання, заброньованого через Airbnb, господареві і гостю пропонується залишити відгук один про одного, і ці огляди часто містять особисту інформацію та вільно доступні будь-кому, хто переглядає сайт Airbnb.

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

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

Частина 2: Організації

Захист організаційної стратегії і корпоративної комерційної таємниці

Організації повинні захищати службову інформацію, таку як формулювання корпоративної стратегії, або комерційна таємниця (наприклад, інтелектуальна власність), Яку конкуренти або недобросовісні особистості можуть використовувати для ослаблення організації. Це відноситься не тільки до компаній, відповідальним за випуск передових в своїх галузях технологій (наприклад, в оборонній, аерокосмічній або автомобільної промисловості), але до всіх видів організацій взагалі. У 2016 році хакери націлилися на Національний комітет демократичної партії і злили в мережу внутрішню електронну переписку, яка підірвала довіру до декільком кандидатам від Демократичної партії. Також в 2016 році хакери, під виглядом офіційних представників центрального банку Бангладеш, відправили інструкції в Нью-Йоркський відділ Федерального резерву, щоб вкрасти $ 951 млн з рахунку Центрального банку Бангладеш в Нью-Йоркському федеральному резерві. Їм вдалося вивести $ 101 млн, і більшу частину цієї суми влада як і раніше не можуть відновити.

Збір інформації про клієнтів для маркетингу і досліджень

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

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

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

Захист клієнтської інформації в сфері В2С-послуг

Для всіх компаній, орієнтованих на споживача, і, можливо, особливо для таких технологічних компаній, як Google, Apple і Amazon, збір особистої інформації споживачів допомагає забезпечити більш персоналізоване обслуговування кожного споживача. Разом з тим компанія бере на себе відповідальність щодо захисту цієї інформації. Наприклад, синхронізація даних через Mac, iPhone і iPad забезпечує людині зручний доступ до інформації, однак при цьому також передбачається, що Apple буде робити кроки для захисту цієї інформації від сторонніх.

Захист клієнтської інформації в сфері В2В-послуг

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

Поточні заходи щодо захисту компаніями своєї службової інформації

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

Частина 3: Великі масиви даних

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

Заклопотаність із приводу збільшення кількості даних, що зберігається існувала вже, принаймні, протягом минулого століття. У квітні 2014 року дослідницька організація IDC (Міжнародний центр даних) випустила звіт «Цифровий всесвіт можливостей: велика кількість даних і зростаюча цінність Інтернету речей», в якому прогнозувалося, що «з 2013 по 2020 рік цифровий всесвіт виросте в 10 разів – з 4,4 трильйона гігабайт до 44 трильйонів». Нинішній приріст даних забезпечується за рахунок збільшення можливостей обчислень і зберігання даних, збільшення кількості датчиків і збільшення можливостей підключення.

Збільшення обчислювальної потужності і ємності сховищ даних

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

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

Поширення методу хмарної обробки даних

Хмарна обробка даних в цілому означає використання на вимогу видалених (а не локальних) обчислювальних потужностей, сховищ даних, додатків або мереж. Завдяки хмарній обробці даних організації можуть просто орендувати обчислювальну потужність або сховище у хмарних провайдерів і їм не доводиться зберігати великі обсяги даних на своїх власних серверах, підтримувати величезні обчислювальні потужності або традиційні бази даних з постачальниками (хоча традиційні бази даних як і раніше можуть бути корисними для великих організацій). Оскільки провайдери ресурсів для хмарних сервісів повинні надавати надійні масштабовані рішення за запитом, великі корпорації, такі як Amazon, Microsoft і Google, є домінуючими постачальниками хмарних сервісів.

Хмарні сервіси для бізнесу представлені в трьох варіантах:

• «Програмне забезпечення як послуга» (SaaS), коли провайдер ресурсів для хмарних сервісів дозволяє організації використовувати своє програмне забезпечення онлайн (наприклад, доступ до TurboTax онлайн)
• «Платформа як послуга» (PaaS), коли компанія розробляє програми для доступу своїх членів до ресурсів провайдера хмарного сервісу (наприклад, Microsoft Azure)
• «Інфраструктура як послуга» (IaaS), коли провайдер хмарного сервісу надає послуги інфраструктури для клієнта, що пропонує власну послугу на базі їх інфраструктури (для наприклад, Netflix з використанням інфраструктури Amazon Web Service для потокової передачі відео).

Звичайним користувачам можуть бути краще знайомі хмарні додатки типу iDrive, Google Docs або Dropbox. Хмарні технології з’явилися не тільки завдяки розвитку обчислювальних потужностей і збільшення обсягу сховищ даних, про які говорилося раніше, але і внаслідок значного розширення, збільшення швидкості і надійності доступу в Інтернет. Хоча метод хмарної обробки даних виник частково як відповідь на труднощі зберігання постійно зростаючих обсягів даних, його широке впровадження сприяло зростанню обсягу даних для зберігання.

Поширення датчиків, ускладнення пристроїв, можливості підключення

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

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

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

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

Інтелектуальні пристрої часто збирають особисті дані

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

«Цифровий всесвіт» розширюється в геометричній прогресії: в квітня 2013 року Ральф Якобсон опублікував статтю в блозі IBM, присвяченому індустрії споживчих товарів, в якій наводиться розрахунок, що світ щодня створює 2,5 мільярда гігабайт даних. Досягнення в області обчислювальних потужностей і ємності сховищ, нарівні зі створенням вдосконалених сенсорних і комунікаційних технологій, сприяли збільшенню обсягу даних, що збираються організаціями. Датчики виробляють вимірювання, і ці вимірювання передаються іншим пристроям або серверів, збираються і зберігаються у вигляді базових точок.

Штучний інтелект

Більшість досліджень в області штучного інтелекту фінансуються Google, Amazon і Baidu, оскільки дані є їжею штучного інтелекту, а ці компанії щодня генерують величезну кількість даних. Microsoft придбала LinkedIn не заради їх платформи, а заради даних.

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

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

Якщо технологія викликала цю ерозію недоторканності приватного життя, то можливо, технологія зможе допомогти її вирішити.

Частина 4: Блокчейн-технології

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

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

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

Рішення із застосуванням технології блокчейн

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

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

Гомоморфності шифрування

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

Криптографічні методи, такі як протоколи доказів з нульовим розголошенням знань (ZKPs) і zk-SNARK, вже використовують гомоморфності шифрування. Популярний крипто-протокол під назвою Zcash використовує zk-SNARK для шифрування своїх даних і дає ключі дешифрування авторизованим особам, щоб вони могли бачити ці дані.

Канали стану

Блокчейн може дати моделі для рішень без застосування блокчейна або бути частиною гібридного рішення для захисту конфіденційності.

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

1. Блокування: транзакція блокується за допомогою смарт-контракту в ланцюзі.
2. Взаємодія: взаємодії відбуваються поза ланцюга або в сайдчейне.
3. Публікація: після того, як взаємодії завершені і канал стану закритий, смарт-контракт розблокується і посилання на транзакцію публікується в блокчейне.

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

Висновок

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

Переклад статті “How Blockchains Will Enable Privacy“

Практичне застосування токенізаціі: чеки

Удосконалити чекові платежі за допомогою токенів можна, вирішивши лише незначні проблеми сумісності.

Відродження чеків в розпал фінансово-технічної революції.

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

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

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

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

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

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

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

Всі види фіатних грошей сильно відрізняються один від одного. Через FedLine, ACH і у вигляді чеків відправляються різні долари. Фіатні гроші – це різні формулювання різних систем і нічого більше.

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

Тож не дивно, що банки знаходяться в розгубленості.

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

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

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

Чому ж не відродити старі добрі чеки нової технологічної пігулкою – токенами криптовалют?

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

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

Ми можемо і повинні використовувати «зворотню правову сумісність». Метадані, які включають в себе акт підпису, завірення і так далі, можуть частково зберігатися в блокчейне і частково бути пов’язані з розподіленими базами даних. Цілісність документа, розділеного між блокчейном і традиційним зберіганням, може бути перевірена з 100% точністю і з нульовими витратами. Правило «CC» вже визначає основну архітектуру, потрібно тільки замінити скановані зображення токенами і метаданими. Згідно з цим правилом, якщо щось йде не так, то електронний або паперовий чек може бути відтворений в будь-який момент.

Кожен токенізірованний чек може бути представлений у вигляді звичайного паперового чека, але без комісій і з безкоштовним бездротовим мікрочіпом. Цей чіп, образно кажучи, з’єднаний з Інтернетом, який також безкоштовний і на 100% захищений. Відстеження статусу чеків, починаючи з запевнення і закінчуючи іншими процесами, також можливо завдяки набору інструментів в банку. Законна зміна комісій тепер може здійснюватися на льоту. Токени створюють альтернативний рівень даних, в той час як обробна структура залишається колишньою.

Коли банк випускає чекову книжку для клієнта (у звичайній паперовій формі), клієнту пропонується менш дорога версія для смартфона. У банку немає прямого контролю над додатком з відкритим вихідним кодом, в яке він може завантажувати чеки. Для того, щоб віддалено завантажити токенізірованний чек, банку необхідно отримати блокчейн-адреса через авторизовані канали зв’язку, наприклад, через особистий кабінет в електронному банку.

Для мобільного додатка не потрібно створювати обліковий запис або логін і пароль з централізованою перевіркою. Кожен чек є унікальним блокчейн-об’єктом з завантаженими даними і метаданими, з’єднаними зі звичайною базою даних. Чеки можуть передаватися від клієнта клієнту, але щоб підписати їх, а також «активувати», необхідна персональна авторизація. Банки не стежать за тим, чи правильно авторизовані чеки, як це відбувається зі звичайними паперовими чеками.

Чому оновлення чеків – це здорово.

Чек – це вид фіатних грошей, який найкраще підходить для блокчейна.

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

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

Токен, який мандрує по блокчейну, нагадує швидше чек, ніж пряму одиницю фіатной валюти.

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

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

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

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

Чеки залишаються найприроднішим платіжним інструментом.

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

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

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

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

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

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

І останнє, але не менш важливе. Існує певний культурний образ чеків. Чек – це запрошення в «сховище з багатствами» відправника для отримання грошей, неважливо, як воно виглядає і де знаходиться. Існує певний «джентльменський» ореол навколо цього легендарного виду ділових відносин: клієнтові не потрібно належати до певної мережі ( «у вас є PayPal?»), Щоб йому заплатили. Йому також не потрібно розкривати будь-яку інформацію про себе ( «яка у вас адреса?»). Для того щоб отримати платіж, потрібно тільки повідомити ім’я та поставити підпис.

Переклад статті “Tokenization Use Case: Cheques“