Підручник з дерева намотування

Примітка редактора: Ця історія спочатку була опублікована 20 січня 2018 року. З того часу проект Winding Tree значно просунувся та опублікував офіційні підручники на веб-сайті https://developers.windingtree.com/. Цей підручник та його висновки здебільшого застаріли, історія зберігається лише для довідки.

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

Відповідно до їхньої білої книги:

П'ять компаній у туристичній галузі контролюють більшу частину ринку подорожей. Дві найбільші OTA (Інтернет-туристичні агенції), Priceline Group та Expedia Inc., контролюють 95% ринку OTA в американських Amadeus, Saber та Travelport, трійці найбільших GDS (Global Distribution Systems), мають 99% загальної частки ринку в непрямий інвентар на ринку повітря.

Бум, заявлена ​​проблема. І вони співпрацювали з такими великими іменами, як Lufthansa Group. Як хтось, хто працює в галузі туристичних технологій, у мене виникло багато питань: як команда проекту планує зірвати галузь трильйона доларів? Як працює економіка? Як вони вирішують технологічні завдання? Щоб отримати відповіді на мої запитання, я вирішив отримати досвід з перших рук, поекспериментувати з відкритим кодом, який вони випустили, і поділитися своїми відгуками у підручнику.

У цьому підручнику ми будемо використовувати Мінімальний життєздатний продукт (MVP) для готелів, доступний у Github Winding Tree's. Очікується, що зміниться багато, але це вже добре, щоб зрозуміти потенціал технології.

Нашою метою буде:

  • Створіть готель на блокчейні з однією кімнатою
  • Забронюйте цей номер на 5 днів.

Нам знадобляться деякі інструменти для взаємодії зі смарт-контрактами: git, node (≥7,6), npm та трюфель. Якщо у вас їх немає, просто дотримуйтесь вказівок на відповідних сторінках.

Ми клонуємо контракти та встановлюємо залежності:

$ cd / tmp
$ git клон https://github.com/windingtree/wt-contracts --рекурсивний
$ cd wt-контракти
$ npm встановити

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

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

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

Також у Truffle є інтерпретатор Javascript із введеним провайдером web3, тому для цього навчального посібника ми спростимо налаштування та просто виконаємо код Javascript у командному рядку. Цей же код може бути запущений сервером Node.js або веб-переглядачем.

Ми входимо в консоль розробки трюфелів:

$ трюфель розвивати
Розробка трюфелів розпочалася на http: // localhost: 9545 /
Рахунки:
(0) 0x627306090abab3a6e1400e9345bc60c78a8bef57
(1) 0xf17f52151ebef6c7334fad080c5704d77216b732
(2) 0xc5fdf4076b8f3a5357c5e395ab970b5b54098fef
(3) 0x821aea9a577a9b44299b9c15c88cf3087f3b5544
(4) 0x0d1d4e623d10f9fba5db95830f7d3839406c6af2
(5) 0x2932b7a2355d6fecc4b5c0b6bd44cc31df247a2e
(6) 0x2191ef87e392377ec08e7c08eb105ef5448eced5
(7) 0x0f4f2ac550a1b4e2280d04c21cea7ebd822934b5
(8) 0x6330a553fc93768f612722bb8c2ec78ac90b3bbc
(9) 0x5aeda56215b167893e80b4fe645ba6d5bab767de
Мнемонічне: цукерковий кленовий пиріг цукровий пудинг з кремом з медом, насичений гладкою крихтою солодке частування
трюфель (розвивати)>

Трюфель автоматично запускає вузол Ethereum і створює для нас кілька тестових облікових записів з безкоштовним ETH (на жаль, діє лише в нашому екземплярі testrpc), і ми пов'язані з мнемонічністю. Під час підручника ми не будемо намагатися змінювати рахунки на різні ролі: WT Foundation, менеджер готелів, туристичне агентство.

Складемо договори:

> компілювати
> розгортати

Зараз ми готові почати використовувати договори Winding Tree!

Ось дуже спрощена схема, що показує ієрархію контрактів:

Ієрархія контрактів WT Hotel MVP (спрощена)

Контракт WTIndex лежить в корені ієрархії і створюється Фондом Winding Tree. У цьому підручнику наш тестовий екземпляр testrpc повністю імітує блокчейн Ethereum, тому контракт не існує, і нам потрібно його створити:

> WTIndex.new (). Тоді (екземпляр => wt = екземпляр)

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

> вага. адреса
'0xf25186b5081ff5ce73482ad761db0eb0d25abfbf'

Чудово, наш контракт WTIndex зараз розгорнуто!

Тепер, коли у нас є контракт WTIndex, давайте створимо готель.

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

> wt.registerHotel ("Мій готель", "Дуже приємний готель")

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

> wt.getHotelsByManager (web3.eth.coinbase)
['0xf2beae25b23f0ccdd234410354cb42d08ed54981']

Договір на готель створений, і у нас є його адреса. Для зручності створимо змінну h із екземпляром:

> wt.getHotelsByManager (web3.eth.coinbase) .then (addr => h = Hotel.at (addr [0]))

Перевіримо, чи ми можемо отримати доступ до імені та опису:

> h.name ()
"Мій готель"
> h.description ()
"Дуже приємний готель"

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

Для цього ми створимо UnitType та Unit для нашої кімнати. На відміну від того, що ми зробили для готелю, який був створений контрактом WTIndex, нам потрібно розгорнути ці договори самостійно, і нам потрібно надати право власності на адресу готелю.

