DEXON срещу 25 блокчейн проекта

Преглед на текущата блокчейн технология в сравнение с DEXON

Въведение

Този документ обяснява как DEXON е различен в сравнение с други blockchain инфраструктури. Правим всичко възможно да обясним основните разлики, но вземаме предвид следното, когато четете това:

  1. Няма да се гмурнем в подробности за други проекти. Ние се фокусираме само върху разликите. За подробности, моля, вижте техните уебсайтове и бели листове.
  2. Сравнението се основава на нашето сегашно разбиране и проектите могат да се актуализират често. Ние ще актуализираме този документ, ако е необходимо.
ЗАБЕЛЕЖКА на редактора:
Първоначално това е публикувано на GitHub на DEXON, актуализирано от април 2019 г. Статията по-долу може да изглежда различна от оригинала, тъй като е била пояснена за яснота и краткост.

Dexon

DEXON е мащабируема, ниско латентна, енергоефективна и междуверижна оперативна екосистема DApp. DEXON използва ефективно византийско споразумение като основен алгоритъм за консенсус, пропускането на който може да се мащабира линейно с броя на възлите, докато латентността остава почти постоянна. С приемането на проверима произволна функция, DEXON може да осигури висока производителност, като същевременно поддържа мрежата децентрализирана (~ 100K възли). С такава висока производителност и ниска латентност, практическият DApp най-накрая може да бъде разработен и широко използван.

ОФИЦИАЛЕН САЙТ: https://dexon.org
АЛГОРИТЪМ НА КОНСЕНСУС: https://eprint.iacr.org/2018/1112.pdf

Съдържание

аз. Определение на термините
II. Преглед на Blockchain Technology
A. Blockchain технология (изброени по азбучен ред)
   1. Алгоранд
   2. Биткойн
   3. Кардано
   4. Conflux
   5. Определеност
   6. EOS
   7. Етериум
   8. Хашграф
   9. Hyperledger
   10. IOTA
   11. Кадена
   12. NANO
   13. Омниледжър
   14. Онтология
   15. Orbs Helix
   16. Фантом
   17. Радикс
   18. Снежинка
   19. Призрак
   20. Звездна
   21. Нежна мента
   22. Гръмотевица
   23. ТОН
   24. Вите
   25. Zilliqa

II. Определение на термините

  • Възелът в този документ е валидатор или пълен възел в мрежата.
  • n: брой възли
  • За колоната за интелигентен договор:
    • O: Поддържа се
    • X: Не се поддържа
    • △: Понастоящем не се поддържа, но може да се поддържа

II. Преглед на блокчейн технологиите

Изображението по-долу подчертава пропускателната способност (TPS), скоростта на мрежата (латентността, измерена в секунди), вида на използваната структура на данни, каква технология се използва за постигане на консенсус на blockchain и интелигентната поддръжка на договори за всички 25 технологични проекта за блокчейн, включени в този списък ( 26, включително DEXON).

Можете да се обърнете към тази таблица, докато четете проекта в списъка.

Този списък първоначално е публикуван на GitHub на DEXON

A. Блокчейн технология (по азбучен ред)

1. Алгоранд

ОФИЦИАЛЕН САЙТ: https://www.algorand.com
ТЕХНИЧЕСКИ РЕСУРСИ: https://www.algorand.com/docs/whitepapers

Algorand е проектиран за по-голяма популация (500K ~ възли). Те използват проверима произволна функция, за да защитят възлите от DDoS атака и лотарията решава кой има право да предложи блок или да гласува за всеки кръг.

Консенсусът на Алгоран се основава на византийско споразумение между проби от целия набор от възли. Това е причината, поради която Algorand може да толерира само по-малко от една трета от общия брой възли. По същия начин, използваният в Algorand механизъм за клюки може да удължи времето за потвърждение, когато броят на възлите се увеличи на различни места по света. С тези ограничения времето за потвърждение може да бъде около една минута, ако се очаква броят на възлите да надхвърли 500K. Друг фактор, който ще повлияе на времето за потвърждение, е византийското поведение. Ако византийски възел спечели лотарията и стане лидер, процесът на византийското споразумение ще се нуждае от повече кръгове, за да се сближи. От друга страна, времето за потвърждение на DEXON не се влияе от византийското поведение, стига броят на византийските възли да е под една трета от общите възли.

