Aergo-Technical White Paper (переклад на Українську мову)
AERGO пропонує новий блокчейн протокол який спрямований на підтримку як публічних так і приватних розгортання блокчейнів. Ґрунтуючись на досвіді Blocko Inc. (Blocko) в великомасштабному створенні приватних блокчейнфв для корпоративних клієнтів, AERGO намір спеціалізуватися для реалізації корпоративних архітектур на основі блокчейн шляхом включення як нових, інноваційних, так і усталених технічних підходів до створення масштабованих розподілених систем баз даних.
вступ
Blocko впровадила більше 20 корпоративним клієнтам приватні блокчейни реалізовані на «Coinstack» 1. Coinstack заснований на модифікованій архітектурі Bitcoin і Ethereum Virtual Machine, яка виконує інтелектуальні контракти, має близьку подібність з QTUM2 і RSK3. У той час як Coinstack виконувався досить добре для навіть більш масштабних варіантів використання, таких як включення процесу аутентифікації для всієї клієнтської бази постачальника кредитних карт з мільйони щоденних пользователей4, він також дав уявлення про верхню межу Bitcoin протоколу, продуктивності і несумісності віртуальної машини Ethereum з корпоративної архітектурою підприємства і розробниками для неї. Щоб краще використовувати ланцюжок інструментів і архітектуру програми Coinstack, підтримуючи актуальні варіанти використання, Blocko почав працювати над AERGOSQL і AERGO. AERGOSQL являє собою інноваційний механізм смарт контрактів здатний використовувати реляційну модель даних і розробку смарт-контрактів з використанням інструментів і мов, знайомих корпоративним розробникам. Для докладного опису AERGOSQL, см. Technical whitepaper AERGOSQL, доступний за адресою https://AERGO.io/paper/. У цьому документі описуються проблеми, з якими стикається розгортання корпоративних блокчейнов, нові вимоги і архітектура відповідна цим вимогам.
ВИМОГИ ДО БЛОКЧЕЙНУ ПІДПРИЄМСТВА
Ми вважаємо, що корпоративний блокчейн працює в різних умовах починаючи з публічного, загального блокчейна. З розгортанням Coinstack, Blocko отримав з перших рук відомості про реальний впровадженні корпоративних блокчейнов. Ми описуємо ряд цих загальних вражень нижче: • На відміну від користувачів публічних блокчейнов, які зазвичай працюють з блокчейн нодамі на доступному устаткуванні, підприємства, як правило, запускають блокчейни на серверах з великими обчислювальними потужностями і простором зберігання даних. • Підприємства хочуть запускати блокчейн не тільки в хмарі, а й в приватному хмарі і голом металі машини (без проміжної ОС). Функціональність, що забезпечується приватним хмарою і голим металом, значно відрізняються від загальнодоступних хмарних сервісів. • У той час як публічні користувачі блокчейна запускають Ноди в невеликій кількості, підприємства хочуть працювати з великою кількістю нод для того, щоб скористатися горизонтальної масштабованість і доступністю. • Підприємствам потрібно більше контролю і функціональних можливостей, пов'язаних з адмініструванням блокової ланцюга ніж громадським блокчейн користувачам. • Хоча більшість програм, які потребують загальнодоступною ланцюжку блоків, автономні або залежать тільки від активів на самій блок-ланцюжку, підприємства хочуть підключати програми, запущені на блокчейне з багатьма зовнішніми і внутрішніми системами, такими як електронна пошта, SMS, бази даних, LDAP, і загальнодоступні дані.
Ми досліджуємо нижче ряд інших ключових ознак, які, на нашу думку, є невід'ємною частиною блокчейнов спеціалізованих для підприємства.
Масштабованість
Оскільки користувачі блокчейн підприємства, як правило, мають кращий доступ до обладнання з точки зору кількості так якості, реалізації корпоративного блокчейна повинні масштабуватися як горизонтально, так і вертикально.
Сумісність
Корпоративні середовища, як правило, залежать від різноманітних технологій, накопичених завдяки рокам роботи і впровадження корпоративного блокчейну і повинні працювати як з сучасними стандартними інтерфейсами, такі як OAuth так і старими, власними інтерфейсами, такими як Active Directory.
СЕРЕДОВИЩЕ РОЗРОБКИ
Оскільки основна частина розвитку підприємства, як правило, орієнтована на роботу, мало можливостей для експериментування і вивчення нових мов і інструментів для розробників. Замість примусу розробників вивчати нові мови для створення інтелектуальних контрактів, необхідним є дотримання корпоративних реалізацій щоб дозволити розробникам використовувати свої існуючі знання та досвід за допомогою знайомих інструментів. У той же час певні ресурси веб-розробників, які сприймаються як щось само собою зрозуміле, наприклад, необмежений доступ до інтернету, недоступні для розробників підприємств. В результаті блокчейн реалізацій підприємств необхідно забезпечити більш повну середу розробки за допомогою інтегрованих середовищ, SDK і еталонних архітектур, ніж в реалізації публічних блокчейнів.
КОНФІДЕНЦІЙНІСТЬ ДАНИХ
Підприємства стикаються з необхідністю забезпечення суворої безпеки даних щодо конфіденційної інформації, а також особистих даних клієнта / співробітника. Часто прагнення до безпеки даних є більш важливим міркуванням, ніж незмінність і цілісність даних, що надаються блокчейном. У той час як одним із способів забезпечення безпеки даних в громадських блокових ланцюгах є впровадження шифрування і дешифрування на рівні додатку. Для впровадження корпоративних блокчейнов необхідно забезпечити більш надійний, цілісний підхід до забезпечення безпеки даних.
ПІДГОТОВКА І АДМІНІСТРУВАННЯ
У той час як веб-розробники раді використовувати Vagrant або Docker на своїх ноутбуках, корпоративним ІТ зручніше працювати з великими гарматами, такими як Tivoli Provisioning Manager, OpenStack або Kubernetes. Реалізації корпоративного блокчейна повинні підтримувати інтеграцію з існуючими технологіями для надання управління в корпоративних ІТ і надати набагато більш багатий набір функціональних можливостей для адміністрування. Експорт та імпорт, резервне копіювання даних, моніторинг, ведення журналу та міграція даних є чи типові функції, ігноровані публічними реалізаціями блокчейн, але важливими в корпоративному середовищі.
ЗБЕРІГАННЯ структурована і неструктурованих даних
Смарт-контракти забезпечують основу функціональності як на публічному блокчейне, так і на блокчейне підприємства. На відміну від додатків, побудованих на публічних блокчейнах з доступом до хмарного сховища і постачальниками CDN, додатки на корпоративних блокчейнах повинні бути більш самостійними і корпоративні версії блокчейна повинні реалізувати їх з більшою функціональністю як для структурованих так і неструктурованих сховищ даних.
Архітектура AERGO
AERGO сконструйовано для того щоб бути цілісною, універсальною платформою, мостом між публічними блокчейнамі і приватними блокчейнамі. Для того, щоб бути ефективним в обох середовищах, AERGO повинен бути компактним і гнучким. Для обслуговування робочих навантажень різних замовників, з потенційним доступом мільйонів одночасних користувачів, тим же набором вузлів. AERGO намір запозичити багато концепції з традиційних баз даних і розподілених обчислень.
Розподіл у КАТАЛОГ
Розподілений каталог (DD) є ядром функціональності, і призначений, щоб використовуватися в якості фундаменту для всієї реалізації AERO. Кожен DD в репозиторії пропонується для управління незалежним ізольованим простором імен. Кожне простір імен містить інформацію про різні гілках і тегах, які перебувають в репозиторії, а також про валідності різних ідентифікаторів на блокчейне. Кожен DD повинен стати блокчейном сам по собі, зі своєю власною генерацією блоків. На відміну від звичайних блоків, блоки DD обмежені в розмірах при відносно довгому інтервалі створення між ними; оскільки DD використовуються для управління метаданими, вони повинні бути компактними. DD можна порівняти зі словниками даних в базах даних, zookeeper для Hadoop або etc для CoreOS в його ролі і функціональності
a. Древо Життя (ToL)
Пропонується, щоб простір імен ToL DD містило інформацію про всі гілках сховища, а також їх генезісние блоки або кореневі блоки. Простір імен ToL містить 8 інформацію про останньому блоці кожної гілки, а також; після тега head постійно містить тег останнього блоку кожної гілки.
b. Служба розподілених каталогів (DDS)
Простір імен DDS пропонується щоб утримувати записи для різних сутностей на блокчейне: їх відкриті ключі і валідність, а також пов'язані ролі і дозволу. Простір імен DDS є основою для управління доступом до репозиторіїв AERGO. Кожен об'єкт може бути або client-actor, або сертифікатом сервера. Для об'єктів з сертифікатом сервера, DDS може служити як списком відкликаних сертифікатів, так і DNS з інформацією про маршрутизації. AERGOFS, пропонована розподілена файлова система - компонент AERGO, буде підпорядкований DDS. DDS відстежує томи даних, що містяться в кожному примірнику AERGOFS. У свою чергу AERGOFS можна використовувати для зберігання блоків і індексів для різних гілок в репозиторії. Простір імен DDS формує основу ідентифікації для нод беруть участь в основному процесі консенсусу.
АЛГОРИТМ КОНСЕНСУСУ
a. основний Консенсус
Основний алгоритм консенсусу призначений для використання при побудові DDS. Основний алгоритм консенсусу і DDS є взаємозалежними, так як основний алгоритм консенсусу потрібен для доступу до DDS в DD, щоб задіяти видобуток нових блоків. Запропонований алгоритм консенсусу ядра AERO делегується Proof of Stake (DPOS) 5. DPOS є кращою консенсусної моделлю, оскільки: • Ми вважаємо, що він забезпечує масштабованість і простоту роботи, необхідні основним консенсусом • DPOS працює в припущенні, що можуть статися реорганізації блоків, і є оптимальним для основної інфраструктури AERGO.
b. призначені для користувача консенсусу
За замовчуванням кожен репозиторій використовує основний консенсус. Оскільки AERGO намір надати сумісна архітектура для консенсусного алгоритму, різні схеми узгодженого алгоритму можуть використовуватися замість основного консенсусу. Зокрема, RAFT (для розробки) і PBFT (для суворого порядку) корисні для розробки і управління різними службами. Використовуючи ту ж інструментальну ланцюжок для побудови інтелектуальних контрактів, призначений для користувача консенсусний алгоритм також можна використовувати для кожного сховища. Призначена для користувача логіка може визначати, як відбуваються такі події, що відбуваються в блокової ланцюжку:
• Створення блоку і його перевірка
• Передач блоку і його пріоритет
Оскільки розгалуження і злиття блоків також можуть сприйматися як події реорганізації блоків, так само політика для реорганізації блоків використовується і для розподіленого управління версіями. З точки зору управління версіями політика реорганізації блоків називається "Узгоджене Злиття" - "Consistent Merging".
СМАРТ КОНТРАКТИ
AERGO підтримує мульти парадигму, засновану на плагінах інтелектуальну інфраструктуру контрактів. Кожен контракт може бути виконаний або запитано client-actor або іншим смарт-контрактом. Оскільки AERGO забезпечує дозволяє інтерфейс з максимальною сумісністю між інтелектуальними контракти, контракти, написані для Ethereum Virtual Machine, Fabric Chaincode, або AERGOSQL може використовуватися один з одним.
a. AERGOSQL Канонічний спосіб написання смарт-контракту для AERGO забезпечує AERGOSQL, надає реляційну модель даних для зберігання і доступу до даних і SQLподобний мову сценаріїв для написання смарт-контрактів. Використовуючи AERGOSQL, інтелектуальні контракти можуть бути написані з використанням знайомого синтаксису SQL.
b. сумісність
Завдяки своїй підключається архітектурі AERGO призначений для підтримки різних реалізацій інтелектуальних контрактів. AERGO успадковує сумісність Ethereum Virtual Machine від Blocko Coinstack спочатку. Fabric Chaincode підтримується завдяки легкої віртуалізації, такий як Docker. У початковий випуск AERGO реалізовано управління з використанням go-Ethereum's EVM. Використання evmjit для підвищення продуктивності планується в майбутньому.
ІНТЕЛЕКТУАЛЬНІ оракул
AERGO підтримує інтеграцію смарт-контрактів в ізольованих блокчейнах, а також інтелектуальні контракти, які враховують зовнішні події і фактори за допомогою впровадження інтелектуальних оракулів. Розумні оракули прагнуть забезпечити такі функціональні можливості:
Дозволити смарт-контрактами використовувати дані з застарілих систем, таких як Active Directory •
Дозволити смарт-контрактами ініціювати події в зовнішніх службах, таких як електронна пошта або SMS.
З точки зору розумного контракту розумні оракули - це зовнішні фактори, які пов'язані з конкретним інтелектуальним контрактом; розумні оракули реагують на зміни в пов'язаному смарт-контракті і вводять дані в якості відгуку. У деяких випадках розумні оракули можуть ініціювати інтелектуальні контракти автономно. З точки зору dApp інтелектуальні оракули реалізують мікрослужби, які надають зовнішні функціональні можливості, необхідні dApp. Так як розумні оракули і dApps можуть спілкуватися поза мережею, мікро-послуги, що надаються розумними оракулами, можуть використовуватися для реалізації зовнішньої комунікація, необхідної інтелектуальним контрактами; загальний варіант використання включає обмін токенами з перевіркою достовірності між інтелектуальним оракулом і dApp.
ізоморфні Контракти
Інструментарій розробки AERGO намір підтримувати изоморфное виконання інтелектуального контракту через автоматичне створення коду. . Ізоморфний код, створений з інтелектуального контракту, може отримати доступ як до dApp, так і до розумних оракулам, забезпечуючи прозорий доступ до інтелектуального контрактом та базової структурі даних. Ізоморфне виконання смарт-контракту має вирішальне значення для продуктивності розробки смарт-контракту та додатків і сервісів на їх основі.
Розподілена файлова система
AERGOFS є основним компонентом платформи AERGO, забезпечуючи функціональність розподіленої файлової системи. AERGOFS залежить від DD для управління метаданими, пов'язаними з файлами метадані про кожен файл, включаючи фізичне місце розташування, хеш-значення і різні статистичні дані, зберігається в DD. Хоча інтелектуальні контракти забезпечують структуроване зберігання даних за допомогою схеми даних і індексів даних для більш швидкого запиту, AERGOFS намір надати неструктуровану можливість зберігання даних AERGO. AERGOFS надає простий HTTP-інтерфейс, що дозволяє отримувати доступ як від розумних оракулів на серверному середовищі так і dApps, запущених в веб-браузерах.
Розподіл контролю ВЕРСІЙ
На відміну від традиційних блокчейнов, AERGO розглядає Форк і реорганізації блоків як основні особливості блокчейна, а не подразнюють побічні ефекти. Прийнявши Gitподобние моделі даних і структури команд, AERGO прагне забезпечити можливість спільної роботи з даними так само просто, як і спільну роботу з вихідним кодом.
AERGO підтримує створення публічних і приватних репозиторіїв. Кожен репозиторій може бути іменованих або неіменованого. Іменований репозиторій має пов'язаний публічний об'єкт в AERGO Public Network's Distributed Directory. Безіменний репозиторій не має такого зв'язку. Як і публічний репозиторій Git, публічний репозиторій AERGO призначений для читання і запису, або вибіркових прав для анонімних користувачів. Початкова конфігурація полягає в створенні публічного сховища AERGO з анонімним доступом тільки для читання. Приватний репозиторій призначений бути репозиторієм AERGO з включеним повним контролем доступу, як для читання, так і для запису сховища. Публічний або приватний репозиторій - це приватний блокчейн в тому сенсі, що він працює незалежно від AERGO Public Network. В результаті, AERGO Token не має ніякого застосування в державних або приватних репозиторіях.
У кожному сховища можуть бути створені різні гілки на різні снапшоти в статусі блокчейна. На ділі поняття «найкраща ланцюг» в AERGO аналогічно поняттю головна ланцюг.
СИНТАКСИС І СЕМАНТИКА
AERGO прагне забезпечити дружній синтаксис і семантику для користувачів, які звикли до систем управління версіями таким як Git. Така функціональність доступна через клієнта AERGO CLI, так і RPC APIs.
автоматичне Злиття
За замовчуванням автоматичне злиття є очікуваним процесом злиття двох гілок. Автоматичне злиття аналогічно блокчейн-реорганізації. В цьому випадку злиття блоки джерела поділяються на транзакції і поглинаються в формується пул цілей. В кінцевому рахунку злиття пулу призводить до створення нового блоку, приєднаного до кращого блоку. В процесі транзакції, несумісні з цільової гілкою злиття, автоматично виключаються з нового блоку ..
узгоджене Злиття
Узгоджене злиття відбувається тільки для гілок створених з урахуванням логіки узгодженого злиття. Узгоджене Злиття аналогічно функціям злиття, що надаються системою управління версіями таких систем як Git. На відміну від автоматичного злиття, яке за замовчуванням скасовує неузгоджені транзакції, Узгоджене Злиття залежить від визначеної логіки вирішення конфліктів для управління суперечливими транзакціями. Логіка вирішення конфліктів реалізована у вигляді смарт-контракту системного рівня.
МАСШТАБОВАНІСТЬ
AERGO використовує три різних підходи до досягнення масштабованості. • Поділ на домени • вертикальне маштабування (Scale up) • горизонтальне маштабування (Scale out)
РОЗДІЛЕННЯ НА ДОМЕНИ
Поділ на домени є найбільш базовою стратегією масштабування, використовуваної AERGO. Поділ на домени досягається за допомогою функції управління розподіленої версією (DVC) AERGO. На відміну від звичайних реалізацій блок-ланцюжків, AERGO може розгалужувати і об'єднувати свої дані через гілки вільно. В результаті розподілена книга може бути розділена як логічно, так і фізично через різні репозиторії. Такий підхід вже успішно використовується розподіленими системами контролю версій, такими як Git і Mercurial. Наприклад, гігантська служба, така як GitHub, може розміщувати десятки мільйонів репозиторіїв. Однак ефективність доменного розбиття залежить від структури і використання даних. Коли одному сховища необхідно обробляти необмежене розширення даних, поділ даних за допомогою розгалуження дуже складно. В результаті два додаткових підходу до масштабування надаються AERGO для обробки величезного обсягу даних для одного сховища.
Горизонтального масштабування (SCALE OUT)
Стратегія масштабування AERGO залежить від функціональності, що надається AERGOFS. AERGOFS виконує дві ролі для досягнення масштабованості: (1) AERGOFS може служити шаром зберігання для блоків і індексів кожного вузла. спосіб використання AERGO-вузлів (нод) AERGOFS дуже схожий на те, як HDFS використовується HBase. З AERGOFS кожен вузол може зберігати необмежену кількість блоків і індексів і функціонувати як гігантський uber-вузол. (2) AERGOFS може функціонувати як сховище об'єктів, подібне S3. У цій конфігурації, AERGOFS забезпечує незмінний і довговічний доступ до двійковим даними. В цьому випадку, інтелектуальні контракти AERGO повинні зберігати локатори для доступу до файлів, що зберігаються на AERGOFS.
ВЕРТИКАЛЬНОЕ маштабування (SCALE UP)
Самий прямий і простий підхід, який AERGOFS прагне використовувати для масштабованості, через оптимізацію одного вузла. Хоча горизонтальне масштабування добре працює для великого обсягу даних, воно не відповідає реалістичним тестів. З появою дешевої пам'яті, швидких сховищ даних, таких як SSD, і обмежену пропускну здатність мережі, оптимізація одного вузла дуже ефективна для повсякденних систем. Blocko дізнався цей дорогий урок, забезпечуючи реалізацію блокчейна в реальному житті, в світі підприємств, і AERGO, за допомогою Blocko, прагне запозичити багато ідей і прийомів від Blocko Coinstack в цій області. Для того, щоб зробити кожен вузол максимально ефективним, вузли AERGO планується оснащувати ефективним мережевим стеком і оптимізованим механізмом зберігання даних з розширеними можливостями введення-виведення.
Мережевий стек AERGO забезпечує нестандартну високо-паралельну мережеву структуру, яка здатних обслуговувати велику кількість вузлів зі складною топологією як на голому металі так і в хмарі. • AERGOSQL формує основу високопродуктивного механізму зберігання, необхідного AERGO. • Вузли AERGO використовують многопоточну архітектуру для використання многоядерной середовища.
УПРАВЛІННЯ паралелізм
КОНФІДЕНЦІЙНІСТЬ
ІЗОЛЯЦІЯ ДАНИХ
AERGO намір дозволити користувачам з відповідними правами доступу, доступ до git-подібним приватним репозиторіїв. Створюючи нову гілку з віддаленої батьківської гілки, користувачі можуть зберегти щойно створену блоки в приватній гілки, такі, щоб вони були ізольовані від загального доступу. Тільки з дозволами на розміщення в певному репозиторії гілки можуть отримати доступ до блоків.
ОБМІН ДАНИМИ
Певну галузь можна синхронізувати з віддаленими репозиторіями для обміну даними. В цьому випадку приватні гілки сховища можуть вибирати відповідні коммітов з публічних сховищ або об'єднати весь набір змін автоматично.
паралелізм
Продуктивність конкретного блокчейна залежить від ефективності створення та обміну новими блоками і часу, необхідного кожному вузлу для перевірки нових блоків. Процес створення блоку включає розгляд всього розподіленого консенсусного протоколу блокчейна. Звісно ж, що процес валідації блоків, використовуваних у складі різних розподілених консенсусних протоколів іноді погано розроблений і здійснений. У той час як неефективні вузли прийнятні для реалізації блокчейнов споживчого класу, таких як Bitcoin або Ethereum, корпоративного класу блокчейни такі як AERGO вимагають більш надійної продуктивності, близькою до режиму реального часу. В результаті, кожен вузол повинен бути реалізований з найбільшою ефективністю, як і сам протокол консенсусу. AERGO намір впровадити концепцію паралелізму на різних стадіях обробки блоків щоб домогтися максимальної продуктивності. Паралелізм передбачає ретельний аналіз залежностей між транзакціями, включеними в кожен блок і ефективну архітектуру, натхненну SEDA (staged event-driven architecture).
АНАЛІЗ ЗАЛЕЖНОСТЕЙ
Щоб гарантувати узгодженість між вузлами, реалізації блокчейна зазвичай використовують політику сериализации виконання всіх транзакцій і доступних блоків. В результаті швидкість обробки блоків блокчейн-вузлом залежить від часу, який потрібен для обробки кожної транзакції незалежно від кількості доступних процесорів або пам'яті. Для забезпечення можливості паралельної перевірки транзакцій і блоків, AERGO намір виконати аналіз залежностей між транзакціями і блоками і створення структури даних, відомої як Детерміноване Дерево Транзакцій.
Залежно від розміру блоків, кожне DTT може мати відгалуження від пари транзакцій в довжину до тисяч транзакцій в довжину. Аналогічним чином, DTT може мати різну кількість гілок. Дійсність DTT може бути перевірена тільки шляхом фактичного виконання набору DTT проти набору стану машини. Версія DTT може бути оптимізована в іншу версію шляхом перетворення дерева Щоб створити DTT для набору транзакцій в реалістичні часові рамки, AERGO використовує заснований на правилах підхід для аналізу транзакцій. Більш складні підходи, включаючи машинне навчання планується провести в майбутніх випусках AERGO.