AERGO White Paper (український переклад)
AERGO-це безперечно новий протокол blockchain, який спрямований на розвиток як державних, так і приватних бізнес моделей на блокчейне. грунтуючись на досвіді Blocko Inc's (Blocko) проект забезпечує широкомасштабний, рівень виробництва приватного блокчейна для визнаних корпоративних клієнтів, AERGO преднозначен спеціально для реалізації корпоративної архітектури на основі блокчейна, що об'єднує, інноваційні та усталені технічні підходи до побудови масштабованих розподілених систем баз даних.
ВІДМОВА ВІД ВІДПОВІДАЛЬНОСТІ
Ця стаття відноситься до проекту AERGO і його слід розглядати в поєднанні з наявним. технічним докуменов https://AERGO.io, Цей та інші документи можуть бути змінені або замінені в будь-який час, без попереднього повідомлення про будь-які зміни.
Ця стаття описує майбутній проект.
Цей документ містить прогнози, засновані на переконаннях AERGO Limited, приватної компанії в Гонконзі (CR No. 2713137) (AERGO Limited), а також деякі припущення, зроблені і доступної інформації в AERGO Limited.AERGO, як це передбачено в даному технічному офіційному документі знаходиться в стадії розробки і постійно оновлюється, включаючи, але не обмежуючись ключовими функціями управління і технічними можливостями. AERGO токен (Aergo Token) передбачає і відноситься до розробки і використання експериментальних платформ (програмне забезпечення) і технології, які можуть бути не реалізовані, зазначеному в цьому офіційному документі. Коли AERGO завершиться, може значно відрізнятися від мережі, викладеної в цьому документі. Чи не дається ніяких запевнень чи гарантій щодо досягнення або обґрунтованості будь-яких планів, майбутніх прогнозів або перспектив і ніщо в цьому документі не є обіцянкою чи поданням про майбутнє.
Прийнятні покупці
Інформація, що міститься в цьому документі надається в приватному порядку деяким потенційним покупцям і не призначений для читання кимось іншим. Право на отримання не гарантується і може зазнавати обмежень.
Немає пропозицію підкарантинних матеріалів
Платформа AERGO, AERGO Токен або будь-який маркер, який працює на ньому не призначене для подання безпеки або будь-якого іншого регульованого продукту в будь-якій юрисдикції. Даний документ не є пропозицією або запрошення цінних паперів або будь-якого іншого регульованого продукту, ні для просування по службі, запрошення для інвестиційних цілей. Умови покупки не призначені, щоб бути пропозицією документа фінансових послуг або проспект будь-якого роду.
AERGO Токен не представляє часткові, акцію, паї, ліцензійні платежі чи права на капітал, прибуток, повернення або дохід в платформі або програмному забезпеченні в AERGO Limited або будь-яку компанію або інтелектуальної власності, пов'язану з платформою або будь-яким іншим державним або приватним підприємством, корпорації
Цей технічний технічний документ не є порадою
Цей технічний технічний документ не є радою з купівлі AERGO токена. Не слід покладатися на технічний документ при вирішенні про покупку.
Попередження про ризики
Придбання AERGO токені і участь в AERGO маркерів продажу несе в собі значні ризики. Перед покупкою AERGO токен, ви повинні ретельно оцінювати і приймати до уваги ризики, в тому числі ті, які перераховані в будь-який інший документації.
Думки, висловлені в даному технічному офіційному документі
Погляди і думки, висловлені в даному технічному офіційному документі, належать AERGO Limited і не відображають офіційну політику або позицію будь-якого уряду, влади або державного органу (включаючи, але не обмежуючись будь-якої регулюючий орган будь-якої юрисдикції) в будь-якій юрисдикції. Інформація, що міститься в даному технічному офіційному документі, заснована на джерелах вважаються надійним, але немає ніякої гарантії щодо їх точності або повноти.
Англійська є офіційною мовою цього офіційного документа
Цей технічний технічний документ і пов'язані з ним матеріали випускаються тільки на англійській мові. Будь-переклад тільки для довідкових цілей і не сертифікований AERGO Limited або будь-якого іншого особи. Якщо є якесь невідповідність між перекладом і англійською версією цим технічного офіційним документа, англійська версія превалює.
Чи не приналежність третьої сторони або схвалення
Посилання в даному технічному офіційному документі конкретних компаній і платформи тільки в ілюстративних цілях. Використання будь-якої компанії і / або назви платформ і товарних знаків не має на увазі будь-яких зв'язків з, або схвалення з боку, жодна з цих сторін.
Ви повинні отримати всю необхідну професійну консультацію
Ви повинні проконсультуватися з юристом, бухгалтером, професійним податковим та / або будь-яких інших професійних консультантів по мірі необхідності, для визначення доцільності придбання AERGO токен або іншого способу брати участь в проекті AERGO
Цей технічний технічний документ не був розглянутий будь-яким регулюючим органом в будь-якій юрисдикції. Посилання в цій статті на конкретні компанії, мережі та / або потенційні випадки використання тільки в ілюстративних цілях. Крім явно зазначених партнерів або постачальників, таких як Blocko, використання будь-якої іншої компанії і / або назви платформ і товарних знаків не має на увазі будь-яких зв'язків з, або схвалення з боку, будь-який з цих сторін.
Передісторія
Blocko поставила понад 20 корпоративних клієнтів з його власної реалізації приватних blockchain «Coinstack.» 1 Coinstack базуються на модифікованій архітектурі Bitcoin і Ефіріум Virtual Machine виконують смарт-контракти, маючи близьку подібність з Qtum 2 і RSK. 3 У той час як Coinstack виконується досить добре для ще більш масштабними сценарії використання, такі як харчування процесу аутентифікації для всієї клієнтської бази провайдера кредитних карт з мільйонами щоденних користувачів, 4 вона також дала уявлення про верхню межу цього протоколу Bitcoin про продуктивність і несумісність в Ефіріуме віртуальної машини з архітектурою підприємства і розробниками за ними.
Для того, щоб більш ефективно використовувати ланцюжок інструментів і архітектуру програми в Coinstack підтримки реальних сценаріїв використання, Blocko почав працювати над AERGOSQL і AERGO. AERGOSQL є інноваційним, новий розумний контракт двигун здатний використовувати реляційну модель даних і розробки смарт-контрактів з використанням інструментів і мов, відомих корпоративним розробникам. Детальний опис AERGOSQL см технічний технічний документ AERGOSQL доступні на https://AERGO.io/paper .
У даній статті описуються проблеми, з якими стикаються корпоративні впровадження blockchain і нові вимоги і архітектури, здатні вирішувати ці проблеми.
ENTERPRISE BLOCKCHAIN
ВИМОГИ
Ми вважаємо, що підприємство blockchains працює при різних припущеннях і умовах із загальнодоступних, загальних blockchains. З розгортанням Coinstack, Blocko отримав експозицію перших рук реальності підприємства blockchain усиновлень. Наведемо деякі з цих загальних припущень нижче:
- На відміну від користувачів громадських blockchain, які зазвичай працюють blockchain вузлів на апаратному забезпеченні, підприємство, як правило, працювати blockchain на сервер класу апаратних кошти з величезною обчислювальною потужністю і зберіганням.
- Компанії хочуть працювати blockchain не тільки на хмарі, а на приватному хмарі і голометалліческіх машин, а також. Функціональні можливості, що надаються приватним хмарою і голометалліческіх умовах істотно відрізняються від послуг громадського хмари.
- У той час як користувачі громадського blockchain запускають blockchain вузли в невеликій кількості, підприємства хочуть запустити велику кількість blockchain вузлів для того, щоб скористатися переваг
- Компаніям потрібні більше контролю і функції, пов'язані з управлінням blockchain, ніж користувачі публічних blockchain.
- У той час як більшість додатків, що працюють на громадському blockchain самодостатні або залежить тільки активи на самому blockchain, підприємства хочуть підключати програми, що працюють на blockchain з багатьма зовнішніми і внутрішніми системами, такими як електронна пошта, SMS, бази даних, LDAP і загальнодоступними дані .
Ми досліджуємо нижче ряд інших ключових атрибутів, на нашу думку, які є невід'ємною частиною підприємства зосереджено blockchains.
Масштабованість
Оскільки підприємство blockchain користувачі, як правило, мають більш широкий доступ до обладнання з точки зору як кількості, так і якості, реалізації підприємства blockchain необхідно масштабувати як по горизонталі, так і по вертикалі.
Сумісність
Enterprise середовища, як правило, залежать від різноманітних технологій, накопичених за роки роботи і реалізації blockchain підприємства повинні працювати як з сучасними, стандартними інтерфейсами, такі як OAuth так і старими інтерфейсами, таких як Active Directory.
СЕРЕДОВИЩЕ РОЗРОБКИ
Оскільки в більшості підприємств, як правило, мало місця для експериментів і вивчення нових мов і інструментів для розробників; замість того, щоб змушувати розробників вивчати нові мови для створення смарт-контрактів, необхідно дозволити розробникам використовувати існуючі знання та досвід знайомого набору інструментів.
У той же час, деякі ресурси і веб-розробники вважають само собою зрозумілим, такі як необмежений доступ в Інтернет, не доступність корпоративних розробників. В результаті реалізації підприємства blockchain необхідно надати більш комплексну середу розробки з IDEs, SDKs і еталонними архітектурою, ніж реалізації державних blockchain.
КОНФІДЕНЦІЙНІСТЬ ДАНИХ
Компанії стикаються з необхідністю забезпечення підвищеної безпеки даних з точки зору конфіденційної інформації, а також клієнта / працівника персональних даних. Часто прагнення до безпеки даних є більш важливим фактором, ніж незмінності і цілісності даних, наданих blockchain. У той час як один із способів забезпечити безпеку даних на публічному blockchains є реалізація шифрування і дешифрування шару на рівні додатків. реалізації корпоративних blockchain необхідно забезпечити більш надійний, цілісний підхід до захисту даних.
ЗАБЕЗПЕЧЕННЯ І УПРАВЛІННЯ
У той час як веб-розробники з задоволенням використовують Vagrant або Docker на своїх ноутбуках, корпоративних ІТ більш комфортно з Tivoli Provisioning Manager, OpenStack або Kubernetes. Реалізації Enterprise blockchain повинні підтримувати інтеграцію з існуючою технологією для надання та управління на підприємстві ІТ і забезпечити більш багатий набір функціональних можливостей для адміністрацій. Експорт та імпорт, резервне копіювання даних, моніторинг, реєстрацію та міграції даних є типовими ознаками упущення реалізації громадських blockchain, в корпоративному середовищі
Структурованому і неструктурований ЗБЕРІГАННЯ ДАНИХ
Смарт-контракти забезпечують основу функціональності як на громадському blockchain і підприємства blockchain. На відміну від dApps, побудованого на громадських blockchains з їх доступом до хмарного зберігання і провайдерам CDN, dApps на blockchains повинна бути реалізована самодостатнім і blockchain потрібно розмістити їх з багатими функціональними можливостями як для структурованого та неструктурованого зберігання даних.
Архітектура
Малюнок 1. Архітектура AERGO
AERGO призначений для цілісної, багатоцільовий платформи, що усуває розрив між державним і приватним blockchains. Для того щоб бути ефективним в обох середовищах, AERGO призначено бути компактним, але гнучкий в дизайні.
Для того, щоб обслуговувати робочі навантаження на багато користувачів з потенційно мільйони користувачів, які одночасно отримують доступ і той же набір вузлів, AERGO намір запозичити багато концепції від традиційних конструкцій баз даних і розподілених обчислень.
Директория дистрибуції
Директория дистрибуції (DD) є основною функцією, яка призначена для використання в якості будівельного блоку для всієї реалізації AERGO.
Кожен DD в сховище пропонуються управляти не залежними, ізольованими іменами. Кожне простір імен містить інформацію про різні галузі і тегів, які перебувають в сховище, а також дії різних ідентифікаторів на blockchain.
Кожен DD призначений бути blockchain сам по собі, зі своїм власним блоком генезу. На відміну від звичайних блоків, DD блоки обмежені розміром з відносно тривалого інтервалу створення між ними; оскільки DDs використовується для управління метаданими, вони повинні бути компактними.
DD порівняємо з словниками даних в базах даних, для Hadoop, або etcd для CoreOS в своїй ролі і функціональності.
а. Древо життя (TOL)
ToL імена з DD пропонуються містити інформацію про всі філіях в сховище, а також їх генезис блоках або кореневих блоках. Інформація про тегах управляються усередині простору імен ToL, а також. В результаті, простір імен TOL містить інформацію про блок кожної гілки, а також; після тега head постійно тримає трек кращого блоку кожної гілки.
б. Розподілена служба каталогів (DDS)
Простір імен DDS. пропонується містити записи для різних об'єктів на blockchain; їх відкриті ключі і термін дії, а також пов'язані ролі і дозволу. Простір імена DDS призначене служити в якості основи для контролю доступу для AERGO сховищ.
Кожен об'єкт може становити або клієнт-учасник або сертифікат сервера. Для осіб з сертифікатами сервера, DDS може служити і списку відкликаних сертифікатів і DNS з інформацією про маршрутизації.
AERGOFS, пропонований компонент розподіленої файлової системи AERGO, призначений бути залежними від DDS, оскільки DDS відстежує обсяги даних, що складаються кожний екземпляр AERGOFS. У свою чергу, AERGOFS може бути використаний для зберігання блоків і індексів для різних гілок в сховище.
Простір імен DDS формує основу для ідентичності вузлів, щоб брати участь в процесі консенсусу сердечника.
КОНСЕНСУС алгоритми
а. основний консенсус
Алгоритм консенсусу ядро призначене для використання в будівництві DDS. Ядро консенсус алгоритм і DDS взаємно залежні, так як алгоритм основного консенсусу необхідний для доступу до DDS в DD для того, щоб видобутку нових блокоПредлагаемий основний консенсус алгоритм AERGO делегований Доказ колі (DPOs) 5.
DPOs є кращою моделлю консенсусу, тому що, в цілому
- Ми вважаємо, що забезпечує масштабованість і простоту експлуатації, необхідну основному консенсусу;
- DPOs працює в припущенні, що блок реорганізації можуть трапитися, що означає, що це оптимальний алгоритм для харчування базової інфраструктури AERGO.
б. Визначається користувачем Консенсус
За замовчуванням, кожен зі сховища використовує базовий консенсус. Оскільки AERGO намір забезпечити підключається архітектуру для алгоритму на основі консенсусу, а також різні модулі алгоритму можна використовувати загальноприйнятий замість базового консенсусу. Слід зазначити, що рафтах (для розвитку) і PBFT (для суворого впорядкування) корисні для розробки і запуску різних послуг.
Використовуючи той же набір інструментів для побудови інтелектуальних контрактів, алгоритм консенсусу визначається користувачем може бути використаний для кожного сховища, а також. Певний користувач логік може управляти як такі події відбулися і управляються в blockchain.
- Створення блоку і його дозвіл
- передача пріоритети Блоку
Оскільки блок розгалуження і злиття можуть бути сприйняті як блок реорганізації події, а також, та ж політика для блоку реорганізації використовується для розподіленого контролю версій, а також. З точки зору контролю версій, політика блоку реорганізації називається «Послідовне злиття.»
SMART КОНТРАКТИ
AERGO підтримує кілька парадигм, плагін на основі смарт-контракту інфраструктури.
Кожен контракт може бути виконаний або запитаний клієнтом-учасником або іншою смарт екземпляром контракту. Оскільки AERGO забезпечує дозвільний інтерфейс з максимальною сумісністю між смартом реалізацією контракту, контрактами, написані для Ефіріума віртуальної машини, тканину Chaincode або AERGOSQL може бути використаний один з одним.
а. AERGOSQL
Канонічний спосіб написати розумний контракт на AERGO забезпечується AERGOSQL. AERGOSQL забезпечує реляційну модель даних для зберігання і доступу до даних і SQL-подібна мова сценаріїв для написання смарт-контрактів.
Використання AERGOSQL, смарт-контракти можуть бути написані, використовуючи знайомий синтаксис SQL.
Малюнок 2. Модель AERGOSQL кодування
Для досягнення максимальної продуктивності, AERGOSQL використовує такі технології, як LLVM для компіляції JIT використовують 6 і високопродуктивні реалізації b-tree, такі як WiredTiger 7 для зберігання даних.
б. Interoperability
Завдяки змінній архітектурі, AERGO призначений для підтримки різних реалізацій смарта-контракту. AERGO успадковує Virtual Machine сумісність Ефіріума з Blocko Coinstack з коробки. Тканина Chaincode підтримується за рахунок полегшеної віртуалізації, таких як Docker.
Перший випуск AERGO залежить від реалізації EVM Go-Ефіріума в. Використання evmjit для підвищення продуктивності планується в майбутньому.
SMART ORACLES
AERGO підтримує інтеграцію смарт-контрактів всередині оточеного стіною саду blockchain, а також смарт-контракти, враховувати зовнішні події і фактори, за рахунок впровадження смарт-оракулів. Смарт-оракули прагнуть забезпечити такі функціональні можливості:
- Дозволити смарт контрактів використовувати дані з успадкованих систем, такі як Active Directory
- Дозволити смарт-контракти для запуску подій в зовнішніх сервісах, таких як електронна пошта або SMS
З точки зору смарта-контрактом, смарт-оракули зовнішні факторами, які в поєднанні з конкретним смартом-контрактом; розумні оракули реагують на зміни в поєднанні смарт-контракту і ввести дані в якості відповіді. У деяких випадках розумні оракули можуть викликати розумні контракти автономно.
З точки зору DAPP, смарт-оракули реалізації мікро-послуг, які надають зовнішні функціональні можливості, необхідні DAPP. Так як смарт-оракули і dApps можуть взаємодіяти офф-ланцюг, мікро-послуги, що надаються смарт-оракулами можуть бути використані для реалізації зв'язку поза смуги, необхідну смарт-контракту; загальний варіант використання включає в себе обмін маркера аутентифікації між смарт-оракула і DAPP.
ізоморфні контракти
AERGO інструментарій розвитку має намір підтримувати изоморфное виконання смарта-контракту через автоматичну генерацію коди. Ізоморфний код, що генерується з смарта-контракту може бути доступний як DAPP і смарта-оракулами, що дозволяє прозорий доступ до смарт-контракту та базової структурі даних. Ізоморфними виконання смарт-контракту має вирішальне значення для продуктивності розробки смарт-контракту та додатків або послуг на його основі.
Малюнок 3. Умовна DAPP проти Ізоморфне DAPP архітектура
Не всі розумні мови контракту підтримка ізоморфних контрактів; підтримка ізоморфними контрактів обмежується контрактами, написаними для AERGOSQL.
Дистрибуція файлової системи
AERGOFS залежить від DD для управління метаданими, пов'язаних з файлами; метадані про кожен файл, включаючи фізичне місце розташування, хеш-значення, а також різні статистичні дані зберігаються в DD.
У той час як смарт-контракти забезпечують структуроване зберігання даних зі схемою даних і індексами для прискорення запиту, AERGOFS намір надати неструктуровану можливість зберігання даних про AERGO.
AERGOFS надає простий інтерфейс HTTP, забезпечуючи доступ з обох смарт-оракулів, які працюють на серверному середовищі і dApps, що працюють на веб-браузерів.
Розподілене управління VERSION
На відміну від традиційних систем blockchain, AERGO розглядає ланцюг вилку і блок реорганізації в якості основних особливостей blockchain, а не подразнюють побічних ефектів. Прийнявши моделі даних GIT, як і командну структуру, AERGO прагне включити співробітництво в даних, як легко, як для спільної роботи над вихідним кодом. репозиторії
Малюнок 4. Державні і приватні Сховища
AERGO підтримує створення громадських і приватних сховищ. Кожне сховище може бути або ім'я або назва.
Іменовані сховище має відповідний публічний об'єкт на Distributed каталогу AERGO Громадської Мережі.
Неназваний сховище не має такого об'єднання.
Багато що, як загальнодоступне сховище Git, публічний репозиторій AERGO призначений бути прозорими для читання і запису або вибірково дозволити різні дозволи для анонімних користувачів. Звичайна конфігурація є створення публічного сховища AERGO з тільки для читання анонімного доступу.
Приватне сховище призначене бути сховищем AERGO з контролем повного доступу включена, як для читання і запису в сховище. Державний або приватний репозиторій фактично є приватним blockchain в тому сенсі, що він працює незалежно від AERGO громадської мережі. В результаті AERGO Токен не має корисність в рамках державних або приватних сховищ.
Малюнок 5. Розгалуження і злиття блоків
Усередині кожного сховища, різні гілки, що вказують на інший знімок в blockchain статус може бути створений. Насправді, поняття «кращої ланцюга» в AERGO аналогічна основної гілки.
Синтаксис і семантика
AERGO прагне забезпечити дружній синтаксис і семантику для користувачів, які звикли до систем контролю версій, таких як Git.
Такі функціональні можливості можуть бути доступні через AERGO CLI клієнта, а також RPC API.
а. Основні команди
Нижче наводяться ілюстрації основного використання AERGO для розподіленого управління версіями.
aergo tag <block hash> [- block = <block hash>]
Ця команда створює новий іменований тег. Без неявній блок хеша як параметр, кращий блок поточного філії використовується в якості кореневого блоку для нового тега. На відміну від філії, тег не може отримати нові блоки.
aergo checkout <branch | tag>
Вищенаведена команда вилучення існуючого філія або тег для обстеження або маніпуляції
aergo pull <repository: branch>
Ця команда зливає зміни в віддаленому філії в місцевому відділенні сховища. В результаті, віддалені транзакції застосовуються до локального сховища, а також. В процесі, названі теги синхронізовані, а також.
aergo push <repository: branch>
Вищевказане прагне об'єднати зміни в місцевому відділенні для філії віддаленого сховища. В результаті, місцеві угоди застосовуються до віддаленого сховища, а також. В процесі, названі теги синхронізовані.
б. Розгалуження і злиття
Одним з найбільш складних концепцій в розподілених системах управління версіями є процесом злиття гілок. Для blockchains з даними в режимі реального часу, злиття ще важче досягти. Завдяки неруйнівного процесу, розгалуження є простий і зрозумілий процес.
Однак, злиття вимагає два різних підходи.
автоматичне злиття
За замовчуванням Автоматичне злиття являє собою очікуваний процес злиття двох гілок. Автоматичне злиття аналогічний процесу блок-реорганізації в blockchains. В цьому випадку блоки приєднується джерела в розчиняються в угоди і поглинаються в mergingpool зливаються мети. В кінцевому рахунку, результати злиття басейну в новому блоці приєднані до блоку кращого зливаються мети. В процесі операції непослідовні до цільового зрощенню гілки автоматично виключаються з нового блоку.
послідовне Злиття
Послідовне злиття відбувається тільки тоді, коли гілка створюється з певною послідовної логікою злиття. Послідовне злиття аналогічно функціональності злиття, що надається системами контролю версій, як Git. На відміну від автоматичного об'єднання відкидає неузгоджених угод за замовчуванням, Послідовна Об'єднання залежить від визначеного вирішення конфліктів логіки управління неузгодженими угод. Логіка вирішення конфліктів реалізований у вигляді смарт-контракту на системному рівні.
масштабованість
AERGO використовує три різних підходи для досягнення масштабованості.
- поділ домену
- Збільшити масштаб
- Масштабування
ДОМЕН НА ОСНОВІ PARTITIONING
Поділ домену на основі найбільш основна стратегія масштабування використовується AERGO. Domainbased поділ досягається за рахунок функціональних можливостей розподілених контролю версій (ОПА) від AERGO.
На відміну від звичайних реалізацій blockchain, AERGO здатний до вилки і об'єднати свої дані через гілку вільно. В результаті, розподілена бухгалтерська книга може бути розділена як логічно, так і фізично за допомогою різних сховищ.Такий підхід вже успішно використовується розподіленими управліннями версій, таких як Git і Mercurial. Наприклад, гігантський сервіс як GitHub здатний провести десятки мільйонів сховищ.
Проте, ефективність поділу на основі домену залежить від структури і використання даних. Коли один репозиторій повинен обробляти необмежене розширення даних, поділ даних через розгалуження дуже важко. В результаті, два додаткові підхід масштабованості забезпечується AERGO для обробки величезної кількості даних для одного сховища.
Шкала з стратегії AERGO залежить від функціональних можливостей, що надаються AERGOFS. AERGOFS виконує дві ролі для досягнення масштабованості:
(1) AERGOFS може служити в якості шару для зберігання блоків і індексів кожного вузла. Чином AERGO вузли використовують AERGOFS дуже схоже на те, як HDFS використовується HBase. З AERGOFS, кожен вузол здатний зберігати необмежену кількість блоків і індексів і функцій як гігантський прибери-вузол.
(2) AERGOFS здатний функціонувати в якості об'єкта зберігання, аналогічної S3, а також. У цій конфігурації, AERGOFS забезпечує незмінний і міцний доступ до двійковим даними. В цьому випадку, розумні контракти AERGO потребують зберігати локатори для доступу до файлів, що зберігаються на AERGOFS.
ЗБІЛЬШИТИ МАСШТАБ
Самий прямий і простий підхід, який AERGOFS прагне використовувати для масштабованості за рахунок оптимізації одного вузла.
У той час як в горизонтальному масштабуванні добре працює для великої кількості даних, які не відповідають реалістичним показниками. З появою дешевої пам'яті, швидкої пам'яттю, такими як SSD, і обмеженою пропускною спроможністю мережі, оптимізуючи один вузол є дуже ефективним для побутових систем. Blocko цей урок дорого, забезпечуючи при цьому реальному житті blockchain реалізації на підприємстві світі, і AERGO, за допомогою Blocko, яка націлена займати багато ідей і методів з Coinstack Blocko в цьому відношенні.
Для того, щоб кожен вузол якомога ефективнішим, AERGO вузли призначені бути оснащені ефективною мережевий стек і оптимізований механізм зберігання даних для поліпшеного введення / виведення.
- AERGO мережевий стек забезпечує ефективність мережі, яка в змозі обслуговувати велику кількість вузлів зі складною топологією як на голій металевої середовищі і хмарної середовищі.
- AERGOSQL утворює основу механізму зберігання високої продуктивності, необхідної AERGO.
- AERGO вузли використовують архітектуру багатопотокової скористатися многоядерной середовищем.
Управління
AERGO прагне забезпечити два механізми угоди сериализации.
Серіалізация BLOCK LEVEL
Оскільки кожна гілка blockchain складається з ряду блоків, транзакції можуть бути серіалізовать через укладання один за одним.
AERGO спрямований на забезпечення Мульти Версія управління паралелізмом (MVCC) на основі висоти блоку. В результаті, з відгалуженням і блоком висотою зазначеної, можна забезпечити [послідовне читання] між різними вузлами в сховище.
Функціональність MVCC AERGO спрямована на забезпечення як ізоляцію знімки для послідовного читання і форми оптимістичній блокування через ряд або документ управління версії. Проте, MVCC працює тільки для блочного рівня сериализации.
Серіалізация НА РІВНІ ПУЛУ
Клієнти, які звертаються AERGO вузли можуть скористатися детермінованим, запланованим створенням блоків делегатів, характеристикою, представленої DPOs і основного консенсусом, для виконання операцій синхронно з сильною гарантією на угоди завершеності.
Оскільки кожен делеговані вузол може застосовувати єдиний порядок сериализации для обробки нових транзакцій в пул пам'яті і створювати нові блоки, клієнти не повинні чекати інтервалу блоку для отримання результату операцій. В результаті, час очікування виконання транзакції зменшується від декількох секунд до мілісекунд.
Малюнок 6. Пул Серіалізация Рівень
Проте, з блочними реорганізацій і ланцюги поділу в грі, а також наявністю illintentioned клієнтів, рівень пулу сериализации забезпечує лише імовірнісний рівень узгодженості. З іншого боку, з оптимістичною навантаженням, рівень басейну сериализация добре працює для вирішення реальних життєвих проблем.
КОНФІДЕНЦІЙНІСТЬ ОТРИМАННЯ ДАНИХ
AERGO намір тільки, щоб дозволити користувачам з адекватним дозволом на доступ до даних Головної книги, надаючи GIT, як приватні репозиторії.
Створюючи нову гілку від віддаленої батьківської гілки, користувачі можуть зберігати новостворені блоки в приватній галузі, таким чином, що вони ізольовані від суспільства. Тільки з тими дозволами на конкретне сховище корпусу філія має можливість отримати доступ до блоків.
DATA ОБМІН
Конкретна філія може бути синхронізована з віддаленими сховищами для обміну даних. В цьому випадку приватні гілки сховища можуть або вишневі вибрати відповідні коммітов з публічного сховища або об'єднати всі зміни набору автоматично.
паралельність
Ефективність конкретного blockchain залежить від ефективності створення і спільного використання нових блоків, і час, необхідний для кожного вузла для перевірки нових блоків.
Процес створення блоку передбачає розгляд всього поширена консенсусний протокол blockchain в. Стверджується, що процес перевірки блок, який використовується в якості частини різних розподілених консенсусних протоколів іноді погано розроблені і реалізовані.
У той час як неефективні вузли є прийнятними для споживчого класу реалізацій blockchain, таких як Bitcoin або Ефіріум, корпоративний клас blockchains як AERGO вимагає набагато надійної роботи на близькому до реального часу. В результаті, кожен вузол повинен бути реалізований з такою ж ефективністю, як і сам консенсусної протоколу.
AERGO намір ввести поняття паралельності на різних етапах обробки блоків, щоб максимізувати продуктивність.
Паралелізм передбачає ретельний аналіз залежностей між угодами, включених в кожному блоці і ефективної архітектурою, натхнених SEDA 8.
АНАЛІЗ DEPENDENCY
Для того, щоб гарантувати узгодженість між вузлами, blockchain реалізація зазвичай використовує політику сериализации виконання всіх операцій і блоків доступні.
В результаті, швидкість блокує blockchain вузла може процес залежить від часу, який потрібен для обробки кожної транзакції, незалежно від числа блоків обробки або доступної пам'яті.
Для того, щоб забезпечити паралельну перевірку транзакцій і блоків, AERGO намір провести аналіз залежностей між операціями і блоками і створити структуру даних, відому як детермінована транзакція дерево.
Deterministic Transaction Tree
Deterministic Transaction Tree (DTT) можна розглядати як формальне подання порядку виконання операцій для отримання в результаті детермінованих результатів в державних машин, які постраждали від угод.В результаті, для набору операцій, може бути більше, ніж один життєздатний і правильно DT
Кожна гілка DTT може бути оброблена і застосована до нижчого автоматам, пов'язаних з операціями паралельно з детермінованими результаті станами. Типовий DTT матиме ряд гілок з різною довжиною.
Малюнок 7. Детермінована транзакції Tres
Залежно від розміру блоків, кожен з DTT може мати відділення від з парою угод довжиною до тисяч транзакцій в довжині. Аналогічним чином, DTT може мати різне число гілок, а також.
Дійсність DTT може бути перевірена тільки на самому ділі виконання DTT проти ряду державних машин. Варіант DTT може бути оптимізований в іншу версію шляхом перетворення дерева, а також.
Для того, щоб створити DTT для безлічі транзакцій в реальні терміни, AERGO використовує підхід на основі правил для аналізу операцій. Більш складні підходи, включаючи машинне навчання планується тестування в майбутніх версіях AERGO.
Останнє оновлення: 17 липня 2018, AERGO