Ако Algorand иска да увеличи пропускателната способност, той трябва да увеличи размера на блока. Увеличаването на размера на блока обаче води до по-дълго забавяне в мрежата, увеличавайки времето за потвърждение. Това означава, че мащабируемостта може да бъде проблем за Algorand. От друга страна, DEXON увеличава пропускателната способност, като увеличава броя на възлите, без да влияе на времето за потвърждение.

2. Биткойн

ОФИЦИАЛЕН САЙТ: https://bitcoin.org/en/
ТЕХНИЧЕСКИ РЕСУРСИ: https://bitcoin.org/bg/bitcoin-paper

Биткойн е първата криптовалута, която въведе във всички останали блокчейн технологии. Това е най-известната и широко използвана криптовалута. Въпреки това, той е известен с дългото си време за потвърждение, ниското TPS и високата такса за транзакция. DEXON решава всичко това, като същевременно предоставя функционалност на DApp, което Bitcoin не може.

3. Кардано

ОФИЦИАЛЕН САЙТ: https://www.cardano.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://www.cardano.org/bg/academic-papers/

Cardano е първият проект, който предоставя конкретно математическо доказателство за сигурността на PoS blockchain. Освен PoS, те предлагат и други многообещаващи идеи като безпристрастна случайност със схемата за разкриване на разкриване и използване на равновесието на Наш за предотвратяване на егоистична атака на минното дело. Въпреки това неговата верижна структура естествено ограничава пропускателната способност, тъй като верижните структури могат да обработват блок само линейно и може да се докаже, че не може да мащабира.

Друг проблем при консенсуса на Кардано е, че той силно зависи от синхронизирането на времето. Ако някои честни възли са десинхронизирани (например, NTP услугата е отвлечена от атакуващ), времето за стартиране на слота ще бъде трудно да се определи (ако е възможно изобщо да се определи) и ще се третира като възли за отказ. Те твърдят, че десинхронизираните възли могат да бъдат коригирани по някакъв метод, въведен в бъдеще, но той все още не е приложен.

4. Conflux

ОФИЦИАЛЕН САЙТ: https://www.conflux-chain.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://arxiv.org/abs/1805.03870

Conflux е базиран на график PoW консенсус, базиран на протокола GHOST, който фиксира блокчейн Phantom. Conflux използва протокола GHOST, за да избере основната верига в графика и да генерира изцяло подредена графика на основната верига. По този начин, той може да се разглежда като консенсус за биткойн и те също идентифицират проблем с пристрастия във Phantom.

Освен това, латентността е ограничена от механизма й на PoW. Има нужда от някои, за да изберете правилната и последователна главна верига с голяма вероятност. Дори и да премине към PoS механизъм, закъснението ще продължи да бъде неприемливо дълго, тъй като протоколът GHOST също има консенсус за правило с „най-дълга верига“.

5. Определеност

ОФИЦИАЛЕН САЙТ: https://dfinity.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://dfinity.org/faq

Dfinity е разрешен блокчейн и е проектиран за голяма популация (около 10K възли). Dfinity съдържа сигнал за случайност, който генерира нова случайност от VRF (проверяема случайна функция) с информация от нов потвърден блок. Те използват случайността, за да изберат лидер и избраници за кръг. Чрез хипергеометрично разпределение Dfinity само изважда стотина възли, за да нотариализира блок вместо да използва всички възли и това е правилно с голяма вероятност. Това обаче намалява способността за търпимост към византийските възли. Например, за да се постигне не-византийско мнозинство от възли с добра вероятност, трябва да се вземат проби поне 423 възли от 10К възли с максимум 1/3 византийски възли. Независимо от това, Dfinity е базиран на веригата, така че неговата производителност е ограничена.

6. EOS

ОФИЦИАЛЕН САЙТ: https://eos.io
ТЕХНИЧЕСКИ РЕСУРСИ: https://eos.io/resources#eosio

