Некоторые из наиболее эффективных конструкций, доступных в настоящее время для доказательства произвольных программ в нулевом знании безопасны только в АСБЕ model- на английском языке: Они требуют доверенного шага инициализации, на котором кто-то должен произвести некоторые магические числа, и если они обманывают (например, сохраняя начальная хаотичность) они могут дать ложные доказательства.

Системы с этими свойствами находятся в некоторых работах в http://www.scipr-lab.org/ И в http://research.microsoft.com/apps/pubs/default.aspx?id=180286, оба из которых в настоящее время используют системы, основанные на GGPR'12 криптосистемы. Они действительно потрясающую производительность, хотя- достаточно быстро, чтобы быть на самом деле целесообразно использовать на доказывающей, и почти как проверка в течение нескольких миллисекунд с нескольких сотен байт для доказательства независимо от размера программы доказанным или сколько времени занимает бежать. Но требование доверенного инициализации является неприемлемым для некоторых приложений. В конечном счете мы хотим системы, которые не зависят от доверенной инициализации, но они менее далеко вперед в развитии и никогда не может быть столь же эффективным.

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

Например, сказать, что я хочу, чтобы платить вам обусловливающие вы опубликовав решение a- сказать- головоломки Судоку. Скрипт работает под эффективным доказательством системы знаний может проверить зашифрованное решение, и потому, что с нулевым знанием шахтеры не могли прийти и заменить выходы, как в простой хэш автоподстройки транзакции. Вы можете использовать CRS Снарк здесь, где плательщик вычисляет доверенную инициализацию, а затем получатель не может cheat-, но тот факт, что плательщик инициализированного это означает, что плательщик может дважды провести гонку выкупа и получить как решение и их монету обратно.

Есть несколько способов решения, но я хотел бы упомянуть еще один, который особенно общее:

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

Это может быть дополнительно оптимизировано вместо требующего Person_A_snark&&Person_B_ECDSA_sig || Person_B_snark&&Person_A_ECDSA_sig ... Крест подпись с использованием ECDSA является более эффективной, так как Снарк доказательства больше (и гораздо медленнее, для вычисления), чем ECDSA подпись, и это в равной степени достигает цели, не позволяя ни одна из сторон, чтобы воспользоваться лазейкой. (В частности, если вы используете сжатие хеширования, чтобы избежать никогда даже не потрудившись публиковать верификатор, открытые ключи для филиалов неиспользованных).

Такой же подход может быть распространен на более чем двух сторон, хотя эффективность становится менее впечатляющей (например, испытатель должен запустить доказательство N-1 разы обращаться с любыми из сторон, возможно, в сговоре с ними, или N / 2, если вы хотите только честную безопасность большинства ) и, к сожалению, это не реально работать вещают оплаты виды применения.