Этот пост @steemitblog написан для вас командой блокчейна Steemit.
Последние несколько месяцев мы были весьма заняты и теперь хотели бы поделиться с вами некоторыми из вещей, над которыми мы работали. Данный пост содержит новости о наших планах по усовершенствованию формулы распределения пропускной способности, обновлению AppBase, RocksDB и хардфорку 20 (ХФ20), а также о новейших разработках по внедрению Smart Media Tokens (SMT).

Масштабируемость

Как многие из вас уже знают из нашего предыдущего поста о масштабируемости, весь последний год команда была преимущественно сосредоточена на повышении масштабируемости. Мы знаем, что подобные изменения не столь увлекательны, как новые функции и усовершенствования платформы, но обеспечение готовности блокчейна масштабироваться до 100x или даже 1000x текущего уровня использования – именно то, что важно сделать, прежде чем мы на самом деле масштабируемся до такой степени. Пренебрегать масштабируемостью до тех пора, пока она не окажется срочно нужна – путь к катастрофе.

AppBase

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

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

Пре-релиз AppBase был анонсирован около трех месяцев назад, и мы ценим все тщательные тесты, проведенные сообществом за это время. Мы также занимались интенсивным тестированием и работали над решением нескольких незначительных проблем, которые были обнаружены в процессе. Мы очень близки к тому, чтобы заверители и операторы узлов начали безопасное использование официального релиза AppBase 19.4 впродакшене

RocksDB

Как мы уже упоминали в нашем посте о масштабируемости Steem, мы проводим много времени, исследуя различные способы более эффективного хранения данных steemd. Одним из таких способов является использование технологии RocksDB. В итоге мы решили остановиться именно на решении с RocksDB и уже успешно перевели плагин “account history” на использование RocksDB.

RocksDB – это быстрое хранилище данных на диске с улучшенным уровнем кеширования, что дополнительно минимизирует задержку при чтении с диска/записи на диск, поскольку оно оптимизировано для быстрого хранения с низкой задержкой. Используемый в производственных системах нескольких организаций сетевого масштаба (Facebook, Yahoo, LinkedIn), RocksDB построен на базе LevelDB, однако обладает повышенной производительностью благодаря своей способности использовать несколько ядер процессора и хранилища SSD для рабочих нагрузок ввода/вывода. Например, его использование в MyRocks позволило уменьшить использование SSD-хранилища, а также увеличить время работы SSD и доступную емкость ввода-вывода для обработки запросов.

В сравнении с предыдущей версией account history:

• Теперь можно запускать ноду account history, сохраняя файл состояния на SSD-накопителе nVME, вместо того, чтобы хранить весь файл состояния в RAM. Это позволило нам запускать ноды account history на серверах с 32-64 ГБ RAM вместо 488 ГБ, которые нам приходилось использовать раньше.
• Нода account history теперь может повторно индексироваться примерно за 10 часов по сравнению с несколькими днями, которые требовались раньше.
• Файл состояния теперь намного меньше, так как RocksDB обладает встроенной функцией сжатия.

Мы завершили обширное тестирование этих изменений в среде разработки/подготовки и уже ввели эти изменения в продакшн. Любые пользователи, которые в последнее время запрашивали данные истории аккаунта из конечной точки api.steemit.com, получали данные из плагина RocksDB.

Плагин account history использовался в качестве теста технологии RocksDB, чтобы определить, соответствует ли она нашим потребностям. Мы более чем довольны результатами этого теста и работаем над заменой Chainbase, которая полагается на RocksDB вместо memory mapped файлов. Это значительно улучшит качество работы steemd, и мы рады наконец совершить переход.

Пропускная способность

По мере того, как мы продолжаем масштабировать блокчейн под всё большее число пользователей, формула пропускной способности, которую мы используем для распределения ресурсов среди всех этих пользователей, становится все более важна. Формулы пропускной способности, используемой нами сейчас, было достаточно для уровня активности, который был у нас до сих пор, но ее можно значительно улучшить. Наша цель – попытаться найти баланс между тем, чтобы предоставить новым пользователям качественный опыт в приложениях на базе Steem, но в то же время не позволять им расходовать необоснованное количество ресурсов сети или рассылать спам. Мы также хотели бы упростить ментальную модель понимания того, сколько Steem Power требуется для определенных уровней использования.

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

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

• Размеру истории блокчейна
• Времени переиндексации
• Размеру файла состояния
• Использованию памяти
• Iops диска
• Пропускной способности сети

В настоящее время мы работаем над внедрением нового инструмента под названием StatsD, добавляющего статистику в steemd, дабы получить более качественные показатели. Мы также изучаем различные версии реализации пропускной способности, которые можно использовать для распределения использования на основе этих показателей.

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

Другие изменения

Изменения в системе безопасности