EOS достига висока производителност и ниска латентност. Те имат 21 т. Нар. „Супернодове“, които могат да се считат за не истински децентрализирани. Също така, към момента на писането, неговият консенсус за византийски грешки за толерантност все още не е приложен, така че времето за потвърждение е около 165 секунди, а не 1 или 2 секунди, както те твърдяха.

7. Етериум

ОФИЦИАЛЕН САЙТ: https://www.ethereum.org
ТЕХНИЧЕСКИ РЕСУРСИ: http://www.ethdocs.org/bg/latest/

Ethereum е първата блокчейна система, която има цялостна екосистема DApp. Той има пропускателна способност, която е по-висока и латентността е по-ниска от биткойн - но все пак не е достатъчна за обикновени приложения, които изискват голяма инфраструктура, като плащане или игри. Популярният DApp може да блокира цялата система, причинявайки високи такси за транзакции. Освен това текущата му скорост (вече на няколко минути) не е идеална за приложения в реално време.

8. Хашграф

ОФИЦИАЛЕН САЙТ: https://www.hedera.com
ТЕХНИЧЕСКИ РЕСУРСИ: https://docs.hedera.com/docs/start/quickstart/

Консенсусът на Хашграф е адаптиран за византийско споразумение за графика, докато от друга страна, ядрото на консенсуса DEXON е отзивчив алгоритъм на византийското споразумение. Тяхната структура на базата на кръг струва латентност за всеки кръг, което означава, че времето му за потвърждение става по-дълго, когато броят на възлите се увеличи. С това ограничение той не може да бъде напълно децентрализиран, тъй като времето за потвърждение може да отнеме минути. Освен това в Hashgraph не се гарантира оживление и се предоставя само доказателство за коректност. С византийски възли, представени в неговата мрежа, е възможно Hashgraph да не може да изведе нито един блок. Междувременно времето за потвърждение на DEXON остава постоянно, тъй като броят на възлите се увеличава. Тъй като DEXON консенсусът има отзивчивост, времето за потвърждение зависи само от действителната скорост на мрежата, а не от някои предварително определени параметри.

9. Hyperledger

ОФИЦИАЛЕН САЙТ: https://www.hyperledger.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://www.hyperledger.org/resources/publications#white-papers

Hyperledger (конкретно, Hyperledger Fabric) е разпределена книга, предназначена за използване в предприятието. Той е разрешен, с ниска латентност, висока пропускателна способност и осигурява частни функционални транзакции. Консенсусът му е модулиран и подвижен. Той може да избира измежду консенсус двигатели / алгоритми като Tendermint, PBFT, Kafka поръчка или RAFT.

Много по-лесно е да се разреши проблемът с консенсуса в разрешена консорциумна обстановка с висока пропускателна способност и ниска латентност, защото предположението за средата е: броят на възлите е фиксиран, всяка идентичност е известна, целта на всички възли е една и съща и мрежовата среда е стабилна и бърза, но възелът не се доверява напълно един на друг. Въпреки че тези настройки може да не са подходящи за използване в предприятието, DEXON се стреми да бъде по-отворен и децентрализиран, като осигурява едновременно висока производителност и ниска латентност.

10. IOTA

ОФИЦИАЛЕН САЙТ: https://www.iota.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://docs.iota.org

IOTA следва правилото за най-дългата верига на графика: възел избира произволно и проверява два предишни блока и прикрепя своя блок към тях. Блок се потвърждава, ако след него е последвал достатъчен брой блокове и дължината на свързаната верига е най-дълга. Правилото обаче е неефективно, тъй като времето за потвърждение не е гарантирано от конкретна граница. Освен това, блокът може да е невалиден, ако е прикачен към блок, който съдържа противоречащи транзакции. Този блок трябва да бъде прикрепен отново към други блокове и може да причини много дълго време за потвърждение. Освен това IOTA не поддържа интелигентни договори поради липсата на обща поръчка между всички блокове.

11. Кадена

