Reusable Proofs of Work, сокращённо RPOW, — экспериментальная система Хэла Финни, превращавшая доказательства вычислительной работы Hashcash в передаваемые цифровые жетоны. Каждый жетон можно было лишь один раз обменять на указанном сервере, то есть в сервисе, обрабатывавшем запросы пользователей. При этом получатель получал новый жетон с той же вычислительной стоимостью. Правильность обменов должны были защищать плата IBM 4758 и удалённая проверка исполняемой программы. Это не была децентрализованная сеть или биткоин.
15 августа 2004 года Хэл Финни пригласил участников почтовой рассылки по криптографии попробовать свой новый эксперимент. Он опирался на Hashcash Адама Бэка: компьютер перебирает разные входные данные, пока не найдёт результат, отвечающий заданному условию. Поиск занимает вычислительное время, а проверить готовый результат можно быстро. Такое доказательство называют Proof of Work — доказательством работы. В борьбе со спамом оно может служить почтовой маркой, оплаченной вычислениями. Финни интересовало, можно ли затем передавать доказательство между людьми, вместо того чтобы исчерпать его пользу одним применением. Именно это означает RPOW: многократно используемые доказательства работы. [1] [2] [4]
Представим, что у Анны есть действительный цифровой жетон и она отправляет его Петру. Если она передала только файл, то могла сохранить копию. Поэтому Пётр предъявляет жетон серверу RPOW и просит обменять его. Сервер проверяет, что жетон ещё не использован, помечает его как израсходованный и подписывает новый, подготовленный программой Петра. Копия старого жетона у Анны больше не пройдёт обмен. Пётр может отправить новый Еве, которая повторит процедуру. Значит, повторно используется передаваемая стоимость, а не один и тот же вечно действительный файл. Пока получатель успешно не завершит обмен, отправитель ещё может потратить исходный жетон раньше него. [2] [11]
На входе мог быть только что вычисленный Hashcash или ещё не использованный жетон RPOW. На выходе появлялся новый жетон с цифровой подписью RSA — математически проверяемым подтверждением сервера. RSA — способ вычисления такой подписи: её создают секретным ключом подписи, а проверяют соответствующим открытым ключом. Это проверяемые числовые данные, а не изображение рукописной подписи. Подпись позволяла проверить происхождение жетона, но сама по себе не сообщала, обменял ли его уже кто-то. Для этого служил учёт использованных входов. При следующих передачах не требовалось заново выполнять трудоёмкий поиск Hashcash: новую подпись получали в обмен на аннулирование старого доказательства. Это не повторное использование электричества и не способ бесплатно размножить требования на ранее выполненную работу. [2]
Стоимость здесь означала уровень вычислительной сложности, а не цену в кронах или долларах. Тогдашний Hashcash использовал SHA-1 — функцию, создающую короткий числовой отпечаток данных, — и искал отпечаток с заданным числом начальных нулевых битов. Бит — один двоичный разряд. Каждый дополнительный требуемый ноль примерно удваивает среднее число попыток. Поэтому жетон уровня 21 представлял ту же ожидаемую работу, что два жетона уровня 20, и мог делиться на них. При объединении и разделении должна была сохраняться сумма этой вычислительной стоимости. Но это не устанавливало фиксированный курс и не гарантировало покупательную способность: более быстрые компьютеры могли создавать тот же вид жетонов дешевле. [2] [10]
Double spend означает двойную трату одной и той же стоимости. Против неё RPOW требовался список уже обменянных доказательств. Вся база находилась не внутри защищённой платы: её хранил обычный компьютер-хост. Плата сохраняла контрольный отпечаток состояния базы и при запросах проверяла криптографические доказательства. Использовался принцип Merkle Tree — дерева отпечатков, позволяющего проверить часть данных относительно одного общего отпечатка. Нужно было обнаруживать не только изменение записей, но и возврат к старой базе, где ещё нет только что потраченного жетона. Без такой защиты оператор мог бы многократно превращать один вход в новые жетоны. [3]
Операции, требующие защиты сервер выполнял внутри IBM 4758 — самостоятельной вычислительной платы в обычном компьютере. Она должна была защищать ключи подписи и важные для безопасности данные даже от владельца этого компьютера. При обнаружении физического вмешательства плата могла стереть секретные данные. Компьютер-хост передавал сообщения и хранил базу, но проект не считал его доверенным. В этом и состояло решение Финни: управление сервером не должно давать оператору возможность произвольно создавать жетоны. Однако защита зависела от исправного оборудования, корректной программы и сохранности ключей. Это не было безусловным обещанием невзламываемости. [3] [9]
Одной публикации исходного кода недостаточно: оператор может показывать одну программу, а запускать другую. Поэтому RPOW использовал remote attestation — удалённое подтверждение конфигурации. Плата предоставляла подписанные сведения о выполняемой программе. Желающий мог собрать опубликованный код соответствующими инструментами и сравнить отпечаток полученного образа программы с заявленным. Сравнивался не просто текст исходного файла. Доверие к подписям шло по цепочке сертификатов до ключа IBM. Это помогало проверить, какая программа действительно запущена, но не доказывало отсутствие ошибок и не гарантировало безупречность производителя или его процедур сертификации. [3] [9]
Обмен цифровых жетонов напоминает eCash, но изначально описанная система RPOW не защищала приватность слепым подписыванием. Финни полагался на зашифрованное соединение до защищённой платы и проверяемую программу, которая не сохраняла связи между выданными и полученными жетонами. Компьютер-хост не должен был видеть их открытое содержимое. При этом он мог наблюдать сетевой адрес клиента, время и объём обмена данными. Повторное предъявление одного жетона тоже позволяло связать некоторые события. Сохранившаяся документация уже описывает поддержку Tor — сети, которая проводит соединение через несколько промежуточных узлов и скрывает от сервера исходный сетевой адрес пользователя. Слепое подписывание, напротив, представлено как возможное будущее дополнение. Эту запланированную функцию не следует считать частью описанного тогда режима работы. [8] [10]
RPOW не остался предложением на бумаге: у него были работающий сервер и доступная клиентская программа. Но Финни с самого начала предупреждал о ранней пробной версии. Необходимое изменение серверной программы могло сделать ранее выданные жетоны недействительными. Проект предназначал их для личного, экспериментального и некоммерческого использования, а не как деньги с гарантированной стоимостью. Даже защищённая плата не могла заставить оператора держать сервер включённым. Исходный проект завершён; сохранившиеся страницы и код служат историческими материалами. Описание тогдашних SHA-1, RSA и оборудования не является рекомендацией для создания современной платёжной службы. [1] [4] [5] [7]
Финни хотел показать на практике часть идеи Bit Gold Ника Сабо: создание цифрового предмета может требовать затрат, после чего его можно передавать. Документация RPOW предусматривала и сотрудничество нескольких серверов, поэтому сводить весь проект к навсегда единственному компьютеру было бы упрощением. Однако конкретный жетон указывал сервер, на котором его следовало обменять; дополнительные машины сами по себе эту зависимость не устраняли. Bitcoin выбрал другой путь. Независимые узлы — компьютеры с программой проверки — контролируют общие правила и публичную историю. Майнеры соревнуются за добавление следующих допустимых блоков: наборов транзакций, связанных с предыдущей записью. RPOW помогает понять, почему одного Proof of Work ещё недостаточно: надо также решить, как все распознают допустимый порядок переводов и кому при этом должны доверять. [1] [6] [11]
Для полной картины прочитайте эту статью вместе с Hal Finney, Adam Back, Hashcash, Nick Szabo, Bit Gold, Proof of Work. На эту статью также ссылаются b-money, Bit Gold, Hal Finney.