an@sha (OP)
|
|
April 11, 2019, 11:05:11 AM Last edit: April 11, 2019, 11:20:09 AM by an@sha |
|
6. СтимулыВернуться к Оглавлению По умолчанию, первая транзакция в блоке является специальной, создающей новую монету, которая принадлежит создателю блока. Такая схема поощряет честных участников сети, стимулируя их поддерживать работу сети, а также решает вопрос о начальном распределении денежной массы в отсутствие центрального эмитента. Равномерное увеличение числа монет в обращении можно сравнить с добычей золота, в которую золотоискатели тоже вкладывают свои ресурсы. В роли последних в нашем случае выступают процессорное время и электричество. Другим способом стимулирования может быть комиссия за транзакции. Если входная сумма платежа больше выходной, то разница является комиссией за перевод и прибавляется к базовому значению награды за найденный блок в первой транзакции. Как только суммарный объем денежной массы достигнет заранее установленного максимума, единственным источником поощрения работы над блоками останутся комиссии, при этом избавленные от инфляции. Такая форма стимулирования может также способствовать уменьшению случаев мошенничества. Если жадный злоумышленник способен выделить больше вычислительных мощностей, чем все честные участники, он может обманывать продавцов, аннулируя свои транзакции и возвращая средства, или же направить свои ресурсы на генерацию новых блоков и монет. Более выгодным для него является вариант «игры по правилам», который обеспечивает получение более половины всех новых денег, чем вариант «саботажа системы» и поддержания своего капитала на постоянном уровне. 7. Экономия дискового пространстваВернуться к Оглавлению Как только последняя транзакция в монете-цепочке окажется внутри достаточно старого блока, все предшествующие ей транзакции в цепочке могут быть удалены в целях очистки дискового пространства. Чтобы хэш блока остался неизменным, все транзакции в блоке хранятся в виде хэш-дерева Меркла [7][2][5] и лишь его корень включается в хэш блока. Размер старых блоков может быть уменьшен за счет удаления ненужных ветвей этого дерева, хранить промежуточные хэши необязательно. Заголовок пустого блока будет составлять около 80 байт. Из расчета скорости генерации блока раз в десять минут получаем 80*6*24*365=4.2 Мб в год. Для среднестатистического на 2008 год компьютера с 2 Гб оперативной памяти с учетом закона Мура, предсказывающего рост на 1.2 Гб в год, хранение данных не будет проблемой, даже если все заголовки блоков будут находиться в памяти. 8. Упрощенная проверка платежейВернуться к Оглавлению Верификация транзакций возможна без запуска полнофункционального узла. Пользователю необходимо лишь хранить заголовки блоков самой длинной цепочки, которую он получил от других узлов, и запрашивать хэш-поддерево для необходимой транзакции. Он не может проверить корректность транзакции самостоятельно, но получив ссылку на блок, в котором она находится, он может убедиться в том, что этот блок и все последующие приняты и подтверждены сетью. На такой метод проверки можно полагаться, пока сеть хотя бы наполовину находится под контролем честных участников, то есть пока злоумышленник не завладеет большими ресурсами. Обычные узлы могут проверять транзакции самостоятельно, но если нападающий генерирует самую длинную цепь блоков, то своими сфабрикованными транзакциями он может скомпрометировать упрощенную схему. Одной из стратегий противодействия этому может быть рассылка сигналов тревоги от обычных пиров, которые получают «ложный» блок. Такой сигнал будет заставлять программу-клиент загружать блок полностью, чтобы самостоятельно подтверждать некорректность данных. Компании, часто принимающие платежи, возможно, будут подключаться к сети в обычном режиме для большей независимости, безопасности и быстроты проверки. 9. Соединение и разделение суммВернуться к Оглавлению Несмотря на то, что можно оперировать отдельными монетами, создавать специальную транзакцию для каждого цента было бы слишком неудобно. Для поддержки разделяемых и объединяемых сумм транзакции содержат несколько входов и выходов. Обычная транзакция будет выглядеть так: либо один вход от предыдущего крупного платежа, либо несколько входов, аккумулирующих небольшие суммы, и не более двух выходов: один является собственно платежом, а другой, если необходимо, возвращает «сдачу» обратно отправителю. Необходимо отметить, что увеличение связей, когда транзакция зависит от нескольких, а те в свою очередь зависят от еще большего числа, не является проблемой, поскольку нет необходимости получать полную и независимую копию истории транзакции. 10. КонфиденциальностьВернуться к Оглавлению Традиционная банковская модель поддерживает необходимый уровень конфиденциальности, предоставляя доступ к информации лишь сторонам-участницам и доверенному третьему лицу. Необходимость открытой публикации транзакций исключает такой подход, однако приватность по-прежнему можно сохранить, если публичные ключи будут анонимными. Открытой будет информация о том, что кто-то отправил кому-то некоторую сумму, но без привязки к конкретным личностям. Столько же данных раскрывается и на фондовых биржах, которые публикуют время и объем частных сделок, не указывая, между кем именно они были совершены. Дополнительной защитой будет являться генерация новой пары «открытый/закрытый ключ» для каждой транзакции: это предотвратит связывание различных платежей с их общим отправителем или адресатом. Некоторого публичного связывания все же не избежать: транзакции с несколькими входами доказывают, что эти суммы принадлежат одному лицу. Риск состоит в том, что раскрытие личности владельца ключа может привести к раскрытию и всех принадлежащих ему транзакций. 11. ОценкаВернуться к Оглавлению Рассмотрим сценарий, в котором злоумышленник пытается генерировать более длинную цепь блоков, чем честные участники. Даже если он преуспеет, это не приведет к тому, что можно будет создавать деньги из воздуха, присваивать себе чужие монеты или вносить иные произвольные изменения. Узлы никогда не примут некорректную транзакцию или блок, ее содержащий. Атакующий может лишь пытаться изменить одну из своих транзакций, чтобы возвратить себе деньги. Гонку между честными участниками и нападающим можно представить как биномиальное случайное блуждание. Успешное событие, когда «хорошая» цепь удлиняется на один блок, приводит к увеличению отрыва на единицу, а неуспешное, когда очередной блок создает злоумышленник, — к его сокращению. Вероятность атакующего наверстать разницу в несколько блоков такая же, как и в задаче о «разорении игрока». Представим, что игрок имеет неограниченный кредит, начинает с некоторым дефицитом и у него есть бесконечно много попыток, чтобы отыграться. Вероятность того, что он преуспеет, как и вероятность злоумышленника догнать честных участников, вычисляется следующим образом [8]:
p = вероятность появления блока в честной цепочке q = вероятность того, что блок создаст атакующий qz = вероятность того, что атакующий наверстает разницу в z блоков В случае p > q вероятность уменьшается экспоненциально с ростом числа блоков, на которое отстает злоумышленник. Поскольку все ставки против него, без удачного рывка в начале его шансы на успех становятся ничтожно малы. Рассмотрим теперь, как долго получателю платежа стоит ждать, прежде чем он будет полностью уверен, что бывший владелец не сможет отменить транзакцию. Мы предполагаем, что злоумышленник-отправитель позволяет адресату некоторое время верить, что платеж был проведен, после чего возвращает деньги себе. Получатель узнает об этом, но мошенник надеется, что будет уже слишком поздно. Адресат создает новую пару ключей и сообщает свой публичный ключ отправителю прямо перед подписанием транзакции. Это не позволит отправителю заранее начать работать над цепочкой и провести транзакцию в тот момент, когда он будет достаточно удачлив, чтобы совершить рывок вперед. После отправки платежа мошенник начинает втайне работать над параллельной версией цепочки, содержащей альтернативную транзакцию. Получатель ждет, пока транзакция не будет добавлена в блок и пока тот не будет продолжен еще z блоками. Ему неизвестен прогресс злоумышленника, но если средняя скорость генерации честных блоков — известная величина, то число блоков нападающего подчиняется распределению Пуассона с математическим ожиданием: Код программы на языке Си выглядит так: #include <math.h> double AttackerSuccessProbability(double q, int z) { double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; } Запустив программу, мы видим, что вероятность экспоненциально падает с ростом z: q=0.1 z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006 Решая относительно P < 0.1%, получаем: P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340 12. ЗаключениеВернуться к Оглавлению В данной работе нами была предложена система электронных транзакций, не основанная на доверии. Построение схемы началось с традиционного представления монет на основе цифровых подписей, обеспечивающего контроль владения, но допускающего двойную трату. Эту проблему мы решили посредством пиринговой сети и схемы «доказательства работы» для записи публичной истории транзакций. Попытка злоумышленника, не обладающего большей частью ресурсов сети, изменить старые записи, вычислительно становится практически неосуществимой. Сильной стороной сети является простота ее структуры. Все узлы работают самостоятельно, иногда обмениваясь информацией. Нет необходимости в идентификации, поскольку сообщения не идут по какому-то определенному маршруту, а основе принципа «наименьших затрат». Узлы могут покидать сеть и вновь подключаться, принимая самую длинную цепочку блоков как подтверждение пропущенной истории транзакций. Они выражают свое согласие принять корректный блок в цепочку, используя свои вычислительные мощности для удлинения этой цепи, или несогласие (если блок содержит неверные данные), не продолжая эту цепочку. Любые необходимые правила протокола могут быть реализованы через данный механизм голосования. Список литературыВернуться к Оглавлению[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998. [2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999. [3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991. [4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993. [5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. [6] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002. [7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980. [8] W. Feller, "An introduction to probability theory and its applications," 1957.
|