ОФИЦИАЛЕН САЙТ: https://kadena.io
ТЕХНИЧЕСКИ РЕСУРСИ: https://kadena.io/whitepapers/

Kadena има за цел да реши въпроса за мащабируемостта на blockchain. Той използва Chainweb за паралелна обработка на транзакции. Всяка верига включва блокови заглавки на други, образувайки DAG, подобен на блок-решетката на DEXON. За извършване на междуверижни транзакции, човек трябва да предостави доказателство за Merkle на интелигентния договор, а активите ще бъдат изтрити от изходната верига и отново създадени във веригата на местоназначение. Kadena също анализира връзките на връстници на връстници и използва специално проектирани графики, които имат малък диаметър и голям ред за постигане на ниска латентност и висока пропускателна способност.

Закъснението на Chainweb отчасти лежи на диаметъра на графика. Когато той мащабира и увеличава броя на веригите, диаметърът на графиката също става по-голям, което води до увеличаване на латентността. Друг проблем може да възникне, когато се предлага блок на верига. Блокът трябва да включва заглавките на блока на връстниците си. Това означава, че предлагането на блокове е блокиращо и не е ефективно, докато в DEXON блок активно атакува всички други новопредложени блокове, постигайки бързо, незаблокиращо предлагане на блок.

12. NANO

ОФИЦИАЛЕН САЙТ: https://nano.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://nano.org/bg/resources/

NANO е първият проект, който въведе блокчейн като своя структура от данни. Всеки акаунт има своя блокчейн, а транзакциите, които предлага, се записват в неговата блокчейн. Когато се случи вилица на блокчейн, NANO използва гласуване с DPoS, за да го разреши.

Структурата на веригата DEXON е напълно различна от тази на NANO. В DEXON, вместо всеки акаунт да има своя блокчейн, всеки валидатор има блокчейн. Това би могло да спести много място в паметта. В блоковата решетка на DEXON всеки връх е блок, докато в NANO всеки връх е половината от транзакция (изпратете tx или recv tx). В нашия случай на biew, тяхната blocklattice е по-близка до „tx-решетка“, а не blocklattice, и ние считаме blocklattice за общ термин, който може да се използва от други проекти, също като blockchain, тъй като е просто тип DAG.

Консенсусният алгоритъм на DEXON също е напълно различен от този на NANO. Валидаторите в DEXON разчитат на алгоритъма за бързо византийско споразумение на DEXON за определяне на последователността на блокове и транзакции, докато NANO няма консенсус относно реда на транзакциите. Без да поръчва транзакции, не може да поддържа интелигентни договори. Друг проблем е неговият DPoS за разрешаване на вилици. Процесът на гласуване, който NANO използва за разрешаване на вилицата, е загадъчен. В текста му няма подробности за процеса на гласуване. Единственото, което знаем е, че има гласуване с мнозинство с 4 кръга. Без допълнителни подробности и доказателства за сигурност, сигурността в NANO може да бъде посрещната скептично. Също така, NANO се нуждае от PoW за предотвратяване на спам (стотинки) атаки, увеличавайки цената на атаката, но също така ограничавайки нейната пропускателна способност и увеличавайки нейната латентност.

13. Омниледжър

ОФИЦИАЛЕН САЙТ: https://iovo.io
ТЕХНИЧЕСКИ РЕСУРСИ: https://iovo.io/assets/whitepaper.pdf

Omniledger цели да реши проблемите с мащабируемостта, без да жертва сигурността и децентрализацията. Основният му подход е затягане, което позволява пропускателната способност да се мащабира линейно с броя на възлите. Omniledger също така предлага приятни функции, като подрязване на главни книги, транзакция на кръстосани остриета и валидиране на доверие, но потвърдете.

