shareyourthinking

Зависимость надежности в удостоверении смарт-контрактов

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

Newton требует, чтобы приложения валидировали BLS-удостоверение в своем смарт-контракте перед выполнением. Без действительного удостоверения нет исполнения.

Это механизм принуждения, и также это жесткая зависимость.

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

Это не критика. Это выбор дизайна с реальными последствиями.

Протокол, интегрирующий Newton, больше не просто полагается на собственный код.

Он полагается на то, что кворум застейканных операторов будет оценивать политики и выпускать удостоверения для каждой транзакции бесконечно.
В whitepaper рассматривается обход цензуры через форс-инклюзию. Но в нем не описано, что происходит при реальном ухудшении работы операторской сети — не цензура, а недовыполнение или частичный простой.
#newt
Я на самом деле думаю, что обязательство по надежности — это вопрос, который больше всего важен для команд протокола, оценивающих Newton, а не набор функций соответствия. Добавление зависимости в смарт-контракт — навсегда, в том смысле, в котором добавление ее в веб-сервис — нет.
#NEWT
Что я еще не выяснил: есть ли режим управляемого деградирования — какой-то способ, чтобы протокол мог перейти к резервному варианту во время простоев операторов, а не останавливать работу полностью.
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt