Такой дизайн возможен, у него есть свои преимущества и недостатки (везде есть свои trade-offs).
Сконструировать proof, что он постил транзакции не по порядку, достаточно легко — нужно предъявить обе транзакции, подписанные его приватным ключом.
Но главное, что независимо от принципов выбора провайдеров порядка, они могут влиять лишь на порядок, и то косвенно, но не могут помешать кому либо добавлять свои транзакции в реестр.
Грубо говоря, да.
«получение сетью», как вы понимаете, это нечёткая формулировка, потому что сеть состоит из множества нод, каждая из которых получает транзакцию и добавляет в свой реестр в разное время.
А получатель так считать не может, он должен быть уверен, что транзакция не инвалидируется.
Конечно, одного факта, что транзакция произошла, мало. Получатель предпочтёт дождаться финализиции порядка этой транзакции (если не готов брать на себя риски).
А есть какие-то оценки для этого? Вероятностные, например. Я. как получатель транзакции должен знать когда могу относительно безопасно отправить свой товар покупателю.
Получатель увидит в своей копии реестра, что порядок данной транзакции финализировался. Обычно это происходит в течение нескольких минут после появления транзакции в реестре, при этом время уменьшается при увеличении нагрузки на сеть. На explorer.obyte.org (который имеет свою копию реестра) можно видеть статус транзакции, нужно дождаться когда он станет stable (final).
вторая транзакция упорядочится после первой, следовательно, будет помечена как double-spend. То, что она ссылается на позавчерашние транзакции — не имеет значения.
Да, мы должны быть достаточно уверены, что выбранные участники будут действительно
— создавать транзакции
— создавать их упорядоченно
Это непросто, потому что многие из них могут быть оффлайн, и надо понимать, что они теряют, если постят неупорядоченно (они ведь анонимны?).
Также, необходимо гарантировать, что «случайным» выбором нельзя манипулировать, в распределённых реестрах это непростая проблема.
Если половина или большинство (т.е. 6 из 12, если их 12) провайдеров порядка перестанут постить, то будет невозможно определить порядок недавних транзакций, хотя они и будут добавляться в DAG. Не зная порядок, нельзя быть 100% уверенным что в случае появления double-spend он не упорядочится раньше той транзакции, которую мы уже видим.
Мотивация с жестко выбранным числом 12 не кажется достаточно обоснованной. Да, это не единая точка отказа, но и не N участников сети, как в существующих открытых блокчейнах.
12 это одна из немногих произвольных констант в данном дизайне. Можно выбрать например 25 или 7 и запустить другую сеть с другим числом провайдеров порядка.
Ну и в целом, начинать вайтпейпер с отсылки к 1984, а затем оперировать списком доверенных сущностей — как-то иронично, что ли…
Что именно иронично?
Важно чётко понимать, о каком именно доверии идёт речь, что именно мы верим относительно доверенных сущностей, верим слепо или рационально, просто доверяем или доверяем-но-проверяем. В «1984» речь идёт о переписывании истории. В DAG это просто невозможно из-за снежного кома транзакций, ссылающихся на каждую запись, и принципа неудаляемости прошлых записей. Это правила протокола, «доверенные сущности» не в силах на них повлиять.
Эта область быстро развивается, и описанный способ выбора провайдеров порядка не является единственно возможным. Как бы вы выбирали их (псевдо)случайно?
Подскажите, как определяется момент, когда транзакцию можно считать случившейся?
когда автор транзакции добавил её в реестр и сообщил о ней в сеть.
Когда она точно не инвалидируется? В биткоине это правило 6ти блоков, а здесь?
Когда её порядок станет окончательно определён. А это случится когда провайдеры порядка добавят «достаточно много» (сколько точно, зависит от формы DAGа в каждом конкретном случае) своих транзакций после вашей. Они должны добавлять свои транзакции строго последовательно, поэтому не смогут добавить их к старой части DAGа, что могло бы изменить порядок.
Проще всего это понять на сети с одним провайдером порядка — тогда все прошлые транзакции, которые включены (прямо или косвенно) в его последнюю транзакцию, уже упорядочены.
она упорядочится рядом с другими транзакциями, которые были транслированы в сеть примерно в то же время. Вот недавний пример такой транзакции explorer.obyte.org/#xLo0zDsHEnV2B4siCtqygxkTJy8jhVkSAv44d+cD3NE= (смотрите на main chain index — это индикатор порядка)
И как выбирается транзакция, чтобы прописать ее в качестве предыдущей? что просто берется из p2p сети? ай ай ай, вот зломышленник разверачивает проверяющие ноды количеством в половину сети, и вот он уже определяет какие транзакции проходят а какие нет!
Каждая нода, когда посылает свою транзакцию, самостоятельно выбирает одну или несколько родительских (предыдущих) транзакций. Экономически выгодно выбирать тех родителей, у которых ещё нет дочерних транзакций.
Что от того, что у злоумышленника проверяющих нод в половину сети? Если вы считаете, что видите вектор атаки, но пока непонятно, поясните.
Так же не имеет смысла играть против того, кто централизованно принимает решение, пропускать транзакций или при держать секунду
Верная мысль, как раз в DAG нет никого, кто мог бы пропускать, не пропускать или задерживать транзакции, нет блок продюсеров в принципе, поэтому DAG хорошо подходит для таких игр и финансовых приложений.
Вопрос не относится к данной статье, но похоже, что вы, как и многие, совершаете очень распространенную ошибку — применяете шаблоны, работающие в блокчейнах, к другой архитектуре, в которой те же шаблоны не обязательно имеют тот же смысл.
Валидаторов не 12, каждая полная нода является валидатором и чтобы стать валидатором, нужно всего лишь запустить полную ноду. Доступ в реестр абсолютно открытый и равный для всех, в этом смысл выбора DAG. Никакого PoA нет, более того — никакого proof-of тоже нет, снова неприменимый шаблон. Вы правильно указали на EOS как доказательство степени контроля, который блок продюсеры имеют над сетью, в Obyte никто не решает о допуске или не-допуске транзакции, никто не может остановить добавление транзакции в реестр.
А транзакций в секунду теперь 30, что по-прежнему мало. Но есть решение, о котором мы ещё не объявили.
Деривативы это действительно тема для которой хорошо подходит DLT. Пространство для фантазии огромное, для реализации новых продуктов нужны всего лишь данные и токены, которые есть на DLT, а регуляторные ограничения неприменимы к автономным агентам, у которых нет владельцев.
Однако во всех задачах, что мы решали, до сих пор удавалось обходиться без циклов. Деривативы это обычно токены с конечным сроком обращения. Держатель посылает токен на AA и получает что-то в обмен. Каждый держатель делает это сам отдельной транзакцией, циклы не нужны.
С купонами сложнее (хотя купоны относятся к бондам, не к деривативам). Можно прибавлять купоны к стоимости бонда и выплачивать при погашении. Соответственно, накопленный купонный доход будут учитываться в текущей цене бондов, по которой они торгуются на рынке. Другой вариант, если хочется выплачивать купоны не дожидаясь погашения, это предложить держателям хранить их на специальном AA, с которого держатель может в любой момент вывести купоны, накопленные с момента предыдущего вывода.
Сконструировать proof, что он постил транзакции не по порядку, достаточно легко — нужно предъявить обе транзакции, подписанные его приватным ключом.
Но главное, что независимо от принципов выбора провайдеров порядка, они могут влиять лишь на порядок, и то косвенно, но не могут помешать кому либо добавлять свои транзакции в реестр.
«получение сетью», как вы понимаете, это нечёткая формулировка, потому что сеть состоит из множества нод, каждая из которых получает транзакцию и добавляет в свой реестр в разное время.
Конечно, одного факта, что транзакция произошла, мало. Получатель предпочтёт дождаться финализиции порядка этой транзакции (если не готов брать на себя риски).
Получатель увидит в своей копии реестра, что порядок данной транзакции финализировался. Обычно это происходит в течение нескольких минут после появления транзакции в реестре, при этом время уменьшается при увеличении нагрузки на сеть. На explorer.obyte.org (который имеет свою копию реестра) можно видеть статус транзакции, нужно дождаться когда он станет stable (final).
— создавать транзакции
— создавать их упорядоченно
Это непросто, потому что многие из них могут быть оффлайн, и надо понимать, что они теряют, если постят неупорядоченно (они ведь анонимны?).
Также, необходимо гарантировать, что «случайным» выбором нельзя манипулировать, в распределённых реестрах это непростая проблема.
12 это одна из немногих произвольных констант в данном дизайне. Можно выбрать например 25 или 7 и запустить другую сеть с другим числом провайдеров порядка.
Что именно иронично?
Важно чётко понимать, о каком именно доверии идёт речь, что именно мы верим относительно доверенных сущностей, верим слепо или рационально, просто доверяем или доверяем-но-проверяем. В «1984» речь идёт о переписывании истории. В DAG это просто невозможно из-за снежного кома транзакций, ссылающихся на каждую запись, и принципа неудаляемости прошлых записей. Это правила протокола, «доверенные сущности» не в силах на них повлиять.
когда автор транзакции добавил её в реестр и сообщил о ней в сеть.
Когда её порядок станет окончательно определён. А это случится когда провайдеры порядка добавят «достаточно много» (сколько точно, зависит от формы DAGа в каждом конкретном случае) своих транзакций после вашей. Они должны добавлять свои транзакции строго последовательно, поэтому не смогут добавить их к старой части DAGа, что могло бы изменить порядок.
Проще всего это понять на сети с одним провайдером порядка — тогда все прошлые транзакции, которые включены (прямо или косвенно) в его последнюю транзакцию, уже упорядочены.
Да, вы описали обычную для p2p сетей попытку изоляции ноды от остальной сети.
Каждая нода, когда посылает свою транзакцию, самостоятельно выбирает одну или несколько родительских (предыдущих) транзакций. Экономически выгодно выбирать тех родителей, у которых ещё нет дочерних транзакций.
Что от того, что у злоумышленника проверяющих нод в половину сети? Если вы считаете, что видите вектор атаки, но пока непонятно, поясните.
Верная мысль, как раз в DAG нет никого, кто мог бы пропускать, не пропускать или задерживать транзакции, нет блок продюсеров в принципе, поэтому DAG хорошо подходит для таких игр и финансовых приложений.
Валидаторов не 12, каждая полная нода является валидатором и чтобы стать валидатором, нужно всего лишь запустить полную ноду. Доступ в реестр абсолютно открытый и равный для всех, в этом смысл выбора DAG. Никакого PoA нет, более того — никакого proof-of тоже нет, снова неприменимый шаблон. Вы правильно указали на EOS как доказательство степени контроля, который блок продюсеры имеют над сетью, в Obyte никто не решает о допуске или не-допуске транзакции, никто не может остановить добавление транзакции в реестр.
А транзакций в секунду теперь 30, что по-прежнему мало. Но есть решение, о котором мы ещё не объявили.
Однако во всех задачах, что мы решали, до сих пор удавалось обходиться без циклов. Деривативы это обычно токены с конечным сроком обращения. Держатель посылает токен на AA и получает что-то в обмен. Каждый держатель делает это сам отдельной транзакцией, циклы не нужны.
С купонами сложнее (хотя купоны относятся к бондам, не к деривативам). Можно прибавлять купоны к стоимости бонда и выплачивать при погашении. Соответственно, накопленный купонный доход будут учитываться в текущей цене бондов, по которой они торгуются на рынке. Другой вариант, если хочется выплачивать купоны не дожидаясь погашения, это предложить держателям хранить их на специальном AA, с которого держатель может в любой момент вывести купоны, накопленные с момента предыдущего вывода.