Криптовалюта TON Crystal

Официальное название: Проект Free TON. Монета TON Crystal

Тикер: TON Crystal

Исходный код: https://github.com/tonlabs

Telegram Official: https://t.me/ton_crystal_news

CoinMarketCap: Еще нет

Что такое Free TON?

Free TON - это блокчейн платформа, построенная на протоколе TON, который разработала команда Telegram. Запуск (07.05.2020) произвели независимые разработчики, валидаторы, компании и другие представители криптовалютного мира. Telegram не участвовал в запуске платформы. Деньги на запуск платформы не собирались, токены не продавались.

Архитектура

В основе архитектуры Free TON — децентрализованная операционная система TON OS, которая представляет собой программный стек, или middleware-интерфейс между блокчейн-сетью и пользователями. Разработчики Free TON приводят аналогию с компьютером, где сам блокчейн — это «железо», а TON OS — инфраструктура над ним и интерфейс для разработчиков и пользователей.

Free TON включает в себя набор инструментов для разработки приложений под TON OS — например, компиляторы с Solidity, C++, базы данных и SDK.

Еще одна особенность операционной системы — наличие пользовательского интерфейса TON Surf, отчасти схожего с интерфейсом Linux. В TON Surf есть готовые защищенные приложения: браузер, кошелек и чат.

Все компоненты платформы, включая TON OS, — это ПО с открытым исходным кодом, которое участникам сообщества можно дорабатывать и улучшать.

TON Crystal

TON Crystal - валюта блокчейна. Купить на текущий момент нельзя. Кристаллы можно получить участвуя в конкурсах. Предусмотрена эмиссия 5 000 000 000 токенов, 85% из которых будут распределены среди первых участников сети через конкурсы и бесплатные раздачи. 10% токенов будут распределены между разработчиками. 5% будут распределены между валидаторами.

Сейчас токены находятся под контролем 23-х первоначальных членов — initial members. Они договорились, что пока сеть не будет достаточно децентрализована, токены распространять не будут.

Но нужно понимать, что как только конкурсные призы начнут выдаваться, победители уже смогут распоряжаться токенами на свое усмотрение. И потенциально могут появиться какие-то места, где их будут продавать.

Конкурсы

Конкурс — это механизм, который стимулирует разных людей делать разные [программные] решения. Это еще одна составляющая децентрализации.

Все смотрят на тему нод, но мало кто понимает, что есть еще вопрос самого софта — кто его пишет и сколько вариантов этого софта существует. Например, в большинстве блокчейнов существует всего одна имплементация ноды (программная реализация какого-либо протокола или алгоритма). И только та команда, которая ее написала, может вносить в нее изменения. А ценность Free TON — в наличии двух имплементаций. Как в эфире, кстати говоря.

Комьюнити будет приветствовать выделение токенов для поддержки решений на всех уровнях: на уровне ноды, на уровне инструментария доступа к ноде, компиляторов. В этом смысле децентрализацию Free TON отличает еще то, что у нас есть альтернативные решения на всех уровнях ПО.

Выдача тех же грантов — это более централизованное решение. Когда есть кто-то, кто говорит: я даю грант вот сюда, сюда и сюда — это централизованный механизм. А подход Free TON с конкурсами более децентрализованный и демократичный. Он позволяет увидеть большее количество решений, лучше подходящие для концепции децентрализации.

Как показала практика, эти комитеты, которые обычно выделяют гранты, по сути дают токены в первую очередь тем, кого лично знают, у кого есть какая-то репутация. А это отсекает большой пласт талантливых разработчиков, которые наверняка могут сделать что-то лучше, но просто не знают, как туда попасть

Децентрализация в контексте Free TON

Источник - Децентрализация, на самом деле, вещь многоуровневая. Обычно все смотрят на количество нод. При этом считается, что биткоин и эфир децентрализованы потому, что у них используется большое количество нод, то есть оборудования, которое стоит в разных местах. Но проблема в том, что это оборудование блоки не выпускает. Оно только рассчитывает ключи для записывания новых блоков. А новые блоки записывают всего два пула — и в биткоине, и в эфире. То есть, если говорить в терминах Free TON, у биткоина и эфира всего по два валидатора, которые контролируют сеть. Вот эту особенность мало кто понимает.

