Нижеприведенный текст — перевод одного поста на reddit, который к моему удивлению, остался практически незамеченным. Автор рассказывает, как он работал над созданием биткойна в качестве одного из участников коллектива, и даже если он немного преувеличил свой вклад, его рассказ кажется мне очень правдоподобным. Ознакомление с его историей кажется мне полезным в любом случае, потому что описывает технические решения, использованные в первой криптовалюте, в их взаимосвязи и раскрывает логику выбора именно этих решений.
Доброго времени суток всем.
Сегодня — восьмая годовщина публикации описания протокола Биткойна. В качестве особой дани памяти я предлагаю вам короткую историю возникновения этой технологии.
Я вышел из игры на многие годы, но сейчас я снова втянут обратно — отчасти под влиянием вовлеченных лиц, отчасти благодаря информации, которая стала общедоступной в течение последнего года. Я не следил за развитием Биткойна и альткойнов в течение последних пяти или шести лет. Я вышел из проекта за шесть месяцев до Номера 2.
Мой последний разговор с Номером 2 был 5 лет назад и он закончился тем, что я удалил всю рабочую переписку и надолго исчез. Любое упоминание Биткойна заставляло меня перевернуть страницу, переключить канал, уйти с сайта из-за причиняющего боль комка страха, возникающего в моем животе при любом упоминании этой технологии.
Я записываю все так, как мне вспоминается, и похоже, из этого может получиться довольно приличная книга о возникновении Биткойна.
Здесь вы найдете некоторые из этих записей. Пока это черновые наброски, их компоновка и последовательность может поменяться. Учтите также, что первоначальный релиз кода и документации Биткойна охватил лишь часть более ранних идей. Это означает, что какие-то идеи из описанных ниже не стали достоянием общественности.
# Введение
Я всегда видел, что между знанием и пониманием лежит большая пропасть.
Куда бы я ни посмотрел, я натыкался на очень умных ребят, обладающих исключительными знаниями в своей области, но не имеющих ни малейшего представления о том, как их применять, использовать и как создавать что-то новое. Они могли лишь последовательно повторять одно и то же для совершенствования своих знаний в данной области. А понимание приходит из опыта за пределами ограниченной области знаний.
Эта история о самом уникальном проекте и понимании, которое было применено к проблеме «электронной наличности», что и привело к эксперименту под названием «Биткойн».
Я пытаюсь показать течение мысли, поток рассуждений, споров, примеров, сомнений и страхов, который проходил сквозь наши умы, пока мы сражались с этим чудовищем и старались выковать что-то, что реально работает. Здесь нет никаких подтверждений правдивости этой истории. Нет абсолютно никаких доказательств, что я действительно принимал участие в этом проекте. Все доказательства были уничтожены в конце 2011 — причина станет ясна позже.
Только Номер 2 должен был знать о моем участии в проекте (до сих пор, имеется в виду). Воспринимайте это как художественный вымысел, если хотите.
Кто я? В сети я был известен под ником Scronty.
Я интересовался компьютерами и электроникой с 11 лет. Смотрел, что заставляют делать эти машины другие, и старался сделать немного больше.
Когда я сталкивался с какой-то проблемой, я всегда начинал с того, что на данный момент о ней известно — как ни крути, но все мы стоим на плечах тех, кто был здесь до нас. Довольно часто я обнаруживал, что предположения, которых придерживался народ по поводу данной проблемы, были именно тем, что мешало им обнаружить новое ее решение. Я начинал подвергать сомнению базовые предположения по разным предметам:
Что если это не так?
Если бы этого не существовало, то как его можно было бы заменить?
Обычно результатом было только занудство всех этих знающих парней.
«Так это всегда и было».
«Это лучший способ сделать это».
«Все эти звания после моего имени означают, что я прав, а ты нет».
«Так написано в книге, рекомендаций которой я придерживаюсь».
«Все цитируют этого человека, должно быть, он прав, — так что я тоже его процитирую».
Ну, вы поняли.
Вы можете наблюдать подобное на любом форуме с середины девяностых. Также вы можете легко встретить самовлюбленных умников, которые свысока смотрят на окружающих и принижают их своими знаниями в теме, которую сами выучили только неделю назад.
В частности, все это справедливо и по отношению к программистским и крипто форумам.
# Начало
Пара ребят работали с онлайн-казино. У них была проблема.
Для того, чтобы игроки могли воспользоваться их сервисом, они должны были предоставить информацию о банковской карте и заплатить за игровые фишки-токены. Однако, часто игроки начинали играть, проигрывали все свои деньги, а затем откатывали платеж, утверждая, что он не авторизован и это платили не они.
А иногда сеть компании некорректно обрабатывала перевод, средства списывались с аккаунта игрока, но на стороне компании не появлялось никаких записей об этом, игрок не получал никаких игровых токенов, и опять же, пытался откатить платеж. Крупные компании, выпускающие кредитные карты, запрещали их использование в азартных играх онлайн и начали запрещать такие отмены платежей.
Этим парням был нужен способ перемещать средства между игроками и казино так, чтобы все могли быть уверены в честности происходящего. Чтобы платеж нельзя было сделать по ошибке, и если он сделан, нельзя было бы его отменить.
Номер 2 участвовал в группе шифропанков с середины девяностых годов. Когда я присоединился к проекту в начале 2008 он работал над этой проблемой, совмещая эту работу с другими проектами, на протяжении последних пяти лет, в течение последнего года или около того он работал над этим проектом фуллтайм.
Он написал white paper, описывающий систему электронной наличности, которую могло использовать онлайн-казино (и лицензировать эту систему другим компаниям), плюс писал соответствующий код. Он пытался реализовать работающий пример электронной наличности.
Были другие криптографы, с которыми он общался на эту тему, но все это «просто не работало». Всегда было множество векторов атаки на описываемое решение и, хотя с криптографической точки зрения white paper и код были приемлемы, он считал их неудовлетворительными. После разговора со своим другом Номером 3 они подумали о том, что возможно дело в том, что у них глаз замылился и они должны обсудить свои идеи с кем-то, кто не был криптографом.
Проблема была в том, что найти подходящего человека было непросто. Он должен был быть достаточно умным чтобы понимать криптографию (или быть способным ее изучить), заинтересоваться предметом, но еще не быть криптографом. Обычно ребята, которые достаточно умны для этого и которым это интересно, — уже криптографы.
Через разные IRC каналы Номер 3 вышел на меня и свел меня с Номером 2. Своей работой в рамках сообщества Win32.Asm я показал, что достаточно умен и могу находить решения сложных задач. Плюс мой публичный профиль показывал, что я оставался в рамках серо-белых тем, не был связан с азартными играми онлайн.
# Просьба о помощи
Меня попросили взглянуть на white paper и сказать, что там нужно изменить, так как реализующий его код просто не работал — его части не сочетались друг с другом, или все в целом переставало работать, если в сети не соблюдались определенные предварительные условия. Номер 2 хотел опубликовать документацию до конца года (2008).
Я начал читать документ — понимая очень немного. Хэширование, шифрование и дешифрование, и публичные ключи, и приватные ключи. Разные типы алгоритмов хэширования, шифрование, а затем хэширование, хэширование, а затем шифрование… О, Боже!
Просто скажи мне, что я должен поменять, чтобы все заработало
— продолжал спрашивать меня Номер 2.
Да я вообще не понимаю, что за [censored] я читаю
— отвечал я.
Номер 2 решил, что он ошибся и ему нужно попробовать поискать кого-то другого. Я сказал ему, что ему нужно применить другой подход.
Что нужно изменить?
— спросил он.
Так, для начала мне следует понимать, что я вообще читаю. Так что дайте мне информацию про все эти крипто-штуки
— сказал я.
Не-не-не, если ты выучишь этот крипто-жаргон, ты попадешь под его влияние и больше не будешь тем «не-криптографом», который нам нужен для проверки white paper.
Я сказал ему, что без изучения этого жаргона я вообще не смогу прочитать этот документ. А еще — что по мере того, как я буду учиться, я смогу говорить ему, что именно нужно поменять. А если и когда это дойдет до стадии, в которой я выучил слишком много и мой глаз тоже замылится, тогда я смогу выйти из проекта и он сможет найти кого-то еще мне на замену. Он согласился, что позволить мне немного поучиться криптографии может быть хорошей идеей (:roll-eyes:) и велел мне приступать.
Я спросил, где мне взять информацию. Он ответил:
Погугли.
Не. Ты работал в этой области в течение нескольких последних лет, так что ты можешь дать мне ссылки на сайты с нужной инфой.
Он вернулся со списком ссылок и сказал мне просмотреть их и прочитать white paper. В списке было 104 ссылки — [сеnsored].
Шаг за шагом я начал продираться через эту информацию. Через несколько недель я разобрался с полудюжиной статей/сайтов, которые ничего для меня не прояснили. Как-то по истечению трех или четырех недель я в отчаянии сказал ему:
С такой скоростью я провожусь с этим весь год и так и не пойму все до конца. Ты должен отфильтровать эту информацию для меня. Ты уже читал все эти документы и сайты, так что дай мне список самых важных, которые помогут мне в понимании white paper.
Он вернулся со списком из приблизительно 23 пунктов.
Теперь перечисли их в том порядке, в котором мне нужно их прочитать.
Он дал мне отсортированный и отфильтрованный список крипто-документов и сайтов, который я и начал читать с самого начала.
# Транзакции
Возьмем компьютерную сеть, в которой транзакции должны отправляться получателю. Первоначальный вариант white paper был в большой степени смесью разных криптографических white paper о электронной наличности того времени. Мы знали, что когда кто-то хочет послать платеж другому человеку, информация о нем должна надежно распространиться по всей сети. Но как разрешить проблему повторной траты одних и тех же средств?
Кусочек бумаги, являющийся бумажной наличностью, может быть только в одном месте в каждый момент времени — вы не сможете дважды потратить физическую банкноту. Все существовавшие тогда системы электронной наличности полагались на центральный сервер в вопросе контроля распределения монет и в том, что никакие монеты не будут потрачены дважды.
Но если этот сервер упадет или будет недоступен из-за DDOS’а или действий правительства (или кто-то просто споткнется о шнур питания) — все, нет никаких денег.
Мы знали, что монеты изначально должны быть как-то созданы. Я обнаружил, что большинство методов «чеканки монет», описанных в документах и на сайтах были чушью (это личное мнение, никакого неуважения к тем, кто писал все эти документы). Они либо собирались действовать как центральные банки, либо собирались позволить “клубу друзей”, в котором все согласны друг с другом, решать, кто получит монеты в этот раз.
Как политики, которые используют «независимую» третью сторону для повышения выплат себе. Мы знали, что кусочек электронной наличности должен быть как-то создан, но после того, как он создан, как отправить его кому-то? Номер 2 и я метались между несколькими идеями, исследуя обработку различных типов транзакций один за другим и подстраивая под них то, как должен выглядеть пакет с данными о транзакции.
Мы начали с единственного кусочка электронной валюты. Как кусочек золота, он должен позволять отщеплять от себя более мелкие части. Это означало, что от одного кусочка мы переходили к двум — части, которая отправлялась получателю, и сдаче, которая возвращалась исходному владельцу. Я сказал Номеру 2, что будучи нарисованными в виде диаграммы, это выглядит как электронные или компьютерные логические элементы.
Исключая те случаи, когда выходов больше, чем входов. И тогда это выглядит как нейронные сети.
Если у нас был большой кусок и мы отправили все это количество кому-то, то вход и выход должны быть равны. Если у нас был большой кусок и мы отправили кому-то меньшее количество монет, тогда на входе у нас этот большой кусок, а на выходе — отправленное количество плюс небольшой кусок как сдача. По мере того, как мы платим все большему количеству людей, мы будем получать много маленьких кусочков в нашем кошельке.
Если в этой ситуации мы должны заплатить кому-то большое количество, мы можем объединить много маленьких кусочков так, чтобы получилось количество равное или больше того, что мы должны заплатить, и вернуть себе необходимое количество как сдачу. Это означает, что транзакция должна позволять иметь много входов и много выходов, каждый вход подписан текущим владельцем, а выходы — это публичные ключи новых владельцев.
Однажды он сказал мне, что его друг Номер 3 хочет пообщаться со мной напрямую, но он — супер-параноик, так что я должен шифровать все свои сообщения ему с использованием публичных/приватных ключей.
Это был [censored] кошмар. Я должен был:
Все это было нужно для того, чтобы убедиться, что сообщение действительно было от меня, и оно не было перехвачено или подменено.
Затем он решил, что я должен генерировать новые публичный/приватный ключи для каждого нового сообщения на случай того, что прошлое сообщение было перехвачено. Я сказал Номеру 2, что такого не будет. Мне никогда не нравилось использовать программы из командной строки, я всегда думал, что они должны исполняться из графического интерфейса. Я сказал:
Ты будешь моим фильтром в этом проекте и главным каналом в этой команде. Я шлю письма тебе, ты обсуждаешь это с кем тебе нужно и присылаешь мне их ответы. Или ты присылаешь мне их запросы, и я через тебя отвечаю. И что это за надоедливая софтинка из командной строки? Какого [censored] она вообще делает?
Номер 2 дал мне ссылку на информацию — она была в исходном списке из 109 документов/сайтов и отсутствовала в отфильтрованном списке из 23 пунктов.
Это была ссылка на сайт Hal’а, где он очень понятно объяснял, как работает нечто под названием “Hashcash” — Hals RPOW. Оттуда я перешел на сайт Adam’а Hashcash (которого вообще не было в исходном списке). Я читал документацию по Hashcash пока не добрался до раздела с расчетами и дальше читать не смог.
# Hashcash
Я прочитал несколько первых разделов и понял, что это было что-то интересное. Я спросил Номера 2, может ли он проверить, что это была последняя версия, и не было ли там каких-то улучшений/исправлений/апдейтов. Он ответил, что я зря трачу на это время и что я должен продолжить чтение других документов/сайтов из списка, которой он мне дал.
Я сказал ему, что мне виднее, какая информация важна и мне нужно ознакомиться с Hashcash. Он вернулся через пару дней и сказал, что убедился, что опубликованный документ и есть последняя версия.
Я спросил, как он в этом убедился? Он ответил, что обратился к автору сайта Hal’у и попросил у него последнюю версию, и Hal прислал ту же ссылку. Он даже скопировал ответ Hal’а в письме ко мне.
Погоди-ка… Что? … Ты действительно обратился к автору документа?
Ну да. К кому еще обращаться, если не к автору?
Я рассказал ему, что это — большая редкость, когда кто-то проверяет источники и общается с авторами. Большинство читает что-то и воспринимает это как факт, или видит ссылку и воспринимает ее как факт. Если кто-то читает об алгоритме поиска Boyer-Moore’а, он воспринимает как факт то, что он читает последнюю официальную версию этого алгоритма.
Я не слышал о том, чтобы кто-то связывался с Boyer’ом или Moore’ом чтобы узнать, нет ли каких исправлений/улучшений/апдейтов. Алгоритм поиска Boyer-Moore’а обсуждался в то время на форуме Win32Asm сообщества.
Меня это заинтриговало. Даже с учетом иногда раздражающей манеры Номера 2 было очень полезно иметь кого-то, готового выяснять что-то у авторов материала, как в этом случае. Я спросил его, связывался ли он с автором Hashcash, и он ответил, что посылал письма каждому автору всех документов/сайтов из списка, но ответили ему только около десятка или типа того.
Я начал записывать, какие проблемы возникают при попытке создания системы электронной наличности на основе других систем электронной наличности из документов, которые я изучил. Я все еще ссылался на white paper, который Номер 2 дал мне изначально, но это была лишь беспорядочная смесь того, что делали другие на протяжении многих лет. Вот почему снова ничего не получалось, как и у других.
Одной из проблем была доверенная метка времени, нужная, чтобы люди могли знать, что средства не были потрачены дважды. Другой проблемой была «чеканка монет» в системе и доверие к «чеканящему центру».
Насколько я помню, каждый white paper до тех пор (включая выданный мне) использовал доверенную третью сторону как источник меток времени и сложные методы для того, чтобы убедиться, что эти метки не были подделаны.
Чеканка также использовала либо доверенную третью сторону для генерации монет на регулярной основе, либо сеть узлов, договаривающихся о том, как много сгенерить токенов и раздать их всем остальным.
Номер 2 сказал, что мы должны использовать доверенную третью сторону, иначе как еще мы можем быть уверены в метках времени и чеканке токенов.
Я сказал, что он неверно думает об этом.
Ты исходишь из того, что нам нужна доверенная третья сторона, просто потому, что любая статья по криптографии говорит о том, что это делается именно так. Но ты также говоришь, что не можешь полагаться на доверенную третью сторону, потому что это создает «точку отказа» с соответствующим вектором атаки, которая может уронить всю систему.
Помнишь Шерлока Холмса, который говорил: исключите все невозможное и то, что останется, каким бы невероятным оно ни казалось, будет правдой? Для того чтобы система работала, использование доверенных третьих сторон должно быть исключено. Если мы не можем их использовать, то как нам сделать то, что нужно?
Понятия не имею. Ты думаешь, что этот proof-of-work, который ты изучаешь, как-то может быть для этого использован?
— ответил Номер 2.
Не знаю. Определенно, какие-то возможности для этого у него есть. Он используется, чтобы убедиться, что отсылаемые и получаемые данные исходят из известного доверенного источника и они не были подменены.
Не знаю. Определенно, какие-то возможности для этого у него есть. Он используется, чтобы убедиться, что отсылаемые и получаемые данные исходят из известного доверенного источника и они не были подменены.
Этот алгоритм заставляет компьютер пользователя генерировать хеши данных, чтобы найти хеш с заданным количеством нулей в начале. Если хеш не найден, программа увеличивает значение в данных и снова вычисляет хеш. Это повторяется пока нужное значение не будет найдено. Это означает, что компьютер пользователя тратит какое-то время на работу над этими хешами и останавливается только когда найдет нужный.
Этот алгоритм был разработан для того, чтобы справиться с проблемой почтового спама, с которой все мы сталкивались: спамер должен использовать большое количество вычислительных ресурсов для того, чтобы сгенерировать хеши для всех рассылаемых писем (хешируемые данные включают адрес получателя, так что на каждого получателя нужен отдельный хеш). Этот процесс может управляться так, что сложность генерации хеша может увеличиваться со временем по мере развития и роста вычислительной мощности железа.
Проблема чеканки чем-то похожа на это, поскольку электричество, используемое для генерации хешей, может использоваться для чеканки электронной наличности и запуска этих монет в обращение. Фактически получается, что то, сколько наличности дается конкретному чеканщику определяется выставленным ему счетом в реальных деньгах (за потребленное электричество).
Это также определяет цену добытых монет, так как существует прямая зависимость между счетом за электричество в реальном мире и количеством отчеканенных монет. Взяв время, потраченное на генерацию хешей, количество энергии, потребленной процессором во время этой генерации (только во время генерации хешей, а не каких-то других вычислений), а также местную стоимость электричества в данной местности/области/стране, в которой расположен чеканщик, получим адаптированное к местности количество электронной наличности, которое будет добавлено на его счет.
Это означало, что кто-то, добывающий монеты в местности с дешевым за счет государственной поддержки электричеством должен был получить меньше электронной наличности, потому что потратил меньше реальных денег на генерацию хешей. Таким образом, у нас появился механизм, на основе которого могла работать эта электронная наличность.
Я остановлю здесь этот рассказ и продолжу его в зависимости от реакции на эту публикацию. В продолжении будут некоторые детали того, как возникла идея цепочки блоков, плюс некоторые идеи, которые остались за пределами оригинальной white paper и первоначального кода (прежде всего это был лишь первый эксперимент для проверки работоспособности концепции).
# Небольшое дополнение
Если вы перечитаете оригинальную Bitcoin white paper, то части Introduction, Calculation, Conclusion и References были написаны и отредактированы Номером 2 и Номером 3. Разделы Transactions, Timestamp Server, Proof-of-Work, Network, Incentive, Reclaiming Disk Space, Simplified Payment Verification, Combining and Splitting Value и Privacy были скопированы из писем от меня к Номеру 2, объясняющих, как должна работать каждая часть по мере того как мы находили эти решения.
Я написал текст раздела Abstract, когда Номер 2 попросил меня написать Introduction. Номер 2 использовал его как Abstract потому что решил, что он слишком короткий для введения. Номер 2 и Номер 3 отредактировали весь документ и удалили из него все двойные пробелы, добавили заголовки разделов, отредактировали от 2% до 5% текста, исправляя грамматические ошибки и улучшая читаемость. Вы можете прочитать исходный текст раздела Abstract с встречающимися двойными пробелами здесь: Public Mailing-list Posting
Между нами присутствовало серьезное недопонимание в процессе составления white paper, о котором я расскажу в следующий раз.
Ваш Phil (Scronty)
источник: https://geektimes.ru/post/285802/