Забелязан проблем с Omniledger е, че латентността му може да бъде голяма при напълно децентрализирана обстановка. Причината е, че той използва ByzCoinX (което е оптимизация на консенсус-алгоритъм, подобен на PBFT) за консенсус в рамките на шейд и Atomix (атомно излъчване, подобно на DB) за транзакции между частици. Това означава, че размерът на групата в шейдър за комуникация не може да бъде твърде голям, или разходите за комуникация и латентността ще бъдат големи. За да увеличите броя на възлите с ограничен размер на шрифта, броят на парчетата ще се увеличи, а също така ще се увеличат и нуждите от транзакции с кръстосани късове. При атомно излъчване трансакцията с кръстосани остриета трябва да изчака потвърждаването на всеки участващ фрагмент и дори един неуспешен шейд ще доведе до неуспех на транзакцията. В DEXON транзакциите трябва да въведат само един шейд и ще бъдат изведени незабавно.

Omniledger също жертва известна сигурност. Според хипергеометричното разпределение, ако извадените византийски възли в един фрагмент трябва да бъдат по-малко от една трета, човек може да толерира византийски възли много по-малко от една трета в цялата мрежа, или вземането на проби не може да бъде успешно с голяма вероятност. Ето защо броят на византийските възли, които Omniledger може да толерира, е една четвърт, а не една трета от общите възли.

14. Онтология

ОФИЦИАЛЕН САЙТ: https://ont.io
ТЕХНИЧЕСКИ РЕСУРСИ: https://developer.ont.io

Алгоритъмът за консенсус на Ontology, Ontorand, използва случайността от последния блок, за да генерира нови предложения за блокове и валидатори. Процесът на гласуване на византийското споразумение (макар и не достатъчно подробен) изглежда изключително подобен на Algorand. Неговата проверима случайна функция, която генерира случайност в блок, е абсолютно същата като Algorand. Без никакво цитиране и подобрение от Algorand, Ontorand изглежда много сходен с Algorand. За сравнение с Algorand, моля, направете справка тук.

15. Orbs Helix

ОФИЦИАЛЕН САЙТ: https://orbs.com
ТЕХНИЧЕСКИ РЕСУРСИ: https://orbs.com/white-papers/

Основният приоритет на Helix е честността. Той използва VRF (проверима случайна функция) като безпристрастен случаен източник, за да избере комисията и лидера. Когато работи основният консенсус (PBFT), всички транзакции се криптират от потребителите, използващи прагово криптиране. Това означава, че няма начин възелът да цензурира или да даде приоритет на всяка транзакция. След постигане на консенсус съдържанието на блок след това се декриптира и транзакциите се изпълняват. По този начин редът на транзакциите не може да бъде пристрастен, постигайки справедливост. Helix също използва VRF, за да реши коя транзакция може да бъде поставена в блок. Тъй като възлите не могат да решат кои транзакции да бъдат поставени в блок, таксите за транзакциите могат да бъдат зададени на константа.

За съжаление, справедливостта не идва без разходи. Криптирането на прага не само увеличава изчислителните разходи, но се нуждае от допълнителна фаза на декриптиране. Това увеличава латентността. Освен това неговата верижна структура не е мащабируема. За да реши проблема с мащабируемостта, Orbs въвежда „интелигентно заточване“ (за което не открихме никакви технически подробности). Скорошна симулация показва, че Helix има само 10 TPS (с неизвестна латентност). Със 100 частици той може да достигне 1000 TPS, докато DEXON има 1M + TPS със сто възела в един шал.

16. Фантом

ОФИЦИАЛЕН САЙТ: https://phantom.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://phantom.org/lightpaper.pdf

Phantom е блок-верига, базирана на DAG, която се обобщава от най-дългото правило на биткойн във верига към DAG. Phantom е предложение за Spectre и те предложиха алчен алгоритъм, наречен ghostDAG протокол, за да постигнат цялостно подреждане. Те обаче не доказаха коректността и жизнеността на алгоритъма си, нито предоставиха резултатите от симулацията за Phantom в разпределената настройка. Друга жива атака срещу Phantom беше предложена индивидуално от работата на Li et al. и работата от Кияиас и Панагиотакос. Те също така твърдяха, че ще се опитат да комбинират Phantom и Spectre в бъдеще. Ще актуализираме информацията, ако те предоставят нови и правилни резултати.

В DEXON коректността и жизнеността на византийското споразумение DEXON са строго доказани.

17. Радикс