Для сравнения, мы сейчас запустили конкурс, по итогам которого к нам пришло 350 независимых валидаторов. И мы принципиально решили, что на одну команду будем выдавать один приз. То есть мы хотим, чтобы не случилось такой истории, когда кто-то, например, запустит 200 валидаторов и начнет контролировать сеть. Но опять же, 350 валидаторов — это первый, важный этап. Добавив всех этих валидаторов, мы станем одной из самых, если не самой, децентрализованной PoS-сетью.

Децентрализации сеть еще не достигла, это планируется сделать в три этапа. На момент написания поста сеть находится на первом этапе под кодовым названием "Бешеный бык" и разработчики пока могут вносить изменения в конфигурацию сети/ См. об этом ниже.

Отличие сетей, построенных на протоколе TON, от других блокчейнов в скорости транзакций и возможности масштабирования. Идея TON была в том, чтобы существенно повлиять на внедрение блокчейна в массы — таковой она осталась и во Free TON. То же самое касается фокуса на user-базу: Free TON распределит бесплатно децентрализованно 85% токенов между конечными пользователями экосистемы.

Глобально Free TON — это первый блокчейн с таким уровнем производительности, который позволяет делать большие пользовательские кейсы — кейсы которые требуют высокой пропускной способности сети, или того, что по-английски называется high throughput. Free TON помогает приблизить UX/UI к тому уровню, к которому привыкли пользователи. То есть мы — я имею в виду коммьюнити Free TON — выводим блокчейн-технологии из нишевого мира для криптогиков в мейнстрим.

99% работающих сейчас блокчейн-решений, которые имеют какую-то оценку, работают в одну цепочку. И это их фундаментальное ограничение. Есть такие, которые работают быстрее, где пропускная способность составляет тысячи транзакций в секунду. Есть и более медленные. Но всё это — одна цепочка.

По определению, на одном компьютере нельзя обеспечить весь мир. Чтобы юзкейсы работали для всего мира, нужно чтобы, условно говоря, компьютеров было много. Это называется шардингом (sharding), или шардированным блокчейном. Free TON — это первый блокчейн с динамическим шардингом. Здесь шарды возникают по мере нагрузки. И это естественно: если у тебя не справляется один компьютер — окей, ставим рядом второй, третий, тысячный и так далее.

Конечно, есть ограничение, но оно настолько большое, что никакой набор практических кейсов, которые сейчас есть, не упрется в эту производительность. Архитектурно Free TON рассчитан на миллионы транзакций в секунду.

Криптовалюта TON Crystal и ее распределение

Нативная криптовалюта блокчейна Free TON называется TON Crystal. Совокупная эмиссия токенов составит 5 млрд, при этом по замыслу сообщества проекта, все токены изначально должны быть распределены на нефинансовых условиях.

Токены из генезис-блока распределены между несколькими смарт-контрактами, которые не будут участвовать в стейкинге или голосованиях. Все токены TON Crystal планируется распределить следующим образом:

85% получит смарт-контракт Referral Giver для распределения между первыми пользователями, промоутерами проекта и другими участниками сети, чей вклад в развитие связан с развитием сообщества вокруг проекта.
5% получит смарт-контракт Validator Giver для их распределения между валидаторами сети.
10% получит смарт-контракт Developer Giver для привлечения к работе над проектом профессиональных разработчиков, которые в том числе будут строить приложения поверх блокчейна Free TON.

После завершения распределения все токены TON Crystal будут распространяться свободно.

Все решения по распределению монет через контракты-дарители будут приниматься путем голосования через механизм Soft Majority Voting (SMV) держателями TON.

Например, если 10% держателей проголосуют «за» и 0% проголосуют «против», то SMV сочтет решение одобренным, поскольку высказались все, кто проявил интерес и ответственность. Если же проголосуют все, то будет работать традиционный принцип 50% +1.

Рис. № Сценарии SMV-голосования

Источник

Особенности проекта

Free TON включает в себя большую часть запланированных функциональных особенностей блокчейн-системы TON. В силу специфики запуска развитие сети разбито на три стадии (дорожная карта / road map). Примечательно, что каждая из них названа в честь известных американских фильмов.

