ВЖИК и БЗИК

Гусь М:

Генерация – эт, конешна, хорошо. А никто не думал, что по этому поводу будут мыслить фискальные органы?

Кои есть в любой кстати стране...

А если работать чисто «вчёрную», то о каких-либо масштабах (тем паче мировых) и думать не стоит...

Господин М:

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

Господин К:

Не следует забывать, что цели у этих сетей кардинально противоположные. У файловой – тиражирование документа максимальное количество раз. У экономической – недопущение тиражирования обязательства.

Я не вижу возможности недопущения тиражирования, кроме как:

– материальный носитель (банкноты),

– централизация в доверенном месте (современные ЭПС).

Мудрый У:

На самом деле распределённная p2p денежная система не такая уж утопия. «Доверенных» мест может быть множество. Например, по принципу DNS. В предложенном мной варианте получается ещё и множество «эмиссионных центров». Подобного рода систему на самом деле сложно контролировать. Но можно, если сама система этого захочет. Плюсы и минусы для системы есть в обоих вариантах.

Господин К:

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

Мудрый У:

Не слишком ли рано мы уже на технические аспекты реализации перешли?

Тут надо разделить задачи:

1. Проверка неподдельности электронных купюр.

2. Недопущение многократного использования одной и той же купюры одним пользователем.

3. Проверка наличия обязательств у продавца.

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

Господин К:

Это не технические, это – концептуальные!

Вернёмся на шаг назад: можете перечислить все варианты, которые вам приходят в голову, применительно к ЭПС.

После этого опять возвратимся и определимся с моделью:

– полная децентрализация (как у налички),

– частичная децентрализация (как у сетей p2p или ДНС).

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

Взять хотя бы те же ДНСы. Разные провайдеры обновляют их в разное время и с разной периодичностью. При переносе сайта с хостинга на хостинг вполне может оказаться, что у одного пользователя новый сервер откроется через пару часов, а у другого ещё долгое время будет доступ к старому серверу.

Господин М:

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

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

Обязательства в этом мире эмитируются и принимаются на каждом шагу и далеко не только ЭПС. Ни о какой централизации речи нет. Единственное, что отличает ЭПС от остальных, это то, что они смогли построить эффективные механизмы учёта и контроля этих обязательств. Настолько эффективные, что эти обязательства стало возможным использовать в качестве средства платежа.

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

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

Система, в которой вместо 100 больших ЭПС крутится 100 000 маленьких, будет:

а) более устойчивой – вместо нескольких больших points of failure, множество мелких,

б) менее подвержена политическим рискам – меньше будет клиентов, созревших для государева контроля,

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

г) более, ничем принципиально отличаться от текущей ситуации, не будет (прошу обратить внимание на этот пункт).

Я последние пару лет в плане хобби поигрываюсь с дизайном такой системы, не паразитирующей на существующих ЭПС, пишу прототипы и пытаюсь самому себе доказать принципиальную неосуществимость этой идеи. Пока безуспешно.

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

Две стороны, доверяющие друг другу, открывают между собой расчётный счёт с начальным балансом 0 и устанавливают друг другу лимиты. Платежи между сторонами состоят в том, что обе они меняют состояние своего баланса на сумму платежа. При этом плательщик увеличивает свой баланс на сумму платежа, а получатель уменьшает на эту же сумму. Таким образом, суммарный баланс всегда 0.

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

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

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

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

Ну-те'с, поищем failure mode в таком варианте!

Господин K:

Тут одна огромнейшая дыра. Система на доверии и учёт балансов ведётся индивидуально.

Допустим, состояние системы изначально такое: А=0
Б=0
В=0

А передаёт 100 единиц к Б:
А=– 100
Б=100
В=0

Далее Б создаёт копию своего хранилища данных и возвращает транзакцию к А с одной из копий:
А=0
Б=0
В=0

Взаиморасчёты в этой копии с А полностью совпадают.

Со второй копии данных делает перевод к В:
А=– 100
Б=0
В=100

Легитимность данного перевода может быть проверена только в случае, если известны все корреспонденты Б. В таком случае Б связывается с каждым и «прозванивает» историю операций *– Б– *. В случае недоступости одного из корреспондентов перевод не осуществляется (а корреспондент мог в отпуск на полгода уйти, или вообще потерять доступ к своему механизму учёта). Ну и мысль можно развивать до бесконечности и в разных направлениях.

Господин М:

До пункта «Взаиморасчёты в этой копии с А полностью совпадают» всё верно, а дальше – нет. Б не может заплатить В те 100, которые ему заплатил А. Это разные счета. Точно также как я не могу напрямую заплатить e-gold-партнёру, который принимает только wmz. У участников этой сети есть не один общий счёт, в который в кучу сваливаются обязательства разных сторон, а по одному счёту с каждой стороной, с которой у него есть доверие (расчётный счёт). Поэтому В совершенно не интересует состояние баланса между А и Б, можно даже копию хранилища не делать. Его интересует только состояние взаимного счёта Б– В, копия которого у него есть всегда и он будет решать, принимать платёж или нет, исходя из состояния этого счёта. Состояние системы (балансы) удобнее описывать в виде пар: AB=X означает, что текущий баланс между A и B равен Х. Соответственно, баланс между В и А равен – Х.

Тогда исходное состояние:
A– Б = 0
Б– В = 0
В– А = 0

А передаёт 100 единиц к Б:
А– Б = – 100
Б– В = 0
В– А = 0

Б передаёт 100 единиц В:
А– Б = – 100 (Б– А = 100)
Б– В = – 100 (В– Б = 100)
В– А = 0

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

Товарищ А:

А не пошли ли они, эти самые фискальные органы, в одно место?

Когда я другу говорю, сделай мне забор, вот тебе пузырь водки, органов там не ночевало. Так почему они должны быть там, где им не место?

Господин К:

Ага. То есть все взаиморасчёты замыкаются в парах Х– У! Тогда это ещё хуже.

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

Если Б взял у А 100 рублей, чтобы заплатить за телефон оператору В, то он согласно этой схемы ничего не сможет сделать, так как взятые 100 рублей для него бесполезны в расчётах с другими корреспондентами.

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





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

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

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