ОФИЦИАЛЕН САЙТ: https://www.radixdlt.com
ТЕХНИЧЕСКИ РЕСУРСИ: https://papers.radixdlt.com/tempo/latest/#ab абстракт

Radix използва техниката на заточване, за да увеличи пропускателната способност. За да се постигне консенсус между различните части, транзакция трябва да бъде ключена и да бъде потвърдена от много възли. Всеки възел предоставя своя локален логически часовник и добавя своята стойност към транзакцията. След това възлите могат да използват този логически вектор на часовника, за да решат частично подреждане между две конфликтни транзакции. В случай на съвместен набор, възел намира други транзакции от локалното си хранилище или от своя партньор, който се опитва да реши частично подреждане на транзакциите.

Въпреки това, може да се каже, че има основен проблем в Radix: частичното подреждане никога не може да стане пълно подреждане без консенсус алгоритъм. Някои частични подреждания на транзакции в Radix могат да бъдат решени чрез векторни времеви марки, но без значение колко транзакции са замесени, винаги има някои случаи, които едновременните набори могат да разрешат. С други думи, поръчките на някои транзакции никога не могат да бъдат решени и няма да бъдат извеждани от системата. Освен това, когато мрежата е кратко разделена или има голямо закъснение, възлите могат да имат различни локални изгледи. Тъй като възелът решава поръчка от други транзакции от своя локален изглед, това ще доведе до различно подреждане между възлите, което ще доведе до вилица, и в Radix няма алгоритъм за консенсус, който да реши този проблем.

В обобщение, Radix няма консенсус. Може да се използва в частни / разрешени настройки, но няма да работи в реална мрежа.

18. Снежинка

WHITEPAPER: От екипна ракета

Консенсусът на Snowflake започва от обикновен метод за оцветяване, добавя допълнителни броячи и правила и накрая завършва с доказан вероятностен сигурен алгоритъм за консенсус, Avalanche. Всички възли се сближават в един и същи цвят, което означава, че ще се споразумеят за една и съща транзакция, когато се случи конфликт.

За да разрешат конфликтни транзакции, възлите трябва да изпълняват алгоритъм на лавина за всяка транзакция в набор от конфликти. Злоумишлено, един атакуващ може да спами системата с голям брой конфликтни транзакции, в резултат на което системата да изпълнява лавина алгоритъм стотици хиляди пъти, а латентността ще нарасне значително. DEXON няма да страда от такава атака. DEXON Византийското споразумение остава бързо, независимо колко конфликтни транзакции има.

19. Призрак

ОФИЦИАЛЕН САЙТ: https://spectreproject.io
ТЕХНИЧЕСКИ РЕСУРСИ: https://eprint.iacr.org/2018/104.pdf

Spectre е базирана на DAG система за цифрова книга, която използва рекурсивно блоково гласуване, за да реши кой блок на конфликт трябва да бъде финализиран. Този алгоритъм за консенсус позволява на участниците да предлагат блокове произволно бързо, което означава, че неговата мащабируемост и латентност са ограничени към мрежата. Липсата на цялостно подреждане на блокове обаче прави невъзможно изпълнението на интелигентен договор. Ето защо те предлагат „Phantom“, консенсус, който също се основава на DAG, но с общи свойства за подреждане. Сравняваме също DEXON с Phantom.

20. Звездна

ОФИЦИАЛЕН САЙТ: https://www.stellar.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://www.stellar.org/papers/stellar-consensus-protocol.pdf

Stellar използва обобщена версия на традиционния протокол на византийското споразумение, който те нарекоха „федерално византийско споразумение.“ Този алгоритъм за консенсус изисква участниците да избират свои собствени квотни резени. Ако пресечката на кворум е удовлетворена, се доказва, че всички непокътнати участници ще постигнат консенсус.

Единственото притеснение от този вид консенсус е, че дали даден възел може да остане непокътнат (да не е засегнат от византийските възли) зависи от избора на неговите кворни резени. За да имате сигурна конфигурация с бърза реакция и стабилна услуга, по-добре е възелът да избира възли, създадени от надеждни компании или банки, като квотни резени, което може да доведе до полуцентрализация.

