ВЖИК и БЗИК

Мудрый У:

Мы обсуждаем уже, какие именно могут быть способы «сжульничать», и как технически реализовать противодействие этим способам. Хотя ещё не до конца уяснили, что именно мы создаём и для какий целей.

Если учесть то, что жульничать могут все стороны, включая центры проверки подписей и эмиссионные центры. Мало того, жульничать могут ещё и в сговоре между собой, ещё и все одновременно.

Потенциально, и интернет-провайдер может «жульничать», подменив ip-адрес сайта банка на фишинговую страницу. И бумажные деньги тоже подделывают.

Найти потенциально «слабое место» у системы намного проще, чем придумать на 100% защищённую электронную денежную систему. Но, опять же – «нет задачи, с которой не мог бы справиться человек с высшим образованием»!

Можете перечислить все варианты, которые вам приходят в голову, применительно к ЭПС?

Перед тем как мы начнём обсуждать подобные вещи, мне хотелось бы обсудить именно концепцию и цели подобной системы.

Можно усложнить задачу, например можно эмитировать «вжики» под обязательства услуги или товара, которых ещё нет.

Например, я хочу построить дом на 100 квартир. Для этого нужно отдать:
500 р на взятки за разрешения,
200 р архитектору,
100 р рабочему,
и т. п.
Итого 1000 р (условно).
Стоимость 1-ой квартиры – 20 р.
Чтобы построить этот дом и заработать 1000 р (20 * 100 = 2000) нужно изначально иметь 1000 р.

Теперь представим, что я эмитировал «вжики» и заплатил ими чиновнику, архитектору, рабочему... Они могут либо дождаться окончания строительства и обменять на готовую квартиру (получив 200 вместо 100), либо сразу потратить эти «вжики» в любом другом «магазине», который их принимает. Таким образом, если мне доверяют, что дом я дострою в срок, то я могу его построить, не имея начального капитала.

Господин К:

Это всё здорово, но вам с М надо сначала между собой согласовать всё, а после этого предлагать варианты мне, а то у вас разные концепты...
Ваш – частичная централизация (контролирующие сервера).
Его – полная децентрализация.

С файлообменной сетью разрывы не являются критичными, так как там одни и те же данные растиражированы множество раз, и чем больше раз – тем надёжнее.

Допустим, у нас есть 10 серверов. Во время атаки между серверами оборвалась связь, но на каждом из серверов пользователи совершили несколько транзакций. Как после этого события синхронизровать данные? А что если один из пользователей совершит транзакцию на сервере А, а потом повторит на сервере Б, имея слепок данных со старой информацией? Естественно, за тот период времени, пока сервера А и Б будут полностью изолированы от других.

Мудрый У:

А кто говорил, например, что транзакции должны быть моментальными???

Господин К:

Обсуждаются именно слабые места механизмов, а не програмного решения.

А для чего нужны деньги? Универсальный эквивалент учёта стоимости. Чтобы не менять два шила на три мыла, но не факт, что один из контролирующих серверов умышленно не исказит данных. В криптологии такое обычно решается выбором третьего лица, которому доверяют участники сделки. Например: сервер ВМТ, на котором хранятся все транзакции, Центры сертификации, подписывающие цифровые сертификаты.

Сложность подделки бумажных денег несравнимо выше, чем организация ДдоС-атаки, для перегрузки интернет-канала, или создание копии хранилища данных.

если мне доверяют, что дом я дострою в срок, то я могу его построить не имея начального капитала.

- По идее так и получается. Просто в реальности вы бы использовали чужие фантики, а не свои. И чужие имеют больше доверия, так как их потратить можно всюду.

По поводу мгновенности транзакций…Сервера можно перегружать дольше, чем пару минут. Например, из-за землетрясения где-то в Азии, почти вся Азия была отрублена от инета, кажется на несколько дней.

Да и честно говоря, задержка в сроке платежа должна чем-то компенсироваться. В банковской системе это компенсируется, например, распространённостью самой системы и, видимо, простотой использования. Так, я бы с радостью всюду платил/принимал ВМ, если бы все корреспонденты (в т. ч. и в Европе) могли платить/принимать ВМ.

Учитывая, что система будет не с моментальными платежами и срок задержки из-за непредвиденных загрузок, скорее всего, не будет регламентирован, то скорее всего система не сможет существовать, распространившись за пределы сообщества (где все всем доверяют).

