На основі різних концепцій управління, спільнота EOSC оптимізувала механізм виборів Eosio, запустила основну мережу EOSC на Genesis Height 1 і продовжувала переробляти та модернізувати основну мережу EOSC, змушуючи EOSC продовжувати розвиватися до децентралізованої високоефективної платформи розумної контракту, що закладає основу для великої популярності економіки крипто.

фон

Криптоваправка розпочала критичну стадію від соціальних експериментів до масштабного комерційного використання.
За масштабним комерційним використанням означає величезний транзакційний тиск. Для ефективного виконання величезних потреб у транзакції система блокчейн повинна спочатку забезпечити достатньо сильну продуктивність. Для цього необхідні більш високі вимоги для повного вузла, таких як краща конфігурація апаратних машин, більша ємність зберігання, більш стабільна мережа, швидша пропускна здатність, нижча затримка тощо. Очевидно, високий поріг для повного вузла призведе до зменшення кількості вузлів, що виробляють блок, які можуть працювати стабільно. Якщо механізм POS використовується в такій системі блокчейн, система швидко сходяться на централізовану ситуацію. Щоб досягти балансу між високою продуктивністю та децентралізацією, алгоритм консенсусу DPOS, безсумнівно, є найкращим вибором в даний час та найкращим рішенням для управління невеликою кількістю вузлів.
Еосіо, заснований на алгоритмі консенсусу DPOS, з'явився, і громада вперше побачила світанку масштабного комерційного використання криптовалюти. Чи є механізм виборів повністю ефективним, є ключовим фактором виживання механізму консенсусу DPOS, а також пов'язаний з тим, чи може механізм консенсусу DPOS передати POW для ведення наступного покоління хвилі шифрування.
Для того, щоб приїхати до приходу епохи масштабного комерційного використання криптовалюти, спільнота EOSC оптимізувала механізм виборів Eosio, запустила основну мережу EOSC на Genesis Height 1, і продовжувала переробляти та модернізувати основну мережу EOSC, так що EOSC продовжує еволюціонувати до децентралізованої платформи розумного контракту.

Механізм консенсусу

EOSC слідує за консенсусним механізмом Eosio, а саме консенсусу DPOS BFT. На відміну від Eosio, EOSC не приймає режим Eosio з одним блоком кожні 0,5 секунди, а один вузол генерує 6 блоків. Кожні 3 секунди в EOSC вузли не будуть генерувати блоки постійно. Хоча вузли можуть скоротити час очікування розпакуваних транзакцій, поточне мережеве середовище часто не є ідеальним, швидке генерація блоків вплине на стабільність ланцюга і спричинить велику кількість мікрофункцій.
Поточний механізм консенсусу Eosio недостатньо ідеальний, але як платформа DAPP, час підтвердження блоку не є першочерговим пріоритетом оптимізації ланцюга. Для EOSC механізм консенсусу повинен розглядатися у середовищі з високим навантаженням. У поточній ситуації, коли паралельна комп'ютерна система не є ідеальною, поспішно вдосконалюючи механізм підтвердження трубопроводу, є дуже проблематичним.
Майбутній консенсус -механізм EOSC розвиватиметься паралельно з двох напрямків
1. Сумнівно з розробкою Eosio та оновити його алгоритм консенсусу. Ми судимо на основі поточного прогресу розвитку Еосіо. Коли Eosio завершить паралельне вдосконалення, алгоритм консенсусу буде модернізований для досягнення більш швидкого часу підтвердження блоку.
2. Інші механізми консенсусу на основі номерів підтвердження будуть адаптовані для доповнення існуючого консенсусу DPOS. З одного боку, буде реалізована взаємодія між консенсусом ланцюга вбудованого шару 2 та основною ланцюгом. З іншого боку, більш децентралізований механізм перехресного ланцюга може бути досягнутий за допомогою інших механізмів консенсусу.

вдосконалення технологій EOSC

модель ресурсів на основі плати за обробку
Незважаючи на те, що процесора Eosio та модель оплати чистих ресурсів є хорошим дизайном в технології, він занадто складний для користувачів і не може сприяти розробникам DAPP для оптимізації своїх контрактів. З іншого боку, метод закупівлі оперативної пам’яті Eosio призведе до певної поведінки накопичувача, яка не сприяє розвитку екосистеми DAPP. З цієї причини EOSC інноваційно розробляла нову модель ресурсів. Завдяки практичній оптимізації він досліджує модель ресурсів на основі плати за обробку в складному середовищі розумного контракту для повного вирішення проблем з ресурсами, що зачіпають екосистему EOS.
Перш за все, EOSC сплачує процесор користувача та чисте споживання ресурсів у режимі оплати праці. Для дії, визначеної розробником у DAPP, розробники DAPP можуть встановити необхідну плату за поводження для дії. Система контролює використання дії на основі цього. З одного боку, це сприяє користувачам зрозуміти споживання ресурсів, а з іншого боку, він також сильно сприяє розробникам DAPP оптимізувати використання контрактних ресурсів, щоб вся екосистема могла розвиватися здорово.
EOSC використовує хмарний хост оренди для розподілу ресурсів RAM таким чином, як у оренді хмарних хостів. Користувачі можуть сплатити витрати на оренду ресурсів RAM, використовуючи дивіденди голосування, щоб користувачам не потрібно було турбуватися про оплату оренди, а також усунути проблему заборгованості оренди. За допомогою методу "оренда та продажу" EOSC може ефективно уникати спекулятивної поведінки проти ресурсів оперативної пам’яті, так що розробка DAPP не повинна турбувати ціни на оперативну пам’ять і ефективно сприяти будівництву екосистеми DAPP.
Незважаючи на те, що сміливо впроваджує та вивчає нові моделі ресурсів, EOSC також досліджує механізм, який можна сумувати з моделями ресурсів Eosio. Для процесора та чистих ресурсів користувачі можуть платити збори на основі віку дивідендів для досягнення впливу отримання процесора та чистих ресурсів, подібних до іпотеки Eosio. Для оперативної пам’яті користувачі можуть досягти ефекту Eosio на основі придбання ринку за допомогою розвороту голосування, щоб розробники DAPP могли швидко ввести Eosio з інших ланцюгів Eosio і плавно звернутися до ресурсної моделі EOSC.
Гладкий механізм оновлення
Виборчий механізм EOSC заохочує супер вузли активно брати участь у просуванні технологічних оновлень. На відміну від розколу версії вузла Eosio спільноти, EOSC активно сприяє технологічним оновленням та оновленню на практиці.
Для того, щоб досягти більш плавного несумісного процесу оновлення, EOSC додав набір механізмів оновлення на основі висоти ефективного блоку. Спільнота може підтвердити висоту ефективного блоку функції за допомогою декількох ознак, щоб децентралізувати процес плавного оновлення. На відміну від нещодавно запропонованої схеми тегів Eosio на основі даних про розширення блоку, механізм оновлення EOSC є більш доброзичливим та сприятливим для розуміння. Перша практика EOSC децентралізованого процесу оновлення "м'якої вилки" в ланцюзі на основі Eosio, що є основною гарантією для EOSC продовжувати розвиватися для вирішення різних проблем з механізмом.
З іншого боку, функція встановлення атрибутів ланцюга на основі декількох знаків може забезпечити спільноту набір децентралізованої конфігурації ланцюга та схем на ланцюзі. Різні параметри та конфігурації можуть бути децентралізовані відповідно до фактичного розвитку, щоб громада могла розвиватися краще.
механізм серцебиття вузла та стабільний інтервал вихідного блоку
Для сприяння стабільності основної мережі EOSC зміцнює побудову альтернативних вузлів з точки зору економічної моделі. У той же час EOSC додає механізм серцебиття вузла на ланцюг для сприяння зміцненню та поліпшенні їх стабільності та сприяння більшій стабільності всієї основної мережі.
Виходячи з механізму серцебиття, EOSC може підтвердити роботу вузла, так що несправні вузли були покарані на основі ланцюга, тим самим закликаючи побудови вузлів та запобігаючи нестабільності вузлів діяти у всій основній мережі.
Час інтервалу генерації блоку збільшується на початку запуску, щоб уникнути випадкових м'яких виделок в основній мережі, коли поточна мережева інфраструктура ще не є ідеальною. Інтервал генерації напівсекундного блоку, розроблений Eosio та механізмом підключення шести блоків до одного вузла, безумовно, може покращити доступність ланцюга в майбутньому, але він не застосовується в поточному мережевому середовищі. З прагматичним ставленням час інтервалу генерації блоку буде збільшуватися спочатку, а після того, як умови в майбутньому будуть зрілі, він буде змінений на швидке генерацію блоку. Це може ефективно зменшити м'які виделки. У той же час, зменшення кількості блоків може значно збільшити швидкість синхронізації всього вузла, щоб було більше повних вузлів, тим самим підвищуючи доступність усієї мережі.
Більше API контрактного шару
Для того, щоб зробити розробники DAPP більш зручним для розробки контрактів, були додані деякі API, а також деякі конкретні коригування були внесені до системних контрактів.
По -перше, додається API для отримання висоти блоку, і розробники можуть легко та ефективно отримати висоту поточного блоку. Виходячи з цього API, контракти можуть ефективно уникати блокування блок-атак та інших атак на основі повторних речовин. По -друге, додається API для отримання інформації про конфігурацію ланцюга, і розробники можуть адаптувати різні корекції параметрів та оновлення ланцюга до ланцюга на шарі контракту, щоб контракт також міг плавно дотримуватися функції оновлення ланцюга. Нарешті, щоб уникнути підроблених валютних атак, перед початком ланцюга використовуються незалежні договори токенів, щоб користувачі могли чітко розрізнити підроблені валютні атаки.
адаптація послуг між ланцюжками
На початку запуску команда Force передбачила, що підтримка перехресного ланцюга буде основною функцією громадських ланцюгів у майбутньому. Таким чином, команда Force розпочала розробку проекту Codex та встановила ланцюг реле Codex.RELAY, щоб надати реле послуг для кожної ланцюга, щоб реалізувати механізм перехресного ланцюга між кожною ланцюжком, який може забезпечити більш повну підтримку для Codex.relay. Через супер вузли двох ланцюгів, що працюють один з одним, можна досягти "повного" перехресного механізму, тобто ступінь децентралізації будь-якого ланцюга не буде зменшено під час процесу перехресного ланцюга.
За допомогою механізму перехресного ланцюга можна отримати велику масштабованість. На основі естафетних послуг можна додати підставки Shayer 2. Деякі послуги та DAPP з високим споживанням ресурсів можуть бути запущені на основі суб-ланцюгів, а результати обчислення або основні стани можуть бути синхронізовані з реле-службами. Таким чином, для розширення функцій можуть бути додані спеціальні суб-ланцюги, такі як зберігання, обчислення, DAPP та випадкові числа.
Високо налаштована рамка розробки блокчейна Eosio
На основі естафетних послуг він може додати підставки 2-го рівня. Надалі різні суб-ланцюги відіграватимуть велику роль в екосистемі Eosio. Однак слід зазначити, що в даний час проект blockchain з індивідуальними функціями на основі Eosio все ще має високий поріг. З цієї причини команда Force запустила проект Codex.io, який є дуже налаштованою рамкою розвитку блокчейна Eosio, знижуючи поріг розвитку підставки та надаючи розробникам більш економічний та доброзичливий досвід розвитку піддій.
Команда Force накопичила великий досвід розробки блокчейна на основі Eosio під час процесу розробки, а також сподівається дати повну гру на її найбільшу цінність. Codex.io - це рамка розробки блокчейна "поза коробкою". Розробники можуть швидко запустити ланцюг на основі Codex.io. Після простої конфігурації вони можуть налаштувати різні символи та вільно вибирати економічні системи та моделі ресурсів. Виходячи з цього, розробникам потрібно лише звернути увагу на проблеми, які сама ланцюг потребує вирішення. Згідно з цим, вони можуть вибрати їх реалізувати на основі контрактів або ланцюжків рідних шарів. Codex.io може полегшити розробникам для розширення нативного шару ланцюга для вирішення деяких проблем з продуктивністю, а також може значно розширити функції ланцюга.
Codex.io інтегрує функції розширення, запропоновані більшістю ланцюгів Eosio. З інклюзивним ставленням, Codex.io дозволяє розробникам вільно поєднувати функції на ланцюзі: включаючи мінімальну систему безпеки живої безпеки, систему облікових записів, різні механізми чорно-білого списку, загальні механізми управління та механізми голосування та різні плагіни.
Через Codex.io в майбутньому буде інтегрована велика кількість підкладок шару 2, що забезпечить нескінченне розширення.