сети.
Это экспериментальный релиз. В тестовой сети новый функционал будет активирован на блоке 483000 (30.11.15), в боевой сети - на блоке 621000 (примерно 21.01.16).
Всем тестовым нодам необходимо обновиться. Кто этого не сделает - останется в форке.
Боевым нодам нужно будет обновиться на стабильную версию 1.7, которая ожидается в конце декаюря, но в любом случае им необходимо обновиться до хардфорка на блоке 621000.
Новый функционал:
Миксер монет. Функционал основан на работе Tim Ruffing,
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf .
Миксовать можно следующие активы: NXT, MS-валюту (если она не создана с признаком "немиксуемая"), AE-ассеты. Любой аккаунт может инициировать новый микс, указав актив, сумму, требуемое количество участников, финальный блок для регистрации участников (API-функция shufflingCreate). Последующие миксинг-шаги можно осуществлять вручную (
API shufflingRegister,
shufflingProcess,
shufflingVerify/
shufflingCancel), либо, что более удобно, посредством автоматизированного Миксера - API-функции
startShuffler. После запуска Миксер отслеживает в блокчейне транзакции, относящиеся к инициированному миксу, и автоматически посылает требуемые транзакции от имени пользователя, выполняя микс, проверку или отмену по мере необходимости. Для этого Миксер должен держать пароль пользователя в памяти, т.е. он должен выполняться только на проверенном локальном компьютере. Перезагрузка сервера требует повторного запуска Миксера, т.к. он никогда не должен сохранять пароль на диск.
Чтобу участвовать в миксе, необходимо внести депозит в 1000 NXT вдобавок к сумме валюты или ассета; если миксуются монеты NXT, то миксируемая сумма должна превышать 1000 NXT. Если микс состоялся, то эта величина добавляется к аккаунту-получателю, чтобы у того для последующих транзакции были NXT для покрытия комиссии сети (поскольку аккаунтами-получателями могут быть только абсолютно новые аккаунты). Если микс не удаётся из-за того, что зарегистрировавшийся не выполняет требуемые шаги, или посылает ложные данные, то участник, отменяющий микс наказывается удержанием этого депозита (в пользу форжера финишного миксо-блока). Если микс отменяется из-за недостатка участников, никто не наказывается, и все депозиты возвращаются.
Для получения информации о текущих миксах и их участниках используются следующие API-функции:
getAllShufflings,
getAccountShufflings,
getAssignedShufflings,
getHoldingShufflings,
getShufflers,
getShuffling, и
getShufflingParticipants.
При желании, нода может удалить из своей базы данных закончившиеся миксы, выставив параметр
nxt.deleteFinishedShufflings=true (по умолчанию -
false).
Комиссия за создание микса, или подключение к нему составляет 1 NXT, за транзакцию миксования либо отмены - 10 NXT, и за транзакцию проверки - 1 NXT.
Управление аккаунтами (Account control) для
фазированных транзакций.
Любой аккаунт можно ограничить в выпуске фазированных транзакций только определённой модели голосования. Для этого аккаунт при помощи API-функции
setPhasingOnlyControl посылает транзакцию
setPhasingOnly. Чтобы узнать статус аккаунта на предмет его фазо-ограничений, используется функция
getPhasingOnlyControl, а также функция
getAllPhasingOnlyControls для получения списка всех аккаунтов с определённым фазо-ограничением.
Аккаунт можете переустановить своё фазо-ограничение новой
setPhasingOnly-транзакцией, то есть с новыми фазо-ограничениями. Для снятия ограничений используется фиктивная модель голосования "в никуда".
Обратите внимание, что типы голосования "по транзакции" и "по хэшу" не подлежат фазовым ограничениям.
Во избежание "смертельных объятий" собственно подтверждение транзакций (PhasingVoteCasting) не подлежит ограничению Управлением аккаунтами.
При установке Управления аккаунтом можно указать максимальную комиссию,
ограничивающую общую комиссию для ожидающих фазирования транзакций управляемого аккаунта,
и лимиты могут быть наложены на минимальное и максимальное время фазирования.
Транзакции аккаунтов с лимитами на максимальную комиссию ограничиваются одной такой транзакцией на блок.
Немедленное (по одобрении) исполнение фазированных транзакций
Фазированные транзакции с моделью голосования, не зависящей от баланса аккаунта (такой как "по транзакции" и "по хэшу"), либо с моделью "по аккаунту" с указанием "белого списка" и без требования минимального баланса, исполняются (если возможно) сразу после одобрения, т.е. до финального блока (в том блоке, в котором исполняется транзакция одобрения). Такое досрочное исполнение гарантируется для типов транзакций, известных как "фазово-безопасные". Для других типов, в случае если досрочное одобрение не состоялось из-за конфликта с другой транзакцией, предпринимается ещё одна (последняя) попытка на фазо-финальном блоке.
Новый алгоритм пересчёта сложности
Среднее время между блоками будет 60 сек., 1440 блоков в день. Время между блоками даже в худших случаях практически никогда не превзойдёт 10 мин.
Для форжингового баланса будет установлен лимит в 1000 NXT. Это относится к собственному гарантированному балансу плюс к полученным в лизинг балансам. Аккаунт с балансом менее 1000 NXT по-прежнему может сдавать свою форжащую мощность в лизинг.
Свойства аккаунтов
- это пары "наименование" / "значение", которые могут быть установлены на любом аккаунте (кроме Генезисного) либо владельцем аккаунта, либо другим аккаунтом. "Наименования" ограничены 32-мя символами, а "значения" - 160-ю. "Наименования" уникальны в пределах аккаунта и устанавливающего аккаунта, но не глобально. Свойства аккаунтов не могут перемещаться между аккаунтами. Установивший свойство аккаунт может заменить "значение" на другое. Аккаунт (либо установивший свойство аккаунт) может удалить свойство. Нет ограничения на количество свойств, которые может иметь аккаунт. Комиссия за установку "значения" составляет 1 NXT при длине "значения" до 32 символов, плюс по 1 NXT за каждые дополнительные 32 символа.
Свойства аккаунтов управляются вызовами
setAccountProperty and
deleteAccountProperty. Для запроса свойств аккаунта, или установленных аккаунтом, используется вызов
getAccountProperties.
Единичный ассет
Выпуск ассета в единичном количестве
(с разрядностью 0) и с описанием не более 32 символов потребует комиссии в 1 NXT only (вместо обычных 1000 NXT). Если описание превышает 32 символа, взимается комиссия в 1NXT за каждые дополнительные 32 символа. Имя единичного лимитировано 10-ю символами, так же, как у обычного ассета.
Ограничение транзакций создания уникальных ресурсов
Выпуск ассета (кроме единичного), MS-валюты, и назначение алиаса (кроме переназначения) ограничиваются по одной транзакции каждого указанного типа на один сфорженный блок.
Перераспределение комиссий за выпуск ассета и MS-валюты
Комиссия за выпуск ассета (кроме единичного) и MS-валюты будет распределяться между форжерами текущего и трёх предыдущих блоков в пропорции 4:3:2:1.
В одной транзакции допускаются одновременно удаляемые обычные и удаляемые шифрованные вложения. Максимальный размер каждого такого вложения - 42кБ, но если в транзакции присутствуют одновременно оба вложения, то общих их размер не может превышать этот предел (44880 байта).
Те ноды, которые предоставляют публичный доступ к API (по http или https, при помощи параметров
nxt.apiServerHost=0.0.0.0 и
nxt.allowedBotHosts=*) теперь помечаются как предоставляющие
Услуги нод API or API_SSL. Ноды, предоставляющие услуги могут быть выявлены запросом
getPeers с параметром "service". Этот API-запрос был доработан, и теперь принимает параметр "service" с несколькими значениями, возвращая перечень нод, поддерживающих все запрошенные Услуги. Те порты, на которых открыт API интерфейс, включается в информацию о нодах в ответных полях
apiPort и
apiSSLPort.
Изменения, несовместимые с предыдущими версиями:
Удаление части эмитированного количества ассета будет производиться отдельным типом транзакции
AssetDelete вместо перемещения количества в Генезис (которое больше поддерживаться не будет). Для получения информации об удалённых ассетах добавлен API-вызов
getAssetDeletes; и вызов
getAssetTransfers более не применяется для целей выявления перемещённых в Генезис ассетов.
Также появился новый вызов
getExpectedAssetDeletes для получения запланированных к удалению в очередном блоке аасетов, по аналогии с вызовом
getExpectedAssetTransfers.
...