21. Нежна мента

ОФИЦИАЛЕН САЙТ: https://tendermint.com
ТЕХНИЧЕСКИ РЕСУРСИ: https://tendermint.com/docs/

Tendermint използва PBFT като техен консенсус алгоритъм. Въпреки че PBFT има ниска латентност в разрешени настройки, той не може да бъде без разрешение, тъй като PBFT има големи разходи за комуникация поради двуфазния си ангажимент. Това означава, че когато броят на възлите се увеличи, необходимата честотна лента на мрежата също ще се увеличи квадратично, ограничавайки броя на възлите. DEXON използва криптографска техника за сортиране на криптографско сортиране и конфигурируема ак честота, за да намали разходите за комуникация.

22. Гръмотевица

ОФИЦИАЛЕН САЙТ: https://www.thundercore.com
ТЕХНИЧЕСКИ РЕСУРСИ: https://eprint.iacr.org/2017/913.pdf

Thunderella комбинира два различни алгоритъма на консенсус и се опитва да постигне висока сигурност с добри резултати. С по-малко от една четвърт от комитета са византийски възли, той може да постигне ниска латентност с BFT алгоритъм. С повече от една четвърт може да се върне към всяка блокчейн система, която може да понася по-малко от 1/2 от n византийски възли.

Ако повече от една четвърт от комитета са византийски възли, Thunderella става по-бавна, докато DEXON остава ниската си латентност. Също така Thunderella е верижна система и мащабирането може да бъде проблем.

23. ТОН

TECH RESOURCES: https://drive.google.com/file/d/1ucUeKg_NiR8RxNAonb8Q55jZha03WC0O/view

TON (Telegram Open Network) е блокчейна система, която се отличава с висока пропускателна способност с кратко време за потвърждение. За да постигнат това, те предлагат нова гледна точка, наречена „Безкрайна парадигма на заточване“, която се опитва да изтласка изострянето до своята крайност. В TON има masterchain за общо финализиране на състоянието. Под masterchain има няколко работни вериги за изпълнение на конкретни задачи за различни криптовалути и услуги. Ако една работна верига е претоварена, под нея може да има няколко шейдър вериги за увеличаване на пропускателната способност. Във всяка верига валидаторите изпълняват базиран на BFT алгоритъм за консенсус с DPoS механизъм, за да предлагат блокове. С този заточващ дизайн TON твърди, че може да достигне няколко милиона TPS с 5 секунди закъснение.

Една съществена разлика между TON и DEXON е, че TON трябва да стартира BFT консенсус алгоритъм на няколко различни нива на веригите. За masterchain, той изисква всички валидатори да участват в BFT алгоритъм. Тъй като BFT алгоритъмът обикновено не е мащабируем, можем да имаме само ограничен брой възли, които да участват в masterchain. Това може да се счита за малко централизирано. В DEXON не изискваме всички възли да изпълняват един BFT алгоритъм; по този начин можем да имаме стотици хиляди възли, участващи в нашата система.

TON също има проблем с финализирането. Той позволява на валидаторите да променят невалидни блокове, без да разклонява, тъй като е по-ефективен и ще засегне само някои блокове история. Този дизайн обаче позволява на атакуващия да променя произволни блокове история, ако те могат да компрометират набора на валидатора. Обикновено в система с финализиране на BFT би трябвало да е невъзможно да се променя историята, дори ако текущият набор валидатор е компрометиран. Дори при традиционната PoW схема, стартирането на 51% атака и модифицирането на исторически блокове има много по-висока цена с ниска вероятност за успех. Този дизайн може да причини проблеми със сигурността в TON.

24. Вите

ОФИЦИАЛЕН САЙТ: https://www.vite.org
ТЕХНИЧЕСКИ РЕСУРСИ: https://www.vite.org/whitepaper/vite_en.pdf

Вите поправя основно проблема на NANO, който споменахме в сравнението си с NANO. Той използва същата блокчейна решетка с NANO и добавя нов механизъм за консенсус (HDPoS) за изграждане на верига за моментни снимки. Това не само решава проблеми със сигурността в NANO, но и нарежда транзакции, което го прави способен да изпълнява интелигентни договори. Нещо повече, Vite наследява предимствата на NANO, включително почти моментални транзакции с висока TPS.

