А почему детишки должны в нее верить, если она научно не доказана? Внимательно почитайте вашу же ссылку на википедию. Это всего лишь «эвристическое утверждение».
Чтобы таким образом проверить какой мощностью оборудования обладает майнер. И пропорционально этой мощности начислить ему монеты, когда пул найдет «красивый хеш» и таким образом заработает монеты.
Тут нужно понять одну важную вещь: поиск «красивого хеша» это случайный процесс. Может так получится, что вы на самом простом компьютере начали вычислять хеши и вам сразу попался нужный хеш. Вот только вероятность такого события очень маленькая. Но если таких майнеров у пула будет миллион, то и вероятность увеличивается в миллион раз. А выигрыш распределяется на миллион майнеров, т.к. особой заслуги конкретного майнера не было — это был случайный процесс. Следующий раз найдет другой майнер, а монета опять распределится на всех (пропорционально мощности).
Вы забываете добавить слово «имхо». Если вы не знаете такого способа это не значит что его не существует. Я, например, знаю такой алгоритм, который позволит радикально сократить количество сетевого трафика, даже не прибегая к шардингу. Я могу о нем более подробно рассказать, если вам интересно. Вкратце: все ноды изначально упорядочиваются (относительно своего адреса-публичного ключа), затем обмен идет только уникальной информацией. Число обменов примерно равно логарифму размера сети. Размер общей переданной информации примерно равно одному блоку. По сравнению с текущими протоколами это дает ускорение в 1000 раз (алгоритм уже проверен в тестовой сети).
Из этого следует вывод что варианта «просто куплю оборудование — начну богатеть» не работает. Или я где-то не прав?
Вы можете объединиться с другими «желающими разбогатеть» и более чаще получать вознаграждение, которое будете делить с друг другом пропорционально мощности оборудования. Это называется майнинг пулы
Это прекрасно, но ваша элементарная логика учитывает только вариант, когда хранятся все данные на ноде. Но есть другие варианты, например шардинг. А тогда несложно прикинуть, что если каждая нода будет хранить тысячную часть всех данных, то блокчейн в год будет расти примерно на полтора гигабайта. Любые пользовательские компьютеры смогут это поддерживать. Кошельки смогут быть не только на мощных централизованных серверах.
P.S.
Извините за сохранение вашей стилистики «доказательства»…
Если говорить про проект 2013 года, то перевод был из RS-Balance, там несколько другие были объекты, например, там не было регистров и кроме того, там редактированием задним числом невозможно. И кстати это значительно облегчило жизнь при переходе…
В случае более ранних проектов, например, в 2008 году переводил с 1С 7.7, то передача осуществлялась справочник в справочник, документ в документ, а бухучет велся в отдельных базах, и после перехода он также продолжался вестись в отдельных базах. Более того у меня на практике так сложилось, что клиенты от несколько сот пользователей в базе всегда вели бухучет в отдельных базах.
Согласен, применять такой способ для всех случаев жизни не оптимально. Его выгодно применять только на тот контур программы, число пользователей которого очень большое, а их деятельность высокооперативна (например непосредственно обслуживают покупателей, фронт-офис). Если это, например, финансовый блок с небольшим количеством пользователей системы, в нем мало сотрудников, остановка их работы на несколько дней существенно не повлияет на работу компании, то можно переводить обычным способом — остановить старую программу, запустить новую или параллельно вести учет в течении месяца в двух программах…
Наверно, текст статьи я написал несколько сумбурно и не передал основную мысль. Попытаюсь это сделать заново.
Всего существует две полноценные рабочие базы. Одна база — это старая программа, другая это новая программа. Между ними настраивается двухсторонний обмен. Все изменения сделанные в одной базе передаются в другую. Не важно какие пользователи в каких базах работают.
Сложность тут в том что это технически трудная задача, но она ничто по сравнению с организационной задачей при внедрении системы для нескольких сот пользователей. Да, нужно потратить несколько месяцев для наладки обмена, зато получаем выигрыш при внедрении: безопасность перехода и достаточно быстрая скорость перевода. В данном проекте была филиальная структура, мы с фин. директором заказчика ездили по филиалам и внедряли программу — неделя в одном городе, неделя в другом. Но через некоторое время собственникам фирмы надоело постоянное отсутствие фин.директора, т.к. он нужен был в Москве. Было принято решение внедрять удаленно — через Skype. Скорость внедрения резко выросла, каждый день я переводил один филиал, а через пару недель мы отключили старую программу (это был RS-Balance)
Я скорее технический специалист, чем бизнес-консультант. Данная статья отвечает КАК нужно переходить на новую систему.
Причины перехода на новую программу остались за рамками статьи, только вскользь было упомянуто про то, что старая программа больше не удовлетворяет потребности бизнеса. И если говорить про конкретный проект, то решение созрело и было принято бизнесом до меня, от меня требовалось только осуществить переход.
Цели написания статьи — показать новый способ внедрения, в противовес так называемому большому взрыву. Так получилось, что две одинаковые фирмы выполняли внедрение 1С практически одновременно. В одной выполнялось большим взрывом — т.е. с 1 января все пользователи перешли на новую систему. А в другой, где работал я со своей командой, управляемым взрывом — перевод по отдельным рабочим местам. Разница была в том, что первая фирма на месяц остановила отгрузки клиентам, т.к. оказалось что программа была местами не доработана, вторая фирма ни на день (и даже не на час) не прекращала свою работу. И вот хочется чтобы мой опыт пригодился…
Тут нужно понять одну важную вещь: поиск «красивого хеша» это случайный процесс. Может так получится, что вы на самом простом компьютере начали вычислять хеши и вам сразу попался нужный хеш. Вот только вероятность такого события очень маленькая. Но если таких майнеров у пула будет миллион, то и вероятность увеличивается в миллион раз. А выигрыш распределяется на миллион майнеров, т.к. особой заслуги конкретного майнера не было — это был случайный процесс. Следующий раз найдет другой майнер, а монета опять распределится на всех (пропорционально мощности).
Вы можете объединиться с другими «желающими разбогатеть» и более чаще получать вознаграждение, которое будете делить с друг другом пропорционально мощности оборудования. Это называется майнинг пулы
P.S.
Извините за сохранение вашей стилистики «доказательства»…
В случае более ранних проектов, например, в 2008 году переводил с 1С 7.7, то передача осуществлялась справочник в справочник, документ в документ, а бухучет велся в отдельных базах, и после перехода он также продолжался вестись в отдельных базах. Более того у меня на практике так сложилось, что клиенты от несколько сот пользователей в базе всегда вели бухучет в отдельных базах.
Согласен, применять такой способ для всех случаев жизни не оптимально. Его выгодно применять только на тот контур программы, число пользователей которого очень большое, а их деятельность высокооперативна (например непосредственно обслуживают покупателей, фронт-офис). Если это, например, финансовый блок с небольшим количеством пользователей системы, в нем мало сотрудников, остановка их работы на несколько дней существенно не повлияет на работу компании, то можно переводить обычным способом — остановить старую программу, запустить новую или параллельно вести учет в течении месяца в двух программах…
Всего существует две полноценные рабочие базы. Одна база — это старая программа, другая это новая программа. Между ними настраивается двухсторонний обмен. Все изменения сделанные в одной базе передаются в другую. Не важно какие пользователи в каких базах работают.
Сложность тут в том что это технически трудная задача, но она ничто по сравнению с организационной задачей при внедрении системы для нескольких сот пользователей. Да, нужно потратить несколько месяцев для наладки обмена, зато получаем выигрыш при внедрении: безопасность перехода и достаточно быстрая скорость перевода. В данном проекте была филиальная структура, мы с фин. директором заказчика ездили по филиалам и внедряли программу — неделя в одном городе, неделя в другом. Но через некоторое время собственникам фирмы надоело постоянное отсутствие фин.директора, т.к. он нужен был в Москве. Было принято решение внедрять удаленно — через Skype. Скорость внедрения резко выросла, каждый день я переводил один филиал, а через пару недель мы отключили старую программу (это был RS-Balance)
Причины перехода на новую программу остались за рамками статьи, только вскользь было упомянуто про то, что старая программа больше не удовлетворяет потребности бизнеса. И если говорить про конкретный проект, то решение созрело и было принято бизнесом до меня, от меня требовалось только осуществить переход.
Цели написания статьи — показать новый способ внедрения, в противовес так называемому большому взрыву. Так получилось, что две одинаковые фирмы выполняли внедрение 1С практически одновременно. В одной выполнялось большим взрывом — т.е. с 1 января все пользователи перешли на новую систему. А в другой, где работал я со своей командой, управляемым взрывом — перевод по отдельным рабочим местам. Разница была в том, что первая фирма на месяц остановила отгрузки клиентам, т.к. оказалось что программа была местами не доработана, вторая фирма ни на день (и даже не на час) не прекращала свою работу. И вот хочется чтобы мой опыт пригодился…