Стадия I «Raging Bull» — разработчики могут вносить изменения в конфигурации сети. В код имплементируется «бомба децентрализации». Фактически это таймер обратного отсчета до момента, возможность изменения конфигурации в сети со стороны разработчиков будет отключена.

Стадия II «Rumble Fish» — на данной стадии валидаторы получат контроль над конфигурацией сети в результате сворачивания «бомбы децентрализации».

Стадия III «Fight Club» — сеть Free TON достигает полной децентрализации.

Как устроен TON Blockchain?

TON Blockchain по сути является коллекцией блокчейнов, состоящих из более мелких блокчейнов. Дизайн TON Blockchain предполагает, что все данные в блоках и статусы представлены как организованные в деревья ячеек или направленные ациклические графы (DAG) коллекции ячеек (bag of cells), состоящие из 1023 битов данных и содержащие до четырех ссылок на другие ячейки. Архитектура TON Blockchain предполагает наличие основного блокчейна — Masterchain, а также до 292 дополнительных блокчейнов. Такой подход позволит сделать систему гибкой к изменениям и минимизировать проблемы, связанные с ростом размера основной цепи.

Masterchain отвечает за функционирование всей системы, включая хранение хешей блоков, информацию о валидаторах, эмиссии монет, статус воркчейнов и т.п.

Рис.1

Источник

Задача блокчейна типа Workchain — поддерживать функционирование до 2 в 32 степени виртуальных воркчейнов (работающих блокчейнов), разбитых на шарды. Воркчейны отвечают за выполнение тьюринг-полных смарт-контрактов, созданных на новом языке программирования Fift, имеют собственные виртуальные машины (TVM) и идентификаторы и включают в себя до 2 в 60 степени шардов.

Создать и активировать воркчейн может любой участник сообщества, готовый заплатить высокую комиссию за публикацию его спецификации в транзакции на Masterchain и получивший одобрение ⅔ валидаторов сети. На сегодня идентификатор имеет только основной воркчейн (Workchain Zero, workchain_id = 0), работающий со смарт-контрактами TON и транзакциями Gram.

Shardchain обеспечивает системе масштабируемость. Предполагается, что за счет внедрения «парадигмы бесконечного шардинга» (Infinite Sharding Paradigm) блокчейны TON смогут автоматически разделяться и объединяться в зависимости от нагрузки в сети, обеспечивая высокую скорость обработки данных и низкие комиссии.

Shardchain включает в себя множество небольших виртуальных блокчейнов — Accountchain, содержащих исходящие и входящие сообщения аккаунта, которые могут иметь отправителей и получателей как внутри системы TON, так и вовне (например, пользователи TON смогут получать и отправлять средства из блокчейнов биткоина, Ethereum и других).

Основная и тестовая сеть (Main net / Test net)

Основная сеть в Surf – main net или main.ton.dev.

Основная сеть уже есть в Surf (кошеле-браузер) для публичного доступа. Однако TON Crystal будут доступны для свободного обращения только после решения сообщества Free TON (Free TON Community).

Тестовая сеть - это test net или net.ton.dev с тестовыми токенами Ruby. Вы можете свободно переключаться между сетями в Surf: Settings → Advanced settings → Develop mode

Алгоритм консенсуса Catchain

Эта статья (оригинал от 2 марта 2020) посвящена одному из ключевых вопросов, отвечающему за безопасность и корректность работы блокчейна TON — протоколу достижения консенсуса между валидаторами сети, который подробно описан в документе Catchain Consensus: An Outline под авторством Николая Дурова.

По сути консенсус TON — это алгоритм из семейства BFT, который включает в себя как сам алгоритм консенсуса, так и протокол обмена сообщениями между узлами валидаторов сети. Известно, что BFT консенсус основан на т.н. “Соглашении Византийских Генералов” и описывает проблему достижения согласия в распределенной системе при условии, что отдельный участник не располагает информацией обо всей сети и не доверяет ни одному из ее участников.

Все блокчейн-системы можно условно разделить на два основных типа в зависимости от алгоритма достижения консенсуса:

1) Когда блоки создаются ДО достижения консенсуса (классические PoW, PoS и т.п. системы) с последующим сложным процессом согласования между участниками сети. При этом возможно одновременное существование нескольких “правильных” блокчейнов, из которых в дальнейшем выбирается одна истинная цепочка.

