Обновление Safe Network 🇷🇺 15 сентябрь 2022 г

Это машинный перевод. Оригинал на английском здесь: Update 15 September, 2022

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

Общий прогресс

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

И @roland в значительной степени завершил переход от SectionChain (безопасный связанный список) к новому дизайну Section DAG. Еще немного испытаний, и мы на месте.

@qi.ma искал потенциальные ошибки в FilesContainers, так как в последнее время комнеты выявили некоторые подозрительные конфликты версий.

Мы также исследовали некоторые проблемы с подключением клиентов от узлов, которые, по-видимому, приводят к потере некоторых ответов. И удаление ненужных шагов сериализации вокруг OperationId, что еще больше снижает нагрузку на узлы.

Орган власти

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

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

Почему это важно? Что ж, это важно, потому что мы хотим четко разграничить, кто что может делать. Насколько это возможно, мы хотим, чтобы полномочия были неявными в типах данных и операциях, чтобы они контролировались криптографией, а не сложными иерархиями, и нам нужны максимально простые структуры авторизации.

Типы данных

Разрешения встроены в типы данных.
Неизменяемые данные
Когда дело доходит до мутации, куски неподвластны авторитету. На планете нет власти, которая позволила бы вам изменить данные. Поэтому нам не нужно беспокоиться о разработке для них логики авторизации.
Однако для хранения фрагмента нам нужны полномочия, в данном случае они предоставляются Разделом, в котором они должны храниться, и однажды предоставленные эти полномочия применяются навсегда. SectionAuth — это действительный ключ раздела плюс подпись.

Изменяемые данные
Для хранения контейнеров требуется SectionAuth, а для их изменения требуется ClientAuth - только владелец должен иметь возможность изменять свои данные. Таким образом, в этом типе данных подразумевается, что он требует подписи клиента, прежде чем его можно будет изменить. ClientAuth является действительной подписью клиента.

Другим типом изменяемых данных является SectionTree, дерево, ответвляющееся от Genesis. Здесь ситуация немного отличается, так как фактически есть несколько владельцев (все разделы), но каждый раздел может добавить лист только к своей конкретной ветке со своим SectionAuth.

DBC немного сложнее, поскольку они требуют, чтобы клиент авторизовал повторный выпуск (ClientAuth) и раздел, чтобы подписать его (SectionAuth), но опять же, до тех пор, пока к нему не будут прикреплены эти два бита полномочий, DBC эффективно бесполезный.

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

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

Операции с данными

В терминах REST API операции с данными выглядят так:
Операции GET не требуют никакой авторизации.
Для операций PUT требуется SectionAuth для хранения и комбинация ClientAuth и SectionAuth для оплаты.
Операции POST требуют ClientAuth для изменения контейнеров SectionAuth для изменения отдельных листьев SectionDAG.

Для передачи токенов требуется комбинация ClientAuth и SectionAuth.

Сетевые операции

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

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

А для DKG жизненно важно, чтобы сообщения, отправляемые старейшинами с их долей голосов, были авторизованы. Авторитет сообщения принадлежит отправителю и проверяется по его подписи в сообщении. Это называется «NodeAuth».

Хорошо, но для чего все это?

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


Полезные ссылки

Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.

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