Чтобы повысить стабильность сети, команда разработала несколько патчей для системы безопасности, которые были выпущены в Steem 0.19.3. Большинство заверителей и операторов нод уже приняли эти изменения и запустили их в продакшн.

Тестирование cli_wallet

Cli_wallet – это инструмент для взаимодействия с блокчейном Steem, который используется многими заверителями, биржами и разработчиками приложений. Поскольку мы продолжаем вносить изменения в архитектуру блокчейна (например, с AppBase и RocksDB), мы сочли важным разработать набор тестов, который можно было бы использовать для проверки обратной совместимости новой версии кода со старой версией и не мешал бы работе никаких функций cli_wallet.

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

Руководства по стилю кода

В ишью 2366 на нашем GitHub мы работаем над документом о стиле кода, чтобы разработчики руководствовались стандартными решениями, а у кодовой базы был единый набор правил стиля. Они будут полезны для любого разработчика, вносящего лепту в steemd, и помогут сохранить исходный код чистым и рабочим.

API подтверждения транзакций

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

Мы работаем над новым API, способным лучше определять статус транзакции. Он не только более эффективен, чем текущий процесс подачи транзакций, но и позволяет steemit.com обнаруживать подобные сценарии и обеспечивать попадание ваших действий в блокчейн.

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

Хардфорк 20

Хардфорк 20 на некоторое время отошел на задний план, поскольку мы были сосредоточены на решениях, связанных с масштабируемостью, но пришло время снова сделать его приоритетным. Пока у нас нет точной даты его проведения, но мы нацелены на начало третьего квартала 2018 года. Более подробная информация о ХФ20 будет представлена по мере продвижения разработки.

SMT

У нас есть несколько разработчиков, занимающихся исключительно SMT, и мы добились заметного прогресса. Хотя многие из изменений, над которыми велась работа, являются сугубо техническими и в основном служат для обновления большей части существующих функциональных возможностей steemd (который был разработан для одного токена: STEEM) для работы с несколькими токенами, уже начинают вырисовываться очертания нового интересного функционала.

Вот 10 интересных изменений, которые уже готовы:

• В 1508 была проведена первоначальная работа, которая обеспечивает возможность создавать новые SMT.
• В 1653 и 1729 были созданы тестовые примеры, гарантирующие, что вся логика создания SMT работает должным образом.
• В [1683] был создана основа для интеграции SMT с внутренним рынком, чтобы пользователи могли торговать SMT за STEEM и STEEM за SMT.
• В 2029 была задана структура, которая будет использоваться для работы SMT маркет-мейкеров на внутреннем рынке.
• В 1682 была добавлена поддержка SMT в операцию трансфера, которая используется для передачи токенов между аккаунтами.
• В 1843 были обновлены посты/комментарии, чтобы пользователи могли указывать до двух токенов SMT (помимо STEEM), на которые претендует пост/комментарий.
• В 1856 был обновлен оператор голосования: добавлена поддержка операций голосования по постам/комментариям, которые включают несколько активов для голосования (SMT).
• В 1896 была создана операция востребования пользователями токенов за пост/комментарий, для которого включены выплаты в SMT.
• В 2056 была добавлена поддержка smt_refund_operation, которую могут использовать участники ICO, чтобы (при желании) отменить свой вклад в ICO и получить возмещение, если запуск ICO был отложен.
• В 2021, 2160 и 2085 была добавлена поддержка вестинга SMT (SMT Power).

Больше технических деталей

Для тех из вас, кто интересуется техническими деталями: сейчас команда тратит много времени на важные структурные решения в дополнение к коду. Многие из их обсуждений можно найти в GitHub.
С одним из примеров можно ознакомиться в этом ишью, где мы обсуждаем, как обрабатывать автоматические действия, такие как эмиссия SMT и транзакции маркет-мейкера. В другом, 2212, мы обсудили крайние случаи вестинга SMT для предотвращения переполнения целочисленной переменной и ошибок округления.

Тестнет

Мы знаем, что все очень ждут запуска SMT в продакшн. Мы тоже! Наша команда работает изо всех сил, чтобы сделать это реальностью. Первой важной вехой, к которой мы стремимся, является запуск тестовой сети SMT (под названием “Forerunner”), где разработчики смогут начать играть с некоторыми из реализованных функций.

Мы будем продолжать рассказывать о нашем прогрессе и непременно сообщим вам, как только тестнет Forerunner будет готов к использованию.

Steem on,

• Команда Steemit

---

Оригинал поста: ЗДЕСЬ

---

Если вам нравится то, что мы делаем - поддержите witness blockchained в сети Steem

---

Телеграм чат: https://t.me/steemit

---

Вы можете торговать токенами STEEM/SBD на RuDEX с 0% торговой комиссией