2) Когда блоки создаются ПОСЛЕ достижения консенсуса. В таких системах невозможно существование одновременно нескольких блокчейнов.

Catchain принадлежит ко второму типу алгоритмов, в которых предварительное согласование происходит до создания нового блока и промежуточные форки (разветвления) практически невозможны. Модель консенсуса Catchain основана на уже известном алгоритме practical Byzantine Fault Tolerance (Hyperledger Fabric, Zilliqa), обладающем повышенной стойкостью против атак Сивиллы в асинхронных сетях, а также имеет сходства с Tendermint (Cosmos) и алгоритмами dBFT (Neo, Algorand). Однако существует ряд принципиальных отличий, которые позволяют отнести его к отдельному классу алгоритмов.

Раунды валидации

Для конкретной задачи создания новых блоков одного из блокчейнов TON (мастерчейна или одного из активных шардчейнов) создается специальная группа, состоящая из нескольких валидаторов. Члены этой группы используются как для создания приватной оверлейной сети внутри ADNL*, так и для запуска соответствующего экземпляра протокола Catchain. Процесс достижения консенсуса состоит из нескольких раундов, которые выполняются внутри одного Catchain. В один момент времени может проходить несколько раундов, поскольку одни этапы одного раунда могут пересекаться с другими.

*ADNL - Abstract Datagram Network Layer. У TON сайтов есть адрес ADNL и TON Sites принимают запросы HTTP через протокол RLDP (который является протоколом RPC более высокого уровня, основанным на ADNL, главном протоколе сети TON) вместо обычного TCP/IP протокола. Всё шифрование обрабатывается ADNL и нет необходимости в использовании https протокола.В момент когда один из узлов посылает пакет другому узлу он должен знать один из его публичных ключей. Он зашифровывает пакет этим ключом и добавляет в начало пакета 256-битный адрес получателя — поскольку один узел может иметь несколько таких адресов, это позволит ему определить, какой ключ использовать для расшифровки. Вместо адреса получателя в начале пакета данных может находиться идентификатор канала. В таком случае обработка пакета уже зависит от конкретных договоренностей между узлами — например, отправленные в некий канал данные могут предназначаться другому узлу и должны быть ему переадресованы. Также может быть взаимодействие напрямую между узлами, но с шифрованием по индивидуальной паре ключей для этого канала. Это и называется называется ADNL. Также есть возможность реализации аналога TCP поверх него или собственной надстройки — RLDP Reliable Large Datagram Protocol.

Каждый раунд заканчивается либо коллективным принятием блока-кандидата, предложенного одним из участников процесса, либо принятием особого “нулевого кандидата”, т.е. не принятием ни одного из предложенных кандидатов. Раунд считается завершенным только после того, как потенциальный кандидат соберет подписи более чем 2/3 всех валидаторов и это событие может быть добавлено в специальный CommitSign, после чего процесс автоматически начинает участвовать в следующем раунде (с новым идентификатором).

Рис. 2

Источник

События одного раунда валидации происходят в следующей последовательности:

В начале каждого раунда несколько валидаторов (из заранее составленного списка) предоставляют свои т.н. блок-кандидаты (с задержками в зависимости от приоритета) и фиксируют этот факт посредством Submit events в данный catchain.

Как только процесс получает все необходимые файлы, он начинает валидацию этого кандидата и в конечном итоге создается одно из событий: Approve или Reject для данного конкретного кандидата.

Далее каждый валидатор голосует либо за кандидата, набравшего более 2/3 голосов, либо, если таких кандидатов еще нет, за действительного кандидата с наивысшим приоритетом. Голосование осуществляется путем создания событий голосования, встроенных в новые сообщения.

При каждой медленной попытке (т.е. любой попытке, кроме первой) процесс голосует либо за кандидата, который был предварительно принят (тем же самым процессом), либо за кандидата, который был предложен VoteFor.

Если в ходе такой попытки данный кандидат получил более 2/3 голосов «за», то создается следующее событие PreCommit, подтверждающее то, что все другие кандидаты отбрасываются.

Далее, если такой блок-кандидат собирает PreCommits более чем у 2/3 всех валидаторов внутри данной попытки, то он будет принят и отмечен событием CommitSign с действительной подписью блока.