Мудрый У:

Нужно чем-либо пренебречь. Например, возможностью «сжульничать», хотя бы кого-нибудь одного, либо возможностью «жульничать» всех одновременно и в сговоре.

Первый вариант – понятно.

Второй вариант: каждый сервер, перед тем как становится доступным для проверок, синхронизирует данные. Для успешного завершения транзакции случайным образом выбираются 10 серверов из тысячи, и у каждого запрашивается подпись. Подобным способом производится и синхронизация (т. е. подменить данные на одном из серверов недостаточно для успешной синхронизации с этого сервера).

И последнее: чтобы использовать «чужие фантики», их нужно сначало где-то купить! «А у нас денег нет», как говорил Кот Матроскин.

Господин K:

Вот это-таки довольно непростая задача, сильно увеличивющая нагрузку. Так, в централизованной системе используется один главный сервер транзакций. В децентрализованной, тысячи, каждый из них в то же время должен содержать актуальные данные.

Допустим, данные обновляются путём отправки пакета (условно). Тогда:
– пользователь отправляет пакет с инфой о транзакции на один/десять серверов. (На этом в централизованной системе трафик бы закончился).
– децентрализованная система начинает отправлять пакеты с каждого из серверов на все остальные, для синхронизации. В итоге получается, что на одну транзакцию в системе будут загружены 1000 серверов точно тем же объёмом работы, что и в централизованной один сервер.

Как бы выглядит всё хорошо на первый взгляд, если не вдаваться в технические детали, раз уж договорились. Но когда дойдёт до технической реализации, проблемы не заставят себя долго искать. Хотя бы взять во внимание нагрузку каждого контролирующего сервера, соразмерную с нагрузкой одного единственного сервера централизованной системы.

Мудрый У:

Только трафик возрастает не в число серверов в квадрате, а просто в число серверов. Суммарное число запросов может не увеличиться, а даже сократиться (теоретически), соответственно и нагрузка. Но это только в случае если мы делаем распределённую p2p-систему. И это плата за p2p. В «не денежных» p2p-системах тоже много «лишнего» трафика.

Вообще, я не сторонник именно концепции p2p, я просто показал один из вариантов, что теоретически это возможно.

Господин К:

В п2п этот «лишний» трафик как раз выполняет функцию, для которой он и предназначен – тиражирование файлов по клиентам.

На уровне абсолютного доверия (что я считаю утопичным) возможно всё, любой механизм взаимодействия, в противном случае надо иходить из уровня абсолютного недоверия или крайне избирательного доверия.

Господин М:

Позвольте крамольный вопрос – а факт ли, что один из существующих контролирующих серверов (e-gold, WMT, etc) умышленно не искажает данные? Что им это «мешает» сделать? Ничего, кроме нашей святой веры, что они это не делают. Вопрос снова и снова упирается в доверие. А если кто им не верит, то он голосует ногами – просто не пользуется их сервисами.

Вообще, в криптографии есть такое понятие как необходимый уровень заговора (required conspiracy). Минимальное количество кидал, которое необходимо для того, что нарушить протокол. И есть протоколы, которые специально разрабатываются с целью, обеспечить минимально необходимый уровень заговора, например 3.

Один из примеров такого протокола приведён выше.

Так вот, в существующих системах необходимый уровень заговора – 1. Захочет завтра e-gold «умышленно исказить данные» – обнулить у вас баланс на счёте и всё. И сделает это в одностороннем порядке и никакой заговор не нужен.

Всё правильно – точно так же, как взяв 100 e-gold у своего друга, вы вряд ли заплатите ими за свой телефон. Взятые 100 e-gold бесполезны в расчётах с другими корреспондентами, с теми, которые его не принимают. (Я буду всё время приводить аналогии с существующим положением дел, чтобы было с чем сравнивать и от чего отталкиваться).

У нас сейчас есть кучка относительно замкнутых систем учёта (ЭПС), внутри (!) которых обязательства гуляют напрямую. И есть кучка шлюзов между этими системами (обменники), которые конвертируют эти обязательства между системами.

