Если на смартфоне всплывает окно с обновлением приложения, мы активируем его без раздумий. Телефоны могут обновляться даже без уведомления пользователя. В конце концов, обновления необходимы — без установки последней версии программного обеспечения существует риск сбоев в работе сервисов на устройстве.
В криптовалютах с открытым исходным кодом все обстоит по-другому. Для работы с Биткоином не нужно подробно изучать строки кода, однако такая возможность все равно должна быть. Так как здесь нет единого органа управления, который осуществлял бы обновления и вносил изменения по своему усмотрению, добавление новых функций в блокчейн может быть довольно затруднительным.
В этой статье мы рассмотрим, каким образом модернизируются криптовалютные сети без участия центрального органа управления. Для этого и используются хардфорки и софтфорки.
Кто принимает решения в сети блокчейна
Чтобы разобраться в работе форков, необходимо понять, кто принимает решения (или осуществляет управление) в сети.
Что такое форки простыми словами — Криптословарь fork
В сети Биткоина можно выделить три группы участников — разработчики, майнеры и пользователи полных нод, которые вносят основной вклад в сеть. Упрощенные ноды (т. е. кошельки на телефонах, ноутбуках и т. д.) широко используются, но не являются «участниками» сети.
Разработчики
Разработчики создают и обновляют код. Любой пользователь с монетами может вносить в него изменения, так как код общедоступен и дает возможность отправлять любые предложения разработчикам.
Майнеры
Майнеры осуществляют защиту сети. Они запускают код криптовалюты и предоставляют ресурсы для добавления блоков в блокчейн. Например, в сети Биткоина для этих целей используется алгоритм Proof of Work. За свою работу майнеры получают вознаграждения за блок.
Пользователи полных нод
Полные ноды — это основа криптовалютной сети. Они проверяют, отправляют и принимают блоки и транзакции, а также хранят у себя копию блокчейна.
Перечисленные категории участников зачастую могут совпадать. Например, разработчик может быть одновременно и полной нодой или же полная нода может быть в то же время майнером. Любой человек может выступать в роли всех троих или ни одного из них. На самом деле, под пользователями криптовалюты обычно понимаются те, кто не выполняет ни одной из этих ролей. Вместо этого они используют упрощенные ноды или централизованные сервисы.
С учетом вышеописанного можно согласиться, что решения в сети должны принимать разработчики и майнеры. Разработчики создают код: без них не было бы программного обеспечения и некому было бы исправлять ошибки или добавлять новые функции. Майнеры осуществляют защиту сети: без здоровой конкуренции в майнинге контроль над чейном может быть захвачен злоумышленниками.
Однако, если бы майнеры и разработчики попытались навязать другим участникам сети свои желания, ничего бы не вышло. Многие считают, что реальный контроль принадлежит полным нодам. Однако все дело заключается в функции бесшовного обновления сети — пользователи могут выбирать, какое программное обеспечение они хотят использовать.
Что такое Soft Fork и Hard Fork в крипте? Обзор и примеры (ETH Classic, Litecoin, BTC Cash)
Разработчики не заставляют пользователей загружать бинарные файлы Bitcoin Core под дулом пистолета, также и майнеры не в состоянии ставить ультиматум и вносить свои изменения.
Эти участники не являются всемогущими управленцами — они лишь поддерживают работу сервисов. Если пользователи потеряют интерес к сети, то и ценность монет упадет, что напрямую повлияет на доход майнеров (их вознаграждение в долларах уменьшится). Что касается разработчиков, то пользователи могут просто игнорировать их.
Дело в том, что программное обеспечение не является ничьей собственностью. Пользователи могут вносить любые изменения и взаимодействовать с теми, кто использует измененное программное обеспечение. Это осуществляется посредством форка программного обеспечения и создания новой сети.
Что такое форк
Форк — это создание копии программного обеспечения и его модификация. При этом первоначальный проект продолжает функционировать, но форк развивается отдельно в своем направлении. Предположим, что внутри команды некого сайта с криптовалютой возникли серьезные разногласия по поводу дальнейшего развития. Тогда одна часть команды может воссоздать сайт в другом домене, где они будут размещать другой контент.
Оба этих проекта построены на одной основе и имеют общую историю подобно тому, как одна дорога разделяется на два разных направления.
Обратите внимание, что форки могут осуществляться только в проектах с открытым исходным кодом, и подобные случаи происходили еще задолго до появления Биткоина или Ethereum. Однако хардфорки и софтфорки могут производиться только в сетях блокчейна . Давайте рассмотрим их подробнее.
➟ Думаете, с чего начать работу с криптовалютами? Купите биткоин на Binance!
Хардфорки и софтфорки
Несмотря на похожие названия и задачи, хардфорки и софтфорки существенно различаются. Рассмотрим каждый из них подробнее.
Что такое хардфорк
Хардфорки — это обновление программного обеспечения, несовместимое с предыдущими версиями. Обычно это происходит, когда ноды добавляют изменения, противоречащие существующим правилам старых нод. Новые ноды могут взаимодействовать только с нодами, использующими новую версию. В результате блокчейн разделяется на две отдельные сети: одну со старыми правилами и другую — с новыми.
После обновления ноды становятся синими. Старые желтые ноды отвергают их, а синие соединяются друг с другом.
Итак, теперь две сети работают параллельно. Они обе продолжат работать с блоками и транзакциями, но не в одном блокчейне. Все ноды работали в одном блокчейне до создания форка (у этого форка будет такая же история, как и у оригинального блокчейна), но в будущем их блоки и транзакции будут отличаться.
Поскольку сети имеют общую историю, средства пользователей дублируются в новой сети, если у них были монеты до форка. Предположим, во время форка у вас было 5 BTC на блоке 600 000. Даже если вы потратите эти 5 BTC в старом чейне в блоке 600 001, они останутся в блоке 600 001 нового блокчейна. Если в форке будет использоваться прежняя валюта, ваши приватные ключи также будут содержать средства из оригинального форка.
В качестве примера хардфорка можно привести форк 2017 года, в результате которого Биткоин был разделен на два чейна — оригинальный Биткоин (BTC) и новый Bitcoin Cash (BCH). Форк появился в результате долгих споров о наилучшем подходе к масштабированию. Сторонники Bitcoin Cash хотели увеличить размер блока, а сторонники Биткоина выступили против этого изменения.
Увеличить размер блока можно только с изменением правил. Это происходило до софтфорка SegWit (подробнее об этом далее), поэтому ноды принимали только блоки размером менее 1 Мб. Даже блок на 2 Мб, соответствующий всем прочим требованиям, все равно был бы отклонен.
В форке только ноды с новым программным обеспечением смогли одобрять блоки крупнее 1 Мб. Конечно, это означало полную несовместимость с оригинальной версией, так что взаимодействовать могли только ноды с одинаковыми модификациями.
Что такое софтфорк
Софтфорк — это обновление с обратной совместимостью, то есть обновленные ноды могут взаимодействовать со старыми нодами. Обычно софтфорк происходит при добавлении новых правил, которые не противоречат старым.
Например, с помощью софтфорка можно уменьшить размера блока. Проиллюстрируем это на примере Биткоина: хотя существует максимально допустимое значение размера блока, минимального размера нет. То есть для одобрения блоков меньше определенного размера нужно просто отклонять более крупные блоки.
Это не приведет к автоматическому отключению от сети. Ноды софтфорка по-прежнему смогут взаимодействовать с нодами из оригинального блокчейна — они просто будут фильтровать получаемую информацию.
Хороший пример софтфорка — это вышеупомянутый форк Segregated Witness (SegWit), который произошел вскоре после разделения Bitcoin/Bitcoin Cash. Обновление SegWit было тщательно продумано и изменило формат блоков и транзакций. Старые ноды все еще могли проверять блоки и транзакции (изменение формата не противоречило правилам), но просто не понимали их. Для прочтения определенных полей и анализа дополнительных данных необходимо переключение на новое программное обеспечение.
Даже через два года после активации SegWit не все ноды были обновлены. Обновление имеет свои преимущества, но никакой срочности в этом нет, посколько изменения не оказывают деструктивного влияния на сеть.
Хардфорки и софтфорки — что лучше?
По сути, каждый вид форков служит своим целям. Рожденные в результате разногласий хардфорки могут разделить сообщество, но запланированные форки позволяют свободно модифицировать программное обеспечение по обоюдному согласию.
Софтфорк — это более мягкий вариант. Он подразумевает изменения с определенными ограничениями, которые не противоречат старым правилам. В любом случае, если обновление может оставаться совместимым, то беспокоиться о фрагментации сети не стоит.
Резюме
Хардфорки и софтфорки имеют решающее значение для успеха сетей блокчейна в долгосрочной перспективе. Они позволяют вносить изменения и обновления в децентрализованные системы, несмотря на отсутствие единого органа управления.
Форки — это возможность для блокчейнов и криптовалют интегрировать новые функции по мере их разработки. Благодаря этим механизмам исчезает необходимость в централизованной системе с вертикальным управлением. Без них развитие блокчейнов тормозилось бы одними и теми же правилами.
Источник: academy.binance.com
Git fork. Зачем нужны форки и как с ними работать
Как и в случае с ребейзом, с форками в гите я разобрался не сразу. Вроде ничего особенного там нет, это просто копия репозитория, но натыкаешься на какие-то подводные камни и не сразу понимаешь, как их обойти. Да и вообще, зачем нужны эти форки, тоже осознаешь не сразу. Когда врубаешься, все становится просто, ну это как всегда.
Я не сторонник подхода «чо тут не понимать, тупой штоле» и попробую рассказать человеческими словами, что вообще такое форки, зачем они нужны и как с ними работать. А вы оцените, как получилось. Синьор git девелоперам статья покажется банальщиной, но тем, кто еще не успел обрести такой титул, будет полезно.
Начнем с примера.
Ты работаешь в компании Company в какой-то команде и со своими ребятами пишешь код, например, блога вашего сайта. Рядом сидят ребята из другой команды, которые занимаются админкой. У каждой команды отдельный репозиторий, вы работаете и друг другу не мешаете.
Вам приходит задача — дать возможность разрешать или запрещать комментировать статьи блога отдельным пользователям. Сами вы это сделать не можете. Такие данные о пользователях хранятся не на вашей стороне, а у ребят, занимающихся админкой. У них есть списки пользователей и все данные по ним. А вы тянете эти данные по апи.
Прямо микросервисы, все как положено.
Доступа к их репозиторию нет, поэтому идете договариваться. Обсуждаете вместе детали. Так, нужно завести поле в базе, какое-нибудь булево isAllowedComments, соответственно, подготовить миграцию, вывести это поле отдельной колонкой в таблице пользователей, там поставить чекбокс и уметь сохранять это в базу. А еще в апи, которое вы дергаете, нужно добавить в респонсе это самое поле.
Вроде немного, ребята говорят, окей, через пару дней сделаем. И на самом деле делают, все хорошо.
Небольшие просьбы вроде этой появляются все чаще. То вам нужно накатить миграцию и разбанить всех пользователей, которые зарегались больше года назад. То в апи в респонсе вам понадобилось количество комментов пользователя. И каждый раз вы идете с такой мелочью к соседям и просите это сделать.
Рано или поздно ребятам из админки это надоедает, потому что у них хватает и своей работы. Они предлагают вам дать права на репозиторий и пробовать такие небольшие задачи делать самим. Говорят, мол, с такой фигней типа добавления поля в респонс вы и сами справитесь. Если что, зовите, поможем.
Прав на пуш в мастер, конечно, никто не даст, но свои ветки создавайте и присылайте мердж-реквесты. Мы смотрим, если все хорошо, то мерджим в мастер и выкладываем в прод. Все довольны. И нам работы меньше, и вам не ждать, пока у нас руки дойдут до вашей задачи.
Вы с командой соглашаетесь. Ты клонируешь их репозиторий и пилишь фичи. Примерно так
Дальше идешь в битбакеты-гитхабы, в репозиторий админки, делаешь мердж-реквест и ждешь, когда его примут. Обычная схема. Мердж-реквест примерно везде делается одинаково: ищешь кнопку «Создать мердж-реквест» или пулл-реквест, выбираешь свою ветку, затем выбираешь, куда сливать (обычно уже по умолчанию будет мастер) и жмешь «Отправить».
Проходит пара месяцев. Ты случайно замечаешь в репозитории админки ветку petya/update-email. Спрашиваешь ребят из админки, а что за Петя вам коммитит? Те говорят, а, это чувак из отдела емейлов, мы им тоже доступ дали, как и вам. Они тоже приходили к нам по 3 раза в месяц, мы задолбались и теперь с ними работаем по вашей схеме.
Ничего, все довольны.
Проходит год. Команд, которые работают по такой схеме, уже десяток. В репозитории появляются ветки
- vasya/blog-user-ban
- petya-ivanov/email_new_field
- email/migration
- blog/hotfix
- petrov/srochno-v-prod
Эти ветки множатся, мерджатся между собой и вообще живут своей жизнью. Называются они как попало, коммиты подписывают кто во что горазд, старые ветки не удаляются после мерджей. Надвигается хаос.
Конечно, ребятам из админки не очень нравится такой мусор в их репозитории. Сначала они пытаются с этим бороться и проводить разъяснительные работы. Пытаются рассказать о правилах приличия в их репозитории. Пишут доку и официальное письмо всем программистам, где все подробно рассказывают. Как именовать ветки, как подписывать коммиты, не забывать удалять старые ветки, не заводить лишние ветки без надобности и прочее.
Это дело хорошее, но бесполезное. В компании полсотни разрабов, у каждого своя команда и свои правила работы с репозиторием. Люди приходят и уходят, эти правила уже никто не помнит, да и всем пофигу, главное фичу сделать, чего там заморачиваться с ветками и коммитами. Пусть у команды админки об этом голова болит.
Главное, у нас все хорошо, в своем командном проекте, потому что мы никого к себе не пускаем, ахаха. Поэтому и ветки красиво называются, и коммиты адекватно подписаны. Нас тут 5 человек работают, уж между собой-то договоримся.
А между тем в репозитории админки образуется все больший трэш. То злодеи опять пушат ветки с названиями не по ГОСТу, и тимлида бесят. То сам тимлид с похмелья выдал новому чуваку доступы на пуш в мастер, а тот на радостях запушил миграцию, которая пол-сайта уронила. То по ошибке смерджили petya/hotfix вместо vasya/hotfix. В общем весело всем, кроме ребят из админки.
И вот однажды что-то изменилось. Тебе понадобилось запилить новую фичу и ты привычно набиваешь
git checkout master git pull —rebase origin master git checkout -b vasya/fix-comments . git push origin vasya/fix-comments waiting. Rejected
Опа, что за фигня? Пробуешь еще раз на всякий случай — снова rejected. Пишешь команде админки
- репца, привет, я чот запушить вам не могу, вы права сняли?
- привет, Петя, да, мы убрали права на пуш для всех не-членов нашей команды
- эээ, ну во-первых, я Вася, а во-вторых, как мне теперь делать?
- теперь все мердж-реквесты принимаются из форков
- окей, а на фига это надо? Все равно же в мастер нельзя было запушить, все и так через мердж-реквесты было.
- видишь ли, Вася, у нас тут столько народа, что мы уже не понимаем, кто Вася, а кто Петя, а кто вообще мимо проходил. И в ваших ветках мы тут просто тонем, git fetch невозможно сделать. Мы пытались донести до коллег, что это наш репозиторий и мы просим соблюдать простые правила работы с ним. Но народа много и все решили, что наш проект это помойка, в которой можно делать, что угодно. Все равно ж в мастер не попадет, а там разберутся. Ну и пара инцидентов с неправильно выданными правами. Да, наш косяк, но вас слишком много, чтобы за каждым уследить. Короче, форкайте репозиторий и резвитесь там, как хотите. А нам отправляйте только мердж-реквесты. Вам без разницы, а нам спокойней и в репозитории чище.
- окей, понятно
Понятно-то оно понятно, но ты с форками не работал. Ладно, думаешь, разберешься же, не тупой. Мердж-реквест что ли из форка не отправишь? К тому же ты читал git-scm и знаешь, что форк — это просто копия репозитория. Начинаешь разбираться.
Сначала идешь в гитхаб-битбакет и ищешь там в нужном репозитории кнопку Fork. Обычно она недалеко от кнопки clone. Жмешь на fork и для тебя создается проект. Если исходный был company/adminka.git, то твой будет примерно vasya/adminka.git. Ну или примерно так. Дальше клонируешь его как обычно
Естественно, свой форк клонируешь, а не оригинальный. Затем там создаешь привычно ветку и пушишь ее.
git checkout -b blog/new-field . git push origin blog/new-field
Заходишь в гитхаб-битбакет исходного репозитория, жмешь «Создать мердж-реквест», выбираешь свою ветку, она будет называться примерно vasya/adminka/blog/new-field, и ждешь, пока мердж-реквест примут.
Пока все ровно так, как ты привык, ничего нового. Мердж-реквест принимают и все хорошо.
Через месяц тебе нужно сделать еще одну задачу. Ты привычно подтягиваешь мастер и настораживаешься
git pull —rebase origin master From bitbucket.org:vasya/adminka Current branch master is up to date.
За месяц нет новых коммитов в мастере? Да не верю. Идешь в репозиторий админки, смотришь, там до фига коммитов, чуть не каждый день в мастер пушат. В чем дело?
Присматриваешься, откуда ты пулишься и видишь, что это vasya/adminka. Это твой репозиторий, твой форк. Конечно, ты его месяц не трогал и он ничего не знает о новых коммитах в исходном проекте. Их нужно подтянуть и только тогда создавать новую ветку. Можно сделать это так
То есть вместо origin указываешь адрес нужного репозитория. И вот теперь-то подтянется мастер именно исходного проекта, а не твоего. А еще лучше сделать так, чтобы не набивать каждый раз длинный адрес
Теперь у тебя есть origin — твой репозиторий, твой форк, а есть upstream — оригинальный репозиторий. И ты можешь пулиться, указывая сразу upstream
git pull —rebase upstream master
Вот теперь твой мастер актуален, можешь создавать ветку и пушить в репозиторий. Пушить уже в origin, то есть свой, потому что в upstream, исходный, тебе пушить никто не даст. То есть еще раз, пулишь мастер так
git pull —rebase upstream master
а пушишь свою ветку так
git push origin branch-name
По сути это все, что нужно знать о работе с форками. После этого идешь создавать мердж-реквест, твоя ветка уже видна в исходном репозитории. Если ты работал над веткой, а за это время в мастер накидали еще коммитов, то перед отправкой мердж-реквеста стоит отребейзиться от мастера
git checkout master git pull —rebase upstream master git checkout branch-name git rebase master git push -f origin branch-name
Тут можешь делать, как хочешь, твой форк, твои правила. Можешь пушить с форсом, как у меня в примере. Если не хочешь с форсом, то можешь создать отдельную ветку и положить коммит в нее. Как угодно. Главное, чтобы твои коммиты лежали поверх свежих коммитов из мастера.
Тогда никто не будет возникать при рассмотрении мердж-реквеста, а ты будешь уверен, что у тебя самые свежие обновления.
Подробнее почитать про ребейз можно здесь — git merge и rebase.
И на этом все. Главное, что нужно сделать, это добавить upstream и четко понимать, в чем его отличие от origin.
С форками можно работать и в компании на полсотни разработчиков, но особенно это популярно в опенсорсе. Возьмите какой-нибудь проект, например, vuejs, у него больше 20 тысяч форков и 3 сотни контрибьюторов. Представьте, что бы творилось в репозитории, пусти всех этих энтузиастов пушить свои правки. А так они спокойно работают со своими форками и присылают пулл-реквесты, не засоряя проект.
Всем удачи. Любите гит, он совсем не страшный 🙂
P.S. Пожалуй, это самая большая статья про форки, которую можно было написать =))
P.P.S. И небольшой опрос напоследок
Все статьи о git
- Курс «Git для начинающих». Видеоуроки
- Git merge vs rebase для начинающих
- Git fork. Что такое форки и как с ними работать
- Как я перестал бояться и полюбил git
- Git bisect. Ищем баги с помощью гита
- 12 причин работать с гитом в командной строке
- Как склеить коммиты в git
- Мой набор команд при работе с git
- Как работать с git в Modx
- Как установить git в Linux Mint
- Визуализация истории git с помощью Gource
Источник: webdevkin.ru
Что такое хардфорк и софтфорк
Форк (от английского слова fork — вилка или развилка) — явление, которое нередко сопровождает различные блокчейн-проекты.
Блокчейн — это децентрализованная база данных, цепочка последовательных блоков, хранящих в себе информацию о транзакциях, которые совершаются в сети. Структуру блокчейна и устройство блоков определяет протокол, заложенный в программный код узлов этой сети. Изменение протокола — и есть форк.
Зачем нужны форки
Два момента, которые чаще всего указывают разработчики блокчейна в качестве причин форка, — это необходимость усовершенствования блокчейн-технологии и оптимизация сети. Самые распространенные изменения:
- увеличение размеров блока с целью повышения пропускной способности (транзакций/сек.);
- уменьшение комиссии за транзакции.
Кроме того, может быть утрачено единое видение проекта, могут возникнуть непреодолимые разногласия внутри сообщества блокчейн-проекта, и в этом случае форк также неизбежен.
Разновидности форков
В зависимости от масштабов модификации протокола блокчейна, разделяют хардфорк (дословно с англ. — жесткая вилка) и софтфорк (дословно с англ. — мягкая вилка).
- Хардфорк — существенная модификация работы алгоритмов и кода блокчейна, в результате которой сеть либо полностью переходит на новую версию блокчейна, либо разделяется на две параллельных сети. Хардфорк часто используют для запуска новых криптопроектов (криптовалюты).
- Софтфорк — незначительное изменение протокола блокчейна, в результате которого появляется две версии протокола, существующие параллельно, то есть все узлы блокчейна работают в одной сети, но часть из них по старым правилам, а часть — по новым.
Зачем нужен хардфорк
Код блокчейна может изменяться и дорабатываться: убираются существующие ошибки и уязвимости, добавляются обновления и улучшения.
Когда доработки серьезные, производится хардфорк. То есть, по сути, создание параллельной копии протокола, но с добавлением нового кода.
Хардфорки — это такая модификация, при которой узлы блокчейна (ноды) добавляют изменения, которые противоречат правилам, по которым работают старые ноды. Соответственно, новые ноды могут работать только с нодами, использующими новую версию блокчейна. Результат — блокчейн полностью переходит на новый протокол или делится на две отдельных сети: в старой действуют старые правила, в новой — новые.
Кроме того, все монеты этого блокчейна как бы раздваиваются, так как появляется новый блокчейн с новой монетой, с теми же самыми балансами на тех же самых адресах, что в старом блокчейне. При этом биржевая ценность исходной монеты, как правило, делится на неравные доли: менее популярная монета, появившаяся в результате форка, стоит меньше более популярной исходной монеты.
Такой подход позволяет сохранить стабильность текущего протокола блокчейна и избежать риска сбоев при обновлении.
Хардфорки проводятся для крупных обновлений, а также применяются для разрешения спорных ситуаций.
Простыми словами: хардфорк нужен для внесения серьезных изменений в работу блокчейна, настолько серьезных, что его приходится делить на две отдельных сети.
Участники хардфорка
Как правило, хардфорк — это результат длительных обсуждений, ведущих к консенсусу в сообществе блокчейн-проекта. Изначально выдвигается какое-то предложение, потом оно дорабатывается, тестируется и в конечном итоге реализуется.
В случае, когда обновление крупное и несет в себе не только технические изменения, а например, меняет токеномику криптовалютного проекта, обсуждение может выйти за рамки сообщества разработчиков блокчейна.
К примеру, в блокчейне Ethereum существует целая система по усовершенствованию сети (Ethereum Improvement Proposal).
Для активации хардфорка нужно не просто написать новый программный код, но и получить согласие на обновление большинства участников. Кроме разработчиков блокчейна, также очень важно мнение валидаторов сети. Ведь именно от них зависит работа блокчейна и, если они будут не согласны с предложенным разработчиками обновлением, то просто не переведут на него свои вычислительные узлы.
Важно понимать,что протокол блокчейна невозможно изменить без согласия сообщества, так как децентрализована не только сеть, но и программный уровень.
Блокчейн-проекты, образующиеся в результате хардфорков
Итак, если большинство участников блокчейн-проекта согласны с обновлением, сеть переходит на новый протокол. Если же единство мнения отсутствует, часть нод переходит на новую версию блокчейна, а часть работает по старым правилам. Результат — блокчейн разделяется на две цепи.
Для примера, крупнейшие хардфорки: Bitcoin Cash, Ethereum Classic, Merge.
Зачем нужен софтфорк
Софтфорк — вид форка, характеризующийся обратной совместимостью. То есть, это такое изменение программного протокола блокчейна, после которого новые алгоритмы без проблем взаимодействуют со старыми.
Суть обратной совместимости в том, что старые транзакции могут распознаваться новыми нодами. То есть, для обеспечения соблюдения нового протокола обновиться должна часть валидаторов, а не абсолютно все узлы, как при хардфорке.
Простыми словами: Софтфорк — это такой себе апгрейд блокчейна, выполненный для улучшения его работы, когда старый и новый протоколы гармонично функционируют в одной сети.
Софтфорки не подразумевают деление блокчейна на автономные сети, выпуск новых монет или каких-то других принципиальных изменений.
В основном, софтфорки проводятся для реализации таких задач:
- увеличение производительности сети;
- снижение комиссии;
- повышение конфиденциальности блокчейна;
- улучшение безопасности.
После проведения софтфорка участникам сети нужно обновить свое ПО и то, не обязательно, те, кто не согласен с изменениями, могут работать по старым правилам.
Софтфорки способствуют улучшению различных свойств криптовалют, устраняют ошибки в коде, стимулируют конкуренцию.
Известные софтфорки: SegWit (софтфорк биткойна, основная цель которого — увеличение размеров блока для повышения пропускной способности сети), Pay to Script Hash (P2SH) (софтфорк проводился для изменения формата биткойн-адресов), Replace-by-fee (софтфорк Litecoin, позволил участникам сети редактировать транзакции в части изменения уровня комиссии).
Форки сопровождают развитие практически любого популярного блокчейна, а пользователи криптовалюты, грамотно используя информацию о них, могут повысить свои доходы от инвестиций и торговли монетами.
Источник: tangem.com