Все подписи блоков регистрируются в catchain, и в конечном итоге собираются для создания «доказательства блока» (содержащего подписи более 2/3 валидаторов для этого блока). Такое доказательство является внешним выходом протокола консенсуса и распространяется в оверлейной сети полных узлов, которые подписывают новые блоки этого шардчейна или мастерчейна.

Как только кандидат в блоки собирает подписи CommitSign более чем у 2/3 всех валидаторов, раунд считается завершённым и процесс автоматически начинает участвовать в следующем раунде, игнорируя все события, связанные другими раундами.

Предотвращение форков

Как уже говорилось выше, в блокчейнах с традиционными механизмами защиты посредством Proof-of-Work и Proof-of-Stake, а также их гибридами, какое-то непродолжительное время могут существовать несколько “правильных” цепочек блоков или форков, из которых потом выбирается одна.

Система TON Blockchain, построенная на основе множества небольших блокчейнов (multi-blockchain), практически не оставляет шансов для возникновения такого рода событий, т.к. использует блокчейн в качестве средства трансляции сообщений внутри определённой группы процессов. Однако, всё же существует небольшая вероятность создания и одновременного подтверждения нескольких идентичных блоков.

Именно для предотвращения таких сценариев как раз и создан протокол Catchain, который методом создания двух (или более) разных версий одного и того же сообщения и рассылки их разным группам пиров, позволяет выявить форки на самой ранней стадии их возникновения.

Подписи блоков в Сatchain создаются таким образом, что подтверждение форков (т.е. доказательство намеренного его создания), является чрезвычайно простым, так как на самом деле подписывается хэш очень маленькой структуры (содержащий магическое число, порядковый номер блока, а также хэш остатка сообщения). Следовательно, для доказательства форка требуется только две такие маленькие структуры и две подписи.

Рис. 3

Источник

Как только обнаруживается форк (обычно это происходит при рекурсивной загрузке зависимостей некоторых других сообщений), одна группа узлов начинает игнорировать сообщения соседней группы и все свои последующие сообщения, т.е. они не принимаются и не транслируются далее. При этом, сообщения, созданные до обнаружения форка, могут быть загружены, если на них ссылаются в сообщениях (блоках), созданных процессами, которые не знают об этом форке до того, как на них ссылались.

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

Каждый узел хранит свою копию списка известных "плохих" участников сети в группе (таких, которые создали хотя бы один форк). Этот список постоянно обновляется при обнаружении нового форка. Таким образом, если отправитель определяется как "плохой", то его сообщение игнорируется и отбрасывается.

⭐Более детально с документацией можно ознакомиться вот здесь.

Валидаторы

Кто такие валидаторы?

Валидатор в сети Free TON это узел сети (нода, сервер), который участвует в валидации генерируемых новых блоков блокчейна.

Валидаторы - группа узлов сети, которые прошли выборы в валидаторы на определенный период (цикл валидации), в течение которого они совместно участвуют в валидации.

Валидация - это подписание блоков несколькими узлами для достижения консенсуса (общей договоренности) о правильности блока. Сама процедура достижения консенсуса необходима в сети для обеспечения надежности ее функционирования, то есть устойчивости к сбоям отдельных узлов или преднамеренным атакам.

Фактически валидаторы обеспечивают основу функционирования децентрализованной сети. За свою работу они получают вознаграждение состоящее из комиссии за обработку (1,7 TON за новый блок в мастерчейне, 1 TON за новый блок в шардчейне - инфа не точная!), а также из распределяемой по валидаторам эмиссии новых токенов. В текущих параметрах сети эмиссия зафиксирована на уровне 2% в год. Она распределяется каждый цикл валидации на всех валидаторов пропорционально их стейкам.

После генерации новых блоков в Shardchain, при достижении BFT-консенсуса всех валидаторов происходит генерация нового блока в Masterchain. Он включает в себя хеши последних шардчейн-блоков и делает все предыдущие блоки каноническими. Таким образом, не дожидаясь 20 подтверждений, заключенная в Shardchain транзакция может быть использована уже в следующем шардчейн-блоке.

