- TRON
- Прогресс с момента создания проекта
- Архитектура
- 3 слоя
- Основной слой
- Уровень хранения данных
- Уровень приложений
- Протокол
- Что такое протокольные буферы?
- Децентрализованная биржа (DEX)
- Консенсус
- Делегированное доказательство доли (DPoS)
- В сети TRON существует три типа узлов: узел-свидетель, полный узел и солидный узел.
- Счет
- Типы
- Создание
- Структура
- Блок
- Заголовок блока
- Транзакции
- Подписание :-
- Модель пропускной способности :-
- Виртуальная машина TRON (TVM)
TRON
Протокол TRON, одна из крупнейших операционных систем на основе блокчейна в
предлагает поддержку публичного блокчейна с высокой пропускной способностью, высокой масштабируемостью и высокой доступностью для
всех децентрализованных приложений (DApps) в экосистеме TRON.
Прогресс с момента создания проекта
- Фонд TRON был создан в июле 2017 года в Сингапуре.
- В декабре 2017 года TRON запустил свой протокол с открытым исходным кодом. Testnet, Blockchain Explorer и Web Wallet были запущены к марту 2018 года.
- Вскоре после этого в мае 2018 года был запущен TRON Mainnet, что ознаменовало выход Odyssey 2.0 как техническую веху.
- В июне 2018 года TRON объявил о своей независимости, создав блок Genesis, а в июле 2018 года приобрел BitTorrent.
- В октябре 2018 года TRON запустил виртуальную машину TRON Virtual Machine (TVM), полный набор инструментов для разработчиков и систему поддержки 360. Дорожная карта TRON предусматривает объединение 100 миллионов пользователей BitTorrent с сетью TRON через Project Atlas, а также содействие сообществу разработчиков в запуске новых интересных DApps в сети TRON.
Архитектура
💡 Следующая статья написана самим основателем TRON, поэтому ознакомьтесь с ней,
Техническая архитектура блокчейна TRON | Gemini
💡 Ниже приведена ссылка на архитектуру TRON (официальный PDF)
TRON использует трехслойную архитектуру, разделенную на уровень хранения, уровень ядра и уровень приложений.
Протокол TRON придерживается протокола Google Protobuf, который по своей сути поддерживает мультиязычное
расширение
Диаграмма 3-слойной архитектуры Tron
3 слоя
Основной слой
В основном слое есть несколько модулей, включая смарт-контракты, управление счетами и
консенсус. На TRON реализована виртуальная машина на основе стека и используется оптимизированный набор инструкций.
используется оптимизированный набор инструкций. Чтобы лучше поддержать разработчиков DApp, в качестве языка смарт-контрактов был выбран Solidity.
язык, а в будущем планируется поддержка других продвинутых языков. Кроме того, механизм консенсуса TRON
механизм консенсуса TRON основан на делегированном доказательстве ставки (DPoS).
чтобы удовлетворить его уникальные требования.
Уровень хранения данных
TRON разработал уникальный протокол распределенного хранения, состоящий из хранилища блоков и хранилища состояний.
Хранилище. Понятие графовой базы данных было введено в дизайн уровня хранения, чтобы
лучше удовлетворить потребность в диверсифицированном хранении данных в реальном мире.
- Хранилище Blockchain Storage :- Хранилище Blockchain Storage компанииTRON выбирает использование LevelDB, которая разработана компанией Google и доказала свою успешность во многих компаниях и проектах. Она обладает высокой производительностью и поддерживает произвольные байтовые массивы в качестве ключей и значений, сингулярные get, put и delete, batched put и delete, двунаправленные литераторы и простое сжатие с помощью очень быстрого алгоритма Snappy.
- Хранение состояния :-TRON имеет KhaosDB в памяти всех узлов, которая может хранить все новые форкированные цепи, созданные в течение определенного периода времени, и поддерживает свидетелей для быстрого перехода от их собственной активной цепи к новой основной цепи. Она также может защитить хранилище блокчейна, сделав его более устойчивым к аномальному завершению в промежуточном состоянии.
Уровень приложений
Разработчики могут создавать на TRON разнообразные DApps и специализированные кошельки. Поскольку TRON
позволяет развертывать и исполнять смарт-контракты, возможности полезных приложений неограниченны.
Протокол
Протокол TRON придерживается протокола Google Protocol Buffers, который является нейтральным по языку, платформе,
и расширяемый способ сериализации структурированных данных для использования в коммуникационных протоколах, хранении данных,
и т. д.
Что такое протокольные буферы?
Буферы протоколов (Protobuf) – это гибкий, эффективный, автоматизированный механизм для сериализации структурированных данных, подобно JSON или XML.
данных, подобно JSON или XML, но гораздо меньше, быстрее и проще.
Определения Protobuf (.proto) могут быть использованы для генерации кода для C++, Java, C#, Python, Ruby,
Golang и Objective-C с помощью официальных генераторов кода. Различные сторонние
реализации также доступны для многих других языков. Protobuf облегчает разработку для
клиентов за счет унификации определений API, а также оптимизации передачи данных. Клиенты могут взять API
.proto из репозитория протоколов TRON и интегрировать их с помощью автоматически создаваемых кодовых
библиотеки.
Для сравнения, Protocol Buffers в 3-10 раз меньше и в 20-100 раз быстрее, чем XML,
с менее неоднозначным синтаксисом. Protobuf генерирует классы доступа к данным, которые проще использовать
программно.
Децентрализованная биржа (DEX)
Сеть TRON изначально поддерживает функции децентрализованного обмена. Децентрализованная биржа
состоит из нескольких торговых пар. Торговая пара (обозначение “Биржа”) представляет собой биржевой рынок
между токенами TRC-10 или между токеном TRC-10 и TRX. Любой аккаунт может создать торговую
пары между любыми токенами, даже если такая же пара уже существует в сети TRON. Торговля и колебания цен торговых пар следуют протоколу Bancor. В сети TRON предусмотрено, что веса двух токенов во всех торговых парах равны, поэтому соотношение их балансов и есть цена между ними.
💡 Код блокчейна TRON реализован на Java и изначально был форком от EthereumJ.
Консенсус
Tron использует DPoS
Делегированное доказательство доли (DPoS)
В сетях PoS держатели токенов блокируют свои балансы токенов, чтобы стать блокчейнами.
валидаторами. Валидаторы по очереди предлагают и голосуют за следующий блок. Однако проблема
со стандартным PoS заключается в том, что влияние валидаторов напрямую зависит от количества заблокированных токенов.
Это приводит к тому, что стороны, хранящие большое количество базовой валюты сети, оказывают чрезмерное
влияние на экосистему сети.
Механизм консенсуса TRON использует инновационную систему делегированного доказательства доли, в которой 27
Суперпредставители (СП) производят блоки для сети. Каждые 6 часов владельцы счетов TRX
которые заморозили свои счета, могут проголосовать за выбор кандидатов в СР, а 27 лучших кандидатов
считаются СР. Избиратели могут выбирать СР на основе таких критериев, как проекты, спонсируемые СР для повышения популярности TRX, и вознаграждения, распределяемые среди избирателей. Это позволяет создать более демократичную и децентрализованную экосистему. Счета SRs являются обычными счетами, но накопление ими голосов
позволяет им производить блоки. Учитывая низкую пропускную способность Bitcoin и Ethereum из-за их механизма консенсуса PoW и проблем с масштабируемостью, система DPoS в TRON предлагает инновационный механизм, обеспечивающий 2000 TPS по сравнению с 3 TPS у Bitcoin и 15 TPS у Ethereum.
Сеть протокола TRON генерирует один блок каждые три секунды, и каждый блок начисляет 32
TRX суперпредставителям. В общей сложности 27 СР будут ежегодно получать 336 384 000 TRX.
Каждый раз, когда СР заканчивает добычу блока, вознаграждение отправляется на субсчет в супер-бухгалтерии.
SR могут проверять, но не использовать напрямую эти токены TRX. Вывод средств может быть осуществлен каждым
SR раз в 24 часа, переводя вознаграждения с субсчета на указанный счет SR.
Для более подробной информации смотрите здесь :-
Основы алгоритма консенсуса DPoS в TRON
В сети TRON существует три типа узлов: узел-свидетель, полный узел и солидный узел.
- Узлы-свидетели создаются ПП и в основном отвечают за производство блоков и создание/голосование предложений.
- Полные узлы предоставляют API и транслируют транзакции и блоки.
- Узлы Solidity синхронизируют блоки с другими полными узлами и также предоставляют индексируемые API.
💡 SR = Суперпредставитель (производители блоков)
Счет
Типы
В сети TRON существует три типа счетов: обычные счета, счета-токены и
контрактные счета.
1.Обычные счета используются для стандартных транзакций.
2.Токен-счета используются для хранения токенов TRC-10.
3.контрактные счета – это смарт-контракты, созданные обычными счетами, которые могут быть запущены и обычными счетами.
Создание
Существует три способа создания счета TRON:
- Создать новый счет через API
- Перевести TRX на новый адрес счета
- Перевести любой токен TRC-10 на новый адрес счета.
Структура
- имя_счета: имя для этого счета – например, BillsAccount.
- тип: тип счета – например, 0 (означает тип “Обычный”).
- balance: баланс этого счета – например, 4213312.16
- vote: полученные голоса по данному счету – например, {(“0x1b7w…9xj3”,323),(“0x8djq…j12m”,88),…,(“0x82nd…mx6i”,10001)}.
- asset: другие активы, ожидаемые TRX на этом счете – например, {< “WishToken”, 66666>, < “Dogie”, 233>}.
- latest_operation_time: время последней операции на этом счете.
message Account {
message Vote {
bytes vote_address = 1;
int64 vote_count = 2;
}
bytes accout_name = 1;
AccountType type = 2;
bytes address = 3;
int64 balance = 4;
repeated Vote votes = 5;
map<string, int64> asset = 6;
int64 latest_operation_time = 10;
}
enum AccountType {
Normal = 0;
AssetIssue = 1;
Contract = 2;
}
Блок
Блок обычно содержит заголовок блока и несколько транзакций.
message Block {
BlockHeader block_header = 1;
repeated Transaction transactions = 2;
}
Заголовок блока
Необработанные данные обозначаются в Protobuf как raw_data. Он содержит исходные данные сообщения, содержащие 6 параметров:
- timestamp: метка времени этого сообщения – например, 1543884429000.
- txTrieRoot: корень дерева Меркла – например, 7dacsa…3ed.
- parentHash: хэш последнего блока – например, 7dacsa…3ed.
- number: высота блока – например, 4638708.
- version: зарезервированная версия – например, 5.
- witness_address: адрес свидетеля, упакованного в этот блок – например, 41928c…4d21.
message BlockHeader {
message raw {
int64 timestamp = 1;
bytes txTrieRoot = 2;
bytes parentHash = 3;
uint64 number = 4;
uint64 version = 5;
bytes witness_address = 6;
}
bytes witness_signature = 2
;
bytes blockID = 3;
}
💡 Подпись свидетеля обозначается как witness_signature в Protobuf, это подпись для заголовка данного блока от узла свидетеля.
💡 Идентификатор блока обозначается как blockID в Protobuf. Он содержит атомарную идентификацию блока. Блок
ID содержит 2 параметра:
hash: хэш блока.
number: хэш и высота блока.
Транзакции
Подписание :-
Процесс подписания транзакций в TRON осуществляется по стандартному криптографическому алгоритму ECDSA с кривой выбора SECP256K1. Закрытый ключ – это случайное число, а открытый ключ – точка на эллиптической кривой. Процесс генерации открытого ключа состоит в том, что сначала генерируется случайное число в качестве
а затем умножение базовой точки эллиптической кривой на закрытый ключ для получения открытого ключа. Когда происходит транзакция, исходные данные транзакции сначала преобразуются в формат байтов.
Затем исходные данные подвергаются хэшированию SHA-256. Закрытый ключ, соответствующий контракту
подписывает результат хэширования SHA256. Результат подписи добавляется к транзакции.
Модель пропускной способности :-
Обычные транзакции потребляют только очки пропускной способности, а операции с умными контрактами потребляют как
энергию и точки пропускной способности. Существует два типа очков пропускной способности. Пользователи могут получить
очков пропускной способности при замораживании TRX, в то время как 5000 бесплатных очков пропускной способности также доступны ежедневно.
Когда транзакция TRX транслируется, она передается и сохраняется в виде массива байтов по сети. Баллы пропускной способности, потребляемые одной транзакцией = количество байтов транзакции, умноженное на скорость передачи баллов пропускной способности. Например, если длина массива байтов транзакции равна 200, то транзакция потребляет 200 пунктов пропускной способности. Однако если в результате перевода TRX или токенов создается целевой счет, то списываются только очки пропускной способности, затраченные на создание счета, а дополнительные очки пропускной способности не списываются. В сценарии создания счета сеть сначала израсходует очки пропускной способности, которые инициатор транзакции получил в результате замораживания TRX. Если этого количества недостаточно, то сеть расходует TRX инициатора транзакции. В стандартных сценариях перевода TRX с одного счета TRX на другой, сеть сначала расходует очки пропускной способности, полученные инициатором транзакции за замораживание TRX. Если этого недостаточно, то расходуются 5000 бесплатных ежедневных очков пропускной способности. Если и этого недостаточно, то сеть расходует TRX инициатора транзакции. Сумма рассчитывается по количеству байтов в транзакции, умноженному на 10 SUN. Таким образом, для большинства держателей TRX, которым необязательно замораживать свои TRX для участия в голосовании SR, первый шаг автоматически пропускается (поскольку баланс TRX заморожен = 0), и транзакция выполняется на 5000 ежедневных свободных полос пропускания.
При передаче токенов TRC-10 сеть сначала проверяет, достаточно ли общего количества свободных пунктов пропускной способности выпущенного актива токена. Если нет, то расходуются пункты пропускной способности, полученные при замораживании TRX. Если точек пропускной способности все еще недостаточно, то расходуются TRX инициатора транзакции.
Виртуальная машина TRON (TVM)
TVM – это легкая, полная по Тьюрингу виртуальная машина, разработанная для экосистемы TRON. Сайт
TVM легко соединяется с существующей экосистемой разработки, чтобы предоставить миллионам глобальных разработчиков
разработчиков с созданной на заказ блокчейн-системой, которая является эффективной, удобной, стабильной, безопасной и
масштабируемой.
Ура!!!
Аксат Бхардвадж
Разработчик блокчейна и технолог