🌴🌴🌴
Продолжу предыдущую тему
Теперь о Graftroot
⬇️⬇️⬇️
Taproot эффективен в случае «совместного закрытия», однако альтернативные варианты предполагают раскрытие ветвей Меркла, что также тянет за собой обработку больших массивов данных.
Технология Graftroot, предложенная Максвеллом, предполагает, что участники смарт-контракта создают «пороговый публичный ключ», но в дальнейшем они его не видоизменяют. Вместо этого они подписывают скрипты (альтернативные условия траты) с целью создания «пороговых подписей» для каждого из них.
Так, пользователь выбирает определенный скрипт, хранит его вместе с соответствующей подписью, которая может подтвердить, что альтернативное условие траты истинное и одобрено всеми участниками делегированное.
Вернемся к ситуации с А и Б, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть А может потратить монеты через неделю или же это может сделать Б, если он задействует секретное число. В этом случае они оба объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.
Затем оба участника создают и подписывают альтернативные скрипты. А сохраняет «пороговую подпись» для скрипта, который позволит ей осуществить трату через неделю, а Б делает то же для сценария с секретным числом. Отметим при этом, что “пороговых подписей” и соответствующих сценариев для траты недостаточно: они служат лишь подтверждением, что Б и А договорились об условиях. Для осуществления траты необходимо выполнить условия, заложенные в скрипте.
В случае провала «совместного закрытия», участники должны раскрыть альтернативный скрипт и «пороговую подпись». Сторонние пользователи смогут сопоставить «пороговый публичный ключ» с «пороговой подписью», чтобы подтвердить, что условия в скрипте были одобрены всеми сторонами. Таким образом они оба могут потратить средства, а другие пользователи никогда не узнают о наличии альтернативных сценариев.
Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».
Graftroot скрывает наличие альтернативных версий, однако в каждой транзакции должна указываться используемая версия протокола, которая может показать пользователям, какая именно технология использовалась.
Есть небольшая проблема, связанная с одновременным развертыванием всех этих функций. Каждый раз, когда развертывается новое «изменение консенсуса», оно требует нового формата адресации.
Новые адреса отличаются от старых, и этим выдают тех, кто уже использует новую функцию – тем более, что не каждый внедрит обновление сразу в день его запуска. Это займет время, точно так же, как и прошлые изменения. Это небольшой удар по конфиденциальности, однако одновременное развертывание всех этих обновлений превратилось бы в настоящий хаос.
Продолжу предыдущую тему
Теперь о Graftroot
⬇️⬇️⬇️
Taproot эффективен в случае «совместного закрытия», однако альтернативные варианты предполагают раскрытие ветвей Меркла, что также тянет за собой обработку больших массивов данных.
Технология Graftroot, предложенная Максвеллом, предполагает, что участники смарт-контракта создают «пороговый публичный ключ», но в дальнейшем они его не видоизменяют. Вместо этого они подписывают скрипты (альтернативные условия траты) с целью создания «пороговых подписей» для каждого из них.
Так, пользователь выбирает определенный скрипт, хранит его вместе с соответствующей подписью, которая может подтвердить, что альтернативное условие траты истинное и одобрено всеми участниками делегированное.
Вернемся к ситуации с А и Б, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть А может потратить монеты через неделю или же это может сделать Б, если он задействует секретное число. В этом случае они оба объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.
Затем оба участника создают и подписывают альтернативные скрипты. А сохраняет «пороговую подпись» для скрипта, который позволит ей осуществить трату через неделю, а Б делает то же для сценария с секретным числом. Отметим при этом, что “пороговых подписей” и соответствующих сценариев для траты недостаточно: они служат лишь подтверждением, что Б и А договорились об условиях. Для осуществления траты необходимо выполнить условия, заложенные в скрипте.
В случае провала «совместного закрытия», участники должны раскрыть альтернативный скрипт и «пороговую подпись». Сторонние пользователи смогут сопоставить «пороговый публичный ключ» с «пороговой подписью», чтобы подтвердить, что условия в скрипте были одобрены всеми сторонами. Таким образом они оба могут потратить средства, а другие пользователи никогда не узнают о наличии альтернативных сценариев.
Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».
Graftroot скрывает наличие альтернативных версий, однако в каждой транзакции должна указываться используемая версия протокола, которая может показать пользователям, какая именно технология использовалась.
Есть небольшая проблема, связанная с одновременным развертыванием всех этих функций. Каждый раз, когда развертывается новое «изменение консенсуса», оно требует нового формата адресации.
Новые адреса отличаются от старых, и этим выдают тех, кто уже использует новую функцию – тем более, что не каждый внедрит обновление сразу в день его запуска. Это займет время, точно так же, как и прошлые изменения. Это небольшой удар по конфиденциальности, однако одновременное развертывание всех этих обновлений превратилось бы в настоящий хаос.
