ВЖИК и БЗИК

Мудрый У:

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

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

Потенциально, и интернет-провайдер может «жульничать», подменив 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 раза хранить. Причём таким образом, что если одна из трёх записей пропала, и при условиях «никому не доверяю», эту запись можно было бы восстановить.





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

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

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

пища для ума
почитать и переварить


рекомендуем
на правах рекламы







GSM-сигнализация, Покер, Выставки в Италии, Лечение пародонтита, Раскрутка сайта, Изготовление pos-материалов, Металлочерепица, Разработка сайта, Оборудование для бассейнов, Тонировка автомобилей, Женское бельё, Продажа газосиликатных блоков, Доводчики, Где купить очки?, Курсы английского языка, Керамический гранит, Заказать переезд, Доставка по Москве, Минитракторы, Расходные материалы, Volkswagen, Подшипники, Бетонные полы, ЧОП, Автошколы с медкомиссией и фотографом, Ответы на все вопросы про автошколу, Выгода от приобретения жилья в восточных странах, Современные панели, Качественные услуги по проведению переезда, Достоинства профнастила кровельного перед другими типами профиля, Коммерческая недвижимая собственность, Удивительное рядом - уникальные фотообои на ваших стенах, Необходимость фасовки продуктов в эффектную упаковку, Оригинальные копии знаменитых живописцев, Модные тренажеры для всех, Декор различных помещений при помощи вагонки , Новейшие средства для ухода за инвалидами, туры оаэ, отдых в италии, экскурсионные туры в чехию, отдых в тайланде, отдых в китае, создание сайтов беларусь, отдых в греции, перевозки груза, инструктор вождения, отдых вьетнам, загранпаспорта, стоимость оптимизации сайта