Function X: Мартовский Hash Out
В этом выпуске мы подробно обсудим hub и zone, а также предложения, которые поступили от сообщества в социальных сетях по Февральскому Hash Out.
Function X’s Hub и Zone
Давайте подробнее рассмотрим Hub и Zone, о которых мы говорили в Январском Hash Out.
Напомним, что «Hub» рассматривается как родительская цепочка, которую мы обычно называем публичной цепью Function X. Это основа связи между различными блокчейнами, которую называют «Zone».
Zone — это блокчейн, обладающий определенной функциональностью, например, цепочкой «оплата» специально предназначенной для операций в системе XPOS Point-of-Sales (Сеть точек продаж). В этой цепочке «оплата» вы увидите транзакции каждого устройства XPOS от людей, покупающих или тратящих криптовалюту через XPOS.
«Hub» используется для координации и распределения ресурсов, т.е. «management» (управление), а «Zone» используется для операций, т.е. «department» (отдел).
Разные zone могут иметь разные правила консенсуса. Например, zone «логистика» отдается предпочтение безопасности её жизнеспособности, поскольку нет проблемы двойного расходования в хранении данных, в то время как zone “финансы” мы хотим отдать приоритет безопасности над скоростью, поскольку речь идет о деньгах
Кто будет устанавливать правила консенсуса для zone?
Соответствующие заинтересованные стороны в zone, вероятно, люди, которые запускает zone. Например, если вы создали zone с названием «Медицинская Zone» и она используется для выдачи сертификатов или медицинских карт в группе медицинских учреждений, вы, как владелец этой zone, напишите консенсус вместе с другими заинтересованными сторонами. Вы и заинтересованные стороны, вероятно, тоже валидаторы.
Пример 1. Inter-zone связь: использование услуг, предоставляемых другими zone.
Если zone являются «разными отделами» в компании, как zone взаимодействуют друг с другом? Inter-zone связь — это связь, которая происходит между двумя или более zone.
Для примера возьмем услугу zone “хранение”. Мы можем настроить эту zone с децентрализованным хранилищем, работающим на IPFS [*]. Когда другие zone, такие как zone «оплата», хотят хранить данные транзакций XPOS в облаке, мы можем использовать службы IPFS, предлагаемые в zone «хранение».
Во время inter-zone связи нам нужно будет пройти через hub. К этому моменту должно быть ясно, что полные узлы находятся на уровне hub, а сервисные узлы — на уровне zone. Февральcкий Hash Out содержит пояснения о полных и сервисных узлах.
Пример 2. Inter-zone связь: проверка данных между zone
Эта функция также может быть расширена для отправки цифровых активов между zone. Например. Бобби работает в отделе «оплата», как заинтересованное лицо. Алиса находится в отделе «хранение». Теперь Бобби хочет отправить Bitcoin Алисе. Когда Бобби отправляет Bitcoin, он сначала будет проверен zone отдела “оплата“, а затем переместится в Hub и, наконец, в zone отдела” хранение”, где находится Алиса.
Существуют много других вариантов, помимо хранения и отправки криптоактивов, которые обеспечивают координацию между zone. Другие примеры могут включать голосование, текстовые сообщения, голосовые вызовы и т. д. Иногда концепцию inter-zone связи в общих чертах называют межблочной связью (IBC). IBC используется для обозначения идеи связи между цепями, а не набором фиксированных протоколов.
Hash Out февральское обсуждение
В Февральском Hash Out мы обсуждали требования, как стать полноценным узлом, используя либо фиксированное число, скажем, 100 000 токенов FX, либо фиксированный процент для ставки. Некоторые предложили 0.026% от общего предложения.
Преимущество использования процента состоит в том, что оно отражает истинное отношение к предложению, недостатком является то, что валидатору необходимо постоянно обновлять поставленные токены, чтобы претендовать на валидаторство. Например, 0.0026% от общего объема поставок составляет всего 9 843 токена сегодня, но означает больше токенов в будущем. Использования фиксированного числа намного проще для валидаторов и это подтверждается в обсуждении на Reddit Февральского Hash Out.
В Февральском Hash Out Recap мы также обсуждали важность не злонамеренных узлов и почему требуется штраф, если в системе присутствуют злонамеренные узлы. Одна из возможностей повышения стабильности на ранних стадиях сети или «предпусковой стадии» будет приглашение их тестировщиками до того, как программное обеспечение будет выпущено для общественности. Чтобы сделать участие привлекательным, будет действовать система стимулирования [**]
[*] Мы будем больше говорить о IPFS в будущих HashOuts. Ранее об этом упоминалось Function X Concept Paper
[**] Схема будет частично исходить из того, что осталось от раздачи токенов Fx, держателям NPXS/NPXSXEM.
Статью подготовили: Дэнни Лим и Питт Хуанг. Предложения от Dr. Йоса Гинтинга, Дэвида Бен Кея и Индры Винарты.
Created by
PundiXLabs
