🌐 Новости о разработке EOS.IO (Daniel Larimer)

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

BIOS EOSIO

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

один аккаунт (eosio.system)
один приватный ключ
один производитель блоков

Этот исходный аккаунт похож на корневой аккаунт в системах linux и обладает неограниченной силой до тех пор, пока не передаст эту силу смарт-контракту операционной системы более высокого уровня. Из этого начального состояния аккаунт @eosio.system загрузит смарт-контракт операционной системы, имплементирующий следующее:

установление доли для голосования, пропускной способности сети, CPU, ОЗУ и хранилища
создание контракта, который позволяет голосовать за прокси и производителей

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

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

Динамическое число производителей блоков

Главным достижением является то, что блокчейны EOSIO начали поддерживать динамическое число производителей блоков, которое теперь можно менять путем простого обновления смарт-контракта @eosio.system. По умолчанию остается задан 21 производитель, но теперь это значение более не зафиксировано в коде.

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

Измерение

Ранее мы указывали на то, что выполнение каждой транзакции будет занимать не более 1 мс времени, субъективно измеренного производителем блока. Но мы поняли, что существует спрос и на такие транзакции, выполнение которых может занять до 50 мс, равно как и желание стимулировать эффективность своих разработчиков, поощряя создание транзакций, выполнение которых займет менее 50 мкс. В нашей оригинальной модели для всех транзакций использовался один и тот же процессор, независимо от того, была ли скорость 50 мкс или 1 мс, что устраняло стимул для оптимизации ниже 1 мс.

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

Мы поняли, что можем без дополнительных затрат заменить существующий ограничитель скорости, основанный на измерении времени, на ограничитель, вычисляющий объективное количество выполненных инструкций WASM. Это схоже с тем, как Ethereum измеряет потребление газа. С помощью этой новой объективной меры мы можем оценить лимит ЦП таким же образом, каким оцениваем лимит пропускной способности.

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

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

Разделение ЦП и пропускной способности сети

В предыдущих обновлениях мы указывали на то, что будем разделять ОЗУ, хранилище и пропускную способность, где ЦП/сеть рассматривались как часть пропускной способности. Мы поняли, что некоторые приложения, например, Steem, могут обладать высокой пропускной способностью сети (для постов) и низкой пропускной способностью процессора, в то время как другие приложения могут иметь низкую пропускную способность сети (для биржевых ордеров) при более высокой пропускной способности процессора (матчинг ордеров). Это означает, что установление универсальной цены и/или доли не имеет смысла.

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

Сжатие транзакций

В процессе добавления поддержки c++ библиотеки STL мы заметили, что смарт-контракты могут получаться довольно большими (50 КБ), а следовательно, использовать значительную долю пропускной способности сети. Вполне возможно, что еще более сложные контракты могут вырасти до 200 Кб и более. Также мы поняли, что многие приложения, такие как Steem, пакуют хорошо сжимаемый контент в транзакции.

Мы добавили поддержку zlib-сжатия транзакций, что может обеспечить сокращение использования пропускной способности на 60% и более для загрузки смарт-контрактов и имеет потенциал для еще более сильного сжатия контента, подобного размещаемому на Steem.

Обновления сети

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

сжатое содержимое блока – при трансляции блока в него включаются только ID транзакций, без ретрансляции всех транзакций в блоке. Это позволит сократить использование пропускной способности почти на 50%.
поддержка больших сообщений – передача больших сообщений (например, смарт-контрактов весом в 50 Кб) требует иного сетевого протокола, нежели небольшие сообщения (например, транзакции весом в 200 байт)

Заключение

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

Переведено @blockchained

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