Давайте створимо базову кімнату:

> UnitType.new (h.address, 'BASIC_ROOM'). Тоді (i => ut = i)
> Unit.new (h.address, 'BASIC_ROOM'). Тоді (i => u = i)

Тепер, щоб додати Unit та UnitType у свій готель, фокус у тому, що договір про готель належить не за нашою адресою, а за контрактом WTIndex. Якщо ми спробуємо його змінити, нам буде відхилено:

> h.addUnitType (ut.address)
Помилка: Виняток VM під час обробки транзакції: недійсний опкод

Щоб додати UnitType та Unit, і взагалі для всіх змін до договору про готель, нам потрібно буде використовувати функцію callHotel (). На щастя, це захищено так, що тільки ми як менеджер можуть викликати цю функцію:

> wt.callHotel (0, h.contract.addUnitType.getData (ut.address))
> wt.callHotel (0, h.contract.addUnit.getData (u.adress))

Щоб прийняти бронювання, готельєри мають два варіанти:

  • Миттєво з рідним маркером LIF Winding Tree
  • З механізмом підтвердження з іншими варіантами оплати.

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

> wt.callHotel (0, h.contract.changeConfirmation.getData (true))

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

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

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

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

В екосистемі Намотування дерева резервація зроблена з двох частин:

  • Приватний із деталями гостей
  • Загальнодоступний із зазначенням даних про бронювання готелів та дати.

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

Тут є технічна деталь: потенційно, не всі готелі вимагатимуть однакових даних та приймати однакові способи оплати, тож як туристичне агентство може знати, які поля є обов'язковими чи ні?

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

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

> privateData = "PRIVATE_GUEST_DATA"
> publicData = h.contract.book.getData (u.address, web3.eth.coinbase, 20150, 5)
> h.beginCall (publicData, privateData) .then (i => beginCalltx = i)

Примітка: 20150 - це число дня після 1 січня 1970 року: 3 березня 2025 року

Готель може спостерігати блокчейн для бронювання подій. Отримавши подію, готель може отримати публічні та приватні дані:

> abiDecoder = requ ('abi-декодер')
> abiDecoder.addABI (Hotel._json.abi)
> beginCallEvent = abiDecoder.decodeLogs (beginCalltx.receipt.logs) [0]
> beginCalltxCode = web3.eth.getTransaction (beginCalltx.tx) .input
> transferDecoded = abiDecoder.decodeMethod (beginCalltxCode)
> abiDecoder.decodeMethod (transferDecoded.params [0]. значення)
{назва: 'книга',
  парами:
   [{назва: 'unitAddress',
       значення: '0xf25186b5081ff5ce73482ad761db0eb0d25abfbf',
       тип: 'адреса'},
     {ім'я: 'від',
       значення: '0x627306090abab3a6e1400e9345bc60c78a8bef57',
       тип: 'адреса'},
     {ім'я: 'fromDay', значення: '20150', тип: 'uint256'},
     {ім'я: 'daysAmount', значення: '5', тип: 'uint256'}]}
> web3.toAscii (transferDecoded.params [1]. значення)
'PRIVATE_GUEST_DATA'

І прийміть бронювання:

> pendingCallHash = beginCallEvent.events [1] .значення
> wt.callHotel (0, h.contract.continueCall.getData (pendingCallHash))

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

> u.getРезервація (20150)
[BigNumber {s: 1, e: 0, c: [0]},
  BigNumber {s: 1, e: 0, c: [0]},
  '0x627306090abab3a6e1400e9345bc60c78a8bef57']
> h.beginCall (publicData, privateData)
Помилка: Виняток VM під час обробки транзакції: недійсний опкод

Успіху!

У цьому підручнику ми побачили, як використовувати договір MVP Winding Tree для готелю, і нам вдалося зрозуміти потенціал платформи.

Однак низка питань залишається відкритою і потребує подальших розробок від команди Winding Tree та її громади:

  • Масштабованість: поточна вартість налаштування готелю є досить високою (у платі за газ), оскільки нам потрібно відправити кілька транзакцій для створення кожного типу одиниць та одиниць та їх налаштування. Необхідні також часті оновлення інвентаря, коли деякі роботи виконуються в даній кімнаті. Описовий файл, що зберігається поза контрактом, наприклад, в IPFS або SWARM, був би набагато кращим. Також деякі загальні зміни ефіруума з переходом до каналів "Доказ на користь" та "Державні канали" мають значно покращити ситуацію.
  • Конфіденційність: З існуючим механізмом відносно готельного контракту ABI відносно тривіально для отримання приватних даних гостя. Ми добровільно подали в приклад кредитну карту, щоб поставити питання про відповідність PCI-DSS. В Європі також є GDPR. Як ці дані будуть захищені? Також деякі туристичні агенції мають приватні тарифи в результаті ділових переговорів, чи повинні ці дані бути загальнодоступними?
  • Дублікати та підроблені списки: ніщо не заважає поганому акторові створити підроблений індекс, підроблені готелі тощо. Вони навіть можуть створити безліч застережених застережень, щоб зробити їх законними. Як туристична агенція та врешті-решт мандрівник захищені від цієї ситуації? Недопустимо, щоб мандрівник, який їхав до готелю, виявив, що тут нічого немає, або найгірше. Будь-яка серйозна реалізація потребує вжиття великої кількості заходів, щоб забезпечити хорошу адресу контракту з готелем, який існує у фізичному світі.

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