В сети Free TON количество валидаторов может достигать 1000, из них валидацией блоков в мастерчейне (основной цепи блоков) могут заниматься до 100 валидаторов, а остальные валидируют блоки в шардчейнах (второстепенных цепях блоков).

Вся концепция децентрализации стоит на одном простом факте: если валидаторы независимые, то внесение неправильных изменений даже у 30% валидаторов не должно влиять на результаты вычислений, записываемых в блоки. Если большинство участников запустили правильный код и не вносили в него изменения, блоки записываются правильно. Это защита от тех, кто придет в сеть с целью записывать неправильные блоки или делать неправильные вычисления. В биткоине по-другому. Там побеждает более длинная цепочка. То есть, фактически, кто угодно может записать что угодно. Но если большинство участников, условно, честные и делают правильные вычисления, то побеждает более длинная цепочка. Это другая идеология защиты. Но у биткоина и эфира количество тех, кто формирует блоки, гораздо меньше, чем у Free TON.

⭐ Запуск Free TON ноды (С++). См. детали по ссылке.

Что такое стейкинг?

Концепция стейкинга подразумевает участие в совместном финансировании валидаторов, которые формируют стейкинг пул (staking pool) для намерения получения мандата на определенный период для валидации в TON блокчейн и получения соответствующего вознаграждения.

Surf (кошелек) выступает в качестве посредника (номинатора) и предлагает пользователям удобную систему участия в стейкниг пуле.

Все, что вам нужно, это перевести желаемое количество токенов в стейк до начала выборов валидаторов. Данные токены будут заблокированы.

Если валидатор избран TON блокчейном, то ваш стейк становится активным (т.е. используется в услуге) на фиксированных период, установленных блокчейном. Если валидатор не выбран, ваш стейк будет возвращен с соответствующим уведомлением.

Когда валидатор получит вознаграждения по механизму Proof of Stake (PoS), стейкинг-контракт DePool (см. про него ниже) поделится наградами с валидатором, вами и другими участниками, участвующими в стейкинг пуле данного валидатора.

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

Что такое контракт стейкинга DePool?

Один из смарт-контрактов в системе — контракт стейкинга, он же DePool (Decentralized Pool).

Во Free TON существует концепция устойчивой децентрализации — sustainable decentralization. Они считают, что единственный способ избежать негативного сценария, это децентрализация пулов. Например, простой пользователь — физическое лицо — отправляет в сеть 10 токенов на смарт-контракт DePool, что дает возможность валидатору использовать стейк для создания блоков. При этом валидатор, который подписывает блоки, не может голосовать этими токенами, и право голоса остается у пользователей — у тех владельцев небольшого количества токенов, которые отдали эти токены в децентрализованный пул.

Получается, с одной стороны, пользователи сохраняют возможность получать доход от этих токенов, используя их в стейкинге. С другой — сохраняют право голоса и не переходят к какому-то консолидатору. Так право голоса сохраняется у миллионов людей. Считается, что это очень важный компонент устойчивой децентрализации и уникальное свойство Free TON. Таких контрактов нет в других блокчейн-сетях.

⭐Детально и на английском см. здесь.

Рис. 5

Источник

Легенда схемы:

DePool - смарт-контракт для стейкинга, который позволяет другим смарт-контрактам инвестировать в общий пул средств и через некоторое время получить их назад с профитом.
Elector - системный смарт-контракт, работающий в мастерчейне. Периодически запускает выборы валидаторов.
DePool Proxy (proxy) - смарт-контракт, который доставляет сообщения между DePool и Elector.
Participant - смарт-контракт, который инвестирует в DePool.
Validator - софт блокчейн-ноды. Каждый смарт-контракт DePool работает только с одной нодой.
Validator wallet - смарт-контракт, который использует Validator для отправки запросов о результатах голосования в DePool.
DePool wallet - смарт-контракт, который хранит адрес текущего/актуального DePool-контракта и на который может быть выведена прибыль из DePool-контракта. Это может быть и кошелек валидатора, который поддерживал/обеспечивал работу DePool wallet.
Global Validators Set (GVS) - текущий набор/список валидаторов одобренный на прошлых выборах.
Validation period - период времени, на который был установлен список валидаторов (GVS).
Staking round - период времени между моментом инвестирования Участником (Participant) в DePool-контракт и получением своих средств обратно (с прибылью или без оной).
Timer - смарт-контракт, который время от времени может запускать тот или иной смарт-контракт.
DePool Association Contract - смарт-контракт, который хранит список всех зарегистрированных DePool-контрактов и статистику по раундам валидации, которые они совершили. DePool Association периодически получает назад все не потраченное pool_fraction-вознаграждение из DePool-контрактов.
Nominator Voting Contract - смарт-контракт, который аккумулирует голоса Участников за кандидатов в Валидаторы и выбирает Validator wallet для следующего стейкинг-раунда в DePool-контракте.

