Хотелось бы уделить внимание тому,что новый класс блокчейнов, который включает Ethereum и Algorand, обрабатывает платежи по-разному из устаревших блокчейнов. В этих новых цепочках для подтверждения новых платежей, участникам протокол согласия не требуется для поиска и проверки прошлых платежей. Скорее им нужно только сохранить и обновить небольшое количество информации, а именно: текущий баланс каждого ключа в системе.Блокчейн, который так работает, — это основанная на балансе чёрная цепь (BBB).
Разные BBBs могут иметь разные согласованные протоколы. Например, Эфириум в настоящее время основанный на доказательстве работы, в то время как тот из Algorand основан на чистом доказательстве о ставке. Но независимо от их согласованный протокол, Algorand, Ethereum и все остальные BBBs могут проверять новые платежи и быть RTBF
В любом BBB пусть B будет самым последним блоком, вы — участник согласованного протокола, а PK — открытый ключ.
Тогда, по определению, вы знаете текущий баланс PK, balpK. То есть она знает, что количество деньги, доступные для PK, — это balpK, после всех платежей в цепочке, включая платежи в блоке B,
были выполнены. (В других BBB вы можете знать balpk, постоянно отслеживая цепочку из начала, или получая balPK из источника, которому она доверяет. В Альгоранде у вас есть доказуемый способ узнать правильное значение balpK в любом блоке.)
Предположим теперь, что выдан RTBF-запрос на удаление личной информации I платежа P = (M, I) в предыдущем блоке A. Затем сама u может удалить I из любой копии BBB, которую она может
иметь. Такое стирание может помешать ей (или любому, кто делает то же самое) доказать другим, что денежный перевод М действительно произошел в блоке А. Тем не менее, эта неспособность к доказательству не меняется сумма денег, в настоящее время доступная для PK. Это тот случай, независимо от того, был ли PK плательщиком или нет
Получатель платежа в P. Таким образом, вы знаете, что после удаления личной информации I of P текущий баланс PK продолжает оставаться balpk.
Соответственно, чтобы проверить, все ли платежи, сделанные PK в недавно предложенном блоке C, действительны, вам нужно
только убедитесь, что сумма всех сумм денег, которые PK переводит через свои платежи в C, не превышать baIpK, если C добавлен в цепочку, то вы обновляете баланс, доступный для PK, и баланс любого
другие открытые ключи, делающие или получающие платежи в C. То же самое верно для текущего баланса любого открытого ключа в системе.
В итоге BBB могут успешно обрабатывать запросы RTBF о платежах,обратите внимание, что на каждом блоке баланс данного ключа включает не только сумму в национальной валюте
доступные для него, но также и стабильные монеты и все другие грибные и нематериальные активы, которыми владеет ключ.
Проблема с сбалансированными блокчейнами
BBBs может успешно выполнять запросы RTBF о платежах по следующим простым причинам: (a)остатки собирают важную информацию, необходимую для обработки будущих платежей, (б) остатки не содержат личную информацию и не зависят от запросов RTBF, и, следовательно, (с) остатки могут быть правильно сохраняться, даже если запросы RTBF требовали удаления всех прошлых платежей.
Однако BBB не могут успешно выполнять запросы RTBF о транзакциях данных, потому что данные транзакции также могут быть взаимозависимыми, и потому что нет ничего, эквивалентного балансу для общих данных. То есть трудно выделить в компактной части информации, что важно в целом последовательность общих операций с данными. Таким образом, если личная информация I в транзакции данных T:(D, l) должны были быть удалены в ответ на запрос RTBF, данные D автоматически перестали бы аутентифицированными, с потенциально катастрофическими последствиями для будущих транзакций данных, которые должны иметь зависимость от D.
Решение Algorand
Право одного человека заканчивается, когда начинается право другого. RTBF является важнейшим правом. Но доверие генерируемое действительно распределенной цепочкой блоков, также вызывает большой общественный интерес. Было бы жаль отказаться от последнего при защите первого. Можем ли мы сохранить их обоих? Да, в самом деле.
Децентрализованный блокчейн работает благодаря усилиям двух категорий пользователей:
1. Участники консенсуса, которые проверяют новые транзакции и генерируют новые блоки.
2. Поставщики информационных услуг, которые дают обычным пользователям доступ к информации, хранящейся в
уже сгенерированные блоки.
(Обычные пользователи могут просто заключать сделки, сохранять сами сгенерированные блоки, если они того пожелают, или запрашивать поставщики информационных услуг о данных, хранящихся в цепочке, когда они им нужны.)
Algorand позволяет участникам консенсуса и поставщикам информационных услуг соблюдать RTBF без каких-либо недостатков, для себя, блокчейн или экосистемы в целом.
Основная идея в двух словах
Algarand отделяет стираемые данные от не стираемых и гарантирует целостность данных после удаления.
Блокирует, отдельно сохраняя (и никогда не стирая!) хэш любых стираемых данных.С этой целью Algorand изменяет традиционную структуру блоков и транзакций.
Структура сделок в алгоранд
По сути, Algorand вводит два новых связанных, но отдельных поля транзакций: стираемое поле и случайное поле. Первый позволяет хранить информацию E, которая может быть удалена позже.
и вторая случайная строка, R, которая помогает удалить E, если необходимо позже,без нарушения остальной информации, X, транзакция может содержать. Стираемое(соответственно, случайное) поле транзакции может быть пустым, в этом случае E = 0
(соответственно R = 0). Соответственно, транзакция T всегда может быть записана как
T = (X, E.R).
Как мы будем утверждать, X продолжает надежно храниться в блокчейне, независимо от каких-либо возможные RTBF запросы. Мы называем X важной информацией о транзакции T.
Мы называем транзакцию T = (X, E, R) RTBF честной, если вся личная информация, которая может быть стертой только появляется в E, а RTBF — нечестно в противном случае. Честные пользователи выпускают исключительно RTBF-честные сделки.
Блочная структура Альгоранда
Для блока Algorand В, — = (BDi, BHi),
o BDi продолжает включать последовательность транзакций блока,
T1 = (X11E11R1) 1 ->. Tn = (X71: En: Rn)
вместе с подписями их эмитентов. Единственное изменение в формате транзакции.
- BHi включает в себя для каждой транзакции T} = (X), E}, Rj) в блоке два хэш-значения
Ответ Algorand на запросы RTBF
Предположим, что RTBF-запрос сделан относительно RTBF-честной транзакции Tj: (Xi! Ej, R1) в предыдущем блок В. Затем, в ответ на такой запрос, участник консенсуса или информационная служба
провайдер заменит (XI-, Ej, RI) на X, — в своей собственной копии BDi, то есть она будет стирать Ej и R} из данных блока BDi;
Продолжит хранить X] — в 3D; и
Продолжит сохранять (I115. Hj) в заголовке блока HB ,.
Теперь предположим, что сделан запрос RTBF о нечестной транзакции RTBF 7 ‘]. Затем в ответ по такому запросу участник консенсуса или поставщик информационных услуг удалит все транзакции Ti в своей собственной копии 8D , но продолжает хранить (hr, hi) в заголовке блока HBi.
(В любом случае, узнав о запросе RTBF о 7), честный обычный пользователь, который происходит
Хранить блок Б, — сама, может действовать таким же образом.)
Обсуждение
Обратите внимание, что заголовки блоков Algorand не зависят от запросов RTBF. Действительно, новые заголовки блоков
продолжают генерироваться по мере роста цепочки, но оставаться неизменным и фактически неизменным один раз генерируются.
Пока транзакция T] = (XI’EI ‘RI) в блоке B не подлежит запросу RTBF,
неизменность всего Tj, включая E, и RJ, продолжает гарантироваться блокчейном.
Фактически, учитывая (Xi, Ej, Rj), можно сначала вычислить хеш-значение 17 = H (EI-, Rf), затем хеш-значение
H (X] -, v) и, наконец, убедитесь, что они совпадают с двумя значениями хеша h; и h, — надежно хранится в
заголовок блока BHir
Если RTBF-запрос сделан относительно RTBF-честной транзакции 7 “, -: (XI-, Ej, Rf) в блоке 8 , то только подлинность существенной информации X} — продолжает гарантироваться блокчейном. По факту, как только запрос сделан, E] — и R1 »удаляются из данных блока BDi, но не Xj. Не является пара значений хеша (h; hj) удалена из заголовка блока 3H ,. Таким образом, для проверки подлинности X], один получает пару (h’v, hj) из BHi, вычисляет значение хеш-функции H (X] -, hj’v) и проверяет, что полученный результат действительно совпадает со значением hi .
Если сделан запрос RTBF о нечестной транзакции RTBF T1 = (Xj, Ej, RI) в блоке В , то, как уже было сказано, весь T1- удаляется из данных блока BDi. Если TJ- это платеж, то его удалениене влияет на другие платежи в цепочке, поскольку Algorand основан на балансе. Но iij были данные транзакция, значимость последующих транзакций данных, которые полагаются на важную информацию Tj X, — может быть скомпрометировано. Таким образом, если эмитент T — не является вредоносным, то в ее интересах обеспечить
что T] — транзакция RTBF-hanest.
В RTBF-честной транзакции T = (X, E, R) случайность значения R гарантирует более высокий уровень соответствия RTBF. Чтобы убедиться в этом, предположим, что случайная строка R не использовалась,чтобы все транзакции T и блочные заголовки BH имели форму
T = (X, E) и BH, = (H (BH, »_ 1), (v ‘, v), WAD),
где v ‘= H (E) и 17 = (X, 12 ’). Предположим теперь, что E непосредственно идентифицировал известного человека: для
Например, пусть E 2 «Билл Гейтс», затем, в ответ на запрос RTBF, блокчейн может очень хорошо стереть E, но блокчейн по-прежнему позволяет любому пользователю, подозревающему, что в транзакции участвует Билл Гейтс,докажите, что это так, действительно, такой пользователь может вычислить H (Билл Гейтс) и проверить, что
Расчетное значение совпадает с надежно сохраненным значением 1 /, Билл будет иметь все права на расстроение ».
Напротив, когда h ‘= H («Билл Гейтс», R), при условии, что R был выбран случайным образом, один раз «Билл Гейтс» и R были стерты, никто не знает, если и подозревает, что транзакция T относится к Биллу Гейтсу может подтвердить себе или доказать другим, что это так
В RTBF-нечестной транзакции 7 ‘= (X, E, R), однако, R может быть вовсе не случайным. Скорее, Эмитент T может выбрать R = 0, чтобы любой, кто угадал E, мог легко подтвердить ее правильность и угадать. Эту тонкую трудность можно избежать, заставляя эмитента T выбирать R случайным образом. Мы выполним такое принуждение, слегка адаптировав методы проверяемой случайной функции, впервые
блокчейн Algorand. Этот подход, однако, слишком технический для этого блога. Проще но разумная альтернатива дана в этой сноске.
Когда транзакция T = (X, E, R) считается приемлемой для сохранения в новом блоке 1 ‘,блок предложения случайным образом и независимо выбирает строку R ’, которую она включает в ED, — вместе с
(X, E, R), и два хеш-значения, которые она включает в BHl, — это h ‘= H (E, R, R ’) и h = H (X, h’) t.
Посмотрите, как с помощью этих простых модификаций все еще можно проверить подлинность всего T перед RTBF запрос сделан, или только X, после того, как был сделан запрос RTBF. Это также легко увидеть, пока один of R и R ’случайны, когда E стирается, никто не может правильно угадать E и подтвердить правильность догадки
Также возможно, чтобы предлагающий блок, а не эмитент T, выбирал R принудительным и строгим образом
Это решение на самом деле очень эффективное, но слишком техническое для целей этого блога.
RTGF-совместимые поставщики информационных услуг Algorand
Поставщики информационных услуг выполняют две важные функции:
(а) Предоставление возможности новым пользователям, желающим присоединиться к консенсусному протоколу, получать информацию, которая необходима(8,9., в BBB, остатки на последнем блоке); и
(б) Предоставление пользователям, которые не могут или не хранят весь блокчейн, доступ к конкретным частям информации, которая им нужна (например, данный блок или данная транзакция).
Безусловно, безопасное и эффективное использование этих функций является проблемой . Однако Algorand разработана уникальная технология для решения этой проблемы. По сути, технология Algorand позволяет поставлять информацию, чтобы ответить на каждый пользовательский запрос с кратким и убедительным доказательством того, что ответ действительно правильный. Важно, что такое доказательство основано исключительно на блоке генезиса, единственном блоке это можно считать однозначно известным.
Я посвящу отдельный блог этой новой и захватывающей технологии Algorand.Подчеркнем, что при запросе транзакции T = (X, E. R) честный поставщик возвращает (X, E, R), с надлежащим доказательством, если RTBF-запрос не был сделан относительно T. Иначе, он возвращает просто X, снова с надлежащим доказательством, вместе с надлежащим доказательством того, что T подвергался законному запросу RTBF.
Соответствующие органы могут легко проверить, является ли поставщик информационных услуг RTBF-совместимым.
Например, сохраняя инкогнито, они могут запросить провайдера и проверить, возвращает ли он информацию это должно было быть забыто. В принципе, они также могут проверить, хранит ли провайдер
информация, которую нужно было забыть, но это было бы более сложно. Аналогичная сложность возникает для поисковых систем. Предположим, что Google (1) попросили удалить »| страницу со страницей информация, (2) обещает это сделать, но (3) фактически не выполняет запрос. Тогда это легко право на конфиденциальность, чтобы узнать, что Google все еще раскрывает) . Однако гораздо труднее
полномочия проверять, нет ли у Google lS ofpoge p. Другими словами, это трудно доказать отрицательный.
Обратите внимание, что если обычный пользователь продолжает хранить личную информацию, которая была забыта,
другое дело. В случае поисковых систем такое ведение аналогично ведению отдельного пользователя. который продолжает сохранять страницу p, которая ранее была деинкриминирована. Хорошо известно, что RTBF делает не требует стирания всех копий забытой информации, когда-либо созданной и сохраненной кто угодно. В сентябре 2019 года Суд Европейского Союза постановил, что Google будет которую должен получить пользователь, может быть довольно небольшим. даже если блокчейн уже вырос, чтобы быть очень большим. Чтобы получить это безопасно. тем не мение. пользователи других блокчейнов должны скачать всю цепочку. что определенно не эффективно. Else. они должны доверять кому-то, чтобы дать им
правильная информация. что не безопасно. Рано или поздно. некоторые пользователи будут полагаться на неверную информацию. с возможно катастрофические последствия.