Правильное допущение, В (MTC) не знаком с Б (e-gold ltd), поэтому доверия нет. Поэтому мы ищем Г, у которого доверие есть и к В, и к Б. Называется он «обменный пункт» или «сервис пополнения телефонных счетов». Суть в том, что он выступает в качестве шлюза, который принимает обязательства с двух сторон.

И так же верно, что В никогда не будет платить Б напрямую. Но так же и верно, что В будет платить своим поставщикам, а те своим и в конце концов деньги, тем или иным способов вернутся обратно к В. Заметим, что я описываю не гипотетическую, а реальную ситуацию – круговорот бабла в природе.

Все транзакции полностью не должны дублироваться на всех серверах. Кроме очевидной неэффективности этой схемы, есть ещё и очень серьезные возражения конфиденциального плана.

Каждый сервер (репозиторий) хранит у себя только транзакции своих пользователей. А транзакции каждого пользователя с каждым из его корреспондентов, кроме того, дублируются на их серверах. Таким образом, каждая транзакция хранится всего два раза. Грубо говоря, это RAID 5, а не RAID 1.

И искусственно синхронизировать ничего не надо. Плательщик отсылает платёж получателю, получатель возвращает квитанцию, оба регистрируют транзакцию в своих журналах и обновляют свои балансы. Всё. Больше никому, кроме них, до этого нет дела.

Кстати, никто не обещал, что возникновение новой валюты будет простым! Это технические проблемы и решаются они техническими же средствами, коих у нас, слава Богу, предостаточно. При реализации системы маршрутизации ip-пакетов в децентрализованной сети с негарантируемой работоспособностью маршрутизаторов и каналов связи, проблемы тоже не заставили себя долго искать. И ничё. Порешали.

Господин К:

Я был подготовлен к замечаниям. Что мы имеем в текущих системах:

– централизованный процессинг, которому предлагается доверять при регистрации и до использования системы. То есть: «есть сомнения – не пользуйся».

Что мы имеем в распределённой:
– пары взаимоотношений, где изначально ни между кем не существует доверия.
Наши варианты:
– полная децентрализация.
– – – в этом случае между каждой парой участников возникает проблема поиска третьей стороны, которой они доверяют.
– частичная децентрализация.
– – – в таком случае возникает вопрос: что делать, если я доверяю Серверу 1, но не доверяю Серверу 2? Как обеспечить надёжную синхронизацию в таком случае? А если я Хакер, и запустил свой Сервер Х, которому только и доверяю?
Вообще с этим описанием я не могу сразу несогласиться, всё вроде выглядит хорошо и прицепиться не к чему.

ПС. Беру таймаут на обдумывание.

Господин М:

Нет доверия – нет взаимоотношений. Точно так же, как в случае с централизованной системой.

В редких случаях доверие будет прямым, тогда посредник не нужен, но вообще говоря, в большинстве случаев нужен посредник – и порой не один, – если нет такой одной стороны, которой они оба доверяют.

Ситуация один в один как и сейчас. Нет у нас «централизованной» системы. Я уже приводил пример с e-gold и WMT. Пока ты крутишься в пределах одной системы и расплачиваешься её обязательствами с теми, кто их принимает – проблем нет. Всё автоматизировано. Но, как только пользователю e-gold нужно заплатить пользователю WMT, вот тут-то и «возникают проблемы поиска третьей стороны», которой они доверяют. А зачастую и не одной, если напрямую валюты поменять нельзя, то приходится искать нескольких посредников и менять их по цепочке.

Сейчас эта процедура ручная (ну там пошёл на мониторинг, сравнил курсы, резервы и т. д.). А я предлагаю автоматизировать передачу обязательств между разными эмитентами точно так же, как некоторые эмитенты автоматизировали передачу своих обязательств (ЭПС) и конвертацию одних обязательств – в другие (обменщики).

Чтобы, грубо говоря, имея e-gold, можно было заплатить wmz, а система автоматически нашла бы цепочку посредников, в которой каждый доверяет следующему (и не более) и провела всю транзакцию.

Мудрый У:

Э-э-э... Чтоб отдалённо напоминать RAID 5, надо хотя бы 3 раза хранить. Причём таким образом, что если одна из трёх записей пропала, и при условиях «никому не доверяю», эту запись можно было бы восстановить.





Продолжение обсуждения проекта ВЖИК и БЗИК.

Вернуться назад, на предыдушую страницу.

Вернуться в "Проекты и проектики".