История криптовалют. Биткойн-детектив - страница 31
Образец договора может выглядеть следующим образом:
K_A соглашается отправить K_B решение некоторой задачи до 01.01.2000.
K_B обязуется оплатить K_A 100 MU (денежные единицы) до 01.01.2000. K_C
принимает решение провести арбитраж в случае возникновения спора. K_A соглашается оплатить максимум 1000 MU в случае дефолта. K_B обязуется оплатить максимум 200
MU в случае дефолта. K_C обязуется оплатить максимум 500 MU в случае умолчанию.
4. Завершение (conclusion) договоров. Если договор успешно выполнен (завершился без спора), каждая из сторон передает подписанное сообщение «Контракт с SHA-1 хэш H завершился без возмещения ущерба». В ином случае: «Контракт с SHA-1 хэш H завершен со следующими неустойками: ***». При получении всех сигнатур (подписей), каждый участник системы возвращает обеспечение на счета каждой из сторон, удаляет учетную запись контракта и начисляет на счет (или списывает со счета) каждого участника контракта сумму в соответствии с договором.
5. Принудительное завершение (enforcement) контрактов. Если стороны договора не приходят к соглашению даже с помощью арбитра, каждая сторона передает свои предложения по штрафным санкциям (распределению обеспечения) и какие-либо аргументы или доказательства. Все участники (Each participant) выносят определение о том, как следует распорядиться обеспечением, и соответственно изменяют счета».
Второй протокол был еще короче:
«Счета участников не хранятся каждым из них самостоятельно, но на некоторых серверах, связанных широковещательным каналом. Формат операционных сообщений в этом случае остается тем же, что и в первом протоколе, но заинтересованным участникам каждой транзакции следует проверять случайно выбранное подмножество серверов, что сообщение ими было получено и успешно обработано.
Необходим какой-то механизм, обеспечивающий доверие к серверам, например, потребовать от каждого сервера внести определенную сумму на специальный счет, который будет использоваться для штрафов или вознаграждений. Кроме того, каждый сервер должен периодически фиксировать и публиковать текущее состояние баз данных по собственникам и эмитентам (создателям денег). Каждый участник должен иметь возможность проверить, что его собственные остатки на счетах верны, и что сумма остатков на счетах не превышает общую сумму созданных денег. Это предотвращает возможность для серверов, даже в сговоре, постоянно и без издержек увеличивать денежную массу. Опубликованные базы данных могут быть использованы для синхронизации новых и существующих серверов.
Протокол, предложенный в этой статье, предоставляет средства обмена и способ исполнения контрактов анонимным лицам, и тем самым позволяет сотрудничать друг с другом более эффективно. Протокол, вероятно, может быть сделан более эффективным и безопасным, но я надеюсь, что это является шагом в переводе идей крипто-анархии на практику».
Приложением к протоколам шло описание способа создания электронных денег b-money:
«Одной из наиболее сложных задач протокола является создание денег. Эта часть протокола требует, чтобы все участники принимали согласованные решения о стоимости конкретных вычислений. К сожалению, из-за быстрого развития технологий информация о ней не всегда общедоступна, может быть неточна или устаревшей, все это порождает серьезные проблемы.
Я предлагаю альтернативный подпротокол создания денег, в котором количество денег, создаваемых за период, и цена их создания определяются не согласованием между участниками (всеми – в первом протоколе, или только серверами – во втором), а на аукционе. Каждый период создания денег делится на четыре фазы, а именно: