Часть про "простые и понятные инструменты" вы пропустили? Фьючерсные контракты на покупку физического товара, да ещё и "проксированные" через Мосбиржу, на мой взгляд, к таким явно не относятся.
Слово "никаких" относилось и к плечам, и к шортам. Т.е. да, большинству инвесторов следует торговать только в лонг, ибо возможный убыток по шортам в теории ничем не ограничен.
Мораль истории: если биржевая торговля не ваша полноценная работа и вы не хотите иметь неиллюзорную вероятность в один момент оказаться без трусов, то торгуйте только на свои (т.к. никаких плечей и в идеале шорт) простыми и понятными инструментами. Если вы встречаетесь с "надёжными стратегиями" постоянно дающими прибыль, даже если предположить, что это не тупое завлечение хомяков и там написана правда, то всегда держите в голове что с высокой вероятностью это страховка от маловероятных событий (англ. tail risk), т.е. по сути торгующие с другой стороны от этой стратегии платят небольшую комиссию вам дабы избежать больших потерь при редких событиях. Т.е. большую часть времени вы будете получаеть стабильную прибыль, но время от времени будете оставаться с громадным минусом.
А не рассматривалось добавление второго слоя штор с металлическим напылением дабы увеличить эффективность досвечивания и уменьшить световое загрязнение окружающей местности? Плюс по идее они должны быть более эффективными в деле сохранения тепла.
Основная проблема связана с учетом затрат на топливо.
Вклад топлива (включая полный цикл переработки и утилизации) в конечную стоимость э/э для АЭС относительно мал, на старых реакторах это 30-40%, на новых 15-20%. (источник) Гораздо большее влияние оказывает стоимость кредитов из-за больших капитальных затрат на постройку.
улавливание такого количества энергии требует его отдачи
Эта проблема элементарно рассчитывается студентом-физиком за полчаса-час. А Дайсон далеко не студентом был, хочу заметить. Отсюда и вытекает радиус в 2 а.е. и спектр излучения с инфракрасным пиком гипотетической звезды окружённой сферой.
Кучу разнообразных солей и прочей дряни типа серы, свинца, мышьяка, метана и водорода от газовых гигантов вы не сможете использовать
Упускаете один очевидный момент: раз уж цивилизация добралась до сооружения подобных конструкций, то уж контролируемо преобразовывать одни атомы в другие она вероятно научилась, пусть даже и с невысокой энергетической эффективностью. Благо энергии после начальных этапов должно быть более чем достаточно. Не говоря уже о преобразовании водорода и гелия с газовых гигантов, этот процесс вообще будет энергетически положительным.
сомнется внутрь приливными волнами от прохождения ближайших планет
К моменту создания хотя бы цельного кольца ближайшие планеты уже будут разобраны под нуль скорее всего.
Ещё раз: у существующих в железе малых реакторов экономика (в расчёте на общее время жизни) получается значительно хуже чем у больших реакторов. Росатом с удовольствием строил бы малые реакторы, будь это не так. Это не только уменьшило бы CAPEX (а значит и объём выплат на погашение кредита), но и позволило бы значительно упростить маневрирование мощностями.
безаварийные атомные реакторы на атомных ледоходах используются десятилетиями
Даже если забыть про экономику, вы вообще в курсе, что на таких реакторах используется высоко-обогащённый уран оружейного уровня?
этот проект был выбран несмотря на отсутствие какой-либо статистики по таким реакторам
ВВЭР-1200 это эволюционное развитие хорошо зарекомендовавшей себя ветки, поэтому их значительно проще сертифицировать, в отличии от менее классических реакторов, предлагаемых вами.
Касательно же 4-го поколения, на мой взгляд, им скорее всего станут либо высокотемпературные газоохлаждаемые, либо же быстрые реакторы с металлическим теплоносителем (т.е. развитие БРЕСТа/БН), а никак не хайповые малые реакторы. Интересны ещё реакторы со сверхкритической водой. Можете обратить внимание, что у них есть общая тема: повышение температуры для достижения более высокого КПД преобразования тепла в электроэнергию плюс возможность размножения топлива (или близко к тому), т.е. улучшение экономики реактора.
А про то что и Чернобыль и Фукусима это реакторы дизайна 60-х годов вы не забываете? С тех пор реакторы уже на полтора поколения вперёд продвинулись. Тот же ВВЭР-1200, даже с Фукусимским уровнем раздолбайства не привёл бы к заражению окружающей местности.
Малыми реакторами Росатом вполне себе интересуется, см. ПАТЭС и ледокольные реакторы. С "малыми полностью автоматические необслуживаемые реакторами" есть как-минимум две проблемы: во-первых, для них всё-равно нужна будет серьёзная охрана, во-вторых, все они на данный момент бумажные (т.е. не понятна реальная экономика, не зря существующие реакторы стараются делать большой мощности, так просто напросто получается выгоднее).
Сторонники Билла Гейтса с упованием рассказывали о преимуществах реакторов на бегущей волне, но как только начались хоть какие-то разработки, проект резко "поскучнел". Ещё есть стартапы обещающие революцию с жидкосолевыми реакторами, но почему-то в промо-материалах забывают упомянуть какой кошмар они представляют для материаловедов, ибо для них необходимо обеспечить коррозионную стойкость в присутствии половины таблицы Менделеева, да ещё и при серьёзном радиационном потоке. И это уже не говоря уже о сложностях с онлайн переработкой топлива. Даже в сравнительно более простом БРЕСТе с этими проблемами инженеры мучаются не первое десятилетие.
Предполагается, что изотопы с большим числом нейтронов (которые пока не были получены) будут более стабильными. Теоретические оценки максимального времени жизни в острове стабильности колеблются от минут/суток до веков и более.
Есть ещё одно чрезвычайно интересное предсказание касательно значительно более тяжёлых атомов (более 300 а.е.м.), т.н. "континент стабильности". Вместо отдельных нейтронов и протонов ядра подобных атомов будут состоять из "кваркового супа", не будут произвольно распадаться и могут быть отличными поглотителями нейтронов.
"Пересвет" и аналоги будут такую мелочёвку на раз пережёвывать. Плюс сделать полностью автономный дрон летающий только на визуально-инерциальной информации (что требуется для устойчивости к средствам РЭБ), умеющий надёжно распознавать цели и стоящий достаточно дёшево это весьма нетривиальная задача, насколько я знаю, до конца до сих пор нерешённая. Военные по множеству причин отдают предпочтение удалённому управлению человеком-оператором.
Для того что бы заявить базовую поддержку Раста будет достаточно показать что на вашем чипе запускается Hello World написанный на нём, что думаю проще чем работа по интеграции в среды разработки. Если сделаете HAL под ваш чип, будет вообще идеально. Для маркетинга вашего чипа это будет только плюс. :)
Нет, это открытая архитектура, вы можете свободно брать её спецификацию и использовать её по своему усмотрению (например, создавать производные), но это не даёт вам право свободно использовать бренд RISC-V. По аналогии, если вы возьмёте исходники компилятора опенсурсного языка (Rust, D, Go, etc.) и поменяете их, вы не вправе называть получившийся продукт компилятором исходного языка не получив на то разрешения, что достаточно логично.
Разработчик ядра (CloudBEAR) является членом RISC-V International, поэтому ядра разработанные ими имеют полное право называться RISC-V. Насколько я понимаю, компании использующей подобные ядра для создания микроконтроллеров становиться членом совершенно не обязательно. Плюс членство для коммерческих организаций стоит далеко не миллионы (в зависимости от размера компании от $5к до $35k, см. слайд 22), а для институтов, non-profit-ов и частных лиц так и вообще бесплатно.
Рад видеть подобные статьи! Не рассматривали возможность поддержки Rust-а для дополнительного слоя безопасности? Вроде встроенная поддержка RISC-V там на неплохом уровне.
Я видел и более быстрые аппаратно ускоренные Кузнечики, чем AES-ы.
Вопрос в распространённости на пользовательском железе (мы же о потребительском TLS говорим, а не о спец. применениях). С практической точки зрения Кузнейчик это достаточно медленный алгоритм и сверх этого уполовинивать его производительность ради теоретических улучшений безопасности, на мой взгляд, нецелесообразно.
но это касается и AES-а того же в той же степени
Нет, не касается, т.к. для него есть хорошо известные bit sliced реализации. Уже много лет никто, хоть немного разбирающийся в теме, не реализует AES для применения в продакшене через таблицы подстановок. Для Кузнейчика тоже можно реализовать bit sliced реализацию, но, насколько мне известно, никто этого не делал.
говорят про 127/63 векторы инициализации
Другие алгоритмы вполне обходятся nonce кратным 8 битам, и только MGM уникален.
И мне очень нравится что у нас безопасность ставят выше остального.
Везде есть баланс. Вы же не поддержите увеличение количества раундов блочного шифра в 2-3 раза для улучшения "безопасности"? Накручивать теоретическую безопасность в ущерб производительности очень плохо влияет на возможности распространения алгоритма и размер области возможных применений (например, я бы не стал применять Кузнейчик, и тем более режим вроде MGM, для шифрования дисков и данных в оперативной памяти).
И насчёт, "выше всего остального". Давайте просто вспомним про то, что разработчики уже который год не могут внятно объяснить происхождения S-боксов и про теоретический взлом Стрибога урезающий безопасность 512-битного варианта почти в два раза.
не такое уж оно всё и медленное в софте
Для пользователя ещё куда не шло, но вот на сервере MGM с Кузнейчиком без аппаратного шифрования, будет кушать ресурсов весьма заметно по сравнению с аналогами (иначе говоря, сервис с поддержкой ГОСТового TLS будет стоить дороже, тем самым отрицательно влияя на его конкурентоспособность).
Распараллеливание (в т.ч. instruction-level parallelism) в данном случае ни на что не влияет. И GCM, и MGM оба поддерживают параллельную обработку блоков, поэтому MGM неизбежно будет как минимум в два раза медленнее GCM. Иначе говоря, с GCM вы условно будете шифровать за раз два блока, а с MGM вы будете за раз шифровать один блок и аутентифицировать его.
Где я такое утверждал? Вопрос в том, что соразмерно ли подобное падение производительности заявленным улучшениям в безопасности. Если уж и платить за двойное шифрование, я лучше выберу, при наличии возможности, вариант SIV режима, который даст misuse resistance, свойство гораздо более ценное на практике, чем, насколько я понимаю, в большей степени теоретическое усовершенствование заявленное в статье MGM.
Не ясно что не так с производительность Кузнечика (реализаций его куча, варианты оптимизаций (предрасчёт таблиц) тоже есть)
По сравнению с хардварно ускоренным AES (да, сравнение не честное, но оно нынче практически в каждом утюге) и с ARX шифрами всё достаточно грустно. Не говоря уже о том, что использование таблиц, да ещё и таких крупных как в подходе с предрасчётом, сразу ставит нас под прицел тайминг атак (а bit sliced реализаций ГОСТовых шифров я в открытой литературе найти не смог). Плюс bit sliced реализация AES адаптированная под SIMD инструкции, так же значительно превосходит по производительности Кузнейчик, даже использующий предрасчитанные таблицы.
Я думаю в любую реализацию MGM передаётся 128-бит nonce, просто верхний бит обнуляется и MGM явно показывает потерю энтропии в этот 1-бит
С таким подходом вы можете получить по сути nonce reuse, т.к. внешне передавая разные nonce вы будете использовать одно и то же значения счётчика сначала для шифрования, а потом для аутентификации. Причём эту ошибку вполне вероятно допустить на практике, например, используя для nonce счётчик с Little Endian порядком байт. Не утверждаю, что подобная ошибка может привести к взлому режима на практике, но хорошего в этом в любом случае мало. Хорошая реализация, на мой взгляд, должна выдавать ошибку если 128-й бит не равен нулю.
Найдите мне ещё один AEAD режим который бы использовал nonce с длиной не кратной восьми битам. Даже авторы MGM когда я обратил внимание на эту особенность в переписке с ними, привели примеры аналогичных подходов, но которые, сюрприз, использовали nonce таки кратное 8 битам.
в режиме MGM (я бы сказал, улучшенной версией GCM)
Ага, эта версия настолько "улучшена" что требует двойного применения блочного шифра (в случае Кузнейчика ещё и не блещущего производительностью) вместо одинарного в GCM (строго говоря, 2*n+m+4 против n+m+1, где n и m — кол-во блоков в шифруемом сообщении и в аутентифицируемых данных соответственно). Не говоря уже о "гениальном" решении использовать длину nonce равную 127-битам (63 бита для Магмы).
Проблема с использованием стоимости в том, что можно взять иностранную штуковину стоящую 1 рубль и продать её государству за 100 рублей, положив 90 рублей в "карман" (зарезервировав долю для нужных лиц и всякие "сертификации") и отдав 9 работникам. И вроде бы получили 99% локализации и в отечественные рабочие места сколько-то ушло, но схема очевидно гнилая.
Да, локализацию процесса создания добавленной стоимости необходимо поощрять, но нормальная схема должна балансировать процент локализации и итоговую цену по сравнению с аналогичными зарубежными продуктами.
В случае когда известно распределение чисел и мы храним данные в байтах, наиболее эффективной кодировкой будет следующий подход:
Создаём биективное отображение, которое отображает самое частое число в 0, следующее по частоте в 1, и т.д. (можно отображать не отдельные числа, а диапазоны, например, 128 наиболее частых чисел получают индексы 0-127, и т.д.)
Кодируем полученные индексы используя вариант VLQ использующийся в git-е.
Это если мы заботимся только о плотности хранения. Если же нам важна ещё скорость упаковки/распаковки, то тут уже начинается поиск компромиссов. Например, Group Varint Encoding (вариант VLQ) менее плотен по сравнению с git VLQ, но за счёт меньшего количества ветвлений он быстрее на современных процессорах.
Часть про "простые и понятные инструменты" вы пропустили? Фьючерсные контракты на покупку физического товара, да ещё и "проксированные" через Мосбиржу, на мой взгляд, к таким явно не относятся.
Слово "никаких" относилось и к плечам, и к шортам. Т.е. да, большинству инвесторов следует торговать только в лонг, ибо возможный убыток по шортам в теории ничем не ограничен.
Мораль истории: если биржевая торговля не ваша полноценная работа и вы не хотите иметь неиллюзорную вероятность в один момент оказаться без трусов, то торгуйте только на свои (т.к. никаких плечей и в идеале шорт) простыми и понятными инструментами. Если вы встречаетесь с "надёжными стратегиями" постоянно дающими прибыль, даже если предположить, что это не тупое завлечение хомяков и там написана правда, то всегда держите в голове что с высокой вероятностью это страховка от маловероятных событий (англ. tail risk), т.е. по сути торгующие с другой стороны от этой стратегии платят небольшую комиссию вам дабы избежать больших потерь при редких событиях. Т.е. большую часть времени вы будете получаеть стабильную прибыль, но время от времени будете оставаться с громадным минусом.
А не рассматривалось добавление второго слоя штор с металлическим напылением дабы увеличить эффективность досвечивания и уменьшить световое загрязнение окружающей местности? Плюс по идее они должны быть более эффективными в деле сохранения тепла.
Вклад топлива (включая полный цикл переработки и утилизации) в конечную стоимость э/э для АЭС относительно мал, на старых реакторах это 30-40%, на новых 15-20%. (источник) Гораздо большее влияние оказывает стоимость кредитов из-за больших капитальных затрат на постройку.
Эта проблема элементарно рассчитывается студентом-физиком за полчаса-час. А Дайсон далеко не студентом был, хочу заметить. Отсюда и вытекает радиус в 2 а.е. и спектр излучения с инфракрасным пиком гипотетической звезды окружённой сферой.
Упускаете один очевидный момент: раз уж цивилизация добралась до сооружения подобных конструкций, то уж контролируемо преобразовывать одни атомы в другие она вероятно научилась, пусть даже и с невысокой энергетической эффективностью. Благо энергии после начальных этапов должно быть более чем достаточно. Не говоря уже о преобразовании водорода и гелия с газовых гигантов, этот процесс вообще будет энергетически положительным.
К моменту создания хотя бы цельного кольца ближайшие планеты уже будут разобраны под нуль скорее всего.
Ещё раз: у существующих в железе малых реакторов экономика (в расчёте на общее время жизни) получается значительно хуже чем у больших реакторов. Росатом с удовольствием строил бы малые реакторы, будь это не так. Это не только уменьшило бы CAPEX (а значит и объём выплат на погашение кредита), но и позволило бы значительно упростить маневрирование мощностями.
Даже если забыть про экономику, вы вообще в курсе, что на таких реакторах используется высоко-обогащённый уран оружейного уровня?
ВВЭР-1200 это эволюционное развитие хорошо зарекомендовавшей себя ветки, поэтому их значительно проще сертифицировать, в отличии от менее классических реакторов, предлагаемых вами.
Касательно же 4-го поколения, на мой взгляд, им скорее всего станут либо высокотемпературные газоохлаждаемые, либо же быстрые реакторы с металлическим теплоносителем (т.е. развитие БРЕСТа/БН), а никак не хайповые малые реакторы. Интересны ещё реакторы со сверхкритической водой. Можете обратить внимание, что у них есть общая тема: повышение температуры для достижения более высокого КПД преобразования тепла в электроэнергию плюс возможность размножения топлива (или близко к тому), т.е. улучшение экономики реактора.
А про то что и Чернобыль и Фукусима это реакторы дизайна 60-х годов вы не забываете? С тех пор реакторы уже на полтора поколения вперёд продвинулись. Тот же ВВЭР-1200, даже с Фукусимским уровнем раздолбайства не привёл бы к заражению окружающей местности.
Малыми реакторами Росатом вполне себе интересуется, см. ПАТЭС и ледокольные реакторы. С "малыми полностью автоматические необслуживаемые реакторами" есть как-минимум две проблемы: во-первых, для них всё-равно нужна будет серьёзная охрана, во-вторых, все они на данный момент бумажные (т.е. не понятна реальная экономика, не зря существующие реакторы стараются делать большой мощности, так просто напросто получается выгоднее).
Сторонники Билла Гейтса с упованием рассказывали о преимуществах реакторов на бегущей волне, но как только начались хоть какие-то разработки, проект резко "поскучнел". Ещё есть стартапы обещающие революцию с жидкосолевыми реакторами, но почему-то в промо-материалах забывают упомянуть какой кошмар они представляют для материаловедов, ибо для них необходимо обеспечить коррозионную стойкость в присутствии половины таблицы Менделеева, да ещё и при серьёзном радиационном потоке. И это уже не говоря уже о сложностях с онлайн переработкой топлива. Даже в сравнительно более простом БРЕСТе с этими проблемами инженеры мучаются не первое десятилетие.
Предполагается, что изотопы с большим числом нейтронов (которые пока не были получены) будут более стабильными. Теоретические оценки максимального времени жизни в острове стабильности колеблются от минут/суток до веков и более.
Есть ещё одно чрезвычайно интересное предсказание касательно значительно более тяжёлых атомов (более 300 а.е.м.), т.н. "континент стабильности". Вместо отдельных нейтронов и протонов ядра подобных атомов будут состоять из "кваркового супа", не будут произвольно распадаться и могут быть отличными поглотителями нейтронов.
"Пересвет" и аналоги будут такую мелочёвку на раз пережёвывать. Плюс сделать полностью автономный дрон летающий только на визуально-инерциальной информации (что требуется для устойчивости к средствам РЭБ), умеющий надёжно распознавать цели и стоящий достаточно дёшево это весьма нетривиальная задача, насколько я знаю, до конца до сих пор нерешённая. Военные по множеству причин отдают предпочтение удалённому управлению человеком-оператором.
Для того что бы заявить базовую поддержку Раста будет достаточно показать что на вашем чипе запускается Hello World написанный на нём, что думаю проще чем работа по интеграции в среды разработки. Если сделаете HAL под ваш чип, будет вообще идеально. Для маркетинга вашего чипа это будет только плюс. :)
Нет, это открытая архитектура, вы можете свободно брать её спецификацию и использовать её по своему усмотрению (например, создавать производные), но это не даёт вам право свободно использовать бренд RISC-V. По аналогии, если вы возьмёте исходники компилятора опенсурсного языка (Rust, D, Go, etc.) и поменяете их, вы не вправе называть получившийся продукт компилятором исходного языка не получив на то разрешения, что достаточно логично.
Разработчик ядра (CloudBEAR) является членом RISC-V International, поэтому ядра разработанные ими имеют полное право называться RISC-V. Насколько я понимаю, компании использующей подобные ядра для создания микроконтроллеров становиться членом совершенно не обязательно. Плюс членство для коммерческих организаций стоит далеко не миллионы (в зависимости от размера компании от $5к до $35k, см. слайд 22), а для институтов, non-profit-ов и частных лиц так и вообще бесплатно.
Рад видеть подобные статьи! Не рассматривали возможность поддержки Rust-а для дополнительного слоя безопасности? Вроде встроенная поддержка RISC-V там на неплохом уровне.
Вопрос в распространённости на пользовательском железе (мы же о потребительском TLS говорим, а не о спец. применениях). С практической точки зрения Кузнейчик это достаточно медленный алгоритм и сверх этого уполовинивать его производительность ради теоретических улучшений безопасности, на мой взгляд, нецелесообразно.
Нет, не касается, т.к. для него есть хорошо известные bit sliced реализации. Уже много лет никто, хоть немного разбирающийся в теме, не реализует AES для применения в продакшене через таблицы подстановок. Для Кузнейчика тоже можно реализовать bit sliced реализацию, но, насколько мне известно, никто этого не делал.
Другие алгоритмы вполне обходятся nonce кратным 8 битам, и только MGM уникален.
Везде есть баланс. Вы же не поддержите увеличение количества раундов блочного шифра в 2-3 раза для улучшения "безопасности"? Накручивать теоретическую безопасность в ущерб производительности очень плохо влияет на возможности распространения алгоритма и размер области возможных применений (например, я бы не стал применять Кузнейчик, и тем более режим вроде MGM, для шифрования дисков и данных в оперативной памяти).
И насчёт, "выше всего остального". Давайте просто вспомним про то, что разработчики уже который год не могут внятно объяснить происхождения S-боксов и про теоретический взлом Стрибога урезающий безопасность 512-битного варианта почти в два раза.
Для пользователя ещё куда не шло, но вот на сервере MGM с Кузнейчиком без аппаратного шифрования, будет кушать ресурсов весьма заметно по сравнению с аналогами (иначе говоря, сервис с поддержкой ГОСТового TLS будет стоить дороже, тем самым отрицательно влияя на его конкурентоспособность).
Распараллеливание (в т.ч. instruction-level parallelism) в данном случае ни на что не влияет. И GCM, и MGM оба поддерживают параллельную обработку блоков, поэтому MGM неизбежно будет как минимум в два раза медленнее GCM. Иначе говоря, с GCM вы условно будете шифровать за раз два блока, а с MGM вы будете за раз шифровать один блок и аутентифицировать его.
Где я такое утверждал? Вопрос в том, что соразмерно ли подобное падение производительности заявленным улучшениям в безопасности. Если уж и платить за двойное шифрование, я лучше выберу, при наличии возможности, вариант SIV режима, который даст misuse resistance, свойство гораздо более ценное на практике, чем, насколько я понимаю, в большей степени теоретическое усовершенствование заявленное в статье MGM.
По сравнению с хардварно ускоренным AES (да, сравнение не честное, но оно нынче практически в каждом утюге) и с ARX шифрами всё достаточно грустно. Не говоря уже о том, что использование таблиц, да ещё и таких крупных как в подходе с предрасчётом, сразу ставит нас под прицел тайминг атак (а bit sliced реализаций ГОСТовых шифров я в открытой литературе найти не смог). Плюс bit sliced реализация AES адаптированная под SIMD инструкции, так же значительно превосходит по производительности Кузнейчик, даже использующий предрасчитанные таблицы.
С таким подходом вы можете получить по сути nonce reuse, т.к. внешне передавая разные nonce вы будете использовать одно и то же значения счётчика сначала для шифрования, а потом для аутентификации. Причём эту ошибку вполне вероятно допустить на практике, например, используя для nonce счётчик с Little Endian порядком байт. Не утверждаю, что подобная ошибка может привести к взлому режима на практике, но хорошего в этом в любом случае мало. Хорошая реализация, на мой взгляд, должна выдавать ошибку если 128-й бит не равен нулю.
Найдите мне ещё один AEAD режим который бы использовал nonce с длиной не кратной восьми битам. Даже авторы MGM когда я обратил внимание на эту особенность в переписке с ними, привели примеры аналогичных подходов, но которые, сюрприз, использовали nonce таки кратное 8 битам.
Ага, эта версия настолько "улучшена" что требует двойного применения блочного шифра (в случае Кузнейчика ещё и не блещущего производительностью) вместо одинарного в GCM (строго говоря,
2*n+m+4противn+m+1, гдеnиm— кол-во блоков в шифруемом сообщении и в аутентифицируемых данных соответственно). Не говоря уже о "гениальном" решении использовать длину nonce равную 127-битам (63 бита для Магмы).Проблема с использованием стоимости в том, что можно взять иностранную штуковину стоящую 1 рубль и продать её государству за 100 рублей, положив 90 рублей в "карман" (зарезервировав долю для нужных лиц и всякие "сертификации") и отдав 9 работникам. И вроде бы получили 99% локализации и в отечественные рабочие места сколько-то ушло, но схема очевидно гнилая.
Да, локализацию процесса создания добавленной стоимости необходимо поощрять, но нормальная схема должна балансировать процент локализации и итоговую цену по сравнению с аналогичными зарубежными продуктами.
В случае когда известно распределение чисел и мы храним данные в байтах, наиболее эффективной кодировкой будет следующий подход:
Это если мы заботимся только о плотности хранения. Если же нам важна ещё скорость упаковки/распаковки, то тут уже начинается поиск компромиссов. Например, Group Varint Encoding (вариант VLQ) менее плотен по сравнению с git VLQ, но за счёт меньшего количества ветвлений он быстрее на современных процессорах.