Едно от трудните предизвикателства при използването на DAG структура е да се решава редът на транзакциите. Vite има глобална консенсусна група, която управлява консенсус алгоритъм за създаване на верига за моментни снимки. Този алгоритъм е важен, тъй като е ключът към подобряване на недостатъците на NANO по отношение на сигурността и липсата на цялостна поръчка. За съжаление, ние не можем да намерим подробности за алгоритъма в тяхната хартия и не знаем как транзакциите върху блокчейн се избират и поставят в моментна верига. Безопасен и справедлив ли е този критичен процес? За да се справи с тези предизвикателства, DEXON разработва нашия собствен алгоритъм за бързо византийско споразумение и той е доказано сигурен и разумно справедлив.

25. Zilliqa

ОФИЦИАЛЕН САЙТ: https://zilliqa.com
ТЕХНИЧЕСКИ РЕСУРСИ: https://arxiv.org/pdf/1801.00687.pdf

Zilliqa е оптимизиран PBFT. Той използва многоподпис на EC-Schnorr за обединяване на подписи от възли. Това намалява разходите за комуникация. За да се справи с ограничената пропускателна способност във верижна система, Zilliqa използва техника на заточване, за да обработва паралелно транзакции. Специфичен фрагмент събира микро блокове от нормални парчета, за да произведе крайни блокове.

В Zilliqa има няколко недостатъка. Първо, обединяването с много подписи е изчислително скъпо. Това не е проблем с десетсекундното време за финализиране, но във времето за финализиране на втората секунда, това не е възможно с голям брой възли в фрагмент. Второ, Zilliqa използва специфичен протокол за консенсус, изпълняващ шейд, за да комбинира микро блокове от други части. Това удвоява латентността. В DEXON няма конкретен шейдър, който да изпълни друг излишен консенсус протокол. Механизмът за затягане на DEXON е симетричен. DEXON използва заточване на състоянието, което означава, че всеки фрагмент съхранява само състояние, свързано със себе си. Този механизъм за заточване е симетричен, което означава, че всеки шрифт има еднакъв принос по отношение на консенсус и това се счита за по-справедливо.

заключение

В обобщение, има много блокчейн системи със собствени силни страни и недостатъци. В тази статия ние подчертаваме 25 (от кой знае колко) блокчейн системи, които са достъпни публично. Макар че искаме да сравним тези системи с DEXON, едно от ключовите мерки, които желаем да имаме като читател, е да разберем, че blockchain (или технологията на дистрибутираната книга) все още е в начален стадий и с иновациите, въведени в този начален етап, технологията е настроен да зрее и да процъфтява за нула време, с повече налични блокчейн системи, които биха могли да се възползват от компания или човек според техните специфични нужди.

Ако искате да обсъдим тази статия или искате да добавим още в този списък, говорете директно с техническия екип на DEXON чрез Gitter: https://gitter.im/dexon-foundation/Lobby

Ние приветстваме вашите мнения и искаме да обогатим съществуващия набор от знания относно blockchain технологията в полза на всички.

Нека да поговорим за DEXON

Можете да се регистрирате за бюлетина за най-новите актуализации или да се присъедините към нас в нашите различни дискусии в общността в различни платформи.

Discussions Дискусии в Telegram: https://t.me/dexon_foundation
Обяви: https://t.me/dexon_news
Aler Сигнали за измама: https://t.me/dexon_scam_alerts

Gitter (официален разговор на DEXON за разработчици): https://gitter.im/dexon-foundation/Lobby
Github: https://github.com/dexon-foundation
Reddit: https://www.reddit.com/r/DEXONFoundation/

Twitter: https://twitter.com/dexonfoundation
Faceboook: https://www.facebook.com/DEXON.Foundation/
YouTube: https://www.youtube.com/channel/UCbg6l4M8QmSrJphxQvKof5g
Среден: https://medium.com/dexon