Описание процесса:

DePool is designed to receive investment stakes from Participants, allocate the pool funds to a validator in order to participate in elections of the GVS and after the end of the validation cycle distribute stakes with certain rewards back to the Participants.
DePool is deployed to basechain. But it cannot communicate with Elector directly, because Elector rejects messages from non-masterchain contracts. Thus there is a DePool proxy that is deployed to masterchain and delivers messages from DePool to Elector and back. Also gas and storage fees are 10 times smaller in basechain compared to masterchain.
DePool is open for Participants’ stakes anytime, however, there is a deadline for participation in the upcoming elections. The deadline depends on the timer of the Elector. After the deadline, the incoming stakes will be accumulated for participation in the next elections.
DePool distinguishes stakes received before the deadline and after the deadline, therefore it stores information on Participant stakes in separate staking rounds (or rounds), one for every elections, to facilitate subsequent distribution of stakes and rewards.
In order to be time aware, the DePool should be called from time to time. For this purpose the Timer contract is used. DePool wallet asks Timer to call it periodically and transmits every call from Timer to DePool. Interval between calls is chosen according to elections interval.
Elector uses validation cycle consisting of three phases: elections, validation, investigation (freezing). In the election phase the GVS is elected; it is expected to last 20% of the total round timespan. In the second phase elected validators must validate blocks, it lasts 40% of the validation cycle timespan. In the last 40% of the round the stakes and rewards are frozen by the Elector smart-contract to provide time to detect invalid blocks signed by the previous validator set, if any.
DePool must be linked to a validator wallet to participate in elections on behalf of the latter. Thus DePool must be deployed with validator wallet address that cannot be changed in future. When elections start DePool waits for signed election requests from linked wallet, then attaches round stake to request and transmits it to Elector.
Participants can choose which Validator will be linked to DePool in the future by sending votes to Nominator Voting Contract contract. The vote must include validator wallet address. On the other hand, any Validator can create a proposal in Nominator Voting Contract to gather votes from Participants. When elections starts DePool asks Nominator to choose Validator wallet for active staking round.
Validator can validate many DePools with 1 Validator wallet. Reputation of Validator wallet therefore is available and can be analyzed over time.
To ensure that the validator will perform its functions correctly (be always online and not "lie" to other validators), the validator wallet must itself become a Participant and invest in every staking round at least X% of the minimal total round stake minRoundStake, both are initialized in DePool constructor.
When Elector unfreezes validator stakes, DePool returns its stake back with round rewards. Part of these rewards (node_fraction) goes to DePool wallet balance which can be withdrawn by wallet at any time. Another part (pool_fraction) goes to DePool itself to cover gas and storage fees. And the last part (participants_fraction) is distributed among all Participants in staking round. All these fractions are initialized when DePool is deployed.
DePool keeps a balance for each Participant and can automatically reinvest Participant's stake into the last staking round if appropriate flag is enabled.
When a staking round is complete, DePool sends statistics about it to the DePool Association Contract including total round stake, number of participants, round reward, validator reward and so on. The difference between DePool spendings and revenue will be periodically sent to DePool Association Contract.
DePool stores Participant stakes in two parts: unused and invested. Unused part can be returned by Participant at anytime. Invested part is split between staking rounds and cannot be returned until it will be moved to unused part.
Participant can transfer part of its total stake to another Participant's stake inside DePool storage. This function allows for collateralization of the stake to provide liquidity to stake holders.

Описание процесса стейкинга

Итого, DePool — это контракт, который отвечает за проведение всего процесса стейкинга и связывает процесс стейкинга с выборами валидаторов и процессом валидации. Стейкинг контракт ведёт 3 раунда параллельно, но со смещением по времени (специфика работы выборов и валидации).

