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]
Через обмін цифрових жетонів RPOW нагадує eCash. Однак в описаній початковій системі приватність не забезпечували сліпим підписуванням. Фінні покладався на зашифроване з’єднання безпосередньо із захищеною платою та на перевірну програму, яка не зберігала зв’язків між виданими й отриманими жетонами. Комп’ютер-хост не мав бачити їхнього відкритого вмісту. Утім, він міг спостерігати мережеву адресу клієнта, час і обсяг обміну даними. Повторне подання того самого жетона також дозволяло пов’язати деякі події. Збережена документація вже описує підтримку 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.