Ця стаття — переклад “The P2P layer” з сайту TezEdge
Також стаття доступна в перекладі російською мовою
Peer-to-peer (буквальний переклад “рівний до рівного”, або “учасник до учасника”, далі ми перекладаємо “peer” як “учасник”) мережі представляють особливий інтерес для криптовалют, оскільки вони добре працюють в рамках децентралізованої архітектури блокчейна. Вузол спілкується з іншими вузлами Tezos через мережу однорангових пліток (peer to peer gossip), щоб поширювати інформацію про стан мережі.
Скажімо, Аліса хоче брати участь у мережі Tezos. Її цікавить випічка (baking, процес створення блоків в блокчейні Tezos) або, можливо, вона розробник смарт-контракту і хоче отримати доступ до даних на блокчейні. Незалежно від її мотиву, для участі в мережі Tezos вона повинна налаштувати свій пристрій як вузол у мережі Tezos. Ця настройка відома як бутстрепінг (bootstrapping) і вона включає синхронізацію з мережею (завантаження поточного стану блокчейну). Цей процес розділений на дві частини:
Процес рукостискання
По-перше, перш ніж вона зможе навіть підключитися до шару P2P, Tezos вимагає від нових учасників виконати невелике proof of work завдання, завдяки якому вони створюють ідентифікацію свого вузла. Це завдання — контрзахід проти супротивників, які в іншому випадку можуть затопити мережу Tezos тисячами фейкових учасників (явище, відоме як атака Сивілли). Proof of work передбачає виявлення нонсу (nonce). Це proof of work завдання схоже (але набагато менш складне) на ті, які виконують майнери Біткойна, коли вони добувають нові блоки. Як тільки нонс виявлено, учасник отримує proofofwork_stamp. Ідентифікація вашого вузла базується на цьому нонсі.
Після вирішення proof of work задачі учасники генерують такі чотири типи інформації:
peer_id: ідентичність учасника, заснована на нонсі, розв’язаному в первинному proof of work завданні.
public_key: публічний ключ надається іншим колегам, які поєднують його зі своїми приватними ключами для створення ключів каналу, створюючи надійні зв’язки між учасниками.
secret_key: це власний приватний ключ учасника, який поєднується з публічним ключем інших колег, щоб утворювати ключі каналів, які використовуються для шифрування та розшифровки повідомлень, що надсилаються між учасниками.
proofofwork_stamp: штамп, який використовується для підтвердження дійсності нонса proof of work учасника.
2. Запит списку учасників з DNS
Аліса тепер підключається до мережі Tezos P2P. Тепер їй потрібно буде розібратися, до яких учасників підключитися. Вона запитує список учасників з сервера DNS, який потім доставляє список учасників, який містить IP-адреси учасників, до яких Аліса може підключитися. Хоча потенційно можуть бути мільйони учасників у мережі Tezos, вона підключається лише до кількох за один раз. Якщо необхідно, Аліса може пізніше розширити свій список учасників, попросивши в інших учасників їхні списки.
Тепер розібравшись, з ким вона зв’яжеться, Аліса повинна встановити надійний зв’язок з цими учасниками. Процес, відомий як рукостискання.
3. Рукостискання
Скажімо, Аліса хоче подати руку Бобу. Перед тим, як почнеться рукостискання, Аліса генерує нонс (не пов’язаний з нонсом з кроку №1), який служить лічильником повідомлень, що надсилаються Бобу. Так само Боб генерує нонс, який рахує повідомлення, які він надсилає Алісі. Тоді Аліса та Боб обмінюються своїми proof of work штампами, публічними ключами, нонсами, портами слухачів та списками версій.
Proof of work штамп
Це штамп, який був створений із proof of work завдання Алісою, виконаного на кроці 1.
Публічний ключ
Публічний ключ генерується на кроці 1 і використовується для шифрування повідомлень між учасниками.
Нонс
Цей нонс — унікальне значення, створене Алісою до того, як вона розпочинає рукостискання з Бобом. Він працює як лічильник. Аліса отримує нонс Боба (нонс Боб-Аліса) і використовує його для підрахунку кількості повідомлень, які вона отримала від Боба. Окрім нонсів, отриманих від Боба, Аліса вже має інший нонс, який вона створила перед рукостисканням — нонс Аліса-Боб, що використовується як лічильник повідомлень, які надсилаються Бобу.
Цей нонс не варто плутати з нонсом, який задіяний в proof of work задачі, що використовується для генерування ідентичності учасників.
Аліса перевіряє proof of work штамп Боба та навпаки. Якщо обидва штампи дійсні, Аліса використовує свій приватний ключ та публічний ключ Боба, щоб створити ключ каналу. Боб робить те саме зі своїм приватним ключем та публічним ключем Аліси. Для шифрування чи розшифрування повідомлень, якими вона обмінюється з Бобом, Аліса використовує свій ключ каналу в поєднанні з одним з нонсів, залежно від того, отримує вона (нонс Боб-Аліса) або надсилає (нонс Аліса-Боб) повідомлення.
Тепер вони обмінюються першим зашифрованим повідомленням, яке містить метадані. Після цього вони обмінюються ще одним повідомленням, яке містить Ack / Nack (Прийняти / Відмовити у з’єднанні).
Якщо Аліса отримує Ack від Боба і навпаки, рукостискання проходить успішно, і тепер вони готові розпочати обмін зашифрованими повідомленнями.
Аліса повторює цей процес з іншими учасниками, поки вона не встановить надійний зв’язок із достатньою кількістю учасників. Хоча у неї є надійний зв’язок лише з певною кількістю учасників, вона опосередковано пов’язана з усією розподіленою мережею Tezos, як зображено в анімації вище.
Коли канал формується, колеги обмінюються іншими типами повідомлень, включаючи:
Процес Бутстрепінгу
Тепер, коли підтримувати зв’язок безпечно, Аліса може почати завантажувати свій вузол. Їй треба оновити стан блокчейну, що означає завантаження історії всіх блоків, опублікованих дотепер на Tezos. Аліса запитує останній заголовок блока Боба.
Кожен заголовок блоку містить таку інформацію:
level: (рівень) висота блоку, від генезис блоку
proto: кількість змін протоколу після блоку генезису.
predecessor: (попередник) хеш попереднього блоку.
timestamp: мітка часу, коли стверджується створення блоку.
validation_pass: кількість пропусків валідації (також кількість списків операцій).
fitness: (придатність) послідовність послідовностей непідписаних байтів, що представляє заявлену придатність ланцюга, який закінчується в цьому блоці. Блок з більшою придатністю буде опублікований на користь блоку з меншою придатністю на тій же висоті блоку.
operations_hash: корінний хеш дерева Меркла списку кореневих хешів дерев Меркла для різних наборів операцій у блоці.
context: (контекст) хеш стану контексту після застосування цього блоку.
Подумайте про те, що Аліса не знає, який блок — останній. Це означає, що вона не може ідентифікувати одного учасника, який має останню версію і просто завантажити від нього. Натомість вона підключиться до всіх учасників (з якими вона успішно провела рукостискання) і почне запитувати історію всіх блоків (заголовків блоків та операцій) у кожного учасника. Кожен учасник по-різному підбирає історію свого блоку. Аліса починає з завантаження останнього блоку з найранішого зразка учасника. Алісі потрібно завантажити блоки хронологічно, від найдавніших до найновіших, відображаючи порядок, в якому ці блоки були опубліковані.
2. Завантаження операцій та заповнення блоків
Після завантаження заголовків, Аліса почне завершувати блоки завантаженням операцій всередині них, починаючи з найдавнішого блоку (блок рівню 1, блок відразу після генезис-блоку). Це означає всі операції, включаючи дані транзакцій.
Блок містить такі списки операцій:
Transactions: (Транзакції): транзакції токенів Tezos між користувачами Tezos. Це стандартна операція, що використовується для передачі токенів Tezos на рахунок.
Delegations: (Делегації): використовуються для делегування коштів пекареві (baker), зареєстрованому як делегат. Делегат може бути позначений як активний, чи пасивний. Пасивний делегат не може бути обраний для випічки (baking) або схвалення (endorsement).
Originations: (Створення): ця операція використовується для створення облікових записів. Оригінальні облікові записи мають адреси, починаючи з “KT1”.
Endorsement: (Схвалення): операція схвалення вказує голову ланцюга, з точки зору підтримувача певного слоту. Підтримувач вибирається випадковим чином для включення до блоку, який розширює голову ланцюга, як зазначено в цій операції. Блок із більшою кількістю схвалень покращує вагу ланцюга та збільшує ймовірність того, що ланцюг є канонічним.
Activations: (Активації) цей тип операцій використовується для активації рахунків, яким виділили токени Tezos за їх внеску в початковий збір коштів від Tezos Foundation.
Існують також інші види операцій, які рідше застосовуються:
Seed nonce revelation: (виявлення посівного нонсу: використовується для виявлення нонса, залученого до генерування ідентичності учасника.
Double endorsement evidence: (Докази подвійного схвалення): дуже рідкісний тип операції, який представляє докази подвійного схвалення, тобто коли є два схвалення для двох блоків на одному рівні блоку.
Double baking evidence: (Докази подвійної випічки) тип операції, що представляє докази подвійної випічки, в якій пекар намагався випекти (валідувати) два блоки на одному рівні блоку.
3. Застосування операцій в протоколі
Тепер, коли Аліса завантажила всі операції, вона застосовує їх до протоколу. Важливо зазначити, що протокол Tezos лежить поза шаром P2P. Протокол валідує блоки та операції в них. Після валідації, операції застосовуються, в результаті чого ведеться реєстр, який містить різну інформацію, включаючи баланси всіх користувачів Tezos. Ці дані потім зберігаються в модулі зберігання. Ми розглянемо як протокол, так і зберігання в наступних статтях.
