Статья интересная, однако реальность несколько иная. По крайней мере в сфере коммерческой разработки. С вашего позволения внесу немного "коммерческой практики", возможно, что студентам эти замечания будут полезны.
Мы ежегодно берем студентов на летнюю практику и эта самая практика показывает, что в большинстве случаев к коммерческой работе студенты не готовы.
Самая большая проблема - разрыв системы образования и реальных потребностей рынка. Никто из преподавателей не говорит студентам, что то, что они изучают - невостребованно и отстает от реальности примерно на 10-15 лет. Более того, экономическая обоснованность разработки вообще не преподается. Итогом становится отсутствие понимания расчета затрат на разработку ПО и жесткий удар о финансовую реальность, где между "быстро" и "правильно" в 99% компаний выбирают "быстро". А самостоятельным поиском информации о картах развития себя, как специалиста, озадачиваются единицы, к сожалению.
Второе место занимают завышенные ожидания от практики или получаемой заработной платы. Нужно понимать, что даже если студент пришел на практику - на него тратят время штатные сотрудники, т.е. компания несет расход не только на оплату труда самого студента, но и на заработную плату того, кто его учит. Самое плохое при этом - специалист "выдергивается" из реальных проектов, нанося прямой временной и финансовый ущерб компании. Не нужно ожидать, что вас за ручку проведут от "А" до "Я", максимум, что вам дадут - это вектор движения и небольшие корректировки пути.
При этом "студент" сразу ожидает получать по 120-400к, потому что так ему сказали "средние заработные платы" и его преподаватель. Естественно, что такого не будет, так как интернов и джунов на рынке - переизбыток. Курсы Яндекса, Сбербанка и Нетологии сделали свое черное дело :) Нужно быть готовым, что первое время заработные платы будут на уровне обычного менеджера.
Здесь, однако, замечу, что "работать бесплатно" (если это не летняя практика, конечно) категорически не рекомендую. В 90% случаев вашими силами будет исполнен мелкий заказ и далее вы получите отказ в оффере. К сожалению, такие случаи не редкость. Это коммерческий рынок, чудес ожидать не стоит.
Максимум, что может запросить потенциальный работодатель - это тестовое задание, которое решается за 1-2 часа. Если вы решаете его дольше, то: а) либо ваши навыки не дотягиваются до нужного работодателю уровня, б) либо не стоит с таким работодателем связываться.
Все самое важное с вами обсудят на техническом собеседовании за 30-60 минут без "бесплатной работы".
Вопрос "Как выбрать компанию студенту" рассматривать вообще не стоит. Нужно смотреть правде в глаза, на данном этапе специалист не представляет из себя чего-то такого, ради чего компания может под него подстроиться. Между работником "с опытом" и студентом "с пятерками" работодатель в 99,9% случаев выбирает опыт, как гарантию окупаемости инвестиций в заработную плату.
Для начинающего специалиста справедливо правило: "Где взяли, там и хорошо". На первых этапах именно опыт работы в команде (и умение работать с командой) будет ключевым навыком.
Время в пути/удаленка, компенсации, престиж компании - не для студентов, а для Разработчиков среднего уровня. Именно этими "плюшками" привлекаются "опытные кадры", так как уровень заработной платы на этом этапе уже схожий у всех компаний.
Надеюсь, что начинающим специалистам это замечание будет полезно :)
По итогу вы предлагаете использовать методику парного программирования для оценки навыков на собеседовании, т.е. по сути вы пришли к выводу, о котором я писал в самом начале и о котором был спор.
...в любом случае на работе ему дадут "свой" тест, потому что каждое место уникально, где-то один стэк используют, где-то иной...
Как итог возвращаемся к тому, что "общий тест навыков" не является каким-то доказательством того, что сотрудник что-то умеет. Любая компания поверх него будет делать свой срез.
Мнение интересное, однако не согласен. Скриптовые Боты - это средство автоматизации рутинных задач. Если компания внедрила бота ради бота - это действительно будет "тупой бот с поддержкой в виде людей". С помощью скриптов можно создавать и сложные алгоритмы - вопрос инвестиций в проект.
Если вы говорите об умных ботах, то это уже не бот, а ИИ на минималках. У него и задачи иные. Тот же GPT вам даст ответ сколько километров до Луны, но не скинет презентацию от Иванова Ивана с квартальным отчетом за прошлый месяц. А скриптовый бот - без проблем :)
Все зависит от того, насколько компания заинтересована во внедрении и использовании. И насколько правильно подобран инструмент.
Расскажу два кейса из практики: Первый кейс, бот для HR, трейд маркетинговая компания. В свое время запускали бота для работы с обратной связью в одной компании. За 5 месяцев использования - было 3 (!) использования. Причина: бота делал HR без оглядки на пользователей, а пользователи не хотели общаться с "тупым ботом".
Второй кейс, бот для HR, но уже в другой компании из FMCG. Этот бот работал с сотрудниками, через него собирали сканы документов и т.п. Проработал года 4 в общей сложности, успешно пережил времена Ковида. Один раз выключали на неделю на технические работы (модификация серьезная) - пользователи оборвали горячую линию с просьбой вернуть бота в работу.
Потому коллеги по цеху правильно все рассказали об админках ботов. JMIX - удобный фреймворк, тоже его использовали ранее. Но сразу нужно закладывать порядка 2 ГБ RAM на его работу :)
Ну и свои приколы есть некритичные, например, если 0 строк в отчете будет, то он показывает 1 строку. Почему - не ясно, особенности реализации, видимо.
...главное чьобы джун знал java и был собразителен, умел кодить.
Интересное мнение.
Давайте порассуждаем, что такое "умел кодить"? Умел кодить по отношению к кому/чему? Мидл скажет, что ерунда написана, сеньер скажет, что ерунда и у мидла, и у джуна. Архитектор скажет, что вообще не те паттерны использованы. Ваш коллега скажет, что он сделал бы лучше. GPT вообще имеет свое мнение на этот счет и не всегда рабочее :) и т.п.
Должен быть компактный? Будет нечитаемый. Должен быть подробный с коментами? Будет спагетти-код. Код понятен вам? А вы уверены, что он понятен вашему коллеге?
Как такового критерия точной оценки кода нет. Даже в рамках литературы он делится на "быстрый" и "читаемый". Быстрый - сложно поддерживать, читаемый - менее функционален. Какой лучше? В зависимости от ситуации. Как оценить ситуацию? И опять 100 вариантов ответов.
Сможете четко и измеримо описать что такое "умел кодить" - буду использовать ваш метод и скажу большое человеческое спасибо :)
Аналогично сообразительность. Если я не сообразил сейчас - значит ли это, что не соображу через 5 минут? Все будет зависеть от широты знаний и не более. Вот я недавно "не сообразил" на Хакатоне МТС. А до этого вошел в ТОП-10% по ИБ на другом мероприятии. Я сообразителен? Или все же не очень. :)
Как вы оцениваете сообразительность?
Можно просто попросить человека ознакомться с Thymeleaf за один вечерок.
Верно же я вас понимаю, что я должен принять в штат сотрудника, который обещает выучить, но еще не знает? :) Обещать - не значит жениться. То, что кажется легким - может подкинуть много сложностей в момент реализации. Выучить пример из интернета - это не выучить технологию и правила ее применения.
Даже если он выучит этот кусочек - не факт, что он потянет остальное :)
По сравнением с HTML/CSS - Thymeleaf просто ни о чём.
Навлеку на себя гнев холивара, но озвучу... HTML/CSS - это гипертекстовая разметка, а не разработка. Thymeleaf - это одна из библиотек для ЯП Java, модуль фактически.
HTML/CSS - это верстка. Thymeleaf - это разработка. Задачи несколько разные и говорить, что что-то сложнее я бы не стал. Например, на базе Java можно поднять сервер, а страницу отрисовать в jsp. На базе HTML/CSS сервер не поднять, к сожалению :)
Это совсем разные вещи. Сложности есть и там, и там, но они разные :)
Джуны не всегда и это знают, на то они и джуны :) Если джун пришел и уже знает нужный стек - это уже не джун, а мидл в рамках вашей компании. О том и пишу.
А вообще это лишь пример, странно, что вы считаете, что на базе 1 технологии кто-то работает сейчас. У всех свой техно-зоопарк :)
Хорошо, приведу пример. Одна из используемых нами ранее технологий - это JMIX и ранее преимущество имел бы тот джун, который знает этот фрейм.
Сейчас мы используем (в силу особенностей действующих заказчиков) ванильный HTML. И сейчас при найме преимущество будет иметь тот джун, который умеет в Thymeleaf, например.
Каждая компания имеет свой набор технологий, каждая компания уникальна. Где-то мавеном собирают, где-то гредлом; где-то юзают Java 8, где-то Java 21 и т.п. Справедливо для любого ЯП.
Знаешь нужный стек - ты мидл. Не знаешь - джун.
Ориентироваться на то, что какой-то там тест с госуслуг валидно оценит кандидата лично я бы не стал. Тест то их, а работник уже ваш будет :) Как итог цена ошибки - потерянное время, деньги в виде оплаты труда и возможные репутационные риски для бизнеса. Потому индивидуальные тесты на местах никуда не уйдут.
Тест для джуна на что? На то, что он выучил определение ООП, а в IDE ни разу в жизни не работал? Если он может нормально ответить на нужные вопросы "не из учебника", то он уже не джун, поскольку понимает начинку.
Да и в любом случае на работе ему дадут "свой" тест, потому что каждое место уникально, где-то один стэк используют, где-то иной. Знаешь стэк - ты мидл, не знаешь - будешь джун :)
Предполагаю, что здесь интереснее история. Штат компании для поддержания статуса "IT" должен быть 50%, например. Нет нужного количества - получите стандартный налог. Есть нужное количество - пониженный.
Как итог работодатель будет сам просить сотрудников, чтоб удачно прошли тесты. А государство таким образом отделит "реальное IT", от тех, кто под него мимикрирует ради низкого налога.
И тут же для госорганов появится список тех, кого можно хантить к себе :)
Это ни в коем случае не разработка. Это в чистом виде эксплуатация.
Замечание в целом справедливое, однако данный термин используется именно в рамках разработки ПО, в частности он часто встречается в технических заданиях, где его и видит менеджер. Практика показывает, что во время эксплуатации менеджер и разработчик практически не пересекаются, так как если ПО работает планово - все занимаются своим делом.
От дословного перевода на русский у меня кровь из глаз пошла ...
В контексте словаря терминов употребляется не дословный перевод, а скорее смысловой. Называть файервол "огненная стена" - не очень хорошая затея :) Хотя ляпы могут быть - не исключаю.
AD - служба каталогов от MS, предназначена для централизованного управления инфраструктурой.
"Служба каталогов MS" для менеджера - это все тот же китайский язык. Хотя определение сути у вас действительно вышло удачнее моего. Добавлю в описание - спасибо :)
У меня схожее мнение ) Т.е. по сути будет пару сотен блокчейн элементов (по количеству банков), что не позволит банку самостоятельно менять баланс и упростит сверку внутри блокчейна.
Возможно, что до блокчейна пока не добрался, остался еще ряд документов на изучении. Если он и встроен, то в межбанковской сверке - точно не на уровне пользователей. Статья будет дополняться по мере изучения дополнительных материалов.
В целом есть центральная БД на стороне ЦБ, который производит эмиссию и, как итог, может свободно менять значения, получается. Т.е. как и пишут - это гибридная схема максимум, точно не полный блокчейн.
По сути верно, "цифра" = "счет ЦБ", но уже не банка.
"обеспечить инфраструктурой"
Статья дополняется, на данный момент известно, что это встраиваемый в банковское приложение модуль на базе API, который будет требовать ЭЦП (скорее всего ПЭП из ГосУслуг).
Ввязываясь в тему "электронных платежей", желательно все же предварительно изучить технологию и историю ее развития...
Спорное утверждение, всегда найдутся новые детали ) Это история формата "программируя на питоне вы должны знать ассемблер". Я описал лишь одну технологию из десятков, а вот продуктивный диалог и помогает разбираться в деталях, которых ранее не знал, например.
Мои выводы могут меняться, если доводы оппонента обоснованы. В конце концов задача именно разобраться в теме и помочь по итогу разобраться тем, кому оно потом потребуется. В статью дополнения тоже закидываю по мере их накопления.
Предполагаю, что не просто так победил именно этот стандарт. Одна из возможных причин - возможность "взлома" баланса посредством доступа к чипу. По сути рисковую зону увели из "взломать чип" в сторону "нужно взломать банковский сервер", что явно более сложная задача хотя бы потому, что к нему нет прямого доступа.
И потому, возможно, нет альтернатив хранения этого баланса оффлайн и его сверки с другими данными. Децентрализация данных, вероятно, здесь не спасает.
Участник платформы (банк) может заблокировать счет пользователя. Это говорит о том, что он находится выше по иерархии.
При этом сам счет пользователя принадлежит Оператору (ЦБ), как и счет банка. В одной из вкладок статьи уже разместил официальную ролевую модель согласно документации ЦБ.
Возможно, что вы увидите интересные вам детали позже, так как статья дополняется. Ряд документов находится на изучении, однако, вы можете найти на них ссылки в самом начале статьи. Там полные протоколы связи, ответов, передаваемых метрик, ролевая модель и т.п.
Я бы хотел избегать политической плоскости вопроса, так как она не относится к технической теме статьи.
Однако, кое-что в вашем ответе меня заинтересовало: 1) Какие именно платежные системы работали offline? Если вас не затруднит - назовите хотя бы 1 удачный проект. В этом случае запись должна производиться на чип, что само по себе уже несет риск подделки и было бы интересно узнать как это работает. В случае карт - на чипе нет информации о балансе, он запрашивается посредством терминала в момент оплаты, т.е. карта это полностью онлайн инструмент и без связи (терминала) - бесполезна. 2) Криптовалюта противоречит концепции контролируемой эмиссии, так как эмиссаром выступает не государство, а майнинг. На данный момент примеров полного перехода на криптовалюту лично я не знаю. Вы знаете такие примеры?
Хотя попытки создать хотя бы мини-экосистему принимались в далеком 2021 году: https://rb.ru/story/bitcoin-bequia/ Однако, если посмотреть на тот же заказ отеля, то как считали в долларах, так и считают:
Статья интересная, однако реальность несколько иная.
По крайней мере в сфере коммерческой разработки.
С вашего позволения внесу немного "коммерческой практики",
возможно, что студентам эти замечания будут полезны.
Мы ежегодно берем студентов на летнюю практику и эта самая практика показывает, что в большинстве случаев к коммерческой работе студенты не готовы.
Самая большая проблема - разрыв системы образования и реальных потребностей рынка.
Никто из преподавателей не говорит студентам, что то, что они изучают - невостребованно и отстает от реальности примерно на 10-15 лет.
Более того, экономическая обоснованность разработки вообще не преподается.
Итогом становится отсутствие понимания расчета затрат на разработку ПО и жесткий удар о финансовую реальность, где между "быстро" и "правильно" в 99% компаний выбирают "быстро".
А самостоятельным поиском информации о картах развития себя, как специалиста, озадачиваются единицы, к сожалению.
Второе место занимают завышенные ожидания от практики или получаемой заработной платы.
Нужно понимать, что даже если студент пришел на практику - на него тратят время штатные сотрудники,
т.е. компания несет расход не только на оплату труда самого студента, но и на заработную плату того, кто его учит.
Самое плохое при этом - специалист "выдергивается" из реальных проектов, нанося прямой временной и финансовый ущерб компании.
Не нужно ожидать, что вас за ручку проведут от "А" до "Я", максимум, что вам дадут - это вектор движения и небольшие корректировки пути.
При этом "студент" сразу ожидает получать по 120-400к, потому что так ему сказали "средние заработные платы" и его преподаватель.
Естественно, что такого не будет, так как интернов и джунов на рынке - переизбыток.
Курсы Яндекса, Сбербанка и Нетологии сделали свое черное дело :)
Нужно быть готовым, что первое время заработные платы будут на уровне обычного менеджера.
Здесь, однако, замечу, что "работать бесплатно" (если это не летняя практика, конечно) категорически не рекомендую.
В 90% случаев вашими силами будет исполнен мелкий заказ и далее вы получите отказ в оффере.
К сожалению, такие случаи не редкость.
Это коммерческий рынок, чудес ожидать не стоит.
Максимум, что может запросить потенциальный работодатель - это тестовое задание, которое решается за 1-2 часа.
Если вы решаете его дольше, то:
а) либо ваши навыки не дотягиваются до нужного работодателю уровня,
б) либо не стоит с таким работодателем связываться.
Все самое важное с вами обсудят на техническом собеседовании за 30-60 минут без "бесплатной работы".
Вопрос "Как выбрать компанию студенту" рассматривать вообще не стоит.
Нужно смотреть правде в глаза, на данном этапе специалист не представляет из себя чего-то такого, ради чего компания может под него подстроиться.
Между работником "с опытом" и студентом "с пятерками" работодатель в 99,9% случаев выбирает опыт, как гарантию окупаемости инвестиций в заработную плату.
Для начинающего специалиста справедливо правило:
"Где взяли, там и хорошо".
На первых этапах именно опыт работы в команде (и умение работать с командой) будет ключевым навыком.
Время в пути/удаленка, компенсации, престиж компании - не для студентов, а для Разработчиков среднего уровня.
Именно этими "плюшками" привлекаются "опытные кадры", так как уровень заработной платы на этом этапе уже схожий у всех компаний.
Надеюсь, что начинающим специалистам это замечание будет полезно :)
По итогу вы предлагаете использовать методику парного программирования для оценки навыков на собеседовании, т.е. по сути вы пришли к выводу, о котором я писал в самом начале и о котором был спор.
Как итог возвращаемся к тому, что "общий тест навыков" не является каким-то доказательством того, что сотрудник что-то умеет.
Любая компания поверх него будет делать свой срез.
Мнение интересное, однако не согласен.
Скриптовые Боты - это средство автоматизации рутинных задач.
Если компания внедрила бота ради бота - это действительно будет "тупой бот с поддержкой в виде людей".
С помощью скриптов можно создавать и сложные алгоритмы - вопрос инвестиций в проект.
Если вы говорите об умных ботах, то это уже не бот, а ИИ на минималках.
У него и задачи иные.
Тот же GPT вам даст ответ сколько километров до Луны, но не скинет презентацию от Иванова Ивана с квартальным отчетом за прошлый месяц.
А скриптовый бот - без проблем :)
Все зависит от того, насколько компания заинтересована во внедрении и использовании.
И насколько правильно подобран инструмент.
Расскажу два кейса из практики:
Первый кейс, бот для HR, трейд маркетинговая компания.
В свое время запускали бота для работы с обратной связью в одной компании.
За 5 месяцев использования - было 3 (!) использования.
Причина: бота делал HR без оглядки на пользователей, а пользователи не хотели общаться с "тупым ботом".
Второй кейс, бот для HR, но уже в другой компании из FMCG.
Этот бот работал с сотрудниками, через него собирали сканы документов и т.п.
Проработал года 4 в общей сложности, успешно пережил времена Ковида.
Один раз выключали на неделю на технические работы (модификация серьезная) - пользователи оборвали горячую линию с просьбой вернуть бота в работу.
Потому коллеги по цеху правильно все рассказали об админках ботов.
JMIX - удобный фреймворк, тоже его использовали ранее.
Но сразу нужно закладывать порядка 2 ГБ RAM на его работу :)
Ну и свои приколы есть некритичные, например, если 0 строк в отчете будет, то он показывает 1 строку.
Почему - не ясно, особенности реализации, видимо.
Интересное мнение.
Давайте порассуждаем, что такое "умел кодить"?
Умел кодить по отношению к кому/чему?
Мидл скажет, что ерунда написана,
сеньер скажет, что ерунда и у мидла, и у джуна.
Архитектор скажет, что вообще не те паттерны использованы.
Ваш коллега скажет, что он сделал бы лучше.
GPT вообще имеет свое мнение на этот счет и не всегда рабочее :)
и т.п.
Должен быть компактный? Будет нечитаемый.
Должен быть подробный с коментами? Будет спагетти-код.
Код понятен вам? А вы уверены, что он понятен вашему коллеге?
Как такового критерия точной оценки кода нет.
Даже в рамках литературы он делится на "быстрый" и "читаемый".
Быстрый - сложно поддерживать, читаемый - менее функционален.
Какой лучше? В зависимости от ситуации.
Как оценить ситуацию? И опять 100 вариантов ответов.
Сможете четко и измеримо описать что такое "умел кодить" - буду использовать ваш метод и скажу большое человеческое спасибо :)
Аналогично сообразительность.
Если я не сообразил сейчас - значит ли это, что не соображу через 5 минут?
Все будет зависеть от широты знаний и не более.
Вот я недавно "не сообразил" на Хакатоне МТС.
А до этого вошел в ТОП-10% по ИБ на другом мероприятии.
Я сообразителен?
Или все же не очень. :)
Как вы оцениваете сообразительность?
Верно же я вас понимаю, что я должен принять в штат сотрудника, который обещает выучить, но еще не знает? :)
Обещать - не значит жениться.
То, что кажется легким - может подкинуть много сложностей в момент реализации.
Выучить пример из интернета - это не выучить технологию и правила ее применения.
Даже если он выучит этот кусочек - не факт, что он потянет остальное :)
Навлеку на себя гнев холивара, но озвучу...
HTML/CSS - это гипертекстовая разметка, а не разработка.
Thymeleaf - это одна из библиотек для ЯП Java, модуль фактически.
HTML/CSS - это верстка.
Thymeleaf - это разработка.
Задачи несколько разные и говорить, что что-то сложнее я бы не стал.
Например, на базе Java можно поднять сервер, а страницу отрисовать в jsp.
На базе HTML/CSS сервер не поднять, к сожалению :)
Это совсем разные вещи.
Сложности есть и там, и там, но они разные :)
Джуны не всегда и это знают, на то они и джуны :)
Если джун пришел и уже знает нужный стек - это уже не джун, а мидл в рамках вашей компании.
О том и пишу.
А вообще это лишь пример, странно, что вы считаете, что на базе 1 технологии кто-то работает сейчас.
У всех свой техно-зоопарк :)
Хорошо, приведу пример.
Одна из используемых нами ранее технологий - это JMIX и ранее преимущество имел бы тот джун, который знает этот фрейм.
Сейчас мы используем (в силу особенностей действующих заказчиков) ванильный HTML.
И сейчас при найме преимущество будет иметь тот джун, который умеет в Thymeleaf, например.
Каждая компания имеет свой набор технологий, каждая компания уникальна.
Где-то мавеном собирают, где-то гредлом; где-то юзают Java 8, где-то Java 21 и т.п.
Справедливо для любого ЯП.
Знаешь нужный стек - ты мидл.
Не знаешь - джун.
Ориентироваться на то, что какой-то там тест с госуслуг валидно оценит кандидата лично я бы не стал.
Тест то их, а работник уже ваш будет :)
Как итог цена ошибки - потерянное время, деньги в виде оплаты труда и возможные репутационные риски для бизнеса.
Потому индивидуальные тесты на местах никуда не уйдут.
Тест для джуна на что?
На то, что он выучил определение ООП, а в IDE ни разу в жизни не работал?
Если он может нормально ответить на нужные вопросы "не из учебника",
то он уже не джун, поскольку понимает начинку.
Да и в любом случае на работе ему дадут "свой" тест, потому что каждое место уникально, где-то один стэк используют, где-то иной.
Знаешь стэк - ты мидл,
не знаешь - будешь джун :)
Предполагаю, что здесь интереснее история.
Штат компании для поддержания статуса "IT" должен быть 50%, например.
Нет нужного количества - получите стандартный налог.
Есть нужное количество - пониженный.
Как итог работодатель будет сам просить сотрудников, чтоб удачно прошли тесты.
А государство таким образом отделит "реальное IT", от тех, кто под него мимикрирует ради низкого налога.
И тут же для госорганов появится список тех, кого можно хантить к себе :)
Внес некоторые правки на основании вашего замечания, думаю, что стало более точно
Замечание в целом справедливое, однако данный термин используется именно в рамках разработки ПО, в частности он часто встречается в технических заданиях, где его и видит менеджер.
Практика показывает, что во время эксплуатации менеджер и разработчик практически не пересекаются, так как если ПО работает планово - все занимаются своим делом.
В контексте словаря терминов употребляется не дословный перевод, а скорее смысловой.
Называть файервол "огненная стена" - не очень хорошая затея :)
Хотя ляпы могут быть - не исключаю.
"Служба каталогов MS" для менеджера - это все тот же китайский язык.
Хотя определение сути у вас действительно вышло удачнее моего.
Добавлю в описание - спасибо :)
У меня схожее мнение )
Т.е. по сути будет пару сотен блокчейн элементов (по количеству банков), что не позволит банку самостоятельно менять баланс и упростит сверку внутри блокчейна.
Возможно, что до блокчейна пока не добрался, остался еще ряд документов на изучении.
Если он и встроен, то в межбанковской сверке - точно не на уровне пользователей.
Статья будет дополняться по мере изучения дополнительных материалов.
В целом есть центральная БД на стороне ЦБ, который производит эмиссию и, как итог, может свободно менять значения, получается.
Т.е. как и пишут - это гибридная схема максимум, точно не полный блокчейн.
По сути верно, "цифра" = "счет ЦБ", но уже не банка.
Статья дополняется,
на данный момент известно, что это встраиваемый в банковское приложение модуль на базе API, который будет требовать ЭЦП (скорее всего ПЭП из ГосУслуг).
Спасибо :)
Спорное утверждение, всегда найдутся новые детали )
Это история формата "программируя на питоне вы должны знать ассемблер".
Я описал лишь одну технологию из десятков, а вот продуктивный диалог и помогает разбираться в деталях, которых ранее не знал, например.
Мои выводы могут меняться, если доводы оппонента обоснованы.
В конце концов задача именно разобраться в теме и помочь по итогу разобраться тем, кому оно потом потребуется.
В статью дополнения тоже закидываю по мере их накопления.
Конкретные примеры - очень помогают в этом :)
Понял в чем проблема, подумаю как переформулировать :)
Предполагаю, что не просто так победил именно этот стандарт.
Одна из возможных причин - возможность "взлома" баланса посредством доступа к чипу.
По сути рисковую зону увели из "взломать чип" в сторону "нужно взломать банковский сервер", что явно более сложная задача хотя бы потому, что к нему нет прямого доступа.
И потому, возможно, нет альтернатив хранения этого баланса оффлайн и его сверки с другими данными.
Децентрализация данных, вероятно, здесь не спасает.
Участник платформы (банк) может заблокировать счет пользователя.
Это говорит о том, что он находится выше по иерархии.
При этом сам счет пользователя принадлежит Оператору (ЦБ), как и счет банка.
В одной из вкладок статьи уже разместил официальную ролевую модель согласно документации ЦБ.
Возможно, что вы увидите интересные вам детали позже, так как статья дополняется.
Ряд документов находится на изучении, однако, вы можете найти на них ссылки в самом начале статьи.
Там полные протоколы связи, ответов, передаваемых метрик, ролевая модель и т.п.
Я бы хотел избегать политической плоскости вопроса,
так как она не относится к технической теме статьи.
Однако, кое-что в вашем ответе меня заинтересовало:
1) Какие именно платежные системы работали offline? Если вас не затруднит - назовите хотя бы 1 удачный проект.
В этом случае запись должна производиться на чип, что само по себе уже несет риск подделки и было бы интересно узнать как это работает.
В случае карт - на чипе нет информации о балансе, он запрашивается посредством терминала в момент оплаты, т.е. карта это полностью онлайн инструмент и без связи (терминала) - бесполезна.
2) Криптовалюта противоречит концепции контролируемой эмиссии, так как эмиссаром выступает не государство, а майнинг.
На данный момент примеров полного перехода на криптовалюту лично я не знаю.
Вы знаете такие примеры?
Хотя попытки создать хотя бы мини-экосистему принимались в далеком 2021 году:
https://rb.ru/story/bitcoin-bequia/
Однако, если посмотреть на тот же заказ отеля,
то как считали в долларах, так и считают:
Вроде как сейчас все сервисы государственные на ГосОблако двигают.
Так что в любом случае будет аутентификация в куче сервисов одним пальцем :)