Технічна Документація Tezos
У першій частині ми обговоримо концепцію абстрактних блокчейнів і реалізацію самовиправного крипто-леджера. У другій частині опишемо пропонований нами seed протокол.
Протокол блокчейна можна розбити на три окремих протоколи:
- Мережевий протокол, що виявляє блоки і транслює транзакції.
- Протокол транзакції, що визначає, що робить транзакцію дійсною.
- Протокол консенсусу, що формує консенсус навколо унікального ланцюга.
Tezos впроваджує універсальну мережеву оболонку. Ця оболонка не залежить від протоколу транзакцій і протоколу консенсусу. Разом протокол транзакцій і протокол консенсусу ми називаємо «протоколом ланцюга блоків». Спочатку ми опишемо математичне представлення протоколу блокчейна, а потім - деякі варіанти реалізації в межах Tezos.
Протокол блокчейна по суті є монадичною реалізацією паралельних мутацій глобального стану. Це досягається шляхом визначення «блоків» як операторів, які впливають на даний глобальний стан. Вільний моноїд блоків, які працюють відповідно до стану походження, утворює деревоподібну структуру. Глобальний канонічний стан визначається як мінімальний лист для зазначеного порядку (розташування).
Виходячи з вищесказаного, отримаємо наступне абстрактне уявлення:
- Let $(\mathbf{S},\leq)$ повністю упорядкований, обчислюваний набір можливих станів.
- Let $\oslash \notin \mathbf{S}$ представляє особливий, недійсний стан.
- Let $\mathbf{B} \subset \mathbf{S}^{\mathbf{S} \cup {\oslash}}$ - набір блоків. Набір дійсних блоків: $\mathbf{B} \cap \mathbf{S}^{\mathbf{S}}$.
Загальний порядок на $\mathbf{S}$ розширено до $\forall s \in \mathbf{S}, \oslash < s$. Цей порядок визначає, який лист у дереві блоків вважатиметься канонічним. Блоки в $\mathbf{B}$ розглядаються як оператори, які впливають на даний стан.
Підсумовуючи вищенаведене, зазначимо: будь-який б локчейн-протокол1 (Bitcoin, Litecoin, Peercoin, Ethereum, Cryptonote і т.д.) може бути повністю визначений кортежем:
Загалом, мережевий протокол ідентичний для цих блокчейнів. Алгоритми «майнінгу» - це лише незалежна властивість мережі, враховуючи стимули для створення блоків.
У Tezos ми робимо протокол блокчейну інтроспективним, дозволяючи блокам впливати на сам протокол. Набір рекурсивно можна виразити як:
Цей формальний математичний опис не пояснює, як побудувати дерево блоків. Це роль мережевої оболонки, яка слугує інтерфейсом між мережею пліток і протоколом.
Мережева оболонка працює, підтримуючи кращий з відомих клієнтові ланцюгів. Їй відомі три типи об'єктів. Перші два - це транзакції і блоки, які поширюються через мережу тільки в тому випадку, якщо вони вважаються дійсними. Третім є протоколи і модулі OCaml, використовувані для зміни існуючого протоколу. Їх докладний опис буде приведено нижче. А поки ми зосередимося на транзакціях і блоках.
Найскладнішою частиною роботи мережевої оболонки є захист вузлів від атак типу «відмова в обслуговуванні».
Кожен блок містить мітку часу, видиму для мережевої оболонки. Блоки, що з'являються з майбутнього, буферизуются, якщо їх мітки часу знаходяться в межах кількох хвилин системного часу, і в іншому випадку відхиляються. Структура протоколу повинна виносити розумні відхилення тактового генератора в клієнтах і припускати, що мітки часу можуть бути сфальсифіковані.
Оболонка підтримує єдиний ланцюг, а не ціле дерево блоків. Цей ланцюг перезаписується тільки в тому випадку, якщо клієнт дізнається про строго кращий ланцюг.
Утримання дерева було б економічнішим з точки зору мережевих комунікацій, проте вразливим до атак типу Denial-of-Service ( «відмова в обслуговуванні»), коли зловмисник виробляє велику кількість слабких, але дієвих виделок.
Тим не менш, для ноди залишається можливим брехати про рахунок цього ланцюга; брехня, яку клієнт може розкрити лише після обробки потенційно великої кількості блоків. Однак такий вузол згодом може бути проігнорований.
На щастя, протокол може володіти властивістю, за якої ланцюжки з низьким показником демонструють низьку швидкість створення блоків. Таким чином, клієнт розглядатиме лише кілька блоків «слабкого» форку, перш ніж дійде висновку, що оголошений рахунок є хибним.
Окрім того, оболонка є «захисною». Вона намагається підключитися до безлічі вузлів через різні діапазони IP-адрес. Оболонка виявляє відключені вузли і блокує шкідливі ноди.
Для захисту від атак типу «Відмова в обслуговуванні» протокол надає оболонці контекстно-залежні граничні значення для розміру блоків і транзакцій.
Ми можемо ефективно охопити майже всю універсальність нашої абстрактної структури блокчейну за допомогою наступних типів OCaml. Для початку заголовок блоку визначається як:
type raw_block_header = {
pred: Block_hash.t;
header: Bytes.t;
operations: Operation_hash.t list;
timestamp: float;
}
Ми навмисно не вводимо поле заголовка сильніше, щоб воно могло представляти довільний контент. Однак ми вводимо поля, необхідні для роботи оболонки. До них відносяться хеш попереднього блоку, список хеш операцій і мітка часу. На практиці операції, включені до блоку, передаються разом із блоками на рівні мережі. Самі операції представлені у вигляді довільних BLOB-об'єктів.
type raw_operation = Bytes.t
Стан представляється за допомогою модуля Context, який інкапсулює незмінне сховище "ключ-значення", засноване на дисках. Структура сховища типу "ключ-значення" є універсальною і дозволяє ефективно представляти широкий спектр станів.
module Context = sig
type t
type key = string list
val get: t -> key -> Bytes.t option Lwt.t
val set: t -> key -> Bytes.t -> t Lwt.t
val del: t -> key -> t Lwt.t
(*...*)
end
Задля уникнення блокування дискових операцій, функції використовують асинхронну монаду Lwt [@LWT]. Зверніть увагу, що операції над контекстом є чисто функціональними: get використовує option monad замість того, щоб видавати виняток, в той час як обидва set і del повертають новий Context. Модуль Context використовує комбінацію кешування пам'яті і дискового сховища, щоб ефективно представити незмінне сховище.
Тепер можемо визначити тип модуля довільного блокчейн-протоколу:
type score = Bytes.t list
module type PROTOCOL = sig
type operation
val parse_block_header : raw_block_header -> block_header option
val parse_operation : Bytes.t -> operation option
val apply :
Context.t ->
block_header option ->
(Operation_hash.t * operation) list ->
Context.t option Lwt.t
val score : Context.t -> score Lwt.t
(*...*)
end
Ми більше не порівнюємо стани напряму, як в математичній моделі. Натомість, проектуємо Context на список байтів, застосовуючи функцію Score. Список байтів впорядкований спочатку за довжиною, а потім - за лексикографічним порядком. Це відносно універсальна структура, схожа на ту, що використовується при управлінні версіями програмного забезпечення, яка вважається досить гнучкою якщо мова йдеться про представлення різних упорядкувань.
Чому б не визначити функцію порівняння всередині протокольних модулів? По-перше, було б важко виконати вимогу, за якої така функція представляє загальний порядок. Проекція значень підтверджує це у всіх випадках (зв'язки можуть бути розірвані на основі хешу останнього блоку). По-друге, нам в принципі потрібна можливість порівнювати стани різних протоколів. Конкретні правила зміни протоколу, ймовірно, зроблять це вкрай малоймовірним, але мережева оболонка цього не знає.
Операції parse_block_header і parse_operation відкриваються для оболонки і дозволяють їй передавати повністю типізовані операції і блоки до протоколу, а також перевіряти, чи правильно вони сформовані, перш ніж приймати рішення про перенаправлення операцій або додавання блоків до локальної блокової деревоподібної бази даних.
Функція apply є основою протоколу:
- Коли їй передається заголовок блоку і пов'язаний список операцій, вона обчислює зміни, внесені до контексту, і повертає змінену копію. Всередині зберігається лише різниця (як в системі управління версіями), що використовує хеш блоку в якості дескриптора версії.
- Коли передається лише список операцій, і вона жадібно намагається застосувати якомога більше операцій. Ця функція не є необхідною для самого протоколу, але вкрай корисна для майнерів, які намагаються сформувати дійсні блоки.
Найпотужніша особливість Tezos - можливість реалізовувати протокол, здатний до самозміни. Це досягається шляхом надання протоколу двох процедурних функцій:
- set_test_protocol котрий замінює використовуваний в тестовій мережі протокол на новий протокол (зазвичай прийнятий голосуючим стейкхолдером).
- promote_test_protocol який замінює поточний протокол на протокол, який в даний час тестується.
Ці функції пер етворюють Context, змінюючи пов'язаний протокол. Новий протокол вступає в силу, коли до ланцюга застосовується наступний блок.
module Context = sig
type t
(*...*)
val set_test_protocol: t -> Protocol_hash.t Lwt.t
val promote_test_protocol: t -> Protocol_hash.t -> t Lwt.t
end
protocol_hash - це хеш sha256 з тарболу файлів .ml і .mli. Дані файли компілюються на льоту. Вони мають доступ до невеликої стандартної бібліотеки, але знаходяться в пісочниці і можуть не виконувати жодних системних викликів.
Ці функції викликаються через функцію apply, яка повертає новий Context.
Зміну протоколу можуть викликати безліч умов. У найпростішому варіанті голосування стейкхолдерів тягне за собою зміну протоколу. За більш складні правила можна голосувати поступово. Наприклад, за бажанням стейкхолдера можна прийняти поправку, яка вимагатиме додаткових поправок, щоб надати перевірюваний комп'ютером доказ того, що нова поправка поважає певні властивості. Це ефективна і алгоритмічна перевірка «конституційності ».
Щоб спростити роботу зі створення графічного інтерфейсу, протокол надає API-інтерфейс JSON-RPC. Сам API описується схемою json, що вказує типи різних процедур. Як правило, такі функції, як get_balance, можуть застосовуватися в RPC.
type service = {
name : string list ;
input : json_schema option ;
output : json_schema option ;
implementation : Context.t -> json -> json option Lwt.t
}
Ім'я являє собою список рядків, які дозволяють використання просторів імен в процедурах. Введення і виведення опціонально описуються схемою json.
Зверніть увагу, що виклик виконується в даному контексті, який зазвичай вважається найближчим предком найвищого листа. Наприклад, запит контексту на шість блоків вище найвищого листа відображає стан головної книги з шістьма підтвердженнями.
Сам користувацький інтерфейс може бути адаптований до конкретної версії протоколу або в цілому отриманий зі специфікації JSON.
Подібно до того, як блокчейни починаються з хеша генезису, Tezos починається з seed протоколу. Цей протокол може бути змінений, аби відобразити практично будь-який алгоритм на основі блокчейну.
Пропонуємо, щоб одна монета називалася «tez», а найменша одиниця - просто цент. Також пропонуємо використовувати символ ꜩ (
\ua729, «латинська маленька буква tz») для позначення теза (tez). В ході збору коштів загалом було згенеровано 763,306,929.69 ꜩ, які було розподілено серед учасників збору.Припускаємо, що безпека будь-якої децентралізованої валюти вимагає стимулювання учасників грошовою винагородою. Як пояснюється в доповіді, залежність суто від транзакційних витрат страждає від трагедії громад. Tezos в свою чергу покладається на союз облігацій і винагород.
Облігації являють собою 5-циклові гарантійні внески, придбані майнерами та індосантами. У випадку подвійного підпису ці облігації втрачаються.
По закінченню одного циклу майнери та індосанти отримують винагороду разом з облігацією, щоб компенсувати вартість втраченої можливості. Безпека головним чином забезпечується вартістю облігації, а винагорода має становити лише невеликий відсоток від цієї вартості.
Метою облігацій є зменшення необхідної винагороди і, можливо, використання ефекту неприйняття збитків в інтересах мережі.
У seed протоколі майнінг блоку пропонує винагороду в розмірі 16 ꜩ і вимагає наявності облігації в розмірі 512 ꜩ за кожен створений блок. Підписання блоку пропонує винагороду до 2 ꜩ в залежності від пріоритету створеного блоку. У кожному блоці може бути до 32 підписів, а для підпису необхідна застава у 64 ꜩ.
Графік винагород передбачає номінальний рівень інфляції в 5,5%. Номінальна інфляція нейтральна: вона нікого не збагачує і не збідняє2.
Зверніть увагу, що період року визначається за мітками часу блоку, а не за кількістю блоків. Це повинно усунути невизначеність щодо тривалості прийнятих майнерами зобов'язань.
Якщо адреса неактивна, її не буде обрано для створення блоків (що призведе до уповільнення алгоритму консенсусу), і їй не буде дозволено голосувати доти, поки її не активують (задля уникнення невизначеності щодо рівня участі).
Поправки приймаються виборчими циклами тривалістю $N = 2^ {17} = 131072$ блоків кожен. З огляду на інтервал блокування в одну хвилину, це близько трьох календарних місяців. Виборчий цикл сам по собі ділиться на чотири чверті $ 2^{15} = 32768$ блоків. Цей цикл є відносно коротким, щоб сприяти раннім поліпшенням, але очікується, що подальші поправки збільшать його тривалість. З метою забезпечення швидкої ітерації, голосування за оновлення протоколу в перший рік буде частішим. В якості заходу безпеки Tezos Foundation матиме право вето, термін дії якого скінчиться через дванадцять місяців, допоки ми не виключимо будь-які відхилення в процедурі голосування. Затвердження вимагає певного кворуму. Цей кворум починається з $Q = 80\%$, але динамічно адаптується для відображення середньостатистичної участі. Це необхідно лише у випадку з втраченими коїнами.
Зміни протоколу пропонуються шляхом відправки хеша тарбола файлів
.ml і .mli, що представляє новий протокол. Стейкхолдери можуть схвалити будь-яку кількість таких протоколів. Цей процес також відомий як «схвальне голосування», і вважається особливо надійною процедурою.Поправка, що одержала найбільше схвалення в першому кварталі, тепер підлягає голосуванню. Стейкхолдери можуть голосувати за, проти або явно утриматися. Ті, що утрималися, рахуються разом із кворумом.
Якщо кворуму дотримано (включно з тими, хто явно утримався), і поправка отримала $80\%$ голосів "за", така поправка затверджується і замінює протокол випробувань. В іншому випадку вона відхиляється. Припускаючи, що досягнутий кворум $q$, мінімальний кворум $Q$ оновлюється як:
:
Мета цього оновлення - уникнути втрати токенів, через які процедура голосування з часом застрягає. Мінімальний кворум - це експоненційне рухоме середнє кворуму, досягнутого за кожні попередні вибори.
Припускаючи, що поправку було схвалено, її буде допущено до тестової мережі з початку третього кварталу. Стейкхолдери голосують вдруге, щоб підтвердити намір просунути протокол випробувань до основного протоколу. Для цього також потрібна наявність кворуму і кваліфікована більшість у $80\%$.
Ми свідомо обрали консервативний підхід до поправок. Проте, стейкхолдери можуть приймати поправки, що послаблюють або посилюють цю політику, якщо вважатимуть за необхідне.
Наш механізм proof-of-stake являє собою поєднання кількох ідей, в тому числі Slasher [@Slasher], chain-of-activity [@CoA] і proof-of-burn. Нижче наведено короткий огляд алгоритму, компоненти якого буде детальніше описано згодом.
Кожен блок видобувається випадковим стейкхолдером (майнером) і містить дек ілька підписів попереднього блоку, наданих випадковими стейкхолдерами (підписантами). Як майнінг, так і підпис пропонують невелику винагороду, і водночас вимагають внесення 5-циклового гарантійного внеску, який буде анульовано у випадку подвійного майнінгу або подвійного підпису.
На початку кожного циклу з чисел, які обрали і взяли на себе в передостанньому, і розкрили в останньому циклі майнери блоків, виходить випадкове початкове число. За його допомогою стратегія «слідуй за токенами» застос овується для розподілу прав на майнінг і підпис на певні адреси наступного циклу.
4 цикли механізму proof-of-stake:
Протокол накладає мінімальні затримки між блоками. Кожен блок, в принципі, може бути добутий будь-ким зі стейкхолдерів. Однак для цього блоку кожен стейкхолдер піддається випадковій мінімальній затримці. Стейкхолдер, який отримав найвищий пріоритет, може майнити блок через хвилину після попереднього блоку. Стейкхолдер, який отримав другий за величиною пріоритет, може майнити блок через дві хвилини після попереднього блоку, третій - три хвилини і так далі.
Це гарантує, що форк, в якому бере участь лише невелика частина стейкхолдерів, демонструватиме низький рівень створення блоків. Якби це було не так, то атака типу «Відмова в обслуговуванні» була б можливою, якщо обманом змусити ноди перевірити дуже довгий ланцюг, у якому, як стверджується, був зафіксований надзвичайно високий показник.
Кожен видобутий блок містить хеш-зобов'язання для випадкового числа, обраного майнером. Ці цифри повинні бути виявлені в наступному циклі під загрозою втрати страхової застави. Таке суворе покарання призначене для запобігання вибіркового утримання чисел, які можуть бути використані для атаки на ентропію сіда.
У наступному циклі майнери-зловмисники можуть спробувати піддати цензурі такі виявлення, однак, оскільки в одному блоці може бути виявлено кілька чисел, вони навряд чи досягнуть успіху.
Всі показані числа в циклі об'єднуються в хеш-список, а початкове число отримується з кореня за допомогою функції отримання ключа scrypt. Вивід ключа повинен бути налаштований таким чином, щоб отримання початкового числа займало близько частки відсотка від середнього часу перевірки (підтвердження) блоку на типовому настільному ПК.
Для випадкового вибору стейкхолдера ми застосовуємо процедуру коїнів.
У світі біткоіну цей принцип відомий як follow-the-satoshi («слідуй за сатоші»). Процедура працює «нібито», а в кожного сатоші, який колись карбували, є унікальний серійний номер. Сатоші неявно впорядковані за часом створення; випадкові сатоші створюються і відслідковуються через блокчейн. Звичайно, деякі центи не відслідковуються напряму. Замість цього застосовуються правила для опису того, що відбувається, коли входи об'єднуються і витрачаються на кілька виходів.
В кінці алгоритм відстежує набір інтервалів, пов'язаних з кожним ключем. Кожен інтервал представляє «діапазон» сатоші. На жаль, з часом база даних стає все більш фрагментованою, збільшуючи роздування на стороні клієнта.
Ми оптимізуємо попередній алгоритм, створюючи великі «роли коїнів», складені з тезів (tez). Так, існує близько мільйона ролів. База даних відображає поточному власнику кожен з його ролів.
У кожній адресі міститься певний набір конкретних ролів, а також якийсь дріб'язок. Коли ми хочемо витратити частину повного ролу, рол переривається, і його серійний номер відправляється до черги ролів LIFO (щось на зразок «ув'язнення» (''limbo'')). Кожна транзакція обробляється таким чином, щоб звести до мінімуму кількість зламаних ролів. Щоразу, коли в адресі міститься достатньо коїнів для формування ролу, з черги витягується серійний номер, і рол формується наново.
Пріоритет LIFO гарантує, що зловмисник, який працює на секретному форці, не зможе обміняти коїни, які він тримає, переміщаючи залишок між рахунками.
Незначний недолік цього підходу полягає в тому, що ставка округляється до найближчого цілого числа ролів. Однак це забезпечує значне підвищення ефективності в порівнянні з підходом follow-the-satoshi.
Незважаючи на те, що роли пронумеровані, цей підхід не виключає використання зберігаючих функціональність протоколів, наприклад Zerocash. Ці протоколи можуть застосовувати в «ув'язненні» одну і ту ж техніку черговості.
Функціонально ця процедура відрізняється від простого витягування випадкової адреси, зваженої за балансом.
Дійсно, в секретному форці майнер може спробувати управляти генерацією випадкового початкового числа і призначити самому собі права на підпис і злом, створюючи відповідні адреси зазд алегідь. Цього набагато важче досягти, якщо роли обираються випадковим чином, оскільки секретний форк не може підробити володіння певними ролами і, таким чином, повинен спробувати перетворити хеш-функцію, яка застосовується до сіду, щоб призначити собі права підпису і майнінгу.
Так, в циклі довжиною $N=2048$ власник частки у $f$ ролів, в середньому отримає $fN$ прав на майнінг, а отримана ефективна частка $f_0$ матиме стандартне відхилення
Якщо зловмисник може виконати пошук методом «грубої сили» з різних початкових значень $W$, його очікувана перевага не перевищує
блоків. Наприклад, зловмисник, який контролює $f = 10\%$ ролів, може розраховувати на майнінг близько $205$ блоків за цикл. У секретному форці, в якому він намагається контролювати початкове число, припускаючи, що обчислив більше трильйона хешів, він міг би призначити собі близько $302$ блоків, або близько 14,7%\%$ блоків. Зверніть увагу, що:
- Хеш, з якого отримано початкове число, є дорогою функцією виведення ключа, що робить пошук методом "грубої сили" недоцільним.
- Щоб домогтися лінійного посилення у добутих блоках, атакований повинен витратити квадратично-експоненціальне зусилля.
Випадкове початкове число застосовується для багаторазового вибору ролу. Перший обраний рол дозволяє стейкхолдерам майнити блок через одну хвилину, другий - через дві хвилини - і так далі.
Коли стейкхолдер розглядає початкове число і розуміє, що може викарбувати блок з високим пріоритетом в наступному циклі, він може внести заставу.
Щоб уникнути потенційно проблемної ситуації, коли жоден зі стейкхолдерів не вніс гарантійний депозит для майнінгу конкретного блоку, після 16-хвилинної затримки блок може бути видобуто без депозиту.
Облігації імпліцитно і негайно повертаються їх покупцям в будь-який ланцюг, де вони не майнять блок.
Наразі у нас вже майже готова робоча система proof-of-stake. Ми могли б визначити вагу ланцюга як кількість блоків, але, це відкриє шлях до корисливого майнінгу.
Так, ми вводимо схему підпису. Під час карбування блоку випадкове початкове число використовується для випадкового призначення 32 прав підпису 32 ролам.
Стейкхолдери, які отримали права підпису, спостерігають за карбуванням блоків і потім подають їхні підписи. Потім ці підписи включаються до наступного блоку, спробами майнерів забезпечити включення батьків до блокчейну.
Винагорода за підпис, отримана підписантами, залежить від пріоритету майнера, який майнив блок. Чим вищий пріоритет, тим вища винагорода за підпис. Таким чином, у підписанта є очевидний стимул підписати те, що він щиро вважає найкращим виробленим блоком. У нього також є стимул домовитися про те, який блок підписати, оскільки винагорода за підпис виплачується тільки в тому випадку, якщо блок врешті буде включено до ланцюга блоків.
Якщо блок з найвищим пріоритетом не видобуто (можливо, через те, що майнер не підключений до мережі), у підписантів може з'явитися стимул витримати паузу на випадок, якщо майнер запізниться. Тим не менш, інші підписанти потім можуть вирішити підписати блок з найкращим пріоритетом, і новий блок зможе включати ці підписи, виключаючи незгодних. Так, майнери навряд чи будуть слідувати цій стратегії.
І навпаки, ми могли б уявити ситуацію (рівновагу), в якій підписанти панікують і починають підписувати перший-ліпший блок, побоюючись, що інші підписанти зроблять це і що новий блок буде негайно побудован о. Це, однак, надмірно надумана ситуація, яка нікому не принесе вигоди. У підписантів немає стимулу думати, що ця рівновага ймовірна, не кажучи вже про те, щоб змінити код своєї програми, щоб діяти таким чином. Зловмисний стейкхолдер, який намагається зірвати операції, завдасть шкоди лише тим, хто спробує слідувати цій стратегії, оскільки інші навряд чи наслідуватимуть його приклад.
Вага - це кількість підписів.
Щоб уникнути подвійного карбування блоку або його подвійного підпису, майнер може передбачити донос для свого блоку.
Донос приймає форму двох підписів. Кожен підпис карбування або блоку підписує висоту блоку, що робить доказ неправомірних дій (зловживання) досить чітким.
Хоча ми можемо дозволити викривати злодіяння кому завгодно, насправді немає жодного сенсу дозволяти це комусь ще, окрім майнера. Дійсно, майнер може просто скопіювати будь-який доказ зловживання і видати його за власне викриття.4
Щойно сторону буде визнано винною в подвійному карбуванні або підписанні, страхова облігація втрачається.
Замість невитрачених виходів Tezos використовує облікові записи з відстеженням станів. Коли ці облікові записи вказують виконуваний код, вони стають відомими як контракти. Оскільки обліковий запис є типом контракту (у якого немає виконуваного коду), ми спільно називаємо обидва «контрактами».
У кожного договору є «менеджер», який у випадку з аккаунтом є просто власником. Якщо контракт позначено як витратний, менеджер може витратити пов'язані з ним кошти. Крім того, в кожному контракті може бути вказано хеш відкритого ключа, який використовується для підпису або майнінгу блоків в протоколі proof-of-stake. Закритий ключ може контролюватися або не контролюватися менеджером.
Формально контракт представляється у вигляді:
type contract = {
counter: int; (* counter to prevent repeat attacks *)
manager: id; (* hash of the contract's manager public key *)
balance: Int64.t; (* balance held *)
signer: id option; (* id of the signer *)
code: opcode list; (* contract code as a list of opcodes *)
storage: data list; (* storage of the contract *)
spendable: bool; (* may the money be spent by the manager? *)
delegatable: bool; (* may the manager change the signing key? *)
}
Дескриптор контракту - це хеш його початкового вмісту. Спроба створити контракт, чий хеш-код конфліктує з існуючим контрактом, є неприпустимою операцією і не може бути включена в дійсний блок.
Зверніть увагу, що дані представлені як тип-об'єднання.
type data =
| STRING of string
| INT of int
де
INT - 64-розрядне ціле число, а рядок - набір обмежених байтів. Ємність сховища обмежена байтами, вважаючи цілі числа за вісім байтів, а рядки - за їх довжину.Операція походження може використовуватися для створення нового контракту. Вона вказує код контракту і початковий вміст його сховища. Якщо дескриптор вже є дескриптором існуючого контракту, походження відхиляється (для цього немає жодних причин, крім як через помилку або зі злого нам іру).
Транзакція - це повідомлення, відправлене з одного контракту в інший. Дане повідомлення представляється у вигляді:
type transaction = {
amount: amount; (* amount being sent *)
parameters: data list; (* parameters passed to the script *)
(* counter (invoice id) to avoid repeat attacks *)
counter: int;
destination: contract hash;
}
Така транзакція може бути відправлена з контракту, якщо він підписаний з використанням ключа менеджера, або відправлена програмно за допомогою коду, що застосовується в контракті. Коли транзакцію отримано, сума додається до балансу цільового контракту; виконується код цільового контракту. Цей код може використовувати передан і йому параметри, читати і записувати сховище договору, змінювати ключ підпису і проводити транзакції для інших договорів.
Роль лічильника полягає в запобіганні повторних атак. Транзакція доступна лише тоді, коли показники лічильника контракту дорівнюють показникам лічильника транзакції. Після застосування транзакції лічильник збільшується на одиницю, запобігаючи повторного використання транзакції.
Транзакція також включає хеш-блок нещодавнього блоку, який клієнт вважає допустимим. Якщо зловмисникові вдасться форсувати тривалу реорганізацію за допомогою форку, він не зможе включити такі транзакції, що робить форк явно фальшивим. Це остання лінія захисту. TAPOS - відмінна система запобігання тривалих реорганізацій, але не достатньо підходяща для запобігання короткострокових подвійних витрат.
Пара (account_handle, counter) є майже еквівалентом невитраченого виведення в Bitcoin.
Оскільки зберігання даних вимагає великих витрат в мережі, мінімальна плата становить ꜩ 1 за кожен байт збільшення об'єму пам'яті. Наприклад, якщо після виконання транзакції до сховища було додано ціле число, а до існуючого рядка в сховищі було додано десять символів, ꜩ 18 буде виведено з балансу контракту і знищено.
Мова заснована на стеку з високорівневими типами даних, примітивами і суворій статичній перевірці типів. Натхненням для дизайну стали Forth, Scheme, ML і Cat. Повна специфікація набору інструкцій доступна в [@language]. Вона надає повний набір інструкцій, систему типів і семантику мови. Вона слугує точним посібником, а не простою передмовою.
Наразі ця система схожа на процес обробки транзакції Ethereum. Тим не менш, ми відрізняємося способом оплати. Ethereum дозволяє виконання довільно довгих програм, вимагаючи плату, яка лінійно збільшується з часом виконанням програми. Хоча це дає стимул для одного майнера перевірити транзакцію, на жаль, у інших майнерів, які також повинні її перевірити, такого стимулу немає. На практиці більшість цікавих програм, які можна використовувати для смарт-контрактів, дуже короткі. Таким чином, ми спрощуємо конструкцію, встановлюючи жорстке обмеження на кількість кроків, які дозволено в програмах.
Якщо обмеження виявляється занадто жорстким для деяких програм, вони можуть перервати виконання в кілька етапів і використовувати кілька транзакцій для повного виконання. Оскільки Tezos може бути змінено, це обмеження можна змінити в майбутньому, а вдосконалені примітиви можуть бути введені як нові коди операцій.
Якщо обліковий запис дозволяє, ключ підп ису може бути змінений шляхом видачі підписаного повідомлення із запитом на зміну.
Нам здається, ми створили привабливий seed протокол. Проте, справжній потенціал Tezos полягає в тому, щоб надати стейкхолдерам можливість прийняти рішення щодо протоколу, який, на їхню думку, підходить їм найбільше.
1. GHOST - це підхід, який впорядковує листки з урахуванням властивостей дерева. Такий підхід проблематичний як з теоретичних, так і з практичних міркувань. Майже завжди краще емулювати йому, вставляючи докази майнінгу до основного ланцюга.2. Навпаки, інфляція майнінгу Біткоіну зубожить власників біткоіну в цілому, а діяльність центрального банку збагачує фінансовий сектор за рахунок вкладників.3. Це стандартне обмеження на очікування максимуму W нормально розподіленої змінної.4. Доказ zero-knowledge дозволив би кожному отримувати вигоду з доносів на злодіяння, але той факт, що це приносить вигоду, не зовсім ясний.
Last modified 2yr ago