Из чего состоит раунд:

Ожидание выборов - в этот момент набираются стейки
Выборы валидатора
Валидация нодой-валидатором (в этот момент стейки лежат в ней)
Период заморозки стейков в контракте выборов
Разморозка стейков, раздача вознаграждения и возвращение средств

В каждый раунд контракт набирает стейки, пока не начнутся выборы. Как только начинаются выборы, стейки больше не принимаются в текущий раунд, создается следующий раунд и все последующие стойки уходят в него. Контракт получает от ноды со стейками подписанный запрос с adnl адресом и public key. Весь стейк вместе с запросом уходит на выборы - его отправляет контракт от имени ноды.

Если нода выиграла на выборах, то стейк на ней размораживается в контракте выборов на период валидация + период заморозки. Пока идёт валидация, стартуют следующие выборы и далее всё повторяется.

Когда стейк размораживается в контракте выборов, контракт стейкинга забирает его и делит прибыль, возвращая стейк участникам.

Если включена опция autoresume, то стейки участников вместе с наградой уходят в следующий раунд.

⭐ Стейкинг временно недоступен в Surf.

Стейкинг валидатора

Стейк - ставка/депозит валидатора необходимый для участия в выборах валидаторов и последующей валидации в Proof-of-Stake блокчейне.

Доход валидатора - за работу по валидации валидатор получает вознаграждение по окончании каждого цикла валидации. Доход состоит из 2х частей:

эмиссия новых токенов (фиксированная в сети на уровне ~2% в год);
плата за подписанные блоки (1,7 TON за каждый блок в мастерчейне и по 1 TON за каждый блок в шардчейне).

На текущий момент все валидаторы получают вознаграждение пропорционально своему стейку. То есть если валидатор поставил стейк в размере 1% от суммы всей стейков, то и его вознаграждение составит 1% от общего вознаграждения.

Поскольку размер стейка слишком большой для обычного участника, а количество валидаторов ограничено. То был разработан смарт-контракт DePool (см. ниже) позволяющий делать стейки «вскладчину» любому участнику с небольшой суммой для участия в стейкинге и получения своей части вознаграждения. Смарт-контракт гарантирует то, что валидатор не может использовать средства участников каким-либо другим образом, тем самым участникам гарантируется безопасность их средств от недобросовестности валидатора.

Выборы валидаторов происходят (по текущей конфигурации сети) каждые 18 часов. Каждый период состоит из 3 фаз:

выборы открыты, смарт-контракт выборщика принимает новые стейки, а предыдущие валидаторы могут вернуть свои стейки от смарт-контракта выборщика;
выборы закончены и смарт-контракт определяет группу валидаторов на следующую фазу;
новая группа валидаторов начинает работу. У старой группы валидаторов стейки находятся во временном фризе.

Визуально это выглядит так:

Рис. 4

Источник

Определение группы валидаторов - смарт-контракт выборщика действует по таким правилам:

Из конфигурации сети читаются следующие параметры:

мин и макс число валидаторов;
мин и макс размер стейка;
max_factor максимальная разница между первым (максимальным) и последним (минимальным) стейками валидаторов.

Набирается максимальная/wrap группа валидаторов, начиная с первого и далее по порядку (порядок соответствует уменьшению размера стейка, а если стейки совпадают, то по увеличению времени его подачи), которая имеет разницу между наибольшим и наименьшими стенками не более max_factor.
Для следующего стейка (он может быть от одного или от нескольких валидаторов) рассчитывается сумма всех стейков таким образом, чтобы соблюсти правило max_factor. Для этого максимальный стейк (или стейки) обрезаются до удовлетворения правила max_factor. Если получившаяся сумма всех стейков стала больше, то смарт-контракт выборщика пытается добрать следующие стейки, следуя аналогичной процедуре обрезания стейков по правилу max_factor.
Как только суммарный стейк рассчитанный по такой процедуре перестает расти, то есть находится максимум суммы стейков, то это состояние считается прошедшим выборы - затем все прошедшие выборы валидаторы начнут валидировать на следующий период выборов, а обрезанные части стейков (если они были) сразу возвращаются на кошельки, с которых были отправлены.